Re: the 2.18 endgame
Hi, On Fri, Jul 10, 2009 at 4:45 PM, Matthias Clasenmatthias.cla...@gmail.com wrote: Unfortunately, I haven't heard anything about GTK+-related events at Guadec yet, so my proposal may not quite be in line with what was discussed there. Please let me know if thats the case... I will be getting back about the GTK+-related events on the mailing list soonish. GTK+ 2.90: - Outstanding GSEAL issues have not been resolved. bratsche spent some time on it, but gave up for lack of feedback As was already mentioned in this thread, GIMP almost compiles under GSEAL. Mitch claims GIMP uses a lot of GTK+ API and thus is a pretty good test case. From this I think we can deduce that the work is close to being done. There are some API issues left to figure out such as the get-by-ref and get-by-value as Cody mentioned, class private data (there is a patch for this already) and widget flags (for which Mitch seems to have a patch already). Part of the getting back I mentioned above will be evaluating exactly what is still left to be done according to the original plans. Here is my proposal: - Consider the current GLib api final (modulo minor tweaks) - Push gdbus, gvariant, extended geometry management to the next cycle - Focus on fixing CSW regressions and making CSW work on win32, doing weekly releases from now on. Alex will be on vacation for a while, unfortunately. - If client-side decorations are ready in the next week or two, we may merge that - Do weekly devel snapshots from now on, to track CSW regression fixes - Do the final 2.18 release when CSW regressions are under control, but no later than Gnome 2.28, obviously (which gives us a hard deadline of September 21) If I am allowed to comment on this, this seems very reasonable to me. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
I believe Tor is the only win32 contributor; Not true, there are several other people who contribute, too. Cody Russell (bratsche), Hans Breuer, and Dominic Lachowicz are ones that immediately come to mind. Myself, I work much less on it than I would like to. (Oh well, to be frank, I am just fooling myself; if I *really* was highly motivated, I would find the time...) My visibility is perhaps higher because I build the official win32 and win64 binaries (but then, traditionally there is or has been non-official binaries in perhaps more widespread use), and I often take part in Windows-related threads on the mailing lists. Just like apparently in the Mac OSX port, there are areas in the Win32 port that are well known to be broken and nobody has had the inspiration to fix properly. Some issues are truly hard to solve and perhaps not that important after all (we have managed so far), others just require inspiration and some intensive hacking. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
test locations
Hi, This is about 5694ab7642c9ba6fbb85424e71d1c42c17661dd1 and the location of tests. When hacking on gio, I had complained that make always decided to rebuild the tests in gio/tests while I was hacking on the library. That has quite a few inconveniences: - It results in increased output while building and in turn me not noticing compiler warnings or even error messages (when running make -j) - It results in increased build time, because it not only rebuilds the one file I changed, but all tests, too. So after getting an ok from Alex, I moved the files into tests/gio/, and got what I wanted. Apparently this was not the desired result, as Matthias moved them back. I tried to read up in the git log about why, but didn't find anything conclusive. So I'm wondering: - Should tests be located in $LIB/tests or tests/$LIB and why? - Is there a reason for tests being in both $LIB/tests and tests/$LIB? - Why are the tests built during make and not only for make check? Which are all really just subquestions in helping solve the most important question for me: - How can I solve the two problems listed above? I assume that long-term, these problems will only be getting worse as more tests are added. Cheers, Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
Matthias Clasen wrote: Yes, the api breakage was discovered soon after the merge and is fixed in 2.17.4 Perfect; I didn't notice I was still tracking the csw branch; sorry for the noise. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
Am Sun, 12 Jul 2009 19:47:21 -0700
schrieb John Ralls jra...@ceridwen.us:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications
use the XDG data directory functions in Glib, you might get away
with this too. Maybe you could invent something similar that used
the OSX bundle as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are
easy to use, and Richard Hult already abstracted it into a gobject.
But the code still has to be patched. It's not just application code,
either, but infrastructure libraries like gconf, gnome-keyring, dbus,
etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just
a define that isn't used for anything, but every one would have to
be examined, and a goodly number of them would require patching.
It's common enough to scan $PREFIX *and* runtime discovered paths
because the application may be installed in a non-standard place that
is not included in eg. XDG_DATADIRS, so that's not a mistake and will
yield lots of false positives.
Just my 2 cents,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-doc for non-library.
On Mon, 2009-07-13 at 01:28 +0200, Ali Abdallah wrote: Hi, I want to document C code written let's say in files obj.c obj.h contain GObject, signals, properties, in order to doc these gtk-doc needs the _get_type function to produce GObject doc, but this code is not a library and i don't want to have .la library in the project just to doc the code. gtk-doc only works with libraries. Make sure your library is noinst_LTLIBRARIES instead of lib_LTLIBRARIES and it won't install any gunk on the filesystem. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
It sounds like you want magic to happen. Either you have to use some
sort of script to re-normalize the paths, or you can use glib's
functions to look up data files relative to the bundle itself, without
needing to write (much) OSX-specific ObjC code. It's not inventing
anything. It's just implementing these APIs in terms of how the
operating system's packaging conventions behave.
Best,
Dom
On Sun, Jul 12, 2009 at 10:47 PM, John Rallsjra...@ceridwen.us wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications use
the XDG data directory functions in Glib, you might get away with this
too. Maybe you could invent something similar that used the OSX bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are easy to
use, and Richard Hult already abstracted it into a gobject. But the code
still has to be patched. It's not just application code, either, but
infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find
/usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk' \; `
and got more than 100 hits. Many of them are likely to be just a define that
isn't used for anything, but every one would have to be examined, and a
goodly number of them would require patching.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-doc for non-library.
Bastien Nocera wrote: On Mon, 2009-07-13 at 01:28 +0200, Ali Abdallah wrote: Hi, I want to document C code written let's say in files obj.c obj.h contain GObject, signals, properties, in order to doc these gtk-doc needs the _get_type function to produce GObject doc, but this code is not a library and i don't want to have .la library in the project just to doc the code. gtk-doc only works with libraries. Make sure your library is noinst_LTLIBRARIES instead of lib_LTLIBRARIES and it won't install any gunk on the filesystem. Yes i know, but i was wondering if there is a way to just document the source code with correct hierarchy properties signals, ... . Cheers Cheers. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Sun, 2009-07-12 at 19:47 -0700, John Ralls wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications use
the XDG data directory functions in Glib, you might get away with this
too. Maybe you could invent something similar that used the OSX bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are easy
to use, and Richard Hult already abstracted it into a gobject. But the
code still has to be patched. It's not just application code, either,
but infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just a
define that isn't used for anything, but every one would have to be
examined, and a goodly number of them would require patching.
Well, it's hard to say how many places Gnucash hard codes paths, but the
number of places in the GTK+ stack is nowhere close to 100.
http://git.fishsoup.net/cgit/reinteract/tree/src/reinteract_wrapper_osx/main.m
Sets only 7 environment variables before initializing GTK+ to get
everything found properly within the bundle.
I did need:
http://bugzilla.gnome.org/show_bug.cgi?id=554524
Hmm, Behdad gave me the commit approval on that; didn't see that.
Dom's suggestion of unifying with the Win32 functionality for locating
paths relative to the executable makes a lot of abstract sense though I
haven't looked into the practical details of how it works out.
- Owen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Sun, 2009-07-12 at 07:29 -0400, Paul Davis wrote: Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. There is no fixed core GTK+ team. The way we've always determined who gets listed in the GTK+ release announcements as the team is simply to look at who has done lots of work and taken ownership of components. [ It looks like the team list in some of the recent release announcements has gotten a bit stale; the 2.16 list includes me among some other people not doing much work at the moment. ] If someone wants to make sure that the OS/X port is released working out of the box for 2.18, they have to be building from git, fixing problems that come up, going through patches in bugzilla, etc. And then that person will be on the team and the team can make the commitment you want. In the past, when I've made changes that require per-backend changes, I've generally tried to stub out the necessary parts of the other backends if stubs make any sense. E.g., http://bugzilla.gnome.org/show_bug.cgi?id=587247 Adds a backend function that is called after processing updates; backends that don't need to do anything there don't need to do anything so stubbing out was very reasonable. But other changes do require actual work, and requiring every person submitting a patch to GDK to: A) Have a OS/X machine and a windows machine B) Know enough about OS/X and windows programming to make changes Doesn't seem reasonable. (As you say.) Requiring people making changes to GDK to provide the docs and test cases so that the people maintaining the backends can easily add the missing functionality is, on the other hand, quite reasonable. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
On Mon, Jul 13, 2009 at 5:32 AM, Benjamin Otteo...@gnome.org wrote: Apparently this was not the desired result, as Matthias moved them back. I tried to read up in the git log about why, but didn't find anything conclusive. So I'm wondering: - Should tests be located in $LIB/tests or tests/$LIB and why? - Is there a reason for tests being in both $LIB/tests and tests/$LIB? tests/ is the old location that was used for scattered tests, before we had the unified test framework we have now. tests were moved from tests/ to $LIB/tests as there were integrated in the test framework. Having the tests in $LIB/tests makes sense to me for a number of reasons: a) Moves the tests closer to the code b) cd $LIB; make check actually tests the library with all available tests - Why are the tests built during make and not only for make check? That is certainly something that can be fixed. I'd welcome a patch to so. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
On 07/13/2009 03:47 PM, Matthias Clasen wrote: - Why are the tests built during make and not only for make check? That is certainly something that can be fixed. I'd welcome a patch to so. Always building the tests ensures that they are kept up do date with changes in the rest of the code base. If they are not built along with the rest of the code base then they will eventually become out of sync and someone has to fix them later, possibly months after the change that introduced the compilation errors were made. / Martin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 13, 2009, at 3:39 AM, Christian Dywan wrote:
Am Sun, 12 Jul 2009 19:47:21 -0700
schrieb John Ralls jra...@ceridwen.us:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications
use the XDG data directory functions in Glib, you might get away
with this too. Maybe you could invent something similar that used
the OSX bundle as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are
easy to use, and Richard Hult already abstracted it into a gobject.
But the code still has to be patched. It's not just application code,
either, but infrastructure libraries like gconf, gnome-keyring, dbus,
etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just
a define that isn't used for anything, but every one would have to
be examined, and a goodly number of them would require patching.
It's common enough to scan $PREFIX *and* runtime discovered paths
because the application may be installed in a non-standard place that
is not included in eg. XDG_DATADIRS, so that's not a mistake and will
yield lots of false positives.
A valid point, and covered in my weasel-words.
XDG is a good line of attack that I hadn't really thought about, thanks.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
On Mon, Jul 13, 2009 at 3:55 PM, Martin Nordholtsense...@gmail.com wrote: Always building the tests ensures that they are kept up do date with changes in the rest of the code base. If they are not built along with the rest of the code base then they will eventually become out of sync and someone has to fix them later, possibly months after the change that introduced the compilation errors were made. That argument has essentially no value at all to me, for lots of reasons. First of all, compiling all tests while I'm experimenting on the code and nowhere near a checkin is just annoying. Next, just compiling the tests and not actually running them is almost useless, as it only finds API breakage. You need to actually run the tests to find the bugs. And in the context of glib there's a multiplied effect, as API breakage is found almost immediately. Then, I expect someone to run make check before doing checkins anyway. And if people forget it, there should be a build farm that catches it and complains loudly (either on IRC or on mailing lists), flagging the commit that broke. And finally, it's trivial to figure out which checkin broke a test with git bisect run. Note that I'm not opposed to having a useful test suite in glib and gtk - in fact, I'd welcome it. But it's important that the test suite not just aids in finding bugs but also has a very limited impact on hackers, so they don't outright reject it. The current setup seems to not be very good at that, as the number of tests does not seem to grow and people seem to never run it (yes, that includes me). I'd even say they are annoyed by it (see this mail thread), but that might just be me. If you wanted to improve the testsuite situation, you should have a look at other projects that successfully make heavy use of testsuites and copy what they do. Examples of such projects I've contributed to are Mozilla, Webkit or Cairo. (If a jibe is allowed: None of them build the testsuite on make, as it would at least double build times.) I've attached a patch that seems to work for me. Cheers, Benjamin diff Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
Benjamin, Am Montag, den 13.07.2009, 16:52 +0200 schrieb Benjamin Otte: On Mon, Jul 13, 2009 at 3:55 PM, Martin Nordholtsense...@gmail.com wrote: Always building the tests ensures that they are kept up do date with changes in the rest of the code base. If they are not built along with the rest of the code base then they will eventually become out of sync and someone has to fix them later, possibly months after the change that introduced the compilation errors were made. That argument has essentially no value at all to me, for lots of reasons. And your complaints have essentially no value to me. As make all-am is already what you are looking for (and given that it already exists, Martin's points seem to be really convincing). What's the problem in just keeping to use make all-am for your compile-warning-testing and before you commit, execute make all and be happy (unless you changes the behavior, then you want to run make check as well). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
On Mon, Jul 13, 2009 at 5:02 PM, Sven Herzberghe...@gnome-de.org wrote: Benjamin, What's the problem in just keeping to use make all-am for your compile-warning-testing and before you commit, execute make all and be happy (unless you changes the behavior, then you want to run make check as well). Huh? Currently, while hacking, you want make all-am. Before committing, you need make check. When building from tarballs, you want a recursive make all-am. Wouldn't it make sense to make the default make all useful in at least one case? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Mon, 2009-07-13 at 05:47 -0700, Owen Taylor wrote:
On Sun, 2009-07-12 at 19:47 -0700, John Ralls wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves
things
relative to where the Glib DLL is installed. If your applications
use
the XDG data directory functions in Glib, you might get away with
this
too. Maybe you could invent something similar that used the OSX
bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are
easy
to use, and Richard Hult already abstracted it into a gobject. But
the
code still has to be patched. It's not just application code,
either,
but infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H
'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just
a
define that isn't used for anything, but every one would have to be
examined, and a goodly number of them would require patching.
Well, it's hard to say how many places Gnucash hard codes paths, but
the
number of places in the GTK+ stack is nowhere close to 100.
http://git.fishsoup.net/cgit/reinteract/tree/src/reinteract_wrapper_osx/main.m
Sets only 7 environment variables before initializing GTK+ to get
everything found properly within the bundle.
I did need:
http://bugzilla.gnome.org/show_bug.cgi?id=554524
Hmm, Behdad gave me the commit approval on that; didn't see that.
Dom's suggestion of unifying with the Win32 functionality for locating
paths relative to the executable makes a lot of abstract sense though
I
haven't looked into the practical details of how it works out.
Is this something that can be done at the glib level? (If not already
done). It would be useful to non gui apps too.
Kevin
- Owen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 13, 2009, at 4:47 AM, Dominic Lachowicz wrote:
It sounds like you want magic to happen. Either you have to use some
sort of script to re-normalize the paths, or you can use glib's
functions to look up data files relative to the bundle itself, without
needing to write (much) OSX-specific ObjC code. It's not inventing
anything. It's just implementing these APIs in terms of how the
operating system's packaging conventions behave.
Best,
Dom
On Sun, Jul 12, 2009 at 10:47 PM, John Rallsjra...@ceridwen.us
wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications
use
the XDG data directory functions in Glib, you might get away with
this
too. Maybe you could invent something similar that used the OSX
bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are
easy to
use, and Richard Hult already abstracted it into a gobject. But the
code
still has to be patched. It's not just application code, either, but
infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find
/usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/
gtk' \; `
and got more than 100 hits. Many of them are likely to be just a
define that
isn't used for anything, but every one would have to be examined,
and a
goodly number of them would require patching.
Regards,
John Ralls
Um, I think that's what I said, except for the part about magic.
The problem isn't in the code I'm working on (Gnucash), it's in many
of the various libraries that Gnucash depends upon. While GTK+/Pango/
Cairo are included in that list, they're by no means all, or perhaps
even any, of the problem. I brought it up here as a side issue to my
main concern, and even added that I wasn't sure it's the right place.
Now I'm pretty sure that it isn't.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 13, 2009, at 5:47 AM, Owen Taylor wrote:
On Sun, 2009-07-12 at 19:47 -0700, John Ralls wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications
use
the XDG data directory functions in Glib, you might get away with
this
too. Maybe you could invent something similar that used the OSX
bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are easy
to use, and Richard Hult already abstracted it into a gobject. But
the
code still has to be patched. It's not just application code, either,
but infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just a
define that isn't used for anything, but every one would have to be
examined, and a goodly number of them would require patching.
Well, it's hard to say how many places Gnucash hard codes paths, but
the
number of places in the GTK+ stack is nowhere close to 100.
http://git.fishsoup.net/cgit/reinteract/tree/src/reinteract_wrapper_osx/main.m
Sets only 7 environment variables before initializing GTK+ to get
everything found properly within the bundle.
I did need:
http://bugzilla.gnome.org/show_bug.cgi?id=554524
Hmm, Behdad gave me the commit approval on that; didn't see that.
Dom's suggestion of unifying with the Win32 functionality for locating
paths relative to the executable makes a lot of abstract sense
though I
haven't looked into the practical details of how it works out.
- Owen
It is indeed hard to say. Gnucash includes binreloc code (an old copy
and paste, not up to date) which I have patched to look in a bundle if
one is available. This seems to have resolved the problem for the
Gnucash part.
I know that GTK, Cairo, and Pango are not all of the problem; I even
said so in my OP:
I realize that this is a bigger problem than just GTK, but it needs
to be addressed if GTK is to be a cross-platform framework
competitive with Qt and WxWidgets. Perhaps if there is a better
forum to discuss it someone here will point me at it.
The 100+ hits covered all of Gnucash's dependencies, and Gnucash is
rather notorious for having a lot of dependencies. Most of them are
likely to be harmless, but they all have to be checked.
Your solution in ticket 554524 is workable, if a bit inelegant. Have
you committed it?
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 13, 2009, at 6:04 AM, Owen Taylor wrote: On Sun, 2009-07-12 at 07:29 -0400, Paul Davis wrote: Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. There is no fixed core GTK+ team. The way we've always determined who gets listed in the GTK+ release announcements as the team is simply to look at who has done lots of work and taken ownership of components. [ It looks like the team list in some of the recent release announcements has gotten a bit stale; the 2.16 list includes me among some other people not doing much work at the moment. ] If someone wants to make sure that the OS/X port is released working out of the box for 2.18, they have to be building from git, fixing problems that come up, going through patches in bugzilla, etc. And then that person will be on the team and the team can make the commitment you want. In the past, when I've made changes that require per-backend changes, I've generally tried to stub out the necessary parts of the other backends if stubs make any sense. E.g., http://bugzilla.gnome.org/show_bug.cgi?id=587247 Adds a backend function that is called after processing updates; backends that don't need to do anything there don't need to do anything so stubbing out was very reasonable. But other changes do require actual work, and requiring every person submitting a patch to GDK to: A) Have a OS/X machine and a windows machine B) Know enough about OS/X and windows programming to make changes Doesn't seem reasonable. (As you say.) Requiring people making changes to GDK to provide the docs and test cases so that the people maintaining the backends can easily add the missing functionality is, on the other hand, quite reasonable. - Owen http://www.gtk.org/development.html certainly gives the impression that there exists a core and a team, though not necessarily a core team. Perhaps I should rephrase my question a bit more harshly: Is http://www.gtk.org/download-macos.html still true? Is there someone with commit authority who is working hard to finish gtk's quartz backend? Working on tickets? Applying patches? Or should gtk-osx.sourceforge.net (and maybe live.gnome.org/gtk+) include a warning that GTK mostly works on OSX for the moment, but can't be recommended for new development because it has no active maintainer? No, I'm not volunteering. Regards John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Sun, 12 Jul 2009, John Ralls wrote: On Jul 12, 2009, at 4:29 AM, Paul Davis wrote: We bundle Ardour for OS X and chose the include GTK framework in the .app. Ardour is fully relocatable - I believe I was responsible for the description of how to do this that Richard wrote up. Its basically a matter of using an apple-provided tool to both locate and reset the paths to every library the app depends on. I have a nice little shell script that recursively finds every dynamically linked object that the app uses, copies it into the app structure and then resets the link-time dependency so that its relative to the app bundle. Yes, the nice little shell script is part of ige-mac-bundler, a python program which populates a bundle and which is now in my care. But the problem isn't with rpaths. The problem is with path strings compiled into the library. Those can be adjusted via environment variables and by using relative paths in some of the config files. See http://ricardo.ecn.wfu.edu/pub/gretl/osxbuild/build.pdf Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 13, 2009, at 6:55 PM, Allin Cottrell wrote: On Sun, 12 Jul 2009, John Ralls wrote: But the problem isn't with rpaths. The problem is with path strings compiled into the library. Those can be adjusted via environment variables and by using relative paths in some of the config files. See http://ricardo.ecn.wfu.edu/pub/gretl/osxbuild/build.pdf Allin, Sometimes. Perhaps always in GTK, Cairo, and Pango. Not in dbus or GConf. (Dbus at least uses XDG. GConf doesn't.) Haven't yet looked at gnome-vfs or gnome-keychain. But none of those are GTK+ problems, so let's just drop it. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
