http://www.osnews.com/story/9609/GTK_Goes_Cairo_Owen_Taylor_on_X_Cairo_GTK_Integration Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Thu, 09 Jul 2009 21:13:56 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread? http://osnews.com/thread? I have been waiting for a while that the toolkits will catchup to Cairo...
What many people don't know about Cairo, it is sort of a display PDF (a reduced one)
and can hook directly into OpenGL and other base frameworks (X is also an option)
So hopefully we can see soon a mssive increase in speed regarding GTK2 and Gnome, given OpenGL is working.... Fri, 04 Feb 2005 06:44:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? How does Cairo compare to Qt 4's Arthur? Fri, 04 Feb 2005 07:04:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? It is described here (in terms of future integration):
http://www.trolltech.com/products/qt/whatsnew.html?pfriend=yes Fri, 04 Feb 2005 07:08:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Er, I think I wrote cairo backend for GNUstep a year ago which is probably best at integration than any toolkit since GNUstep's display API is almost likely 1:1 translation to cairo's, but if you mean to use 'to depend' in the bad way, no GNUstep isn't depending on cairo Fri, 04 Feb 2005 07:37:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? There are many bindings for Cairo right now, we know this. However, that doesn't mean that they are "integrated/depended" to these toolkits though. GTK+ *is* the first major toolkit that has integrated Cairo, and no, it's not in a "bad" way. Fri, 04 Feb 2005 07:41:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Cairo is just a library which draws vector graphics using various backends (Glitz which rasterizes with OpenGL or an XRENDER backend, or a Win32 backend...).

It doesn't have any more to do with the X server than any other X client, so it couldn't be an extension. It could be part of the X distribution, if that's what you meant by "part of the core", but couldn't be part of the "core protocol"...

Of course, you could write a Cairo implementation inside the X server (and then have a protocol for it, etc). This would be pointless as we already have GLX.

--ralpht Fri, 04 Feb 2005 07:51:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Sorry Eugenia, GNUstep's cairo backend is not a binding. Fri, 04 Feb 2005 07:53:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? That's how they are called by the Cairo web site: http://cairographics.org/bindings "Toolkit bindings" Fri, 04 Feb 2005 07:55:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? More explainations, In GNUstep back-cairo, text system uses cairo to display glyphs, every native widgets also use cairo to draw line, frame, rectangles, bezier paths, every native visible thing (eg opengl doesn't count). Thus, we don't need a cairo binding, all the display code are cairo ready since the api are mostly identical (ie. GNUstep's display api is already subset of cairo's) Fri, 04 Feb 2005 08:03:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Integration? To me it seems there is much crossover of functionality between them. Fri, 04 Feb 2005 08:06:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > That's how they are called by the Cairo web site: http://cairographics.org/bindings "Toolkit bindings"

That's why GNUstep isn't listed there, it doesn't even let user know if they are
using cairo or not. There's certainly no Objective-C wrapper around cairo's api, ie. no binding. Though I am thinking exposing cairo's apis should be a good idea although we already have many similar sets of api including 2 sets of postscript-like and another one that tried to clone quartz's plus another level for Objective-C friendliness. Fri, 04 Feb 2005 08:12:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? When will cairo be released or ready for use? Fri, 04 Feb 2005 08:38:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Well, apparently Red Hat thinks "soon". Fri, 04 Feb 2005 08:42:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Well, apparently Red Hat thinks "soon".

How do you know that? Can you copy me your url? Fri, 04 Feb 2005 09:10:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I read people complaining about GNOME relying on on too many libraries. How will Cairo impact GNOME from a build and stability and deployment point of view ? Fri, 04 Feb 2005 10:03:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? How (will?) this impact on Mono??

I know that mono depends on cairo (and libpixman IIRC) and that this is quite a big barrier to installing mono/gtk# (for me on slackware at least). If all these library are to be included in default gtk+, will the mono guys be able to 'get at them' there??

