Hi All,
Recently there have been a number of proposals for significant changes in Geany, different languages, GObjectification and other various changes.
As good or bad as the individual suggestions may be, they have made it clear to me that there is no plan for the future of Geany that allows them to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany should be headed.
To start the ball rolling, here are some of the things I see Geany should aspire to:
1. An architecture that allows multi-threading to be used for non-GUI tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
2. Language specific assistance, such as indentation, or dynamic error marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
3. Proper portability. At the moment Geany is really a Linux application that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
4. Multiple top level windows. As monitors are cheaper, being able to spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I would suggest the process to be:
1. gather other major ideas for capabilities that Geany should plan to support 2. develop a design that supports these (or at least the most useful ones) 3. look at how that design can be implemented, can the existing design be mutated to it, or is it a clean framework that large parts of the existing functionality can plug into, or is it a whole clean implementation. This also includes issues like languages to use (C, C++, Vala, Haskell etc). 4. depending on the outcome from 3. use a new repository organisation or at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
This is something very different to the way Geany is currently operating, and I don't know if the community wants to consider such a more structured approach. If its felt that its worthwhile then I suggest that steps one and two are best achieved using the wiki and I will volunteer to set up and maintain page(s) for those phases at least.
So to summarise, what capabilities should Geany aspire to support, and what is the process to develop the best software architecture to support those capabilities.
Cheers Lex
On 13-11-10 11:18 PM, Lex Trotman wrote:
Hi All,
Recently there have been a number of proposals for significant changes in Geany, different languages, GObjectification and other various changes.
As good or bad as the individual suggestions may be, they have made it clear to me that there is no plan for the future of Geany that allows them to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany should be headed.
To start the ball rolling, here are some of the things I see Geany should aspire to:
- An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since we don't have to contend with TM/CTags that uses global state like mad, and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something. This could include ability to disable or augment certain built-in filetype-specific stuff that can't easily be done currently.
- Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
I agree that's a good way to do it, like Chrome, Firefox, LibreOffice, etc. to have own wrapper over various toolkits for internal use depending on the platform, but IMO, it's vastly too much work for Geany, and GTK+ isn't actually all that bad (despite their sometimes confounding API changes/deprecations).
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
- Multiple top level windows. As monitors are cheaper, being able to
spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
As with with my comment in #3, if the application was structured as the GUI toolkit is designed to be used, using some of the more modern GTK+ APIs, this is ridiculously easy, especially when used with the #5 I'm going to add:
5. Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons that come to mind, in no particular order:
* Scintilla is a big fat not-really-GTK+ C++ library * We have to keep a fork up-to-date in our source tree * It provides one of worst APIs known to man, and causes us to have all kinds of wrappers to make the API normal and to have our code still littered with unsafe SSM() calls that make the code really weird. * Limited functionality to support plugins participating in the buffer/view; for example there's only a really small number of indicators, markers, pixmaps, etc. It's not really built with arbitrary extension (ex. by plugins) in mind. * It makes simple things like MVC hard to do with the way its user API is so view-centric. * While it supports background loading, it doesn't support background/async lexing, and so completely blocks the UI for huge documents. * Writing lexers is beyond complicated. Having to write C++ code to add/customize syntax highlighting is insane from a user POV. * Has no builtin support for colour schemes making us have to have a whole, kind of confusing, configuration file system to provide it ourselves. * Reduce Geany's binary size since the editor component would be linked dynamically, and not statically like Scintilla is. I don't know if this actually matters but I think Scintilla with all the lexers and stuff I think it can end up as several MB in the binary. * As with above, and the one about updating the fork; using a dynamically linked version allows the system admin to upgrade their libraries and they'll automatically be used by Geany. * Drop dependency on a C++ compiler. This isn't a big deal really. And of course replace with a new dependency on gtksourceview library. * GtkSourceView provides convenient features like SourceCompletion and SourceMarks and such that would make doing stuff from plugins quite straightforward. * GtkSourceView completely integrates into our GUI toolkit, using native (not custom drawn like Scintilla) widgets inside and interacts properly with stuff like scrolling, focus, DnD, key-bindings, etc. * If we ever do use GObject stuff more and/or make the plugin API automatically bindable with GObject-Introspection, GtkSourceView already provides the .gir stuff needed. * I think GtkSourceView is installed by default usually with at least GNOME and XFCE (via Gedit and Mousepad using it and being the "default" text editors).
And I since we're mentioning huge changes :) ...
6. Automatically-bindable plugin API that we officially support for multiple languages. Writing plugins in C is crap, IMO. Writing a GeanyPy or GeanyLua plugin is kind of crap, because they depend on other plugins, and you can't make a "real" first-class plugin with them. LibPeas and Gobject-Introspection are the obvious possibility here, but would require to "GObjectify" the code pretty much.
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I would suggest the process to be:
- gather other major ideas for capabilities that Geany should plan to
support
I just plopped #5 and #6 on to the list, wherever it ends up :)
- develop a design that supports these (or at least the most useful ones)
- look at how that design can be implemented, can the existing design be
mutated to it, or is it a clean framework that large parts of the existing functionality can plug into, or is it a whole clean implementation. This also includes issues like languages to use (C, C++, Vala, Haskell etc). 4. depending on the outcome from 3. use a new repository organisation or at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
Yeah, some are quite huge changes, we couldn't be tip-toeing around trying not to touch too many lines of code or breaking config file or plugin APIs and stuff in the main branch as usual :) I think a separate branch on the main repository, as mentioned, would make the most sense.
This is something very different to the way Geany is currently operating, and I don't know if the community wants to consider such a more structured approach. If its felt that its worthwhile then I suggest that steps one and two are best achieved using the wiki and I will volunteer to set up and maintain page(s) for those phases at least.
So to summarise, what capabilities should Geany aspire to support, and what is the process to develop the best software architecture to support those capabilities.
I'm in/+1, if in doing so we fully adopt GObject/GTK+ and the normal/common/modern ways to do stuff using them. I'm not really interested to turn Geany into a non-GTK+ app or maintain separate backends or continue using painful old non-GObject C stuff, always having to avoid a lot of good APIs just for the sake of old supported build platforms and library versions. I'm willing to volunteer a considerable amount of time to helping out with it in the above case, and at least see where it goes, otherwise I'll just be a good tester of the re-design/branch :)
Cheers, Matthew Brush
On 11 November 2013 20:31, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-10 11:18 PM, Lex Trotman wrote:
Hi All,
Recently there have been a number of proposals for significant changes in Geany, different languages, GObjectification and other various changes.
As good or bad as the individual suggestions may be, they have made it clear to me that there is no plan for the future of Geany that allows them to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany should be headed.
To start the ball rolling, here are some of the things I see Geany should aspire to:
- An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since we don't have to contend with TM/CTags that uses global state like mad, and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
Yes, it should be added to the list, even though it only occurs once.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something. This could include ability to disable or augment certain built-in filetype-specific stuff that can't easily be done currently.
Yes, augmenting the plugin interface to support extra functionality is one way to do it.
- Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
I agree that's a good way to do it, like Chrome, Firefox, LibreOffice, etc. to have own wrapper over various toolkits for internal use depending on the platform, but IMO, it's vastly too much work for Geany, and GTK+ isn't actually all that bad (despite their sometimes confounding API changes/deprecations).
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
Yes, restricting Geany is also one of the possible solutions to put on the list too.
- Multiple top level windows. As monitors are cheaper, being able to
spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
As with with my comment in #3, if the application was structured as the GUI toolkit is designed to be used, using some of the more modern GTK+ APIs, this is ridiculously easy, especially when used with the #5 I'm going to add:
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
- Scintilla is a big fat not-really-GTK+ C++ library
- We have to keep a fork up-to-date in our source tree
- It provides one of worst APIs known to man, and causes us to have all
kinds of wrappers to make the API normal and to have our code still littered with unsafe SSM() calls that make the code really weird.
- Limited functionality to support plugins participating in the
buffer/view; for example there's only a really small number of indicators, markers, pixmaps, etc. It's not really built with arbitrary extension (ex. by plugins) in mind.
- It makes simple things like MVC hard to do with the way its user API is
so view-centric.
- While it supports background loading, it doesn't support
background/async lexing, and so completely blocks the UI for huge documents.
- Writing lexers is beyond complicated. Having to write C++ code to
add/customize syntax highlighting is insane from a user POV.
- Has no builtin support for colour schemes making us have to have a
whole, kind of confusing, configuration file system to provide it ourselves.
- Reduce Geany's binary size since the editor component would be linked
dynamically, and not statically like Scintilla is. I don't know if this actually matters but I think Scintilla with all the lexers and stuff I think it can end up as several MB in the binary.
- As with above, and the one about updating the fork; using a dynamically
linked version allows the system admin to upgrade their libraries and they'll automatically be used by Geany.
- Drop dependency on a C++ compiler. This isn't a big deal really. And of
course replace with a new dependency on gtksourceview library.
- GtkSourceView provides convenient features like SourceCompletion and
SourceMarks and such that would make doing stuff from plugins quite straightforward.
- GtkSourceView completely integrates into our GUI toolkit, using native
(not custom drawn like Scintilla) widgets inside and interacts properly with stuff like scrolling, focus, DnD, key-bindings, etc.
- If we ever do use GObject stuff more and/or make the plugin API
automatically bindable with GObject-Introspection, GtkSourceView already provides the .gir stuff needed.
- I think GtkSourceView is installed by default usually with at least
GNOME and XFCE (via Gedit and Mousepad using it and being the "default" text editors).
Yes, all suitable libraries should be examined and the implications that has on the rest of the design considered.
And I since we're mentioning huge changes :) ...
- Automatically-bindable plugin API that we officially support for
multiple languages. Writing plugins in C is crap, IMO. Writing a GeanyPy or GeanyLua plugin is kind of crap, because they depend on other plugins, and you can't make a "real" first-class plugin with them. LibPeas and Gobject-Introspection are the obvious possibility here, but would require to "GObjectify" the code pretty much.
Yes you are right, the plugin interface design should be examined as part of the process.
These are all big changes that don't fall into the current Geany mode of
"light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I would suggest the process to be:
- gather other major ideas for capabilities that Geany should plan to
support
I just plopped #5 and #6 on to the list, wherever it ends up :)
Yes, thats the idea, the more ideas the better :).
- develop a design that supports these (or at least the most useful ones)
- look at how that design can be implemented, can the existing design be
mutated to it, or is it a clean framework that large parts of the existing functionality can plug into, or is it a whole clean implementation. This also includes issues like languages to use (C, C++, Vala, Haskell etc). 4. depending on the outcome from 3. use a new repository organisation or at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
Yeah, some are quite huge changes, we couldn't be tip-toeing around trying not to touch too many lines of code or breaking config file or plugin APIs and stuff in the main branch as usual :) I think a separate branch on the main repository, as mentioned, would make the most sense.
Yes, at the very least a long term branch.
This is something very different to the way Geany is currently operating,
and I don't know if the community wants to consider such a more structured approach. If its felt that its worthwhile then I suggest that steps one and two are best achieved using the wiki and I will volunteer to set up and maintain page(s) for those phases at least.
So to summarise, what capabilities should Geany aspire to support, and what is the process to develop the best software architecture to support those capabilities.
I'm in/+1, if in doing so we fully adopt GObject/GTK+ and the normal/common/modern ways to do stuff using them. I'm not really interested to turn Geany into a non-GTK+ app or maintain separate backends or continue using painful old non-GObject C stuff, always having to avoid a lot of good APIs just for the sake of old supported build platforms and library versions. I'm willing to volunteer a considerable amount of time to helping out with it in the above case, and at least see where it goes, otherwise I'll just be a good tester of the re-design/branch :)
Yes, and I'll keep those comments to be input to the step 2./3. phase.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 11.11.2013 10:31, schrieb Matthew Brush:
- Drop Scintilla and use GtkSourceView. I'll just enumerate the
reasons that come to mind, in no particular order:
- Scintilla is a big fat not-really-GTK+ C++ library
- We have to keep a fork up-to-date in our source tree
- It provides one of worst APIs known to man, and causes us to have
all kinds of wrappers to make the API normal and to have our code still littered with unsafe SSM() calls that make the code really weird.
- Limited functionality to support plugins participating in the
buffer/view; for example there's only a really small number of indicators, markers, pixmaps, etc. It's not really built with arbitrary extension (ex. by plugins) in mind.
- It makes simple things like MVC hard to do with the way its user API
is so view-centric.
- While it supports background loading, it doesn't support
background/async lexing, and so completely blocks the UI for huge documents.
- Writing lexers is beyond complicated. Having to write C++ code to
add/customize syntax highlighting is insane from a user POV.
- Has no builtin support for colour schemes making us have to have a
whole, kind of confusing, configuration file system to provide it ourselves.
- Reduce Geany's binary size since the editor component would be
linked dynamically, and not statically like Scintilla is. I don't know if this actually matters but I think Scintilla with all the lexers and stuff I think it can end up as several MB in the binary.
- As with above, and the one about updating the fork; using a
dynamically linked version allows the system admin to upgrade their libraries and they'll automatically be used by Geany.
- Drop dependency on a C++ compiler. This isn't a big deal really. And
of course replace with a new dependency on gtksourceview library.
- GtkSourceView provides convenient features like SourceCompletion and
SourceMarks and such that would make doing stuff from plugins quite straightforward.
- GtkSourceView completely integrates into our GUI toolkit, using
native (not custom drawn like Scintilla) widgets inside and interacts properly with stuff like scrolling, focus, DnD, key-bindings, etc.
With ScintillaGTK it also interacts properly, doesn't it? It impements GtkWidget and can act as such.
- If we ever do use GObject stuff more and/or make the plugin API
automatically bindable with GObject-Introspection, GtkSourceView already provides the .gir stuff needed.
- I think GtkSourceView is installed by default usually with at least
GNOME and XFCE (via Gedit and Mousepad using it and being the "default" text editors).
All of these points read like whine. Some of them also apply to GtkSourceView (GSV) and you haven't shown how GSV improves things. I can read that you don't like Scintilla but how is GSV better and what do we gain? Perhaps you could summarize the nice things about GSV? Note that I have done nothing with it and therefore no idea how it works or what APIs it provides. But I also do not know why you would chose it over Scintilla or even convert an existing Scintilla-based project to it.
Best regards.
On 13-11-11 02:42 AM, Thomas Martitz wrote:
Am 11.11.2013 10:31, schrieb Matthew Brush:
[snip]
- GtkSourceView completely integrates into our GUI toolkit, using
native (not custom drawn like Scintilla) widgets inside and interacts properly with stuff like scrolling, focus, DnD, key-bindings, etc.
With ScintillaGTK it also interacts properly, doesn't it? It impements GtkWidget and can act as such.
Not really, I mean it is technically a subclass of GtkWidget, but it draws its own text instead of using GtkTextView, it uses its own scrollbars instead of using GtkScrollable/GtkScrolledWindow, it has problems with focus (see related functions in Geany's source), it hijacks keybindings completely outside of GTK+, it provides only a single crazy signal for every possible thing, it hasn't any GTK+ properties or style properties, it hasn't any methods/functions/API but a single weird mandatory function thing (scintilla_send_message) that requires to constantly be doing casts on its parameters since they try to accept every type through long/ulong, it doesn't use any G* types for anything (ex. enums, function parameters, colours, images, etc) and so on.
[snip]
All of these points read like whine. Some of them also apply to GtkSourceView (GSV) and you haven't shown how GSV improves things. I can read that you don't like Scintilla but how is GSV better and what do we gain? Perhaps you could summarize the nice things about GSV? Note that I have done nothing with it and therefore no idea how it works or what APIs it provides. But I also do not know why you would chose it over Scintilla or even convert an existing Scintilla-based project to it.
It's probably easier to list the things that are worse in GSV since there's only one point I can think of where Scintilla beats it hands-down:
* No code folding (promised since forever, not sure when it ever comes).
Anyway, it will be added to any list of big potential changes and we can discuss on the wiki or wherever this might eventually end up if it goes anywhere, I guess this isn't really the thread to be getting as detailed as I did or continue such detailed discussions (ping me on IRC if you want).
Cheers, Matthew Brush
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
But does this mean that some Sci-features are going to pass away? E.g. scintilla supports multiple selections and, gap buffer, multiple gaps, inline styling (e.g. spellcheck, mark words) that I never seen in gedit/mousepad.
-- Best regards, Pavel Roschin aka RPG
One of the things I've enjoyed about switching from gedit to geany is that geany typically doesn't use nearly as much memory and loads large files easily. Now, I don't know if that's related to Scintilla vs GtkSourceView, but really long documents, particularly with long lines, freeze gedit up.
At first I was sceptical of using a Scintilla-based editor from my GtkSourceView, but geany has grown on me.
With any direction change, I would hope most of all that the basics I know and love about geany remain untouched:
1. Relatively easy to read source code. 2. Fast and light weight. Feature-rich without the bloat. 3. Plugins can do virtually anything. (I found gedit plugins to be a bit more difficult, especially since the editor was in a different language than the python plugins, although that could be more my inexperience with the languages at the time I started.) 4. Consistent behavior across languages, like a good power-editor. One concern about language specific code mentioned in this thread and other threads is if the editor will still handle things consistently. 5. Support for many languages. This is probably the main reason I don't use something like Eclipse, because switching editors for the various languages that I have to program in is annoying.
Anyway, whatever you decide, please don't take such a change in direction as to gnome things up for us.
That's my 2 cents, if they are worth anything since most of my contributions so far are still small.
Thanks,
Steve
On 11/11/2013 08:45 AM, Pavel Roschin wrote:
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
But does this mean that some Sci-features are going to pass away? E.g. scintilla supports multiple selections and, gap buffer, multiple gaps, inline styling (e.g. spellcheck, mark words) that I never seen in gedit/mousepad.
-- Best regards, Pavel Roschin aka RPG _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12 November 2013 03:51, Steven Blatnick steve8track@yahoo.com wrote:
One of the things I've enjoyed about switching from gedit to geany is that geany typically doesn't use nearly as much memory and loads large files easily. Now, I don't know if that's related to Scintilla vs GtkSourceView, but really long documents, particularly with long lines, freeze gedit up.
At first I was sceptical of using a Scintilla-based editor from my GtkSourceView, but geany has grown on me.
With any direction change, I would hope most of all that the basics I know and love about geany remain untouched:
- Relatively easy to read source code.
- Fast and light weight. Feature-rich without the bloat.
- Plugins can do virtually anything. (I found gedit plugins to be a
bit more difficult, especially since the editor was in a different language than the python plugins, although that could be more my inexperience with the languages at the time I started.) 4. Consistent behavior across languages, like a good power-editor. One concern about language specific code mentioned in this thread and other threads is if the editor will still handle things consistently. 5. Support for many languages. This is probably the main reason I don't use something like Eclipse, because switching editors for the various languages that I have to program in is annoying.
Anyway, whatever you decide, please don't take such a change in direction as to gnome things up for us.
That's my 2 cents, if they are worth anything since most of my contributions so far are still small.
Hi Steve,
Thanks for that, it is definitely worth while re-iterating the basic tenets of "the Geany way" that make up a large part of the value it provides to its users. If any design decisions threaten these, then they need to provide a commensurate benefit or be rejected.
Cheers Lex
Thanks,
Steve
On 11/11/2013 08:45 AM, Pavel Roschin wrote:
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
But does this mean that some Sci-features are going to pass away? E.g. scintilla supports multiple selections and, gap buffer, multiple gaps, inline styling (e.g. spellcheck, mark words) that I never seen in gedit/mousepad.
-- Best regards, Pavel Roschin aka RPG _______________________________________________ Devel mailing listDevel@lists.geany.orghttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12 November 2013 02:45, Pavel Roschin roshin@scriptumplus.ru wrote:
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
But does this mean that some Sci-features are going to pass away? E.g. scintilla supports multiple selections and, gap buffer, multiple gaps, inline styling (e.g. spellcheck, mark words) that I never seen in gedit/mousepad.
Hi Pavel,
My intention in starting this thread was to try to get some overall design going for the purposes of *adding* big features that would be hard to do now, I assumed that retaining all existing Geany features was a given. So unless somebody can show that an existing feature is **really** unused then any design we reach needs to end up being able to support the same features, though maybe not implemented in the same way.
If the editing widget is changed the same capabilities need to be possible, though maybe not implemented in the same way. The cost of re-implementing anything would be factored against whatever benefits a new widget might bring.
Cheers Lex
-- Best regards, Pavel Roschin aka RPG _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 11.11.2013 10:31, schrieb Matthew Brush:
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
As mentioned in another mail already, we got a lot of users requesting to still support Gtk2 as they don't want to change to some Gtk3-based desktop. These users will decrease with time for sure and once Xfce 4.12 is ready for Gtk3 hopefully will disappear, but currently it looks a bit like this will be happen when GNU/Hurd final is released. Until this eternity, we need to find a way for users not using Gtk3 in favor of Gtk2 -- even I know it's a pain in the back.
Cheers, Frank
On 13-11-12 09:47 AM, Frank Lanitz wrote:
Am 11.11.2013 10:31, schrieb Matthew Brush:
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
As mentioned in another mail already, we got a lot of users requesting to still support Gtk2 as they don't want to change to some Gtk3-based desktop. These users will decrease with time for sure and once Xfce 4.12 is ready for Gtk3 hopefully will disappear, but currently it looks a bit like this will be happen when GNU/Hurd final is released. Until this eternity, we need to find a way for users not using Gtk3 in favor of Gtk2 -- even I know it's a pain in the back.
It would be a less painful if we could at least use the current/last supported GTK+2 version at least (2.24-ish). Supporting back some half a decade of GTK+2 versions when already the most recent version is deprecated/dead and shouldn't really be used for any new code is kind of crazy.
I'm curious if you asked the users complaining about not wanting to "switch to a Gtk3-based desktop" whether they actually have libgtk3 installed anyway? For example I use XFCE 4.10, which isn't technically a Gtk3-based desktop environment, and I'm happily using Gtk2 and 3 apps side-by-side without any issues. Is it possible the users were just expressing more GNOME-hate and directing it GTK3 instead or you think they really are using super old desktop environments before Gtk3 started being widely distributed?
Cheers, Matthew Brush
I'm being a bit off topic, but one problem I have with having both Gtk2 and Gtk3 apps is that there have been settings and theme discrepancies. For example, I use Linux Mint MATE, and there have been some problems with bookmarks being in sync between the file open dialog in Gtk2 apps vs Gtk3 apps. Plus, if I don't use a theme that is available in both versions of Gtk, then I end up with foreign looking apps in my environment, almost like I'm port forwarding X and getting things theme-less. Even geany hasn't been flawless in this Gnome Civil War, with the default external file browser being nautilus, where my system uses the nearly identical caja, although I changed the setting in geany of course.
On 11/12/2013 03:23 PM, Matthew Brush wrote:
On 13-11-12 09:47 AM, Frank Lanitz wrote:
Am 11.11.2013 10:31, schrieb Matthew Brush:
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
As mentioned in another mail already, we got a lot of users requesting to still support Gtk2 as they don't want to change to some Gtk3-based desktop. These users will decrease with time for sure and once Xfce 4.12 is ready for Gtk3 hopefully will disappear, but currently it looks a bit like this will be happen when GNU/Hurd final is released. Until this eternity, we need to find a way for users not using Gtk3 in favor of Gtk2 -- even I know it's a pain in the back.
It would be a less painful if we could at least use the current/last supported GTK+2 version at least (2.24-ish). Supporting back some half a decade of GTK+2 versions when already the most recent version is deprecated/dead and shouldn't really be used for any new code is kind of crazy.
I'm curious if you asked the users complaining about not wanting to "switch to a Gtk3-based desktop" whether they actually have libgtk3 installed anyway? For example I use XFCE 4.10, which isn't technically a Gtk3-based desktop environment, and I'm happily using Gtk2 and 3 apps side-by-side without any issues. Is it possible the users were just expressing more GNOME-hate and directing it GTK3 instead or you think they really are using super old desktop environments before Gtk3 started being widely distributed?
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13 November 2013 10:06, Steven Blatnick steve8track@yahoo.com wrote:
I'm being a bit off topic, but one problem I have with having both Gtk2 and Gtk3 apps is that there have been settings and theme discrepancies. For example, I use Linux Mint MATE, and there have been some problems with bookmarks being in sync between the file open dialog in Gtk2 apps vs Gtk3 apps. Plus, if I don't use a theme that is available in both versions of Gtk, then I end up with foreign looking apps in my environment, almost like I'm port forwarding X and getting things theme-less. Even geany hasn't been flawless in this Gnome Civil War, with the default external file browser being nautilus, where my system uses the nearly identical caja, although I changed the setting in geany of course.
Hi Steven,
This might be a MATE issue, I run both GTK2 and GTK3 in Mint Cinnamon and havn't seen theme issues. (default Mint theme, I'm too lazy to change it :) If by bookmarks you mean "recently used" then it definitely updates from both, but how accurately and how regularly I havn't examined in detail.
Cheers Lex
My bad. It appears the bookmark discrepancy isn't between versions, but between caja and the file open dialog:
As for themes, try installing pluma and gedit and opening them. Usually for me, if you haven't changed themes yet, you get very different looking UI themes, but maybe they have fixed this in later versions of Mint.
Thanks,
Steve
On 11/12/2013 04:15 PM, Lex Trotman wrote:
On 13 November 2013 10:06, Steven Blatnick <steve8track@yahoo.com mailto:steve8track@yahoo.com> wrote:
I'm being a bit off topic, but one problem I have with having both Gtk2 and Gtk3 apps is that there have been settings and theme discrepancies. For example, I use Linux Mint MATE, and there have been some problems with bookmarks being in sync between the file open dialog in Gtk2 apps vs Gtk3 apps. Plus, if I don't use a theme that is available in both versions of Gtk, then I end up with foreign looking apps in my environment, almost like I'm port forwarding X and getting things theme-less. Even geany hasn't been flawless in this Gnome Civil War, with the default external file browser being nautilus, where my system uses the nearly identical caja, although I changed the setting in geany of course.Hi Steven,
This might be a MATE issue, I run both GTK2 and GTK3 in Mint Cinnamon and havn't seen theme issues. (default Mint theme, I'm too lazy to change it :) If by bookmarks you mean "recently used" then it definitely updates from both, but how accurately and how regularly I havn't examined in detail.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13 November 2013 10:24, Steven Blatnick steve8track@yahoo.com wrote:
My bad. It appears the bookmark discrepancy isn't between versions, but between caja and the file open dialog:
Thats something inside GTK2/3 that provide the open dialog, nothing we can control AFAIK.
[...]
As for themes, try installing pluma and gedit and opening them. Usually for me, if you haven't changed themes yet, you get very different looking UI themes, but maybe they have fixed this in later versions of Mint.
Well MATE is a fork of Gnome2, so it may have trouble setting themes for GTK3 apps since AFAIK its still written in GTK2. Cinnamon is a fork of Gnome3 so it knows about both GTK2 and GTK3.
Cheers Lex
PS I should have said "run both GTK2 and GTK3 versions of Geany"
Am 13.11.2013 00:15, schrieb Lex Trotman:
This might be a MATE issue, I run both GTK2 and GTK3 in Mint Cinnamon and havn't seen theme issues. (default Mint theme, I'm too lazy to change it :) If by bookmarks you mean "recently used" then it definitely updates from both, but how accurately and how regularly I havn't examined in detail.
For Xfce dusk I can report the same as Steven does. Gtk3 applications running out of the box with some grayish stile. I put a screenshot to [1] to show what I mean.
Cheers, Frank
On 13-11-12 03:06 PM, Steven Blatnick wrote:
I'm being a bit off topic, but one problem I have with having both Gtk2 and Gtk3 apps is that there have been settings and theme discrepancies. For example, I use Linux Mint MATE, and there have been some problems with bookmarks being in sync between the file open dialog in Gtk2 apps vs Gtk3 apps. Plus, if I don't use a theme that is available in both versions of Gtk, then I end up with foreign looking apps in my environment, almost like I'm port forwarding X and getting things theme-less. Even geany hasn't been flawless in this Gnome Civil War, with the default external file browser being nautilus, where my system uses the nearly identical caja, although I changed the setting in geany of course.
Fair enough, but none of this is Geany's problem, it's more like your distro isn't well-configured and the GTK+ team did a crap job maintaining overall compatibility between major releases even at the user level.
Unless we're going to switch toolkits or someone is volunteering to maintain a fork, there's really no logical reason to avoid the inevitable, scratching and clawing at the past hoping some generous RedHat developers are going to forever maintain dead versions, or they'll change their minds and revert back to good old days or something.
Cheers, Matthew Brush
On 11/12/2013 03:23 PM, Matthew Brush wrote:
On 13-11-12 09:47 AM, Frank Lanitz wrote:
Am 11.11.2013 10:31, schrieb Matthew Brush:
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
As mentioned in another mail already, we got a lot of users requesting to still support Gtk2 as they don't want to change to some Gtk3-based desktop. These users will decrease with time for sure and once Xfce 4.12 is ready for Gtk3 hopefully will disappear, but currently it looks a bit like this will be happen when GNU/Hurd final is released. Until this eternity, we need to find a way for users not using Gtk3 in favor of Gtk2 -- even I know it's a pain in the back.
It would be a less painful if we could at least use the current/last supported GTK+2 version at least (2.24-ish). Supporting back some half a decade of GTK+2 versions when already the most recent version is deprecated/dead and shouldn't really be used for any new code is kind of crazy.
I'm curious if you asked the users complaining about not wanting to "switch to a Gtk3-based desktop" whether they actually have libgtk3 installed anyway? For example I use XFCE 4.10, which isn't technically a Gtk3-based desktop environment, and I'm happily using Gtk2 and 3 apps side-by-side without any issues. Is it possible the users were just expressing more GNOME-hate and directing it GTK3 instead or you think they really are using super old desktop environments before Gtk3 started being widely distributed?
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
בתאריך ד', נוב 13, 2013 בשעה 1:27 AM, Matthew Brush mbrush@codebrainz.ca כתב:
On 13-11-12 03:06 PM, Steven Blatnick wrote:
I'm being a bit off topic, but one problem I have with having both Gtk2 and Gtk3 apps is that there have been settings and theme discrepancies. For example, I use Linux Mint MATE, and there have been some problems with bookmarks being in sync between the file open dialog in Gtk2 apps vs Gtk3 apps. Plus, if I don't use a theme that is available in both versions of Gtk, then I end up with foreign looking apps in my environment, almost like I'm port forwarding X and getting things theme-less. Even geany hasn't been flawless in this Gnome Civil War, with the default external file browser being nautilus, where my system uses the nearly identical caja, although I changed the setting in geany of course.
Fair enough, but none of this is Geany's problem, it's more like your distro isn't well-configured and the GTK+ team did a crap job maintaining overall compatibility between major releases even at the user level.
Unless we're going to switch toolkits or someone is volunteering to maintain a fork, there's really no logical reason to avoid the inevitable, scratching and clawing at the past hoping some generous RedHat developers are going to forever maintain dead versions, or they'll change their minds and revert back to good old days or something.
Why to switch to other toolkits?! I not understand what don't good in GTK+.
And also - why to keep GTK+ 2? GTK+ 3 avilable in all distro, also in older distro, it also work in Windows and also in Mac. this because GTK+ 3 released before almost three years.
Cheers, Matthew Brush
On 11/12/2013 03:23 PM, Matthew Brush wrote:
On 13-11-12 09:47 AM, Frank Lanitz wrote:
Am 11.11.2013 10:31, schrieb Matthew Brush:
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
As mentioned in another mail already, we got a lot of users requesting to still support Gtk2 as they don't want to change to some Gtk3-based desktop. These users will decrease with time for sure and once Xfce 4.12 is ready for Gtk3 hopefully will disappear, but currently it looks a bit like this will be happen when GNU/Hurd final is released. Until this eternity, we need to find a way for users not using Gtk3 in favor of Gtk2 -- even I know it's a pain in the back.
It would be a less painful if we could at least use the current/last supported GTK+2 version at least (2.24-ish). Supporting back some half a decade of GTK+2 versions when already the most recent version is deprecated/dead and shouldn't really be used for any new code is kind of crazy.
I'm curious if you asked the users complaining about not wanting to "switch to a Gtk3-based desktop" whether they actually have libgtk3 installed anyway? For example I use XFCE 4.10, which isn't technically a Gtk3-based desktop environment, and I'm happily using Gtk2 and 3 apps side-by-side without any issues. Is it possible the users were just expressing more GNOME-hate and directing it GTK3 instead or you think they really are using super old desktop environments before Gtk3 started being widely distributed?
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Why to switch to other toolkits?! I not understand what don't good in GTK+.
And also - why to keep GTK+ 2? GTK+ 3 avilable in all distro, also in older distro, it also work in Windows and also in Mac. this because GTK+ 3 released before almost three years.
Because many distros are more than 3 years old and still supported. Geany
has users (and developers) in commercial and academic environments which will often be constrained to older (but still supported) versions of Red Hat, Scientific Linux, Suse etc.
Its fine for hobbyists to want to play with the latest, we only have one PC to change over, but institutions often have hundreds or thousands and have all sorts of specific software to ensure still works when they upgrade.
Cheers Lex
I not understand, you mean have some old version of some distro isn't support GTK+ 3 and them always with older version of all package - so why Geany need to be the last in them distro?
Geany need to go forward, and older distro will keep the old version of Geany same them keep the old version of GTK+ 2 and not support GTK+ 3 yet. Geany 1.24 and also Geany 0.21 it realy good software, but we can't to bog becausw have some older distor.
Regards, Yosef Or Boczko
בתאריך ד', נוב 13, 2013 בשעה 1:48 AM, Lex Trotman elextr@gmail.com כתב:
Why to switch to other toolkits?! I not understand what don't good in GTK+.
And also - why to keep GTK+ 2? GTK+ 3 avilable in all distro, also in older distro, it also work in Windows and also in Mac. this because GTK+ 3 released before almost three years.
Because many distros are more than 3 years old and still supported. Geany has users (and developers) in commercial and academic environments which will often be constrained to older (but still supported) versions of Red Hat, Scientific Linux, Suse etc.
Its fine for hobbyists to want to play with the latest, we only have one PC to change over, but institutions often have hundreds or thousands and have all sorts of specific software to ensure still works when they upgrade.
Cheers Lex
On 13 November 2013 10:53, Yosef Or Boczko yoseforb@gmail.com wrote:
I not understand, you mean have some old version of some distro isn't support GTK+ 3 and them always with older version of all package - so why Geany need to be the last in them distro?
Several reasons:
1. we don't have the resources to backport bug fixes to old versions, the only bug fix versions are the latest release of Geany.
2. The users on old distros have the same use-cases as those on new distros, so they need the new features as much as anyone else. Restricting the features available disenfranchises that group of users.
3. IIUC some of the Geany devs are in that situation, they clearly will not contribute to changes that they can't use.
Geany need to go forward, and older distro will keep the old version of Geany same them keep the old version of GTK+ 2 and not support GTK+ 3 yet. Geany 1.24 and also Geany 0.21 it realy good software, but we can't to bog becausw have some older distor.
Going forward is adding features that are useful to users, such as those suggestions being gathered in the "direction for Geany" thread.
Changing GUI toolkit versions is peripheral to that and should only happen if it assists in adding real features, because otherwise its just busy-work that stops real features being added. If changing GUI toolkit versions makes it significantly easier to do something useful then it may be a worthwhile change. The intention of the other thread is to look at the design to see if this is the case.
Cheers Lex
[...]
On 13-11-12 04:23 PM, Lex Trotman wrote:
On 13 November 2013 10:53, Yosef Or Boczko yoseforb@gmail.com wrote:
I not understand, you mean have some old version of some distro isn't support GTK+ 3 and them always with older version of all package - so why Geany need to be the last in them distro?
Several reasons:
- we don't have the resources to backport bug fixes to old versions, the
only bug fix versions are the latest release of Geany.
Their sysadmins and distro vendors are supposed to take care of that aren't they? And anyway, most users wouldn't even be able to get a newer Geany installed from source on such a restricted system.
- The users on old distros have the same use-cases as those on new
distros, so they need the new features as much as anyone else. Restricting the features available disenfranchises that group of users.
Older versions of Geany are still really good, and supported by their sysadmins and distro vendors, and it's not like major huge changes have happened since say 0.18 or something. What's more, it's not like it's actually Geany disenfranchising them, it's almost every single FOSS program that exists and even more so their IT people/sysadmins.
- IIUC some of the Geany devs are in that situation, they clearly will not
contribute to changes that they can't use.
I think Pavel said he's in this situation at work, but it's not like it's insurmountable, just more of a pain in the butt. Anyone else?
Geany need to go forward, and older distro will keep the old version of Geany same them keep the old version of GTK+ 2 and not support GTK+ 3 yet. Geany 1.24 and also Geany 0.21 it realy good software, but we can't to bog becausw have some older distor.
Going forward is adding features that are useful to users, such as those suggestions being gathered in the "direction for Geany" thread.
It's painful writing new, pre-deprecated code against dead dependency version and not being able to use newer or improved APIs, though.
Cheers, Matthew Brush
- we don't have the resources to backport bug fixes to old versions, the
only bug fix versions are the latest release of Geany.
Their sysadmins and distro vendors are supposed to take care of that aren't they? And anyway, most users wouldn't even be able to get a newer Geany installed from source on such a restricted system.
Well, they might for Mozilla, or similar, but I doubt distros will do any work for a dinky little obscure app like Geany unless our source will directly work on their system. And probably not even then :(
[...]
- IIUC some of the Geany devs are in that situation, they clearly will
not contribute to changes that they can't use.
I think Pavel said he's in this situation at work, but it's not like it's insurmountable, just more of a pain in the butt. Anyone else?
Also as we discussed on IRC, it would be worthwhile pinging the user list for what system they use, work and home, and what version of Geany etc to add to Franks conference/trade show data. We should agree what to ask on the devel list first, to ensure we get what we need to know with only one pass, spamming users with multiple questions isn't good.
Cheers Lex
On 13-11-12 03:48 PM, Lex Trotman wrote:
Why to switch to other toolkits?! I not understand what don't good in GTK+.
And also - why to keep GTK+ 2? GTK+ 3 avilable in all distro, also in older distro, it also work in Windows and also in Mac. this because GTK+ 3 released before almost three years.
Because many distros are more than 3 years old and still supported. Geany
has users (and developers) in commercial and academic environments which will often be constrained to older (but still supported) versions of Red Hat, Scientific Linux, Suse etc.
Its fine for hobbyists to want to play with the latest, we only have one PC to change over, but institutions often have hundreds or thousands and have all sorts of specific software to ensure still works when they upgrade.
That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some):
- Use an old, nearly end-of-life enterprise distro - Don't have admin rights or clout enough to get admins to install newer versions of stuff - Need to compile Geany from source, from the absolutely bleeding edge head of Git, rather than using the version they're "supposed to" as available from their distro and supported by their IT personnel - Refuse to take a few hours to compile newer GTK+ stack in $HOME - Can't or don't want to run a virtual machine, bootstick or live distro to get access to more modern software
Cheers, Matthew Brush
[1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins.
Am 13.11.2013 01:21, schrieb Matthew Brush:
That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some):
- Use an old, nearly end-of-life enterprise distro
- Don't have admin rights or clout enough to get admins to install
newer versions of stuff
- Need to compile Geany from source, from the absolutely bleeding edge
head of Git, rather than using the version they're "supposed to" as available from their distro and supported by their IT personnel
- Refuse to take a few hours to compile newer GTK+ stack in $HOME
- Can't or don't want to run a virtual machine, bootstick or live
distro to get access to more modern software
Cheers, Matthew Brush
[1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins.
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
Best regards.
Am 13.11.2013 11:22, schrieb Thomas Martitz:
Am 13.11.2013 01:21, schrieb Matthew Brush:
That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some):
- Use an old, nearly end-of-life enterprise distro
- Don't have admin rights or clout enough to get admins to install
newer versions of stuff
- Need to compile Geany from source, from the absolutely bleeding
edge head of Git, rather than using the version they're "supposed to" as available from their distro and supported by their IT personnel
- Refuse to take a few hours to compile newer GTK+ stack in $HOME
- Can't or don't want to run a virtual machine, bootstick or live
distro to get access to more modern software
Cheers, Matthew Brush
[1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins.
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
I'd like to add that this is an issue that really puts off existing and potential contributors (see Matthew's document-messages work which is awesome but stalled) because it's unclear whether it's worthwhile to work on something that requires a newer gtk. It's unclear because we have no process for evaluating and eventually bumping the minimum gtk version and a contributor cannot know if or when the gtk version will be bumped to meet the changes he has in mind.
The current process of "do the change and we'll see" followed by having the same discussion over compatibility again without result is terrible for everyone involved.
Best regards.
[...]
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Agree, AFAIK only one thing "needs" 2.16, and thats the nightly builder (which runs 2.16 checks and the windows nightly) and the windows release builder (whatever that is?) that includes it in the bundles.
Note, the windows nightly builder web page actually says its built against 2.14.7, does anyone know if thats right?
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
I'd agree that a planned schedule based on a metric would be an improvement. At least both developers and users would have some certainty about things.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
בתאריך ד', נוב 13, 2013 בשעה 12:46 PM, Lex Trotman elextr@gmail.com כתב:
[...]
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Agree, AFAIK only one thing "needs" 2.16, and thats the nightly builder (which runs 2.16 checks and the windows nightly) and the windows release builder (whatever that is?) that includes it in the bundles.
Note, the windows nightly builder web page actually says its built against 2.14.7, does anyone know if thats right?
I sure isn't right. You can to find GTK+ 3.6 and GTK+ 2.24. I build myself GTK+ 2 and GTK+ 3 on Windows, it possible.
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
I'd agree that a planned schedule based on a metric would be an improvement. At least both developers and users would have some certainty about things.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 13.11.2013 11:22, schrieb Thomas Martitz:
Am 13.11.2013 01:21, schrieb Matthew Brush:
That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some):
- Use an old, nearly end-of-life enterprise distro
- Don't have admin rights or clout enough to get admins to install
newer versions of stuff
- Need to compile Geany from source, from the absolutely bleeding edge
head of Git, rather than using the version they're "supposed to" as available from their distro and supported by their IT personnel
- Refuse to take a few hours to compile newer GTK+ stack in $HOME
- Can't or don't want to run a virtual machine, bootstick or live
distro to get access to more modern software
Cheers, Matthew Brush
[1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins.
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
I like the idea.
My suggestion: We should finish work on 1.24 in near future and release it with 2.16 dependency. After this we can upgrade to 2.24 or whatever. Also during this progress we should really sit down and define a way how to define what we are going to support. -> Different thread.
Cheers, Frank
On 13-11-13 04:12 AM, Frank Lanitz wrote:
Am 13.11.2013 11:22, schrieb Thomas Martitz:
Am 13.11.2013 01:21, schrieb Matthew Brush:
That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some):
- Use an old, nearly end-of-life enterprise distro
- Don't have admin rights or clout enough to get admins to install
newer versions of stuff
- Need to compile Geany from source, from the absolutely bleeding edge
head of Git, rather than using the version they're "supposed to" as available from their distro and supported by their IT personnel
- Refuse to take a few hours to compile newer GTK+ stack in $HOME
- Can't or don't want to run a virtual machine, bootstick or live
distro to get access to more modern software
Cheers, Matthew Brush
[1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins.
I'm *really really really* tired of this topic. This comes up every now and then, with the same bulled points over and over and with no outcome at all (we're still at 2.16 after a couple of discussions even though nobody explicitly says we need to be at this specific version).
Can't we just define a simple rule that's written out somewhere as to which GTK+ version to support. I don't mean a specific version number but a rule like "The one released X years/month ago" or "the version shipped in (enterprise) distro ABC" or "re-evaluated in a grand IRC meeting every Y month". This would mean implicit bumping of the minimum (by accepting patches that bump the minimum while observing the rule) as required. Then we don't have to have this tiresome argument over and over.
I like the idea.
My suggestion: We should finish work on 1.24 in near future and release it with 2.16 dependency. After this we can upgrade to 2.24 or whatever. Also during this progress we should really sit down and define a way how to define what we are going to support. -> Different thread.
+1
And we should also try/confirm ourselves some of the older distros we claim to want to support (as listed in your other message), to see if it's even possible or feasible to compile a latest Geany from source in these cases where the person isn't having the needed permissions to install packages (build tools, dev headers, etc) or touch stuff outside of $HOME.
I get the feeling a lot of people want to stick to gtk2 just because they fear change (or got burned by GNOME3, which uses gtk3) rather than being limited by technical reasons. Since the eventual change to gtk3 is inevitable, if there's no actual technical reason not to, we should probably get cracking on making it work as best as possible in Geany.
Cheers, Matthew Brush
Am 13.11.2013 00:48, schrieb Lex Trotman:
Because many distros are more than 3 years old and still supported. Geany has users (and developers) in commercial and academic environments which will often be constrained to older (but still supported) versions of Red Hat, Scientific Linux, Suse etc.
Yes.
Its fine for hobbyists to want to play with the latest, we only have one PC to change over, but institutions often have hundreds or thousands and have all sorts of specific software to ensure still works when they upgrade.
As an admin inside a smaller environment (<500 clients) its hard enough to get Windows XP out. We even got versions < XP SP3 running :(
Having this in mind for Geany: We have to check clearly, what we want to support. As already mentioned we don't have a good ruleset for this at the moment.
Cheers, Frank
On Tue, 12 Nov 2013 15:27:20 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
Unless we're going to switch toolkits or someone is volunteering to maintain a fork, there's really no logical reason to avoid the inevitable, [switch to GTK+3]
I've heard this a lot when Vista came out. And it never got > 18% market share.
I'm curious if you asked the users complaining about not wanting to "switch to a Gtk3-based desktop" whether they actually have libgtk3 installed anyway?
I do. Slower, looks ugly since Xfce has no theme support for it, and is otherwise no different.
side-by-side without any issues. Is it possible the users were just expressing more GNOME-hate and directing it GTK3 instead or you think they really are using super old desktop environments before Gtk3 started being widely distributed?
The current Debian stable + testing:
gtk+2 packages: 2005 (seven months ago: 2795) gtk+3 packages: 710 (seven months ago: 345)
So, we have 74% super old applications from before gtk+3 started being widely distributed. :) Definitely better than 89% though.
The interesting thing is the death of 400 gtk+2 packages, too bad I didn't keep a list to see what's going on. Either a big structural change, or "the inevitable" may be something different that you think...
I get the feeling a lot of people want to stick to gtk2 just because they fear change (or got burned by GNOME3, which uses gtk3) rather than being limited by technical reasons. Since the eventual change to gtk3 is inevitable, if there's no actual technical reason not to, we should probably get cracking on making it work as best as possible in Geany.
"We deprecated the widgets with icons" (buttons, menu items etc.) "because we did some ugly hacks to hide the icons in these widgets for GNOME3, and we want to cleanup the code by killing these widgets".
"We removed the stock icons because there are a lot of nice icon themes novadays" (how are these related?) "and because... well, you can change the accelerators for the standard actions (Open, Save, ...) now!"
Yes, Matthew, do I fear the changes in gtk+3. I believe there is no need to explain or discuss what such attitute may lead to.
(As of GNOME 3, I only used it on a company computer for several days, and it wasn't that bad. Certainly better than Windows 8, though not something I'd install on my home machine.)
Am 11.11.2013 10:31, schrieb Matthew Brush:
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since we don't have to contend with TM/CTags that uses global state like mad, and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
I like that idea very, very much. In some plugins we already do check for filetype on document changes to activate functions or deactivate them. Having this as kind of a general build in would help a lot and opens a lot of new doors for plugin devs. As well as it might will remove some unneeded stu from core for most users.
Cheers, Frank
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. [...]
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something.
Nice idea, but why? It's not like they eat a lot of resources, and constantly (un)loading plugins has it's cost too.
- Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily [...]
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI.
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
[...]
Nice points. But long time ago, I chose Geany specifically because it provided rectangular selections, and the GtkSourceView based editors did not - and still don't. Maybe in the next century?.. Of course, both rectangular selection and virtual space in Scintilla are afterthought and implemented as hacks, but they work.
Another bad thing about GtkSourceView is that it'll make us even more dependent on the newest GTK+ versions, and I don't trust *their* direction. If we are to make such vast changes as using GtkSourceView, GTK+3 and even Vala, why not rewrite everything in Qt and C++?..
- Automatically-bindable plugin API that we officially support for
multiple languages. Writing plugins in C is crap, IMO.
It depends on the need for speed. A GeanyInsertNum, GeanyExtraSel or Scope in <insert your favorite interpreter here> would be pointless.
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
Slightly off-topic but Vala makes the async/GIO file stuff insanely easy and short to write as it has support for it built right into the language syntax.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. [...]
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something.
Nice idea, but why? It's not like they eat a lot of resources, and constantly (un)loading plugins has it's cost too.
So they don't have to connect to every single document and notebook signal and only activate themselves when a specific filetype is opened/closed/saved/etc and de-activate themsleves when the tab switches and stuff. What's more it would/could provide some form of conflict resolution over which plugins are handling which filetypes and stuff. This is especially useful since we're talking about "language support plugins", not run-of-the-mill existing Geany plugins which just (can) stomp all over each other and Geany anyway :)
- Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily [...]
The other way we could go is to just strive to be a proper, modern GTK+ application. By this I mean using stuff like GtkApplication, GtkApplicationWindow, GSettings, etc. The GTK+ stack has lots of cool stuff to make doing applications easier/better that we don't use because of the ever-present restriction about needing to be able to support LTS distros with old GTK2 and not wanting to "GObjectify" and/or make large changes to the code.
The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI.
It works fine here with Scintilla, FWIW. GTK3 overall definitively feels a little slower and some of the new "touch friendly" dialogs and stuff are kind of annoying, but I mean barring completely switching toolkits (unlikely) or writing our own cross-platform wrapper toolkit (infeasible), it's what we're stuck with for the future, so why fight it kicking and screaming?
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
[...]
Nice points. But long time ago, I chose Geany specifically because it provided rectangular selections, and the GtkSourceView based editors did not - and still don't. Maybe in the next century?.. Of course, both rectangular selection and virtual space in Scintilla are afterthought and implemented as hacks, but they work.
Yeah, and rectangular selection is definitively a valid point, but I think we shouldn't rule out listing (on the wiki or wherever this discussion winds up) the pros and cons of each and seeing what comes. For all we know we could wind up with very compelling list of improvements/features compared to rectangular selection and then we can decide whether it's worth it (maybe it's even possible/easy-enough to implement it in GtkTextView/GSV ourselves) or maybe it goes complete opposite and we come up will all kinds of things Scintila provides that GSV doesn't.
Another bad thing about GtkSourceView is that it'll make us even more dependent on the newest GTK+ versions, and I don't trust *their* direction. If we are to make such vast changes as using GtkSourceView, GTK+3 and even Vala, why not rewrite everything in Qt and C++?..
We wouldn't have to use the latest greatest version of GtkSourceView, although I don't see why not (assuming we're sticking with GTK+), since that project is all about making a kick-ass powerful, flexible, GTK+ friendly source code editing component.
I'm not totally against Qt (it's actually really nice) but GTK+ is really nice too, and Vala is much easier/nicer than C++ (even if not nearly as mature/stable). Additionally, I think we'd have to drop the "fast and lightweight" tag line if we switched to Qt or people wouldn't take us seriously anymore :)
- Automatically-bindable plugin API that we officially support for
multiple languages. Writing plugins in C is crap, IMO.
It depends on the need for speed. A GeanyInsertNum, GeanyExtraSel or Scope in <insert your favorite interpreter here> would be pointless.
What does Scope do that it needs hard-core low-level speed for? Or the other plugins? I've written a few GeanyPy scripts that blast through the buffer in tight loops and stuff, and compared to the speed of rendering/GUI stuff and how slow the user can physically notice, it does a fine job. What's more, if the API was done in C/Vala, you could just as easily still write the plugins in C should you chose to, only the non-hardcore-low-level-C-hackers wouldn't be left out in the cold as they are now.
Cheers, Matthew Brush
On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change).
Slightly off-topic but Vala makes the async/GIO file stuff insanely easy and short to write as it has support for it built right into the language syntax.
GLib-based, right? Well, at least we'll have only one (GIO) set of problems to worry about.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. [...]
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something.
Nice idea, but why? It's not like they eat a lot of resources, and constantly (un)loading plugins has it's cost too.
So they don't have to connect to every single document and notebook signal and only activate themselves when a specific filetype is opened/closed/saved/etc and de-activate themsleves when the tab switches and stuff.
Don't worry, gtk+3 will waste more time than all the current plugins together.
What's more it would/could provide some form of conflict resolution over which plugins are handling which filetypes and stuff. This is especially useful since we're talking about "language support plugins", not run-of-the-mill existing Geany plugins which just (can) stomp all over each other and Geany anyway :)
We'll be lucky if these _future_ plugins provide so much functionality as to have conflicts over specific file types.
The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI.
It works fine here with Scintilla, FWIW.
You forgot the obligatory "YMMV". Should I make a video clip and post it? :)
GTK3 overall definitively feels a little slower and some of the new "touch friendly" dialogs and stuff are kind of annoying, but I mean barring completely switching toolkits (unlikely) or writing our own cross-platform wrapper toolkit (infeasible), it's what we're stuck with for the future, so why fight it kicking and screaming?
Because it's slower and annoying? Because we don't know what funny thing the gtk+ devs will do tommorow? The more I think about it, the more a transision to KDE seems a good idea.
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
[...]
Nice points. But long time ago, I chose Geany specifically because it provided rectangular selections, and the GtkSourceView based editors did not - and still don't. Maybe in the next century?.. Of course, both rectangular selection and virtual space in Scintilla are afterthought and implemented as hacks, but they work.
Yeah, and rectangular selection is definitively a valid point, but I think we shouldn't rule out listing (on the wiki or wherever this discussion winds up) the pros and cons of each and seeing what comes.
The rectangular selection is a must have for me, as I'm using Geany for a general purpose editor as well.
We wouldn't have to use the latest greatest version of GtkSourceView, although I don't see why not (assuming we're sticking with GTK+), since that project is all about making a kick-ass powerful, flexible, GTK+ friendly source code editing component.
It's really disheartening to see it lacking features that the MS-DOS editors in the 80-s had. I mean it, no sarcasm here.
- Automatically-bindable plugin API that we officially support for
multiple languages. Writing plugins in C is crap, IMO.
It depends on the need for speed. A GeanyInsertNum, GeanyExtraSel or Scope in <insert your favorite interpreter here> would be pointless.
What does Scope do that it needs hard-core low-level speed for?
The message loop and processing.
Or the other plugins?
Nothing. After the rectangular selection was rewritten in Scintilla 2.x, it became so slow than even a shell script will not make any difference.
On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change).
So fix GLib instead of adding a bunch of different workarounds to Geany. Geany's code isn't the place to work around bugs in the *open source*, supposedly cross-platform toolkit we use, it completely defeats the purpose of using such a library in the first place. If we can fix it Geany, we can just as easily contribute the fixes to GLib instead. If the fixes are too hackish or not good enough to be accepted in GLib, why would we want them in Geany's code?
Slightly off-topic but Vala makes the async/GIO file stuff insanely easy and short to write as it has support for it built right into the language syntax.
GLib-based, right? Well, at least we'll have only one (GIO) set of problems to worry about.
Yes, and see above. (works fine for me though, YMMV)
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. [...]
A way for plugins to "handle" certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something.
Nice idea, but why? It's not like they eat a lot of resources, and constantly (un)loading plugins has it's cost too.
So they don't have to connect to every single document and notebook signal and only activate themselves when a specific filetype is opened/closed/saved/etc and de-activate themsleves when the tab switches and stuff.
Don't worry, gtk+3 will waste more time than all the current plugins together.
What's more it would/could provide some form of conflict resolution over which plugins are handling which filetypes and stuff. This is especially useful since we're talking about "language support plugins", not run-of-the-mill existing Geany plugins which just (can) stomp all over each other and Geany anyway :)
We'll be lucky if these _future_ plugins provide so much functionality as to have conflicts over specific file types.
They definitively won't with all this completely counter-productive hating on the library we use, holding back any type of useful progress so you can vent your frustrations about something that is completely outside of our control.
The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI.
It works fine here with Scintilla, FWIW.
You forgot the obligatory "YMMV". Should I make a video clip and post it? :)
I don't doubt it, I just said it works for me. I know of at least a few other users and devs also using it without such problems.
GTK3 overall definitively feels a little slower and some of the new "touch friendly" dialogs and stuff are kind of annoying, but I mean barring completely switching toolkits (unlikely) or writing our own cross-platform wrapper toolkit (infeasible), it's what we're stuck with for the future, so why fight it kicking and screaming?
Because it's slower and annoying? Because we don't know what funny thing the gtk+ devs will do tommorow? The more I think about it, the more a transision to KDE seems a good idea.
OK, but barring a switch to Qt, it's not at all useful gripe about how much it sucks and cling to it in desperation, hoping some magical free software gnome will come along and revert years worth of commits, made on a corporation's dime, by people who seem to like the changes.
Lots of users actually *want* Geany to move to Gtk3, for various reasons such as using the same theme as the rest of their desktop (see what Gtk version the top 3 Linux distros are using) or to get better/any Wayland or support, or for various other reasons.
So they shouldn't get proper support for their environment because you hate change, refuse to acknowledge the inevitable and want to stick to a deprecated version of our toolkit for a couple more years until it's completely dead and gone and we are left with a big crusty hairball of obsolete, unmaintainable source with more #ifdef's than actual lines of code?
- Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons
that come to mind, in no particular order:
[...]
Nice points. But long time ago, I chose Geany specifically because it provided rectangular selections, and the GtkSourceView based editors did not - and still don't. Maybe in the next century?.. Of course, both rectangular selection and virtual space in Scintilla are afterthought and implemented as hacks, but they work.
Yeah, and rectangular selection is definitively a valid point, but I think we shouldn't rule out listing (on the wiki or wherever this discussion winds up) the pros and cons of each and seeing what comes.
The rectangular selection is a must have for me, as I'm using Geany for a general purpose editor as well.
It should definitively be taken into consideration if we do look at switching in the future, as well as any other pros and cons.
We wouldn't have to use the latest greatest version of GtkSourceView, although I don't see why not (assuming we're sticking with GTK+), since that project is all about making a kick-ass powerful, flexible, GTK+ friendly source code editing component.
It's really disheartening to see it lacking features that the MS-DOS editors in the 80-s had. I mean it, no sarcasm here.
This hasn't changed between older and newer versions of GtkSourceView AFAIK.
- Automatically-bindable plugin API that we officially support for
multiple languages. Writing plugins in C is crap, IMO.
It depends on the need for speed. A GeanyInsertNum, GeanyExtraSel or Scope in <insert your favorite interpreter here> would be pointless.
What does Scope do that it needs hard-core low-level speed for?
The message loop and processing.
So you profiled it and found that the message loop was too slow and that your "processing" was a big bottleneck?
Or the other plugins?
Nothing. After the rectangular selection was rewritten in Scintilla 2.x, it became so slow than even a shell script will not make any difference.
Scintilla openly accepts patches :)
FWIW, I'm not actually advocating that Gtk3 is better than Gtk2, I'm advocating it doesn't change the fact that, for better or worse, Gtk3 is the current version of our toolkit library (for quite some time now) and complaining about it won't change anything.
Cheers, Matthew Brush
Le 15/11/2013 04:19, Matthew Brush a écrit :
On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change).
So fix GLib instead of adding a bunch of different workarounds to Geany. Geany's code isn't the place to work around bugs in the *open source*, supposedly cross-platform toolkit we use, it completely defeats the purpose of using such a library in the first place. If we can fix it Geany, we can just as easily contribute the fixes to GLib instead. If the fixes are too hackish or not good enough to be accepted in GLib, why would we want them in Geany's code?
Easier said than done unfortunately. The GIO problem about losing data on write failure has been discussed on their bug tracker, and the problem is that the fix isn't as obvious at it seems, and people didn't really agree on how it should be addressed. Unfortunately it didn't go much further AFAIK, and people started to use hacks and workarounds.
On 13-11-15 07:02 AM, Colomban Wendling wrote:
Le 15/11/2013 04:19, Matthew Brush a écrit :
On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
> 1. An architecture that allows multi-threading to be used for non-GUI > tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change).
So fix GLib instead of adding a bunch of different workarounds to Geany. Geany's code isn't the place to work around bugs in the *open source*, supposedly cross-platform toolkit we use, it completely defeats the purpose of using such a library in the first place. If we can fix it Geany, we can just as easily contribute the fixes to GLib instead. If the fixes are too hackish or not good enough to be accepted in GLib, why would we want them in Geany's code?
Easier said than done unfortunately. The GIO problem about losing data on write failure has been discussed on their bug tracker, and the problem is that the fix isn't as obvious at it seems, and people didn't really agree on how it should be addressed. Unfortunately it didn't go much further AFAIK, and people started to use hacks and workarounds.
Right, but is it worth having 2 or 3 ways of writing a file in Geany's code, only selectable through hidden/various preference, another (presumably) large code-paths of absolutely critical code, which never gets any regular testing (except for the default way), and that 99% of users will never use or care about? I mean if many other Gtk apps are doing it this way and the sky hasn't fallen (eg. there's only 12 comments on that bug report, many from developers, no crazy users crying about lost data and stuff), is it an indication that it's just not that important enough to warrant such workarounds?
Cheers, Matthew Brush
Am 15.11.2013 04:19, schrieb Matthew Brush:
The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI.
It works fine here with Scintilla, FWIW.
You forgot the obligatory "YMMV". Should I make a video clip and post it? :)
I don't doubt it, I just said it works for me. I know of at least a few other users and devs also using it without such problems.
I can confirm this problem. I can also confirm that it only happens in combination with GTK+3. It's hugely annoying. But who knows what's the cause of it. (?)
Best regards.
On Thu, 14 Nov 2013 19:19:05 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
They definitively won't with all this completely counter-productive hating on the library we use, holding back any type of useful progress so you can vent your frustrations about something that is completely outside of our control.
I don't like regressions, be it in Glade, Scintilla or GTK+, or any other software. What is so strange about it? With too many of them, I start considering something entirely different - isn't that normal? The sad thing is, none of these are Geany's fault.
Lots of users actually *want* Geany to move to Gtk3, for various reasons such as using the same theme as the rest of their desktop (see what Gtk version the top 3 Linux distros are using) or to get better/any Wayland or support, or for various other reasons.
What stops them from using Geany with gtk+3? What do you mean by "move to gtk+3" - drop gtk+2 ASAP? Why not let the package maintainers for the different distributions decide whether to build Geany for 2 or 3?
So they shouldn't get proper support for their environment because you hate change, refuse to acknowledge the inevitable and want to stick to a deprecated version of our toolkit for a couple more years until it's completely dead and gone and we are left with a big crusty hairball of obsolete, unmaintainable source with more #ifdef's than actual lines of code?
"hate change"? :) I'm considering KDE, which is a much bigger switch. It would have been nice to have Geany for some more time, but I have absolutely no idea how long gtk+2 will be supported.
As of the "inevitable" - every bad thing is inevitable, unless there are enough people to oppose it. If there aren't, OK, free software is all about choice.
What does Scope do that it needs hard-core low-level speed for?
The message loop and processing.
So you profiled it and found that the message loop was too slow and that your "processing" was a big bottleneck?
Do I really need to write a python variant of source_dispatch() and on_editor_notify() to see that it'll slow everything down to a crawl? C'mon. :) I program in python since some time now, have an idea about it's speed, and one of the things I like about it is ctypes.
Or the other plugins?
Nothing. After the rectangular selection was rewritten in Scintilla 2.x, it became so slow than even a shell script will not make any difference.
Scintilla openly accepts patches :)
I don't doubt about it. :) But it was _properly_ rewritten, and the new rectangular selection shares a lot with the multiply selection. Any rectangle larger than 10k lines (or 20k, if you have a high level customer CPU) is slow by design, it's not a bug. After I had short discussion with one of the developers, 2.xy was somewhat improved, but it hit the design limit.
FWIW, I'm not actually advocating that Gtk3 is better than Gtk2, I'm advocating it doesn't change the fact that, for better or worse, Gtk3 is the current version of our toolkit library (for quite some time now) and complaining about it won't change anything.
Perhaps you missed my mail from Nov 14 in the "Gtk2 vs Gtk3" thread, it contains exact percents of how current gtk+3 is, and how the gtk+ packages dropped overall big time.
But with all that said, you are right that such a discussion will lead us nowhere. I'll read your answer, if there is any, and that'll be it. Hopefully it'll contain some directions as to when Geany is going gtk+3 only. The "Gtk2 vs Gtk3" percents may be a good starting point.
On 13-11-15 11:19 AM, Dimitar Zhekov wrote:
On Thu, 14 Nov 2013 19:19:05 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
[snip]
Lots of users actually *want* Geany to move to Gtk3, for various reasons such as using the same theme as the rest of their desktop (see what Gtk version the top 3 Linux distros are using) or to get better/any Wayland or support, or for various other reasons.
What stops them from using Geany with gtk+3? What do you mean by "move to gtk+3" - drop gtk+2 ASAP? Why not let the package maintainers for the different distributions decide whether to build Geany for 2 or 3?
With the Gtk3 configure option default to off, I worry it will continue to be considered "experimental" and left off by packagers and/or that it will get enough testing.
Also when you go to fix/cleanup/improve something you have to be so careful with the functions used (moreso than with newer versions) because so many were added long after the versions we support even though many people have been using them for years. What's more, there's a whole host of nice APIs (even widgets, some being nice) available since Gtk2 days that in my experience make application development cleaner and easier, that we can't even begin to support while needing to maintain Gtk2 compatiblity. And even those newer stuff we can support it requires a bunch of #ifdef guards and extra work/code-paths, which often makes it not even worthwhile.
Additionally, I don't think GObject-Introspection really properly supports pre-Gtk3, so all plans for the plugin API improvements are on hold until then.
As I mentioned in another thread/message, at least bumping to the very last version of Gtk2 for now would allow to cleanup a bunch of the old code and also to use some APIs that appeared in late Gtk2 (or GLib from that time).
[snip]
FWIW, I'm not actually advocating that Gtk3 is better than Gtk2, I'm advocating it doesn't change the fact that, for better or worse, Gtk3 is the current version of our toolkit library (for quite some time now) and complaining about it won't change anything.
Perhaps you missed my mail from Nov 14 in the "Gtk2 vs Gtk3" thread, it contains exact percents of how current gtk+3 is, and how the gtk+ packages dropped overall big time.
I read it, but didn't understand the point you were making in the context of the part you were replying to about whether people were actually using really old distros that *don't* support Gtk3, that is, they have no libgtk3 installed/available or whether they just don't like GNOME/Gtk3 (which, IMO, is not useful/relevant reason to hold back on Gtk2, it's only postponing the inevitable, as mentioned).
But with all that said, you are right that such a discussion will lead us nowhere. I'll read your answer, if there is any, and that'll be it. Hopefully it'll contain some directions as to when Geany is going gtk+3 only. The "Gtk2 vs Gtk3" percents may be a good starting point.
If it were up to me (it's obviously not), we'd bump to very last Gtk2 after next release (1.24), moving towards going completely Gtk3 after the release that follows it (1.25). Also, I'd enable Gtk3 support by default after the next release, including using Gtk3 bundle in Win32 build, and leaving Gtk2 support as "legacy", if it were my call.
Cheers, Matthew Brush
What about redesign the GUI?
Regards, Yosef Or Boczko
בתאריך ב', נוב 11, 2013 בשעה 9:18 AM, Lex Trotman elextr@gmail.com כתב:
Hi All,
Recently there have been a number of proposals for significant changes in Geany, different languages, GObjectification and other various changes.
As good or bad as the individual suggestions may be, they have made it clear to me that there is no plan for the future of Geany that allows them to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany should be headed.
To start the ball rolling, here are some of the things I see Geany should aspire to:
- An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
- Language specific assistance, such as indentation, or dynamic
error marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
- Proper portability. At the moment Geany is really a Linux
application that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
- Multiple top level windows. As monitors are cheaper, being able
to spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I would suggest the process to be:
- gather other major ideas for capabilities that Geany should plan
to support 2. develop a design that supports these (or at least the most useful ones) 3. look at how that design can be implemented, can the existing design be mutated to it, or is it a clean framework that large parts of the existing functionality can plug into, or is it a whole clean implementation. This also includes issues like languages to use (C, C++, Vala, Haskell etc). 4. depending on the outcome from 3. use a new repository organisation or at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
This is something very different to the way Geany is currently operating, and I don't know if the community wants to consider such a more structured approach. If its felt that its worthwhile then I suggest that steps one and two are best achieved using the wiki and I will volunteer to set up and maintain page(s) for those phases at least.
So to summarise, what capabilities should Geany aspire to support, and what is the process to develop the best software architecture to support those capabilities.
Cheers Lex
On 12 November 2013 09:38, Yosef Or Boczko yoseforb@gmail.com wrote:
What about redesign the GUI?
Yes, the ability to support a different or more flexible GUI organisation is one of the possible disruptive changes to be considered.
Cheers Lex
Regards, Yosef Or Boczko
[...]
Hi All,
There have been lots of interesting suggestions so far. I will leave the thread until the end of the week and then try to summarise.
So keep thinking.
So far nobody has said "don't do anything" so I guess that means that there is general support for examining the design of Geany and developing a process to support getting to the preferred design.
Cheers Lex
On 11 November 2013 23:51, Lex Trotman elextr@gmail.com wrote:
Hi All,
There have been lots of interesting suggestions so far. I will leave the thread until the end of the week and then try to summarise.
So keep thinking.
So far nobody has said "don't do anything" so I guess that means that there is general support for examining the design of Geany and developing a process to support getting to the preferred design.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I've "moved on" to PhpStorm due to the failing "indexed project" support of Geany. Still miss the simplicity, and speedy interface, but I had to switch to do my job better. I'd vote for better/faster indexing (and scopes).
I'm still following the mailinglist for sentimental reasons ;)
-H-
[...]
I've "moved on" to PhpStorm due to the failing "indexed project" support of Geany. Still miss the simplicity, and speedy interface, but I had to switch to do my job better. I'd vote for better/faster indexing (and scopes).
I'm still following the mailinglist for sentimental reasons ;)
Hi again Harold,
Its rare to hear from ex-users. So any input could be a useful different perspective.
By "index" I assume you mean symbol parsing?
Cheers Lex
-H- _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12 November 2013 00:24, Lex Trotman elextr@gmail.com wrote:
[...]
I've "moved on" to PhpStorm due to the failing "indexed project" support of Geany. Still miss the simplicity, and speedy interface, but I had to switch to do my job better. I'd vote for better/faster indexing (and scopes).
I'm still following the mailinglist for sentimental reasons ;)
Hi again Harold,
Its rare to hear from ex-users. So any input could be a useful different perspective.
By "index" I assume you mean symbol parsing?
Hey Lex,
Yes, I meant symbol parsing. PhpStorm even has contextual symbol parsing, so it knows what variables, functions, methods, etc are available in a certain scope. Pretty fancy; some might even say it's way too much.
PhpStorm also supports * Undeclared variables (even potentially unreachable variables!) * Unused variables * Unreachable code * And lots more like these!
I quit using Geany because starting (or exiting) it with a Drupal project opened took about 8(?) minutes to open, without any feedback. PhpStorm indexes (multi-threaded) in the background and starts semi-fast (it's still Java).
I'm not expecting Geany to incorporate these way too advanced features, but multi-threaded background indexing seems like a must have to compete with the "big boys".
Cheers!
Harold
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
[1] https://developer.gnome.org/gtk3/3.10/GtkHeaderBar.html
What you thing?
Regards, Yosef Or Boczko
בתאריך ג', נוב 12, 2013 בשעה 12:46 AM, Lex Trotman elextr@gmail.com כתב:
On 12 November 2013 09:38, Yosef Or Boczko yoseforb@gmail.com wrote:
What about redesign the GUI?
Yes, the ability to support a different or more flexible GUI organisation is one of the possible disruptive changes to be considered.
Cheers Lex
Regards, Yosef Or Boczko
[...]
On 13-11-11 03:11 PM, Yosef Or Boczko wrote:
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
Yes, we shouldn't avoid embracing/using our GUI toolkit to its fullest just because people dislike the most famous desktop environment that uses it. If we're never going to fully embrace it to avoid "gnoming things up", then we should switch to a different toolkit that everyone feels comfortable with and fully embrace that. The toolkit we use shouldn't be a political/emotional issue but rather technical.
Cheers, Matthew Brush
Am 12.11.2013 00:35, schrieb Matthew Brush:
On 13-11-11 03:11 PM, Yosef Or Boczko wrote:
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
Yes, we shouldn't avoid embracing/using our GUI toolkit to its fullest just because people dislike the most famous desktop environment that uses it. If we're never going to fully embrace it to avoid "gnoming things up", then we should switch to a different toolkit that everyone feels comfortable with and fully embrace that. The toolkit we use shouldn't be a political/emotional issue but rather technical.
Embracing the toolkit (GTK) and adopting GNOME application style are two different things. Yes, we can make more use of GTK. But we do not have to "GNOME it up" for it. And whether or not we use a toolkit to its fullest is no indication at all that we switch to another one.
Best regards.
On Tue, 12 Nov 2013 08:39:14 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Embracing the toolkit (GTK) and adopting GNOME application style are two different things. Yes, we can make more use of GTK. But we do not have to "GNOME it up" for it. And whether or not we use a toolkit to its fullest is no indication at all that we switch to another one.
I think it's already been expressed here, but I would say that (within the realm of what is possible), Geany should continue to work comfortably in any window manager / desktop environment. While I've grown to tolerate Gnome3 over the last year (mainly because I don't have time to properly test the alternatives), I expect to abandon it in the future in favour of something a little less GPU heavy.
I'm very interested in this (potential) architectural change, and should I find myself with time in the future (not going to happen for at least another few months) I'd be quite interested in trying to contribute.
Regards,
Jon
On 13-11-11 11:39 PM, Thomas Martitz wrote:
Am 12.11.2013 00:35, schrieb Matthew Brush:
On 13-11-11 03:11 PM, Yosef Or Boczko wrote:
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
Yes, we shouldn't avoid embracing/using our GUI toolkit to its fullest just because people dislike the most famous desktop environment that uses it. If we're never going to fully embrace it to avoid "gnoming things up", then we should switch to a different toolkit that everyone feels comfortable with and fully embrace that. The toolkit we use shouldn't be a political/emotional issue but rather technical.
Embracing the toolkit (GTK) and adopting GNOME application style are two different things. Yes, we can make more use of GTK. But we do not have to "GNOME it up" for it. And whether or not we use a toolkit to its fullest is no indication at all that we switch to another one.
I mean to use the classes and features of the toolkit (GLib/GObject/GTK+), not "GNOME it up" or whatever that means. For example instead of writing a bunch of long functions embedded in another module to customize a widget, to instead make a subclass widget and put the code related to the widget in the widget's class code instead of mixed all about. Or another example, making use of GApplication which provides the functionality we have a whole complicated socket.c module for (uniqueness/instance), or GtkApplicationWindow which works with GtkApplication to support multiple windows easily and sharing actions and such between them.
I don't even use GNOME and I have no idea really what GNOME-style apps are like, so I'm kind of confused why people think I want to "GNOME up" Geany. I just want to use the features of our cross-platform toolkit to their fullest instead of doing stuff the hard way, just to avoid "GNOMEing up" our code, and I definitively would rather not want to switch toolkits.
Cheers, Matthew Brush
Am 12.11.2013 00:11, schrieb Yosef Or Boczko:
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
[1] https://developer.gnome.org/gtk3/3.10/GtkHeaderBar.html
What you thing?
If this needs to only support Gtk3 I'm against it alone for that reason. As you might know I'm doing a couple of boothes for Geany during the year and one major question last times is: will Geany keep supporting Gtk2.
Cheers, Frank
Am 12.11.2013 16:38, schrieb Frank Lanitz:
Am 12.11.2013 00:11, schrieb Yosef Or Boczko:
As a GNOME 3 user, I realy like the recent design of the applications in GNOME, specify the GtkHeaderBar[1].
And yes, I know have some people not like the new design of GNOME.
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go also to the GtkHeaderBar, it realy good thing.
[1] https://developer.gnome.org/gtk3/3.10/GtkHeaderBar.html
What you thing?
If this needs to only support Gtk3 I'm against it alone for that reason. As you might know I'm doing a couple of boothes for Geany during the year and one major question last times is: will Geany keep supporting Gtk2.
Everything can be done with ongoing GTK2 support. It's just a question of how different the two code paths are and the associated maintenance effort. There will, for a long time to come, a GTK2 compatible build even if we are going to use GTK3 features more.
But we should bump, at some point, the min. GTK2 version because that has APIs more similar to GTK3. Actually, in my opinion, ASAP so that we can merge the changebar work of Matthew.
Best regards.
Le 12/11/2013 00:11, Yosef Or Boczko a écrit :
As Matthew say, we can to go use the modern GTK+ API, for GtkApplication, GSettings and more, and I offer to go
GtkApplication and GSettings don't change the UI in any way really, they just help you built you app. And I certainly quite like both [1].
[1] *Not* saying we absolutely should use them or not in Geany Matthew, don't get too excited ;)
also to the GtkHeaderBar, it realy good thing.
This, however, is a display widget. And honestly, I have absolutely no idea how it'd make something better/good/anything -- nor exactly what UI concept it's supposed to achieve even.
So no, "using widget W" don't seem to be a good idea to me. "Improving UI at place P, and widget W would be a perfect match for it", why not.
Regards, Colomban
Am 11.11.2013 08:18, schrieb Lex Trotman:
- An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
I would like that. Also for some plugin tasks it would be great. But agree that it is not an easy task.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
I'm afraid too. Most likely dependencies will increase as well as memory footprint. But this is something we get regular asked on our boothes: More intelligent auto completion stuff. Unfortunately this is one of the things making the huge IDE so huge.
- Proper portability. At the moment Geany is really a Linux
application that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
Is qeany.org still available? ;) Well... I don't think its a good idea to make the toolkit drawing the editor complete changeable. It will be a huge effort to support the same features on Qt and Gtk and Windows ... Even some "native" backends would be really cool. So kind of modules as we already do with some of the ifdef-sections for Windows.
- Multiple top level windows. As monitors are cheaper, being able to
spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I agree. Also I think this needs to be discussed in a more face-to-face-session than wiki or email.
[suggested steps] These are good.
Cheers, Frank
[...]
I'm afraid too. Most likely dependencies will increase as well as memory footprint. But this is something we get regular asked on our boothes: More intelligent auto completion stuff. Unfortunately this is one of the things making the huge IDE so huge.
Yes, more capabilities or using less memory, sadly it will be "pick one" :) Thats why having stuff plugin is important, letting you leave out the stuff you don't want.
Its good to get user feedback. Are there any other useful inputs from your contacts with users that we need to know about for the purposes of these discussions?
[...]
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
Thats an interesting potential solution we need to examine.
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I agree. Also I think this needs to be discussed in a more face-to-face-session than wiki or email.
That might be hard, Geany contributors are worldwide, in various time zones. It can be done via email or wiki, I've done it more than once, with different countries. It requires everything to be written in detail, which is painful, but that then leaves a record for later consultation so there is less "why did they do **that**" :)
Of course if you are offering to pay to fly us all somewhere nice (warm, beaches, good food) for consultations ... :)
Cheers Lex
On 13-11-12 04:05 PM, Lex Trotman wrote:
[...]
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
Thats an interesting potential solution we need to examine.
This is completely taken care of/easy[1] with some of the newer APIs provided by GTK3 (might even be available in later GTK2 versions). It uses DBus for interprocess communications behind the scenes.
Cheers, Matthew Brush
[1]: Easy to use that is, not easy to bolt on to existing Geany code without upsetting it :)
Am 13.11.2013 02:15, schrieb Matthew Brush:
On 13-11-12 04:05 PM, Lex Trotman wrote:
[...]
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
Thats an interesting potential solution we need to examine.
This is completely taken care of/easy[1] with some of the newer APIs provided by GTK3 (might even be available in later GTK2 versions). It uses DBus for interprocess communications behind the scenes.
How's the DBus situation on Windows?
Best regards
On 13-11-13 12:04 AM, Thomas Martitz wrote:
Am 13.11.2013 02:15, schrieb Matthew Brush:
On 13-11-12 04:05 PM, Lex Trotman wrote:
[...]
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
Thats an interesting potential solution we need to examine.
This is completely taken care of/easy[1] with some of the newer APIs provided by GTK3 (might even be available in later GTK2 versions). It uses DBus for interprocess communications behind the scenes.
How's the DBus situation on Windows?
I've never used in on Windows myself but based on a 2 second Google search it seems to be available/ported/working. It sounds plausible since I think Qt also uses it, and they seem to be big on Windows support.
Cheers, Matthew Brush
On 13 November 2013 10:53, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-13 12:04 AM, Thomas Martitz wrote:
Am 13.11.2013 02:15, schrieb Matthew Brush:
On 13-11-12 04:05 PM, Lex Trotman wrote:
[...]
I think this would need a more client-server-architecture as maybe described in point 3. However, I'd like to have multiple Geany instances working at same session. But I'm a little afraid of the changes needs to be done for it.
Thats an interesting potential solution we need to examine.
This is completely taken care of/easy[1] with some of the newer APIs provided by GTK3 (might even be available in later GTK2 versions). It uses DBus for interprocess communications behind the scenes.
How's the DBus situation on Windows?
I've never used in on Windows myself but based on a 2 second Google search it seems to be available/ported/working. It sounds plausible since I think Qt also uses it, and they seem to be big on Windows support.
How many "Geany on Windows" users are there? is it 90% POSIX/10% Windows? Or more? Less?
I'm a big fan of the "90% rule". If 90% of the users don't need/want it, don't implement or support it. Same goes for library versions: if 90%+ has GTK3, it's safe to require that.
2ct.
-H-
[...]
How many "Geany on Windows" users are there? is it 90% POSIX/10% Windows? Or more? Less?
I'm a big fan of the "90% rule". If 90% of the users don't need/want it, don't implement or support it. Same goes for library versions: if 90%+ has GTK3, it's safe to require that.
Because Geany does not install spyware to see where it is used, we really don't know. :)
Various people make various guesses based on their personal experience, but really the people who know are only the users themselves.
I was thinking of asking on the users ML, after we agreed the questions here first. But do we want to?
Are we looking for "market share"? Or are we interested in making the best software that suits the contributors, and if its useful to others fine?
Thats a pretty deep and fundamental question about the project, what do those who are interested enough to monitor the dev list think?
Cheers Lex
2ct.
-H- _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 13.11.2013 11:30, schrieb Lex Trotman:
I was thinking of asking on the users ML, after we agreed the questions here first. But do we want to?
Are we looking for "market share"? Or are we interested in making the best software that suits the contributors, and if its useful to others fine?
Thats a pretty deep and fundamental question about the project, what do those who are interested enough to monitor the dev list think?
Well... I was thinking for a long time asking users what they are using in terms of OS/languages(locale)/languages(src)/plugins etc. As IMHO we should do everything which fits the needs of contributors as well as current users best.
Cheers, Frank
On 13-11-13 02:30 AM, Lex Trotman wrote:
[...]
How many "Geany on Windows" users are there? is it 90% POSIX/10% Windows? Or more? Less?
I'm a big fan of the "90% rule". If 90% of the users don't need/want it, don't implement or support it. Same goes for library versions: if 90%+ has GTK3, it's safe to require that.
Because Geany does not install spyware to see where it is used, we really don't know. :)
Various people make various guesses based on their personal experience, but really the people who know are only the users themselves.
I was thinking of asking on the users ML, after we agreed the questions here first. But do we want to?
It's a great idea but as you mentioned on IRC, we really have no way to know how representative subscribers to the users list are. For example maybe only X out of every X^Y Geany users subscribes to the mailing list, so even if we ask and N people say one thing, still the vast majority of users might be indifferent or completely disagree if they were asked/subscribed.
Are we looking for "market share"? Or are we interested in making the best software that suits the contributors, and if its useful to others fine?
Suiting the contributors/developers goes a long way in a project like Geany that is meant for users who themselves are also developers. What's more we have a mix of contributors on most popular *nix distros, Windows, even some using MacOS, and we all eat our own dogfood.
Thats a pretty deep and fundamental question about the project, what do those who are interested enough to monitor the dev list think?
My personal opinion is that in each new release we should try to support the then current versions of all platforms that our cross-platform toolkit allows us to support. I don't think we should do any more or less than that.
Cheers, Matthew Brush
Am 14.11.2013 01:18, schrieb Matthew Brush:
It's a great idea but as you mentioned on IRC, we really have no way to know how representative subscribers to the users list are. For example maybe only X out of every X^Y Geany users subscribes to the mailing list, so even if we ask and N people say one thing, still the vast majority of users might be indifferent or completely disagree if they were asked/subscribed.
Well... We got >100k installations on Ubuntu and Debian together (popcon). And at least about 10 Windows user (which are the ones I know) ;) On ML (user) we have about 500 subscribers IIRC the latest numbers.
Cheers, Frank
On 14 November 2013 13:51, Frank Lanitz frank@frank.uvena.de wrote:
Am 14.11.2013 01:18, schrieb Matthew Brush:
It's a great idea but as you mentioned on IRC, we really have no way to know how representative subscribers to the users list are. For example maybe only X out of every X^Y Geany users subscribes to the mailing list, so even if we ask and N people say one thing, still the vast majority of users might be indifferent or completely disagree if they were asked/subscribed.
Well... We got >100k installations on Ubuntu and Debian together (popcon).
If you would use my "90% rule" you'll need 11k+ Windows users to justify full support and the same experience across platforms.
You might also say that Windows-support must live in "contrib", and not "core" ...
Btw: 90% is just a random-ish number.
-H-
On Wed, 13 Nov 2013 10:59:47 +0100 Harold Aling geany@sait.nl wrote:
How many "Geany on Windows" users are there? is it 90% POSIX/10% Windows? Or more? Less?
I'm a big fan of the "90% rule". If 90% of the users don't need/want it, don't implement or support it. Same goes for library versions: if 90%+ has GTK3, it's safe to require that.
2ct.
But the 90% are not the same for everyone. 0.9 * 0.9 * 0.9 ~= 0.73.
On Mon, 11 Nov 2013 18:18:15 +1100 Lex Trotman elextr@gmail.com wrote:
- Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
I wish it could be so easy. The current (not published) spawn.c module is 840 lines with the tests. Some functions differ only by a few OS specific lines. Duplicating the entire functions is not acceptable, it'll add 300+ LOC, and the specific parts can't always be isolated in functions easily. C++ is helpful, because you have most of the current context in 'this', and the virtual methods are fast. But it breaks all derived classes almost every time a base class is changed, so it's no wonder that Scintilla is a static library. GObject, be it Vala or Zulu, means that you need run-time type cast each time you call a virtual method, and that may be a problem inside GSpawnSource.
BTW, glib/gtk+ does not have such separation for the most part. For example, glib-2.30/glib contains 142 "ifdef G_OS_", and gtk+-2.22.0/gtk contains another 151. Only gdk has full backends, but the reasons here are obvious.
Le 11/11/2013 08:18, Lex Trotman a écrit :
[...]
So I am starting this thread to try to get ideas on where Geany should be headed.
[...]
#N Seamless support for buffers with embedded 0 bytes
#N+1 Harder-to-break plugin API, maybe by hiding most things behind functions/accessors/setters
Am 15.11.2013 15:34, schrieb Colomban Wendling:
Le 11/11/2013 08:18, Lex Trotman a écrit :
[...]
So I am starting this thread to try to get ideas on where Geany should be headed.
[...]
#N Seamless support for buffers with embedded 0 bytes
How do you define seamless? There's a patch that lets geany open binary files and it works pretty well in my experience.
#N+1 Harder-to-break plugin API, maybe by hiding most things behind functions/accessors/setters
I agree. I would also say that improving the plugin API and making the life easier for plugin developers should be one of Geany's (or _the_) primary goals, given the stagnant (little man power, maintanance fears and it's generally hard to get stuff merged) for the core. This goal includes several pieces:
* harder to break API (as you have mentioned) * accessible through multiple programming languages * Bindings via GObject/introspection (this helps for both points) * Formalized deprecation process * Architecture to load plugins automatically/on demand, for e.g. filetypes plugins.
I would also like to see the strange way we export the API (via #define foo(...) a->b->foo(...)) sanitized. This might be even be required to achive some of the above points. We could easily use the linker to export/hide specific symbols in the geany executable. I think autotools have even built-in support for this. If plugins see the actual function prototypes (instead of defines) we can also more easily use optional GCC decorators, for example to have it warn on deprecated function usage.
With geany-plugins we do have a nice platform already for promoting and shipping plugins to users. Now we just need to make the actual process of writing plugins more inviting.
Best regards.
Le 15/11/2013 15:52, Thomas Martitz a écrit :
Am 15.11.2013 15:34, schrieb Colomban Wendling:
Le 11/11/2013 08:18, Lex Trotman a écrit :
[...]
So I am starting this thread to try to get ideas on where Geany should be headed.
[...]
#N Seamless support for buffers with embedded 0 bytes
How do you define seamless? There's a patch that lets geany open binary files and it works pretty well in my experience.
Lots of part in Geany assumes C strings, which are 0-terminated arrays. By "seamless", I mean that everything that deals with data from the buffer properly handles NUL bytes, e.g. not only that one can open and display them but also work with them just the same as if they didn't embed NULs. This shouldn't be too hard, but *really* tedious, probably needs API break or additins, and it's likely some parts gets forgotten.
Am 15.11.2013 16:10, schrieb Colomban Wendling:
Lots of part in Geany assumes C strings, which are 0-terminated arrays. By "seamless", I mean that everything that deals with data from the buffer properly handles NUL bytes, e.g. not only that one can open and display them but also work with them just the same as if they didn't embed NULs. This shouldn't be too hard, but *really* tedious, probably needs API break or additins, and it's likely some parts gets forgotten.
Will also need some work on plugin side, but its a long-running-wish-list-items to open also files with \0
Cheers, Frank
Hi All,
Just a note I am still summarising the thread, but "real life" is getting in the way. Real soon now (hopefully).
Cheers Lex
Le 11/11/2013 08:18, Lex Trotman a écrit :
Hi All,
[...]
- An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the parsers support symbols in anything other than the global scope, and adding them would significantly increase the parsing effort, but doing it in a background thread would make the performance hit less obvious. But there needs to be a careful design of the passing of data from the edit buffer to the parser and back to the symbol tables to minimise overhead, latency and ensure its non blocking. With such an architecture other complex functionality can then also happen in the background without impacting Geany's responsive feel.
Multithreading is a good thing, and we should indeed consider using it, and how and what could benefit from it.
But as a direct answer to the explanation, and after having made an attempt at moving tag parsing to a separate thread, it's *really* not that simple.
Actually, running the parsers in their own thread is quite easy. This requires copying the whole buffer, yes, but unless you lock the buffer (which at best would prevent editing during the operation, at worse freeze the UI), you basically have to make a copy. And this isn't so slow anyway.
But then you'll see that actually the parsers weren't the slow part, or at least not as dominating as you might have though. What I found was terribly slow was maintaining the workspace tag array -- and this is harder to move to another thread (though doable by copying it), because again locking is complex.
I'm not saying it shouldn't be MT'd, but that one shouldn't be naive about it (like I was): it basically requires a redesign of the Tagmanager.
- Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. I consider that these hang off the previous capability of better parsing/analysis of the program. Matthew has demonstrated a prototype that provides some of these facilities using libclang (for the clang languages only C, C++, Obj-c). But the current Geany architecture does not support plugging such things in easily, and with the number of languages that Geany supports, I would suggest that its small, light and fast tag would be severely threatened if assistance for all languages were plugged in at once.
Possibility for a plugin to more tightly integrate with completion, calltips and alike is one important thing if we want to get better language-specific support. And I think we do. Also allowing a plugin to add a new language (with parser, lexer, etc), would be great.
After, whether loading filetype plugins on-demand or not, I'm not so sure; plugins aren't so slow, and users could enable/disable the one they don't use. Auto-loading would probably be nice, but I'm not 100% sure it's worth the additional complexity and separation from "regular" plugins. To be considered though.
- Proper portability. At the moment Geany is really a Linux
application that has some limited (and buggy) support for Windows. The main editing widget that Geany uses is available for many platforms and toolkits. If Geany had an architecture that separated the target specific parts into a "backend" the way Scintilla does, then it would be possible to support multiple targets more easily, making Geany less at the mercy of one toolkit's direction (that means you deprecating GTK) and better able to support different platforms like OSX and Windows. Work such as that Dimitar is doing for spawning on Windows naturally then falls into such a backend.
Matthew summed up pretty well IMO. Although it looks like a good idea, I don't think it's a fit for Geany. And also, I believe that the UI toolkit should do that, but I guess none actually do as good as one could want.
- Multiple top level windows. As monitors are cheaper, being able to
spread views of files to optimally utilise the screen space available adds to the users effectiveness. Most languages support multiple modules in different files and many use multiple files for related parts, such as C/C++ header and body. Looking at and editing several places/files at once has many uses. As useful as splitwindows one and two are (especially together) they still assume a single rectangular top level is available for subdivision. But different desktop menu layouts or having other applications visible at the same time can limit the contiguous rectangular space available. Multiple top levels can make better use of non-rectangular space.
We already can run multiple Geany instances (but yes I know, there are side issues). For me the multi-windows thing would be a direct consequence of a proper "no tie between UI and document" thing -- that I hope we'll get some not so far away day. And maybe splitwindow2 helps at that (sorry, I still didn't manage to properly review this).
These are all big changes that don't fall into the current Geany mode of "light maintenance and extra features as someone implements them". For big changes like those above however, a clear design and a planned process is needed to ensure that the big changes don't clash with each other and that they are not derailed by interim smaller changes.
I would suggest the process to be:
- gather other major ideas for capabilities that Geany should plan to
support 2. develop a design that supports these (or at least the most useful ones) 3. look at how that design can be implemented, can the existing design be mutated to it, or is it a clean framework that large parts of the existing functionality can plug into, or is it a whole clean implementation. This also includes issues like languages to use (C, C++, Vala, Haskell etc). 4. depending on the outcome from 3. use a new repository organisation or at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
New branch is necessary -- in a separate repo or not. New repository without a new branch basically means a fork, and I guess Geany can't really afford that :)
This is something very different to the way Geany is currently operating, and I don't know if the community wants to consider such a more structured approach. If its felt that its worthwhile then I suggest that steps one and two are best achieved using the wiki and I will volunteer to set up and maintain page(s) for those phases at least.
I'm not sure how such a structured approach could work given the manpower and free-time-porject aspect of Geany [1], but it surely is a good idea to at the very lest try something and try to make it work. Thanks a lot for that BTW.
Regards, Colomban
[1] Though, one could hope that structured goals could attract more contributors, since they'd have something concrete they could help build -- as opposed to the usual "pick something you care about", it'd be "there's some things to do, help if you care to".
[...]
- depending on the outcome from 3. use a new repository organisation or
at least a new branch in the existing Geany repo to ensure that the existing Geany is not destabilised by major changes as they take place.
New branch is necessary -- in a separate repo or not. New repository without a new branch basically means a fork, and I guess Geany can't really afford that :)
Just to be clear, I meant another repo under the Geany organisation, since I suspect there will be more than one branch involved in getting to wherever we decide we want to end up and so it might get a bit messy if its all in the main repository. But it really depends on the what we end up deciding.
[...]
Regards, Colomban
[1] Though, one could hope that structured goals could attract more contributors, since they'd have something concrete they could help build -- as opposed to the usual "pick something you care about", it'd be "there's some things to do, help if you care to".
That was indeed one of my thoughts :)
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
