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: Christian Grothoff
Subject: Re: [GNUnet-developers] gnunet-gtk portability
Date: Sun, 24 Aug 2003 17:26:50 -0500
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 24 August 2003 05:10 am, 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.
>
> 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.
>
> Would it be too bad to remove these functions from the gtkui-source and
> hardcode sizes and positions?

Actually, if you look at the "todo" file, I said that I'd like to arrange some 
of the GTK windows a bit better (and I wanted to specify some fixed sizes) 
but I didn't have the time to figure out how to do it with GTK so far. 
Persionally, I disklike the window-manager'ish component layout of GTK and 
would prefer fixed offsets that I can hard-code, but I didn't bother to 
figure out how so far. So if anyone wants to dive in and hardwire a bunch of 
offsets to reasonable values, I'm all game. If it helps portability, all the 
better. 

Apropos portability, I'm planning on moving all the #ifdef platform code into 
helper-functions in gnunet-util (except from gnunet-gtk). Ideally, we should 
have a bunch of testcases for gnunet-util and testing a port should ONLY 
require touching gnunet-util to make the tests pass. After that, everything 
should "just" work. 

Also, if you look at the latest CVS (post 0.5.5), I've started to refactor the 
library structure and the header organization. My goal is to have a couple of 
header files in src/include that are actually installed in /usr/include to 
allow developers to use our libraries without integrating their code into our 
CVS tree. Also, I'm trying to reduce the number of libraries to a more 
reasonable level (I've been able to shorten the gnunet.spec file by 70 lines, 
mostly by reducing the proliferation of GNUnet libraries...). 

I hope these changes will make it easier to port the code (my attempts with an 
OSX port have so far failed miserably [the battle is with libtool about 
dlopen...])

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/STuq9tNtMeXQLkIRAmDHAJ97ic6ut4byAUq8PowOiFHrl599QwCfSjOH
esKKmX1luC2fg58pQopWShw=
=rhxi
-----END PGP SIGNATURE-----





reply via email to

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