Cheers!
--Robin Fri, 04 Feb 2005 10:09:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I am so tired of all these dependencies.
I have been using a LFS system for a couple of years and it is
starting to be a pain in the ass due to extensive dependencies. And why can't they just list what they depend on on their homepage. In the section dependencies only fontconfig and Xrender is listed. Why can't they just also list glitz and libpixman? And I bet that they also need a specific development version of both of them making it even harder to compile from scratch. I have one little request to all developers. Please use the major/minor/patchlevel versioning for your projects, it makes it so easy when compiling and hunting down dependencies. Fri, 04 Feb 2005 10:14:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? "Why can't they just also list glitz and libpixman?"

because they arent dependencies for anything but the cvs version. you are using LFS. so dont whine about it Fri, 04 Feb 2005 10:29:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? When will we see this in action? (When is Cairo expected to be released) And will these changes be immediately visible in DE's that use GTK (like gnome or xfce), or is further tweaking needed?

Will gnome/gtk apps appear more "snappy"? (One of the biggest complaints against gtk apps is their redraw time... will Cairo help fix this issue?)

I'm excited about cairo's release... they've been beefing it up on paper discussion for a while... it's great to see that it's become more tangible finally! Fri, 04 Feb 2005 10:44:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? There is no official release date for cairo yet, but they hope to get a stable(in the sense that api will be stable) version to match the release date of gtk-2.8.

Right now, there are waay too much optimizations to be done in cairo but it seems that it will be definitely faster than the good ol' gtk/xlib.(even when it uses xlib as its backend)

Anyway, the interesting backend of cairo is glitz, which uses opengl to do image composition and it is really very fast.

http://www.cs.umu.se/~c99drn/opengl_freenix04.pdf

So, if you have a somewhat-decent gfx card(I guess a GeForceFX 5200 should be more than enough, and it is already low-level market), and use GTK->cairo->glitz, things should definitely be much faster. Fri, 04 Feb 2005 10:54:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Great, this will delay the include of a print dialog in GTK even further. Couldn't they focus on the _realy_ important features first? This would mean no need for libgnomeprint anymore and so less dependencies. Fri, 04 Feb 2005 11:19:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I am not a Cairo developer but followed it from time to time. Some people raised the questions or concerns about to many dependencies.

As far as I understood, Cairo is a core X.org project and in the long run probably will replace huge parts of the xlib (maybe X after a period of time completely so that X is only a legacy), so the dependency in the long run will be not better or worse than the xlib but with major improvements in speed and rendering quality.

X with Cairo is moving into the direction of NeXTStep and MacOSX but without breaking the X11 legacy. Fri, 04 Feb 2005 11:42:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > So, if you have a somewhat-decent gfx card(I guess a
> GeForceFX 5200 should be more than enough, and it is already
> low-level market), and use GTK->cairo->glitz, things should
> definitely be much faster.
Problem: Where is the open-source graphics driver with 3D acceleration for this card? Running open-source on-top of closed-source drivers is pointless. Fri, 04 Feb 2005 12:01:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I am stupid, I know.. I see this thing stated in previous comments:
Cairo can run with an xlib backend.
Or with an OpenGL backend.
It could replace XLib.
It will speed up Gtk+.
It does not break Xlib legacy.
It has win32 backends.

So, my questions are:
Cairo is supposed to display vector graphics. It can cohoperate with X. Why should it be possible to replace X ?
It can use an XLib backend means it will use it if he can't find an opengl card?
On windows, it will use opengl if he can't find it or revert to gdi?
Since Xlib can be replaced with it, will Gdk disappear compeletely becoming just a thin layer over cairo?

I hate this mess :/ Fri, 04 Feb 2005 12:03:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > Problem: Where is the open-source graphics driver with 3D acceleration for this card? Running open-source on-top of closed-source drivers is pointless.

Interesting philosophical question. Try not to think too hard about it, or your brain will explode! :-) Fri, 04 Feb 2005 12:14:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? It can use an XLib backend means it will use it if he can't find an opengl card?

Not really. When drawing with cairo, you first specify the surface it should draw upon.

