Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
X GUI Graphics Software

Not Just Eye Candy At Freedesktop.org 445

Posted by timothy from the x-rocks dept.
Jim Gettys writes "While Keith Packard's eyecandy at freedesktop.org, including drop shadows, translucent menus and windows with alpha channels is nice to look at, and in some ways useful, *much* more important is that the same facilities are useful for thumbnailing, screen magnifiers, and arbitrary transforms of applications on their way to the screen, just to name a few of the potential applications. So enjoy the eyecandy, but remember, too much candy can rot your brain. And if you want to avoid fattening your brain, you can come help us make this ready for prime-time, and work off the candy you ate and pitch in at freedesktop.org." For background, see this earlier Slashdot post about Freedesktop.org, and the brief description below.

An anonymous reader sums up this effort to revamp X: "The new X server features full support for transparency, and has window-level image compositing among other things. It allows applications to present alpha-blended content to the screen. A new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can take those contents and composite them right onto the screen. The X server project holds sources to build an X server separately from a full X distribution."
This discussion has been archived. No new comments can be posted.

Not Just Eye Candy At Freedesktop.org More

Not Just Eye Candy At Freedesktop.org

Comments Filter:

  • I'll have my eyecandy... (Score:3, Funny)

    by Black Parrot ( 19622 ) on Wednesday November 12, 2003 @10:53AM (#7453486)

    ...with a dash of syntactic sugar, thank you.

  • Slashdot API (Score:3, Funny)

    by Anonymous Coward on Wednesday November 12, 2003 @10:54AM (#7453495)
    Slashdot made the website translucent.

  • So much for Xouvert... (Score:3, Insightful)

    by sirReal.83. ( 671912 ) on Wednesday November 12, 2003 @10:55AM (#7453503) Homepage
    I don't get why the Xouvert folks didn't just pitch in on this effort. They're almost a month and a half behind their schedule.

    Oh well, I'm still getting what I want. Maybe soon they'll be able to add 3D support, as now it's just FB/VESA. Now I'm off to make some debs from the CVS.

    /me thanks fdo

    • Re:So much for Xouvert... (Score:5, Informative)

      by xcomputer_man ( 513295 ) on Wednesday November 12, 2003 @11:05AM (#7453591) Homepage
      The objectives of Xouvert and the freedesktop.org Xserver are different. Xouvert is intended to be an experimental "bleeding edge" branch of XFree86 with opportunities for developers to contribute easily and will remain in sync with XFree. Xserver on the other hand has no connection or relationship with XFree and is wholly an alternative (not a fork ... this code is based on Keithp's own XDrive server which has a brand new core, not XFree86, although some code is reused I believe). In other words they are in fact separate projects.

      I'm not sure exactly how the Xouvert folks respond to this, but I believe they are interested in eventually collaborating with this effort in the future, from, my discussions with a couple of them.

      And no, it's not just FB/Vesa. There are servers available for r128, mga, mach64, and a couple of older cards (S3 savage/trio and trident).

      • Eww, a whole new server? I hope there's more code sharing against XFree86 rather than less.. it would seem a tremendous waste to have to reinvent and maintain that particular wheel.

        Even for someone as renowned as Keith.

        • Re:So much for Xouvert... (Score:5, Informative)

          by po8 ( 187055 ) on Wednesday November 12, 2003 @12:29PM (#7454383)

          In the long run, KDrive will become the standard: it's a much better server. KDrive does share much code with XFree86, but it has major cleanups and simplifications. It will need more driver support (though this is much simpler in the KDrive architecture) as well as 3D support before it is ready to take over, though.

          In the short run, the right answer is to fold the changes back into XFree86. This should be no big deal technically: there's nothing terribly KDrive-specific about them. Politically, it may be harder: the reason that Keithp was ejected from the XFree86 project was essentially for trying to change things. :-)

          The XFree86 DRI project server is on freedesktop.org, and will probably have these fixes well before the XFree86 core server. This server is likely the immediate future of XFree86 anyhow.

      • I do not care much about the new eye candy if I cannot use it and I do not really want software based hacks. Can this eye candy work with my ATI or Nvidia card?
      • Err correcting myself: Keith Packard's server was called KDrive, not XDrive.

  • Buggy system (Score:5, Funny)

    by YetAnotherName ( 168064 ) on Wednesday November 12, 2003 @10:56AM (#7453513) Homepage
    Looking at screenshot number 3, I think the fellow's got a few bugs to work out.

    Bu-dum-chee!

    Thank you! Thank you! I'll be here all week! Try the buffet!

  • But are they doing it right? (Score:5, Insightful)

    by ArmorFiend ( 151674 ) on Wednesday November 12, 2003 @10:59AM (#7453536) Homepage Journal
    A new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can take those contents and composite them right onto the screen.
    Can someone tell me, are they doing it the right way, or the all-software way? The right way uses the innate RGBA capabilities of the video card (probably through OpenGL) to do the compositing. The software way is good to have if the computer in question doesn't have a decent GPU, but if it also doesn't have a decent CPU, slowness is going to ensue.

    • Re:But are they doing it right? (Score:3, Informative)

      by Anonymous Coward
      They are doing it in a way, that X server doesn't know about implementation details. It may run in software, it may be implemented in hardware (using OpenGL for example). X server just doesn't care, it is job for Composition manager. It may do another things except alpha blending windows - for example capturing screen changes for vnc or screen recorders.

      I would post the link, but freedesktop is slashdotted.

    • Re:But are they doing it right? (Score:5, Informative)

      by rogue_gambit ( 26909 ) on Wednesday November 12, 2003 @11:06AM (#7453600)
      That will be up to the compositing manager. It can choose to do it all in software or use OpenGL if available.

      We will probably see a lot of window managers get composite managing built in, but there is also likely to be a few compositing only manager, which will work with your favorite window manager.

      So in the end it is up to the manager to uo decide how to do the compositing.
    • [i]Can someone tell me, are they doing it the right way, or the all-software way? The right way uses the innate RGBA capabilities of the video card (probably through OpenGL) to do the compositing. The software way is good to have if the computer in question doesn't have a decent GPU, but if it also doesn't have a decent CPU, slowness is going to ensue.[/i]

      I beg to differ: You do not *have to* use hardware acceleration to get good performance if software is done right [slashdot.org]. And from my understanding, the actual

      • Re:But are they doing it right? (Score:5, Interesting)

        by ArmorFiend ( 151674 ) on Wednesday November 12, 2003 @11:44AM (#7453941) Homepage Journal
        The article you cite is probably a case of a hardware fast path NOT being used, but being advertised by the API. Thus he was asking for hardware operation X, and getting a generic software operation X, which wasn't hand optimized for his particular options. In that case his hand optimized code might be faster by a lot. Such a case occurs fairly often in graphics.

        For a non-speculative example, OpenGL's glDrawPixels draws rasters from the lower left corner, whereas most UIs like to draw from the upper left. You can change it by calling glPixelZoom( 1.0, -1.0 ), but in many cases this knocked the gl driver from 1-1 pixel mapping into floating point transforms (basically it started using software to scale the image by some floating point value). A few phone calls to nvidia, 3dlabs, sgi, and intergraph later, and their drivers started special-casing for a -1.0 y pixel zoom, and our software sped up by a factor of about 1000.

        In the far future of Moore's law we will not have GPUs at all, merely CPUs with power to burn. So in that sense I agree with you that hardware is/will-be not needed. Now I haven't done any graphics programming since machines hit 1ghz, so that far future may be now. :)

        • In the far future of Moore's law we will not have GPUs at all, merely CPUs with power to burn. So in that sense I agree with you that hardware is/will-be not needed. Now I haven't done any graphics programming since machines hit 1ghz, so that far future may be now. :)


          Actually, from what people at SIGGRAPH kept saying, graphics cards are outpacing Moore's law. If that continues we'll have amazing vector processors and rasterizers with a dinky little CPU telling them what to do.
    • Too be honest, that does not matter. It is a fairly simple matter to move that code from software to hardware. The hardpart is getting all the applications and the users of the Xservers to head this direction.

    • Yes, they are. (Score:5, Informative)

      by penguin7of9 ( 697383 ) on Wednesday November 12, 2003 @12:46PM (#7454534)
      X11 isn't like the stuff Microsoft or Apple churn out. Microsoft and Apple just hack something together, throw it out, and call it a "standard API". It's easy. It's quick to market. And it locks people into proprietary APIs and has all sorts of other problems.

      X11 is a protocol, not an implementation. As part of defining protocol extensions, people build a reference implementation of the protocol extension. It makes perfect sense to build the reference implementation in software. Hardware vendors and implementors can then build hardware accelerated versions of it and compare it with the software implementation.

      This approach has worked very well. It means that X11 has remained backwards and forwards compatible over more than a decade and that X servers have been able to take advantage of new hardware technologies as they have come out.

      Note that Apple is not using the "innate RGBA capabilities of the video card" to its fullest extent either. Furthermore, even good 3D cards may not do the right thing for 2D rendering--2D desktop rendering is not simply a subset of 3D rendering.

      • Re:Yes, they are. (Score:3, Informative)

        by TrancePhreak ( 576593 )
        I forgot to mention... If MS just hacks stuff together, then why does Windows 3.1 software still work? Win95 software works on 95 and later, etc etc. You seem to have some lack of knowledge for what you're talking about.

        Also, in Win2K and XP, the selection rectangle has a filled in center that is alpha blended, if the video card supports it - it is done in hardware.

    • Re:But are they doing it right? (Score:4, Informative)

      by jg ( 16880 ) on Wednesday November 12, 2003 @01:57PM (#7455403) Homepage
      The bits never leave the X server.

      The current implementation is software only, and
      runs at usable speed.

      So I expect when we start using the alpha blending hardware, we'll run like a bandit...

  • Image mirror of translucent X server (Score:4, Informative)

    by Anonymous Coward on Wednesday November 12, 2003 @10:59AM (#7453540)
    Image saved before slashdotting, Here [bayou.com]

  • XVideo support? (Score:2, Interesting)

    by Anonymous Coward
    Do translucent windows sitting on top of video playback work with accepatable speed?
    • Do translucent windows sitting on top of video playback work with accepatable speed?

      Good question. I'd also be interested in hearing XP/OS X users answer the same question.

      Can anyone comment on this?

      • Re:XVideo support? (Score:2, Funny)

        by Anonymous Coward
        Can anyone comment on this?

        I can, but not intelligently.
      • I'm running WinXP on a PIII 1Ghz with a 64meg GForce2 MMX clone. I have Trillian's alpha set to 90%, and yes, it does flicker when watching movies. Of course fullscreen will take care of that. Another issue I noticed, is when connecting to my machine with VNC,any window that has alpha blending will become invisible to the VNC server (you can still interact with the window, ya just don't see it).
      • I'd also be interested in hearing XP/OS X users answer the same question.

        Works no trouble under OS X (on a 12" Powerbook, at least). I often do my coding using a transparent terminal, vi and a DVD running underneath.

        Cheers,
        Ian

  • So enjoy the eyecandy, but remember, too much candy can rot your brain. And if you want to avoid fattening your brain, you can come help us make this ready for prime-time, and work off the candy you ate and pitch in at freedesktop.org

    If translucent windows can "fatten your brain" (er..?) then is ratpoison [sourceforge.net] the Atkins Diet? Someone else help me out with abusing this metaphor some more.

  • Slashdotters are always complaining about that X is slow/bloated/outdated/old/must be replaced/etc/etc. Yet X is slowly improving. Nonetheless, that doesn't stop people from complaining.
    Now that I've seen thousands of Slashdotters complain about X, and it seems alpha transparency is finally progressing, I can only conclude one thing:
    Don't listen to the whiners!

    Really, *all* those people do is whining and bashing, and *nothing else*. No constructive criticism, no suggestions - just whining and bashing. An
    • So you are whining about the whining on Slashdot, therefore becoming that which you despise. :-)

      Of course when the comunity yells loud enough for a particular feature, some determined hacker will eventually act, and things will get done. Look at the amount of noise generated in favor of font anti-aliasing, someone listened, took the time to do it, and now the community has one less thing to bitch about :-)
  • I think it is time we make a more userfriendly, windowmanager-specific GUI for Linux/FreeBSD/etc that will be accepted by the masses and seen as "Linux", maybe make it official, this is the perfect grounds to get it accepted by the masses, making a unified interface for linux and other derivatives, then see if it is accepted. Make it like windows where all you see the whole time is the user interface, to make it better for the desktop world, some say that choice is good, and the ability to run programs remo

    • Re:Grounds for a unified unix gui (Score:5, Informative)

      by FooBarWidget ( 556006 ) on Wednesday November 12, 2003 @11:12AM (#7453651)
      "and the ability to run programs remotely is good, but now days for the average desktop user, this is not very practical,"

      This is a complete non-issue. By default, X doesn't allow connections from outside so you can't use it unless you really *want* to use it.
      And local applications doesn't communicate using a TCP socket, but through shared memory and Unix Domain Sockets (which are as fast as shared memory, at least on Linux), so performance problems for local apps are gone.
      Network transparency doesn't stand in your way. It doesn't bother you. But when you need it, it's there.

      And you people should look beyond the home desktop. Think about the corporate desktop! A server serving hundreds of thin clients can save a lot of money. Many, many people today rely on X.
      Network transparency *does not* block desktop acceptance.
    • Problem isn't the GUI. Hasn't been for a while. Problem as that all the apps that make linux great aren't accessible to the masses (read: don't have GUI).

      Ask your average Linux user about the greatest things in Linux. Chances are that maybe 1/10 can be done inside a windowmanager.

    • Re:Grounds for a unified unix gui (Score:4, Informative)

      by gorilla ( 36491 ) on Wednesday November 12, 2003 @11:48AM (#7453979)
      run programs remotely is good, but now days for the average desktop user, this is not very practical,

      However, given that it's a good design for a GUI program to communicate with the GUI layer using sockets, then you get the ability to run commands remotely almost for free, with the only extra work required being the security & authentication system.

    • I'd go and participate in E17 [enlightenment.org]. Enlightenment as a wm rocks, but E17 looks like it's got all of the desktop goodies + the fine wm.

      Judging by the amount of time they're spending, they could probably use the help.

  • Sounds good... (Score:2, Insightful)

    by Fnkmaster ( 89084 ) *
    Now can we make a decision about toolkit? I like choice as much as the next guy, but the choice is at the wrong level here. I NEVER want to see multiple mismatched, clashing toolkits on my screen at the same time. I want to have to *force* some compatibility layer to make such a beastly occurrence happen. Everything looks consistent and doesn't hurt my eyeballs or brain in Windows (well, Windows hurts my brain, but that's mostly when I'm trying to write raw Win32 code... ugh). Maybe I'm just in the sam

    • Re:Sounds good... (Score:5, Informative)

      by IamTheRealMike ( 537420 ) on Wednesday November 12, 2003 @11:07AM (#7453608)
      Why does this just never happen in Windows (even OOo doesn't exhibit these awful characteristics in Windows - yes, this is a rhetorical question, I understand the technical reasons and they all indicate major flaws in the X architecture to me)?

      I take it you've not used Windows in the last few years then. Take a look at the menus and toolbars in Wordpad, Visual Studio, Office 2003, Windows Media Player and Encarta.

      What? They're all different? How dare those people not use the builtin toolkits - what are they thinking?

      I think that really you don't understand the Windows architecture (which is really quite similar to X except for no network transparency and a kernelized WM), otherwise you'd realise that multiple conflicting toolkits happen all the time there.

      This is even true of MacOS X. There are some well known incidents where it was shown that different apps in the MacOS X base distribution reinvented the same widget multiple times over.

      • Apples and oranges. On Win32 and Mac OS X, there is a single standard native toolkit, and it is well understand that to make a native app, that's what you use.

        In general, you have to go way out of your way to make a Mac OS X app look fundamentally different from other Mac OS X apps. If you're using the modern frameworks, you can even easily tinge the native interface with your own identity and still look native OS X. You _can_ use a custom framework to make things look completely different (you can also do

        • Apples and oranges. On Win32 and Mac OS X, there is a single standard native toolkit, and it is well understand that to make a native app, that's what you use.

          I wish. That'd make my job a lot easier. In fact on Win32 there are multiple versions of the same toolkit. Browse through MSDN some time, and notice how half the controls have special features or replacements that are only available on certain versions or if IE >= whatever is installed.

          Toolbars are a good example of that. What is native? The

      • Sorry, but you seem to be misconstruing my point. I'm not trying to be a widget nazi and say nobody should make new widgets. But they should consistently fit the basic look and feel of the system. I am not trying to defend some of the major fuckups Microsoft has had with some of their more recent apps - there is really no excuse for not using system menus, or at least making your menus look and feel exactly like system menus.

        The problem is that there are no system menus at all in X. Everything is just

    • I think unifying the toolkits eliminates choice for developers. A better and more realistic goal should be to make the differences transparent to the user. The inner workings should be however the developers like them, but I think they should use a common method of drawing common widgets like toolbars, menus, buttons, etc. to unify the appearance of the desktop.

      It's very difficult to implement in practice, but it's an ideal to strive for.
      • Spot on - I was thinking exactly the same thing the other night. Unfortunately, I've got a feeling that such a setup would have to be able to handle really complex themes, and many developers of lightweight toolkits would baulk at having to implement them.

        Still, Linux is all about choice - if you want a consistant feel, you can always stick to only installing apps that use one toolkit or download RedHats Bluecurve or something.
    • In other words, choice is good, as long as you like all of the choices.

      I've been using Gnome since it first became stable enough to run a terminal, and I've never looked back.

      HOWEVER, I run some apps that are KDE-only as well. I've never seen a problem in doing this.

      OOo is, IMHO, the klunkiest, least usable of the desktop applications for UNIX/POSIX systems that I've seen (well, ok if you want to compare to ghostview that's another level of unusability). I use Gnumeric when I need to read or write a spre
    • Then only run apps that fit your idea of 'correctness'.

      Don't screw it up for the rest of us.
    • Now can we make a decision about toolkit?
      Nope, sorry. I'm surprised you even bothered to ask.

      What do you expect? Now, can we all just standardize on English? Can we all just start using Common Lisp for all our programming needs? Can we all start using metric?

      You can ask all you want, but really what's the point? Let's deal with the realm of the possible here.

    • You should be using Fedora Core. Bluecurve makes all the toolkits look the same, so it's a nonissue.

  • Eyecandy is important :-) (Score:5, Interesting)

    by Space cowboy ( 13680 ) on Wednesday November 12, 2003 @11:02AM (#7453564) Journal
    ... I mean, look at Apple. They've built most of a business around being cool, sexy, and user-friendly. This is a triumvirate for the company, and with the unix-based OS-X, they'll be expanding into hardcore geek territory as well :-)

    I even wrote eyecandy (the visualisation applet) on hostip.info - it's a trade: I show you something pretty, you put in your city. Or not. Your choice, but hopefully the eyecandy helps sweeten the deal :-)

    Simon.

  • Mmmm Candy! (Score:4, Funny)

    by Lumpy ( 12016 ) on Wednesday November 12, 2003 @11:04AM (#7453579) Homepage
    So enjoy the eyecandy, but remember, too much candy can rot your brain.

    oh that reminds me of something.... oh yeah! THIS [yimg.com]

  • alpha blending in x vs wm (Score:4, Interesting)

    by jd142 ( 129673 ) on Wednesday November 12, 2003 @11:11AM (#7453641) Homepage
    Since I can't get to the freedesktop site right now, I'm curious about the speed increase when the alpha blending is done by the X server instead of by the window manager. The one screen shot I did see(only because someone mirrored it) had gnome with semi-transparent windows. I'm not a gnome user, I use KDE and I know it handles transparent windows and menus. But how much faster and snappier will the response be with the transparency done at lower level?
    • Keep in mind that KDE doesn't do real transparency, it takes a screenshot at creation time and blends the images together. Thus, you can get menus that look out of place, such as when there's a periodically updating window behind the transparent object.

    • Re:alpha blending in x vs wm (Score:5, Interesting)

      by xcomputer_man ( 513295 ) on Wednesday November 12, 2003 @11:25AM (#7453779) Homepage
      The issue is not really the speed increase (although yes, it will be faster). The point is that this will give you *TRUE* alpha channel-enabled visuals. What KDE and a couple of other projects like the Enlightenment DR15/16 series have done in the past is a "pseudo-transparency" hack done by grabbing the root pixmap and using it to blend. By using a compositing manager and adding true 32bit ARGB visuals, a window can say exactly how transparent each pixel should be, and the compositing manager combines everything together to produce the final display. Semi-transparent windows are overrated: this gives you a LOT more potential for snazzy effects (for starts, how about shaped windows that have antialiased edges?).
    • KDE doesn't handle transparent windows. It fakes transparency by getting the content of the lower windows and using them as the background to higher-level ones. So you'll notice that if you have any kind of changing content underneath a transparent window, you won't see it update.
      It's not a matter of transparency being implemented at a lower level- transparency isn't really implemented at all at this point.
    • KDE doesn't do real transparency. It takes a screenshot of the underlying windows and then alpha blends the menu over that screenshot and draws the result to screen. If the contents of the windows below the menus change while the menu is still open, you'll see it.
    • But how much faster and snappier will the response be with the transparency done at lower level?

      I don't know the answer, but I can make an educated guess. A lot. And I mean a whole crapload faster.

      If the server does not support alpha, then the only way wm to blend things is to ask X politely for the background, do the compositing in software, and send it back to X to draw. In fact, in many cases the only "background" you can ask X for is the desktop background, which means that semi-transparent window

    • Re:alpha blending in x vs wm (Score:3, Informative)

      by jg ( 16880 )
      The blending is being done entirely in the X server.

      The speed with depend on whether the X server has hardware support for blending.

      The prototype doesn't; it is, however, fast enough to be useable even doing it all in software with a Vesa server, so I think we're ok on performance.
  • It's nice to see some modern imaging models being implemented in X.

    But it seems to me that this will just lead to a more fragmented user environment. X has always had the problem of "applications behaving differently." So now, some are going to support the imaging model, and others won't.

    From a user's point-of-view, that sucks.

    If you want a killer desktop environment, work on the user interface. Not the imaging model.
    • Eh? You'll simply get some applications that'll make use of transparency, and some that won't. The imaging model is transparent to the application, as far as I'm aware.
  • Can anyone explain why Xserver/kdrive doesn't support standard XFree video card drivers? It's a great project, even without these new extensions, but unaccelerated X sucks badly. Is there something wrong with the XFree driver architecture?
    • I seem to recall KeithP once mentioning that, in order to implement transparency, he would have to break the XFree driver ABI. For this reason, it was originally planned for XFree5, but it seems the problems this year has forced a rather unpleasant fork situation.

      • Re:No accelerated drivers?? (Score:4, Informative)

        by DreadSpoon ( 653424 ) on Wednesday November 12, 2003 @12:02PM (#7454133) Journal
        I don't think this is the issue anymore - the extensions used for this translucency don't require any driver changes, as RENDER (or any other rendering method/extension) can be used.

        Here's to hoping XFree86 gets these extensions. Having an X server that doesn't work that well for the hardware most people are using is going to limit how many people can use these new extensions... ;-)

  • Slashdotted (Score:5, Funny)

    by jargoone ( 166102 ) on Wednesday November 12, 2003 @11:16AM (#7453693)
    For your viewing pleasure, I have obtained an ASCII-art mirror of the screen shots:

    ----------
    |* |
    |* |
    |* |
    | |
    |========|
    ----------

  • Mirror Here (Score:4, Informative)

    by herrvinny ( 698679 ) on Wednesday November 12, 2003 @11:17AM (#7453701)
    at http://www.herrvinny.com/sdmirror/ [herrvinny.com]

  • Am I the only one? (Score:3, Interesting)

    by nizo ( 81281 ) on Wednesday November 12, 2003 @11:20AM (#7453719) Homepage Journal
    Am I the only one who just uses plain ol' fvwm anymore? Since 60% of what I do is typing in a window, with another 30% surfing and 10% doing wordprocessing/gimping :-) do I really need a huge bloated eye-popping-candy-filled window manager?


    Don't get me wrong, if you have fast hardware and are trying to convert grandma from "some other environment" go for it, but for me personally I will take lean, mean, and quick any day of the week.

    • Re:Am I the only one? (Score:2, Interesting)

      by eyeye ( 653962 )
      Agreed. I like to look at eye candy, once or twice - I might even spend 10 minutes going "ooooh" and pissing around with things but when I am working they will all get switched off if possible.

      I cant think of any eye candy advances (in windows XP, lol!) that help my productivity. Even looking at apples amazing new features doesnt impress me. The pseudo 3d user switching effect has already been done on a linux WM (when moving workspaces). Expose etc doesn't seem to give any more advantages than normal abi
    • Am I the only one who just uses plain ol' fvwm anymore? Since 60% of what I do is typing in a window, with another 30% surfing and 10% doing wordprocessing/gimping :-) do I really need a huge bloated eye-popping-candy-filled window manager? Don't get me wrong, if you have fast hardware and are trying to convert grandma from "some other environment" go for it, but for me personally I will take lean, mean, and quick any day of the week.

      Most people install the distro and use Gnome or KDE. Some may install

    • >do I really need a huge bloated eye-popping-candy-filled window manager?

      Unless its a really good reason, I can't go back to aliased-fonts.

      And since I read/write text, they are eye-candy I use all the time.

  • That's not eyecandy... (Score:3, Funny)

    by Anonymous Coward on Wednesday November 12, 2003 @11:25AM (#7453775)
    THIS [victoriassecret.com] is eyecandy!
    Anyone know who this is?

  • If people want things to look and work like Mac OS (Score:5, Insightful)

    by Anonymous Coward on Wednesday November 12, 2003 @11:30AM (#7453820)
    I've noticed the look of the screenshots at this site. It seems so many people want things that look and work like Mac OS X in the freeware world nowadays. Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead? I think NeXT and now Apple has proven the world won't fall apart if you use Objective-C instead of C++. If you go to the http://www.w3.org/ site you'll even see that the first web browser was written in Objective-C. Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.
    • Object-C is an ugly syntatic kludge of a language. C++ isn't perfect but its FAR more consistent than O-C. Why anyone would want to
      use objective C if they haven't got a gun pressed to their heads is a mystery to me.
      • Your personal, subjective views on Objective-C without supporting materials does not add weight to your proclaiming your stance is fact.

        The syntax to Objective-C that draws from Smalltalk-80 flows grammatically and is quite self documenting.

        C++ on the other hand isn't designed to be self documenting and doesn't discourage poor grammar practices.

    • they don't like the underlying technology (Score:5, Insightful)

      by penguin7of9 ( 697383 ) on Wednesday November 12, 2003 @01:05PM (#7454776)
      Then why are so many more people going with Gnome and KDE? Why don't more people just support the GNUstep people instead?

      Easy: while a lot of people like the look of the Mac, they don't like the underlying technologies: DisplayPDF and Objective-C. Personally, I think those technologies are obsolete, inefficient, and cumbersome.

      I think adding transparency to X11 is a technically much better solution. It is language neutral and transport agnostic. It also has the virtue of being backwards compatible. And it doesn't require people to throw away their existing X11 software--there is a lot more X11 software than OpenStep or Apple software.

      X11 will also get server-side stored vector graphics based on SVG. Again, same functionality as DisplayPDF but more standards compliant and a better design.

      Also, OpenStep exists as a standard so it sure will make easier to port commercial applications written in Cocoa to the Unix world.

      In what sense do you believe OpenStep is a "standard"? Where are the standards documents? Where can you even get an implementation?

      It seems that right now, we have GNUstep and Cocoa, two similar but incompatible implementations, together with some copyrighted API documents.

      Note, incidentally, that few of the features that make the Macintosh API visually appealing (shadows, transparency, etc.) were pioneered by Apple, and historically were implemented without anything like Apple's software infrastructure.
  • So when is OSS going to invent something in the usability area for a change? Cascading menus were nice 10 years ago when screen resolutions were 640x480, but with the technology today, I don't see any reason why I have to look at a small subset of the available commands at any given time.

    When do we get a new screen-size "menu" system that lists all the commands in one convenient overlaid window, just like, well, the Web Site Directory portion on yahoo.com's main page? How about something new and useful ins
    • The larger a menu is, the harder it is to find something on it. Humans can tell where something is without any effort in a menu with five items or so (hence the five lines for notes on written music). Once you get much above that, it becomes much harder to use - you have to stop and think about where on the menu you need to click in order to perform a command.

      Cascading menus aren't ideal, but they provide a way to divide up functionality so that it can be quickly scanned visually by a human.
      • You're assuming the only choices are to present 5 commands at a time or to present all commands in one big long list. There are other ways, you can present a screen-full of commands divided into small groups, each group presented in its own section.

        Look at real menus in restaurants. Some restaurants have a lot of food choices, but the choices are presented under different sections, appetizers, soups, salads, noodles, etc. Once you find the right section, you can find your favorite food easily...

        Now think

  • All that is missing (Score:2, Interesting)

    by icebear.dk ( 182125 )
    Hmm, this looks promising. Now all that is needed is for someone to write either a compatibility layer to bring the XFree drivers over to the freedesktop.org Xserver including GLX compatibility, make the Compositing Manager use OpenGL and eureka we have GPU based compositing.

    This is close to the features coming in Longhorn, where the windows are to be considered textures rendered by the GPU.

    Now my personal dream is still to see a combination of this and a high level protocol/server in which the applicatio
  • Comment removed based on user account deletion
  • ... the same facilities are useful for thumbnailing, screen magnifiers, and arbitrary transforms of applications on their way to the screen ...

    For example, parsing the content and editing it on the way to the screen. How long before it's used for pop-up advertising?

    -kgj
  • In order to play with this X server, what hardware does one need (i.e. what hardware does the current CVS version support?)

Slashdot Top Deals

C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Close