On Mon, 11 Nov 2013 18:18:15 +1100 Lex Trotman elextr@gmail.com wrote:
- 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.