Re: [Gimp-developer] gimp-remote
On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann wrote: > Hi, > > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > >> Would you mind to explain what sort of problems that would be? If we > > > > mozilla ./file > > > > => file not acesssible (permission denied, other user, inaccessible dir) > > => file not accessible (different machine) > > => file not acesssible (different filesystem view) > > > > Assuming that a process has exactly the same view of the filesystem > > as any other is in general not true. Comparing hostnames helps > > somewhat in the first case. > > I see the point. But it would be trivial to take care of this, > wouldn't it? The remote protocol would have to check if the instance > of gimp that is already running on the current X server is a local > process or not. Did I miss something obvious? I think the behavior should be as follows: By default, gimp should try to connect to a running instance, but *only* if it's on the same machine and running as the same user. gimp --remote (or if argv[0] == gimp-remote) should always attempt to connect to a running instance, and honor the args that the current gimp-remote has. And gimp --new-instance always starts a new instance. The default in absence of a command line argument should be controlled by an environment variable, for people with uncommon setups (like, differing filesystem views). That should make everyone happy. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> 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. 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. > 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? > 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. Could you elaborate what exactly you are talking about? Where are the usability problems you are seeing in comparison to gimp 1.3? > Many people have voiced their concerns, and I think it's a shame > that they all get ignored. 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". Unfortunately there seems to be a trend to bitch on other people's work without even trying to propose better solutions. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
Hi, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: >> Would you mind to explain what sort of problems that would be? If we > > mozilla ./file > > => file not acesssible (permission denied, other user, inaccessible dir) > => file not accessible (different machine) > => file not acesssible (different filesystem view) > > Assuming that a process has exactly the same view of the filesystem > as any other is in general not true. Comparing hostnames helps > somewhat in the first case. I see the point. But it would be trivial to take care of this, wouldn't it? The remote protocol would have to check if the instance of gimp that is already running on the current X server is a local process or not. Did I miss something obvious? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sun, Feb 06, 2005 at 02:48:03PM +0100, Sven Neumann <[EMAIL PROTECTED]> 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. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
On Mon, Feb 07, 2005 at 12:16:33AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > new, local instance should start to open that file, since the remote > > one can't load that file. But if the remote protocol just looks for a > > gimp window, it will try to use the existing gimp instance to open the > > file. Unsuccessfully. > > Yes, I understood that. And I said that we already have exactly this > problem with the current implementation, so it can probably not become > worse. > > Daniel mentioned problems that could be caused by moving the > gimp-remote functionality to the gimp binary. I asked him to explain > what kind of problems that would be. I don't know why you answered to > this question since it appears that your answer was unrelated. I am sorry to get off-topic, but in your recent posts (weeks) you became very very unfriendly towards other people who want to be helpful. I find his answer very related, as he explained a problem that your proposed change would result in, which is basically what you asked. Now, if you don't want to hear about problems, why are you asking in the first place? -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
On Sun, Feb 06, 2005 at 08:41:30PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Of course you can't load a local file into a gimp instance running on This is, of course, possible, but not with the current gimp-remote, and it's probably not that desirable t make it run. > a different machine but on the same X server. That's not any different > to the current situation though. It's very different, the current situation "just works" when invoking gimp. With your proposed change it simply doesn't work. That *is* a big difference in my book. > And it would probably be possible to design the remote protocol in a way > that avoids this problem. So we can only improve things. I don't thin it is in general. It's possible t ake it work in, say, most circumstances, but I don't think the current behaviouor is so annoying as to make failures acceptable. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Sun, Feb 06, 2005 at 02:51:05PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Would you mind to explain what sort of problems that would be? If we mozilla ./file => file not acesssible (permission denied, other user, inaccessible dir) => file not accessible (different machine) => file not acesssible (different filesystem view) Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case. There was a debian bug about this against mozilla, but as it is solved, it's archived and I couldn't find it anymore. So at least some people found that annoying enough to have it fixes. (I found it pretty annoying, but didn't file it as a bug report because I thought I would be alone in that opinion :) Such automatic behaviour presumes single-user (everything is readable to the gimp user) and single-machine (no remote display) configurations, whcih are pretty common nowadays, but universities and other big instalations still often have highly networked environments where this behaviour is annoyung, especially, if, as in the case of mozilla, you couldn't switch it off. > need special command-line switches, we can as well stick to the > current solution. As far as I know, the remote feature of mozilla If the only reason to fold it into the main binary is indeed to get this automatic (but annoying) behaviour, then indeed I see no reason to stick to it. Rifght now, gimp-remote and gimp do semantically very different things. Folding them into the same binary (without different switches) makes behaviour of gimp rather underterministic, especially for scripts etc., and personally I don't think it's worth it. The best thing would be to have gimp-remote automatically start a background instance of the gimp (as it already does). That way one gets these semantics: gimp - start a new editing session, return when closed gimp-remote - make sure a session is already running, return immediately And only the second alternative might run the risk of the file not being accessible. However, the recent trends in GUIs under unix *is* towards single-user-single-machine configs (witness the problems gnome/kde/debian pose in these environments), so you might just ignore these reasons, assuming that such configs will die out. > works by looking for a mozilla window in the current X session. I > don't see what problem that could cause on a multi-user machine. It's pretty annoying if you have to kill mozilla if you want to look at a file in networked or multi-user environments. With gimp, you have the choice. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Nathan Summers <[EMAIL PROTECTED]> writes: > 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. Even though it would be tempting to use some of the features that are currently being added to GTK+ HEAD, it would probably be a bad idea to target GTK+-2.8 for GIMP 2.4. GTK+ HEAD just introduced a dependency on Cairo. Of course it would be nice to finally convert our display drawing routines to a proper vector drawing library, but I think we should better put this on the GIMP 2.6 milestone. Let's rather try to get GIMP 2.4 out as soon as possible and have it depend on GTK+ 2.6. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
Hi, Roel Schroeven <[EMAIL PROTECTED]> writes: > What I mean is this: suppose you have a remote instance of the Gimp > running, and then you want to open a local file in the Gimp. I think a > new, local instance should start to open that file, since the remote > one can't load that file. But if the remote protocol just looks for a > gimp window, it will try to use the existing gimp instance to open the > file. Unsuccessfully. Yes, I understood that. And I said that we already have exactly this problem with the current implementation, so it can probably not become worse. Daniel mentioned problems that could be caused by moving the gimp-remote functionality to the gimp binary. I asked him to explain what kind of problems that would be. I don't know why you answered to this question since it appears that your answer was unrelated. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-remote
Sven Neumann wrote: Hi, Roel Schroeven <[EMAIL PROTECTED]> writes: Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine. I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session. Of course you can't load a local file into a gimp instance running on a different machine but on the same X server. That's not any different to the current situation though. And it would probably be possible to design the remote protocol in a way that avoids this problem. So we can only improve things. I think we're not talking about the exact same thing. What I mean is this: suppose you have a remote instance of the Gimp running, and then you want to open a local file in the Gimp. I think a new, local instance should start to open that file, since the remote one can't load that file. But if the remote protocol just looks for a gimp window, it will try to use the existing gimp instance to open the file. Unsuccessfully. -- "Codito ergo sum" Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] color management
Hi, just wanted to let everyone interested know that I started to add code for color management to GIMP CVS. For now, all we have is a configuration object that is supposed to be visible by the core, modules and plug-ins. This is based on a patch that Stefan DÃhla mailed me last year. The next steps I plan to do are: - add a color management page to the preferences dialog - establish a framework for passing the color management settings to modules and plug-ins - give color display modules access to image parasites, or at least to the "icc-profile" parasite - replacement of the proof display filter by a slightly more complex color display module that deals with monitor profile and printer profile based on the user's color management settings - move the display color management module out of the display filter configuration dialog and add it automatically to all image displays - use the cms module from all color areas and color selectors - add a plug-in to apply color profiles - deal with embedded color profiles on image load - ... So if you want to participate in this development or just check that the right things are being done here, you should consider to follow CVS. I also do not insist on doing all coding myself. There are a couple of tasks that could very well be "outsourced". Let me know if you want to help. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
Hi, Roel Schroeven <[EMAIL PROTECTED]> writes: >> Would you mind to explain what sort of problems that would be? If we >> need special command-line switches, we can as well stick to the >> current solution. As far as I know, the remote feature of mozilla >> works by looking for a mozilla window in the current X session. I >> don't see what problem that could cause on a multi-user machine. > > I don't know about problems on multi-user machines, but I've had > problems when I tried to display Mozilla instances running on > different machines in the same X session. Of course you can't load a local file into a gimp instance running on a different machine but on the same X server. That's not any different to the current situation though. And it would probably be possible to design the remote protocol in a way that avoids this problem. So we can only improve things. What hasn't been discussed at all yet, is how to implement the remote protocol. On X11 we should probably use selections (basically what we are doing now, perhaps done somewhat less hackish). What should be used on Win32? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-remote
Sven Neumann wrote: Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine. I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session. IIRC there was even a problem running an MS Windows native Mozilla together with a Unix-mozilla via Cygwin's X server. -- "Codito ergo sum" Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Nathan Summers <[EMAIL PROTECTED]> writes: > 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. Well, I do remember that we had lots of complaints last time we updated the dependencies. Otherwise we would have gone for GTK+-2.6 at the moment we branched after the 2.2 release. Dave Neary has been one of the most active advocates for being conservative with our dependencies. Perhaps he can outline the reasons better. For quite a while the policy is not to depend on libraries that are not yet in debian testing. That's of course just a rule of thumb but it guarantees that we work with stable software and that a reasonable amount of time has passed by since the libraries were released. It does however also mean that problems show up rather late. Often too late to get them fixed w/o waiting for the next GTK+ development cycle. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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 -- The GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > An alternative to implementing our own vfs would be to entirely > hide file handling from file plug-ins, for example by passing them > already opened GIOChannels which they would use to read/write. > It woud be easily possible to make the IO channels use some vfs > layer and the plug-ins wouldn't even notice. > > While this would make "straightforward" file plug-ins (which just > open, read sequentially, close) much easier to implement, it is > problematic for plug-ins which want to seek around in the files > a lot (like jpeg.c). GIOChannel has a seeking API, but we cannot > guarantee that for all vfs backends we may want to use. This seems like a sensible abstraction. There are two ways to handle the seeking problem: 1) Just make sure that all plug-ins that need to seek handle the can't seek error message correctly. This solution sucks. 2) Implement some mechanism whereby the plug-in signals ahead of time that it needs to be able to seek around. On non-seekable streams, the backend transparently uses temporary files (which of course can be seeked.) Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Hi, Michael Natterer <[EMAIL PROTECTED]> writes: > An alternative to implementing our own vfs would be to entirely > hide file handling from file plug-ins, for example by passing them > already opened GIOChannels which they would use to read/write. > It woud be easily possible to make the IO channels use some vfs > layer and the plug-ins wouldn't even notice. > > While this would make "straightforward" file plug-ins (which just > open, read sequentially, close) much easier to implement, it is > problematic for plug-ins which want to seek around in the files > a lot (like jpeg.c). GIOChannel has a seeking API, but we cannot > guarantee that for all vfs backends we may want to use. Unfortunately some image file libraries work directly on a file descriptor. Only if the library provides a stream API, can the plug-in easily be ported to use GIOChannels. We would have to evaluate if this is the case for libjpeg, libpng, libtiff and the other major image file libraries we are using. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sun, 06 Feb 2005 17:22:00 +0100, Sven Neumann <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Robert L Krawitz <[EMAIL PROTECTED]> writes: > 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. Well, this is the wrong list to complain about it. I was just trying to help you to get along with the new file-chooser. 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. But given the antagonism that shows up every time we update the GTK+ dependencies to the latest stable version, I don't even dare to ask about having GIMP depend on the GTK+ development branch. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file handling, something for GIMP 2.4 ?
Sven Neumann <[EMAIL PROTECTED]> writes: > The new GTK+ file-chooser can make use of gnome-vfs, if it is > available. I don't know about the details, but I assume that on win32, > a similar API exists and is probably used by win32 backend of the > file-chooser widget. The default behaviour of the file-chooser is not > to show remote files, but we just need to switch this restriction off. > > If we want to do that, we will however have to make the file plug-ins > use same VFS layer. Unfortunately, there is no platform-independent > VFS library yet, so we would either have to add platform-dependent > code to all file plug-ins, or write our own abstraction layer. I am > not even sure if this is feasible, but I think it would be useful to > evaluate this. I'd suggest first making the "url" plug-in optionally (if available) use gnome-vfs or any other vfs layer available on Win32, OSX etc. (in fact, I'm already about to prepare the url.c code to have multiple backends, the current code being the "wget" backend) An alternative to implementing our own vfs would be to entirely hide file handling from file plug-ins, for example by passing them already opened GIOChannels which they would use to read/write. It woud be easily possible to make the IO channels use some vfs layer and the plug-ins wouldn't even notice. While this would make "straightforward" file plug-ins (which just open, read sequentially, close) much easier to implement, it is problematic for plug-ins which want to seek around in the files a lot (like jpeg.c). GIOChannel has a seeking API, but we cannot guarantee that for all vfs backends we may want to use. We should probably try to design such a VFS/GIOChannel separation in one plug-in to see how feasible this is. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann <[EMAIL PROTECTED]> Date: Sun, 06 Feb 2005 16:19:14 +0100 Robert L Krawitz <[EMAIL PROTECTED]> 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. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Robert L Krawitz <[EMAIL PROTECTED]> 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann <[EMAIL PROTECTED]> Date: Sun, 06 Feb 2005 14:57:59 +0100 Robert L Krawitz <[EMAIL PROTECTED]> 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? -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Sven Neumann <[EMAIL PROTECTED]> writes: > 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. Oh, and before more people ask about the keybindings: Alt- Up Go up a folder. (left in the path-bar at the top of the dialog) Alt-DownGo down a folder. (right in the path-bar at the top of the dialog) Alt-HomeGo to the home directory. Ctrl-L Open the Location entry. / Open the Location entry and enter '/' into it. Other shortcuts are available as mnemonics in the dialog and should be obvious enough not to mention them here. We should probably add this information to the user manual. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Robert L Krawitz <[EMAIL PROTECTED]> 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann <[EMAIL PROTECTED]> Date: Sun, 06 Feb 2005 14:48:03 +0100 Hi, Carol Spears <[EMAIL PROTECTED]> 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!) -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
Hi, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > A thing to remember is that even when it is folded into the main > gimp binary it still needs special command line switches (otherwise > gimp will run into the same problems as mozilla/firebird etc. which > often have frontend shell scripts that mistakenly try to contact a > running mozilla instance, which only works in single-machine, > single-user configs (fixed in debian, btw, but many distros still do > this)). Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Carol Spears <[EMAIL PROTECTED]> 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, "Hal V. Engel" <[EMAIL PROTECTED]> writes: > 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 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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. -- Hal V. Engel pgp8oUv8l4shj.pgp Description: PGP signature
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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 PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
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 <[EMAIL PROTECTED]> > 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
