From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22245 invoked by alias); 3 Dec 2002 21:02:12 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 22217 invoked from network); 3 Dec 2002 21:02:09 -0000 Received: from unknown (HELO pimout1-ext.prodigy.net) (207.115.63.77) by sources.redhat.com with SMTP; 3 Dec 2002 21:02:09 -0000 Received: from zaphod (adsl-64-175-38-170.dsl.pltn13.pacbell.net [64.175.38.170]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with SMTP id gB3L27E9240846; Tue, 3 Dec 2002 16:02:07 -0500 Date: Tue, 03 Dec 2002 13:02:00 -0000 From: Ian Roxborough To: Fernando Nasser Cc: insight@sources.redhat.com Subject: Re: Port to GTK+ and GNOME Message-Id: <20021203125318.639a3c90.irox@ix.netcom.com> In-Reply-To: <3DED13C9.9070506@redhat.com> References: <3DED13C9.9070506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q4/txt/msg00147.txt.bz2 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 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 >