Slashdot Mirror

Maybe we need a high performance network enabled version of Gtk.

The problem is not on Gtk. Gtk makes use of a double buffer to avoid flickering. That's not bad, but it brings an X Window design decission to the surface.

When using X over a network, it always transfers ALL the screen to the clients, even the static parts.

The addition of the XDamage extension to X servers allows the X protocol to transfer _only_ the screen changes over the network. Less transferred data, less network use, more speed.

I can't wait for the Freedesktop X server to be production quality.

Once Linux becomes a viable alternative to Windows for office use things will improve. With office use we will see better driver support for common hardware (not that there is much of a problem currently, other than closed source).

Multimedia support under Linux is not in a bad state. SDL is a good standard set of libraries for handling windowing, OpenGL, input and audio. With projects such as Project Utopia and HAL integrating the kernel with the desktop, things can only get better.

I think the future is bright for Linux gaming.

While UNIX-style IPC is failrly primitive, there has been a good amount of effort (esp. by the freedesktop.org folks) to recitify some of the problems you mention:

COM/DCOM/Active-X: These were designed to support GUI applications; as a result, they're pretty lightweight, but don't handle distributed applications well. CORBA, on the other hand, was designed for remove method invocation, and is really too heavy for GUI-type apps, as GNOME found out. Theres been some progress here, though: DCOP, used by KDE, is very nice; it's KParts system is the best example of its kind in Unix-land. The KDE and GNOME folks (via freedesktop) are moving towards a common protocol and desktop messaging framework, .

Window Managers vs. OOo: I'm not fully aware of the issues, but it sounds like (and wouldn't surprise me to find out that) OOo doesn't follow the well-known ICCCM protocol. There is a standard, OOo doesn't support it. Kind of like how Microdoft Office doesn't use the standard widget set of Windows.

That Java RMI "hack" comes in real handy when doing IPC operations across a heterogeneous network, btw.

The drag-and-drop argument is really getting tired. The three major DEs (KDE, GNOME, XFCE) all support the XDND protocol... This was a problem a few years ago, and mostly to those who didn't understand how X cut and selection buffers work. But now, XDND has simplified and standardized how drang-and-drop works on X clients...

While UNIX-style IPC is failrly primitive, there has been a good amount of effort (esp. by the freedesktop.org folks) to recitify some of the problems you mention:

COM/DCOM/Active-X: These were designed to support GUI applications; as a result, they're pretty lightweight, but don't handle distributed applications well. CORBA, on the other hand, was designed for remove method invocation, and is really too heavy for GUI-type apps, as GNOME found out. Theres been some progress here, though: DCOP, used by KDE, is very nice; it's KParts system is the best example of its kind in Unix-land. The KDE and GNOME folks (via freedesktop) are moving towards a common protocol and desktop messaging framework, .

Window Managers vs. OOo: I'm not fully aware of the issues, but it sounds like (and wouldn't surprise me to find out that) OOo doesn't follow the well-known ICCCM protocol. There is a standard, OOo doesn't support it. Kind of like how Microdoft Office doesn't use the standard widget set of Windows.

That Java RMI "hack" comes in real handy when doing IPC operations across a heterogeneous network, btw.

The drag-and-drop argument is really getting tired. The three major DEs (KDE, GNOME, XFCE) all support the XDND protocol... This was a problem a few years ago, and mostly to those who didn't understand how X cut and selection buffers work. But now, XDND has simplified and standardized how drang-and-drop works on X clients...

While UNIX-style IPC is failrly primitive, there has been a good amount of effort (esp. by the freedesktop.org folks) to recitify some of the problems you mention:

COM/DCOM/Active-X: These were designed to support GUI applications; as a result, they're pretty lightweight, but don't handle distributed applications well. CORBA, on the other hand, was designed for remove method invocation, and is really too heavy for GUI-type apps, as GNOME found out. Theres been some progress here, though: DCOP, used by KDE, is very nice; it's KParts system is the best example of its kind in Unix-land. The KDE and GNOME folks (via freedesktop) are moving towards a common protocol and desktop messaging framework, .

