Slashdot Mirror

Is it sophisticated or poorly designed? Has anyone ever seen an X Application that looked and felt as nice as a native Windows (or Mac OS X) application? Has anyone ever gotten stuff like drag/drop between applications or ICCCM to work correctly? I'd say it's far from sophisticated--it's clunky, ill conceived, and hard to apply effectively.

I believe Windows remote desktop does this
You believe entirely, 100% wrong. Windows does no such thing.

Remote desktop actually works very simply, much like VNC does. It's simpler than using a remote X server as well.

Take a look at the source code for rdesktop sometime. It handles mouse and keyboard redirection, audio streaming (two way), and a video protocol.

Remote desktop "feels fast" because of two things. For one, apparently it has some good kernel level hooks so that where other stuff has to "watch" the frame buffer to figure out changes, remote desktop is notified. It's a much more efficent method, and it means that the client is truly dumb. It doesn't have to know anything about fonts, or widgets, or windows, or anything.

X works quite a bit differently. It also doesn't have to know about widgets and all that stuff. Windows RDP goes "after" everything is drawn and takes a look at the end product - the compisited ready to draw images or portions of portions of the screen. X actually brings the primitives over the wire. Which can be sometimes much, much faster and more bandwidth effective. It depends on the application.

This is a good short inro on xlib programming.

X on UNIX is like GDI on Windows. The issue is in Win32.USER, the window manager. Although X isn't vulerable, certain window managers could be; it depends on how messages are sent between windows.

X performs similar functions to both GDI32 and USER32. Specifically, it does perform the USER32 function of passing events to windows, and does include a mechanism that one client can use to generate events that will be sent to another client. This works regardless of the window manager in use.

However, when the destination client receives the event, it can easily distinguish between an event generated by the X server itself and one generated by another client. Many X programs, including xterm, ignore events generated by other clients, thus preventing similar holes from being exploitable.

I also believe that it isn't common practice to pass around pointers to code to be executed in event data structures in X, although my actual X programming experience is limited to a low level "hello world" program using Xlib and a solitaire implementation in QT, so I could easily be wrong.

All in all, I'd say any given X application is highly unlikely to be vulnerable to such a problem, but you may find one or two that are.

A lot of people like to be able to select individual windows from the taskbar. If you don't, then you can configure your taskbar to group all GIMP windows together. GIMP sets the same WM_CLASS property on all it's windows (even on plug-in windows) and it has done so since GIMP 1.2. That allows the window manager and your taskbar to easily identify GIMP windows and treat them as a group. You can then minimize/maximize all GIMP windows in a single operation, move the window group to a different desktop or whatever else you want to do...

Now what would be nice if there was an equivalent window manager hint available for Win32. Perhaps there is, and all that's missing is support from the Win32 GTK+ backend?

Time and time again, X11 has showed us that it is better to provide mechanism, not dictate policy--even unto the protocol itself.

Um, X is a textbook example of that philosophy gone horribly wrong.

To its credit, the X consortium tried to rectify their mistake thru the ICCC, but again they fell into the trap of creating something with so much misguided "flexibility" that it's almost impossible to find any apps which actually implement the ICCC in full, let alone cooperate in any meaningful way.

The ICCC has been such a joke, that ten years on something as elementary as copy-paste is still a hit-and-miss affair. And what about projects like the CDE, or Enlightenment? Everybody's who been serious about using X to craft a desktop has felt the need to introduce policy above and beyond what X has to offer. That's not a sign of X's flexibility or time-tested design: it's a sign that X sucks.

Let's hope freedesktop.org manages to beat some shape into the mess that is X, but they'll only succeed if they're willing to provide policy rather than mechanism. Bad policy that's followed by many is much more useful than good policy that's followed by few, or no policy at all.

There can be an arbitrary number of selections, each named by an atom. To conform with the inter-client conventions, however, clients need deal with only these three selections:

• PRIMARY
• SECONDARY
• CLIPBOARD

Other selections may be used freely for private communication among related groups of clients.

And any mention of a possible solution brings down the wrath of nerds who want to keep unix as unintuitive and awkward as possible.

Besides the nuisance of what mouse click or keystroke you use to move text, it's not a clipboard like Windows uses, merely a text buffer. Ie; it's only good for text. You cant copy/paste (and by extension drag and drop) files, bitmaps, etc uniformly between apps.

I think the reason for the two different Clipboards is because the KDE (Or gnome? Not sure if it works the same way) clipboard handles copying content other than plain text and the X-Windows one not.

The atom that a requestor supplies as the target of a ConvertSelection request determines the form of the data supplied. The set of such atoms is extensible, but a generally accepted base set of target atoms is needed. As a starting point for this, the following table contains those that have been suggested so far.

One of the really cool, yet rarely used, features of the selection mechanism is that it can negotiate what data formats to use. It's not just about text. When one application asks another for the selection, part of their communication involves the requester asking the owner for the list of types in which they are capable of delivering the selection data; then the requester picks the format they like best, and asks for it that way.