If you give a glitz surface but your gfx card does not have 3D acceleration, then glitz will report it to cairo and cairo will handle it in software. Fri, 04 Feb 2005 12:25:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > It can use an XLib backend means it will use it if he can't find an opengl card?
Yup. If some backend (for instance glitz, which does the OpenGL voodoo) refuses to work, the next one is choosen.
> On windows, it will use opengl if he can't find it or revert to gdi?
This will be handled by the glitz backend: It already contains code for OpenGL on Windows.
> Since Xlib can be replaced with it, will Gdk disappear compeletely becoming just a thin layer over cairo?
There is more stuff Gdk does, than just line drawing. It also abstracts Window management, which is quite different on X11 and Windows, so Gdk will stay, I guess. It just will forward some tasks. Fri, 04 Feb 2005 12:27:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Problem: Where is the open-source graphics driver with 3D acceleration for this card? Running open-source on-top of closed-source drivers is pointless.

Then you should wait for that open-source 3D card:)

Anyway, I don't see why "[r]unning open-source on-top of closed-source drivers is pointless.". Of course, I would much rather use an NVIDIA card with an open-source driver, but you don't always get what you want. Fri, 04 Feb 2005 12:28:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Well theoretically a high level framework like Cairo can replace X entirely... Given that I dont know Cairo well enough, I see following migration path.
The current X protocol is too talkataiv and too dependend on low latency times.

Moving the entire protocoll slowly to something with less overhead is desirable. NX does that by a combined streaming translation effort, which works quite well.
Another way probably once most toolkits are moved there would be to replace the X communication layer beneath X-Lib with a communication layer on a higher level (for instance beneath Cairo which uses higher level functions and thus reduces protocol overhead immensely) this layer still can revert to basic X once it runs situation not covered by itself.

I am sure the Cairo developers have thought along these lines as well by making the render controller pluggable. Fri, 04 Feb 2005 13:31:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Well gnome runs on a 6 month release cycle and typically plans to have a new release of gnome around the same time or a little there after the new releases of GTK. GTK 2.8 was just released say a month or so ago and gnome is about half way through their release cycle so i would guess that by gnome 2.12.x that gtk 2.10.x will be released which will probably be within the next 6-9 months, which is well ahead of longhorn so you have a few months to show this off to your friends and make them jealous . Fri, 04 Feb 2005 13:44:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I look at firefox. It currently depends upon 34 libraries, most of which come from different projects. And I ask myself why? As an end user, this does not benefit me. Actually, it makes my lifer harder because applications are harder to build (and I have never seen a Linux distribution with every package I wanted to try). It is also bloating Linux as much, if not more, than Windows and Mac OS X. Then again, Linux has been losing that battle for the better part of a decade. As for those of you who are hoping X will disappear -- it never will. Too much software depends upon it and too few developers are willing to say "well if I use this one function call from Xlib it will make the program independent of X, hance the user will have the choice to abandon it. Nah. That is too much work. I'm a lazy ass who has no pride in my work after all." Fri, 04 Feb 2005 13:58:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > As an end user, this does not benefit me.

Sure it does, guess how much memory you would require otherwise. Fri, 04 Feb 2005 14:09:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? apt-get install mozilla-firefox

there is no way you will ever tell me linux has "dependency hell" when i can install firefox with a single command in a few seconds, without every having to worry about the dependencies myself. Fri, 04 Feb 2005 14:13:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? ohhh and it's better if everybody never use lib and rewrite everything ... Fri, 04 Feb 2005 14:27:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? # apt-get install mozilla-firefox
apt-get: command not found

Keep in mind there's a world outside of Debian. Just that a few hundred people have racked their braines, how to install a binary package of "mozilla-firefox" onto a Debian system with one command doesn't mean that anyone is able to install GNOME. Fri, 04 Feb 2005 14:33:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? More dependancies result in:
- more total diskspace usage
- longer loading times
- more memory usage

Making GTK+ depend cairo did these three things. Congratulations!