Window Managers vs. OOo: I'm not fully aware of the issues, but it sounds like (and wouldn't surprise me to find out that) OOo doesn't follow the well-known ICCCM protocol. There is a standard, OOo doesn't support it. Kind of like how Microdoft Office doesn't use the standard widget set of Windows.

That Java RMI "hack" comes in real handy when doing IPC operations across a heterogeneous network, btw.

The drag-and-drop argument is really getting tired. The three major DEs (KDE, GNOME, XFCE) all support the XDND protocol... This was a problem a few years ago, and mostly to those who didn't understand how X cut and selection buffers work. But now, XDND has simplified and standardized how drang-and-drop works on X clients...

There's quite a bit of inter-operability work going on at freedesktop.org. There's a lot of shared specifications and software there. Plus there are software libraries that both DEs use that aren't listed on FDO, like libxml2.

The KDE folks have also worked on some Qt-GTK toolkit inter-operability stuff. See also:

GTK-Qt
Ditto
Glib/Qt main loop integration

amongst others.

Gstreamer is LGPL
Free Software NUT

This package is worth checking out if you use Debian
and want to use ATI's own drivers:
ATI Linux drivers packaged for Debian

Hm, anyone actually know what the big difference
between using ATI's closed source drivers or the
open sourced DRI-ones? (except not poluting your
karma ;>)
DRI (debs)

This package is worth checking out if you use Debian
and want to use ATI's own drivers:
ATI Linux drivers packaged for Debian

Hm, anyone actually know what the big difference
between using ATI's closed source drivers or the
open sourced DRI-ones? (except not poluting your
karma ;>)
DRI (debs)

And the rest of us will use XOrg

*Sigh* The technology that allows you to do translucent windows also allows you to do other nifty things. Why don't you read the how it works link before posting like you know what you're talking about.

Had I released KillerApp under a BSD license, Bill or Darl could make a few changes to it and distribute the result under any terms they want - potntially making the new, improved KillerApp completely closed and proprietary. They might make megabucks by changing 10 lines of source code and selling the binary only. Is that fair to me, when I did most of the work originally? No - that's why I release under GPL.

The problem with the XFree86 1.1 license is that it imoses a requirement to give credit if someone chooses to distribute a binary build of their software.

If, in fact, they explicitly exclude client programs linked to the XFree86 libraries, then I don't see a problem.

Had I released KillerApp under a BSD license, Bill or Darl could make a few changes to it and distribute the result under any terms they want - potntially making the new, improved KillerApp completely closed and proprietary. They might make megabucks by changing 10 lines of source code and selling the binary only. Is that fair to me, when I did most of the work originally? No - that's why I release under GPL.

The problem with the XFree86 1.1 license is that it imoses a requirement to give credit if someone chooses to distribute a binary build of their software.

If, in fact, they explicitly exclude client programs linked to the XFree86 libraries, then I don't see a problem.

> There's also Xfree86 4.4rc2 it's still old license and a good start to a fork.

The folks at FDO have just done that.

It appears to be pretty recent, and not yet advertised, but freedesktop.org has forked Xfree86 from 4.4 RC2. Note: this independent from their own experimental X server to which everybody is referring (but which is not really ready for consumption yet). If XFree86 doesn't revert to the old license, distributors are likely going to package the freedesktop fork. It remains to be seen if the major XFree86 developers will follow.

It appears to be pretty recent, and not yet advertised, but freedesktop.org has forked Xfree86 from 4.4 RC2. Note: this independent from their own experimental X server to which everybody is referring (but which is not really ready for consumption yet). If XFree86 doesn't revert to the old license, distributors are likely going to package the freedesktop fork. It remains to be seen if the major XFree86 developers will follow.

It appears to be pretty recent, and not yet advertised, but freedesktop.org has forked Xfree86 from 4.4 RC2. Note: this independent from their own experimental X server to which everybody is referring (but which is not really ready for consumption yet). If XFree86 doesn't revert to the old license, distributors are likely going to package the freedesktop fork. It remains to be seen if the major XFree86 developers will follow.

