GTK+ is now the first major toolkit to depend on the Cairo vector graphics library which is designed to provide high-quality display and print output. Cairo will add 3 more dependencies to GTK: itself, glitz and libpixman (after atk, Pango, Glib, FontConfig and the standard X libs). The addition is now part of the HEAD of GTK’s CVS. Some might argue that Cairo should have been integrated to X instead (as an extension or as part of the core), so all toolkits would get the benefits, transparently (if enough engineering was to go into this). I sent an email to selected GTK+ developers last May about this, and here is what Owen Taylor, GTK’s project leader, replied: Update: GTK+ 2.6.2 released.
[…]
The work that Carl [Worth] has been doing at creating a really high quality vector graphics library is only a portion of the solution, yes, but it is a very important part. By adopting this into GTK+, Qt, Mozilla, OpenOffice, etc, we’ll share more code and everybody will render better.
In some cases this adoption will be under the surface and the user will just see better rendering. In other cases (and we plan to do this in GTK+) the Cairo programming interface will be exposed directly, so that we don’t just get more uniform rendering, we’ll also have a more uniform programmer interface.
You ask why Cairo can’t just be integrated into X at a low level and make everything look good. This doesn’t work because Cairo contains all sorts of concepts that just aren’t in the X currently. While the X API can say “Draw a rectangle”, Cairo can say “Draw a Bezier curve with 50 percent alpha and a radial gradient”. New and very different API is required to take advantage of these capabilities.
You ask why we need all these different backends, all these dependencies, all these different modules. While they may seem to make things worse for someone trying to get stuff built and playing around with it they actually will make a big difference getting this stuff deployed quickly:
– – Because Cairo supports multiple backends, I can use Cairo in GTK+ which needs to work on Windows and other platforms as well.
– – Because Cairo can be used with an unmodified X server, I can use Cairo in GTK+ as soon as Cairo is released, instead of waiting for all our users to get a new X server.
– – Because development is being done in a modular fashion, it can proceed in a much faster way; a Cairo release can be made without waiting for an entire new release of the X window system.
Yes, there is some temporary pain (which build scripts like jhbuild [gnome-building script] can make a lot easier), but in the long run, these packages will get incorporated into operating system distributions and users won’t have to worry about the number of individual packages someone building from source would have to download.
Regards,
Owen
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….
How does Cairo compare to Qt 4’s Arthur?
It is described here (in terms of future integration):
http://www.trolltech.com/products/qt/whatsnew.html?pfriend=yes
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
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.
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
Sorry Eugenia, GNUstep’s cairo backend is not a binding.
That’s how they are called by the Cairo web site: http://cairographics.org/bindings “Toolkit bindings”
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)
Integration? To me it seems there is much crossover of functionality between them.
> 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.
When will cairo be released or ready for use?
Well, apparently Red Hat thinks “soon”.
Well, apparently Red Hat thinks “soon”.
How do you know that? Can you copy me your url?
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 ?
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
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.
“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
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!
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.
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.
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.
> 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.
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 :/
> 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! 🙂
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.
> 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.
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.
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.
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
.
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.”
> As an end user, this does not benefit me.
Sure it does, guess how much memory you would require otherwise.
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.
<sarcasm>
ohhh and it’s better if everybody never use lib and rewrite everything …
</sarcasm>
# 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.
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.
> 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.
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.
“# 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.
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
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
@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.
> 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.
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.
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.
[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).
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.
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.
forgot autopackage and pacman. no insult intended.
How many are going to compile Gnome by hand anyway (gentoo doesn’t count). Patrick Volkerding perhaps?
exactly, and gnome even comes with scripts to make your life easier.
@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.
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.
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
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
@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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Why would not GTK include portable (Win32/X/MacOSX) API for tray icons?
I guess it rather should…
Rayiner, I thought Cario was based on SVG, not PDF?
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.
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.
[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 😉
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.
Besides speed increases, what benefits are there for end users? Will GNOME be able to take on an Aqua-style appearance?