Re: GLIB, libffi and Windows




asking for "love" without giving anything back in return except
complaints after the fact is not conducive to a positive development
Check your facts. I am hard at work trying to get Win32 up to speed. I'm submitting patches when they are ready. I am doing a LOT of debugging, experimentation etc. I may not be able to fill Tor's shoes but I am very much hard at work making sure Win32 doesn't "lag".

environment. the GLib and GTK+ maintainers are not experts on Windows,
we said that multiple times; hackers with Windows experience should
join if they want to be represented.
Which is exactly what I am doing :P

The "creeping featurism" of what is supposed to
be a small, system abstracting library should be cause for concern.

I think you haven't been keeping up to the development of GLib in the
past decade. GLib is a platform library, and has been for a long
while. it's not *just* a small system abstraction library - or at
least, it's not just that any more.
You say potato, I say potahto. To me a platform library *IS* just an abstraction library. Sure it has a bit more "stuff" than just wrapping things like the differences in snprintf() implementations but a not-insignificant portion of GLib is just that: abstracting away minor system differences to create a universal platform. Something it does very well mind you.

I realize it is not the project's goal, but my *personal* agenda is to make Gtk+/GLib development trivial on Windows. Professionally, personally and religiously I'm a UNIX man, but one thing UNIX lacks is some of the better apps available on Windows. It may not change the world but if we can remove one more barrier to Windows developers being able to easily port to UNIX we may start seeing more of them. With Linux having a bigger and bigger market share it is becoming more attractive for people to consider porting to it, but not if that development costs major dollars, and having a platform that works equally well on both OSes drastically reduces that cost. It's worth bearing in mind when GNOME- or UNIX-centric decisions are made, that's all I am saying.

Kean


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]