Can't copy/paste pictures or even a lot of text, because X's crappy clipboard only does ASCII.

• When you write in Gtk+, you can get an application that runs on all the platforms you listed. My gtk+ newsreader Pan runs on Linux, Windows, and Mac OSX.

• The window manager is orthogonal to the topic of what's important from the software maker's point of view: ICCCM compliance is the only feature any application writer cares about. No application requires a specific WM. To do so would needlessly limit their audience.

• Likewise, you're misinformed about Mono: nobody is telling anyone that they have to port anything to Mono. C# is just another language that Gnome supports. Never in the 4+ years I've worked on Pan has anyone mentioned porting Pan to C#.

• gtk doesn't lack documentation. In fact the documentation team has made leaps and bounds over the last year.

• If you prefer RAD tools, Anjuta and Glade are available.

• Discussing Qt as a `modern C++ based toolkit' and disparaging Gtk+ as lacking a `modern API' is just language bias (and ignores moc's pre-STL cruftiness). If you want to use gtk+ in an OO language, many language bindings are available.

Again, this isn't to take anything away from Qt -- its tools are pretty good, and its documentation is excellent. However, Gtk+ is very good too.

I Agree 100% that X clipboard copy-paste support is terrible and freedesktop should focus on that, instead of eye candy and breaking speed records.

I talk about exchange of non-ASCII data through clipboard (I want to emphasize that as I can see that many OSS types think that clipboard is for text only). I mean copying and pasting images, fragments of images (rectangular an irregular shares), with alpha channel; sound clips; video files; HTML with images copied to local application (not some lazy trick where HTML copied from Mozilla to OpenOffice has all HTML untouched and IMGs are still loaded from the network when you save that file and try to open it at home).

The X contains all necessary infrastructure, as explained here and here.

When you actually try to use the X clipboard for something more that transferring plain text, the results are terrible. Read this, this and this Slashdot comment. Shocking.

I love X... but I have to admit that you've hit the nail on the head. It's astonishing how bad cut and paste works between applications. It really only works for text, and then only if the text is flat ASCII. Because it's so bad, many applications have their own, internal version of the clipboard, and you're never really sure whether you're manipulating X's clipboard or the internal clipboard, or what information makes it onto X's clipboard and in what form. It's a total disaster.

The X11 clipboard is already quite powerful and supports a broad array of selection types, not just ASCII. A lot of apps only support ASCII, but that's not X11's problem. If any toolkit or app is reinventing the wheel by implementing a whole new clipboard, that really is quite brain-damaged.

Backing Store
Save Under

Will these finally be supported in XFree86?

Backing Store
Save Under

Will these finally be supported in XFree86?

How is this different from backing store?