Can we get rid of the X11R6 subdir? (once again, stop thinking X is a world to itself)?

Yes. This is being done for the Freedesktop.org X server. See here for more information. And about time! Another thing is that the horrible imake system is being removed (I personally would like to see it taken out behind the barn and shot). Looks like these guys are serious about dragging X into the 21st century.

Q: Couldn't we just write a wrapper for XFree86 drivers and use them?

A: Essentially, no. There are a large number of calls from XFree86 drivers into XFree86's DDX layer. Furthermore, XFree86 drivers don't support acceleration in the same way, so offscreen pixmaps wouldn't be supportable as far as I know.

What other alternatives are there to Xfree?

There are not suitable alternatives for end-users on Linux and BSD on recent hardware. freedesktop.org is an experimental play-area for developers where exciting new features are currently being developed not mundane things like updated drivers for newer video cards (Radeon 9600, 3rd party 9200LE, newer Intel 845 series, etc.), not robust "production quality" software for end-users, Xouvert doesn't actual have any unique code of their own the last time I looked, and Y Window system is more an idea and a work in progress.

Freedesktop X server
y windows

No, from what I'm told, the main reason to fork is the attitude taken by some members of the XFree Core Team. As you said, its their code and they can do what they want but the forking has already happened:

Xouvert
Freedesktop
Cygwin X

Personally I don't see myself ever using XFree 4.4 and am looking forward to a complete release of fd.o. When that happens, I'll likely be moving everything I can off XFree but that's just me.

Maybe its time to get more people looking at Xserver?

A couple thoughts --

I've gotten used to using ALT-TAB to switch between apps, as in browser to word processor, so for me, tabs are great. Sure, I can bundle like app windows under Windows or Linux, but that just doesn't fit my personal style. Go figure.

On the other hand, by using tabbed browsing, you lose about 50% of your screen to tabs for all the windows you have open, right? I value my real estate more than most people then.

I hear you about screen real estate. But then you have me confused; what browser do you use that takes up half the screen just for the tabs? Does Opera do that? I haven't messed with it in a while, as Opera had problems rendering Japanese. Firefox uses barely a pinky's-width, about as much as the URL bar. Maybe as much as 1/8 of the screen for the app bar, menu bar, URL bar, tab bar, and status bar together.

If you rely on your web browser for window management then your operating system is lacking or you are not using it correctly. Which is why tabbed browsing is abhorrent.

I smell a stylistic issue here. Your response nicely showed that my points were partly based on my ignorance of your experience. Forgive me for that. However, "you are not using (your OS) correctly" seems to carry things a bit too far -- part of any good system is the flexibility to use it in many different ways, no? If I choose to group my browser windows in the browser, I fail to see what sin lies in that.

Ahh and the inevitable personal attack,

Actually, a fine point, but I think I was attacking your comments to the effect that *nix systems don't manage windows well. Nothing ad hominem in that.

I use Redhat 9.0 when I'm not using Windows, but I've used several different distros and window managers in the past. The high level of fragmentation in Linux makes window management even more difficult, as one method for management will work fine on one desktop, but it won't on another without configuring it the same way first.

By "desktop" I assume you mean either "windows manager" or "linux distro", rather than the various virtual desktops provided in a single X session. If this is correct, your statement is quite similar to "window management doesn't work the same on several different OSes.

Um, yes. Windows and the Windows window manager are inseparable; the OS and the desktop are one and the same. Swapping desktop managers under linux is effectively similar to changing the complete userland OS under the Windows monolithic paradigm. To exaggerate a little, your comment is a little like "it doesn't work the same on Mac as it does on Windows". Or for the linux savvy, "Gnome and KDE are different." No surprises there.

I'll grant you that a greater level of standardization would be lovely, not just for the end user but for developers as well. I think that's what the Freedesktop.org project is all about, so this is in the works.

Windows tends to act very predictably no matter where you find it, however.

You bring up a good point here -- Windows, through its hegemony, offers a common user experience. There is something of value in this, and the OSS community would be unwise to sneer. Thankfully, many seem wise enough to save the baby from the bathwater, and are putting in the effort to find what works in Windows.

