[Top][All Lists]
[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-----
Re: [GNUnet-developers] gnunet-gtk portability, Tim Müller, 2003/08/29