On a side note, ATI has release specifications for radeon cards up to the 9200 series (which I have). Yet, it doesn't support composite acceleration. In fact, there's no opensource driver that accelerates composite as far as I know. Ain't that funny? The X developers depend on closed source drivers for their own software implementations. They can't write proper drivers themselves. Pathetic. Fri, 04 Feb 2005 14:46:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > Keep in mind there's a world outside of Debian. Just that a few hundred people have racked their braines, how to install a binary package of "mozilla-firefox" onto a Debian system with one command doesn't mean that anyone is able to install GNOME.


Then blame yourself. Use a distribution with proper package management (such as Debian or Gentoo), and soon you'll forget about that problem. Fri, 04 Feb 2005 14:49:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? There is a JPEG vulnerability in one of the Windows core libraries. Unfortunately, as a lot of apps embed the library[1] into the application all those applications had to be updated. Others didn't embed the library, but placed their own copy in the application folder. All of these had to be updated. However updates weren't always available.

Then there was the problem that a lot of apps installed their own copy of the necessary library in the core system folder when they were installed. This meant that if you updated your system, but then installed MS Office XP, your system would become vulnerable again[2]. Microsoft had to put a checker tool on their website to help people out.

By using separate shared libraries you get five benefits
1) If a bug appears in a library it's easy to for the user to patch it
2) Memory usage is significantly reduced, as the OS only keeps one copy of the library in memory for all the applications that reference it.
3) Disk space is significantly reduced, for the same reason as (2)
4) Programmers can write programs faster by using existing libraries
5) Programs that use libraries should run faster. The people that work on the library are experts in that area; the application programmer usually isn't, but by using an expert-designed library they gain its speed and efficiency advantages

Lastly, most decent distributions have a system for automatically resolving dependencies, using graphical programs, so the ease-of-use point doesn't really matter. If you're building from source, or using third-party packages, well then the onus is on you to make sure your able for it.

----------------------------------
[1] Embedding a library in the application is called static linking.
[2] I think Windows XP's System File Restore can fix this if you set a restore point after installing the library upgrade, but from what I've heard it's meant to be quite complex, who wants to do a restore after installing every piece of shareware. Fri, 04 Feb 2005 14:51:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? "# apt-get install mozilla-firefox
apt-get: command not found

Keep in mind there's a world outside of Debian"

all mainstream linux distributions include a auto dependency resolver. it might be apt-get, apt4rpm. smartpm, yum, up2date, slack-get or urpmi. doesnt make a difference at all as far as managing dependencies are concerned.

"More dependancies result in:
- more total diskspace usage
- longer loading times
- more memory usage "

these three are flawed assumptions. if the dependencies are small then they wont increase diskspace. gdk being replaced by a smaller cairo backend decreased disk space usage

longer loading time is subjective. if every application included its own copy, then loading time will increase too

memory usage usually goes down when libraries are shared. Fri, 04 Feb 2005 14:53:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Is it me or does alot of what cairo seem to want to do seem very familiar to the EFL? EVAS and imlib2 can any of the devs comment on this. ie: the major differences Fri, 04 Feb 2005 15:05:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? EFL isnt as much supported as cairo is currently and is not based on 1:4 model afaik. moreover cairo can switch backends transparently and is better integrated with gtk HEAD. cairo also takes advantages of the other x.org extensions in a tightly integrated manner. the next x.org and gtk releases are going to basically redefine the core graphics model Fri, 04 Feb 2005 15:08:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? @Anonymous: the problem with shared libraries is they are not shared very well. Every developer has their own favourite widget set or library to handle terminal I/O, so sharing resources doesn't amount to very much. This is even more true when you consider that shared libraries must be designed for the general case. There is a tonne of stuff in these libraries goes unused on most systems.

Furthermore, your claims do not hold water in an empirical sense. Software developed in the past had to work with much tighter memory constraints. That is to say that the typical computer 10 years ago had 64 times less RAM and about about 64 times less disk space. If you tried to run modern software on a 10 year old machine, you would find that you could not. It is not as though there have been huge leaps in functionality either.

