public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Gold is Heavy <aeoo@garbled.org>
To: gentoo-dev@cvs.gentoo.org
Subject: [gentoo-dev] GNOME and KDE, can they play nice? was: merging gaim...
Date: Wed Oct 10 13:39:02 2001	[thread overview]
Message-ID: <auto-000008687249@front2.mail.megapathdsl.net> (raw)

Hi Martin and other Gentoo Hackers,

Martin said:
"Try the following:  Make sure gnome is in use flags, then remerge
gdk-pixbuf.  Then make sure gnome-base/gnome-core and
gnome-base/gnome-libs are merged, and remerge Pan."

Ok I followed these steps, and I noticed that gnome-base/gnome-core and 
gnome-base/gnome-libs are indeed merged on my box.  (I looked in /var/db/pkg 
to check this.)  And it didn't help, but you probably knew that by now :)

Then, Martin said:
"You have gnome in your USE-variables (in /etc/make.conf), that's why
gnome-support is built. If you don't want GNOME-support, remove gnome
from your use-variables."

Ok, I am beginning to understand the USE flags a little better now.  However 
this brings up a serious question.  What about people who want to use BOTH 
GNOME and KDE??  Personally, I will most likely take out 'gnome' from my USE 
flags and try again, but...  There might be very valid and good reasons why 
someone might want to run both KDE and GNOME on the same box.  Possible 
scenarios:

1. More than one person uses the box at home, and they have different 
preferences.

2. The box is in a computer lab, and many people use it there.  Again, they 
might have different preferences.

3. Someone likes to switch between Gnome and KDE on a whim, just for the fun 
of it.

One possible solution that I can see:

When building apps, check both KDE AND GNOME flags.  If both of them are 
defined, make the app usable in both environments.  For gaim, that would mean 
sacrificing the applet functionality, and maybe gnome bits.  So, the ebuilds 
would be sensitive to both variables and there would be 4 possible actions 
that could be taken: a) neither KDE nor GNOME defined, b) KDE only, c) GNOME 
only and d) usable under both KDE and GNOME.

More generally, if there are more that one desktop environment flags in USE 
flags, then emerge/ebuild should avoid building an application that is 
hardwired to only one desktop environment.  So, this could be generalized 
away from just KDE/Gnome distinction.  This could be further generalized away 
from even desktop environments.

How about creating a new variable called ALTERNATIVE or something like that?

Then we could say:

ALTERNATIVE="desktop_environment kde gnome"
ALTERNATIVE="database postgre mysql"
...and so on,

and what it would mean is this: if there are ALTERNATIVE 
desktop_environment's in place, be sensitive to that fact by NOT building 
apps that do not work with ALL of the alternatives.  If there are alternative 
database's in use, then do NOT build apps that can only use one database and 
not the other.

The primary use for this would probably be for DEs and maybe databases, but 
if any other alternatives should crop up, it would be very easy to handle 
them all with a flexible and general system.

Just an idea :).

--Leo



             reply	other threads:[~2001-10-10 19:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-10 13:39 Gold is Heavy [this message]
2001-10-10 14:25 ` [gentoo-dev] GNOME and KDE, can they play nice? was: merging gaim Mikael Hallendal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=auto-000008687249@front2.mail.megapathdsl.net \
    --to=aeoo@garbled.org \
    --cc=gentoo-dev@cvs.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox