Submitted by Six months ago, architects from two dozen desktop-oriented Linux projects gathered in Portland 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.
How many does it take to screw in a lightbulb?
Well, in Fedora Core/Red Hat you have to have find all the light bulb’s dependencies. And Libcompat… And…
In Debian Stable…well good luck finding a version new enough to fit your light socket!
In Linux From Scratch you have to build the house, the light bulb socket and the light bulb. As well as the tools to build everything and the ladder to get to the socket.
In Gentoo it’s almost the same as above…except you get the tools and a really thorough handbook.
In KDE: We’d use lightbulbs but you’d never see them, too many widgets in the way!
In GNOME: We’d use lightbulbs but it didn’t fit in our HID “guidelines”.
In Windows, the virus already took it.
In Mac OS X: iLight wouldn’t burn out so quickly if the construction wasn’t so dodgy…
In Linspire : they would blame GNU/Linux developper for it being broken and GNU/Linux user for pointing it out to everyone else , even do they charged 200$ for it and said it was included and developped by them …
In Freespire : the same thing but would claim its included in Linspire CNR.
In Mandriva : it would be named ampoule and work out of the box but US redneck cowards would boycott it because its french.
In Ubuntu : It would be brown , energy saving and would be shipped gratis from there website , but the Debian user would not like it as its based from there offer but cutting edge and working.
In Slackware : It would be old , rock solid because made from rocks , based on edison design , and needing an edison technician to instal it in the socket.
In PclinuxOS : it would be perfect and fit on every socket known to exist , but its only availaible on there website and nobody beside a select few know about it due to lack of fundings.
In C64/vic 20 : it would be made in basic and needing a fastloader.
In Beos : It would be perfect but plagued by management always dropping the shipping date or running with the money you paid for it.
In OS/2 : it would be good , but the marketing and company selling it would recommand you use the windows one.
In windows 95 it would crash , offering tone of blue and only be avalaible from brick and mortar as not internet availaible.
In windows 98 it would be the same as 98 but would be availaible on the internet as long as no one is targetting you with ddos or mirc connection.
In fluxbox : it would be not know about
in E ( DR17 ) : it would be in development but , trust them there new , next version is going to be uber cool.
In Apple 9 , it would be dead and have had its own going away moment from Steve Jobs.
In Mepis : it would support only the US army socket.
In Knoppix : it would be german enginneered and sold by linuxtag.
In Corel : it would have disapeared but spawn of it would still be availaible today.
In Stormix : it would have disapeeared because they blew there money on marketing instead of lightbulb development.
In Yellowdog it would only be working if you have the Apple socket.
In FSF : it would be Free as in freedom and be called GNU/Lightbulb.
In BSD : it would be designed for no socket but theorically be better then everything else and serve as the base for Mac OS X.
In OpenBSD : it would swear at you and make no light but be called the best by its user.
In OSNews : Thom Holwerda would talk about it in its sunday eve column and Adam would hack it to work with the database and design a cool logo in case it crashed , Eugenia would discuss it , if she felt like it.
In Troll : it would not be used as they dont like to see the light.
get a life, not funny
Different people, different hobbies, I guess
Dude, in Gentoo you forgot:
$ ACCEPT_KEYWORDS=”~socket” USE=”power -dc ac kde qt gnome -gtk gtk2 -darkness filament” emerge -D light bulb socket connection wiring
It wouldn’t work, so you’d go onto the Gentoo forums and ask why not. You wouldn’t get an answer for days, then ten people would tell you to revdep-rebuild, then you’d find out you needed to emerge kde-illuminations and when you’d finished it would work fine for years
Until you decided to upgrade.
I think the real question is how many NetBSD developers does it take to make the lightbulb screw into a toaster and work?
Edited 2006-05-11 02:55
“How many does it take to screw in a lightbulb?”
Well, KDE prefers halogen, and GNOME prefers a lava lamp.
But seriously, if we can get a unified desktop api in Linux yet still have the ease of development and integration of Windows, there will be nothing to stop Linux’s total global lumination.
Edited 2006-05-10 19:32
How many cooks will spoil the broth?
Love this idea. But I found this a little puzzling:
a user shouldn’t need to run KDE to use a KDE application, or GNOME to use a GNOME application. They should be given a choice, but in such a way that it doesn’t fragment the desktop into two different, warring desktop camps.
Hasn’t this already happened (although I think the “warfare” has calmed down since the KDE libraries were GPL’ed). Portland, sadly, is about damage limitation rather than prevention.
That said, I’m all for it.
You don’t need to run KDE or Gnome to run a KDE application. You may need some of the libraries, but that’s it. Gnome users can use Amarok, just as KDE users can use Totem.
I run Kubuntu, but if I apt-get install any gnome app, as long as libraries are available, I can definitely run it from within KDE. Now, will they look/behave the same? No. There are a few workarounds but nothing overly native (the GTK options in KDE work decently though)
The desktop Linux developers are finally starting to pull their head out of their collective butts and do things for the good of the community rather than the selfish advancement of their pet projects. This should have happened ten years ago. Linux could have been a viable desktop alternative by now and maybe even have a decent marketshare amongst home users.
Linux could have been a viable desktop alternative by now
Could have been? It’s been viable, usable, excellent for years.
and maybe even have a decent marketshare amongst home users.
I fear that won’t happen until Dell and others start marketing it to the home user. And that won’t happen until they think there is a market.
Like Apple?
Sorry to break it to you, but APIs don’t make OSs viable alternatives to Windows. The only thing that will give an OS decent market share among home users is full Windows compatibility.
Sorry to break it to you, but APIs don’t make OSs viable alternatives to Windows.
Cost, and apps do.
More and more Linux apps are being ported to Windows, made to work with Windows programs, etc. More and more people will use the open source alternatives to Windows apps because they are cheaper and develop at a greater rate. When that happens, Linux will wipe the floor with Windows just as Windows wiped the floor with the Amiga, etc. No-one in the Amiga community wanted Windows, but efficiencies of scale drove Commodore into the ground. The same will eventually happen with Windows.
* xdg-file-dialog — command line tool for providing file and directory selection dialogs
Why make this a command line tool, instead of some kind of compatability library? Or better yet, just use gtk-qt[1]…is there a qt-gtk yet?
[1] http://www.freedesktop.org/wiki/Software/gtk-qt
* xdg-file-dialog — command line tool for providing file and directory selection dialogs
Why make this a command line tool, instead of some kind of compatability library? Or better yet, just use gtk-qt[1]…is there a qt-gtk yet?
This is more than about making GTK/Qt apps look like each other, we can already do that with a fair degree of success.
The idea is to make KDE apps behave like Gnome apps when running under Gnome, and vice versa, something we haven’t really been able to do.
A KDE app calls a KDE file picker when running Gnome, and Gnome apps call Gnome file pickers when running in KDE.
Instead of coding for one or the other, call something like xdg-file-dialog and the appropriate dialog or file chooser will come up for the DE the app is running in, not necessarily the DE it was developed with.
The win here, if this works as planned, is that developers can choose the best framework for their requirements *and* leverage some of the integrated functionality at DE can provide, without having to resort to generic GTK or Qt only apps to ensure desktop agnosticity. And users will have access to richer applications that leverage their chosen DE’s infrastructure regardless of the platform/toolkit used.
I’m simplifying things here, but basically it’s a good thing. It’s a translation layer for those common functions each DE performs but implements differently.
One day we should all be able to have our cake and ingest it too.
I’d image that it’s even better than that.
If things are done correctly, a KDE app or GNOME app calls a GNUstep file picker when running GNUstep, and KDE app or GNOME app calls a Windows file picker when running Windows (assuming xdg-file-dialog, the GNOME app, and KDE app are ported to Windows and xdg-file-dialog has been ported to GNUstep).
The idea is to make KDE apps behave like Gnome apps when running under Gnome, and vice versa, something we haven’t really been able to do.
You mean if I then run, say, Kate under GNOME, it will show the GTK+ file picker if I would like to open a file? And it’s affirmative action button will be in the lower right?
If I don’t use a similiar looking theme for GTK+ and KDE apps, the file picker will have the GTK+ theme althought it belongs to the appplication using the KDE theme?
And if I then use another one of Kate’s dialogs, it will have the affirmative action button somewhere else, probably to the left of the ‘Cancel’ button or in the upper right corner or somewhere else?
Additionally, everybody is expected to rewrite his app and use a command line tool? Creating a mixed up situation with some KDE apps using the GNOME file picker while others ar not, and visa versa, that will probably last at least one or two years?
The printing dialog, on the other hand, gets re-designed, IIRC, to be similar in each toolkit?
I really like Project Portland but this special part with the commend line dialog picking stuff looks like a bad idea to me.
You mean if I then run, say, Kate under GNOME, it will show the GTK+ file picker if I would like to open a file? And it’s affirmative action button will be in the lower right?
It will appear the same way it would for any standard app calling the GTK+ file pciker.
If I don’t use a similiar looking theme for GTK+ and KDE apps, the file picker will have the GTK+ theme althought it belongs to the appplication using the KDE theme?
I imagine so, but visual continuity isn’t the point of the Portland project, and there are other workarounds to that.
Take Open Office as an example. It’s a desktop agnostic app. If you want KDE integration such as the file picker, you generally need to install a KDE integration package. Ditto for Gnome.
This should eliminate that requirement.
And if I then use another one of Kate’s dialogs, it will have the affirmative action button somewhere else, probably to the left of the ‘Cancel’ button or in the upper right corner or somewhere else?
It would be as if Kate called a native GTK dialog box.
Additionally, everybody is expected to rewrite his app and use a command line tool? Creating a mixed up situation with some KDE apps using the GNOME file picker while others ar not, and visa versa, that will probably last at least one or two years?
This was really intended to address the developers who *haven’t* created apps yet due to hesitation and uncertainty over which framework to use, so I don’t think that’s as big a problem as it seems.
The applications now that feature either KDE or Gnome integration tend to be part of those DE’s anyways, I imagine that both teams would eventually port them to use the “universal” ABI’s but I don’t think it would be a priority.
The printing dialog, on the other hand, gets re-designed, IIRC, to be similar in each toolkit?
I know a common interface is being worked on, but whether that commonality involves functionality or appearance, I’m not too sure.
I really like Project Portland but this special part with the commend line dialog picking stuff looks like a bad idea to me.
I think the command line stuff right now is probably more proof of concept, but I could be wrong. However, if it’s transparent to the user and it makes application development easier, what’s wrong with it?
However, if it’s transparent to the user and it makes application development easier, what’s wrong with it?
Come on, that’s like asking “If everything’s right, what’s wrong with it?”
I’ve seen many GTK+ apps. Most of their dialogs are custom designs, the standart choices for file picking, color selection, printing and so on are not as important in relation to them.
For example, select “Tools > AutoCorrect” in Open Office Writer: The dialog looks foreign in GNOME and will remain to look foreign.
The proposal, on the other hand, will make the standard dialogs appear foreign within their own apps! Don’t you think that is going to confuse users?
My concern is that the Portland Project guys are not going to test this with a dedicated application before publishing the recommendation.
Even if users in general are not confused, third party application developers will need to spend some more time to clean up the other dialogs because, as said above, their apps will still look foreign. So they will need to test for the running desktop and configure buttom order, appropriately. Why then offer a command line tool instead of a copy of KDE’s file picker in GTK+, and visa versa?
To me this looks like I wouldn’t buy software that is written like that; it’s a bloody ugly workaround. And since the concern of the ISVs is not whether their apps look good but whether their apps do sell, I believe the proposed solution won’t fix their problem.
Edited 2006-05-11 09:52
gtk-qt is a theme engine for using Qt to draw widgets in gtk apps, it does not provide Qt/KDE file dialogs. For that, one currently needs something like KGtk ( http://kde-apps.org/content/show.php?content=36077 ) ot QtGtk ( http://developer.kde.org/documentation/tutorials/qtgtk/main.html ). I’ve never seen the latter in action though
Those acronyms are getting really confusing.. gtk-qt is different from gtkqt argh
What’s “bettering”?
A synonym for improving?
Yes.
I know this is slightly off topic but if you keep reading you should see that it all ties in together… my idea at least.
Ever since the Xfree License change and the creation of Xorg and Freedesktop, Portland etc. Things have really picked up in the standardizing department/area with software for OSS systems. I think this is great! Because only the area’s in which it’s needed are actually worked on and things are slowly but surely being adopted.
One grip I do have is that I am a FreeBSD lover, I came from a GNU/Linux background which introduced me to the world of OSS/FOSS or whatever you want to call it. Anyway, the point is that a lot of this effort is mostly targetted toward the GNU/Linux system and not made with portability in mind.. Eg, HAL. This is currently being worked on by some people over in the *BSD camps (from FreeBSD’s Gnome dev’s).
I guess my point is that I would love to see these programs/software written with the *nix world in mind and not limited to the GNU/Linux systems/distro’s as this would bring the two communities closer together.
I don’t see these two worlds as enemies, I use both and love them both.
Just a thought… ignore the ramblings. (all of it)
Isn’t “Linux Desktop Developers” akin to “Windows Security Engineers” or “Apple Game Pioneers”?
A KDE app calls a KDE file picker when running Gnome, and Gnome apps call Gnome file pickers when running in KDE.
Will the file picker run in the same process as the application itself, or in the desktop daemon’s process?
If in the application’s process, then it will require a common even loop, right? (Looks like Qt is adopting glib, but it will take time…)
If not, then will it be possible to tie the file picker to the application’s window – make it a modal dialog, or make it stay on top, etc.?
What about permissions – if the application is running as a different user, will it still connect to the same desktop daemon?
In general, it would put a lot of responsibility on the daemon.
This should have been done years ago when Windows was having problems. Xp has been nice. Still some security issues but there are workarounds with firewalls.
Too late.
Edited 2006-05-11 01:37
This should have been done years ago when Windows was having problems. Xp has been nice. Still some security issues but there are workarounds with firewalls.
Too late.
Pretty much so. Influential people in the open source desktop world could have made some tough decisions about 5 or 6 years ago when the time was right. Timing is pretty crucial. This stuff is just a band-aid for something that needs major surgery.
Interestingly, OSX is really the big competition right now for Linux and not Windows. It’s amazing how many developers I meet that have switched from Linux to OSX.
You mean commercial developers. These were never Linux friendly. I wanted to switch to MacOSX until I found out PCBSD. Now I am a more fanatic OSS proponent and I keep programming on Linux and FreeBSD. You want macOSX? Try Gnustep. AMAZING !!!
I’d not say “too late” but “a bit” late.
Anyway it’s a step forward, if not to take over the world, at least to improve Linux/BSD user experience.
I think the command line stuff right now is probably more proof of concept, but I could be wrong. However, if it’s transparent to the user and it makes application development easier, what’s wrong with it?
It is more than just a proof of concept, though obviously not a solution that covers all aspects.
It is intended to provide a quick way to do the most common integration tasks, without requiring everyone to wait until new libraries are written, tested and are being shipped by distributors.
The long term goal is to move to a more service oriented architecture, however, being a long term goal, it is not as easy to achieve and a parallel effort to create a short and medium term solution is required as well.
My concern is that the Portland Project guys are not going to test this with a dedicated application before publishing the recommendation.
Jeremy White, one of the ISV developers (Codeweavers) participating in the project, wrote on the mailinglist that he is indeed planning to dedicate a full application on testing the integration efforts.
it’s a bloody ugly workaround. And since the concern of the ISVs is not whether their apps look good but whether their apps do sell, I believe the proposed solution won’t fix their problem.
Granted it is a workaround, but incidentally it were the ISVs that found the idea of commandline access tools a nice thing to have, very likely because of the easier handling of dependecies, i.e. starting a missing executable will just fail during runtime, a missing library will fail starting the application itself