[Geany-devel] build-system branch geany.txt changes

Nick Treleaven nick.treleaven at xxxxx
Mon Oct 13 12:07:19 UTC 2008

On Sat, 11 Oct 2008 17:47:31 +1100
"Lex Trotman" <elextr at gmail.com> wrote:

> > 1. 'Make Commands' is mentioned, perhaps this should be renamed
> > 'Global Commands', as these may well be nothing to do with 'make'.
> I agree it should be changed from 'Make'  but I had trouble getting a
> term I was happy with.
> This was a general issue throughout the document, what group term to
> use for the builder commands?
> Builder itself I thought was too close to the 'build' command which
> doesn't use the builder ;-)
> "Global" I felt could be taken as a reference to storing them
> globally and what is being implemented
> is actually storing them in the Project file or user prefs.  Unless
> the build command is changed
> allowing the use of builder as the group name for the make commands?

Hmm, personally I thought global could just mean for all documents.
Maybe if a project is open, change the group name to 'Project Commands'.

What does everyone else think?

> > 3. Do we need the table of default filetype build commands? If so,
> > IMO it should be autogenerated and included/referenced from
> > geany.txt rather than writing by hand.
> >
> I think it is useful to let the user know what the defaults are so
> they don't need to go look.
> But it probably should be in an appendix and referenced from here.
> Autogenerating I like, you can see how far I got manually.

Yes, an autogenerated appendix would be good. (BTW don't feel you need
to implement everything I/we suggest, just work on what you want.)

> > 4. I think 'Project Make' should be configured from the Project
> > Properties dialog. In this case the global Make command could be
> > grayed out in the Configure Commands dialog.
>  IMO its better UI practice to have all the build menu commands
> configured from the one dialog box
> activated from the build menu.
> Attached is a quick mockup of the dialog,
> Note that the label "Commands for filetype C" will change to the type
> of the current file,
> eg "Commands for filetype Python".
> Note also that the label "Project Builder Commands" will be "Preferred
> Builder Commands" if no project is open.

OK. Maybe 'project builder' suggests a build system, perhaps just
'project commands'? I know that for now they will all be build commands
for the project, but maybe in future we will extend it for other

But the syntax doesn't matter much at this stage, just adding my
thoughts. Sometimes it's hard to design by committee ;-)

> > 5.
> > +Remember that menu item two (default the 'Make Custom Target' item)
> > +will pop up a dialog to ask for additional targets/options when
> > invoked +allowing you to add to the command you define here.
> >
> > Should this just be the 'Make Custom Target' item? (not menu item
> > two)
> >
> Well the section was talking about changing the menu labels and
> commands so it
> might not say "Make Custom Target", hence my hedging it by putting it
> in brackets and
> noting it as default.  Menu item two is somewhat ugly maybe "the
> second menu item" but
> any better suggestions for referring to a menu item independently of
> its label will be gratefully
> received.

Maybe the 'Make Custom Target' could be a more generic 'Custom command'
but with a configurable starting string. The default label could still
be 'Make Custom Target' but we could refer to it as the 'Custom
command' item.


More information about the Devel mailing list