On Thursday 03 February 2005 21:12, Sven Neumann wrote:

Hi,

yesterday I started to port some code in GIMP CVS to functionality that is only in glib-2.6. So we are now depending on glib >= 2.6.0. glib-2.6 has been packaged for most distros for quite a while so that dependency shouldn't cause any problems.

I should note that Mandrake 10.1 (much less older releases) does not ship with glib-2.6. I was able to build the glib-2.6 SRPMS from Mandrake Cooker without too many problems, though.

Mitch, me and probably others already have some changes pending that would introduce a dependency on gtk+-2.6. So far we have usually waited until a package reaches debian testing before depending on it. Since gtk+-2.6 only just yesterday appeared in debian unstable, this would mean waiting at least another nine days. Now I wonder if that's worth it. I'd rather ask you to speak up if you want to hack on GIMP CVS and a dependency on gtk+-2.6 would cause you serious problems. If noone objects, we will bump the minimum required gtk+ version this weekend.

I haven't tried to compile gtk-2.6 for Mandrake yet. At the worst case, I can install it from source using ./configure --prefix=.

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

On Fri, Feb 04, 2005 at 07:44:09AM +0200, Shlomi Fish wrote:

yesterday I started to port some code in GIMP CVS to functionality that is only in glib-2.6. So we are now depending on glib >= 2.6.0. glib-2.6 has been packaged for most distros for quite a while so that dependency shouldn't cause any problems.

I should note that Mandrake 10.1 (much less older releases) does not ship with glib-2.6. I was able to build the glib-2.6 SRPMS from Mandrake Cooker without too many problems, though.

Mitch, me and probably others already have some changes pending that would introduce a dependency on gtk+-2.6. So far we have usually waited until a package reaches debian testing before depending on it. Since gtk+-2.6 only just yesterday appeared in debian unstable, this would mean waiting at least another nine days. Now I wonder if that's worth it. I'd rather ask you to speak up if you want to hack on GIMP CVS and a dependency on gtk+-2.6 would cause you serious problems. If noone objects, we will bump the minimum required gtk+ version this weekend.

I haven't tried to compile gtk-2.6 for Mandrake yet. At the worst case, I can install it from source using ./configure --prefix=.

Just for your consideration: I failed to install GTK 2.6 on a SuSE 9.1 machine. A lot of weir things happened (fonts were not being found, gdm crashed, some unresolved symbol XineramaIsActive etc.). I had to remove GTK 2.6 and GLIB 2.6, to get a usable system again.

I'm not a developer, so this is not an objection, just a note.

Bye, Tino.

On Thursday 03 February 2005 23:27, Tino Schwarze wrote: snip

Just for your consideration: I failed to install GTK 2.6 on a SuSE

9.1

machine. A lot of weir things happened (fonts were not being found,

gdm

crashed, some unresolved symbol XineramaIsActive etc.). I had to

remove

GTK 2.6 and GLIB 2.6, to get a usable system again.

I'm not a developer, so this is not an objection, just a note.

Bye, Tino.

I have also tried installing GTK 2.4 on SuSE 9.1 without success. I have not tried 2.6 yet. SuSE 9.1 comes with GTK 2.2.4. Many things stop working when GTK 2.4 is installed and it appears that many applications would need to be rebuilt to get things working again. I am considering installing SuSE 9.2 as it comes with GTK 2.4. Wish there was a better way to deal with these libraries. But again don't stop moving forward on my account.

From: "Hal V. Engel"
Date: Fri, 4 Feb 2005 13:24:30 -0800

--nextPart10261261.yohHSzoVkz Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Thursday 03 February 2005 23:27, Tino Schwarze wrote: snip
>=20
> Just for your consideration: I failed to install GTK 2.6 on a SuSE=20 9.1
> machine. A lot of weir things happened (fonts were not being found,=20 gdm
> crashed, some unresolved symbol XineramaIsActive etc.). I had to=20 remove
> GTK 2.6 and GLIB 2.6, to get a usable system again. >=20
> I'm not a developer, so this is not an objection, just a note. >=20
> Bye, Tino.

I have also tried installing GTK 2.4 on SuSE 9.1 without success. I=20 have not tried 2.6 yet. SuSE 9.1 comes with GTK 2.2.4. Many things=20 stop working when GTK 2.4 is installed and it appears that many=20 applications would need to be rebuilt to get things working again. I=20 am considering installing SuSE 9.2 as it comes with GTK 2.4. Wish=20 there was a better way to deal with these libraries. But again don't=20 stop moving forward on my account.

I was able to install GTK 2.4 from usr-local-bin.org, but they don't have 2.6 up at this time. I recall having a lot of problems trying to compile either 2.4 or 2.6.

On Saturday 05 February 2005 15:15, Sven Neumann wrote:

Hi,

Robert L Krawitz writes:

I recall having a lot of problems trying to compile either 2.4 or 2.6.

There is not much software that is more straight-forward to build than GTK+. If you have problems to build GTK+, you should ask. But please don't spread FUD about it being a complex and unsolvable problem.

Sven, I don't believe Mr. Krawitz has been spreading FUD about it. What he said was:

<<<
I was able to install GTK 2.4 from usr-local-bin.org, but they don't have 2.6 up at this time. I recall having a lot of problems trying to compile either 2.4 or 2.6.

He did not say it may necessary be the case, just that it was the case for him. I don't consider what he said as FUD-spreading.

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

From: Sven Neumann
Date: Sat, 05 Feb 2005 15:16:56 +0100

"Hal V. Engel" writes:

> I have also tried installing GTK 2.4 on SuSE 9.1 without success. I > have not tried 2.6 yet. SuSE 9.1 comes with GTK 2.2.4. Many things > stop working when GTK 2.4 is installed and it appears that many > applications would need to be rebuilt to get things working again.

You are doing something wrong then. The GTK+-2.x series provides binary backward compatibility. Applications compiled against older versions of glib/pango/gtk+ will continue to work after an upgrade. There's no need to recompile anything. And this is not just a myth, it definitely works. I am running a GNOME desktop where almost everything was built against gtk+-2.4.x. As promised, upgrading to gtk+-2.6 didn't introduce any problems whatsoever.

This doesn't mean that there's necessarily a problem with GTK+ per se, but it does seem to be a bit tricky to compile GTK on SUSE 9.1. In particular, take a look at the .srpm's from the SUSE distribution to see if there are any patches included, and make sure to apply those to the 2.6 tarballs.

SUSE is a great distribution, but they do have a somewhat unfortunate habit of making changes that don't always preserve compatibility. I ran across an example recently with a (small) change they made to Qt and an accompanying change to KDE that would have made it impossible to run their KDE RPM's against Qt built from Trolltech's sources. Not saying that that's the case here, but it should be investigated.

There could be plenty of other reasons why, of course. But it isn't FUD for people to report that they're having problems compiling and running GTK 2.6 against a particular distribution. Multiple people reporting the same thing suggests there's an issue, but doesn't pinpoint where it is.

BTW, I just dropped a note to James Ogley (maintainer of usr-local-bin) to see if he has any plans to upgrade his stuff to gtk 2.6.

On Friday 04 February 2005 07:44, Shlomi Fish wrote:

On Thursday 03 February 2005 21:12, Sven Neumann wrote:

Mitch, me and probably others already have some changes pending that would introduce a dependency on gtk+-2.6. So far we have usually waited until a package reaches debian testing before depending on it. Since gtk+-2.6 only just yesterday appeared in debian unstable, this would mean waiting at least another nine days. Now I wonder if that's worth it. I'd rather ask you to speak up if you want to hack on GIMP CVS and a dependency on gtk+-2.6 would cause you serious problems. If noone objects, we will bump the minimum required gtk+ version this weekend.

