Slashdot Mirror


Xfree86 4.2.0 Out

According to david_eliasson, Xfree86 v4.2.0 is out, but it'll probably be awhile before all the mirror sites have sycned up with the release, so you may want to just enjoy reading that changelog for a couple days before you bother getting the whole archive.

11 of 438 comments (clear)

  1. Re:3.x by psavo · · Score: 4, Informative

    Is anyone still maintaining XFree86 3.3.x?

    I know that Debian people are patching 3.3.6 continuously. I get -v3 updates pretty often. And that is good, because 4.0.2 didn't support my crappy TP560+trident. (AFAIK Debian people fix X themselves, and port fixes from XFree86 CVS).

    --
    fucktard is a tenderhearted description
  2. Re:Moving away from X by stripes · · Score: 5, Informative
    Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency

    There are people working on adding a new rendering model that does antialiasing and sub-pixel addressing. "People" being mostly Keith Packard.

    enhanced programming environment

    There is no reason you can't do that to X, in fact if you compare things like xlib to Gtk--, or Xt to Qt there has been huge progress. Oh, and there is GNUStep too, which is mostly like NeXTStep which is what OS X is based on...

    and a new, well defined and examined user interface?

    That is the hard part. In part because backwards compatibility works against you.

    This would be going the Mac OS X route

    I think OS X has a lot going for it, but the biggest thing really is that the apps do mostly work alike, which is rather unlike X11. I know I'm partly at fault since the X11 apps I worked on (xtank and w3juke) are not much alike :-)

  3. Great news for laptop users! by Adrian+Voinea · · Score: 4, Informative

    One of the major problems I had running XFree86 on my laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.

    So... those with laptops give this option a try in XF86Config:
    Option "UseBIOSDisplay"

  4. Re:Moving away from X by po8 · · Score: 4, Informative
    Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency, enhanced programming environment, and a new, well defined and examined user interface?

    No. Antialiasing and transparency are most of the way into the X server already. Any enhanced programming environment or better user interface is unlikely to be more difficult to implement on top of the X server than atop some from-scratch thing.

    Basically, the X protocol does all the hard parts of a window system fairly nicely. Its rendering functionality was until recently unfortunate, but Packard's client-side rendering via the Render extension appears to be adequate for anything anyone wants to do with GUIs these days.

    The current client-side libraries are not so good, but this can be fixed without changing the X server or protocol. See XCB for one proposed step in that direction.

    IMHO, if one-tenth the energy that was put into whining about X and flailing at never-quite-ready replacement rendering systems went into these sorts of things instead, we'd have a nicer-than-Mac/Windows desktop GUI for free by now.

  5. Re:Moving away from X by pthisis · · Score: 5, Informative

    The problem with X11 is, in part, the separation of client/server; this causes extra latency and a heap of context switches

    The context switches aren't a significant overhead. They weren't even a significant overhead in 1986 when Sun first started spreading FUD about this (at the time, Sun was trying to push NeWs over X11). See e.g. Jim Gettys' posts in the "rendering model in X" thread in the Xrender mailing list archives

    It's not all sunshine, he's willing to own up to places where X needs improvement (exposure lists are a big one, througput for e.g. texture mapping is another), but it's way better than a lot of people claim. And Xrender and DRI address the vast majority of the problem cases very effectively.

    Sumner

    --
    rage, rage against the dying of the light
  6. Re:Moving away from X by kilrogg · · Score: 4, Informative
    most Linux distros by default *don't* have good fonts

    Its really easy to fix: webfonts-1-3.noarch.rpm

    Make sure to read the MS Eula included.

  7. README, Release notes, etc. by Lac · · Score: 5, Informative

    I found additional documents looking through the website. These are much more interesting to read than the changelog.

    The README
    The release notes
    Installation details
    Driver status

    Enjoy!

  8. Re:MS Windows vs. X, same hardware by pthisis · · Score: 5, Informative

    There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive


    If you had read the thread I mentioned in the article you replied to, you'd see the anser to this one:


    > > Not to be too non-technical...
    > > > > If the protocol overhead is so small, why can't my 1200 mips (600mhzPIII)
    > > machine resize windows without widgets streaking? My 486 could do
    > > this fine running MS Windows. Is this because many widget toolkits (GTK,
    > > QT) use XPutImage? There must be some way to speed things up.

    blame your widget set. basically (sorry owen and co on the list) gtk a
    (and i presume qt) dont render optimially at all. the do a semi-decent
    job.. EXCEPt for opaque resizing, and when redrawing is more than a few
    lines and boxes... this is a toolkit issue and imho the current set of
    toolkits (motif, qt, gtk etc.) do a god-awful job of this kind of
    stuff. right now i have silky smooth "opaque resize" stuff working here
    with enlightenment 17 - but i do the rendering completely differently
    to gtk/qt - its all a canvas and thus the rendering happens in a
    "backing" so updates are smooth. on todays hardware this is the best
    way to do it and have almots no artifacts ANd retain speed.

    > "Streaking"? Are these opaque resizes? Alot of apps aren't doing
    > event compression. They repaint the whole damn window every time they
    > get an event. They could have at least checked that there weren't
    > more events in the queue and got rid of them instead of handling each
    > one in turn.

    true. its a very bad thing that there are a LOT of apps that behave like
    this... a LOT. some of the most commonly used are guilty of this
    (netscape for one....)



    the mouse frame rate is low


    If you enable Silken Mouse in XFree86 4.0 and later, this should be fixed. Certainly an implementation issue and not an architectural issue (i.e. not a reason to throw out X and start over)

    applications all have inconsistent look and feel, keyboard support is lacking...


    These aren't X11 problems but GUI problems, GUI standardization is certainly a huge issue. But, gtk-2.0's accessibility enhancements include excellent keyboard support and some steps toward simplifying and unifying look&feel. KDE is moving in that direction as well. Obviously you need to use a single unified UI on your desktop, but having two decent ones available to choose from is not a bad thing (not to say that either is decent yet, but they're both heading there rapidly).

    Sumner
    --
    rage, rage against the dying of the light
  9. (Sigh) here we go again ... by Space+cowboy · · Score: 4, Informative

    This is of course completely dependent on whether your window manager "grabs" the X server while doing a 'move window'. Switch that off, and your windows will update asynchronously. There is a minor performance hit on some (mainly older) graphics cards when this option is selected. Personally I can't tell the difference on my G450.

    The other thing of note is how ...

    A great idea, but difficult to do given the direction Xfree has gone in this regard. IMO Xfree needs replacing, people need better choices for windowing systems. Xfree can't cut it for highly demanding stuff, and no number of extentions are going to change that.

    (above) appears to sound knowledgeable whilst being completely and utterly wrong. (S)he is simply spreading FUD (why, I don't know - perhaps (s)he likes to appear clever when (s)he isn't). Don't you just love it when people try to use stuff they don't know about to advance their personal agenda ?

    Almost as much foot-in-mouth as
    Ich bin ein Berliner
    Simon.
    --
    Physicists get Hadrons!
  10. Re:Xfree is sufferring from poor PR by JollyTX · · Score: 5, Informative

    The XFree86 source tree looks absolutely horrible the first time you try to find out how to compile it.

    I looked at the make files for a _long_ time before I though "hell, let's just do make World and see what happens".

    X built without a single hickup. Why doesn't the README say "If you're using Linux, just do make World and it'll work" ? ;)

    --
    Can you hear me, Major Tom? I'm not the man they think I am at home...