[Geany-Devel] A direction for Geany

[Matthew Brush]

On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
> On Mon, 11 Nov 2013 01:31:35 -0800
> Matthew Brush <mbrush at 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