[Geany-Devel] A direction for Geany

[Dimitar Zhekov]

On Mon, 11 Nov 2013 18:18:15 +1100
Lex Trotman <elextr at gmail.com> wrote:

> 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, making Geany less at the mercy of one
> toolkit's direction (that means you deprecating GTK) and better able to
> support different platforms like OSX and Windows.  Work such as that
> Dimitar is doing for spawning on Windows naturally then falls into such a
> backend.

I wish it could be so easy. The current (not published) spawn.c module
is 840 lines with the tests. Some functions differ only by a few OS
specific lines. Duplicating the entire functions is not acceptable,
it'll add 300+ LOC, and the specific parts can't always be isolated in
functions easily. C++ is helpful, because you have most of the current
context in 'this', and the virtual methods are fast. But it breaks all
derived classes almost every time a base class is changed, so it's no
wonder that Scintilla is a static library. GObject, be it Vala or
Zulu, means that you need run-time type cast each time you call a
virtual method, and that may be a problem inside GSpawnSource.

BTW, glib/gtk+ does not have such separation for the most part. For
example, glib-2.30/glib contains 142 "ifdef G_OS_", and
gtk+-2.22.0/gtk contains another 151. Only gdk has full backends, but
the reasons here are obvious.

-- 
E-gards: Jimmy