Is there a way to fold the source code view to certain depth level?
"Fold All" option now fold everything to first level:
[-] First() [-] second() [-] third; [-] forth
becomes:
[+] First()
If possible, folding to to certain depth level would be useful. e.g: fold to level 2
[-] First() [+] second()
Or 3rd..
But i can imagen adding this to the GUI would cause clutter. So perhaps user configurable key accelerator for this would be realistic.
This is the kind of thing that I see being useful in C/C++ header files, because of the
#ifndef MYCONSTANT_H #define MYCONSTANT_H ... #endif
fold that gets on the first level.
Just though I should highlight it to clear a situation where this feature is indeed really useful.
2006/7/20, Nexu nexu.jin@gmail.com:
Is there a way to fold the source code view to certain depth level?
"Fold All" option now fold everything to first level:
[-] First() [-] second() [-] third; [-] forth
becomes:
[+] First()
If possible, folding to to certain depth level would be useful. e.g: fold to level 2
[-] First() [+] second()
Or 3rd..
But i can imagen adding this to the GUI would cause clutter. So perhaps user configurable key accelerator for this would be realistic.
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Well. Sorry, I just hit the "send" button by accident, before putting the text in its right place or finishing the message.
2006/7/20, Alexandre Moreira alexandream@gmail.com:
This is the kind of thing that I see being useful in C/C++ header files, because of the
#ifndef MYCONSTANT_H #define MYCONSTANT_H ... #endif
fold that gets on the first level.
Just though I should highlight it to clear a situation where this feature is indeed really useful.
2006/7/20, Nexu nexu.jin@gmail.com:
Is there a way to fold the source code view to certain depth level?
"Fold All" option now fold everything to first level:
[-] First() [-] second() [-] third; [-] forth
becomes:
[+] First()
If possible, folding to to certain depth level would be useful. e.g: fold to level 2
[-] First() [+] second()
Or 3rd..
But i can imagen adding this to the GUI would cause clutter. So perhaps user configurable key accelerator for this would be realistic.
Everyone in this list might know right now that I am a heavy advocate for having plugin system planned once 1.0 is finally out.
With that said, I'd like to add that this would be really easy to get done, if we add the right hooks in Geany and let it be controlled by scripts in, say, Python or TCL (or even C plugins).
We would only have to create a system where a plugin could navigate through all folding markers at the current file, and then a user script/plugin could do the feature. That way the GUI for that wouldn't really be a Geany core problem, and plugins could configure their own gui the way they wanted, be it a weird button on the toolbar or a keybinding for the user.
Cheers, Alexandre Moreira.
_______________________________________________
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
On 7/20/06, Alexandre Moreira alexandream@gmail.com wrote:
We would only have to create a system where a plugin could navigate through all folding markers at the current file, and then a user script/plugin could do the feature. That way the GUI for that wouldn't really be a Geany core problem, and plugins could configure their own gui the way they wanted, be it a weird button on the toolbar or a keybinding for the user.
...as the guy who opened the can of extensibility worms, I feel like I should pipe up here. Please note that this branch of the discussion is hypothetical and contingent upon the idea that geany will one day have scripting hooks or the like.
Leaving the interface design decisions to the plugin/script writers is a dangerous idea. If a system of external hooks is to be implemented -- and I hope it will be -- the smart thing to do would be to _require_ specific interface schema. I would suggest requiring _both_ a menu entry and a configurable keybinding. Fooling about with the standard toolbar is a bad idea from a usability standpoint; it would make more sense to have an optional second toolbar containing the access elements for scripts and plugins.
I say this because of firefox. Firefox is basically the "standard" extensible GUI program -- I know it's been done before, but never with as much success as firefox. It's led to a nightmare of usability problems. Some extensions add menu items, some add toolbar icons, some add toolbars, some add icons or text to a status bar -- it's a bit of a chore to track down the interface elements for any given extension. As an example, I submit the Download Manager Tweak. Great extension, but it produces the only sidebar in Firefox without a keybinding to close it. It forces the user to hit a tiny button somewhere in the left third of the window.
Basically, I submit that part of any extensibility framework within geany needs to tightly control who puts what buttons where. I'm partial to what I said earlier: add menu entries as needed. Extensions with more than one menu entry need to cascade them tro avoid cluttering the main menu windows. Each menu entry must have a keybinding -- even if it defaults to nothing, it should let the user change it. As for toolbar modifications, I think they should be restricted to an "extensions" toolbar; that way installing a third-party extension or script doesn't disrupt or destroy standard toolbar buttons.
Geany is a great program. I'm keenly interested in helping it stay that way. :)
Kurt
2006/7/20, Kurt Maier karmaflux@gmail.com:
On 7/20/06, Alexandre Moreira alexandream@gmail.com wrote:
We would only have to create a system where a plugin could navigate
through
all folding markers at the current file, and then a user script/plugin
could
do the feature. That way the GUI for that wouldn't really be a Geany
core
problem, and plugins could configure their own gui the way they wanted,
be
it a weird button on the toolbar or a keybinding for the user.
...as the guy who opened the can of extensibility worms, I feel like I should pipe up here. Please note that this branch of the discussion is hypothetical and contingent upon the idea that geany will one day have scripting hooks or the like.
Leaving the interface design decisions to the plugin/script writers is a dangerous idea. If a system of external hooks is to be implemented -- and I hope it will be -- the smart thing to do would be to _require_ specific interface schema. I would suggest requiring _both_ a menu entry and a configurable keybinding. Fooling about with the standard toolbar is a bad idea from a usability standpoint; it would make more sense to have an optional second toolbar containing the access elements for scripts and plugins.
I say this because of firefox. Firefox is basically the "standard" extensible GUI program -- I know it's been done before, but never with as much success as firefox. It's led to a nightmare of usability problems. Some extensions add menu items, some add toolbar icons, some add toolbars, some add icons or text to a status bar -- it's a bit of a chore to track down the interface elements for any given extension. As an example, I submit the Download Manager Tweak. Great extension, but it produces the only sidebar in Firefox without a keybinding to close it. It forces the user to hit a tiny button somewhere in the left third of the window.
Basically, I submit that part of any extensibility framework within geany needs to tightly control who puts what buttons where. I'm partial to what I said earlier: add menu entries as needed. Extensions with more than one menu entry need to cascade them tro avoid cluttering the main menu windows. Each menu entry must have a keybinding -- even if it defaults to nothing, it should let the user change it. As for toolbar modifications, I think they should be restricted to an "extensions" toolbar; that way installing a third-party extension or script doesn't disrupt or destroy standard toolbar buttons.
Geany is a great program. I'm keenly interested in helping it stay that way. :)
Kurt _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Well, I should probably restrain my "extensibility excitation" too since, as Kurt reminded me, the idea is still hypotethical. It is just that this is, for me, "The Next Best Thing" for Geany to have after the Project Management arrives :)
Cheers, Alexandre Moreira.
On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" alexandream@gmail.com wrote:
Hey guys,
it is so cool, that you all want to extend Geany, but please give us a little bit time to make it ready for this.
scripts in, say, Python or TCL (or even C plugins).
I prefer Python(because so many people like it, there must be something magic with it) _and_ C plugins.
But as mentioned earlier, this whole stuff is not really important at the moment, at least not for me and Nick. I want to finish the 0.8 release soon(but without hurrying), then reduce the length of the todo list and finally implement project management. Then getting it stable, so that 1.0 can be released.
After that, or while getting 1.0 stable, we should think about a reasonable plugin concept.
I really like the idea of plugins, but at the moment it is too early for it.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.key
On Thu, 2006-07-20 at 19:45 +0200, Enrico Tröger wrote:
On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" alexandream@gmail.com wrote:
it is so cool, that you all want to extend Geany, but please give us a little bit time to make it ready for this.
scripts in, say, Python or TCL (or even C plugins).
I prefer Python(because so many people like it, there must be something magic with it) _and_ C plugins.
But as mentioned earlier, this whole stuff is not really important at the moment, at least not for me and Nick. I want to finish the 0.8 release soon(but without hurrying), then reduce the length of the todo list and finally implement project management. Then getting it stable, so that 1.0 can be released.
After that, or while getting 1.0 stable, we should think about a reasonable plugin concept.
I really like the idea of plugins, but at the moment it is too early for it.
Thanks for the answers and responses. I'm looking forward to test the project management functionality.
Personally i think you guys should consider including the mentioned plug-in system with 1.0 release (after everything else on the TODO list is done) so it is a basic part of Geany. Also consider D-Bus as a plug-ins interface as this allows more languages to be used to write plug-ins with (any language that D-Bus got bindings for).
As far for the magic about Python: because it's really simple to code with as well being mature.
2006/7/20, Nexu nexu.jin@gmail.com:
On Thu, 2006-07-20 at 19:45 +0200, Enrico Tröger wrote:
On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" alexandream@gmail.com wrote:
it is so cool, that you all want to extend Geany, but please give us a little bit time to make it ready for this.
scripts in, say, Python or TCL (or even C plugins).
I prefer Python(because so many people like it, there must be something magic with it) _and_ C plugins.
But as mentioned earlier, this whole stuff is not really important at the moment, at least not for me and Nick. I want to finish the 0.8 release soon(but without hurrying), then reduce the length of the todo list and finally implement project management. Then getting it stable, so that 1.0 can be released.
After that, or while getting 1.0 stable, we should think about a reasonable plugin concept.
I really like the idea of plugins, but at the moment it is too early for it.
Thanks for the answers and responses. I'm looking forward to test the project management functionality.
Personally i think you guys should consider including the mentioned plug-in system with 1.0 release (after everything else on the TODO list is done) so it is a basic part of Geany.
I would vote against this. Geany already has a release plan, and I think we should stick to it. First of all, it was not the interest of the main devs to make it a complex system, at least not on 1.0. Second, it would be needed a *LOT* of hooks in the system for it to be acessible for plugins, and it is not the kind of re-engeneering I think we need while on 0.8, at least not when focusing to 1.0.
Also consider D-Bus as a
plug-ins interface as this allows more languages to be used to write plug-ins with (any language that D-Bus got bindings for).
I never considered this as an option and then, when you mentioned it a whole lot of possibilities exploded in my mind. Thanks very much, Nexu, for you made me address a lot of stuff I had in mind for my own personal project (A game server).
As far for the magic about Python: because it's really simple to code
with as well being mature.
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Cheers, Alexandre Moreira.
Oh, I forgot a few things too:
2006/7/20, Alexandre Moreira alexandream@gmail.com:
2006/7/20, Nexu nexu.jin@gmail.com:
On Thu, 2006-07-20 at 19:45 +0200, Enrico Tröger wrote:
On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" alexandream@gmail.com wrote:
it is so cool, that you all want to extend Geany, but please give us a little bit time to make it ready for this.
scripts in, say, Python or TCL (or even C plugins).
I prefer Python(because so many people like it, there must be something magic with it) _and_ C plugins.
But as mentioned earlier, this whole stuff is not really important at the moment, at least not for me and Nick. I want to finish the 0.8 release soon(but without hurrying), then reduce the length of the todo list and finally implement project management. Then getting it stable, so that 1.0 can be released.
After that, or while getting 1.0 stable, we should think about a reasonable plugin concept.
I really like the idea of plugins, but at the moment it is too early for it.
Thanks for the answers and responses. I'm looking forward to test the project management functionality.
Personally i think you guys should consider including the mentioned plug-in system with 1.0 release (after everything else on the TODO list is done) so it is a basic part of Geany.
I would vote against this. Geany already has a release plan, and I think we should stick to it. First of all, it was not the interest of the main devs to make it a complex system, at least not on 1.0. Second, it would be needed a *LOT* of hooks in the system for it to be acessible for plugins, and it is not the kind of re-engeneering I think we need while on 0.8, at least not when focusing to 1.0.
Also consider D-Bus as a
plug-ins interface as this allows more languages to be used to write plug-ins with (any language that D-Bus got bindings for).
I never considered this as an option and then, when you mentioned it a whole lot of possibilities exploded in my mind. Thanks very much, Nexu, for you made me address a lot of stuff I had in mind for my own personal project (A game server).
I ended up thanking Nexu for something but forgot to discuss the meaning of this idea in Geany context. Don't think D-Bus would be a good way for Geany to implement it, at least not as long as it strives to be multi-platform. For all I know D-Bus is still very much binded to the Linux platform (but, please, correct me if I am wrong).
As far for the magic about Python: because it's really simple to code
with as well being mature.
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Cheers, Alexandre Moreira.
2006/7/20, Alexandre Moreira alexandream@gmail.com:
Oh, I forgot a few things too:
2006/7/20, Alexandre Moreira alexandream@gmail.com:
2006/7/20, Nexu nexu.jin@gmail.com:
On Thu, 2006-07-20 at 19:45 +0200, Enrico Tröger wrote:
On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" < alexandream@gmail.com> wrote:
it is so cool, that you all want to extend Geany, but please give us
a
little bit time to make it ready for this.
scripts in, say, Python or TCL (or even C plugins).
I prefer Python(because so many people like it, there must be something magic with it) _and_ C plugins.
But as mentioned earlier, this whole stuff is not really important
at
the moment, at least not for me and Nick. I want to finish the 0.8 release soon(but without hurrying), then reduce the length of the todo list and finally implement project management. Then getting it stable, so that 1.0 can be released.
After that, or while getting 1.0 stable, we should think about a reasonable plugin concept.
I really like the idea of plugins, but at the moment it is too early for it.
Thanks for the answers and responses. I'm looking forward to test the project management functionality.
Personally i think you guys should consider including the mentioned plug-in system with 1.0 release (after everything else on the TODO list is done) so it is a basic part of Geany.
I would vote against this. Geany already has a release plan, and I think we should stick to it. First of all, it was not the interest of the main devs to make it a complex system, at least not on 1.0. Second, it would be needed a *LOT* of hooks in the system for it to be acessible for plugins, and it is not the kind of re-engeneering I think we need while on 0.8, at least not when focusing to 1.0.
Also consider D-Bus as a
plug-ins interface as this allows more languages to be used to write plug-ins with (any language that D-Bus got bindings for).
I never considered this as an option and then, when you mentioned it a whole lot of possibilities exploded in my mind. Thanks very much, Nexu, for you made me address a lot of stuff I had in mind for my own personal project (A game server).
I ended up thanking Nexu for something but forgot to discuss the meaning of this idea in Geany context. Don't think D-Bus would be a good way for Geany to implement it, at least not as long as it strives to be multi-platform. For all I know D-Bus is still very much binded to the Linux platform (but, please, correct me if I am wrong).
And here I am again (sorry, if I were less anxious to answer I would post a single message). I found out that DBus has implementations in FreeBSD/NetBSD/MacOSx/Windows, although I don't know the state of them all, so I was speaking nonsense in the last e-mail.
But again, I really believe we should drop this kind of discussion until we get on planning the plugin system (and that would be post 1.0, probably one major version after it).
As far for the magic about Python: because it's really simple to code
with as well being mature.
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Cheers, Alexandre Moreira.
Regards, Alexandre Moreira
On Thu, 2006-07-20 at 15:53 -0300, Alexandre Moreira wrote:
2006/7/20, Alexandre Moreira alexandream@gmail.com: Oh, I forgot a few things too:
2006/7/20, Alexandre Moreira <alexandream@gmail.com>: 2006/7/20, Nexu <nexu.jin@gmail.com>: On Thu, 2006-07-20 at 19:45 +0200, Enrico Tröger wrote: > On Thu, 20 Jul 2006 13:51:11 -0300, "Alexandre Moreira" > <alexandream@gmail.com> wrote: > > it is so cool, that you all want to extend Geany, but please give us a > little bit time to make it ready for this. > > > scripts in, say, Python or TCL (or even C plugins). > I prefer Python(because so many people like it, there must be > something magic with it) _and_ C plugins. > > But as mentioned earlier, this whole stuff is not really important at > the moment, at least not for me and Nick. > I want to finish the 0.8 release soon(but without hurrying), then > reduce the length of the todo list and finally implement project > management. Then getting it stable, so that 1.0 can be released. > > After that, or while getting 1.0 stable, we should think about a > reasonable plugin concept. > > I really like the idea of plugins, but at the moment it is too early > for it. Thanks for the answers and responses. I'm looking forward to test the project management functionality. Personally i think you guys should consider including the mentioned plug-in system with 1.0 release (after everything else on the TODO list is done) so it is a basic part of Geany. I would vote against this. Geany already has a release plan, and I think we should stick to it. First of all, it was not the interest of the main devs to make it a complex system, at least not on 1.0. Second, it would be needed a *LOT* of hooks in the system for it to be acessible for plugins, and it is not the kind of re-engeneering I think we need while on 0.8, at least not when focusing to 1.0. Also consider D-Bus as a plug-ins interface as this allows more languages to be used to write plug-ins with (any language that D-Bus got bindings for). I never considered this as an option and then, when you mentioned it a whole lot of possibilities exploded in my mind. Thanks very much, Nexu, for you made me address a lot of stuff I had in mind for my own personal project (A game server). I ended up thanking Nexu for something but forgot to discuss the meaning of this idea in Geany context. Don't think D-Bus would be a good way for Geany to implement it, at least not as long as it strives to be multi-platform. For all I know D-Bus is still very much binded to the Linux platform (but, please, correct me if I am wrong).And here I am again (sorry, if I were less anxious to answer I would post a single message). I found out that DBus has implementations in FreeBSD/NetBSD/MacOSx/Windows, although I don't know the state of them all, so I was speaking nonsense in the last e-mail.
But again, I really believe we should drop this kind of discussion until we get on planning the plugin system (and that would be post 1.0, probably one major version after it).
Just some additional info about D-Bus status for Alexandre: D-Bus 0.90 was just released this week. With that, they have also announced API freeze. They're working hard on win32 port from what i can tell on their ML. Someone has also announced on their ML about XPCOM bindings for D-Bus and than there are is work in progress on the PHP bindings.. From IRC, i notice lots of development on the Java bindings. (It's btw "D-Bus" according to the developers and not "DBus")
But for now i can live without a plug-in system. It's not a vital requirement.
PS, what is that game server project you mentioned Alexandre?