The key thing is most Linux users I know, myself included mix and match KDE and Gnome apps. I use Grip not the KDE equiv. Don't even remember what it's called. I use Kedit rather than Gedit and frequently use Kate and Nedit as well.  Then you have desktop independent software like sound players (Xmms, Zinf, etc) video players like Xine that are desktop independent but are a core part of almost all desktops. Along with Xine you havd desktop specific apps which may or may not be relivent. Me I'm going to use which is best and not really care if it's a Gnome or KDE app. For most tasks I use Xine, but I've found Kaffine does better with some formats or for some purposes so I have both installed as well as Mplayer for other purposes and formats.

So what I'd suggest as an alternate is that for core functions we have a common set of documentation. Then for desktop specifics, for example configuring a KDE destop to play mp3s then seperate links for the specifics. I suspect that most people, even those who have not installed the full desktop have most of it installed anyway to support those apps from the other desktop they cannot live without. K3b probably being the most common example of that. Gnome and KDE users may be unaware of really cool utilities that exist in the other desktop. So by having them in the same documentation it can be a discovery process for them.

So the main value is in configuration. Adding an app to the menu of different desktops is a very different process. Where something is located is different not only between desktops but also between versions of the desktop sometimes. Where is not important, the how is. How to configure your networking from GUI or from command line for example. When we are talking about command line we are talking about the same no matter what desktop you are running. So we have a common and redundant if we split the documents up piece of information relivent to all desktops. If we have multiple copies it is certain to get out of synch. So it needs to be embedded or linked.  The core concepts of networking are again common. What IP ranges to use if you are creating a home network for example. So the boxes you fill in may look different or may be the same between desktops and only the steps to get to them are different perhaps. I'd have to look actually :) I do it all from command line myself.

So I'm thinking that embedded docs in the same framework will be better. When somebody wants to go to very desktop specific areas then split off. An example might be

When configuring a home network blah blah blah

link to KDE, Gnome, Command line with steps using each.

DNS configuration using blah blah

In this way the user scrolls down finds the relivent information, then has a link to follow for the method to accomplish the task. They might be using one desktop or another and find it will be clearer and easier to switch to the other desktop to accomplish this task. They might only choose the desktop they use and go with those docs or might do it from the command line and skip all the GUIs. The steps specific to a desktop might lead back to a common place. They might also be known to the user and that part of the documentation skipped over as they already have the proper app open already.

On 11/25/06, Karsten Wade <> wrote:
I went to bed last night thinking, "We need to add Kmail, Konversation,
and Konquerer to the DUG," and then I read this today from John:

> We will need an equivalent Desktop User Guide for KDE like what now
> exists for GNOME. See
> This should probably be a separate document for now.

I actually think we could just reorganize and put KDE and GNOME content
all into the same guide.  Much of the surrounding content is the same
(logging in, etc.), so it would increase maintenance of identical
documentation.  In XML we can more easily build custom DUGlets, that is,
a DUG with a specific desktop only focus.  I think keeping all eyes on
one DUG with dual-WM support should do it.  Does that sound reasonable?

- Karsten
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project
Sr. Developer Relations Mgr.     |           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

fedora-docs-list mailing list
To unsubscribe: