Widget sets (was Re: [TriLUG] redhat-config-network question)

[Brent Fox]

On Fri, 2003-02-28 at 09:57, Tanner Lovelace wrote:
> On Fri, 2003-02-28 at 00:12, Brent Fox wrote:
> 
> > You don't have to use two sets of desktops to run into the problem. 
> > Just running apps based on a different toolkit than the desktop you're
> > currently using is enough.  For example, in 7.3, if you're using KDE and
> > then launch balsa, balsa's buttons look different than other KDE apps. 
> > The user does not understand why Balsa sticks out like a sore thumb. 
> > The opposite is true if you're running Gnome and start up KMail.
> 
> Your examples are taken directly from KDE vs Gnome programs or QT vs 
> GTK.  I get your point, but your example would have been better if 
> you'd chosen something other than contrasting the difference 
> between QT and GTK, especially considering my point below.
>  
> > We have to pragmatic about where to spend our limited development
> > resources.  What good would writing our tools in both GTK and QT do? 
> > Why stop there?  Why not in Tk too?  Why not write them in C as well so
> > the anti-python lobby will be happy?  Once we're finished, we can
> > rewrite them again in Perl.  By 2008, we'd finally have some config
> > tools.  :)
> 
> No, I never said write them in every possible way.  And your
> examples of using different languages are just dumb.  Weren't you the
> one that said the user didn't care what was on the back end (or 
> something like that).  What we're talking about here is how they 
> look.

Maybe you didn't see the smiley...it was a joke.  But anyway, doesn't
theming QT and GTK to look the same accomplish the goal of having a
consistent look with much less development effort than using both
toolkits?

> > Besides, this doesn't address the problem of having apps written in
> > different toolkits look different.  You can't expect everyone to write
> > their apps in multiple toolkits.  Making QT and GTK look the same was
> > the best way to solve this problem.  The user can always change the
> > theme if they want to.
> 
> But, and here I go back to the original complaint, the whole point is
> that the user who brought this up didn't have all the space in the
> world and *didn't* want to install *both* QT and GTK.  Since QT and
> GTK seem to be the two preeminent toolkits (currently) in the linux
> world, *and* both seem to be somewhat large, I would contend that
> distributions should provide their configuration tools so that
> they're either available in both toolkits (in case one isn't installed),
> or, in some other toolkit that's a) separate b) lightweight and c)
> can be themed to look like the default theme.  

Yet AFAIK, no distributions provide config tools in both QT and GTK.  In
fact, I don't know of any application in existence that has both QT and
GTK interfaces.  It doesn't make sense.  In a world of 120 GB hard
drives, most developers are not going to write multiple interfaces just
so some users that have an intense dislike for one toolkit or other can
save 100 MB or so.  It's not a practical use of development resources.

It would slow development time, require more QA, and bloat the code. 
This is bad for developers and bad for users.  I would rather use my
time to create tools that don't exist yet rather than duplicate work
that has already been done.  I believe that provides the greatest
benefit for the larger percentage of users.  

> Red Hat, for better
> or worse, has a reputation for giving KDE the short stick.  As Lisa
> found out, significant functionality is *missing* unless you install
> Gnome.  With this one little detail, Red Hat pushes people into using
> Gnome and GTK, whether they want it or not!  (And people wonder why
> Red Hat gets the reputation of being pushy!)  This is my main complaint.
> Major configuration tools should either be written in both QT and GTK
> or in something separate like TK that doesn't cause the user to install
> both toolkits if they don't want too.

I tried this out today.  I did an install of our most recent beta and I
did a KDE only install.  I went into the individual package selection
screen and unselected all the gnome-* libraries.  I then chose to not
install packages that have dependencies on packages that aren't already
selected.  Here's the config tools I installed:

[root at bfox1 root]# rpm -qa |grep redhat-config
redhat-config-network-tui-1.2.0-2
redhat-config-printer-0.6.47-1
redhat-config-securitylevel-1.1.1-3
redhat-config-services-0.8.4-1
redhat-config-packages-1.1.8-1
redhat-config-mouse-1.0.5-1
redhat-config-network-1.2.0-2
redhat-config-date-1.5.9-8
redhat-config-language-1.0.4-1
redhat-config-rootpassword-1.0.2-4
redhat-config-soundcard-1.0.4-2
redhat-config-xfree86-0.7.3-2
redhat-config-keyboard-1.0.3-4
redhat-config-users-1.1.5-7

Here's the gnome stuff that was pulled in:

[root at bfox1 root]# rpm -qa |grep gnome
gnome-python2-canvas-1.99.14-5
libgnomecanvas-2.2.0.1-1
up2date-gnome-3.1.23-1
libgnomecanvas-devel-2.2.0.1-1
openssh-askpass-gnome-3.5p1-6

See?  It only pulled in the gnome canvas packages, which are needed for
redhat-config-date and hwbrowser.  It didn't install all of gnome.

And it's not like there's anything stopping someone from writing QT
frontends to the config tools.  They're all GPL.  Most of the
redhat-config-* tools are nicely separated into front and back ends so
you already have the back ends to work with.  There are QT bindings for
Python.  If you feel that strongly about it, fire up the editor of your
choice and go for it.  

> BTW, realize also that I fault Mandrake for this too.  Although their
> support of KDE and QT is a *lot* better than Red Hat's, they too
> wrote their configuration tools in GTK.  So, this isn't just a Red
> Hat problem.

I've always wondered why they did their config tools in GTK and not QT.
I've never figured it out.  Shrug.


Cheers,
    Brent