Re: [Gimp-user] GTK make problem
On 08/06/2009 07:55 AM, julien wrote: Hi, glib and gtk-related .pc files are in /usr/lib/pkgconfig. In /usr/local/lib/pkgconfig I have babl.pc, gegl.pc, gio-2.0.pc, gio-unix-2.0.pc, glib-2.0.pc but no gtk.pc, probably because it is not installed yet? I ran PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig export PKG_CONFIG_PATH and still I have this damned eroor on 'make': PKG_CONFIG_PATH is a configure time environment variable. make does not care about PKG_CONFIG_PATH. You need to reconfigure with PKG_CONFIG_PATH and probabl LD_LIBRARY_PATH set (but again, note that LD_LIBRARY_PATH is not needed when later running the built software due to libtool's use of rpaths. / Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] GTK make problem
Martin Nordholts wrote: On 08/06/2009 07:55 AM, julien wrote: Hi, glib and gtk-related .pc files are in /usr/lib/pkgconfig. In /usr/local/lib/pkgconfig I have babl.pc, gegl.pc, gio-2.0.pc, gio-unix-2.0.pc, glib-2.0.pc but no gtk.pc, probably because it is not installed yet? I ran PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig export PKG_CONFIG_PATH and still I have this damned eroor on 'make': PKG_CONFIG_PATH is a configure time environment variable. make does not care about PKG_CONFIG_PATH. You need to reconfigure with PKG_CONFIG_PATH and probabl LD_LIBRARY_PATH set (but again, note that LD_LIBRARY_PATH is not needed when later running the built software due to libtool's use of rpaths. / Martin As Martin says PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig export PKG_CONFIG_PATH ./configure Then 'make'. If 'make' still complains it may mean you've got the 'stripped' version of one or more packages and have to download the development versions (they usually have -devel in their names) which have header files needed for compilation. A similar problem came up about a month ago on the mailing list - it might also be worth your while having a look in the Gimp-user archives (July 2009; subject babl; author John Culleton, Doug, etc) Doug ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] GIMP in MS Windows: Very weird Z-order problem
(The following has only been observed with GIMP 2.6 in MS Windows. I don't know if it's true for Linux too; I just haven't had time to upgrade Linux GIMP from 2.4 yet.) I don't recall this happening with GIMP 2.4. The problem, with the exceptions afterward: Except as noted later, a GIMP window which is wholly or partially obscured by other windows (GIMP or non-GIMP, makes no difference) is made active (e.g., ALT-TABbbing to it, clicking its title bar, clicking the GIMP button on the taskbar, newly created by GIMP itself or opened from the context menu of Windows Explorer or an application that has the ability), it becomes active properly, however the windows in front of it stay in front of it. Clicking on the title bar or taskbar repeatedly does not bring it forward. [In the cases of new or newly opened images, they should be in the foreground automatically anyway. That should be addressed; however, this problem is not about that. When clicking on the taskbar button, Windows draws a moving title bar for the window to be activated moving from the taskbar button to the location of the window. That can be seen normally, but then, the window is still hidden.] However, switching to a different window AFTER the window in question has been activated and then switching back does bring it forward. Once a given window has been unstuck in this fashion, it stays so; it always comes forward when activated thereafter, as far as I've been able to observe so far. When GIMP creates a new window (e.g., using the colors-decompose function) the new window is usually behind the window of the image that created it, but I have seen some exceptions. (That's another case where that window should be forward automatically.) I have not yet been able to test if this is also true in the case of typing TAB to bring the GIMP toolbox and floating dialogs forward; so far, every time any GIMP window is active, those things are always in the foreground (which is good. :-) ) There are some bizarre special cases. One is this, and it's not entirely consistent; I haven't yet figured out the exact behavior yet. If I've just opened a new or existing image which is now behind something, then click on a different application on the taskbar, then again to toggle that button back again and then click the GIMP taskbar button, it stays hidden, even when repeated. However, clicking on that other application's taskbar button and then back to the GIMP button without toggling the other application's taskbar button can bring the GIMP window forward, but only after doing it more than once. Anybody know anything about this? Ray Simard ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP in MS Windows: Very weird Z-order problem
Ray Simard wrote: (The following has only been observed with GIMP 2.6 in MS Windows. I don't know if it's true for Linux too; I just haven't had time to upgrade Linux GIMP from 2.4 yet.) I don't recall this happening with GIMP 2.4. The problem, with the exceptions afterward: Except as noted later, a GIMP window which is wholly or partially obscured by other windows (GIMP or non-GIMP, makes no difference) is made active (e.g., ALT-TABbbing to it, clicking its title bar, clicking the GIMP button on the taskbar, newly created by GIMP itself or opened from the context menu of Windows Explorer or an application that has the ability), it becomes active properly, however the windows in front of it stay in front of it. Clicking on the title bar or taskbar repeatedly does not bring it forward. ...snippage... Anybody know anything about this? Known issue. Solution is to open the preferences menu and select the windows management menu item (Edit Preferences Window Management) and change the items under Window Manager hints so that both read normal window. ns ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