I have the following links (I'm trying to write a window manager myself... :-)
I hope these are the ones you lost:

http://www.xfree86.org//4.3.0/manindex3.html
http://tronche.com/gui/x/icccm/
http://tronche.com/gui/x/xlib/ http://x.holovko.ru/Xlib/contents.html

Hope someone finds them usefull...
Creating a window manager, is actually quiet fun, as long as you have others code to look at...

I have the following links (I'm trying to write a window manager myself... :-)
I hope these are the ones you lost:

http://www.xfree86.org//4.3.0/manindex3.html
http://tronche.com/gui/x/icccm/
http://tronche.com/gui/x/xlib/ http://x.holovko.ru/Xlib/contents.html

Hope someone finds them usefull...
Creating a window manager, is actually quiet fun, as long as you have others code to look at...

The problem with this approach (which Microsoft, Apple, etc. recognized back in the '80s but we still haven't caught up with) is the notion that text is not the only thing that needs to be cut, copied and pasted among and across applications.

Thus, there is inherently a different semantic involved when transferring objects other than text, because X doesn't know how to handle those. X knows nothing of moving a picture between a charting application and a word processor, for instance. Nor should it.

This is not true.

See this article by Jamie Zawinsky: http://www.jwz.org/doc/x-cut-and-paste.html

The interesting part:

One of the really cool, yet rarely used, features of the selection mechanism is that it can negotiate what data formats to use. It's not just about text. When one application asks another for the selection, part of their communication involves the requester asking the owner for the list of types in which they are capable of delivering the selection data; then the requester picks the format they like best, and asks for it that way.

As a simple example, suppose there is a program displaying text in multiple fonts. When pasting that into a text-only program, you'd want to paste only the text. But when pasting that into a word processor, you'd want to keep the font information: if both applications spoke HTML, they could use that as the intermediate format by which they transferred the data.

More complex things are possible, too: for example, when an image is selected on a web page, the web page displayer could offer to serve that up as raw image bits; or as JPEG data; or as the original URL of the image. When trying to copy and paste an image into a text editor that can't do images, the text editor might decide that the next best thing would be to paste the filename of the image, or the URL.

The content negotiation mechansim is very powerful, and I wish more applications would take advantage of it.

For examples of how to use it, see the files select.el and/or x-select.el from any XEmacs distribution. There are some utility functions in there that will let you experiment with content negotiation with other apps, see what types the apps are capable of converting to, etc. For example:

(x-get-selection-internal 'PRIMARY 'TARGETS)
==> [ TARGETS TIMESTAMP TEXT STRING LENGTH FILE_NAME OWNER_OS HOST_NAME USER CLASS NAME CLIENT_WINDOW PROCESS COMPOUND_TEXT]

(x-get-selection-internal 'PRIMARY 'FILE_NAME)
==> "http://www.jwz.org/doc/x-cut-and-paste.html"

The problem with this approach (which Microsoft, Apple, etc. recognized back in the '80s but we still haven't caught up with) is the notion that text is not the only thing that needs to be cut, copied and pasted among and across applications.

Thus, there is inherently a different semantic involved when transferring objects other than text, because X doesn't know how to handle those. X knows nothing of moving a picture between a charting application and a word processor, for instance. Nor should it.

This is not true.

See this article by Jamie Zawinsky: http://www.jwz.org/doc/x-cut-and-paste.html

The interesting part:

One of the really cool, yet rarely used, features of the selection mechanism is that it can negotiate what data formats to use. It's not just about text. When one application asks another for the selection, part of their communication involves the requester asking the owner for the list of types in which they are capable of delivering the selection data; then the requester picks the format they like best, and asks for it that way.

As a simple example, suppose there is a program displaying text in multiple fonts. When pasting that into a text-only program, you'd want to paste only the text. But when pasting that into a word processor, you'd want to keep the font information: if both applications spoke HTML, they could use that as the intermediate format by which they transferred the data.

More complex things are possible, too: for example, when an image is selected on a web page, the web page displayer could offer to serve that up as raw image bits; or as JPEG data; or as the original URL of the image. When trying to copy and paste an image into a text editor that can't do images, the text editor might decide that the next best thing would be to paste the filename of the image, or the URL.

The content negotiation mechansim is very powerful, and I wish more applications would take advantage of it.

For examples of how to use it, see the files select.el and/or x-select.el from any XEmacs distribution. There are some utility functions in there that will let you experiment with content negotiation with other apps, see what types the apps are capable of converting to, etc. For example:

(x-get-selection-internal 'PRIMARY 'TARGETS)
==> [ TARGETS TIMESTAMP TEXT STRING LENGTH FILE_NAME OWNER_OS HOST_NAME USER CLASS NAME CLIENT_WINDOW PROCESS COMPOUND_TEXT]

(x-get-selection-internal 'PRIMARY 'FILE_NAME)
==> "http://www.jwz.org/doc/x-cut-and-paste.html"

http://tronche.com/gui/x/xlib/

About three months ago I got sick of all other window managers, so I wrote my own. Writing a window manager was the most fulfilling software project I've ever undertaken.

My window manager now does all the things I want it to do, none of things I don't want it to do, and I'm running it full-time. Running your own software full-time is an experience every programmer should have - you learn to write solid code, as it would really suck if my window manager crashed while I was writing this into Netscape.

I won't go into a diatribe about why I wrote it, but needless to say, it does a number things that all the other window managers I've tried get completely wrong (and yes, I've tried a lot of window managers, including the "configurable" ones like sawfish and scwm).

At some point, I might release my code, but that would probably require putting in hooks for a configuration file (since it's MY window manager, all the configuration I need to do is 'vi main.c'). If there's enough interest, I can go into details about what it does differently and at some point, I might even release some code. I really couldn't care less if anyone else uses this, however. This is MY window manager, and it does everything I want (this is why you should write your own, saying that feels really good).

Anyway, if you know any C, you should try writing your own window manager (think about it - what would be more satisfying, writing another GNOME/KDE applet, or writing software that you'll be using 100% of the time?). Here are the resources you'll need:

• Xlib manual
  You'll need to know Xlib. You can get the xlib manual in troff from XFree86 CVS, or you can read it online at the link above. I found the greppable, linked html much nicer than a big PostScript file.
• ICCCM manual
  You'll need to follow the ICCCM recomendations if you want your window manager to play nice with other apps.
• Extended Window Manager Hints manual
  The KDE and GNOME people say this is the standard for their desktops. Most of the stuff here is pretty simple, but you should look it over first, as it assumes quite a bit about how you implement your window manager (so you should implement it a certain way in order to support the KDE/GNOME stuff).

For reference, it took me about three weeks and 6000 lines of code to get something I could use full-time. You might also want to look at other window managers' code: there's a window manager called '9wm' that's very small and whose code is extremely legible. Trying to read code from Enlightenment or WindowMaker is not the best way to go as these are very large codebases and use multiple levels of indirection (which makes understanding how some detail is implemented very difficult).

I can supply more information for the potential DIY-er if needed.

While we're on the subject, does anyone know of a reference for Motif hints? I would rather not use someone else's code (licensing restrictions, etc), and would like the definitive reference, if such a thing exists.