?

Log in

No account? Create an account
I'd also like to note that I encountered a pretty strange pattern in… - LogJam [entries|archive|friends|userinfo]
LogJam

[ website | LogJam ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Dec. 21st, 2000|04:10 am]
LogJam
logjam
[evan]
I'd also like to note that I encountered a pretty strange pattern in GTK that made the postas support much more difficult than it should've been.

The "post as" menu is built every time you login (because the list of accessible postas names is part of the login data). If you specify --postas on the command line, then, it needs to set the check by the correct journal name on the menu when the menu is built.
Three designs conspired to make this not work:
As you build a radio menu (as that sort of menu is called), GTK automatically checks the first option on the menu.
The "activate" signal (which indicates when an option is selected) is also emitted when an option is deselected.
From the function which is called by that signal, it is impossible to tell if the option has just been selected or deselected.

So: when I build the menu, and check another user for postas, GTK emits the "activate" signal on the *first* user. And there's no way for the code to determine that it's just GTK wackiness, and not the user's request to actually *switch* to the first user.

By reorganizing the order of signal attachment and menu checking, I managed to work around it... but...
Man, that took a lot of time.

Good news: I learned more about GDB. I now feel pretty comfortable with breakpoints!

Update:
It turns out there's a field of the struct from which the radio menu item widget is derived that lets you see if it was activated or deactivated...
Operator error, as usual. :)
LinkReply