To hearken back to your earlier posting:

Everything in MS applications looks and feels the same, this is what has enabled MS to keep the desktop, and it's a key point of failure for linux on the desktop.

A good point -- the Principle of Least Surprise plays in here. Users expect a particular look and feel, in terms of where menu items are if not necessarily the specific widget set. Straying from this de facto standard of expectations will almost inevitably make a program less popular. Ask anyone who's used Adobe graphics products versus, say,

Actually what I'm thrilled about (even if others say its horribly inefficient) is the 3D accelerated desktop that is supposed to be in Longhorn, and doing away with 2D acceleration. The Mac has it, why can't we?

The guys at freedesktop.org are working on exactly that.

All of you that say that it is hard to read are:
a) reading code that wasn't meant to be cute, but was meant to work where nothing else was as practical,
b) reading code that was written by someone that didn't know perl, or are
c) reading code written by someone that knows perl a LOT better than you.

When a technology's proponents start blaming users for not being 133t enough to use it, that technology is probably doomed. The only thing that can save it is the minority who ignore the elitist blowhards and fix the problems that befuddle the masses.

In my personal experience, people that gripe about Perl are the ones that use it least.

So they dislike the technology and avoid using it? Diabolical!

If you really want Perl to thrive (as opposed ot just survive) then you should start by looking at it with a critical eye. You should also listen to the people who have tried it and given up on. Maybe they don't understand how wonderful Perl could be if they would just master it, but they do understand why newbies are choosing to learn Python instead of Perl.

Except that with the Composite and Damage extensions in the X server over at freedesktop.org, there are compositing managers out there that store buffers of each window in RAM and then render them to the screen with extra effects (see http://ktown.kde.org/~fredrik/composite/ and http://freedesktop.org/~keithp/screenshots/ for some examples).

Good point. But Apache isn't a desktop application, its a server one. The "horizontal intergration" is happening elsewhere, such as FreeDesktop.

KDE 3.2 and the soon to be released Gnome 2.6 follow their standards, and a few other minor projects as well!

THIS SECTION CONTAINS MY PERSONAL OPINIONS AND DOESN'T REPRESENT AN OFFICIAL POSITION OF THE XFree86 PROJECT.

The first incarnation of this version of libGLw used eight header files from LessTif, four for each Motif version. LessTif is covered by the GNU Library General Public License (LGPL) whose terms are not compatible with the XFree86 licensing policy. Since the copyright holder of LessTif is the Free Software Foundation (FSF), I asked Richard Stallman, president of FSF and so called "leader of the Free Software movement", permission to redistribute a copy of those eight headers under XFree86 terms, still maintaining the FSF copyright.

Observe that I was not asking him to change the license of LessTif as a whole, but only to allow me to distribute copies of some header files containing function prototypes, variable declarations and data type definitions. Even so, Stallman said no because the files contained "more than 6000 lines of code". Which code? The LessTif headers are mostly copies of the Motif ones and don't contain any original GNU "code"! I can't still imagine a reason for Stallman's negative answer except for paranoia. He seems to ignore what Motif is and that LessTif's API is simply a copy of Motif's one.

After spending some time, I made my own headers, that became much smaller than the previous ones because I included only a subset of the Motif API and merged everything into four files: 417 lines instead 6000. Humm, perhaps I should be grateful to Sallman too :-).

The poster talks about Redhat rejecting XFree86 4.4. But fails to supply a link.

Redhat's rejection

If you think this is flamebait, visit the projects' websites and take a convince yourself of the facts.

They're changing their license, even though XFree contains GPL code.

