[Geany-devel] build commands - Re: SF.net SVN: geany:[5915] trunk/TODO

Nick Treleaven nick.treleaven at xxxxx
Thu Sep 15 15:18:54 UTC 2011

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

> So it was late at night and I never actually said what I
> meant, can't
> you read my mind?

I realized later you might want the TODO changed, see below.

> >> > +       o (filetype-independent run
> command &
> >> keybinding)
> >>
> >> This only needs a GUI, you can already put
> filetype
> The point that I meant to make was that the to do is
> misleading and
> should be re-worded to be a GUI change, IAW the conclusion
> we came to
> in the conversation you cite below.

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.

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.

> >> Keybindings need to be for all extra commands,
> filetype and
> >> filetype
> >> independent ones, not just the exe one.  Probably
> the
> >> whole build
> >> keybinding group needs to be made dynamically like
> plugin
> >> groups are
> >> so the size can be determined at runtime?
> This is a question about possible implementation that might
> be simpler
> than previously thought, IIUC plugin keybindings groups get
> their
> keybindings saved and restored for them, although they are
> dynamically
> added entries.  If nothing is saved then they can be
> set to a default
> value.  The build keybinding group can be re-sized
> based on the config
> entries at startup, which seems to me to be very similar to
> plugins.

It might not require many changes to allow this, not sure.

I don't think the TODO requires dynamic keybindings though.

> As a general question that I have never thought about
> before, how is
> the to-do list (which is in the VCS and the distribution so
> it must be
> official right?) maintained and community agreement reached
> on what is
> in it and the priorities?

It is sometimes out of date or missing things. I use it as a reminder and to let others know about important things. I think we should avoid putting everything in it, it would require too much maintenance. I'm in favour of a Wiki version also, so long as it stays focused (not a wishlist) and based on concensus.


More information about the Devel mailing list