Re: KDE and Gnome

[Rob Adams <readams readams net>]

I'm pretty sure that KDE actually does have a button order preference
buried somewhere in their gigantic set of desktop preferences dialogs. 
Though you're not going to acheive exactly the niceness of gnome HIG
apps, you can sort of get closer.

Of course, the real solution to this is to just make GNOME so great that
no one will want to use KDE...

-Rob

On Tue, 2003-08-26 at 09:34, Julien Olivier wrote:
> On Tue, 2003-08-26 at 16:37, Sean Middleditch wrote:
> > On Tue, 2003-08-26 at 10:34, Julien Olivier wrote:
> > > On Tue, 2003-08-26 at 15:14, Sean Middleditch wrote:
> > 
> > > > Well, there's a lot more to an interface than the color of its widgets. 
> > > > There is the whole feel/behaviour.  I can't stand using KDE apps (or
> > > > even Mozilla) because they act nothing like the other apps on my
> > > > desktop, even if I install a matching theme for them.
> > > 
> > > Sorry, I was talking of the look, not the feel.
> > 
> > My point was, obsessing over look is completely pointless.  It's
> > worthless next to feel, which is the real usability barrier.
> > 
> 
> OK, but I'm not obsessing over look. I just think that the look is one
> of the things that should be standardized too. I never said it was the
> #1 need.
> 
> > > 
> > > > Buttons are in
> > > > different orders in dialogs.
> > > 
> > > Well, the situation kinda sucks. Why can't we find a consensus on this
> > > problem ?
> > 
> > I doubt it.  Many people hate the GNOME ordering.  I personally love it,
> > since it honestly does work better.  I almost never have to aim for a
> > button not in the bottom right corner, which was (I believe) a reason
> > for the new ordering design.
> > 
> 
> I love it too. And nevermind if KDE developers don't like it. What I'd
> like, however, is having the possibility to create a QT app that
> respects GNOME's HIGS, has buttons in the right order (following GNOME's
> HIG) and looks like a GNOME app. Currently, it's not possible because my
> app's look would depend on QT's theme, not GTK's theme.
> 
> > > 
> > > >   Configuration panels are huge messes of
> > > > useless crap I can't find my way thru.  Widgets are laid out with no
> > > > thought to organization or cleanliness.  etc.  Even a good deal of GTK
> > > > apps I can't stand to use because the UI is complete and utter crack. 
> > > > (like gSynaptic.)
> > > > 
> > > 
> > > That's a totally different problem because this lack of organizatio is
> > > not a direct consequence of the usage of one toolkit. It's simply a bad
> > > design and it can happen in GTK apps as well as QT apps, as you said.
> > 
> > Right.  Unification of anything isn't going to fix this, is my point.
> > 
> 
> We agree on this. I'd like to have a unified _look_ to fix the _look_
> problem, which is a problem per se. Other problems will have their own
> solutions. And I've never pretended that fixing the _look_ problem would
> fix the _feel_ problem too. Just to make sure we understand each other.
> 
> > > 
> > > > All this effort to make unified themes, or even use a single toolkit,
> > > > isn't going to fix the above.  The only way to fix it would be convince
> > > > all developers on a single UI design philosophy, which is impossible. 
> > > > Not to mention there will always be developers who try to do completely
> > > > insane and pointless things like the Mozilla cross platform UI, where it
> > > > fits into one platform (Windows) and feels totally alien on others
> > > > (GNOME, OS X, etc.)
> > > > 
> > > 
> > > In my opinion, there should be a way to make toolkit _look_ the same for
> > > the following reason:
> > > 
> > > I, as a developer, don't want to choose a toolkit because of its look. I
> > > want to choose a toolkit because it's the best trchnology. And if I
> > > choose QT over GTK (for example), and respect GNOME's HIG, I'd like my
> > > app not to look too much of a stranger in GNOME. And that can be
> > > achieved by unifying the "look" and standardizing the way the "feel" is
> > > defined.
> > 
> > If you choose a toolkit due to look, that is your own problem.  Both of
> > the major toolkits are heavily themable.  Making any decision based on
> > look is so foolish I can't even stress it enough.
> > 
> 
> I couldn't agree more. And that's why I say that I'd like to be able to
> choose QT and, still, be able to make my app look like a GTK one without
> having to set up each client's desktop to use a unified theme ala
> bluecurve.
> 
> > So far as feel, it isn't going to be unified too much.  GNOME and KDE
> > have different feels because the developers/users _want_ different
> > feels.  I hate the feel and behaviour of KDE.  Others hate GNOME. 
> 
> 
> Feel will be unified if I choose to make my QT app feel like a GNOME
> one. As you said, it's all about the developer, which I am. I don't care
> about other KDE apps. What I want is have the liberty to choose my own
> toolkit, even if I want my app to integrate with GNOME.
> 
> > Unification would just piss off both such camps.
> 
> 
> In fact, using a themeing library to render widgets wouldn't piss any
> camp because that wouldn't change anything for any camp. Each toolkit
> would simply have to port their themes to this library.
> 
> > > 
> > > > The best solution for unified look is to just use GNOME apps.  Don't
> > > > like how Mozilla looks?  Then why are you using it instead of
> > > > Epiphany/Galeon?  OpenOffice too Windows-ish for you?  Try
> > > > Abiword/Gnumeric.
> > > > 
> > > 
> > > OK, that means that I can't create presentations because I don't like
> > > OOO's look as GNOME doesn't have a presentation program. And that also
> > > means that, for a developer, it's impossible to create an app that will
> > > please everybody. Or you have to create a KDE frontend, a GNOME frontend
> > > and a MOTIF frontend. That sucks...
> > 
> > Ya, it does.  Those front-ends are all different for a reason tho.  if
> > you don't care about people using KDE, don't waste time on a KDE
> > front-end.  If you do, then you have to please the KDE people, who
> > _want_ a different interface than that which GNOME users would enjoy
> > best.
> > 
> > Forcing un-optimal compromise on users and developers because you want
> > to please everyone and not put forth the effort to do so seems rather
> > selfish. ;-)
> > 
> 
> Just explain me why if I want to create a windows app I don't have to
> take care of the toolkit I use while I have to do so on Linux. Don't you
> see a problem here ?
> 
> > > 
> > > > The only other solid option is to do what Abiword did - separate the app
> > > > core and GUI layer, so you can implement different interfaces (GNOME,
> > > > Windows, OS X, KDE, whatever).  I'm very sure KDE could have a native
> > > > Abiword interface if anyone cared enough to code one.
> > > > 
> > > 
> > > That would be a solution but don't expect every programmer in the world
> > > to start separating the app core from the GUI. That would be great but
> > > that's not the case.
> > 
> > Just like we don't expect every desktop to magically start using
> > groupthink and agree on a set of interface standards which are largely
> > up to taste and philosophy, something it would be tyrannical to try to
> > "standardize" and enforce.
> > 
> 
> When I say standardize, I don't mean enforcing. For example, if each
> toolkit _could_ use a themeing library to render their widgets, that
> wouldn't force them to change their look as the look would be ultimately
> defined by the theme used with this themeing library. So, for example,
> QT would use the themeing library and KDE would have a keramik theme for
> this library. As a result, that wouldn't change anything for KDE users
> except that if a KDE users opens a GTK app in KDE, his GTK app would use
> the keramik theme and, thus, have the same look as his KDE apps. Of
> course, each desktop (GNOME, KDE) could still have a default theme on
> his own. But this theme would apply to "foreign" pps too.
> 
> > > 
> > > > We'll never magically get all apps to integrate, tho.  There will always
> > > > be people like the Mozilla developers, or people who purposefully pick
> > > > odd-ball non-mainstream toolkits because they don't care about or
> > > > actively dislike the modern desktops.  Let's accept that and move on. 
> > > > ;-)
> > > > 
> > > 
> > > You're right ! You'll never have one and only one toolkit. And that's
> > > why we should try to find good ways to help apps integrate well with
> > > other toolkits. It's probably never going to be 100% perfect but that's
> > > not a reason to give up, especially when there _are_ solutions.
> > 
> > These toolkits often exist specifically to avoid the "standard" of gtk
> > or qt.  The others are inconsequential.  If developers choose to avoid
> > GTK and Qt, that's their problem.  They lost a lot more than just the
> > look/feek by avoiding the rest of the GNOME/KDE libraries, and those
> > apps should probably be replaced with native, more powerful apps
> > anyhow.
> 
> OK, but what is a "native" linux app ? Are GTK apps native or is it QT
> apps that are native ?
> 
> >   (For example, GTK apps without gnome-vfs support are a huge
> > pain, since I often access files on network file systems thru gnome-vfs
> > - apps that can't do this are a hindrance to me, and I don't care what
> > they look like, since they aren't very usable.)  Integration has to
> > happen at a far lower level than the method used to render a button, or
> > even where that button is.  The proper solution is to get people to stop
> > using oddball niche toolkits or coding their own, and start using the
> > more powerful and already standard libraries and kits provided by the
> > desktops (KDE and GNOME).
> 
> As long as we have more than 1 "native" toolkit, the only solution is
> standardization. Windows doesn't have only 1 toolkit. However you hardly
> have interoperability problems (except look clashes sometimes). Anyway,
> that's off topic as the topic was "look".
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list