Slashdot Mirror

Desktop Linux really needs a unified place for specifying what application handles what mimetypes or protocols.

Something like this?

I like visiting the freedesktop.org specs page, it makes me feel like the linux desktop is finally standardizing.

Desktop Linux really needs a unified place for specifying what application handles what mimetypes or protocols.

Something like this?

I like visiting the freedesktop.org specs page, it makes me feel like the linux desktop is finally standardizing.

I'm sure you'll be flabbergasted by this and this then!

* Linux Adds HAL

In the Project Utopia context, HAL is not like the NT HAL. The Project Utopia HAL is more of a database of devices attached to the system and their capabilities. I believe its an 'abstraction layer' in that it provides a uniform API to multiple datasources of hardware information and is meant to be operating system agnostic (from the client point of view).

A FAQ about it is here.

* Linux Adds HAL

In the Project Utopia context, HAL is not like the NT HAL. The Project Utopia HAL is more of a database of devices attached to the system and their capabilities. I believe its an 'abstraction layer' in that it provides a uniform API to multiple datasources of hardware information and is meant to be operating system agnostic (from the client point of view).

A FAQ about it is here.

You can draw GTK+2 apps using Qt widgets but that doesn't magically give the applications DCOP interfaces

Well designed X apps should work under any standards compliant window manager

What if your your window manager isn't standards compliant?

I bet your window manager doesn't support Xembed standard, which happens to be the way konqueror uses to embed java applets to the window.

Also, will drop shadows and tranlucency work with any windows manager (i.e. XFCE4), or do I have to be running Gnome/KDE?

Yes, I'm using e16 and everything works as advertised. As far as I know, no window manager supports Xcomposite natively yet. There is a tiny application in Xorg CVS called transset that you can use to set transparency on windows in the meantime. But you also need xcompmgr to enable Xcomposite first, since its disabled by default until it is ready for prime time.

Also, will drop shadows and tranlucency work with any windows manager (i.e. XFCE4), or do I have to be running Gnome/KDE?

Yes, I'm using e16 and everything works as advertised. As far as I know, no window manager supports Xcomposite natively yet. There is a tiny application in Xorg CVS called transset that you can use to set transparency on windows in the meantime. But you also need xcompmgr to enable Xcomposite first, since its disabled by default until it is ready for prime time.

Maybe the 6.8 hiding thing was because of Bug 1060
http://freedesktop.org/bugzilla/show_bug.cgi?id=10 60

It's basically a "problem" that causes a library not to be built (libXp.so.6) by default, and this library is used by several programs (both the blackdown and sun java runtime binaries for starters, so these won't run, crashing your browser).

I sincerely hope that this library gets built by default, it doesn't hurt anyone...

Apparently the announcement was a hoax:
more information will be released later today.

Announcement"

----
on Wed, 08 Sep 2004 13:34:10 +0100 Alan Cox wrote:
>
>On Mer, 2004-09-08 at 09:10, Linux Power wrote:
>> xorg 6.8.0 released
>>
>> http://freedesktop.org/~xorg/X11R6.8.0/src/
>
>Link missing from /~xorg btw (that still only has 6.7.0).
>
>Alan
>

we know.

someone made an announcement without authorization from the x.org release
team.

leon
----

For those of you not keeping track of the mailing list, I present you with the following:

http://freedesktop.org/pipermail/xorg/2004-Septemb er/003013.html

For the lazy of you, I paraphrase: someone made an announcement without authorization from the x.org release team.

Towards the end of the pixmap bug report you can see that one of the developers provided a fix that appears to have solved the problem.

According to the Changelog the fix went in on 2004-08-27 (Fix for XV memory allocation) and is in the branch for 6.8.0.

Towards the end of the pixmap bug report you can see that one of the developers provided a fix that appears to have solved the problem.

According to the Changelog the fix went in on 2004-08-27 (Fix for XV memory allocation) and is in the branch for 6.8.0.

