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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
