An extra Edit -> Preferences tab for editing the hidden prefs (renamed to various). All prefs are safe to change AFAICT (checked them one by one), but a few require restart. The screenshot should be self-explanatory.
It's me again!
2) cool then, I definitely prefer the experience with the spin button :)
About saving on focus leave, I changed the implementation quite a bit, because it needed GTK 2.20 to work properly (without it it wasn't possible to cancel at all). Additionally, though the patch should be self-explanatory on these points:
- integer settings don't seem to need the hack, so I removed it for them
- I used gtk_cell_editable_editing_done() in :focus-out-event, and it seems to handle cancellation perfectly well.
I tested the whole patch with both Debian Sid (GTK 2.24.4) and Lenny (GTK 2.12.12) and it seems to work fine on both :)
Finally, I have two more remarks (sorry for not having formulated them before, but just came to my mind now):
1) Documentation needs an update. Could you do it? (please :D)
2) Maybe a link on the pref page to the documentation of these preferences would be a good thing?
Ah, and we use an indentation width of 4, so if there is some alignment it should be done for this width ;) (I think of the inclusions at the top of stash.c)
Anyway, good job! With the few changes the patch I attach introduces, I think it's OK to commit -- apart the two little things I mentioned above.
 Virtualization's good :p
Yes, spin renderer doesn't need the hack, and is out of sync with text renderer. Probably spin's focus out is executed before text's, and gets the canceled flag before text has the chance to set it. I wonder if we should rely on that - looks more like a bug to me.
gtk+ says that remove-widget must be emitted after editing-done. Now, we know that text renderer's focus-out emits one, but...
BTW, why do you speak about validation? From what I see, the text rendered simply installs an entry focus-out signal and unconditionally sets editing canceled (though it's a mystery to me what happens another part of the list is clicked). Anyway, I'd like to know if there's anything else, and either make the comments more clear ("magically" bugs me), or remove the hack altogether, as it only affects statusbar_template.
Forget it, I'm removing the hack, because it blocks entry's popup menu. Yes, we can trap the popup populate and unmap signals, but that's a bit too much. The spin renderer menu is blocked too, which is probably a gtk+ bug, but at least typing a digit or two (in our case) needs no input method changes or unicode characters.
OK, changed the documentation, except for a Various page screenshot - my theme and fonts are quite different.
About the link - unfortunately, glade 2.12.2 does not seem to support such a widget. Of course, I can add one programatically. Or maybe set the hbox spacing to 0 and add a prefix label, followed by a link and a suffix label, as in labels-with-link.png - looks better than all-blue, indented text. RFC.
updated geany.txt, removed the focus-out hack
No problem for the screenshot, Enrico will take care of it short before the release. Adding a placeholder image may be a good idea though. (done in the patch)
Well, forget it. It's not really doable with GTK < 2.18 (which supports links in labels), and anyway we have the Help button -- just make this one work. I did it in the patch, it's fine.
For the doc, great! I just don't really like the way whether the pref needs restart & co is exposed, and I have an alternative suggestion (in the attached patch). Any remarks?
Once again I join a review patch, but we should be close to the final version :)
review diff for arious-prefs-5861-g
> we have the Help button -- just make this one work.
Really... Well, since the manual states which settings need restart in much more detail, I replaced the restart notice with a suggestion to read the documentation. Maybe remove it alltogether? Having a Help button should be enough for anybody... though I haven't used one in years, since the help is usually something like "enter the file name in the File name field".
> I just don't really like the way whether the pref needs restart
> is exposed, and I have an alternative suggestion (in the attached
> patch). Any remarks?
In the text version, the first two cells read to me as "Applies immediately to new documents", especially because they are the first ones. Swapped them.
> we should be close to the final version
Aye. We tried a lot of things, feels like time to settle.
applied 5861-g-review, small changes