That's the 6.7.0 release notes For the new release, you might want to check this link instead.

This is awesome! From section 3.3 of Release Notes:

The nv driver for NVIDIA cards has been updated as follows:

* Support added to the nv driver for the GeForce FX 5700, which didn't work with XFree86 4.3.
* The driver now does a much better job of auto-detecting which connector of dual output cards the monitor is attached to, and this should reduce or eliminate the need for manual xorg.conf overrides.
* The 2D acceleration for TNT and GeForce has been completely rewritten and its performance should be substantially improved.
* TNT and GeForce cards have a new Xv PutImage adaptor which does scaled YUV bit blits.

http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOTE S3.html#3

Dropshadow screenshots
http://ruinaudio.com/Xorg-xcompmgr.png
http://jserv.sayya.org/misc/matchbox-gcin.png
http://jserv.sayya.org/misc/matchbox-xcomposite4.p ng
http://img3.exs.cx/img3/6458/screen_lynucs_1759409 500411796a9ba106_1.jpg

Translucency screenshots
http://freedesktop.org/~mallum/argb.png
http://freedesktop.org/~krh/Screenshot.png

Dropshadow screenshots
http://ruinaudio.com/Xorg-xcompmgr.png
http://jserv.sayya.org/misc/matchbox-gcin.png
http://jserv.sayya.org/misc/matchbox-xcomposite4.p ng
http://img3.exs.cx/img3/6458/screen_lynucs_1759409 500411796a9ba106_1.jpg

Translucency screenshots
http://freedesktop.org/~mallum/argb.png
http://freedesktop.org/~krh/Screenshot.png

Here for 6.8.0.

the transluency effect doesn't look quite right to me.

You can see from one of the screen shot the hour hand of the background xclock having exactly the same dark green color over the spots where two transluency windows overlapped and where only one transluency window is on top of it.
May be the calculations stopped at the first level?

I really wish the default font situation would be better in the world of X and nix/bsd distros.

The problem is that apple and microsoft have both invested a lot of money having people hand-tune their fonts, and do not allow linux distro's to distribute their fonts. But you CAN download and install the windows fonts for free and have identical fonts to your XP setup on your linux box. In debian it's as easy as "apt-get install msttcorefonts". Most distro's have specific one-liners that will install the fonts for you, and there is a more involved generic routine as well.

The open source community does have the bitstream vera fonts to include with distro's, and they are very nice, but they're not quite as good as the windows fonts.

I think it would be nice if the distro's gave you an "install windows fonts" link in the start menu post install. But that's really the only criticism I have of fonts on linux right now. After all, if you have fontconfig installed, installing fonts can be as simple as copying them to the .fonts folder in your home directory.

present in X11R6.8

There is no X11R6.8 as yet .. X.org Release Status

I think they've already missed 3-4 planned release dates(See Deadlines)

present in X11R6.8

There is no X11R6.8 as yet .. X.org Release Status

I think they've already missed 3-4 planned release dates(See Deadlines)

See here.

There isn't an official time-table, just the information I've gleaned from lurking on mailing lists and whatnot. If you look at the xserver mailing lists from around this winter, you can piece together the basic plan.

Of course, the key piece here is Cairo/Glitz, which is already quite usable.

There isn't an official time-table, just the information I've gleaned from lurking on mailing lists and whatnot. If you look at the xserver mailing lists from around this winter, you can piece together the basic plan.

Of course, the key piece here is Cairo/Glitz, which is already quite usable.

You want IPC? On UNIX? Have you heard of little things called "pipes" and "shell scripts"? : )

On a more serious note, this sounds like a job for freedesktop.org. You might find the bit about CORBA (the first bullet on the page) interesting...

Um, no. Both KDE and GNOME are implementing the freedesktop.org standard for MIME. Actually, pretty much all new features on both platforms seem to be coordinated through freedesktop.org, so they are getting more compatible over time. A good thing.