I haven't tried to compile gtk-2.6 for Mandrake yet. At the worst case, I can install it from source using ./configure --prefix=.

Well, now I tried to compile and install gtk-2.6 on Mandrake 10.1. I used the Cooker Source RPMs, and compiled them each in turn. gtk+-2.6.0 required the new version of pango, which in turn required the new version of automake 1.8 to be compiled. The compilation of the automake 1.8 RPM took a long time due to the fact that all the tests was run. There's a macro in the beginning of the RPM SPEC that instructs the tests not to run, so I suggest people either set it to false or install the automake-1.8 compiled RPM.

That was my main problem. After that everything mostly went well. When I installed the gtk RPMs, I got a file conflict with one of the files of gtk-engines2, so I had to use "rpm --replacefiles". Compiling the new gtk-engines2 RPM worked, but trying to install it ended up in other packages that required it as a dependency, so I did not go into there.

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

From: Sven Neumann
Date: Sat, 05 Feb 2005 18:36:29 +0100

Robert L Krawitz writes:

> There could be plenty of other reasons why, of course. But it isn't > FUD for people to report that they're having problems compiling and > running GTK 2.6 against a particular distribution. Multiple people > reporting the same thing suggests there's an issue, but doesn't > pinpoint where it is.

I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are "a lot of problems" doesn't help at all and is what I would consider spreading FUD. We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone.

It's been a while since I tried it (when GIMP 2.2 came out), so I don't remember for certain what happened. It may have even been something getting confused about /usr vs. /usr/local (in which case it wouldn't be a GTK problem at all), but I honestly don't remember.

On Sat, 05 Feb 2005 18:36:29 +0100, Sven Neumann wrote:

Hi,

Robert L Krawitz writes:

There could be plenty of other reasons why, of course. But it isn't FUD for people to report that they're having problems compiling and running GTK 2.6 against a particular distribution. Multiple people reporting the same thing suggests there's an issue, but doesn't pinpoint where it is.

I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are "a lot of problems" doesn't help at all and is what I would consider spreading FUD.

This still doesn't meet the definition of "spreading FUD." To spread FUD you must:
1) Either lie or deliberately misrepresent the truth (this includes selective retelling of the facts)
2) In one or more fora such that a large number of poorly-informed people are reached
3) In an attempt to keep people from using a competitor's product (esp. to keep them from switching from your product.)

The reports from SUSE users that they have had problems upgrading gtk don't meet any of the three requirements. Thus they are not spreading FUD. You don't get to redefine the term. :)

We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone.

You asked if going to 2.6 would cause a problem for them, and they indicated it would. They didn't ask you for any help in solving their distro woes, so it was wrong for you to criticize them for that. (especially by using such a loaded term.)

I especially find it amusing that you consider the vagueness of the SUSE user's descriptions to be a problem because you've been much less clear in this thread than they have. Here is a perfect example:

Mitch, me and probably others already have some changes pending that would introduce a dependency on gtk+-2.6.

What exactly are these changes? Why are they so critical? By your (unusual) definition, you've been spreading FUD about gtk 2.4, saying that it is inadequate without saying what the problems are, which, as you so astutely observe, "doesn't help anyone."

For the record, I have no problems with using 2.4, especially if they've fixed the disaster that was the 2.4 file selector dialog. (Why do I say disaster? Because it was _less usable_ for me than the original dialog, but ymmv.)

Rockwalrus

hello,
On Sat, Feb 05, 2005 at 06:36:29PM +0100, Sven Neumann wrote:

I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are "a lot of problems" doesn't help at all and is what I would consider spreading FUD. We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone.

i heard earlier this week that gtk+-2.6 is available on debian sid now. none of the sources i checked had it and still today, an apt-get update and still only gtk+-2.4 is available.

perhaps you could share the debian source of gtk+-2.6?

carol

On Sat, 5 Feb 2005 13:53:27 -0800, Carol Spears wrote:

i heard earlier this week that gtk+-2.6 is available on debian sid now. none of the sources i checked had it and still today, an apt-get update and still only gtk+-2.4 is available.

perhaps you could share the debian source of gtk+-2.6?

http://packages.debian.org/unstable/libs/libgtk2.0-0

Rockwalrus

thanks rock!
On Sat, Feb 05, 2005 at 04:57:39PM -0500, Nathan Summers wrote:

On Sat, 5 Feb 2005 13:53:27 -0800, Carol Spears wrote:

i heard earlier this week that gtk+-2.6 is available on debian sid now. none of the sources i checked had it and still today, an apt-get update and still only gtk+-2.4 is available.

perhaps you could share the debian source of gtk+-2.6?

http://packages.debian.org/unstable/libs/libgtk2.0-0

i guess that apt is not so well named lately? maybe "apt not to" is better?

carol

Nathan Summers writes:

This still doesn't meet the definition of "spreading FUD." To spread FUD you must:
1) Either lie or deliberately misrepresent the truth (this includes selective retelling of the facts)
2) In one or more fora such that a large number of poorly-informed people are reached
3) In an attempt to keep people from using a competitor's product (esp. to keep them from switching from your product.)

For those who are not familiar with the term FUD it is an acronym for Fear, Uncertainty, and Doubt.

I probably should have said that I believed that the problems I had with GTK 2.4 were likely caused by the RPMs I was using (user local bin) as I had not tried building it myself. So this is a SuSE 9.1 specific problem. There have been some rather lengthly discussions about this on a SuSE forum that I frequent and some users are able to install this using these RPMs with no problems and others encounter significant problems. It appears to be about 50/50 odds. No one seems to know why.

Also I was not asking that you stop moving forward as I specificly said in my earlier note to not worry about my problem and to go forward. I will try building 2.6 from source in the next few days and if I run into a problem I will ask for assistance.

From: "Hal V. Engel"
Date: Sat, 5 Feb 2005 17:46:17 -0800

I probably should have said that I believed that the problems I had=20 with GTK 2.4 were likely caused by the RPMs I was using (user local=20 bin) as I had not tried building it myself. So this is a SuSE 9.1=20 specific problem. There have been some rather lengthly discussions=20 about this on a SuSE forum that I frequent and some users are able to=20 install this using these RPMs with no problems and others encounter=20 significant problems. It appears to be about 50/50 odds. No one=20 seems to know why. =20

Interesting. I had no problem with the usr-local-bin RPM's for GTK 2.4. BTW, are you running KDE? One thing that comes to mind is that by default in SUSE KDE installs a GTK theme; you can try turning that off by creating a file (zero length is fine) in your home directory named ".no-qtrc-to-gtkrc-mapping" (no quotes, of course).

As it happens, I'd really like to run GTK 2.6, if for no other reason than the horrible browser dialog in 2.4, and perhaps it's worth trying again.

Also I was not asking that you stop moving forward as I specificly said=20 in my earlier note to not worry about my problem and to go forward. I=20 will try building 2.6 from source in the next few days and if I run=20 into a problem I will ask for assistance.

Agreed -- I consider Sven's note to be an FYI and I certainly don't think that my comment should have been interpreted as asking Sven not to do this. It was just a comment since I noticed other people using SUSE 9.1 having problems with this.

On Thu, Feb 03, 2005 at 08:12:18PM +0100, Sven Neumann wrote:

Mitch, me and probably others already have some changes pending that would introduce a dependency on gtk+-2.6. So far we have usually waited until a package reaches debian testing before depending on it. Since gtk+-2.6 only just yesterday appeared in debian unstable, this would mean waiting at least another nine days. Now I wonder if that's worth it. I'd rather ask you to speak up if you want to hack on GIMP CVS and a dependency on gtk+-2.6 would cause you serious problems. If noone objects, we will bump the minimum required gtk+ version this weekend.

