Re: Harmony + GNOME (Was: Re: C++)

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Thu, 23 Apr, 1998 at 10:08:26PM -0500, Francisco Bustamante set free these words:
> >  > that's the problem ... I bet a lot of people who write theme will only
> >  > do a gtk theme as that's the main reason to the theme ... doing a harmony
> >  > theme port will be secondray .. so I'd guess unless there is a LOT
> >  > of harmony apps there is gonna be less themes so a particular theme
> >  > will only work on gnome/gtk apps
> >  
> >    Well, firstly we may be able to find a way to use gtk themes through a
> >  Harmony 'adapter' theme. Secondly, how many themes are there likely to be?
> >  Not a huge number. I'd say you'd probably get the following:
> >  
> >  	Windows
> >  	Mac
> >  	Nextstep
> >  	Motif 1.2
> >  	Motif 2.0
> >  	Pixmap-based
> >  
> >    We can write Harmony to understand whatever config files are used by the
> >  pixmap-based theme, so it's just a matter of duplicating the others
> >  (which as a stopgap could be temporarily emulated with pixmap themes in
> >  any case). Duplicating a theme someone else has already written isn't
> >  heavy work; it could be done within a week for the basic set of widgets I
> >  should think.
> 
> What seems to be making people want to use a toolkit other than gtk is
> that they wish to use C++. I don't think this should be a reason to
> change one of gnome's basic goals, which is having a standard look and
> feel, and applications working with each other. I think that if we
> wanted to use whatever toolkit we wanted there wouldn't be much point
> in gnome.
> 
One of gnome's basic goals is look and feel, but it's not all of the goals --
and perhaps not even the most important (depends who you ask, I suspect).  So
using another Look and Feel scheme doesn't immediately 100% disqualify an app.
If it was able to Drag and Drop with other GNOME apps, provide and use
appropriate CORBA services, etc  I think it would be near enough to a gnome
app for a lot of people to use.  Even better, if the toolkit used in this app
was able to emulate the Look and Feel, themes, etc of gnome apps (which  it
looks like Harmony is intending to do.)  Then the only drawback would be using
up extra resources to load the toolkit behind the app... and that's something
I've never seen as one of gnome's proposed goals (saw it mentioned in KDE's
initial announcement though.)

> If C++ support for gtk needs to be improved, that is IMO easier and
> faster than writing a whole toolkit from scratch and trying to catch
> up with gtk's features. Besides, I wouldn't like more libs using
> memory to be able to run app with "Gnome complaint" toolkits.
> 
I agree with this, but it seems Harmony's primarily aimied at making KDE free
software.  If the developers are willing to make Harmony as compatible with
Gnome as they can, I'm all for it!  The increased memory requirements may make
me only run an app using Harmony when I need that particular "killer app", but
it would still be my option.  Improved C++ support for gtk+ is a related but
separate issue from alternate toolkits.  If gtk+'s C++ support was "good
enough" there'd be no reason for anyone to code for qt anymore.... but I doubt
that's going to happen -- qt is good enough that someone interested in doing
it would have to create a qt wrapper for gtk+ (the Harmony guys seem to have
set their own goals so this would be a new and different project.) or come out
with some interface that was somehow stellarly beyond what is currently on the
market.  (If you'd care to do either of those, however, I'd be more than happy
to use ;-)

-Toshio
-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~