Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
-mental
On Sun, 4 Jan 2004, MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
What features specifically?
Bryce
On Sun, 2004-01-04 at 23:23, Bryce Harrington wrote:
On Sun, 4 Jan 2004, MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
What features specifically?
The ones I've run up against recently are the fullscreen stuff and some of the glib string utilities (e.g. g_str_has_suffix()).
-mental
On Mon, 5 Jan 2004, MenTaLguY wrote:
On Sun, 2004-01-04 at 23:23, Bryce Harrington wrote:
On Sun, 4 Jan 2004, MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
Mandrake 9.1 has 2.0. I haven't tried upgrading, though I expect it'd be quite painful.
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
What features specifically?
The ones I've run up against recently are the fullscreen stuff and some of the glib string utilities (e.g. g_str_has_suffix()).
I imagine it must be frustrating to have to work around those lacks, however it sounds like it would be beneficial to stay with 2.0 a bit longer, until we're more confident that a larger proportion of the userbase is on Gtk2.2-based systems.
Bryce
On Jan 4, 2004, at 7:51 PM, MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
I'd have a problem, since RH 8.0 only has GTK+ 2.0
Also, I was starting to track a few things down, and it looks like the fedora legacy project hit quite a few people still using 8.0 on many systems.
Jon A.Cruz wrote:
On Jan 4, 2004, at 7:51 PM, MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
I'd have a problem, since RH 8.0 only has GTK+ 2.0
Also, I was starting to track a few things down, and it looks like the fedora legacy project hit quite a few people still using 8.0 on many systems.
Debian or Gentoo will make the pain go away :)
njh
MenTaLguY wrote:
Would anyone have any problems if we bumped the gtk configure-time requirement to >= 2.2.0?
We're already having trouble with 2.2-specific stuff getting introduced, since (I think) that's what most of the developers have. We may as well make the dependency explicit if we use those features.
-mental
I think that should be OK here. I think the Win32 DLLs are at 2.2 already.
Again, yet ANOTHER benefit of static libs: you don't need to worry about what the customer has installed.
On the other hand, an interim way of getting around the download factor is to supply the dependent .so's along with Inkscape.
Bob
On Mon, 2004-01-05 at 09:45, Bob Jamison wrote:
On the other hand, an interim way of getting around the download factor is to supply the dependent .so's along with Inkscape.
I don't think that solution would fly on Linux; asking around what people actually have, we'll have to stick with Gtk 2.0 for a while longer yet.
-mental
MenTaLguY wrote:
On Mon, 2004-01-05 at 09:45, Bob Jamison wrote:
On the other hand, an interim way of getting around the download factor is to supply the dependent .so's along with Inkscape.
I don't think that solution would fly on Linux; asking around what people actually have, we'll have to stick with Gtk 2.0 for a while longer yet.
-mental
Well, you could link with -rpath, so that the client app will look for the .so's in a particular place, regardless of that the LD path is. That is how the Linux Java JRE finds the proper .so's, even when you copy the /jre directory to your application's directory.
Bob
participants (5)
-
Bob Jamison -
Bryce Harrington -
Jon A.Cruz -
MenTaLguY -
Nathan Hurst