Differences between revisions 4 and 5
Revision 4 as of 2011-10-30 09:03:52
Size: 7766
Editor: FranklinPiat
Comment: drop link MenuStructure
Revision 5 as of 2021-07-23 14:32:09
Size: 7766
Comment: fix typo
Deletions are marked like this. Additions are marked like this.
Line 64: Line 64:
I thought it would be nifty that {{{apt-get install debain-desktop-apps-'''}}} would install all of the independant apps at once. Very usefull for non GNOME KDE people. Consequently {{{apt-get install debian-desktop-'''}}} would give you the motherload. :) I thought it would be nifty that {{{apt-get install debian-desktop-apps-'''}}} would install all of the independant apps at once. Very usefull for non GNOME KDE people. Consequently {{{apt-get install debian-desktop-'''}}} would give you the motherload. :)

Native or Generic?

Because there are so many desktop choices in the Debian distribution as a whole, it will be necessary to decide whether or not to customize each one or build a desktop out of the common denominator. For instance KDE, GNOME, and XFCE are all relatively effective user environments. However each have their own apps for performing common tasks. GNOME and KDE are significantly different, and XFCE is purely GTK based. To help define the desktop-base package we will need to decide this matter.

It is my hope that this page be a discussion on the matter.

Comments


I would argue for Native apps. Here are my reasoning and my packaging ideas:

I put a lot of thought in how to organize the debian desktop packages for ease of use and maintenance. Ideally the end user or administrator should have a fine level of control over what debian desktop environments and applications are installed. Therefore I would like to draw a distinction between environment and application, as some applications are entirely independant of environment. Mozilla is the most outstanding example. As such we can use meta-packages or tasks to set up the appropriate debian desktop packages.Ideally the top-level debian-desktop packages or tasks should not contain any content. (So we can convert them to tasks if possible.) It is my hope that they purely depend on the needed package. To ease management of the packages with apt, it would be suitable to use a simple naming scheme. The prefix "debian-desktop-" seems to be an acceptable base name. Each meta-package for environment could be titled like the following:

debian-desktop-gnome debian-desktop-kde debian-desktop-xfce debian-desktop-enlightenment debian-desktop-windowmaker debian-desktop-icewm debian-desktop-rox debian-desktop-gnustep

Marcelo argued against dividing them this way. He argued that wmaker, e, and icewm are not really environments, but are simply window managers. Although this is true at heart, I have found that any window manager that provides a task bar, dock, menu, or even file manager will generally be regarded by the novice user as an environment. I show windowmaker to lots of people (it runs in cygwin now :) ) and they see no difference. So in short, IMHO windowmaker and icewm are percieved as user environs. I do not feel that arguing the differences between programming environ and user environ will be productive. That said, back on topic...

Ideally each of the above meta-packages or what-not should install a complete set of useful apps appropriate to the environ. No doubt, deciding these apps will be a painful process, and on considering this I realized that some things don't fit the mold. Again Mozilla will be my example, as Mozilla does not require any of these to function. Furthermore it is posible that the user does not want to install Mozilla and would only want the browser specific to the environ. To my knowledge KDE is the only enviroment that fits this example, however others may appear in the future. This is very possible when Mozilla reduces to just a set of libraries with things like Phoenix running on top.

So it seems reasonable that we will need meta-packages for apps that don't fit a given environment. So far I have come up with two and mabey a third. Please note thet these are entirely theoretical as I have not actually created packages yet.

debian-desktop-apps-internet

Should provide all applications and libraries necessary to view webpages, check email or news, and use IRC/IM services. No application or library should be dependant on running a specific user environment.

mozilla-browser mozilla-mailnews mozilla-psm mozilla-xmlterm mozilla-chatzilla

debian-desktop-apps-media

Should provide all applications and libraries necessary to listen to ?MP3's, Ogg's, and view Mpegs. Should also allow media apps to function in any of the common sound/video environments. No application or library should be dependant on running a specific user environment.

xmms vorbis-tools smpeg-xmms alsa-xmms xmms-nas xmmsarts xine-ui

debian-destop-apps-office

Should provide all the software and libraries necessary to work with office documents, spreadsheets, and interface with databases. No application or library should depend on a specific user environment.

gimp openoffice.org

Note: I have only found OpenOffice comprehensive enough to meet this criteria.

I believe there is a trend here, and I wonder how many other "sub" catagories would be found if people looked into it. Please understand that I am not trying to resurrect the old Task System that used packages. It would be preferable to use the existing task system to do this, but it will take the cooperation of the release manager to get it done. Since we need themes for each environment to even out the look & feel of each desktop, it seems like placing the themes in these desktop packages briefly is a good idea. Again it would be ideal to move this to the existing task system, so the themes would have to move into their own packages in due time.

A little note on the naming scheme:

I thought it would be nifty that apt-get install debian-desktop-apps-''' would install all of the independant apps at once. Very usefull for non GNOME KDE people. Consequently apt-get install debian-desktop-''' would give you the motherload. :)

- MatthewMcGuire


For -media:

mplayer (when installed to unstable)---- gqmpeg


For -internet:

psi


gnomeicu


sim-icq (looks really like the windows-icq)

For office:

xpdf


kpresenter


gimp1.2


gimp1.2-nonfree


acroread (if available)----


For media: xine


MarkBucciarelli, 2002/12/08 09:08 UTC (via web):


If we use human interface terms that focus on specific tasks (like "Letter", "Memo" and "News Letter" instead of "Word Processor"), we can have a generic menu structure across all debian-desktop-* window managers. I think we should also have a standard file structure created as well: my current thought is to have the directory structure rooted in the Desktop and mirror the menu structure; for example, ~/Deskop/abc/letters and ~/Desktop/music/.

Although I hate revive old flame wars, I believe there was a consensus to do exactly that with the menu system. IIRC there was a lot of discussion reagarding non-matching menus in KDE and GNOME. Consequently there is an ongoing discussion to create a spec for menus at http://www.freedesktop.org .


I have added xine to the media list and it turns out that the OpenOffice.org package is not environment dependant. Mplayer is tied up in legal mumbo-jumbo so it is not available at this time. The other apps have not been added as they posess dependancies on either GTK or QT. Arguably Mozilla and XMMS depend on GTK as well, however they do not depend on any GNOME specific library or service. Therefore, applications that solely depend on GTK or QT and are not GNOME, KDE, or XFCE specific can be classified as 'Generic'. This also means that these apps must not use Gconf or Dcop in any way. I will continue to investigate the recommended applications, and will report later. Thanks for the suggestions.

- MatthewMcGuire


IMHO ?GConf shouldn't be considered GNOME-specific. It is GNOME using ?GConf, not the other way around, and ?GConf is perfectly resonable to use w/o GNOME. Also, ?GStreamer definitely should be added to media list (nb. it uses ?GConf in some of plugins), as "the" media framework. It may be hard to decide if given dependancy is desktop-specific or not, but nevertheless it must be done Right(TM).