[Geany-Devel] A direction for Geany

[Matthew Brush]

On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
> On Tue, 12 Nov 2013 17:47:26 -0800
> Matthew Brush <mbrush at 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 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?
>
> 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)

>>>>> 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.
>
> 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?

>>>> 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.
>
> 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.

>>>> 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?
>
> 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