[Geany-devel] independent run commands & build/run split - was build commands
nick.treleaven at xxxxx
Fri Sep 16 16:45:54 UTC 2011
--- On Fri, 16/9/11, Lex Trotman <elextr at gmail.com> wrote:
> > 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
> Agree it would mean adding an extra group, otherwise there
> is no way
> of separating them. But I don't see that a big
I think it would make for a simpler and more consistent GUI - consistent with build commands having two groups.
Anyway independent run commands aren't too important a feature. Not bothered enough to implement a separate group for now, but it would be better if we do add GUI support for those commands.
> > Seems quite detailed. Perhaps the build section in the
> manual could be made more terse now we have detailed
> explanations in the wiki?
> I guess that depends on what the relationship between the
> manual and
> the wiki ends up being, remember the manual is installed,
> the wiki
From what I remember the manual seemed to repeat some things and was overall too long, but YMMV. If you think the wiki is too ephemeral we could maybe make your doc an official webpage.
> > 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.
> If we added two independent run commands it would be half
> yes. Agree
> against filetype/independent split, not sure what you meant
> about the
> project dialog, it needs to match the build dialog.
The build dialog would need a notebook, but the project dialog already has one. So we can just append a 'Run' tab for the project dialog.
Even if we don't add an independent run command group, I think the build/run split is good because it reduces the size of the build dialog. Maybe Enrico would agree on that point?
Build and run are quite different actions, so shouldn't be grouped together.
This is something I might do sometime, assuming it's not a bad idea.
> > 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.
> There should be only one place to edit things, not some
> fields in the
> notebook and some in another details dialog. It is
> better UI design
> to not have to skip back and forward to get the whole
We said before that the user shouldn't have to click an extra button to edit a command. That is something frequently done. Enrico did agree on that point.
P.S. thanks for the welcome back in the other thread ;-)
More information about the Devel