[Geany-Devel] Let's use Vala

[Matthew Brush]

On 13-11-12 07:50 AM, Frank Lanitz wrote:
> I cannot add much to the vala yes/no question, as the only part of ala
> I've seen by know are Matthews's plugin in g-p. Two or maybe three
> things are important to me, in case of:
>
> - Geany needs to keep its small memory footprint

Yes, I don't think there'd be an appreciable[1] extra amount of memory, 
it uses all existing libraries we have loaded in memory anyway, and Vala 
has special annotations and stuff to tailor the generated C code for 
when you need to optimize for special cases.

> - Created code needs to run on all plattforms Geany currently is running
> on -- At least I know of *BSD, Solaris,, MacOS X, Windows, Linux and we
> need to stay compatible with curent stable versions of SLES, RHEL etc.
> which means at least RHEL 5.x and SLES 10. Also at least for the next
> year we need to keep on running on Debian Squeeze also.

Yep, it's just GObject code, so anywhere GTK+/GObject runs, the code 
compiled out of Vala should run just the same.

> - There needs to be a final, let's call it C-only-release (well, having
> 1.24 in some would be a good idea anyway)

+1.

> - g-p should keep on running: We got a lot of badly maintained, but good
> used plugins. If a major rewrite is needed for them, I doubt it will be
> done for a huge number of.
>

Not strictly related to Vala but more to the other thread, I doubt this 
is feasible/possible with upsetting the plugin API to some degree, given 
the scope of the changes being discussed there[2]. On the bright side, 
with the possibility of exposing the plugin API to higher-level, more 
user-friendly languages (via generatable bindings and such) we could see 
a boon of nice new plugins, written in much more maintainable languages, 
by a more diverse class of developers, and much less ability to bring 
Geany down to a crashing halt with one little pointer mishap :)

Cheers,
Matthew Brush

[1]: Of course this is subjective but even just something like using 
GTK+3 build probably dwarves anything introduced by some additional 
GObjects generated out of Vala.

[2]: Since so much of Geany's guts/implementation is exposed directly, 
it'd most likely be impossible to make any non-trivial 
changes/re-factorings without disturbing the plugin API. And even if we 
aimed to keep the plugin API mostly stable during the changes, we'd 
probably end up with maintenance nightmare of all kinds of old backwards 
compatibility wrappers and such.