[cairo] About cairo_show_text and UTF-8...

[Mike Emmel]

On 1/11/06, MenTaLguY <mental at rydia.net> wrote:
> On Wed, 2006-01-11 at 08:53 +0800, Mike Emmel wrote:
> > I'd say someth on the order of 10-30k i.e a pretty lightweight C object api.
> > A lot of the problem is in the fact you drag in all of glib to get GObject.
> > GObject itself get reject for use in projects often simply because you
> > need all of glib for GObject. I would think a mini-Gobject would stand
> > a chance of getting used more often. I know of no core libraries
> > outside of Gnome/GTK that use GObject mainly because of the size
> > issue.
>
> Maybe the thing to do is to subset glib, then?  Just enough to support
> GObject + Pango?
>

Thats part of it. Prob for glib the best would to break it out into
domain specific .a
that you could link int.
For GObject there is some support for caching pre allocated instances
and some other stuff that not absoultely required it may not be worth
removing just something I noticed in review.  Pango would benefit from
haveing the utf8 support as a .a  lib for example.
At them minumum for glib you need the type system and g_new.
I'm not convinced that the signaling/marshling system is absolutely
required for example.
It could easily be in its own .a file.

In any case if there was a reasonably useful subset that came in
between 10-30k as I  said before I really think a lot more people
would be willing to use GObject  in core libraries.  If compatibility
was maintained then you have the option of either static linking for a
small library or simply linking with the system shared libs or
potentially a custom shared library if supporting a few apps fore
example.

In a lot of ways its almost a matter of changing the build glib is
fairly well segregated so I'd be surprised if much code actually had
to move.
This is important for bringing GObject based libraries to
alternative/embedded systems.  I'ts a physchological thing for destkop
programmers since although they can build a small glib/gobject build
in a "real" deployment linking agianst the larger library just makes
sense but if it can be small it gives them warm fuzzies about using
GObject.

Pango is one case where it could be pretty useful on its own. Since
there are basically no other Gobject based libraries I know of that
would make good generic system libraries ( Because its use was
rejected )  its tough to know how useful this would be in general. But
if you make it small more people will use it if they do then it makes
sense to finally bring in the full library as a dynamic link.
GObject  would make it easy for example to build higher level wrapper
libraries around cairo. I can think of quite a set of libraries that
would benefit from having higer level unifying GObject based api's.

If glib/gobject were small then gdk ( not gtk) could be useful as a
foundation for a few custom ui toolkit that may be designed different
from gtk but easily compatible vi gdk.  I would think a small gdk with
custom domian speficif widgets would be useful in the embedded world. 
The size of gdk+glib+gobject is simply to much to compete agianst
doing a custom solution.  If you had a standard what to make a small
version of glib/gobject I bet I could clean up gdk enough to get a
total library around 150k. Gdk itself is about 200k or so if I
remember correctly  that would be pretty compelling for a lot of
people. One use case is that gdk would be enough to support writing
custom widgets in higher level languages like java python etc for
example you don't have to wrap gtk for this. Cairo is of course along
for the ride :)

Its a mental thing :)


Mike


> -mental
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBDxGYDcUNIGiXCc4MRAi9WAKCh5kAX7Oa65dSGT+tWnEYHBf22owCfbfDF
> Un/6MteBUqxuZAI6x8vE1wI=
> =IW+u
> -----END PGP SIGNATURE-----
>
>
>