gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] gnunet-gtk portability


From: Tim Müller
Subject: Re: [GNUnet-developers] gnunet-gtk portability
Date: Thu, 28 Aug 2003 09:25:20 +0100
User-agent: KMail/1.5.3

On Sunday 24 August 2003 11:10, N. Durner wrote:

Hi,

> I've tried to build gnunet-gtk under CYGWIN using the GTK+ package from
> http://www.dropline.net/gtk/.
> It doesn't work because GTK+ relies on the Microsoft C runtime library and
> it is not possible to use the CYGWIN runtime library (on which we rely on)
> *and* the one from Microsoft.

Sorry, but that doesn't make a lot of sense to me. Why would a GUI toolkit 
that is mainly used in the *nix-world rely on the Microsoft C runtime 
library?

Have you tried using another Gtk-for-cygwin package like this one here, or 
compile it from scratch?

http://web.sfc.keio.ac.jp/~s01397ms/cygwin/


Also, the packages at http://www.dropline.net/gtk/ are Gtk+-2.x (just as the 
ones at the URL above), but last I checked gnunet-gtk was based on Gtk+-1.2, 
so you might have additional problems there.


> So I started to write some "GTK-like" functions that simply call the
> appropriate Windows API functions.
> However, I have difficulties implementing "window manager" functions like
> gtk_table_xxx and gtk_vbox_xxx, because there is no such thing under
> Windows.

Why are you doing this exactly? I don't quite see how GtkVBox and GtkTable 
have anything to do with the window manager.


> Would it be too bad to remove these functions from the gtkui-source and
> hardcode sizes and positions?

This is the way Gtk+ works - you don't hardcode sizes or positions, unless in 
very very special cases. I don't think gnunet-gtk is one of those cases. This 
might be different from other toolkits you are used to, but that's the way it 
works. Using hardcoded sizes and positions in Gtk+ will in the long run cause 
a lot of headaches and probably lead to a bad GUI.

If you start replacing gtk_* functions with 'Windows API' functions, you would 
probably be better off rewriting the GUI from scratch using a toolkit you're 
more familiar with.

However, I don't really see any real reason why gnunet-gtk shouldn't be 
portable to cygwin/windows, especially if it is ported to Gtk+-2.x. After 
all, gnunet-gtk is not exactly a complex GUI interface with many weird corner 
cases, and other far more complex gtk+ projects have managed to do a 
cygwin/windows port as well.


Sorry for this not exactly constructive mail. I don't have access to a windows 
installation at the moment, otherwise I'd try to help out. However, the 
approach suggested just didn't seem quite right, so I thought I'd voice my 
concerns anyway :-)

Cheers
-Tim







reply via email to

[Prev in Thread] Current Thread [Next in Thread]