@omnivector: what you say works well *if* the package exists. But let's say you want to use xephem in Debian. I had the 7 CD set on me when I installed Debian on a friend's machine the other night, and xephem was nowhere in sight. So to install xephem, I would have to fetch download the source and compile it myself. Now xephem requires motif. There's not much of an issue there because Debian has it. But I need the lesstif-dev package as well (to compile xephem). As you can see, I'm already doing package management and lesstif is a simple dependency (compared to gtk+).

Now, you may argue, xephem is an esoteric program. After all, how many people want to view the night sky. Fine. Then imagine a user who wants to use the latest version of a particular package (e-uae, for example, because it is currently under rapid development). The latest build will NEVER be in the Debian archives because making a package takes too much time. But the latest version of e-uae also requires moderately recent versions of of autoconf and automake. Here I am managing dependencies again. And the worse bit is, managing dependencies for packages which already exist tends to break the package manager -- so you end up managing dependencies for everything.

Nice try though. I've used Linux for years and know what its pitfalls are. That doesn't mean that I don't like it. It just means that I'm being realistic about it. Fri, 04 Feb 2005 15:50:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? > Well theoretically a high level framework like Cairo can
> replace X entirely... Given that I dont know Cairo well
> enough, I see following migration path.

X is a network protocol, Cairo a rendering engine. How can
Cairo replace X if not by writing a Cairo protocol? How
would it be different compared to writing a Cairo extension
of the X protocol?

> The current X protocol is too talkataiv and too dependend
> on low latency times.

It is not. These are a client issues. A Cairo protocol,
written for scratch, would hardly be more efficient than
a Cairo extension of the X protocol. There is nothing bad
in the X protocol, as long as it is used appropriately,
believe me ;-).

/Gian Filippo. Fri, 04 Feb 2005 15:57:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? It's called, "dynamic linking", and any moron worthy of booting a decent OS could figure it out with the readelf command in seconds and even someone completely unworthy can avoid it entirely by using any one of many gui's, sticking within a distro, or even less such as autopackage, zero-install or click-and-run.
X is so awful that every other windowing system is trying to catch up and emulate it's core feature set and design from the 70's.
X can fit in under 32megs of flash including a copy of linux, I don't see any problems with it either. I think all this consternation may be due to the speed of open source development vs. a trainload of venture capital development combined with a rather childlike and impatient audience. Fri, 04 Feb 2005 16:13:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Cairo won't replace X. X will use Cairo. Just check out the Xgl project that is in the x.org cvs, and look for it in the archives. Fri, 04 Feb 2005 16:16:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? [quote]... and use GTK->cairo->glitz, things should definitely be much faster. [/quote]

Is that really what you believe? I hope you're right, but I definitely don't believe so, but I'd like you to convice me. Cairo should be way more complex than GDK's painting mechanism and text performance for glitz could be problematic.

Nevertheless, cairo is a great library and there's a strong need for many projects for a high performance vector graphics library. Let's hope cairo does a good job in terms of flexibility (little doubt) and great performance (way bigger doubts). Fri, 04 Feb 2005 16:17:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? bitch bitch bitch.

is anything ever good enough for you.

or is it only when the developers have precisely the same priorities as what you want.

ever hear the phrase "lend a hand"

you just expect to eat for free, then complain when the steak is medium rare instead of rare. Fri, 04 Feb 2005 16:18:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? then try urpmi mozilla-firefox, or yum install mozilla-firefox, or run YaST and look for it, or Click 'n' Run, or swaret, or whatever package manager Xandros is using. And if none of them work, you've only got yourself to blame for using a crappy distro. Fri, 04 Feb 2005 16:30:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? forgot autopackage and pacman. no insult intended. Fri, 04 Feb 2005 16:32:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? How many are going to compile Gnome by hand anyway (gentoo doesn't count). Patrick Volkerding perhaps? Fri, 04 Feb 2005 16:44:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? exactly, and gnome even comes with scripts to make your life easier. Fri, 04 Feb 2005 16:50:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? @Eugenia: farm boy is right. GNUStep was the first toolkit to integrate Cairo (in two seperate efforts, IIRC). Indeed, it's more integrated into GNUStep than into GTK+, because in GNUStep, the native drawing APIs use Cairo, while in GTK+, you've got kind of a bolt-on mechanism where you call a special function to enable Cairo rendering on a GDK drawable, but the actual GDK drawing routines don't use Cairo.

