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

[Lex Trotman]

[...]
> 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.
>

Agree.

>> > 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
>> isn't.
>
> 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.
>

Up to the general Geany community, I don't mind either way.

>> > 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.
>

Oh, I see what you mean now.  Both have a build and a run tab.

> 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.
>

Well, they are in the same menu, that was the original model, to have
the dialog ordered the same as the menu.  But splitting it isn't such
a problem.

> 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
>> picture.
>
> 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.

And we continue to disagree on this point :)

 I'm don't think we should start a discussion now. When someone has
the time to implement it, then both should be prototyped and put to
the community.

Cheers
Lex