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.