@Ezekiel683: EVAS and Cairo are very different. The former is a retained mode API that (at the moment), only specifies raster operations. The latter is an immediate mode API that specifies mostly vector operations. Both use OpenGL, but after that, they diverge.

@Werner: Cairo really can't replace X. It's just a drawing API, it has no concept of windows or window management. It has drawing surfaces, and these can be anything from an in-memory data structure (Postscript), to an OpenGL context (Glitz). Without a window system, it can't display anything. What Cairo will likely do is supplant the X drawing APIs. In future Cairo-based system, the X server will concern itself mainly with handing out window buffers (via Composite), either as GL contexts to Glitz or as XRender drawables, and will handle window moving, resizing, etc. Text will be handled fully client-side, via Pango (or Scribe or whatever), as will graphics, via Cairo or Arthur. In a way, this is very similar to what OS X does currently, except that this mechanism will retain X compatibility. Fri, 04 Feb 2005 16:51:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Actually, it you'd stop for a second and actually learn about what Cairo is you'd know that one of it's features is optimizing for display on the screen and in print. Cairo isn't going to the delay the flippin' print dialog; it's the basis of it. Fri, 04 Feb 2005 17:00:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? The latest build will NEVER be in the Debian archives because making a package takes too much time. But the latest version of e-uae also requires moderately recent versions of of autoconf and automake. Here I am managing dependencies again. And the worse bit is, managing dependencies for packages which already exist tends to break the package manager -- so you end up managing dependencies for everything.


Give portage a try. You can probably install it in debian too.


john@newkid ~ $ USE="-*" ACCEPT_KEYWORDS="~x86" emerge e-uae -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild N ] games-emulation/caps-20040303 316 kB
[ebuild N ] app-emulation/e-uae-0.8.27 -X -debug -gtk -ncurses -sdl -svga 1,103 kB

Total size of downloads: 1,419 kB Fri, 04 Feb 2005 17:13:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? More dependancies result in:
- more total diskspace usage
Incorrect. Increased dependencies result in reduced diskspace usage, as other programs do not need to duplicate the code. GTK and QT can now share a portion of their codebase, so when you have both on your system, you are now saving space.
- longer loading times
Incorrect. When using shared libraries, when mutliple programs laod the same library, it still only needs to be loaded into memory once. That means the loading time will be reduced as it will have to do less disk seeks.
- more memory usage
Incorrect. The library only needs to be loaded once into memory when multiple toolkits, programs, or whatever are using it. This results in a decreased memory usage.

Making GTK+ depend cairo did these three things. Congratulations!
Incorrect. GTK+ depending on cairo with the glitz backend should provide a small speed boost as it uses OpenGL for rendering. Additionally, making GTK+ depend on Cairo allows for more features to be added to GTK+, such as improved generation of screenshots, printing from applications in Gnome, and so on.

Wow, you are 4 for 4 incorrect! Please look up what you're saying before you post it in the future Fri, 04 Feb 2005 17:28:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? @Anonymous: I'm fairly certain that people are familiar with the benefits of libraries in theory, but it is a very different story in practice. In practice, if you have three different programs, there is a very good chance you are using three different libraries. To be more accurate, there is a good chance that you are using three different sets of libraries.

Now it is all fine and dandy to say, "well just use gtk+ OR just use qt based applications." But real life doesn't work like that. I like vim (ncurses). I like slrn (slang). I like xephem (motif). I like firefox (gtk+). I like xfig (xaw3d). Yes a few of those libraries are shared with other programs (eg. xpdf and xephem use motif), but is the point of actual returns going to be two programs? I doubt it. Libraries are usually far too general to just be applicable for two applications. That is what contributes to bloat.

