Slashdot Mirror
Miguel Delivers State of Gnome Address
Skeezix writes "Miguel de Icaza has delivered the State of Gnome Address in which he gives an excellent summary of the current state of Gnome, what is being worked on, what the future looks like, and how you can help."
The recent announcement of Apple included some very amazing
screenshots of what they could do with their technology. I was
impressed by it for the first two hours, until I realized how easy it
would be for us to actually pull a hack like that.
Although the fully-transparent system can be done with little
effort (as we have a very powerful infrastructure to achieve it: Raph
Levien's libart) a lot of work has to go *first* into making GNOME
easier to use, more intuitive and more easy for newcomers.
If you've seen the screenshot he is refering to that is a pretty impressive statement. Gnome is and is going to be an extremely advanced application framework. But as Miguel points out, there is much work that needs to be done now to make the Gnome Desktop ready to take the world by storm. And no matter who you are, there is something you can do to help.
----
Celebrate the finer things in life
If you're referring to the problem of netscape crashing on any page with some java on it...look at http://help.netscape.com/kb/consumer/19990807-8.ht ml
It now works for me 100%
2^n++ * 0.01 cents for you.
This should be "clients can drive the parsing process instead of the parser taking control." This is really cool when you're trying to parse XML and HTML streams from potentially blocking input streams, such as the network. Props to DV for doing this!
LILO boot: linux init=/usr/bin/emacs
While I have no reason to doubt what you say... I'm gonna stick with KDE for a while. I was totally disgusted with the quality of Gnome/E that shipped with my RH6.0 cd. I love the way it looks but it was not a release product.
One of the main reasons I choose Linux over everything else was because it WORKS. I don't care how *pretty* it is, it must WORK FIRST, everything else is secondary.
While KDE looks kinda klunky, it's as STABLE as a rock and I've grown to like it over the past 6 months.
I don't give a hoot what kind of new technology they are working on if it blows core all over the place and I'm never sure which mouse click will be my last.
That said...I will give it another try, but only after they release a *stable* version and I see many positive reviews stating that it works.
*pfffffft*
:)
That was the sound of water being expelled from my mouth and onto my computer's monitor at a high velocity after reading the above post.
As someone who uses both Gnome, OpenWindows and CDE regularly (on Intel and Sun workstations), I have to say that, on all accounts, Gnome is by far superior. Much more so when it behaves differently from both OW and CDE than when it behaves like those.
Sure, there's Lesstif, and there's probably a few dozen Free CDE clones around. But a lot of excellent work has been done on Gnome, to the point where it can be considered far superior for worstation use than CDE. As for porting current apps to Gnome, Lesstif makes it perfectly possible.
There isn't even the usual excuse of "eliminating duplication of effort". As long as we're writing software on our own, let's try to go beyond what has already done. I mean, look at what happened the last time someone tried to write an Unix clone
To the editors: your English is as bad as your Perl. Please go back to grade school.
Come on, of course it's trivial to add transparency to the desktop if you have a rendering system that supports Alpha channel. Windows 2000 even supports this, and there are little utilities that let you turn transparent windows on and off. Miguel would be sadly mistaken if he thinks this is all he has to add to GNOME to compete with Apple, or even Java2. Enlightenment/imlib already provides transparency in themes, but they provide *zippo* support to apps that want to render say, a 300DPI illustration.
What Miguel is missing is that Aqua is not about transparency, it's about Quartz, the Display-PDF rendering system. The NeXT display postscript system and Sun's NeWS could also handle alpha easily, but does anyone think that the only useful feature of Display Postscript or Quartz is being able to render alpha?
Systems like Quartz, DPS, and Java2D are resolution independent, support anti-aliasing on everything, full affine transformations for everything, virtually all compositing modes you can think of, built in ability to stroke complex shapes, like lines using arbitrary thickness, fill, dash-pattern, and endcaps. For instance, with Java2D it's almost trivial to write a postscript/pdf/svg renderer because the base library is so powerful.
Miguel's solution might resemble Aqua's transparent windows, but without a real 2D rasterization engine, GNOME apps will never approach the flexibility of Quartz apps in rendering. In fact, he won't even approach the quality of Aqua's nice warping/scaling of images with aliasing artifacts.
What I really hate is this not-invented-here tendency to automatically superficially evaluate and dismiss other people's technology without even doing 10 minutes of research besides looking at screenshots, and then making public assertions about how trivial it is, and how much better your "solution" will be.
Clearly, Linux's GUI toolkits need a powerful comprehensive resolution independent 2D API to support powerful display and printing apps. The current mode of separating the display and printing APIs is a pain in the ass to develop for.
The best innovations are built on the shoulders of others, and if Miguel would spend more time learning and stealing technology from Apple, Microsoft, and even the KDE team, and less time dismissing everything and trying to reinvent it, maybe GNOME wouldn't be so buggy and unusable.
> Alpha channel support is already in CVS as implemented as a part of GDK-pixbuf.
What exactly does this mean? Why aren't my
widgets translucent? Oh, you mean as part of
the canvas. Well, that's different. Cool, but
not quite the same.
Just because it's in CVS doesn't mean it's done,
or useful for what we're talking about.
> However, to achieve a fully hardware
accelerated alpha channel would require a extention to the X protocol, which the Xfree team is very intrested in,
Hmm. Some of the developers were asked about
that very thing, and they said: "that's what
opengl is for". In other words, they weren't
keen on the idea.
And that's only a part of the puzzle. There is
a whole lot more to Quartz than alpha blending
(generalized compositing, transformations, raster
based post-processing effects like the drop
shadow). Are you going to put all that on the
server?
> and might be eventually based on the current code, if the code is re-released under the X license. There are anti-aliasing widgets for gnome, ala Gnome-Canvas, but it is no where as low level as quartz.
Exactly. Quartz has a single rendering model
with compositing, affine transformations, etc,
for the entire system. No canvas/windowing
system/window manager/widget set boundaries.
Which is why they can do that, and gnome can't,
without a significant amount of work at this
point. And no, a quick hack to make translucent
menus doesn't count.
(that's a thinly veiled challenge, gnome folks!)
>However, to laugh at X is arrogant. Yes, it is ancient, but the protocol was well designed for networks, and it is very extensible.
Well, they call it their PDF rendering model
in Macosx, but that's basically an updated
version of Display Postscript. Which could be
easily serialized across a network. It might
be dog slow, but so would X with that kind of
eye candy, and with DPS you'd have a whole lot
more room to optimize lowlevel stuff on the
server side (like compositing), WITHOUT adding server extensions.
Sorry, X can probably be patched and patched and
patched to get it to do what people want, and it
will probably work pretty well, but it won't be
pretty. Better maybe to start over?
Peter
Currently GNOME lacks a bit of polishing when it comes to the end desktop because we do not ship a good set of presets for it. Shipping good presets and revamping the user interface (as suggested by our user interface team at http://www.gnome.org/gnome-ui) is a really important task.
The real URL is at http://developer.gnome.org/gnome-ui.
The great thing about developing interfaces with GNOME is the libglade architecture. Designing an usable interface is easier if you can rapidly design it in such a program and if you can tweak and revise it at runtime.
-- adraken
As others have pointed out, this stuff must be in the X server (display server) since to be effective it should be hardware accelerated. The only project which comes near this is GNUStep with Aladdin's Display Ghostscript project. If I remember correctly, the DGS will be an X server extension for the client side widget libraries, so for those X servers with DGS support GNUStep will have hardware accelerated Display Ghostscript -- just what you seem to require.
Of course, the GNUStep project has taken a long time to mature... but they seem to be nearing completion of their core libaries and DGS code, leaving application support left. Since their libraries are close enough to MacOS X and the old OpenStep specification it should be fairly easy to port between the two.
I like GNOME a bunch, but honestly I loved my old NeXT CUBE a whole bunch more. I'll happily buy a PowerMac G4 if MacOS X turns out as nicely as my old CUBE did...
Finally, RE: junking X altogether instead of extending the X prototcol... I'm in favor of keeping X and just extending the protocol. We have such a large application base locked up in X that to toss X would be to throw the baby out with the bathwater. X is crufty, and could use a core protocol update, but it's also still good enough for most every day work. We need to either update the protocol (yeah right, like the Open Group is going to bother), or extend it server side.
I'm under the impression that the XFree86 team is having some legal (patent) issues about including TrueType support directly in the newer XFree 4 X server, which is why they're going to only support TrueType font servers. If this is true, then that's another good argument for pursuing a Display Ghostscript model and dumping TrueType support altogether.
Cheers,
Xlib