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