Now we are adding extra layers to gtk+. That means MORE bloat, not less. That means gtk+ is going to be harder to build when you do have to build it (some of us use more exotic hardware and distributions). Just because someone says that I can use gentoo to build the latest version of e-uae doesn't mean that it will magically fix all of the problems for everyone. They simply fixed ONE problem for ONE person. (Not only that, but I frequently use the CVS version. Does Gentoo help with that?)

Dependencies are complexity. Complexity means more potential points of failure. So unless you reduce complexity, you are just asking for problems. Fri, 04 Feb 2005 17:46:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? People can't quit complaining can they. For ages people complained about X, and now that there is an extra dependancy in "my build everything from scratch" path. Jeeze, grow up. Now that the X.org devs and GTK+ devs really have their stuff together, and are working on making things you complained about in the past disapear, what do you do? Bitch more. It's a work in progress, and in the migration time there will be more legacy things to support, DEAL WITH IT. If not go back to using your Xfree 3.x series and your xlib apps, otherwise quote bitching. Fri, 04 Feb 2005 18:12:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Wouldn't it be more intelligent to include a widget set in the X Window Manager? I mean, creating standards makes living easier, for developers _and_ users. Fri, 04 Feb 2005 18:17:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? You know, if they had decided to put a widget set in X, we would all be stuck with Motif today... C'mon, even Microsoft doesn't tie the widget set into a core system protocol. Over the years, and between their product lines, Microsoft has had a number of different widget sets, as has Apple. When you put something into a core protocol like that, it's not coming out, ever. Compatibility concerns simply won't allow it, and in the computer market, compatibility is king. Why else do you think nearly every PC is using a decades old architecture that has been hacked and patched to bring it kicking and screaming into the early 1990s? Because of this, the only sane thing to do is decouple something like a widget set from the core protocols of the OS, because when the next big thing comes along (and it will), it'll be easier to replace it. In retrospect, it would have been great if X had included even *less* stuff in the core protocol. That way, we could've ditched the antiquated X text and graphics APIs a long time ago. No point in making the same mistakes twice. Fri, 04 Feb 2005 18:23:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Yeah, you're probably right.

But I don't really like the way Linux (and UNIX) handles things. There are 3 (if not more) different sound systems I have to support (as a developer), 2 big widget sets, and all this. And here it is: there's mainly no compatibilty because everyone thinks "I'm gonna do it better". That's cool, and choice is a good thing, definately, but why can't standards for all these things be developed?

There's only 1 real, accepted standard for XHTML, for example. If anybody wants to make it better, he talks to the w3c. That's the way I'd like it to be in Linux. Fri, 04 Feb 2005 18:37:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? There are several sound systems in Windows too, and several widget sets. Heck, even on MacOS there are significant differences between Cocoa and Carbon. The only OSs that can afford to be "standardized" are the ones that have userbases too small to sustain multiple standards. With regards to XHTML, the web is something different. It simply wouldn't work without some common standard (although, even on the web browsers implement standards very differently), while multiple toolkits do work in an OS, you're just forced to pick one. Fri, 04 Feb 2005 18:45:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Yes Mac OS has at least two distinct programming environments, but it is a far cry from the Unix world where there are about half a dozen significant widget sets and dozens of less signficant ones. And the sad part is, they will never go away because there are old programs which are no longer being updated, and some old programs are being updated but the developer doesn't see the value in switching to a new widget set.

