Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India) [LWN.net]

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 9, 2006 2:36 UTC (Sun) by proski (subscriber, #104) [Link]

I think it's outside the scope of the project. Why would an application vendor need to supply a theme with the application? Do you want all your windows to change color after you install some Foozilla? I, for one, would prefer exactly the opposite, namely that the third party software conforms to my choice of the theme.

freedesktop.org is doing some work on interface standardization, but I see no reason to put it under the Portland "roof".

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 9, 2006 4:04 UTC (Sun) by drag (subscriber, #31333) [Link]

I think that themes and fonts and such would be nice to get under portland, but I think at this point it's technically infeasible.

With current portland it seems that they are going after the low hanging fruit. Doing the stuff that seems most important and not that difficult.

If it succeeds well I see them going after more stuff.

But remember this isn't just about third party things. If I set fonts and colors in kcontrol why should have I have to do it again for all gnome-font-proprieties and similar?

If a theme is avaible for both KDE and Gnome (like bluecurve) why should I have to set it up in a bunch of KDE preferences AND gnome preferences?

Of course this sort of thing is much more difficult to resolve then having the ability to choose a default browser and email client working in between KDE and Gnome environments.

And it should extend to other things.
If I hit ctrl-l in a nautilus window and connect to a ssh server, shouldn't I be able to access this from a KDE or other non-gnome application?

(for that I am a big fan of getting rid of KDE's and Gnome's respective VFS stuff (or at least diminishing so it works) and going with FUSE.

FUSE is currently mostly Linux-centric, but it's portable enough. I think going that way would be great since not only Gnome (or KDE) apps can use it, but traditional POSIX and command line stuff can use it also. Also current VFS stuff can be extended into FUSE-land (although FUSE is generally better performing then either Gnome's or KDE's "propriatory" stuff)

For instance you have compressed file systems.. network shares. NTFS file system access. GoogleFS and odd things like that.

I like using encfs and sshfs. Sshfs is actually faster for me for (network speeds up to 100mbit/s) then NFS. (although obviously for large amounts of users nfs has much better cpu usage)

Fuse rocks. It would be a great thing to be able to have a easy to use gui integrated into KDE and Gnome to control that sort of stuff.

Maybe something using Afuse?? (it's a userspace automounter.. very neat)
http://afuse.sourceforge.net/

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 9, 2006 4:57 UTC (Sun) by proski (subscriber, #104) [Link]

Just because you want something done, it doesn't mean it should be done in a certain way or as part of a particular project. Many annoyances you mentioned are much better addressed by changing the desktop environments to conform to a certain common standard rather than by inserting intermediate layers between applications and the desktop environments, which is what Portland project is doing. Do you really need a third party configuration tool?

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 9, 2006 23:05 UTC (Sun) by drag (subscriber, #31333) [Link]

Nope. I want changes that I do in Gnome to also make (applicable) changes in KDE.

I want to be able to set the fonts and colors once.. not having to go into 3 or 4 different dialogs to do it.

I don't see any reason why portland, if it is succcessfull in this project, can be used to find a way to syncronize the two desktops without having to make big changes or break backward compatability.

That is except for the gnome/kde VFS stuff, which I didn't like either much. Setting up mounts and volumes and such should work for all applications at the file system level rather then higher up in the file dialogs. At least in my opinion.

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 10, 2006 11:34 UTC (Mon) by superstoned (subscriber, #33164) [Link]

Well, if you use KDE, the changes you make to colors is automatically applied to Gnome apps. They thought of that. And if you install the gtk-qt theme, icons, fonts and style are the same too. There even is a hack to let Gnome apps use the KDE file dialogs!

So gnome apps integrate quite well in KDE, and the opposite just needs some efforts from the Gnomes.

Desktop Linux Integration Nears With Portland Project Beta Release (SYS-CON India)

Posted Jul 9, 2006 15:02 UTC (Sun) by nix (subscriber, #2304) [Link]

In any case, gtk-qt already exists, so if your preferred theme is a KDE/Qt one, you already have what you wanted :)

Important to not oversell Portland

Posted Jul 9, 2006 3:18 UTC (Sun) by dank (guest, #1865) [Link]

Read http://portland.freedesktop.org before concluding
that Portland is going to unify Gnome and KDE.

The Portland members fall into two groups:

1) those who want to get something useful and simple
done quickly; these are the folks behind the xdg-utils
currently being readied for release. Their goal is
to capture current best practice among folks who
really ship portable applications, and bottle it up
to make it easier for everyone to use. This is
likely to make it into common use fairly quickly.

2) those who want to unify Gnome and KDE; these are the
folks behind the DAPI library, which is not part of
the current release plans. Their goal is to change
the way desktop software is written; instead of API
calls to open dialogs and the like, you'll invoke out-of-process
servers, kind of like ActiveX. They have been vague
about how much of the KDE and Gnome APIs they want to replace,
but the answer seems to be "all of them".
This is unlikely to have much impact on real software any time soon.
(I can't tell for sure, but I think they're driven
by a sense of being burned by KDE's sensitivity to
the well-known problems using C++ shared libraries --
both those caused by gcc's ABI changes, and those
inherant in using C++ to expose library ABIs).