Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
X GUI Software

New X Roadmap from Jim Gettys 278

Posted by michael from the best-laid-plans dept.
A reader points to a roadmap on freedesktop.org that provides a good summary of what is out there for *nix desktops, with emphasis on X but also covering some other areas.
This discussion has been archived. No new comments can be posted.

New X Roadmap from Jim Gettys More

New X Roadmap from Jim Gettys

Comments Filter:

  • X Can Be Sold... (Score:2, Insightful)

    by mfivis ( 592345 )
    ...through controlled marketing. The learning curve of Linux aside, people can be sold on the idea of Linux en masse. There are video games that take longer to learn than basic control over the X desktop.

    • Re:X Can Be Sold... (Score:5, Insightful)

      by alset_tech ( 683716 ) on Saturday November 22, 2003 @02:26PM (#7537463) Homepage
      The difference (and this is not a slam towards X - I love it) is that learning a video game is a recreational process. Learning X in a business setting is a productivity issue. In many cases this isn't a big deal, but in some situations this can be a serious consideration. When you have to take time for employee training the benefits of an X system may have some competition for budget. Dan
      • Do you think that in some companies, where many employees have highly focused tasks, that employees can be trained to learn only the features they need to get a particular job done? Oviously not programmers, but perhaps inventory control or even customer service?

        • Re:X Can Be Sold... (Score:2, Interesting)

          by alset_tech ( 683716 )
          This is true, but when you have scores of employees (and let's face it, many of them are not especially bright) you may end up spending the better part of a day teaching them in small or large groups. I suppose a distinction should be made between large corporate environments and small operations where this isn't and issue.
      • More to the point, when you don't motivate your employees to attend the training you have provided then they don't go, and they don't learn anything, and your support staff keeps fighting all the same pebcak fires.

    • Re:X Can Be Sold... (Score:3, Interesting)

      by Hatta ( 162192 )
      "Basic control over the X desktop" is largely a function of the window manager, not X. And as such, can be as easy or as hard as you want it to be. A WM like icewm takes almost no time to learn for someone coming from windows, while fluxbox is practically unnavigable for someone who hasn't read the docs (but an absolute joy for one who has). The few things that are actually X's responsibility are the middle click text buffer, changing resolutions with CTRL-ALT-+/- and killing the server with CTRL-ALT-BACKSP
    • There is no such thing as an "X desktop", just like there is no such thing as a "GDI+ desktop" or a "PDF desktop". X is a low-level protocol.

      Whether a desktop based on X is easy or difficult to learn depends entirely on the desktop. Something like Ion or CDE, can be frustrating, unintuitive, and complex to novices. OTOH, your local ATM, which may be running X as well, probably is so easy to learn that you don't even think of it as "learning".

  • X Roadmap? (Score:3, Funny)

    by Anonymous Coward on Saturday November 22, 2003 @02:21PM (#7537435)
    Ah, there's probably a joke in there somewhere about crossroads and hidden treasure, but I can't find it...
    • It that the one with the orangutan and the three-legged goose?
    • Here is my solution to making the X-Windows desktop more productive and user friendly:

      YesTool, a GUI interface to the classic powerful Unix utility " yes ", written by the great hacker and University of Maryland alumni David MacKenzie [gnu-friends.org]!

      YesTool will be totally user configable, just like the permissive command-line " yes ". It will be written in object oriented reusable code using parameterizable C++ templates, so you can easily subclass it to make your own tools like NoTool, MaybeTool and ExecutiveDecisio

  • There is no specific roadmap (Score:5, Insightful)

    by sisukapalli1 ( 471175 ) on Saturday November 22, 2003 @02:29PM (#7537487)
    Except a long list of associated technologies. For a non X-pert, the article is just a summary of what is there out there. I was expecting some sort of "this is what the future plans are."

    Roadmap is a little bit misleading term.

    S
    • Yeah, it's more like "Obstacle Course". That's a nice litany of alphabet soup, but what I care about as a consumer is what your goals are and maybe the smallest inkling that you have a plan that is based on some sort of principles (user experience, compatibility, new languages and technologies, etc.). As a user, and as so many fan boys have proclaimed, I don't use X directly, so I want X to work more closely with stuff I DO use like KDE/Gnome desktop environments, applications, etc. The X/Window-Manager/
    • There were a couple of future items that they seemed to mention. I can't recall because it seemed so irrelevant to my use of X.

      I feel kind of cheated, in that they wasted my time. I deliberated read through the most of the page despite what my gut told me when I looked through the table of contents. Did anybody notice how the table of contents had a major point #1, but no #2? Maybe it's there but I'm just too tired to see it. All I know is that I can't be bothered to check because it definitely won't tell
    • Maybe "roadmap" needs to be changed to "flight plan". Most physical roadmaps show you all the existing roads and maybe a few that are under construction, but a flight plan means that you are declaring where you are going and when you plan to be there.
    • I for one found this "road map" to be very enlightening. There is no one person or group of people in this community that can say "this is what we (the community) is going to do". So rather freedesktop published a "map" that shows where on that map we are currently and the route to get where we want to go.

      The "Road map" seemed from my perspective to be targeted more at poential developers than desktop users. Remember Xfree86 has been a rather closed process, so this looks like an honest attempt to try an

    • Re:There is no specific roadmap (Score:5, Informative)

      by jg ( 16880 ) on Saturday November 22, 2003 @09:32PM (#7539686) Homepage
      This is a work in progress.

      I wasn't expecting it to get slashdotted.

      Roadmaps show you where you were, where you are, and maybe where you are going.

      I plan to do more on where things are going...

      And it would be good if other projects did roadmaps of their own projects.

  • Jim Gettys.... (Score:3, Funny)

    by Anonymous Coward on Saturday November 22, 2003 @02:32PM (#7537506)
    I though he was working on all the termcap stuff...

  • One cool thing in the roadmap... (Score:5, Interesting)

    by Realistic_Dragon ( 655151 ) on Saturday November 22, 2003 @02:37PM (#7537525) Homepage
    Low level xlib (ie, generic level) support for X session movement from machine to machine.

    This sounds a bit like screen implimented for X - you can take apps to work and back again without shutting them down, and keep apps running whilst restarting an X server. (With a bit of luck it will support echoing one app to mutliple windows as well.) It also allows for graceful app shutdown when an X server dies.

    Up until now I have been using VNC to do this, but adding it directly into xlib should make it a good deal less clunky. Way to go guys.
    • There is a program to do this already - it sets up another X displays, and instead of :0, you use :1. (similar to ssh setting up :10 for tunnelling). It allows programs to be moved from one display to another pretty seamlessly as I recall. It's called 'xmove' I think :-)

      Simon
      • Xmove while ok in concept, it doesn't work that great in practice. I was able to get it to work on to Xsessions on the same machine, or two VNC Xsessions. But between an Xsession on a remote machine, or even the local Xsession and a local VNC Xsession it wouldn't go due to font and/or color depth incompatibilities.

        Native support that addresses those issues would be great, I would love to run X apps in a screen like wrapper would I could attach them to any Xsession I might be located at.
    • VNC doesn't work at the individual application level; this does. That makes an enormous difference.

      You can get some idea of how this will work in XEmacs (which has multi-display support and can be moved from the console). There is also the xmove server, which already implements this functionality via a proxy.

      It's amazing that this has taken so long. The members of the X Consortium have really been sitting on their hands: this functionality was intended to be in X11 since pretty much the beginning.

  • Enough is Enough. (Score:2, Interesting)

    by cgranade ( 702534 )
    I don't mean to X-Bash- leave that for xterm and Konsole- but I, for one, am ready to welcome our YWindows overlords [slashdot.org], whenever they get here. I like the idea of rewriting from scratch once in a while, which is why I love the idea of scrapping X and going with Y. I mean, X is good, no doubt, but it shows its age. Transparent windows, more often than not, only show the underlying wallpaper and not the interlaying windows. Often, X just locks under load. Still, it is, under normal business circumstances, stabl
    • The damage and compositing extensions being worked on will allow all windows to be stored off-screen and their image operated on, there are screenshots available of them rendering gtk menus translucently over the underlying windows and with a drop shadow, all of which is composited offscreen (and could be hardware accelerated with driver support) and then blitted onto the actual display.
      Why do we need to completely replace X to get something a couple of extensions can do?
      • For reference, the screen shot is here [freedesktop.org].

        Personally I think this kind of thing is a bit silly and pointless, but it seems people want to be entertained by their menus, so I guess we're stuck with more of it ;)
        • Personally I think this kind of thing is a bit silly and pointless, but it seems people want to be entertained by their menus, so I guess we're stuck with more of it ;)

          Semitransparent windows are obviously a bunch of eye candy at present, but they might prove useful once the extension becomes widespread. I'm sure it'll lead to lots of annoying X clients at first, but that stage will pass once people tire of the "effect for effect's sake" part of it.

    • I mean, X is good, no doubt, but it shows its age.

      X11 is not showing its age at all--if you started from scratch today and did a good job at designing a window system with the functionalityi of X11, what you would end up with would look pretty much like X11 anyway.

      Systems like Y or Berlin seem attractive because they are toys; sooner or later, they have to address the same issues X11 addresses and then they become similarly complex. GDI+ and Quartz don't even quite try to solve the hard problems or de

  • xouvert? (Score:5, Informative)

    by ciaran_o_riordan ( 662132 ) on Saturday November 22, 2003 @02:44PM (#7537555) Homepage
    For anyone that doesn't know:
    The Xouvert Project [xouvert.org]
    has been set up to help develop experimental extensions to X in an open way, using Free Software.
    (It's not a competing X implementation, it is assistance).
    (Jim didn't mention this in his paper)

  • Menus (Score:3, Insightful)

    by starseeker ( 141897 ) on Saturday November 22, 2003 @02:47PM (#7537572) Homepage
    A very good overview of the major tools used on Linux desktops.

    I've been wondering about menus in Linux/*BSD - not so much the format of menu storage, although that is an issue, but the applications themselves. We have a very large number of applications out there, but that is a problem for end users because installing them does not result in an update of the graphical menus by which they tend to access them. I think this is one of those little things that makes people think Linux isn't desktop ready.

    I've been wondering - why not do something like the following:

    Create a database of all applications which are or might be deployed on Linux boxes. Define a standard, detailed menu structure into which all these should fit. For example, in the case of science/mathematical applications:

    (Sci/Math)
    (Math)
    (Symbolic)
    (Numerical)
    (Plotting)
    (2D)
    (3D)
    (Electrical)
    (Layout)
    (Simulation)
    (Chemistry)
    (Drawing)
    (Simulating)
    (Physics)
    (Mechanical)
    (Electrical)
    (Quantum)
    (Misc)

    Categories exist mainly as examples - they are not suggestions for what they would actually be. Do the same for graphical applications, editors, programming tools, etc, etc, etc. Once the structure is layed out in broad, start with the Debian archives, freshmeat, sf and savannah, and the other usual suspects and begin defining entries for each application. For each app, there will be a category or categories into which they fit - define this in the entry. To avoid duplicates, assign each category ranking a numerical value - 1 if it definitely should be there, two if it works there but someone wanting a smaller menu structure might not want it, etc. down to don't include this unless a full menu tree is specified. Allow arbitary execution techniques, so apps needing options or odd ways of launching can be accomidated.

    Then, have a way to scan the system binary directories and update based on new binaries found. If the app needs options defined when starting, the entry in the menu will know that and prompt for them when adding it to the active list. Perhaps with some kind of tripwire style system monitoring the menu system could even be triggered as a new binary appears.

    This system would be general and independant, because anybody could write a utility to generate a system's menus based on the database. Then, also, there can be global levels of configuration available. The user could define their own sensitivity - say "Show all Graphics programs but only show level 2 or better text editors". There can even be a "standard" menu structure that doesn't use app names at all, but only generic names and uses the highest ranked app in each category.

    Does anyone know of a project like this underway? I know people have made lists of apps before but if a protocal could be defined to add things like a central database, updating based on binary appearance, user configured options as program is added to menu if desired, etc it might really cause a revolution in Linux desktop menus.
    • The 'menu' package in debian does something along these lines. Frankly I find it messy and filled with stuff I don't want in my menu, so I never use it. :)
    • The problem is that this results in menus that are completely useless and things in all sorts of random places. People think too differently. In case you hadn't noticed, no OS automagically adds things to the menu, the installers for programs do that.

      What Linux needs is decent installation systems. You know, things with options, instead of the usual "Run the RPM and have it fuck up your file associations and menu layout" shit.
      • Well, Debian automagically adds things to the menu, but they have an integrated installer. And frankly, its a bit of a mess. Fortunately there's two menus, the popular tools menu and the "everything installed" submenu. Debian just might be the answer to your RPM problems.

        Of course, then you'll have real problems about installation. Its not very user friendly, but if you can make your way through the text based installers (easy if you're at home with consoles), then day to day operations are simple and most
    • Reason number 3 why Debian rules: Menu system works in concert with the package system itself. (Reason number 1 is APT, reason number 2 is make-kpkg.)

      Debian's menu system is well thought of. A couple of categories (Apps, Games, XShells, and a couple of more), with subcategories. Most menus are kept 2 levels deep, so there's no endless wading through the menus.

      All menu entries are put in menu directories (/usr/lib/menu for packaged apps, /etc/menu for system-wide custom entries, ~/.menu for user-specific

  • A new respect... (Score:4, Interesting)

    by Realistic_Dragon ( 655151 ) on Saturday November 22, 2003 @02:47PM (#7537577) Homepage
    Reading this document has given me a new respect for the X developers.

    You can use a modern X server to talk to an X client on a 1990s vintage machine with no problems at all, yet X is pretty fast on modern machines, has pretty good 3D support and is being updated to add more and more eye candy all the time - without breaking backwards compatibility.

    Their aims may not be the same as the ones you think they should have for your own use, but when compared against their aims they are doing very well indeed, and should be recognised for that.

  • Does anyone still use Metro-X? (Score:4, Interesting)

    by Anonymous Coward on Saturday November 22, 2003 @02:50PM (#7537597)
    Back when I first got a PC capable of running X (1993?), I remember having to use Metro-X instead of XFree86. At the time I was blown away by Metro-X since: (a) it actually worked and was easy to configure -- no tweaking resource files all day, and (b) it seemed to cost money, which baffled me since I never figured anyone would pay for Linux software.

  • Bring it on (Score:5, Insightful)

    by Space cowboy ( 13680 ) on Saturday November 22, 2003 @02:51PM (#7537599) Journal
    Any X "roadmap" is going to have the hungry trolls out in force, mindlessly flailing around with "arguments" that X is badly designed and should be junked at the first opportunity.

    My take is this. You can do what you like to the underlying graphics subsystem. I neither know nor care what the protocol-on-the-wire says. However, you can take the network transparency from my cold and bloody fingers once I've shuffled off this mortal coil, and even then you'll have a fight on your hands. This single attribute is the reason I use it, and why it's possible to remotely administer far far more unix machines than windows ones. VNC is cool, but X is built-in. I love it.

    Simon.

    • VNC vs. X (Score:5, Insightful)

      by penguin7of9 ( 697383 ) on Saturday November 22, 2003 @04:39PM (#7538164)
      Note that network transparency is really mostly about conventions and standards for applications running on different hosts.

      VNC doesn't try to address that issue at all. And, in fact, GDI+ and Quartz can be trivially used as remote display engines, but neither their toolkits nor their applications have any clue how to behave properly.

      Unfortunately, Gnome and KDE are eroding network transparency in X11. For example, they use some of their own preferences files, accessed via the file system, which means that preferences come from the remote machine, not the desktop. I think Gnome is trying to address this, I'm not sure about KDE.

  • Linux Desktop (Score:2, Interesting)

    by Hatta ( 162192 )
    X, Fluxbox, RXVT, Bash. What more do you need?

    • Re:Linux Desktop (Score:3, Interesting)

      by GreyWolf3000 ( 468618 )
      Ummm...quite a bit. If all you use are cli apps, then X isn't even useful. Try fb.

      If I'm going to use X, I'm going to want a desktop environment (Gnome or KDE), a graphical e-mail client, web browser, text editor, office software, etc.

      I don't understand people that use X like a high-resolution vc. What's the point of it again?

      • Re:Linux Desktop (Score:3, Insightful)

        by mackstann ( 586043 )
        I think it's much more common to use *almost* all text-based apps. Every window I have open is an xterm, except firebird. I also use gimp sometimes, nicotine, and maybe a couple other gui apps once in a while. But browsing is the big one. Pretty much every browser sucks IMO, and firebird is the closest to not sucking. Text browsers are definitely not my cup of tea (nor is elinks running in framebuffer or whatever).

        So I make the decision that using X is a good idea. I don't understand why that means y

    • scripsit Hatta:

      X, Fluxbox, RXVT, Bash. What more do you need?

      Um, a terminal that doesn't barf on Unicode? (Eterm and aterm have the same problem... so I just stick to good ol' xterm).

  • how about basic copy & paste? (Score:4, Insightful)

    by McKie ( 513250 ) on Saturday November 22, 2003 @03:18PM (#7537694)
    All that stuff is great, but the clipboard situation still stinks. It's one of the main stumbling blocks whenever I try to get someone interested in using Linux.

    Even if you truly believe in selection/middle-mouse, you have to admit that it should at least be *possible* to configure X to use a universal Alt-C/Alt-P.

    • Should be fairly trivial to bind a keybinding into producing a fake Button2 press. Although then your pointer would still need to be over the area you want to paste in.

      Try shift+insert to paste, it's not universal, but I believe it's pretty common.
    • Umm, X's clipboard does work in a universal alt-c/alt-p type way (although some programs do have different bindings, e.g. ctrl-c/ctrl-p).
      You are aware that the selection/middle-mouse buffer is not the clipboard at all, right? There is a completely seperate and proper clipboard, which is why most programs have Edit->Copy/Paste menu entries. People do tend to get confused and think the selection buffer is the same as the clipboard. IT IS NOT.
    • What the hell is this? Every time, somebody says "Cut and paste", "cut and paste", "cut and paste". Is somebody working off a script out there?

      Every new program uses ctrl+X and ctrl+V, the same as Windows! Somebody is sure to point out that those keys don't work in Emacs or in the Terminal. Well I have news for you: they don't work in Emacs or the Terminal on Windows, either! They don't work in Lotus-123! Yet somehow people think they should work in software of the same age on Linux.

      Selection and middle-m
    • The selection mechanism is a different mechanism from copy-and-paste.

      Even if you truly believe in selection/middle-mouse, you have to admit that it should at least be *possible* to configure X to use a universal Alt-C/Alt-P.

      X just handles the graphics and windows--it has no more control over what applications do than a Postscript printer does.

      How applications handle selections and copy-and-paste is entirely up to the application programmer and toolkit.

      And why should we follow Windows there? Personall

  • Very interesting article (Score:4, Interesting)

    by big-magic ( 695949 ) on Saturday November 22, 2003 @03:24PM (#7537725)
    This is a very interesting article. The thing that I found most interesting is that it demonstrates that the open source community is now in the driver's seat with respect to X development. That's a real change from the old days when the X consortium wouldn't give the XFree86 group the time of day.

    I know alot of people are down on the XFree86 group these days, but it looks like they single handedly destroyed the old X consortium.

  • Two request about XF86.. (Score:3, Interesting)

    by Anonymous Coward on Saturday November 22, 2003 @03:33PM (#7537778)

    1) (partially linux specific) A way of getting DGA (or DGA2) to work for a non-root program. No sudo-stuff, no suid root, just a way for a completely ordinary user to use DGA without being able to crash the machine.

    2) A standard way of getting an equivalent to the MSWindows Alt-tab and alt-enter for programs that run in fullscreen mode.

    For example, an extension that the window manager can hook into, that allows fullscreen applications to run in an own workspace, and a xserver enforced keycombination that can bring back the window manager workspaces if the full screen application crashes.

    • There is no need for a standard way of doing it. The xrandr extension allows the possibility of resolution and depth changing on-the-fly. All window managers need to do is write their own code to bind Alt-Enter with changing the resolution to match (as closely as possible) the size of the active window.
    • I'm not sure what you are getting at with the fullscreen stuff.

      What does Alt+Tab do on Windows? I just tried it on both a maximized window and a program (Photoshop) that takes over the screen. Like expected it just acts like those are windows and does not resize, remap, or do anything else other than switch the top one.

      Most X programs that take over the screen just resize the window contents to the size of the screen. Modern window managers no longer move these, so the contents fill the screen. Then Alt+T
  • ... who's going to have the next hissy fit or fork off a new branch because their not allowed CVS access or any responsibilty due to the arrogance and narcissistic self importance or certain people involved in the project?

    Did I miss something?

    cLive ;-)

    -1 Flaimbait :)

    • Who are you referring to exactly? If Keith Packard, well he is about the only person who is actively working on improving X internals, he's already given us Xft, Xft2, XRender, Kdrive (which is /very/ promising). He appears now to be working on 2 extensions to allow X to do compositing. To call him arrogant or narcisstic to ask for CVS access is plain wrong.

      Further, he appears to have the support of Jim Gettys, which says a /lot/.
  • never achieved widespread acceptance (as in the X Color management part of the API)

    Perhaps that never achieve widespread acceptance because the XFree86 implementation (or perhaps just every graphics card I ever tried it on) sucked big time.

    I wasted far too many hours trying to implement some things using this (that I'd done before with commercial X implementations on dedicated Unix hardware) before giving up in disgust because it just couldn't be done.

    What kind of things? Stuff like a vector graphics p
    • You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard. The CMS stuff was never used, and was a totally stupid idea. Color management should be done by the program, and any system where the 8-bit number chosen by the program does not end up in the image buffer means that true color management is actually impossible, completley reversing the whole purpose of this extension.

      Colormaps and Visuals were (and still are) a serious error in X. The
      • You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard

        Ooh. Never mind.

        Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color.

        Actually, I take that "never mind" back. You seem to be defining "modern graphics" as that subset of computer display graphics that concerns itself with making images and graphic layouts look "correct" so that wha
  • Okay, I may be unique in that I still do some open source development with Motif (mostly wrapped in C++ classes...), but he also calls the Tk toolkit obsolete.

    Eh? Perl/Tk, Python/Tk and (let us not forget) Tcl/Tk are obsolete? Not dead yet, I'd say, although perhaps GTK+ is starting to replace it in favor. What say you?

    (And I guess I can finally throw out my old PEXlib and OpenLook books. Sigh. Anyone got a graphics API they want rendered obsolete? I'll just go study up on it, that should do it...)

Slashdot Top Deals

Life is a whim of several billion cells to be you for a while.

Close