Read more here:

http://www.gnome.org/~jrb/files/mime/

http://freedesktop.org/Standards/shared-mime-info- spec/shared-mime-info-spec-0.12.html

More to the point than you might think.

NX actually uses RDP to achieve the low-bandwidth solution that is still capable of displaying a whole desktop and still retaining responsiveness.
And Microsoft put a huge amount of research into RDP, and it's what they've been using for their Terminal Server and Remote Desktop applications for a _long_ time now.

My personal experience is that Remote Desktop from my home box is more responsive displaying the entire desktop and all apps(fuldc++, Ultraedit, Miranda, Virc, CodeWarrior) than X11 is with just one app(Codewarrior for Linux) from the same machine to the same machine via the same connection.

I bought NX a while back and use it to control some of my machines when I went to South Africa for christmas. I used it to run an Gnome - Evolution session on a machine here in Seattle.

NX does not use RDP for X sessions. NX uses careful caching of the X11 protocol, along with a library that pretends to be xlib. NX is capable of handling RDP, but then it uses its own optimised version of RDP. It doesn't use RDP for X. I'm pretty sure about this, because I downloaded the GPL source they provide and made a working version (which was not easy. :-) ). I eventually bought it for the convenience of the wrapper applications they provided.

X11 has serious issues with slow links, not because of bandwidth requirements, but because xlib requires a stupid number of synchronous queries for many operations. One estimate I have seen, is that around 300 X packets have to make a round trip before a window will open (in older versions of X, without the Render extension). On a local session, this is all short circuited and you don't see any delay. On a link with (say) a 300ms delay, you are looking a 300*300ms delay, even though each packet is minute.

Keith Packard has done a lot of work on adding extensions to X that mitigate this. Also, there is work on writing a library the implements the X protocol that is completely asynchronous and caches data when possible (which is sort of what the NX .so replacement for xlib does).

NCB can be found here, at http://freedesktop.org/Software/xcb.

I agree with you. Current X is dog slow over high latency links.

Soon, we'll have the XDamage extension too, which will help a lot. It's at http://freedesktop.org/Software/XDamage

As an aside, I am very pleased we have moved away from XFree. X.org should be a massive improvement.

More to the point than you might think.

NX actually uses RDP to achieve the low-bandwidth solution that is still capable of displaying a whole desktop and still retaining responsiveness.
And Microsoft put a huge amount of research into RDP, and it's what they've been using for their Terminal Server and Remote Desktop applications for a _long_ time now.

My personal experience is that Remote Desktop from my home box is more responsive displaying the entire desktop and all apps(fuldc++, Ultraedit, Miranda, Virc, CodeWarrior) than X11 is with just one app(Codewarrior for Linux) from the same machine to the same machine via the same connection.

I bought NX a while back and use it to control some of my machines when I went to South Africa for christmas. I used it to run an Gnome - Evolution session on a machine here in Seattle.

NX does not use RDP for X sessions. NX uses careful caching of the X11 protocol, along with a library that pretends to be xlib. NX is capable of handling RDP, but then it uses its own optimised version of RDP. It doesn't use RDP for X. I'm pretty sure about this, because I downloaded the GPL source they provide and made a working version (which was not easy. :-) ). I eventually bought it for the convenience of the wrapper applications they provided.

X11 has serious issues with slow links, not because of bandwidth requirements, but because xlib requires a stupid number of synchronous queries for many operations. One estimate I have seen, is that around 300 X packets have to make a round trip before a window will open (in older versions of X, without the Render extension). On a local session, this is all short circuited and you don't see any delay. On a link with (say) a 300ms delay, you are looking a 300*300ms delay, even though each packet is minute.

Keith Packard has done a lot of work on adding extensions to X that mitigate this. Also, there is work on writing a library the implements the X protocol that is completely asynchronous and caches data when possible (which is sort of what the NX .so replacement for xlib does).

