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."

3 of 172 comments (clear)

  1. Re:I can't help but wonder... by Kaufmann · · Score: 5

    *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.
  2. Apple Aqua NOT JUST Alpha transparency by rcromwell2 · · Score: 5

    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.

    1. Re:Apple Aqua NOT JUST Alpha transparency by rcromwell2 · · Score: 5
      Miguel is intelligent enought to know we're not just talking about alpha channeling. He was saying that libart provided the necessary tools. In case you are unaware, libart is a library for high-performance 2D graphics. It is the antialiased rendering engine for the Gnome Canvas. It supports a powerful imaging model which is basically the same as SVG or Java2D. It does Vector Paths, Bezier Paths, RGB and RGBA images, Sorted Vector Paths, MicroTile Arrays, and Affine transformations.

      That would be true, if libart really did match the functionality of DPS or Java2D, but unfortunately, a quick look at the API in the header files shows that not only is it insufficient, but it also looks like a very difficult API to use in the first place.

      Consider the following task: Fetch the glyph for the letter 'S', convert it to a bezier path, shear it by 0.3, 0.4. Set this stroke as a clipping path. Next, render the word "Linux rulez", scaled by 2.0/2.0, applying a a gaussian blur kernel to the output (for dropshadow). Next, re render the text with a radial gradient fill overtop of the background. Finally, fetch a penguin icon and render it overtop of the 'I' of the text with 0.3 alpha.
      Of course, all this must be antialiased and rendered pixel perfect. Next, render this in a variety of output formats including:

      1. grayscale
      2. monochrome (1-bit)
      3. ARGB
      4. BGR
      5. palette mapped

      Not only can't libart do this (it has ZERO support for font glyph operations), but libart has no provisions for handling a multiple of pixel formats, nor does it have integrated support for image ops like applying convolutions, and finally, the libart test code to render just a few vpath's is about 5 times longer than the equivalent code required in Objective-C/DPS or Java/Java2D.

      But I'm not bashing libart or Raph Levien. I have respect for his work. I'm sure it will tremendously improve over the next year, when such functionality becomes a "must have", but right now, it's more like an experimental proof-of-concept library in the beginning stages. What I find absurd however, is how the GNOME team keeps putting forward *OBVIOUSLY INCOMPLETE* projects like they are 1.0 FCS versions ready to compete with mature implementations. Like it or not, the current GNOME Canvas can't hold a candle to a Postscript/PDF/Java2D rasterizer, no matter how many times alpha version libraries are asserted.

      My post was marked flamebait, but I view Miguel's comments as the real flamebait. Why does he feel the need to bash Apple's work (I am not a Mac owner and never owned a Mac), like it's so trivial and he's such a master coder that he could just blow Apple and Adobe out of the water if he felt like making the effort?

      Apple's work on imaging in Mac OS X is clearly more than just "skin"/"theme" hacks, and focusing on the cool transparency effects ignores the hard work that went in to actually designing the dockbar user interface. Maybe the GNOME/Enlightenment guys should spend a little more time themselves on UI design, and less on "looks".