i am curious to see what changes having gtk+-2.6 bring to poor gimp. many of the problems with the 2.4 fileselector get shoved off because of this great thing called gtk+-2.6. can we see a screen shot or even several of the new things?

about the dependency, i just spent the better part of a day wrestling to get it installed on debian. upgrading to sid seemed to be the solution but even then, you have to use the right sources as this newer gtk+ is not making it to all of them.

before i upgraded to sid, i tried to build it and its dependencies from the tarball. this attempt was abandoned when the pango tarball install broke after running "make install". i have yet to fix a build problem that occurs during installation on my own.

i guess that i am of average abilities for installing software; an average that is slightly better (usually) because i am building on debian. if i had problems building pango, i think that several others (especially those using other distributions) will have many more problems building the new gtk and its dependents. on the other hand, it will slow down things in bugzilla (maybe) if not so many people are using the cvs gimp and the developers will have more time to get ahead with whatever those great and wonderful things are.

btw, i had to use gimp-1.2 the other day (the broken color tools which were fixed right away, thanks) and let me tell you this, totally from a user perspective. looks and thumbnails are one thing -- a tool that works, this is a far better thing. it was a pure joy to have a file selector that worked with you and was smart. sure, i missed the thumbnail but i actually accomplished the work i needed to do much more quickly and efficiently. and got to where i needed to go on my computer much more quickly without the easy to become stale bookmarks.

meanwhile, gimp is compiling now with gtk+-2.6 -- i am curious to see what i get from all the initial trouble of installing it.

thanks for your work, everyone.

carol

On Sat, Feb 05, 2005 at 02:49:43PM -0500, Robert L Krawitz wrote:

From: Sven Neumann
Date: Sat, 05 Feb 2005 18:36:29 +0100

Robert L Krawitz writes:

> There could be plenty of other reasons why, of course. But it isn't > FUD for people to report that they're having problems compiling and > running GTK 2.6 against a particular distribution. Multiple people > reporting the same thing suggests there's an issue, but doesn't > pinpoint where it is.

I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are "a lot of problems" doesn't help at all and is what I would consider spreading FUD. We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone.