They might well be writing FREEWARE (don't confuse gratis with freedom, there) but I think they probably would care if their code wasn't being used by anywhere near as many people as it was previously.

GNU/Linux wouldn't be without a graphical desktop, there's a wealth of projects out there.

Please take a look at http://www.freedesktop.org/

This could be a good thing. If this continues to be a problem, it could drive a lot of people to the freedesktop.org XServer implementation. This looks like it will come to be a much better implementation anyway, and will almost certainly develop faster in the future, given the same resources as XFree86. If a considerable number of developers/distributions worked on getting the XServer up to speed, with proper driver support, it would probably be better for everyone.

• xserver - the experimental, kdrive-based branch started by Keith Packard
• xorg - the X release of the newly-reformed X.org Foundation.

• xserver - the experimental, kdrive-based branch started by Keith Packard
• xorg - the X release of the newly-reformed X.org Foundation.

Hi Donnie,

We currently have no plans to ship XFree86 4.4.0 in the future.
Red Hat is a strong supporter of open source software and
technologies, and the new XFree86 license seems to be intended to
restricting existing freedom for no real world technical or other
gains. At least no gains that are beneficial to the community.

Richard Stallman of the Free Software Foundation has expressed
his concerns publically about the new XFree86 license and it's
incompatibility with the GPL. Many others in the community
object strongly to the new license as well.

Branden Robinson of the Debian project has put together a list of
license related issues contained in XFree86's source tree, and
efforts are underway to remove code which is considered to be
non-open source, or under too restrictive of license terms.

Our current plan, is to use the freedesktop.org xlibs for the
client side libraries. For the clients, utilities, X server, and
other bits, we have not yet made a 100% solid decision, however
a couple of alternatives are being explored. The details are
not yet completely decided, however one thing that is decided, is
that the XFree86 license version 1.1 is unacceptable.

X11 has sorely lacked such an open and collaborative development
environment for a very long time. It's now time for the open
source community to unite and work together on solving this
problem together, and give X11 permanently back to the community!

I very much look forward to working together in collaboration
with yourself, the Debian project, FreeBSD, Mandrake, SuSE, X.org
foundation, the other BSDs, and any/all other interested parties
on a true open source solution for the needs of X11 users and
developers.

Take care!
TTYL

freedesktop.org's code will be placed under free licenses that encourage wide use; most commonly, the LGPL for libraries, or an X-style license when appropriate.
link

...to XFree86 but I don't see them making any new friends by doing this kind of thing. As soon as
alternatives are more mature, XFree86 will feel the heat.

And as for the Free in XFree86... Hmm..

A fundamental API like you're describing would be the 'lowest common denominator' between the two systems. No KIOSlaves for KDE and no Nautilus integration & panel applets on GNOME. Kinda like AWT from old java, and we all know how much that sucked.

A much saner approach is to ensure that the basic stuff is compatible. Window manager hints, preferences etc. Let application authors write with their preferred toolkit, but ensure it doesn't affect users.

Almost all linux users have both toolkits installed anyway. Yes, I realise some KDE users won't have gnome (Gentoo hackophiles etc.) however if they want to use CoolGnomeApp1.0 they'll just install some librarys and they're away.

Lindows, Xandros and Mandrake meet your specifictations.

1 Lindows sells a DVD player for Linux for the very low cost of $5! For any distro.For writing CDs, use K3B

2 Linux has an online community, plus linux users arent that hard to find. Most have heard of linux.

3) Better wine will come in time. The most important apps already run well, the minor apps that use weird libraries will come soon

4) Most desktop distros use KDE these days, and KDE of course is very tweakable.

5) Yes, most commerical distros have simple language, with printed instruction manuals with lots of help

6. Most distros autodect windows/other os partitions these days, and KDE comes with a LILO configurator. Grub is a lot easier than lilo

7) Lindows has click and run, Xandros has Xandros Networks, Mandrake has RPMdrake (graphical) and urpmi (command line), Fedora has yum and Debian and Debian based Distros have synaptic (graphical) and apt-get (command line). Dependancies have been solved ages ago.

8) Both KDE and Gnome have a "tray", in gnome they call it "notification area", and they have standardized the tray so they can share each others icons See here

9) It depends on the distro. Some distros are lighter than others. But many legacy files are being removed (How many distros come with fvwm any more)

10. The other stuff is being solved too. Try Mandrake 9.2 and you will see that most of your points have been solved!

As far as menus and icons go, there are standards and solutions out there, they just have yet to be finalized and implemented on a wide-scale basis.

