On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800
Matthew Brush <mbr...@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?
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.
2. 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 :)
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 [...]
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?
5. 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 :)
6. 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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