To be frank, I could really care less about the widget wars because most of the old applications and widget libraries are fine in my books. Except there is one snag: the web browser. I use gtk+ for firefox *alone*. That means firefox litterally used more memory and more disk space by an order of magnitude or two. Other attempts at web browsers are nice (I'm using elinks right now), but they usually fail to be compatible. Fri, 04 Feb 2005 19:33:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I think things are going in the right direction for Gtk. With the moving of gnome stuff to GTK and now much better rendering things are looking up.

Now I want to know about the similarities with PDF. Is it actually a subset of PDF or just kinda like PDF. Obviously if it was PDF that would be very nice. Fri, 04 Feb 2005 20:53:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? It has been asked befor AFAIK, but I haven't seen a straight answer...which is of pretty difficult I guess , but:

When will we see this incredible cool thing in gnome? In other words: when will gtk 2.8 be released?

Yes, I know I'm impatient. GTK 2.6 is just released and will be in gnome 2.10, I know Fri, 04 Feb 2005 21:24:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? It uses a PDF-like imaging model, just like Quartz. Specifically, it has bezier vector paths, the outline vs fill distinction, and Porter-Duff compositing operators. In the Cairo architecture, PDF is just another backend. So the PDF backend works by outputting PDF commands in response to Cairo API calls, just like the OpenGL backend works by outputting OpenGL calls in response to Cairo API calls. Fri, 04 Feb 2005 22:12:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Why would not GTK include portable (Win32/X/MacOSX) API for tray icons?

I guess it rather should... Fri, 04 Feb 2005 23:36:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Rayiner, I thought Cario was based on SVG, not PDF? Sat, 05 Feb 2005 11:43:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? I laugh when I see people complaining about dependencies.

Dependencies are a good thing, because they mean that there is code reuse happening, and people aren't reinventing the wheel with every piece of software that pops up.

There is only one situation where dependencies are bad, when the dependency is introduced with no strong reason. We occasionally do see this, for instance in GNOME, where some stuff depends on Bonobo (and then Bonoboui, ORBit, and a sh!tload of other libs) with no good reason. I mean, I guess it would be useful to have an image viewer as a reusable Bonobo component, but Bonobo is crap and that isn't happening, so we are stuck with megs of useless cruft.

Well, that is clearly not the case here, as Cairo will bring visible and important benefits to GTK and every app that sits on top of it. So why care about 3 more dependencies?

Anyways, in either case, the distro should resolve dependencies automatically for you. If it doesn't and you are annoyed by dependencies, you are clearly way over your head.

BTW, people should try to build some of the (previously) proprietary programs that are out there from source, and see what pain really means. And they sure have dependencies, but they don't show when you are installing them on Windows with InstallShield, because they are wraped up with the binaries. On FOSS, the same result is accomplished with YUM, APT, URPMI, ... resolving them automatically at install time. Sat, 05 Feb 2005 15:55:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? but Bonobo is crap

Huh? I remember reading about it the other day and it was supposed to the best thing since monkey or something. Well, maybe it was a couple of years ago. Maybe three. Sat, 05 Feb 2005 17:22:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? [QUOTE]
I look at firefox. It currently depends upon 34 libraries, most of which come from different projects. And I ask myself why? As an end user, this does not benefit me. Actually, it makes my lifer harder because applications are harder to build
[/QUOTE]

Umm.. sorry, but if your building firefox from source, your not in an "end user" catagory. My mum is an end user.. she clicks on the firfox icon and uses it, but does not build it ;-) Sat, 05 Feb 2005 17:37:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? But I don't really like the way Linux (and UNIX) handles things. There are 3 (if not more) different sound systems I have to support (as a developer), 2 big widget sets, and all this. And here it is: there's mainly no compatibilty because everyone thinks "I'm gonna do it better". That's cool, and choice is a good thing, definately, but why can't standards for all these things be developed?


Very true, but I really dont't think the problem is the number of widget sets but rather that they look and feel different to the end user. E.g. if you use QT in windows your app will still look like all other windows apps why can't it be like that in X11.

The selection of toolkit should be a choise for the programmer, the choise of look and feel should be a choise for the end user. If the user wants gnome he should be able to put a skin over KDE/QT apps so they looks like gnome or vice versa. Sun, 06 Feb 2005 02:07:00 GMT donotreply@osnews.com (Anonymous) Comments http://osnews.com/thread? http://osnews.com/thread? Besides speed increases, what benefits are there for end users? Will GNOME be able to take on an Aqua-style appearance? Mon, 07 Feb 2005 00:15:00 GMT donotreply@osnews.com (Anonymous) Comments