Re: [Gimp-user] Compile problems and GTK
Hi, misfit-x [EMAIL PROTECTED] writes: If that didn't work, then there's a config somewhere that's still saying there's a GTK+-2.2.1 somewhere. I have another idea... REinstall GTK+2.2.1, then uninstall it. Then reinstall (just make install in the source tree you compiled GTK+-2.2.4 in, if you still have the sources compiled (ie. didn't delete the dirs or run make clean yet)). And see if that helps. It isn't even necessary to remove the 2.2.1 version. The problem here is the wrong usage of /etc/ld.so.conf as you outlined below: understand what my _/etc/ld.so.conf_ should look like. Mine has the following... /opt/lib/gtk+-2.2.4/lib/pkgconfig Just like misfit-x pointed out already, this is of course completely wrong. /etc/ld.so.conf has nothing to do with pkg-config. I would strongly suggest to take a short look at the man-pages before doing such changes. It certainly helps to know what files you are editing. I would think it should be in /opt/lib/gtk+-2.2.4/lib instead? This is a very unusual install prefix that was choosen for gtk+ here. But if it's indeed /opt/lib/gtk+-2.2.4, then the value you suggested is absolutely correct. Sven ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Compile problems and GTK
misfit-x/ Thanks for pursuing this with me. # rpm -qa | grep gtk+ The results: [EMAIL PROTECTED] gimp-1.3.23]# rpm -qa | grep gtk+ gtk+-devel-1.2.10-25 gtk+-1.2.10-25 But when I changed it from _gtk+_ to _rpm -qa | grep gtk2_ I got the following : [EMAIL PROTECTED] gimp-1.3.23]# rpm -qa | grep gtk2 pygtk2-devel-1.99.14-4 pygtk2-1.99.14-4 gtk2-2.2.1-4 gtk2-devel-2.2.1-4 pygtk2-libglade-1.99.14-4 gtk2-engines-2.2.0-2 Notice how _GTK+ 2.2.4_ becomes _gtk2-2.2.1-4_. Could this be where my system is getting gtk 2.2.1?? /brad If that didn't work, then there's a config somewhere that's still saying there's a GTK+-2.2.1 somewhere. I have another idea... REinstall GTK+2.2.1, then uninstall it. Then reinstall (just make install in the source tree you compiled GTK+-2.2.4 in, if you still have the sources compiled (ie. didn't delete the dirs or run make clean yet)). And see if that helps. Before I throw in the towel and go back to Photoshop, I just want to understand what my _/etc/ld.so.conf_ should look like. Mine has the following... /opt/lib/gtk+-2.2.4/lib/pkgconfig I would think it should be in /opt/lib/gtk+-2.2.4/lib instead? /usr/X11R6/lib /usr/kerberos/lib /usr/lib/qt-3.1/lib /usr/lib/sane Rest of this looks good to me. If you really really want to run PhotoShop, you can in linux using WINE (www.winehq.org). Runs slower but works - at least PS LE 5 worked for me. However, I would rather use Gimp, personally. You can still use Gimp 1.2.x but the new 2.0pre1 is really nice. :) ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Alternative zoom algorithm
[EMAIL PROTECTED] (2004-01-17 at 0309.30 +0100): Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific missing zoom levels in the table above would completely break the advantages of nearly homogenous zooming...) After being pointed in IRC to check what other apps do, a search that resulted in similar things to what I was trying, going thru discarding what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting. GSR ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Re: Alternative zoom algorithm
On Sat, Jan 17, 2004 at 01:26:09PM +0100, GSR - FR [EMAIL PROTECTED] wrote: what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. Get used to it, that's how gimp-developer works :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Compile problems and GTK
Sven/ Just like misfit-x pointed out already, this is of course completely wrong. /etc/ld.so.conf has nothing to do with pkg-config. I would strongly suggest to take a short look at the man-pages before doing such changes. It certainly helps to know what files you are editing. Point well taken. In my desperation to get this thing installed, I got misfit-x's indications mixed up. I guess I will take a look at the man-pages, but I still can't figure out why I can't straighten this thing out, especially since I already have an older GIMP that works on my system. /brad. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: Alternative zoom algorithm
Hi, GSR - FR [EMAIL PROTECTED] writes: So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting. Homogenous scaling is predictable while your approach is just a set of preset aspect ratios that appear to be more or less arbitrary. So far you failed to explain the advantages of your approach. This makes it hard to judge which one would be better. Sven ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: Alternative zoom algorithm
GSR - FR ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (2004-01-17 at 0309.30 +0100): Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific missing zoom levels in the table above would completely break the advantages of nearly homogenous zooming...) After being pointed in IRC to check what other apps do, a search that resulted in similar things to what I was trying, going thru discarding what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. I'd like to explain why I consider your patch as evil. a) It has a table of presets that is constructed in an ad hoc manner without any explantation what the advantages to the user are. b) according to yourself the behaviour of your patch changes depending on the existance of a certain printf. c) Again in your own words apparently one version of your patch fails in certain zoom steps (this is taken from http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c.diff which right now reads: - Rearranged a bit, excuse any inconvenience: Working version, at least with -O0: http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c-cleaned.diff Version with 3:4 and 3:2 zoom, but fails in 50 - 100 and 100 - 200: http://www.infernal-iceberg.com/gimp/gimpdisplayshell-scale.c-dirty.diff - Sorry, I believe that a patch that depends on the compilers optimization level has indeed a real problem - for me this is evil. On a more social level you failed to explain what problem you wanted to solve with this patch in IRC. I thought hard about my proposal and I indeed think that I can justify why I am choosing this set of presets, although I still would prefer the fully homogenous version, but I can see that people have issues with weird zoom percentages. So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting. The whole point is user experience. Homogenous Zooming - for a lack of a better word - would behave exactly the same in every zoom level, regardless if this is from 274% or from 300%. When zooming in always the same rectangular area would be magnified to the image window. The user would be able to estimate, how often he has to zoom in to get *this* detail at *that* size. Compare this to the old behaviour some releases ago, described in bug #124073: from 1:3 it jumps pretty quickly in the details of the image, but from 67:189 the difference for zooming in/out is barely noticeable. I adressed this by implementing a zoom function based on a mix between homogenous zooming and continued fractions (sorry for the word pretty close to continuous, but thats the name of the mathematical concept), which has been considered to work pretty well by some people. Then you started to rework that thing *again* and failed to provide any argument [1], why 1:1, 1:2, 1:3, 1:4... etc. is better than my approach I did neither see the beauty of your concept nor the beauty of your patch, so my words on IRC probably were a bit harsh and I'd like to apologize for that. With your patch the user would have to zoom in 8 times to go from 1:32 to 1:64, (magnifying a quarter of the visible area), but would have to zoom in 2 times to go from 1:2 to 1:4 (also magnifying a quarter of the visible area). With my proposal the user always would have to zoom in two times to magnify a quarter of the visible area [2]. In my earlier mail I presented a possible compromise between homogenous zooming (I hope I made the advantages of that approach clear) and 1:x based zooming. I think it keeps best of both worlds and would like to ask, that alternative proposals have a careful discussion of advantages vs. backdraws against this. Thanks, Simon PS: Not that it'd matter much, but this is the list of zoom steps photoshop uses (percentages): 1600, 1200, 800, 700, 600, 500, 400, 300, 200, 100, 66.7, 50,, 33.3, 25, 16.7, 12.5, 8.33, 6.25, 5, 4, 3, 2, 1.5, 1, 0.7, 0.5, 0.4, 0.3, 0.2, 0.1, 0.05, 0.025, 0.02 For the reasons mentioned above I don't think it is a very good set of steps... [1] There was the argument, that a zoom step of 3:4 would look better than e.g. 5:7, but I cannot confirm that. Both ratios make jiggly lines from straight lines at 1:1, because of the non-interpolation of the display zooming. [2] Please note, that this is because of the use of sqrt(2)=2^(1/2) as the factor between the zoom steps, if that is considered too coarse I could work out a table based on 2^(1/3), which would produce three zoom steps to magnify a quarter of the visible area. -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-user mailing
[Gimp-user] Norwegian language support in the GIMP
I have been trying to call the GIMP with a Norwegian user interface, but without success. I don't know if the GIMP uses locales, but in the not-so-distant past, the locales for Norwegian language changed. The new locales for Norwegian are nb_NO Norwegian bokmal nn_NO Norwegian nynorsk Norway has two official languages. With some programs, I have to call the old locales if I want a Norwegian user interface, e.g. LANG=no_NO scribus even though my LANG is normally set to LANG=nb_NO. But with the GIMP, even this does not work. Any idea what I can do to get this working? Thanks, Conrad ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Alternative zoom algorithm
hi, On Fri, Jan 16, 2004 at 09:49:31PM +0100, GSR / FR wrote: Hi: I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 4 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying. i read a lot of the mail in the threads that followed. I tried to figure out the best way to handle this zoom problem. i think that any functionality should be allowed and encouraged until the info dialog is fixed. maybe the zoom and the info can work together rather than separately. if the user can distinguish the difference between the use of the image then TheGIMP could easier determine the set of rations to use. for instance, in the info dialog the user could choose production and it would first, only accept xcf format for save and second, allow extreme zooms. if the user toggled screen the ratios and save sizes could be limited to screen displays. Different print expectations could be expressed and many of the decisions for the new user could be preset and the GIMP could not just guess what would be best for everything. seems like this is only one use that a better info dialog could help with. determining format and image mode would be easier. i have enough experience with the different image handling, i could help to make the decisions about what the zoom ratio should be if i know you are making a web image and the resolution and image mode that would be best (if you cannot figure it out yourself). lets work on the info dialog. how can we make this thing work properly? carol ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Norwegian language support in the GIMP
On Sat, 2004-01-17 at 18:37, Conrad Newton wrote: [snip] The new locales for Norwegian are nb_NO Norwegian bokmal nn_NO Norwegian nynorsk Norway has two official languages. 'LANG=nb_NO gimp-1.3' works here, but 'LANG=nn_NO gimp-1.3' doesn't. With some programs, I have to call the old locales if I want a Norwegian user interface, e.g. LANG=no_NO scribus This also works with gimp-1.3 here. You could try asking the gnome translation project - more information about them can be found on http://developer.gnome.org/projects/gtp/contact.html Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Re: Alternative zoom algorithm
Marc Lehmann ([EMAIL PROTECTED]) wrote: [...] discussion on #gimp and #gimp is IRC and not gimp-developer The discussion took partly place here also, so please take your dogs back and complain elsewhere about appropriateness. you haven't been around on #gimp when this conversation took place, Well, the discussion here was quite similar (although on #irc it seems to have been worse, which is not surprising to me, many people on #gimp are rather bigheaded and aggressive, much more so than on gimp-developer). If you want to argue about personal matters please do it off the list. The discussion started in bug #124073 and continued on IRC and now gets moved to these lists. GSR wants to replace something I implemented and have put some thought in it. It should be me who is pissed because of this, however, instead of just defending my implementation I chose to offer a compromise on this list. GSR did not yet convince me, that his implementation has any advantages over the current implementation in CVS and I will continue to ask for clarifications until I am convinced that replacing the implementation in CVS is a good thing. Mainly his arguments seem to be: 100% is more important than extreme ratios (please note that my implentation does not have *any* bias towards a certain zoom ratio, and I believe that this is a good thing. And if we need finer grained step it is a two line patch to replace sqrt(2) with something else) and that for some reason certain percentage/ratio numbers are more important than others, which I also doubt. There is no need for 1:7, when 1:6 visually basically looks the same. The fact that certain ratios look bad with the current non interpolating code for the image view cannot be solved by restricting the ratios available. This has to be done in the view code. And btw. I doubt that 1:3 looks significantly better than 10:29. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
