[Geany-devel] ANN: Configurable Build Menu Alpha in SVN

Lex Trotman elextr at xxxxx
Sat Jul 18 12:17:06 UTC 2009

2009/7/18 Enrico Tröger <enrico.troeger at uvena.de>:
> On Fri, 17 Jul 2009 10:03:15 +1000, Lex wrote:
>>> - you really should fix the compiler warnings, I get a whole bunch
>>> when compiling the code (see attachment). Most of them are harmless
>>> like unused variables but the more warnings you usually have, the
>>> bigger the danger is to overlook a real warning which you want to see
>>I don't get any of these, is there an option I need to give make or
>>configure to make it picky???
>>Should be all fixed, but I can't actually check since I don't get them.
>>BTW the filetypes one was useful, but most build ones were just
>>annoying thankfully.
> The most important flag is -Wall, this should be used generally I
> think. I personally use some more flags like (set before
> running ./configure resp. ./waf configure):
> export CFLAGS="-Wall -O0 -g -pipe -march=athlon64 \
>        -DGEANY_DEBUG \
>        -D_FORTIFY_SOURCE=2 \
>        -Waggregate-return \
>        -Wdeclaration-after-statement \
>        -Wdisabled-optimization \
>        -Wfloat-equal \
>        -Wformat-nonliteral \
>        -Wformat-security \
>        -Wformat=2 \
>        -Winit-self \
>        -Winline \
>        -Wmissing-field-initializers \
>        -Wmissing-include-dirs \
>        -Wmissing-noreturn \
>        -Wpointer-arith \
>        -Wshadow \
>        -Wsign-compare \
>        -fno-common \
>        -funit-at-a-time \
>        "
> But this is enables rather much stuff. Anyway, the latest SVN builds
> pretty fine with these fine, good job.
Oh, OK environment variable!!

couple of (maybe helpful, maybe not) comments

I think Wformat=2 includes Wformat-security and Wformat-nonliteral
I don't think Winit-self will work without -Wuninitialized and -O1
Winline seems wasted since no Geany currently inlines and anyway its
not really useful even if you use inlines, if the compiler won't
inline something, it won't, so whats the point of a warning? (C++ user
funit-at-a-time isn't much use at low optimisation levels & is
automatically on at high levels anyway.

probably worth Wstrict-prototypes
>>> - the build settings dialog needs love. First, it needs some spacing
>>> between the GUI elements to match the other Geany dialogs look&feel
>>> and also to be more compliant with the Gnome HIG. But this is low
>>> priority and can be improved later as this is GUI stuff only.
>>No problem, whats your standard spacing etc?
> See the Gnome HIG :).
> Using ui_dialog_vbox_new() gives you the correct border spacing for the
> dialog. Then there is some padding missing between the single GtkEntrys
> maybe add two or three pixels.
> And maybe it looks better when you set the icon size of the clear
> buttons to GTK_ICON_SIZE_MENU but that's not really a big thing.

Ok I'll try those tomorrow, today was toolbars (almost).

>>> Not yet sure whether we can improve this, will think about this a
>>> bit. But at least, please don't make it even bigger. Imagine you are
>>> a new user and just want to change the Run command, in the current
>>> dialog you first need to figure out which field does what and where
>>> the field is you actually want to edit.
>>> Don't get me wrong, it's pretty cool so far but maybe we can make it
>>> even cooler. And I'm not one of those Gnome guys who somtimes like
>>> hide/remove any option from the user. But there is also the other way
>>> to overload the GUI with useless stuff. And so, I'm just about to
>>> find a best way in between :).
>>I agree, its now the biggest dialog in Geany, its just that there is a
>>certain amount of functionality to configure, any suggestions welcome,
>>but I can't see a sensible way of dividing it up to make it smaller.
>>At the moment it reflects the way the menu is laid out.  I think its
>>important to keep that relationship for easy use.
> Yes, as I said I don't have a better idea so far and so I'm not in the
> position to criticise the dialog too much :).
> Maybe we find a solution, if needed at all, later. And since the dialog
> UI exists for now, it's more important to get everything behind
> working. Changing the GUI can be done easily afterwards.

Yes, I am about to say that this branch is feature complete and any
problems that come up now are bugs or put in the TODO list
>>forward to see which directories related to which commands.  Maybe we
>>*have* to be Gnomic and have the working dir column hidden unless the
>>user selects to make it visible.
> The question is whether this makes it better or not regarding
> usability.
> Regards,
> Enrico
> --
> Get my GPG key from http://www.uvena.de/pub.asc
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list