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 <kwade(a)redhat.com> 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 Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
| gpg key: AD0E0C41
fedora-docs-list mailing list