NCB can be found here, at http://freedesktop.org/Software/xcb.

I agree with you. Current X is dog slow over high latency links.

Soon, we'll have the XDamage extension too, which will help a lot. It's at http://freedesktop.org/Software/XDamage

As an aside, I am very pleased we have moved away from XFree. X.org should be a massive improvement.

The decompression part of this driver is in the kernel. This allows applications to get at the uncompressed (or "decoded") videostream through the v4l (video4linux) programming interface.

That's all fine and dandy, you may think. Not so. Nowadays applications shouldn't use these kernel interfaces at all. They should use media frameworks like GStreamer. If they did, the driver core could remain in the kernel, while the decompressor would be a special video-source plugin for GStreamer that talks to the kernel driver through some private interface.

The decompressor code could remain in userspace, where no one gives a flying fsck about its license. Applications would be more portable, and could use any video source instead of only v4l devices. Plus, it would be much easier to reverse engineer that damn decompressor, put it under the GPL, and be done with it.

I see the misinformation campaign continues. Let me quote from the site itself: "None of this is "endorsed" by anyone or implied to be standard software, remember that freedesktop.org is a collaboration forum, so anyone is encouraged to host stuff here if it's on-topic".

In other words, this is merely a hosting site. Except for its smaller size and narrower focus, it's not any different from freshmeat or savannah. The software at fd.o is not official and not required for desktops to use. They are not standards which must be adopted for "freedesktop compliance". While there have been a few people clamouring to make X.org the "official" X11 of GNOME and KDE, frankly it's not going to happen.

To take a specific assertion, "While freedesktop.org is, in many ways, a fairly loosely organized community project, we're all really minions of Havoc": this is completely wrong. Havoc Pennington is an employee of Redhat and a GNOME developer. He has no authority over X.org, KDE, XFCE or any other project outside of Redhat and GNOME. He has extremely little input to any of the projects hosted at fd.o.

Freedesktop.org started out as a great idea, and for a while it was very useful. But then it got infected with politics, and quickly lost most of their relevancy. If not for their recent hosting of independent software projects, they would have faded into obsurity. Frankly, would anyone care about fd.o if X.org wasn't hosted there?

The above url was mistyped.

Freedesktop ClipBoard Specification

Thanks for the info!

The X developers should rewrite the server from scratch using the Aspect Oriented methodology and for example the AspectJ programming language. Many of the X extensions really touch all parts of the server which is exactly the kind of problem aspect oriented programming was designed to solve.

Using AspectJ, an extension such as the Damage extension could be written in a weekend.

Also rewriting the server in AspectJ would allow the developers to leverage the full power of the Java language. With Java reflection the core dispatch code in the server could be replaced by just a few lines of code. The RENDER extension could be completely removed from the server and replaced by using the delegate design pattern to forward X requests to Java2D

The Fresco project had huge potential, but never managed to escape the legacy language C++. It seems everybody working on window system is stuck in the software engineering practices of the seventies.

I know I'm going to get flamed by all the 80x24 textmoders out there, but compositing is cool

It is up to the hardware vendors to make sure their drivers are compatible with the linux kernel. If the vendors don't see a market need for Linux drivers, they wont spend the time & money to create them. Without drivers, the market stays small.

The easiest way for vendors to get and maintain Linux drivers is to release the specs or source code to the kernel developers and let them maintain it! But vendors are nervous about competitors learning secrets from the driver code about the internals of the hardware, so often they dont.

The rest of the problem is handled by Project Utopia

Project Utopia is really an umbrella project of a bunch of smaller open-source projects. Included are the 2.6 Linux kernel, udev, HAL, and other policy pieces like gnome-volume-manager. From the end-user perspective, the idea here is plug-and-play in the non-techinical sense. When you plug in a piece of hardware, it should Just Work.

I submit my #9 Imagine128 graphics card, which I never did get to work under RH9, despite it being in the list of supported cards. Oh well.

