[Geany-devel] Committed Project Build Commands to build-system branch
nick.treleaven at xxxxx
Thu Nov 6 13:37:24 UTC 2008
On Thu, 6 Nov 2008 21:06:09 +1100
Lex Trotman <elextr at gmail.com> wrote:
> > Cool. I just made some minor commits to fix a warning and refactor
> > some GUI code.
> Ok, warning that this is still a prototype, GUI code is still being
> changed to get the full functionality shown in the geany.txt I
> committed recently.
OK, I'll look at the manual changes hopefully today. The small change
was just for code organization.
BTW, you can commit code that doesn't build, or work-in-progress, no
need to wait until it's ready to test, if you have a lot of changes in
your working copy.
> > BTW there are some formatting issues:
> > 1. Some spaces instead of tabs being used for indentation (e.g. in
> > build.c).
> > 2. Spacing - instead of:
> > if( blah!=foo )some_func( foo );
> > use:
> > if (blah != foo) some_func(foo);
> > Please use the existing code style (see HACKING).
> Do you have a configuration for one of the usual source formatters to
> get the format you want, I AM going to continue to get it wrong
> because it is different to the standard format I use all day every
> day at work. The fingers just automatically put spaces on the other
> side of the ( ) etc. Even if I'm thinking about it, it will get done
> wrong from time to time ;-). You are correct that it should be
> consistent within Geany so if there is a formatter that will generate
> the format used throughout Geany I will ensure that I use it.
I haven't really tried them, I wrestled with GNU indent once but
couldn't work out how to tell it to use tabs only. Probably there's
a better formatter out there, but you'll have to play with the options
to get a matching style.
> > The indentation is the most important one, could you fix this
> > please?
> Well, all editing has been done in Geany with indentation set to tabs
> so I don't know where the problem came from??? but I can fix it.
Somehow your commit has introduced them, they weren't there before in
build.c (and elsewhere). Try seaching with the regex "^\t* +" (note the
2 spaces to prevent matches for multiline comments).
There will be a few matches for Glade callback argument alignment, but
other than these all lines should only use tabs.
Sorry to be pedantic ;-)
> > 2. I think we should move the new build_* GeanyProject fields to a
> > GeanyProjectPrivate struct, similar to
> > GeanyDocumentPrivate/GeanyFiletypePrivate. The implementation of
> > those fields might change, so they shouldn't be in the plugin API.
> > I can make this change unless someone disagrees.
> Don't worry, I'll do that because I have already made some changes in
> that area to support the full functionality. No point in doing it on
> the prototype when there are more changes to come.
> > > If a project is open the dialog will have extra fields to provide
> > > labels and commands to replace
> > > the "Make" series of menu items on the build menu.
> > (I guess replacing the make menu items is not implemented yet.)
> Did you have a project open? the prototype only adds these items to
> the menu or the build commands dialog when a project is open. The
Yes, I set 2 project build commands, then checked the menu. It doesn't
work after updating the dialog, but reopening the project does work.
BTW there was a bug where the 3rd project build menu item is created
based on the 2nd label.
> full version will also show them for preferences which isn't
> implemented in this version. Coming real soon now though :-) maybe [?]
Not quite sure what you mean, but I'll read the manual changes first.
> > Maybe by default they should be set to the default make command
> > labels and commands. Otherwise the dialog is unintuitive - just
> > empty boxes.
> The full version will work that way, see the manual. Note these are
> generated if there is nothing saved in the project or preferences.
> That way the menu label strings are translated like any string is.
> It is assumed that when a user edits a label they will do it in the
> language they want and so no translation is needed for the label
> saved in project or preferences, but it is important that there is no
> default value saved that isn't translated.
> > > At the moment there is no way to reset project commands to default
> > > without hand editing the
> > > project file.Setting them to blank does just that, it doesn't
> > > reset to default. A "reset to default"
> > > button will be added.
> > Hmm, why not just use the default if they're blank?
> Because in the full version blank means don't show this menu item,
> this makes the build commands operate the same as the filetype
> commands which do not show unused commands.
OK. Maybe a checkbox to enable them, on by default, might be better.
But no need to implement this.
> NOTE: this brings up one significant change needed for the full
> version, the can compile, can build, flags of the filetype will no
> longer be used since the existance (or not) of such a command is what
> determines if a menu item is shown. Otherwise users would not be
I agree, I wanted to remove them before.
> able to add filetype commands to unused filetype menu items. So in
> the full version, a commandwhich is not set will mean use the default
> whilst one set to nothing (item name) will mean don't use. Have to
> allow 'command set to nothing' just in case someone wants to use the
> make custom dialog to type the whole command, possibly useful for
> occasionally used commands whilst still capturing and parsing the
> command output.
> But are there any other important uses of these flags besides
> controlling what is shown in the build menu?
If so, they can be replaced with if (NZV(ft_command_str)) checks (or
maybe just checks against null for the custom command).
More information about the Devel