Re: KDE and Gnome



On Tue, 2003-08-26 at 17:23, Sean Middleditch wrote:
> On Tue, 2003-08-26 at 12:14, Julien Olivier wrote:
> > On Tue, 2003-08-26 at 16:45, Sean Middleditch wrote:
> 
> > > 
> > > You have that ability.  Use a real mainstream tookit and not a cracked
> > > out niche/custom one.  If you use a weird toolkit, you must not have
> > > cared about conformity.
> > > 
> > 
> > Well, if you use native themes (not bluecurve), GNOME and KDE have very
> > different looks by default (GTK's default VS Keramik). So even
> > mainstream toolkits can have clashing looks.
> 
> Redhat and Mandrake both solve this.  I'm sure SuSE will too, if they
> haven't already.  Other distros may or may not care enough to use a
> unified theme; if they don't, they are the wrong distro to use with
> people who care about this stuff.
> 

I'm not sure letting distributions fix problems is a good idea... but I
agree that using a "fake" unified theme can be seen as a solution.

> > 
> > More over, if someone uses GNOME and changes its theme, it just changes
> > GTK theme. So, even if his GTK theme used to look like his QT theme, it
> > won't be the case anymore after changing his GTK theme.
> 
> This is teeny bug, and doesn't need a massive toolkit purging or theme
> redesign to fix... just write a little spec for picking theme name
> (using XSETTINGS, perhaps) and the likely few lines of code needed for
> it, and you're done.
> 

No it's not a bug ! The problem is that there are about only 3 unified
themes: Galaxy, Bluecurve and [K/G]eramik. That means that if you want
to fix this "bug", you have to remove every other themes from the GTK
and QT theme dialog and display only thise 3 themes. Then you can make a
script that synchronizes GTK and QT themes.

Then, if you want to create a theme for Linux, you have to create a GTK1
theme, a GTK2 theme and a QT3 theme instead of simply creating one
theme.

> Let's not fix the loose nail with bulldozer.
> 

OK, but at least let's try to fix it properly ;)

> > 
> > > > app, you have 2 possibilities: whether you create an app with the
> > > > standard look or you create a skinnable app (like XMMS). You don't have
> > > 
> > > XMMS is dying, thankfully.  The sooner, the better.  The UI is worst
> > > monstrosity I've seen in a long time.  I still can't figure out how half
> > > of it works.
> > > 
> > 
> > I agree but that's not the point. The point is that you always have the
> > possibility to creacte a skinned app and, so, override the default
> > standard look if you really want to.
> 
> Right.  Just like you can not use GTK/Qt if you want to.  It looks and
> acts different because _they wanted it to_.  You can offer all the
> unification you want, but if people don't want to use it, it's not going
> help any.
> 

I agree. But the problem is that, currently, even if you _want_ to make
your app look like other apps, you can't. Because you can't be sure that
your users' GTK and QT themes match. So you have to know which desktop
they run.

> > > If they cared about integrating w/ GNOME/KDE, why in the nine hells
> > > would they use a niche/custom toolkit anyhow?  Mozilla's interface was a
> > > mistake, one which has already been corrected w/ Galeon/Epiphany/Camino
> > > and more for other platforms.  OpenOffice.org is another mistake, one
> > > which is based mostly on the fact it's legacy code that can't be easily
> > > converted.  Many other apps based on a Motif are also that way only due
> > > to legacy code.  How would new theming methods help all these legacy
> > > code anyhow?
> > > 
> > 
> > It would help them because at least they would know which look to
> > emulate. I mean, if you want to create a toolkit on Linux, which look
> > will you give to it ? Windows look ? GTK's default look ? QT's default
> 
> Why make a new toolkit, other than to not look/act like what we already
> have?
> 

Maybe simply because you think GTK or QT are bad from a technical point
of view ? Maybe someone wants to create a very fast/light toolkit but
still wants to have it look like a native Linux app.

> > look ? MacOSX' look ? How do you define what is Linux' default look ?
> 
> Linux doesn't have a default look.  Linux is a kernel.  GNOME is a
> desktop - you make an app to work with the GNOME desktop.  Make the app
> be a GNOME app or not.
> 

I know that Linux is jut a kernel. s/linux/X11 everywhere if you want.
That doesn't change the problem, which is that on X11, you have to
choose a desktop (GNOME or KDE) but you can run apps made in any toolkit
on this desktop. That's why toolkits should try to look the same on a
given desktop.

> > Without a themeing library, you can't even say what is the standard look
> > as it depends on the toolkit AND the theme used on this toolkit. Even
> > the "standard" themes of th 2 main toolkits (GTK and KDE) clash, to say
> > the least.
> 
> You are obsessing on such trivial pointless stuff.  Who cares about
> default themes?  Who even _uses_ default themes?  Distros these days
> don't give you the default theme by default, quit worrying about it.
> 
> And back to your theming library, what is it going to solve?  What?  You
> can't unify anything except in the toolkit itself - the whole method
> used to draw widgets varies between toolkits.  They vary based on
> backend (X, Cairo, FB, etc.).  It's not feasible.
> 

Of course it's feasible. All the library would return would be an array
of pixels defined by theyr RGB value (a pixmap). Then eahc toolkit would
draw it on its widget they way it wants.

> 
> > > No, it'd be a waste of time.  ;-)
> > > 
> > 
> > Well, I really don't think so. But it's all about open source. So you
> > have the right to think it's a waste of time and someone else can hack
> > on it if he wants.
> 
> Righty.  I'm offering my arguments here to prove why it's a waste of
> time, versus a lot of base speculation and uninformed guessing, so as to
> hopefully dissuade anyone so talented from wasting time, and perhaps
> working on real solutions to solvable problems.
> 
> I.e., just making KDE and GNOME sync themes, instead of trying to
> revolutionize the toolkit space that no one else has ever been able to
> do.  ;-)
> 

Well, sorry talented people for spamming you with my uninformed
guessing. Just ignore me...

> > 
> > > > 
> > 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]