Those should be supported. I am using an old Revolution 3D in one of my computers, which uses the same driver, and it works fine. I don't know how they cope with autoconfiguration, but using simple text-mode tools to generate an XF86Config/xorg.conf file worked fine for me.

Here is the documentation for the i128 driver in X11R6.7.

sorry about that, here the hyperlink to that site: qtk-qt

-kaplanfx

Yes there is you idiot. http://www.freedesktop.org/

See freedesktop's basedir spec. Being from freedesktop, it's likely to see wide-spread adoption (hopefully soon including the LSB).

See freedesktop's basedir spec. Being from freedesktop, it's likely to see wide-spread adoption (hopefully soon including the LSB).

I don't see how GNU/Linux could possibly be both "ready for the desktop" and the kind of system I would want to use. I don't want something easy to use. I don't want something with shiny a fisher-price GUI and hardware deccelerated anti-aliasing. I want something fast and powerful. I want a system that stays out of my way, and does what I tell it to. There's no way this could even remotely resemble the system for Joe lUser's Desktop.

While I agree that Linux-based apps and libraries need to standardize, I think we need to be cautious as to what standards we decide to use. By using standards we lose the flexibility that makes Linux systems so good today. Standard API's are relatively harmless, but other standardizations are more bothersome. Standardizing on the UI means that you have to get the GNOME and KDE people to agree on which order the buttons go -- but which way is right? Picking one over the other would alienate a lot of users, and there's no clear right or wrong. It's easy to think that standards will solve all our problems, but a lot harder to think of reasonable standards that work.

1. X is not bloated. Have you run X, by itself, with no window manager to hamper it, or even with a "light" window manager? It flies. The only speed problem I've had with X was that when I'm dragging windows around, the other apps freeze (because X is single threaded). I'll admit X is hard to deal with, but in most modern distros it works right out of the box on most hardware, so you don't have to mess with it.

2. Standardizing Window Management
There already is a standard:http://freedesktop.org/Standards/wm-spec

3. Almost all configuration changes can be made with a text editor. Click Click.

4. What isn't there a GUI version of? I mean, you can't really do one for 'sh', 'less', 'more', and 'cd', and I think all the other ones have been covered.

5. I personally am not waiting for the world to change. I will use what I want. If other people find Linux-based systems useful, more power to them. The only reason I might want more people to use Linux is for more hardware support, and since I consider that a pretty selfish reason, I don't think about it.
Here you say 'OS' when you mean 'Desktop Environment'. Don't confuse the two. The 'Desktop Environment' should provide a basic interface. Without some amazing AI, any attempts to actively help the user would be clippy all over again. It's better for the 'Desktop Environment' to be a passive entity that the user manipulates.
I'm not saying that you should know TCP/IP before using a web browser (you don't even need to know that to use lynx), so this is a strawman.
Secondly, no one "expects" people to learn the CLI to organize their pictures and .swx files. There are a bazillion file manager utilities out there, and I'm sure they can click click all they want until they finish. If they really want to leverage the benefits of running a *nix environment and get it all done in a single 200 character long command, however, they're going to have to use the CLI. There's no way around that.
I dare you to design a GUI with as much flexibility of the CLI:
1. Automatically recognize new unfamiliar commands and their arguments, and integrate it into the GUI in a rational way.
2. Support the combination of innumerable unspecified commands and their arguments to perform an unspecified task (this may require a new paradigm, because pipes don't make much sense in the GUI world...)
3. Support basic programming constructs such as iteration and conditions, without alienating basic users.
3. Be fast and small.
Do all that and the Linux environment would become the most accessible system around, with all the power accessible to those without mad CLI skillz.

Myself, I don't think it's possible, so I'd rather stick with my shell scripts and 7331 645H 5K1775, and avoid the bloated, slow GUI stuff.

Could this be the beginning of a multimedia framework for GNU/Linux?

Could this be the beginning of a multimedia framework for GNU/Linux?

Try Gstreamer for that.

1. Jettison the whole gconf/registry thing in favor of a tree of plain text config files in .gnome or something

3. Give me a default window manager with the ability to select focus-follows-mouse mouse

5. Choose: either a) reincorporate gecko into Nautilus for Web browsing or b) go lightweight and jettison Nautilus for the old gmc

