--- On Thu, 15/9/11, Lex Trotman elextr@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.
Regards, Nick
[...]
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.
There is actually no distinction between filetype and non-filetype commands. They override based on their position in the menu, so if you added one in position EX_00 in a source higher up the hierarchy you would override the default filetype run command.
While you were away I added another writeup to the wiki, http://wiki.geany.org/howtos/configurebuildmenu that might help. Any comments welcome, so far I havn't had any significant ones so either: no-one has read it, its perfect (unlikely), or everyone is so overawed they don't know what to say :)
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.
When writing the wiki description I came to the decision that a simple to use restrictive GUI was best, so maybe this is one way of doing that, although most of the commands will be in build part, the run part will be a bit empty won't it?
My feeling is that the notebook page(s) should only be a summary of the major options for all menu items and a details subdialog showing all the options for one menu item should be used to edit things. This helps to reduce the size of the notebook pages. As we anticipated there have been several suggestions for things that would require additional build settings in addition to the extras that were discussed in the past. Accommodating this would be easier in the details dialog.
[...]
It might not require many changes to allow this, not sure.
I don't think the TODO requires dynamic keybindings though.
True, keybindings is separate from the GUI changes.
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.
Agree, as we have discussed in the past I am in favor of some more planning of the future direction (we don't want a lumpy uncoordinated version of Eclipse to result) and the wiki todo should be the result of that, maybe with a separate wishlist page as input to the process.
Cheers Lex
--- On Fri, 16/9/11, Lex Trotman elextr@gmail.com wrote:
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.
There is actually no distinction between filetype and non-filetype commands. They override based on their position in the menu, so if you added one in position EX_00 in a source higher up the hierarchy you would override the default filetype run command.
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 separate.
While you were away I added another writeup to the wiki, http://wiki.geany.org/howtos/configurebuildmenu that might help. Any comments welcome, so far I havn't had any significant ones so either: no-one has read it, its perfect (unlikely), or everyone is so overawed they don't know what to say :)
Seems quite detailed. Perhaps the build section in the manual could be made more terse now we have detailed explanations in the wiki?
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.
When writing the wiki description I came to the decision that a simple to use restrictive GUI was best, so maybe this is one way of doing that, although most of the commands will be in build part, the run part will be a bit empty won't it?
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.
My feeling is that the notebook page(s) should only be a summary of the major options for all menu items and a details subdialog showing all the options for one menu item should be used to edit things. This helps to reduce the size of the notebook pages. As we anticipated there have been several suggestions for things that would require additional build settings in addition to the extras that were discussed in the past. Accommodating this would be easier in the details dialog.
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.
Nick
Hi Nick,
[...]
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 separate.
Agree it would mean adding an extra group, otherwise there is no way of separating them. But I don't see that a big problem.
[,,,]
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.
[...]
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.
[...]
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.
Cheers Lex
--- On Fri, 16/9/11, Lex Trotman elextr@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 separate.
Agree it would mean adding an extra group, otherwise there is no way of separating them. But I don't see that a big problem.
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 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.
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 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.
Nick
P.S. thanks for the welcome back in the other thread ;-)
[...]
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