Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Bettering the Linux desktop -- Portland progress (DesktopLinux.com)
DesktopLinux.com covers the Portland
Project. "Six months ago, architects from two dozen
desktop-oriented Linux projects gathered in Portland, Ore. to work together
on creating the best possible Linux desktop. Thus was born the Portland
Project. Now, in Mainz, Germany, the expanded group is meeting again on May
8 and 9 to see how far it's come and to look at what's ahead."
(Log in to post comments)
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 12, 2006 17:55 UTC (Fri) by iabervon (subscriber, #722) [Link] Every once in a while I look at this sort of stuff, and I'm mystified, because these specifications make assumptions about the interaction pattern that aren't true of my environment. The icons on my desktop represent tasks, not files, and the menu contains programs I've chosen to have quick access to, not whatever wants to be shown there.
It would be interesting if they specified semantics rather than policy for these programs, so that an environment could respond appropriately even if the user's policy choices aren't Windows-like. I'd actually like to have a list of programs that don't need command line options, such that I can pop up a dialog box that lets me tab-complete their names. I really like the idea of having a mapping from mime-types to command lines to handle them.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 12, 2006 18:29 UTC (Fri) by markhb (guest, #1003) [Link] I really like the idea of having a mapping from mime-types to command lines to handle them.Ah, for the days of OS/2 and the Workplace Shell (the one part of Warp that would actually be useful to open-source). I know that BeOS did this too, but I think OS/2 was the first.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 12, 2006 22:51 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] The last thing we want to do is clone the Windows XP way of doing things, where a level on the Start menu is created for each software vendor, and everyone wants their icons on your desktop. Instead of putting a music player under "Sound and Video", they want to put it under "YoyodyneCorp", since they think their company name is more important to the user than what the program does.I fear that the OSDL wants to serve the requirements of third-party proprietary software vendors, who like it that way, though.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 13, 2006 10:20 UTC (Sat) by drag (subscriber, #31333) [Link] Well the thing is is that you have the same situation with XGL and whatnot.
People have said that XGL simplifies the driver model for Linux and makes it much easier for propriatory companies to write drivers for Linux. And it's true that XGL developers have listenned to them and talked to them about the design and such.
So that's a completely true statement.. But it also makes it much easier for people to write Free software drivers also (I mean those type that are full featured with 3d and 2d acceleration)
What we are dealing with, it seems to me, is that with Portland making things better for propriatory developers is not going to happen to the detriment of Free software developers. In fact making it easier for propriatory folks more then likely also makes it easier for Free software folks. It's just there to make it better for everybody.
I think it would be wonderfull that when I install some peice of software from outside any aviable Debian repositories that it would be able to make a proper menu item and such. I have a hard time remembering names of applications, and the menus make it easier to find them.
I also think it would rock that when I am using Gnome that when I use a KDE application that that KDE application would have the smarts to use my Gnome defaults for media playback settings, mime types, browser, email and other stuff like that.
Right now when I am using Amarok and I want to look for a lyric for a song that it can't find it opens up Konqueror.. which is horrible because I use Epiphany for everything else.
If Amarok authors wanted it to be smart enough to figure that stuff out on it's own then that would be a whole lot of work that they would have to do that wouldn't make Amarok any better at playing songs or anything like that. But with Portland it should end up being easy.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 14, 2006 18:18 UTC (Sun) by elanthis (guest, #6227) [Link] "People have said that XGL simplifies the driver model for Linux and makes it much easier for propriatory companies to write drivers for Linux."
Of course, NVIDIA has publicly disagreed, stating that this claim is bunk. :-)
The XGL developers are doing their thing because *they* think it will be better, not because any hardware vendors have asked for it.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 14, 2006 21:21 UTC (Sun) by drag (subscriber, #31333) [Link] What I understand is that Nvidia is happy with AIGLX from Redhat were ATI is working with XGLX with Novell.
Nvidia is just irritated because they have a crapload of features and special things for high end Linux graphics that nobody else has. Going XGL is going to break some driver compatability and it will end up being a set back for Nvidia's propriatory drivers while a boost for everybody else's.
Obviously they aren't going to like that.
Anyways keep in mind that when your running Nvidia propriatory drivers your running THEIR X window server. It's not even X.org's anymore. It uses a lot of code and functionality from your X.org stuff, obviously, but nobody except Nvidia knows exactly how much code your runnign from nvidia or your running from X.org.
So if push comes to shove Nvidia can keep providing their own stuff like they do now.
For why it's going to make it easier to write drivers for the desktop (hopefully) (and that's 2d AND 3d acceleration) see this:
It would end up replacing all that legacy with a OpenGL-driven system and then all a operating system would have to provide to run X would be a compatable OpenGL implimentation (opengl + stuff to handle resolution changes and such). Weither that comes from software-driven mesa, propriatory drivers, DRI/mesa, or something else.
OpenGL as VESA 4? Posted May 15, 2006 2:43 UTC (Mon) by xoddam (subscriber, #2322) [Link] > It would end up replacing all that legacy with a OpenGL-driven systemWith VESA 2.0 and 3.0 a framebuffer driver can use any video card via a BIOS interface; that's the usual stopgap for people with unsupported performance graphics chips (I've never seen the point in a proprietary driver -- framerates have never mattered that much to me). But as 3D and video acceleration become more important to the casual user, perhaps it's time for a VESA 4.0 specification which provides an OpenGL interface in the video BIOS? It might still be a proprietary driver (depending on the vendor), but it would extend support universally and it would put to rest the objections to a proprietary module *inside* the Linux kernel.
OpenGL as VESA 4? Posted May 16, 2006 9:25 UTC (Tue) by drag (subscriber, #31333) [Link] Maybe.
I could see it someday that video cards get a sort of similar thing that modern CPUs do with their ISA's.
For those that don't know you have things called the x86 ISA or the PowerPC ISA. (learned all this from arstechnica.com personally)
This is a sort of hardware shim that provides a common interface for software/machine code. That is all cpus that support x86 ISA should be able to run the same code. That even though the original 486/pentium CPUs were of a CISC design, but that all x86 cpus since Pentium-pro days, use a essentially RISC core they are compatable software-wise because all the extra logic in the cpus that translate the x86 instruction set to something that can be run on modern cpus.
That way you can have vastly different cpus (pentium pro, pentium-d, amd athlon, amd opteron, intel 486-dx, etc etc) be able to run the same software.
So since modern video cards are basicly special purpose computers (they have their own BIOS/firmware stuff, own Memory, own proccessors etc) I figure that they may end up going in the same direction by creating a common video card ISA. Then on top of that they would provide their 'value added' features in the form of supporting this or that propriatory opengl extension or anti-aliasing acceleration feature.
But I dont' see this happen any time soon, especially with only 2 video card manufacturers. Maybe if Via/S3 and Intel start making good cards and maybe you get a open design with the open graphics project you may see some sort of work torwards that direction, but in the current climate of propriatory-features-are-everything in video card marketting I don't think this is likely.
It would certainly make driver/application developer's and user's lives a hell of a lot easier though.
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 13, 2006 19:28 UTC (Sat) by NAR (subscriber, #1313) [Link] Instead of putting a music player under "Sound and Video", they want to put it under "YoyodyneCorp", since they think their company name is more important to the user than what the program does.But it's also a simple and effective way to avoid name collisions...
Bettering the Linux desktop -- Portland progress (DesktopLinux.com) Posted May 14, 2006 18:30 UTC (Sun) by elanthis (guest, #6227) [Link] Nothing that the Portland project is doing is changing the way proprietary vendors can abuse your desktop right now.
Any proprietary application vendor can create a new submenu in your Application Menu today. They could have done that years ago.
These new tools aren't making it any easier for proprietary vendors to screw up your machine. They're just making it easier for both proprietary and open source vendors to ship applications (be they in source or binary format) that can install to any desktop on any distribution.
Right now, for example, if Gaim wants to install a menu entry, the user has to tell the configure script where to put the .desktop file. It might be in /usr/share/applications, but it might also be in /usr/local/share/applications, or /opt/gnome/share/applications, or /network/helpdesk/level1/share/applications. Either the user installing from source or the packagers creating the packages (one binary package for every version of every distribution for the same upstream source package) has to deal with these differences. There's no way to put a "Download and Install" link on Gaim's website that will work anything close to reliably.
With the Portland/FreeDesktop/LSB stuff, this changes. Apps can be shipped in LSB RPMs which any LSB distro shoudl be able to install (preferably with a point-n-click interface like most native-RPM distros), and the LSB RPMs can make use of the Portland integration scripts to make sure the .desktop files get installed to the right path no matter where the distro (or local system administrator) has determined is the right path.
Whether vendors add the necessary fields to their .desktop files to create new superfluous sub-menues is completely disassociated with the Portland integration work. A binary installer (using BitRock, loki_setup, or some other solution) or distro-specific RPM can still drop an irritating .desktop file in /usr/share/applications. The only difference is that the installer will probably only work on a handful of mainstream distros.
In fact, if anything, the Portland API makes things *better* for users that want to keep control from proprietary vendors. As things are now, an installer just drops a raw .desktop file in some path and that's that. If you don't like the sub-menues it creates, or don't want it to create desktop icons, you'll have to manually clean things up after the fact. (And probably after every upgrade, too.)
With the Portland work, the installer/updater instead passed the .desktop file to a script which then copies it to the correct location. The advantage here is that the script can sanitize the files. For example, the menu item script might strip any superfluous categories from the .desktop file, thereby eliminating the creation of any new submenus. A desktop icon script might just be configured to do nothing.
|
|
||||||||||||