Desktop Entry Specification
"Both the KDE and GNOME desktop environments have adopted a similar format for "desktop entries," or configuration files describing how a particular program is to be launched, how it appears in menus, etc. It is to the larger community's benefit that a unified standard be agreed upon by all parties such that interoperation between the two environments, and indeed any additional environments that implement the specification, becomes simpler."

Desktop Menu Specification
"This DRAFT document defines how to construct a user-visible hierarchy of applications, typically displayed as a menu. It allows third-party software to add menu items that work for all desktops, and allows system administrators to edit menus in a way that affects all desktops."

As far as menus and icons go, there are standards and solutions out there, they just have yet to be finalized and implemented on a wide-scale basis.

Desktop Entry Specification
"Both the KDE and GNOME desktop environments have adopted a similar format for "desktop entries," or configuration files describing how a particular program is to be launched, how it appears in menus, etc. It is to the larger community's benefit that a unified standard be agreed upon by all parties such that interoperation between the two environments, and indeed any additional environments that implement the specification, becomes simpler."

Desktop Menu Specification
"This DRAFT document defines how to construct a user-visible hierarchy of applications, typically displayed as a menu. It allows third-party software to add menu items that work for all desktops, and allows system administrators to edit menus in a way that affects all desktops."

1. I'm just saying that it would be nice if enough people could sit together (even if virtually on a mailing list) and work out a common set of guidelines.

Seems like Robert Love is looking into getting X/GNOME up faster (skip to after first picture). Obviously he's focused on GNOME but with any luck the techniques he uses and general X bits can be pushed to or KDE directly for wider usage.

XFree86 is no longer relevant; XFree86.org can go jump off a bridge for all I care. Now there is Xouvert and also Keith Packard's KDrive server at freedesktop.org. Why are they trying to force a license change when they should be fighting for the right to still even exist? If they don't do something, people are going to drop XFree86 in droves and move to freedesktop.org's server for the eye candy alone. As soon as the driver support is there, XFree86 is gone.

"If XFree86 doesn't back out, it could spell doom for the project as a whole,..."

Hmmm...do I smell Xouvert? or perhaps freedesktop ?
Regards,
Steve

I thought FreeDesktop.org were already working on this.

What would be the difference between xclip -o and xclip --paste ?

They would both output the selection buffer.

xclip is a command line program intended to bring X selection buffer data to the comment line. Surely you are not suggesting that it should be the mechanism for copying and pasting in the GUI! That is outside the scope of xclip entirely.

You seem to be having the same problem a lot of people (and programmers, and programs) have: Distinguishing between the selection buffer and the clipboard.

When something is highlighted, the clipboard is not touched. Instead the selection buffer is filled. When something is deselected, the selection buffer either is emptied or left alone. The correct behavior is to leave it alone. Only when the user sends an explicit copy command should the clipboard be overwritten. Middle-click should not access the clipboard (reference).

The only difference between X and Windows in this respect is that the user can directly access the selection buffer via the middle mouse button.

Confusion between "clipboard" and "selection" is the ONLY problem X has with in this area.... apart from the data-type thing that is, which I agree is a problem for both buffers.

xclip, despite the name, deals with the *selection buffer*. Thus you can "select" text from a pipe, a handy feature indeed.

xclip should be renamed xsel, or something, and then one could create a xclip program which copies from and pastes to pipes. That would be okay. But even then calling xclip should in no way affect any GUI, because it is not supposed to do that.

Binding a GUI shortcut to a theoretical xclip --paste would only succeed in dumping the clipboard to STDOUT... which would just go away. It would never reach an GUI application.

How does xclip solve the problem? It does and it doesn't If you're looking for something which can paste at the mouse pointer independantly of the active application, you're out of luck. But xclip DOES allow you to grab text from the command line and transfer it into a GUI program with ease. That is the desired EFFECT, even if the exact method is not what was described.

this is rated intersting?

stop being ignorant!

I would argue to say that fonts on MY linux box look a hell of a lot better than a windows box. they are ALL antialiased. it's pretty.

why is it always A.C.s I get into arguments with.

Is XCB what you're looking for? I don't think it was written by masochists.