[Geany-devel] project build tab - Re: GTK+ Version Bump to 2.18 - gtkbuilder and 2.16

Nick Treleaven nick.treleaven at xxxxx
Tue Oct 18 16:30:47 UTC 2011

On 18/10/2011 00:36, Matthew Brush wrote:
> On 11-10-17 04:27 PM, Lex Trotman wrote:
>> On 18 October 2011 10:17, Matthew Brush<mbrush at codebrainz.ca> wrote:
>>> I also noticed some issues with defaults in the project dialog where
>>> some
>>> stuff doesn't have a default and some of the combo boxes have two
>>> columns
>>> showing so it looks like:
>>> "Item 1 Item 1"
>>> "Item 2 Item 2"
>>> IMO, it would *really* be nice to get all of the Project dialog
>>> ported to
>>> GtkBuilder since currently only the Editor and Indentation tabs are in
>>> GtkBuilder, the "Project" tab and the Build tab are both hard-coded and
>>> added to the dialog at runtime it seems.
>> Hi Matthew,
>> Yes, the build tab is generated at runtime because it has variable
>> length (set by the number_xx_menu_items prefs).
>> Possibly it could be a treeview, but that would change the whole
>> operation of the build tabs and would need discussion with Nick who
>> has strong ideas on the subject :)

Not really, I'm just opposed to replacing groups of commands with a list 
of commands as I think this is worse usability.

I think a treeview for each command group wouldn't really change things 
and might look better. Is there a way to show a label with mnemonic in a 
treeview column? Not crucial but nice to have.

> +1. I actually started tinkering with making it a treeview in Glade,
> since it makes way more sense to not have a hardcoded number and types
> of build commands, but of course as we discussed before, there needs to
> be a fixed number of commands at startup due to the limitations in the
> keybinding system.

Not necessarily, but sort of. Keybindings that map to a non existent 
command could just do nothing.

> Anyway, for now, we could add the whole UI into Glade except the dynamic
> part and just append/insert rows for more commands at run-time for the
> parts that change. At least 95% of it would go into the UI file.

Sounds good, but maybe it's best to wait until after the merge into 
master. I think branches should stay focused on one thing; that sounds 
like a bigger change.

More information about the Devel mailing list