Re: Port to GTK+ and GNOME

[Ian Roxborough <irox at ix dot netcom dot com>]

Hi Fernando,

I've looked at this problem a couple of times in the past.

tcl-gtk is an interesting project, I wrote a small test program to
see if it was worth using that for Source Navigator, but I felt that
I was loosing much of the benefits of tcl/tk and what should have
been a short program ended up being kind of long.  I've not used
tcl-gtk for a few years, so this might not still be an issue.
However, I feel the work involved in this would be similar to
writing the application.

The solution I was really interested in trying to implement was to
add some sort of generic themeability to Tk, such that it would be
able understand GTK or Qt themes.  I actually got some parts working
and there where a couple of screen shots of SN running the AquaX
theme.  BLT has gone part of the way to providing some of functionality
needed, in particular the tiled widgets that allow bitmap backgrounds
on buttons, listboxes and other things.  Using BLT a writing a bitmap scaling
fuction so you can use scaled bitmap buttons should get you most of
the way there.  Of course not all themes are bitmaps so you might
want to use a theme engine to convert them to bitmaps as needed.

I noticed a couple of ambiguities between the GTK and TK, but they where
minor things, like some widgets not having a boarder or not have a
disabled state.  I don't believe there is anything that would give too
much of a problem.

Ian.

On Tue, 03 Dec 2002 15:27:53 -0500
Fernando Nasser <fnasser@redhat.com> wrote:

> Dear Insight developers and friends,
> 
> With the increasing acceptance of GTK+ and GNOME in many *ix systems, 
> Insight may have to follow the pack and become more consistent with
> the GNOME look-and-feel and somehow migrate to use GTK+ in some form.
> 
> There are currently 3 different possible approaches:
> 
> 1) Use gnocl (loosely modeled after TK)
> 2) Use tcl-gtk (just wraps GTK, or any other GObject based library)
> 3) add a GTK+ port to TK itself
> 
> All of these approaches have their merits and there are trade-offs
> among them.  I wonder if some of you haven't given any thoughts
> already to this and perhaps, have used any of these packages mentioned
> in 1 and 2, know the developers, what the prospects are etc. (these
> projects are still to release -- all they have are betas at the
> moment).
> 
> A GTK port of TK (as we currently have the Win32 and "Unix" variants) 
> would make automatically all Tcl/Tk programs to use GTK (and some
> GNOME widgets like the file chooser).  But I wonder how much of the 
> look-and-feel of GNOME would we get, as it would be still Tk on top 
> (probably more of the look than the feel).
> 
> There is also the problem of implementation --  there is no clear API 
> interface between these Tk layers. The process was not documented
> either (done by Sun, ages ago).  The magic seems to be done by
> changing the Tk callbacks to some windows or unix specific functions
> in the windows or unix subdirectories (only one of the two is
> configured) but there is little common ground between what was done
> for one and the other.  It will probably require a very good TK
> internals knowledge.
> 
> 
> Things that we must discuss, besides the maintainability issues
> related to using one of the packages 1 and 2, are the effort required
> to complete the task.  We don't have many developer hours to do this
> as we all seem to be very busy with our other affairs.
> 
> We will probably want to coordinate with other Tcl?Tk open source 
> projects (like Source Navigator, Red Hat Database Administrator etc.)
> so that we do not waste efforts going in opposite directions.
> 
> 
> Please take some time to think about this and speak your minds.  The 
> future of Insight may depend on this.
> 
> 
> Regards to all,
> Fernando
> 
> 
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
>