[Geany-devel] independent run commands & build/run split - was build commands

Nick Treleaven nick.treleaven at xxxxx
Fri Sep 16 11:11:54 UTC 2011


--- On Fri, 16/9/11, Lex Trotman <elextr at gmail.com> wrote:

> > Now done. Does the non-GUI option override the
> filetype run command? I mentioned keybinding in the item
> because it's more flexible as a different command.
> 
> There is actually no distinction between filetype and
> non-filetype commands.
> They override based on their position in the menu, so if
> you added one
> in position EX_00 in a source higher up the hierarchy you
> would
> override the default filetype run command.

Hmm, this would mean we can't easily add a GUI option for independent run commands as they currently share slots with filetype run commands. I would prefer them to be separate.

> While you were away I added another writeup to the wiki,
> http://wiki.geany.org/howtos/configurebuildmenu that
> might help.  Any
> comments welcome, so far I havn't had any significant ones
> so either:
> no-one has read it, its perfect (unlikely), or everyone is
> so overawed
> they don't know what to say :)

Seems quite detailed. Perhaps the build section in the manual could be made more terse now we have detailed explanations in the wiki?

> > Even with the overriding, a GUI option would still be
> nice. I'm now preferring a Build/Run notebook tab split
> rather than filetype/independent. That way we can avoid a
> subnotebook for the project dialog.
> 
> When writing the wiki description I came to the decision
> that a simple
> to use restrictive GUI was best, so maybe this is one way
> of doing
> that, although most of the commands will be in build part,
> the run
> part will be a bit empty won't it?

Currently it would be half the size of the build tab, as there's only filetype run commands there. But I think it's cleaner than a filetype/independent notebook tab split, and fits with the project dialog better.

> My feeling is that the notebook page(s) should only be a
> summary of
> the major options for all menu items and a details
> subdialog showing
> all the options for one menu item should be used to edit
> things.  This
> helps to reduce the size of the notebook pages. As we
> anticipated
> there have been several suggestions for things that would
> require
> additional build settings in addition to the extras that
> were
> discussed in the past.  Accommodating this would be
> easier in the
> details dialog.

As we discussed before, the current fields should stay on the main dialog. Any extra, less frequently edited settings can be on a details dialog, which can replace the 'edit menu item label' dialog.

Nick



More information about the Devel mailing list