[Geany-Devel] A direction for Geany

Dimitar Zhekov dimitar.zhekov at xxxxx
Tue Nov 12 18:43:28 UTC 2013


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.

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

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

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

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

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

-- 
E-gards: Jimmy


More information about the Devel mailing list