[Geany-Devel] A direction for Geany

[Dimitar Zhekov]

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

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

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

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

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

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

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

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

-- 
E-gards: Jimmy