It's been a while since I tried it (when GIMP 2.2 came out), so I don't remember for certain what happened. It may have even been something getting confused about /usr vs. /usr/local (in which case it wouldn't be a GTK problem at all), but I honestly don't remember.

Fairly likely. Mixing libraries and headers in system paths often leads to trouble.

There's always the option of sticking things into non-system dirs (e.g., $HOME/devel) using ./configure --prefix, and setting PATH, LD_LIBRARY_PATH, and PKG_CONFIG_PATH. On several machines I use, I stick the HEAD versions of glib, gtk+ etc., along with HEAD gimp there.

Doing this makes it much harder to do whatever catastrophic screwups people do that messes up their working system. One can install the new gtk+ just for gimp and be fine.

-Yosh

On Sun, Feb 06, 2005 at 09:58:27AM +0100, Marc A. Lehmann wrote:

On Sat, Feb 05, 2005 at 02:17:43PM -0800, Carol Spears wrote:

http://packages.debian.org/unstable/libs/libgtk2.0-0

i guess that apt is not so well named lately? maybe "apt not to" is better?

$ apt-get install libgtk2.0-0/unstable Reading Package Lists... Done
Building Dependency Tree... Done
Selected version 2.6.1-2 (Debian-amd64:3.2/unstable) for libgtk2.0-0 libgtk2.0-0 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 77 not upgraded.

2.6 is definitely in unstable, and apt works fine to retrieve it.

this confirms my suspicions that apt has a personal vendetta against just me.

carol

On 06.02.2005, at 02:46, Hal V. Engel wrote:

I probably should have said that I believed that the problems I had with GTK 2.4 were likely caused by the RPMs I was using (user local bin) as I had not tried building it myself. So this is a SuSE 9.1 specific problem. There have been some rather lengthly discussions about this on a SuSE forum that I frequent and some users are able to install this using these RPMs with no problems and others encounter significant problems. It appears to be about 50/50 odds. No one seems to know why.

For all SUSE users in here I will try to contact the right people in this company and have them generate gtk+/glib packages for some recent versions of their distribution so you can continue having your own GIMP builds without other conflicts.

Servus, Daniel

On Sunday 06 February 2005 02:21, Daniel Egger wrote:

On 06.02.2005, at 02:46, Hal V. Engel wrote:

I probably should have said that I believed that the problems I had with GTK 2.4 were likely caused by the RPMs I was using (user local bin) as I had not tried building it myself. So this is a SuSE 9.1 specific problem. There have been some rather lengthly

discussions

about this on a SuSE forum that I frequent and some users are able

to

install this using these RPMs with no problems and others encounter significant problems. It appears to be about 50/50 odds. No one seems to know why.

For all SUSE users in here I will try to contact the right people in this company and have them generate gtk+/glib packages for some recent versions of their distribution so you can continue having your own GIMP builds without other conflicts.

Servus, Daniel

I have started building GTK 2.6.2 glib 2.6.2, pango 1.8.0 and atk 1.9.0 all installed without any apparent problems. GTK configures with any problems but fails on the make with the following error messages:

GTK/gtk+-2.6.2/demos/gtk-demo/rotated_text.c:86: undefined reference to `pango_renderer_draw_layout'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_set_color'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_get_type'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_get_color'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_xft_renderer_get_type'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_set_matrix'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_deactivate'
../../gtk/.libs/libgtk-x11-2.0.so: undefined reference to `pango_attr_shape_new_with_data'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_draw_glyphs'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_part_changed'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_draw_layout_line'
../../gdk/.libs/libgdk-x11-2.0.so: undefined reference to `pango_renderer_activate'
collect2: ld returned 1 exit status
make[5]: *** [gtk-demo] Error 1
make[5]: Leaving directory
`/home/heng/sources/GTK/gtk+-2.6.2/demos/gtk-demo' make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/heng/sources/GTK/gtk+-2.6.2/demos/gtk-demo' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/heng/sources/GTK/gtk+-2.6.2/demos' make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/heng/sources/GTK/gtk+-2.6.2/demos' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/heng/sources/GTK/gtk+-2.6.2' make: *** [all] Error 2

So perhaps pango did not install correctly. I did a search of the gtk email list archives to see if I could find something that would give me some clues about what to look for or try. But I didn't find anything. So for the moment I am stuck. It is late and I am tired so I am about to sleep on it. But perhaps someone here with more experience with this than I can give me some guidance on what to do next.

Also this has not caused any problems on my machine unlike the RPMs I had tried a while back. So this is good news. At this point I believe that if I can resolve this problem I will be good to go.

On Sat, Feb 05, 2005 at 11:17:09PM +0100, Sven Neumann wrote:

You asked if going to 2.6 would cause a problem for them, and they indicated it would.

No, they didn't. They said that they have had problems updating gtk+ in the past. So far noone has expressed any actual problems updating glib and gtk+ to version 2.6.

To get some details into the game - a while ago (just after 2.2 was released), I tried upgrading to 2.6 (I thought that 2.6 was required, but this doesn't matter here). I ended up with a system where

- gdm crashed (I was unable to get any useful error message - logging seems to be broken with regard to this, strace did not help) - GIMP 2.2 crashed almost every time I opened the file selector with some strange pango message showing up (some assertion failed) - it seems that font handling has somehow changed (I did compile a new pango, but not a new freetype)
I found an obscure way to prevent this crash, but I cannot remember anymore - it was not really stable either. - OpenOffice stopped working with some unresolved symbol _XineramaIsActive

I straced a lot but got no real conclusion (apart from that the new file selector opens a lot of files which probably kills performance on networked file systems).

I can give it a try tomorrow and see whether I get some useful error messages. (My earlier message to this list describing my problems has somehow been ignored, there might be some details in there.)

Bye, Tino.

From: Sven Neumann
Date: Sun, 06 Feb 2005 14:48:03 +0100

Hi,

Carol Spears writes:

> i am curious to see what changes having gtk+-2.6 bring to poor gimp. > many of the problems with the 2.4 fileselector get shoved off because of > this great thing called gtk+-2.6. can we see a screen shot or even > several of the new things?

There are no changes in the GTK+-2.6 fileselector that would be visible on a screenshot. What has been improved is that a couple of keybindings have been added and some of the focus problems have been eliminated. These changes improve usability of the file chooser a lot and I think that it can now really be called an improvement over the old GtkFileSelection widget. But of course you will disagree with me.

I thought it was supposed to allow actually typing in a filename? The really bad point of the 2.4 file selector is that (at least as far as I can see) it only allows selecting a file, not typing the pathname (at least, I don't see any text entry box!)

From: Sven Neumann
Date: Sun, 06 Feb 2005 14:57:59 +0100

Robert L Krawitz writes:

> I thought it was supposed to allow actually typing in a filename? > The really bad point of the 2.4 file selector is that (at least as > far as I can see) it only allows selecting a file, not typing the > pathname (at least, I don't see any text entry box!)

The GTK+ 2.4 file-chooser already allows you to type in a filename after you press Ctrl-L. In GTK+-2.6 however you just start typing and navigate to the file using the typeahead feature of the treeview. You will only sometimes need to use the Ctrl-L popup.

That's terribly obvious :-( If the entry box isn't visible, how is anyone to know that you can actually do this?

From: Sven Neumann
Date: Sun, 06 Feb 2005 16:19:14 +0100

Robert L Krawitz writes:

> That's terribly obvious :-( If the entry box isn't visible, how is > anyone to know that you can actually do this?

You can do that in all treeviews (at least all treeviews that set a search column). This is something that the user has to be told once but since it's available all over the place, that shouldn't be much of a problem.

Every other file dialog I've ever seen has a visible entry for typing in a filename. It's not clear to me why there's any advantage at all to not having it visible. It just seems like a gratuitous incompatibility.

On Sun, 06 Feb 2005 17:22:00 +0100, Sven Neumann wrote:

That said, I would like to state that whatever happens in GTK+, is of course our responsibility as well. After all it's the GIMP toolkit. IMO we should work a lot closer with the GTK+ development team. If it was me, the GIMP development branch would depend on the latest CVS versions of glib and gtk+. That would allow us to follow the development a lot closer and would allow us to give feedback early enough for it to be considered. The way we are working now (a lot of developers still using the now unmaintained gtk+-2.4 branch), we are of course always way too late.

For a long time the policy was that we used the most recent devel branch release. When did that change? CVS HEAD is a little too fast-moving, but I don't have a problem with using the latest devel version, and I don't remember anyone else having a problem with it, either.

Rockwalrus

Nathan Summers wrote:

For a long time the policy was that we used the most recent devel branch release. When did that change? CVS HEAD is a little too fast-moving, but I don't have a problem with using the latest devel version, and I don't remember anyone else having a problem with it, either.

I'd hate to have to build my own GTK+ - it is absolutely non-straight-forward on Win32, rather forth-back-forth-back...

Michael

On Sun, 6 Feb 2005, Michael Schumacher wrote:

Nathan Summers wrote:

For a long time the policy was that we used the most recent devel branch release. When did that change? CVS HEAD is a little too fast-moving, but I don't have a problem with using the latest devel version, and I don't remember anyone else having a problem with it, either.

I'd hate to have to build my own GTK+ - it is absolutely non-straight-forward on Win32, rather forth-back-forth-back...

I don't find it much more complicated than building GIMP once the build environment is set up properly (though that can be a bit complicated). What might be needed are better instructions for doing that.

Here's a rather good step in that direction: http://mail.gnome.org/archives/gtk-devel-list/2005-January/msg00091.html

Robert

On Sun, Feb 06, 2005 at 02:48:03PM +0100, Sven Neumann wrote:

keybindings have been added and some of the focus problems have been eliminated. These changes improve usability of the file chooser a lot and I think that it can now really be called an improvement over the old GtkFileSelection widget. But of course you will disagree with me.

In some directories it takes the Save As dialog a verified 40 minutes to open. Tab completion is still missing. I still have to use my mouse for every operation in the layers dialog because no shortcuts work there, etc. etc.

For me, gimp-2.x is a big step backwards in usability, and I am not alone, and I still use 1.3 for editing sometimes, and I think it sucks compared to the power 2.x offers, but at least I can work pretty fast with it.

Many people have voiced their concerns, and I think it's a shame that they all get ignored.

On Sunday 06 February 2005 05:44, Sven Neumann wrote:

Hi,

snip

This looks as if you installed pango into a prefix that is not searched by the linker. You will have to either

modify /etc/ld.so.conf

to include that path, or set the LD_LIBRARY_PATH environment

variable.

Sven

Sven,

Thanks for getting back about this. I checked this and at first it appeared to be OK (ld.so.conf looked ok). So I did some more looking around on my system and it turned out that I had 2 versions of pango installed in 2 locations (1.6 in /usr/local/lib and 1.8 in /opt/gnome/lib). So I cleaned this up. I also checked everything else related to GTK and GIMP to make sure that I had no duplicates before moving on.

I then un-installed (just to make sure) and built GLIB, Pango, ATK and GTK. There were no apparent problems during the build process. But now when I try to run GIMP I get the following error message:

gimp: error while loading shared libraries: /opt/gnome/lib/libgtk-x11-2.0.so.0: undefined symbol:gdk_threads_lock

I get the same error message when I try to run Firefox and GKrellM. This is the same error message I was getting after I installed the GTK 2.4 RPMs. I tested GIMP after building each library and it was fine until GTK was installed. I can get these running again by backing out GTK to the version that shipped with my distro.

I did a search of the gtk-list, gtk-app-devel-list and gtk-devel-list and there was a thread on this error message on the gtk-list. But it was a dead end as there was no solution to the problem posted in the thread. Any ideas about what might be causing this?

On Mon, Feb 07, 2005 at 03:00:44AM +0100, Sven Neumann wrote:

Hi,

writes:

In some directories it takes the Save As dialog a verified 40 minutes to open.

You better file a bug report about this then or at least make sure that there's one filed about it.

No sweat, already done for some time :) I wouldn't dare to menton bugs here without :)

There have been a couple of changes that deal with exactly this problem so it would surprise me if the problem is still there. You better make sure that the relevant people know about it.

Well, for one thing it's a gtk+ problem (reading about every file in the directory, which, for large directories, takes ages), and there the bug is filed.

However, when I think about it, there is another problem in the gimp: The save-as dialog (by default) only gives me a path-entry, so it's questionable why all that information is being read (in a blocking way, too), when it's not being displayed. This is likely specific to the gimp.

Tab completion is still missing. I still have to use my mouse for every operation in the layers dialog because no shortcuts work there, etc. etc.

How is the layers dialog related to this?

It's related to general usability. I have a problem with clicking icons, mainly because I seem to have a mental disorder causing me not to be able to identify icons. Well, seriously, me and a lot of people I know are able to read text much faster than icons, and can enter keyboard shortcuts much faster then clicking icons or menu items.

In gimp-2.x, I seem to be unable to set shortcuts in the layers dialog (and the predefined shortcuts that didn't work in 2.0 were removed), so it seems gimp-2 forces me to use menus or clicking icons were I could use keyboard shortcuts before.

I don't think we have ever ignored any concerns and I know that the GTK+ developers do also care a lot about feedback as long as it doesn't boil down to "it sucks".

Hmm, after reading the various threads about the file-selector, I got a different impression, namely, "the file-selector is great, if you can't see this, you suck" (I am exaggerating a bit here, obviously) :) But many people complained about the good features, namely, being able to paste paths or enter paths using tab completion. This seems to get ignored, because there are undocumented and invisible keyboard shortcuts that provide workarounds...

Right now, people laugh at me when they see the "current" (this is gimp-2.2.2) layers dialog and file open/close dialogs.

Unfortunately there seems to be a trend to bitch on other people's work without even trying to propose better solutions.

Hmm, many people (including me, remember my shock when dynamic keyboard shortcuts were mostly gone, which was one of the killer features with gimp) just said sth. akin to "I want the old way back", which in my book counts as "proposing better" (to them) "solutions".

I think there is a general trend in making gimp "more user friendly" and less powerful to use (dialogs, shortcuts, icons), to make gimp uniform to other apps even when it makes little sense because gimp is, after all, different (undo/redo etc.).

(Another interesting but completely unrelated thing is that gnome offers a wide variety of extending your desktop/panel/menus with more icons, but not with text. It certainly looks more colourful, but most people quickly become confused because there is only so much info that you can convey with an icon, and nobody can remember the actions between 20+ different icons. gimp partly follows that, IMHO).

On Sunday 06 February 2005 05:44, Sven Neumann wrote:

This looks as if you installed pango into a prefix that is not searched by the linker. You will have to either

modify /etc/ld.so.conf

to include that path, or set the LD_LIBRARY_PATH environment

variable.

Sven

This helped and I was able to find the problem. I had 2 copies of Pango installed in different locations. I removed the incorrect one and then double checked everything related to GTK and GIMP to make sure there was only one copy and that these were installed in a way that was consistent with the SuSE RPMs. Which they were. I then restarted the GTK installation starting with GLIB just to make sure.

There were no apparent problems during the build process and I tested GIMP as each new library was installed. Everything worked until I installed GTK then GIMP, Firefox, GKrellM and other GTK dependant apps started failing with a libgtk-x11-2.0.so: undefined reference to 'gdk_threads_unlock' error. As soon as I backed out GTK to the version from the distro these apps started working again. By the way this is the same error message I got when I installed gtk 2.4 from the ULB SuSE RPMs.

I checked on the gtk-list archive to see if this error had been reported. There was one short thread about this error message (4 emails). But the fix information is not in the thread. Either because it was never fixed or the information was communicated off list.

So the state of my machine now is that I have glib 2.6.2, Pango 1.8 and ATK 1.9 installed but I still have gtk 2.2.4 installed. Everything is working but of course I can not install any version of GIMP newer than 2.0.x. Anyone have any clues about what I need to do to get gtk 2.6 installed?

On Mon, 7 Feb 2005, Hal V. Engel wrote:

So I did some more looking around on my system and it turned out that I had 2 versions of pango installed in 2 locations (1.6 in /usr/local/lib and 1.8 in /opt/gnome/lib). So I cleaned this up. I also checked everything else related to GTK and GIMP to make sure that I had no duplicates before moving on.

Did you also check that there were no files named for example libgdk-x11-2.0.so* in /usr/local/lib or anywhere else on the system except for /opt/gnome/lib?
(that file is a part of GTK+)

I then un-installed (just to make sure) and built GLIB, Pango, ATK and GTK. There were no apparent problems during the build process. But now when I try to run GIMP I get the following error message:

gimp: error while loading shared libraries: /opt/gnome/lib/libgtk-x11-2.0.so.0: undefined symbol:gdk_threads_lock

I get the same error message when I try to run Firefox and GKrellM. This is the same error message I was getting after I installed the GTK 2.4 RPMs. I tested GIMP after building each library and it was fine until GTK was installed. I can get these running again by backing out GTK to the version that shipped with my distro.

I did a search of the gtk-list, gtk-app-devel-list and gtk-devel-list and there was a thread on this error message on the gtk-list. But it was a dead end as there was no solution to the problem posted in the thread. Any ideas about what might be causing this?

To me that sounds like it's picking up a 2.2 version of libgdk which didn't have that symbol. You could try running:

ldd /path/to/gimp-2.0

to see which shared libraries it depends on. If it seems to pick up libgdk or libgtk from any other directory than /opt/gnome/lib (if that's where you installed GTK+), then you have a problem. You could also check the result of ldd /opt/gnome/lib/libgtk-x11-2.0.so.0

You can run

objdump -T /opt/gnome/lib/libgdk-x11-2.0.so.0 | grep lock

to make sure that the gdk_threads_lock symbol indeed exists in the libgdk you built. It should be listed in the output from grep.

Hope this helps Robert

On Tuesday 08 February 2005 13:15, Robert Ögren wrote: snip

Did you also check that there were no files named for example libgdk-x11-2.0.so* in /usr/local/lib  or anywhere else on the system except for /opt/gnome/lib?
(that file is a part of GTK+)

Yes I did exactly that. I did the same for glib, pango and atk. But I did not try the same for gdk since this is not listed as a dependency for GTK.

snip

To me that sounds like it's picking up a 2.2 version of libgdk which didn't have that symbol. You could try running:

ldd /path/to/gimp-2.0

to see which shared libraries it depends on. If it seems to pick up libgdk or libgtk from any other directory than /opt/gnome/lib (if

that's

where you installed GTK+), then you have a problem. You could also

check

the result of  ldd /opt/gnome/lib/libgtk-x11-2.0.so.0

You can run

objdump -T  /opt/gnome/lib/libgdk-x11-2.0.so.0 | grep lock

to make sure that the gdk_threads_lock symbol indeed exists in the libgdk you built. It should be listed in the output from grep.

Hope this helps Robert

I did find an old version of gdk installed in /usr/local/lib dated 2003 probably installed by who knows what RPM. This was much older than the gdk installed in /opt/gnome/lib so I removed the files from /usr/local/lib and ran ldcongif. And did a make install for gtk 2.6.2. The result is full of joy as GIMP and Firefox now run with out errors.

Thanks for all the help. I will now be able to follow the development of GIMP and can hopefully help guide the implementation of color management.

On Tue, 8 Feb 2005, Hal V. Engel wrote:

On Tuesday 08 February 2005 13:15, Robert Ögren wrote: snip

Did you also check that there were no files named for example libgdk-x11-2.0.so* in /usr/local/lib  or anywhere else on the system except for /opt/gnome/lib?
(that file is a part of GTK+)

Yes I did exactly that. I did the same for glib, pango and atk. But I did not try the same for gdk since this is not listed as a dependency for GTK.

Actually, it is not a dependency. GDK is a part of GTK+ that more or less abstracts the low-level interaction with the windowing system (X11, Win32 etc). So, installing GTK+ installs several library files, for example libgdk_pixbuf, libgdk and libgtk. In the same way, GLib consists of libglib, libgmodule, libgobject and libgthread; Pango has libraries like libpango, libpangoft2, libpangox, libpangoxft, libpangowin32 etc etc. And in addition some other stuff like configuration files and header files gets installed as well.

If you encounter any more problems you might want to take another look in /usr/local to see if there is more old stuff there. (But don't delete files randomly ;) )

The result is full of joy as GIMP and Firefox now run with out errors.

Thanks for all the help. I will now be able to follow the development of GIMP and can hopefully help guide the implementation of color management.

I'm glad to hear that!

Robert

On Mon, Feb 07, 2005 at 11:01:07PM +0100, Sven Neumann wrote:

How would that be specific to GIMP? The problem is that there is not only the combo-box. There's a full directory view below it. It's hidden in an expander but that doesn't change the fact that it is there.

"On my screen, there isn't". It doesn't matter to the user how something is implemented internally, and that it is hidden but there. by default, it's not there ("displayed"), and it's hard to imagine why a uI element that is hidden and not used in many cases should require the majority of cpu time.

This is however completely in the GTK+ realm. It could probably be improved but that would have to be done in GTK+.

I don't think it's completely in the GTK+ realm. But yes, the biggets problem is in the GTK+ realm.

In gimp-2.x, I seem to be unable to set shortcuts in the layers dialog (and the predefined shortcuts that didn't work in 2.0 were removed), so it seems gimp-2 forces me to use menus or clicking icons were I could use keyboard shortcuts before.

The entries are all available in the Image menu, so you can easily bind shortcuts to the entries that don't have one yet. In GIMP 2.2 these shortcuts work globally. Even if the Layers dialog, the toolbox

Yes, that's a usability drawback for me, too :(

limited to what appears in the menus. Perhaps you should explain that to the people laughing. Laugh about their ignorance.

I don't understand why they are ignorant - having to use undocumented functionality and keyboard shortcuts without visible representation anyhwere is a usability problem. It doesn't matter if you post information how to wrk around that on some mailnglist.

I really find it bad that you think those people are ignorant - not everybody can (or even will) read the source to find hidden keyboard shortcuts. That is simply "too much" to ask from anybody.

Marc Lehmann wrote:

"On my screen, there isn't". It doesn't matter to the user how something is implemented internally, and that it is hidden but there. by default, it's not there ("displayed"), and it's hard to imagine why a uI element that is hidden and not used in many cases should require the majority of cpu time.

Not that Sven needs me to defend him, but I didn't perceive that he was trying to justify the behavior, only to explain how it comes about. And the fact is that there is no way to change it except either by changing the Gtk+ code, or by not using the Gtk+ file chooser.

I really find it bad that you think those people are ignorant - not everybody can (or even will) read the source to find hidden keyboard shortcuts. That is simply "too much" to ask from anybody.

Your points are valid, but you have to realize that there is no such thing as a perfect ui solution in a program as complex as GIMP. If every interface element is always visible, the interface gets so complicated as to be unusable. But if elements are hidden, they are hard to use for that very reason. We can't win. So the right approach is not to be dogmatic, but to try to find the compromises that work best for the largest number of users.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Wed, Feb 09, 2005 at 09:56:07PM -0800, William Skaggs wrote:

I really find it bad that you think those people are ignorant - not everybody can (or even will) read the source to find hidden keyboard shortcuts. That is simply "too much" to ask from anybody.

Your points are valid, but you have to realize that there is no such thing as a perfect ui solution in a program as complex as GIMP. If every interface element is always visible, the interface gets so complicated as to be unusable. But if elements are hidden, they are hard to use for that very reason. We can't win.

Well, it should be clear that, except for small changes, the old file dialog worked better for the largest number of users. Also, the file save dialog in gimp-2.2 does have a path entry, so I don't think it's impossible to do it (that's just an example).

Some problems might be caused by misdesigns in gtk+, but not all.

approach is not to be dogmatic, but to try to find the compromises that work best for the largest number of users.

I don't think the largest number of users specifically need a stripped-down file dialog.

writes:

On Wed, Feb 09, 2005 at 09:56:07PM -0800, William Skaggs wrote:

I really find it bad that you think those people are ignorant - not everybody can (or even will) read the source to find hidden keyboard shortcuts. That is simply "too much" to ask from anybody.

Your points are valid, but you have to realize that there is no such thing as a perfect ui solution in a program as complex as GIMP. If every interface element is always visible, the interface gets so complicated as to be unusable. But if elements are hidden, they are hard to use for that very reason. We can't win.

Well, it should be clear that, except for small changes, the old file dialog worked better for the largest number of users. Also, the file save dialog in gimp-2.2 does have a path entry, so I don't think it's impossible to do it (that's just an example).

Some problems might be caused by misdesigns in gtk+, but not all.

Ah, So which problem you have with the file dialog is GIMP specific?

Why don't you stop complaining here and talk to the GTK+ mailing list? There is absolutely nothing we can do about that. And no, we will certainly not hack around to make the GIMP's file dialogs look different from all other GTK+ apps' file dialogs.

ciao, --mitch

On Fri, Feb 11, 2005 at 01:17:32AM +0100, Sven Neumann wrote:

Hi Marc,

writes:

I don't understand why they are ignorant - having to use undocumented functionality and keyboard shortcuts without visible representation anyhwere is a usability problem. It doesn't matter if you post information how to wrk around that on some mailnglist.

Sorry, but the Image->Layer menu is visible and it is fully documented also.

Sorry, I was talking about the file dialog, which certainly has undocumented and invisilble keybindings, such as ctrl-l.

We can certainly improve the set of default keybindings and try to add some useful ones in the Layer menu. There's also still the great menu reorganisation project looking for volunteers...

Yeah, that's fine. I just couldn't understand why usability first has to be reduced and then maybe later improved, but if it's according to some master plan it might work even for me, later.

On Thu, Feb 10, 2005 at 07:35:11PM +0100, Michael Natterer wrote:

writes:

Some problems might be caused by misdesigns in gtk+, but not all.

Ah, So which problem you have with the file dialog is GIMP specific?

It takes a long time to open, for no reason. That is gimp-specific, other apps using the file dialog behave differently, as I explained.

As I already wrote, the gtk+-specific bug has already been reported. I do think it's worthwhile if you read the beginning of this thread.

Why don't you stop complaining here and talk to the GTK+ mailing list?

I didn't know the gtk+ mailing list is responsible for gimp-specific behaviour. Other apps that use the gtk+ file dialog behave differently, as I explained.

There is absolutely nothing we can do about that.

That's fine with me then, really. Please note that i never asked you to do something for me. I did, however, describe usability problems with gimp.

If you want to ignore these, that is your option (most probably because they are totally out of your control, as neither sven nor you ever shied away from more work to improve the gimp), but please don't claim they aren't there.

And no, we will certainly not hack around to make the GIMP's file dialogs look different from all other GTK+ apps' file dialogs.

On my system (debian), gimp's file dialogs already look very different to other gtk+2 apps. No hack is required, and I didn't ask for one, either.

Now, why are you reacting so hostile? I just reported on some general deficiencies in gimp-2.x usability, of which the file dialog is the biggest one. If you (both sven and you) don't want to hear about that, just say so.

I do, however, think it's a bad sign that users (I read a few cases on this mailinglist before) who report their problems with usability get treated like that.

The very least you can do is acknowledge the problems people have, whatever causes it and wether and how it can and should be fixed is secondary.

writes:

On Thu, Feb 10, 2005 at 07:35:11PM +0100, Michael Natterer wrote:

writes:

Some problems might be caused by misdesigns in gtk+, but not all.

Ah, So which problem you have with the file dialog is GIMP specific?

It takes a long time to open, for no reason. That is gimp-specific, other apps using the file dialog behave differently, as I explained.

On my machine it takes about as long to open GIMP's file dialog as opening other GTK+/Gnome apps' file dialogs, for example gedit.

As I already wrote, the gtk+-specific bug has already been reported. I do think it's worthwhile if you read the beginning of this thread.

Why don't you stop complaining here and talk to the GTK+ mailing list?

I didn't know the gtk+ mailing list is responsible for gimp-specific behaviour. Other apps that use the gtk+ file dialog behave differently, as I explained.

It is not GIMP specific.

There is absolutely nothing we can do about that.

That's fine with me then, really. Please note that i never asked you to do something for me. I did, however, describe usability problems with gimp.

If you want to ignore these, that is your option (most probably because they are totally out of your control, as neither sven nor you ever shied away from more work to improve the gimp), but please don't claim they aren't there.

I don't ignore usability problems which (a) really exist and are (b) our fault. I don't even ignore usability problems which are *not* our fault. It took me some days to sort out usability and look an feel problems with the GTK+ team right before the new file chooser was initially released. They added/changed things because we figured them when porting GIMP to GtkFileChooser.

And no, we will certainly not hack around to make the GIMP's file dialogs look different from all other GTK+ apps' file dialogs.

On my system (debian), gimp's file dialogs already look very different to other gtk+2 apps. No hack is required, and I didn't ask for one, either.

We only add the preview and the proc selection which takes about zero seconds unless you are on a P300 or something.

Now, why are you reacting so hostile? I just reported on some general deficiencies in gimp-2.x usability, of which the file dialog is the biggest one. If you (both sven and you) don't want to hear about that, just say so.

It am not hostile. You are spreading FUD.

I do, however, think it's a bad sign that users (I read a few cases on this mailinglist before) who report their problems with usability get treated like that.

The very least you can do is acknowledge the problems people have, whatever causes it and wether and how it can and should be fixed is secondary.

We do acknowledge problems, but we can't do anything about this one (if there is one). I don't see how that "slowness" could be caused by GIMP. That's why I asked to complain against GTK+. There were usability problems which were addressed with GTK+ 2.6. You use GTK+ 2.6, do you?

ciao,
--mitch

On Fri, Feb 11, 2005 at 10:56:38AM +0100, Michael Natterer wrote:

It takes a long time to open, for no reason. That is gimp-specific, other apps using the file dialog behave differently, as I explained.

On my machine it takes about as long to open GIMP's file dialog as opening other GTK+/Gnome apps' file dialogs, for example gedit.

On mine, too. Really, you are putting words intgo my mouth that I didn't say. _Please_ stay out of this thread _or_ read my original mails where I clearly differentiated between gimp-specific issues and gtk+-specific ones.

I think the reaction of accusing people of spreading FUD is pretty dumb, but it seems to become the norm around here.

As you continuously ignore what I wrote I see no reason in prolonging this discussion with you further, it just isn't productive to iterate over facts when the other side ignores them.

I don't ignore usability problems which (a) really exist and are (b) our fault.

Indeed, you call people reporting them as spreading FUD. Way cool. Thanks god I am mostly out of here.

fault. It took me some days to sort out usability and look an feel problems with the GTK+ team right before the new file chooser was initially released. They added/changed things because we figured them when porting GIMP to GtkFileChooser.

And yes, I am sure you are a) doing good work and b) do that diligently. Still, your reaction to reported usability problems is extremely poor.

GIMP. That's why I asked to complain against GTK+.

Well, that's funny, because I already *wrote* that I have reported that problem.

This make sit pretty clear thta you didn't read the report, at leats not very carefully, so why do you think you should accuse me of spreading FUD? Do you even know what I am "spreading"? Probably not...

On Fri, Feb 11, 2005 at 02:32:03PM +0100, Marc A. Lehmann wrote:

Indeed, you call people reporting them as spreading FUD. Way cool. Thanks god I am mostly out of here.

thanks god you are somewhat back!

there is a lack of accountability lately, that same god knows that i am the wrong person to file bug reports and such -- however, bugs get closed for no good reason and talking to the developers in either camp (gtk or gimp) is like talking to that escher drawing of one hand drawing the other. not so pretty as that tho.

back when the developer mail was full of flame wars (mostly between germans, btw) the gimp was fast and did the job really well. now it looks and feels good but is broken for anyone trying to work with it logically. i think even jimmac broke down and got a movie of how long it takes to open a busy directory. rumors of nautilus changing selections and deleting things as well, during that long long opening a directory process.

bug reports just get closed. something is very wrong, and it shouldnt be.

carol

On Fri, 11 Feb 2005 14:32:03 +0100, Marc A. Lehmann wrote:

I think the reaction of accusing people of spreading FUD is pretty dumb, but it seems to become the norm around here.

Especially because as far as I can tell you weren't making vague misleading or dishonest statements about a competitor's product for your personal financial gain. But it is interesting to note that Mitch considers gimp-developer read by enough members of the general public to be usable for FUD purposes.

Rockwalrus

On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann wrote:

where I clearly differentiated between gimp-specific issues and gtk+-specific ones.

Marc, it is you who is constantly trying to change your words.

Ehem?

as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject.

Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp.

did this at least twice in this very thread. Please try to acknowledge when you have been wrong. Others are doing that here as well. You will

Sorry, but bullshitting and bullying around does not help. If at all it's Mitch who should apologize :(

If that is the new kind of tactics of you, namely calling others as spreading FUD, trying to intimadate them and bullying them around then you are very poor.

You should learn to argue based on sound arguments instead of relying on lies and distasteful bullying tactics.

also have to apologize to Mitch or stay not only out of this thread but out of this mailing-list.

What's that supposed to mean? I have to stay out of this mailing list because I won't apologize to Mitch that he made a mistake?

That is, of course, not what will happen. I am not responsible for you and mitch's personal problems, but it's bad that you take it out on others who are trying to be constructive :(

Marc Lehmann (pcg@goof.com) wrote:

On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann wrote:

as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject.

Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp.

Can all of you please take this off list? It is not at all on topic for this list.

Thanks,
Simon

On Sat, Feb 12, 2005 at 09:22:59PM +0100, Sven Neumann wrote:

Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp.

We had already figured out that the file-chooser issues don't belong

Well, it's nice that you figured that out, but I still haven't - yes, the speed problem is inside gtk+, but not the rest of the problems.

here and were discussing the keybindings in the layers dialog. I explained the Image->Layer menu to you and you claimed that it would be hidden.

I claimed and still claim that I cannot set shortcuts in the layers dialog, which was possible before, and posed a problem for other people in the past, too.

I would call this hidden, yes, and I still think it's a usability problem, because 1.2 clearly worked better.

I explained to you that it is clearly visible and documented.

Well, but it isn't :(

That would have been the moment for you to shut up.

I don't understand you. I described various problems. You claim they are simply not there. Why?

I am just trying to explain the problems to you, but your only reactions are ignorance, hostility and bullshit like this.

You *are* ignoring these problems, because you don't even *acknowledge* them. The worst problem is that you intimidate people who report such problems.

Why??

Instead you claimed that you were still talking about the file-chooser. You are taking your words out of the context they originally appeared in. That's not what I would call good style.

You are certainly not in the position to tell others about good style :(

Look at the thread again, you are obviously only interested in a flamewar.

If somebody agrees with your assessment of problems you start accusing them of spreading FUD, twisting words or starting flamewars. Please *do* re-read the thread, if there is a flamewar, then you started it by stopping to discuss the probem and instead resorting to needless insults.

I don't think you are interested in a flameware, neitehr am I. You seem to be interested in silencing problem reports, though, as if they didn't exist.

You've been accusing us of ignoring usability issues.

There are ample examples of that :)

That is ridiculous since we have been working on nothing but usability for the last two years.

Your logic is broken. Wether you worked on usability or not has no relevance to wether you are ignoring *these* usability problems or not.

Other people are obviously capable of proposing enhancements without pissing people off the way you do.

Your bullying tactics happen to work with other people, that's the difference. Obviously there are a lot of people who can piss you off, judging by your insulting reactions to others, too. And no, singling me out doesn't impress me, as I went through the archives and know better...

What does that buy you, I wonder, though.

On Sat, Feb 12, 2005 at 08:29:10PM +0100, Simon Budig wrote:

Marc Lehmann (pcg@goof.com) wrote:

On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann wrote:

as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject.

Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp.

Can all of you please take this off list? It is not at all on topic for this list.

I will now, completely, except for noting that svens postings resulted in precisely what he claimed it wouldn't: yet another thread with actual usability problems has been *killed* in the worst possible way.

On Sun, Feb 13, 2005 at 02:19:52AM +0100, Sven Neumann wrote:

people in the past, too.

I would call this hidden, yes, and I still think it's a usability problem, because 1.2 clearly worked better.

Marc, I shouldn't argue with you

Maybe, but I think sensible arguments are in the best interests of everybody.

but I have to disagree with you here.

I don't think you need to, I completely agree with you on this:

Behaviour of keybindings was dependant on the window that has the focus. I don't know if this has ever been a problem to you but have you ever seen a new GIMP user struggling with this? Keybindings are vital in an application like GIMP. If Ctrl-Z for Undo doesn't work in the Layers dialog because it's only bound to the image window, then you end up moving focus between windows only to make keybindings work. This is how GIMP 1.2 worked. For a newbie it takes a long time to

[it hasn't been a problem to me because I use focus-follows-mouse, but the current focus behaviour is not a problem to me either, so I agree that this change is a good one]

I do not agree with that, though:

The GIMP 1.2 behaviour was a major pain in the ass.

Parts of it were, others weren't. Dynamic keybindings worked much better.

Also, this does not mean that all the other changes were good, certainly the file chooser was step backwards (it has good features, but all in all it's a step backwards, I guess just temporarily until the gtk+ filechooser gets fixed, but still, right now, it is, and it's not clear how this will be fixed, or wether it will be fixed at all).

get used to this behaviour. Sorry, but 1.2 didn't clearly work better.

It did work better at least with respect to keybindings in the layers dialog. Right now, changing keybindings needs to be done in a very awkward way - first search what you want in another menu, with different menu ordering and contents, and then the keybinding isn't even reflected in the layers dialog menu.

Yes, I think 1.2 worked clearly better in the layers dialog, and what you say doesn't really invalidate the arguments in favour of that view.

With GIMP 2.2 you can finally concentrate on your work instead of tracking what window your keypress might go to and what action it will cause there.

I never had that problem with 1.2, but with 2.2, I have the problem of having to go to different places to change keybindings, and not having reminders where I need them.

To users like me, this is an absolute step backwards. I don't think it's right to penalize the workflow of some users to improve it for others, just because their style is differently, unless you absolutely must choose between options that cross each other out.

For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable.

I don't understand you. I described various problems. You claim they are simply not there. Why?

You may have not realized, but I didn't ignore your problems at all.

Well... so far... you... did... mostly... but that's ok if you forget them or I was unclear, as long as I have the chance of explaining it, which is difficult if you get insulted for trying... but... well... your choice.

There's a new thread I opened to discuss file-chooser performance and I

I thought the file-chooser performance was gtk+ related and off-topic here? At least that was my original impression :)

The real problems is unintituive behaviour, for example having to press a "hidden" key combination to get a text entry, or the fact that the file-chooser doesn't display the results of the (lengthy) file scan. If I have to wait for it, it should at least display the results, or do the file scan only when I want it displayed.

That *seem* to be gimp-specific problems, at least nobody claimed something different. If these are gtk+-dependent, too, then I'd be glad to know about it, but other apps, such as gedit, which use the filechooser have different behaviour, so I guess it *is* customizable and gimp-specific.

realized that we should have more pre-defined shortcuts in the Layers dialog. So I added shortcuts for New Layer and Duplicate Layer actions last night.

Cool! That is something that I would have liked to have, too, but it's not as important to _me_, as I can define my own shortcuts. However, defining them has become awkward in 2.2, and this is still an open issue, I think. Having more predefined bindings is nice, but not a solution.

Also, please see that my problem was not that you ignored problems per-se, but that instead of arguing logically (even socially) over problems you start insulting people, which usually results in the thread ending prematurely, which IMHO really lokks like ignoring, worse, like "we don't *want* to hear about that".

This is not the first time some of these issues have been reported, and IMHO it shouldn't take a flamewar to make people realize it.

On Sun, 13 Feb 2005 20:53:17 +0100, Marc A. Lehmann wrote:

For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable.

Out of curiosity, why do you find the 2.x dynamic keybindings not as useful?

Rockwalrus

On Mon, 14 Feb 2005 03:06:33 +0100, Sven Neumann wrote:

The discussion about the design of the file-chooser widget is off-topic since we are not in the position to change it.

Waaait, we're you advocating a few days ago that we follow the burning GTK edge because, after all, it's the Gimp ToolKit and so we can ensure that GTK continues to support the GIMP's needs?

Rockwalrus

An 'adjust related keybindings' menu item for relevant docks would help a lot to ease keyboard-configuration. This would open the prefs->configure keyboard shortcuts dialog, scrolled to the relevant area.

the difficulty of dynamic-keyboard-shortcutting, you can avoid by creating a shortcut scheme in advance.
In mine,
I have P mapped to pencil, shift+P to paintbrush, ctrl+P to clone, ctrl+shift+P to airbrush, ctrl+alt+P to ink, alt+shift+p to dodge/burn. I followed this scheme through all the keybindings. commonest used -> quickest to access, least used == slowest to access. (another example: C == Copy. SHIFT+C == Cut, CTRL+C == Copy Visible, CTRL+ALT+C == Copy Named, CTRL+ALT+SHIFT+C == Cut Named. and all the clear/fill with.. actions are mapped to F plus modifiers. Undo/redo is mapped to ; because i have a dvorak keyboard.) .

On Tue, Feb 15, 2005 at 02:59:55PM -0500, Nathan Summers wrote:

On Sun, 13 Feb 2005 20:53:17 +0100, Marc A. Lehmann wrote:

For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable.

Out of curiosity, why do you find the 2.x dynamic keybindings not as useful?

Mostly because they need to be set in a different place (e.g. image menu) then where they are used (e.g. layers dialog) and the shortcuts are not being shown (Which is bad because I often change them depending on my needs). That is what I meant by "penalizing".

A minor point is that I need to organize my already-crowded keybindings better because they are global, whereas before I ctrl-d could mean duplicate image or layer, depending on the context (I am used to focus-follows-mouse so this didn't bug me the least, but apperently it did bug many others, so the change improve dusability for the masses or so :). I call this "minor" because it's just that: a minor nuisance, and I guess very difficult to make switchable via a preferences item.

And of course very minor is that I need to enable it, but that's sth. I don't need to do very often :->

On Tue, Feb 15, 2005 at 03:07:43PM -0500, David Gowers wrote:

the difficulty of dynamic-keyboard-shortcutting, you can avoid by creating a shortcut scheme in advance.

That certainly works for you, but it also takes the "dynamic" out of "dynamic keyboard shortcuts", and some users (probably an absolute minority, I have no counts) grew very fond of the dynamic aspect and used it heavily.

Having to enter some shortcut editor would destroy this style of working (and isn't necessary right now, of course :)