6. Create a base distribution of official GNOME applications from a lot of the GTK stuff out there, based on which authors agree to follow a rigidly follow a GNOME style guide and use the GNOME API rather than just GTK, so that there is more desktop consistency

7. Add compatibility with KDE themes to GTK, since they seem superior (ability to change colors, not just widget styles, etc.)

8. Give me an "advanced mode" to turn on all kinds of extra GUI configuration bells and whistles like keybindings, autoraise, MIME types, etc.

Arggh... I'm am sick of fools like you jumping into this discussion. You, like many zealots, have no real idea what you are talking about and just jump straight to the extremes without considering the middle ground.

*ahem*

Anyhow, GET A DIFFERENT FUCKING WINDOW MANANGER AND QUIT FUCKING COMPLAINING. There are lots of WMs that conform to the WM spec, try one out and shut your hole. Metacity is fast, and it Just Works. In fact, I've forgotten I even have a seperate window manager... just like it should be.

They're here: http://freedesktop.org/~keithp/screenshots/

The OS-level ability to use the 3D acceleration features of the card by more than one application at a time may prove to be as important to future computing as the ability to create 2D windows at the OS level. I think we should all unite in an effort toward a new advanced graphics architecture.

Yes.

Anyone find some sample compositing screenshots? I've lost the URL for the KDE ones, and I hear there was some cooler stuff shown by Keith recently...

Some usefull information (although not as clearly laid out as I would like) can be found at on x.org's freedesktop page.

Basically, they say that it started out as XFree86 4.4 RC2, and was started because the new XFree86 license may possibly be incompatible with the GPL. Since then, they have continued to improve the code, so it should be better than the version it split from. Of course, I can only imagine that xfree has been developed to about the same amount, but I don't know the exact differences. There is a changelog at the link I gave.

I don't think there are drastic performance differences between the two versions yet, although aparently work is underway to improve performance in some things that were badly implimented in xf86-4.3.

At this point, I would say that unless you are obsessed about having the latest version of everything, want to try out the new, or have run into one of the specific bugs that is fixed, I wouldn't recommend updating. But the next time you would otherwise update to a new version of XF86, I would go ahead and switch to x.org. It's definately not worse, and it seems to be the future of X on linux for time being. For all new installs I would install x.org.

That said, I just ran "emerge -C xfree" "emerge xorg-x11" so I guess I'll find out if it's worth it (in about a day when it finally finishes compiling).

Some usefull information (although not as clearly laid out as I would like) can be found at on x.org's freedesktop page.

Basically, they say that it started out as XFree86 4.4 RC2, and was started because the new XFree86 license may possibly be incompatible with the GPL. Since then, they have continued to improve the code, so it should be better than the version it split from. Of course, I can only imagine that xfree has been developed to about the same amount, but I don't know the exact differences. There is a changelog at the link I gave.

I don't think there are drastic performance differences between the two versions yet, although aparently work is underway to improve performance in some things that were badly implimented in xf86-4.3.

At this point, I would say that unless you are obsessed about having the latest version of everything, want to try out the new, or have run into one of the specific bugs that is fixed, I wouldn't recommend updating. But the next time you would otherwise update to a new version of XF86, I would go ahead and switch to x.org. It's definately not worse, and it seems to be the future of X on linux for time being. For all new installs I would install x.org.

That said, I just ran "emerge -C xfree" "emerge xorg-x11" so I guess I'll find out if it's worth it (in about a day when it finally finishes compiling).