[Gimp-developer] List archives...
Hi Where are the current list archives? The newest on this lists server are from 2003: https://lists.xcf.berkeley.edu/lists/gimp-developer/ Regards Piotr L. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] List archives...
Where are the current list archives? http://www.gimp.org/mail_lists.html HTH, Michael -- Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail ___ 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 ?
Maybe when accessing files through gnome-vfs files are copied to the local system and then opened so that plugins or file ops that need to access the file directly can. Regardless of how it's done, emphasis should be put on what the user expects to happen. In this case (IMHO as a user) the user expects that if they can access and view the file on a sftp connection to a remote server (through say, EOG or nautilus), they should be able to use the gimp on the same file. BTW, gimp 2 kicks ass, keep up the good work devs! On Sun, 6 Feb 2005 11:57:52 -0500, Nathan Summers [EMAIL PROTECTED] wrote: 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 -- Alan -=|=- http://arcterex.net If you think dogs can't count, try putting three dog biscuits in your pocket and then giving Fido only two of them. --Phil Pastoret ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: color management
Hello, Great news!! I have been working in the gimp-color-manager plugin which is strongly related (in fact it can be modified to meet your 7th point) I already have corrected the bugs found in the previous release and made some changes in order to clarify the workflow. Actually the plugin can do -Convert from input profile to work space profile -Convert from work space profile to output profile -Embed and use enbedded work space profiles (using icc-profile parasite) I also want to add the conversion from work space A to work space B before releasing this version. (you can check the actual code at ftp://www.virtual-sub.org/gimp-color-manager-pre-0.0.10.tgz ) It would be great if the plugin can get the color configuration (directory to look for profiles, scanner ,workspace and printer default profiles..) from the preferences set in the new dialog. Is there a guide to setup a cvs compilation in a local user without interfering the global configuration and the other users in the system? I am very interested on getting that color management stuff working, but I cannot change/reinstall the linux box I am using, so I must work locally. [EMAIL PROTECTED] wrote: Hi, [...] - add a plug-in to apply color profiles [...] -- Jordi Cantón http://www.virtual-sub.org ___ 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 Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann [EMAIL PROTECTED] 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? Yes, you miss the first and last error causes given above. A local process proves nothing about file accessibility. Think about it, X11 is a networked environment. Processes share an X-display, but not the filesystem view. Linux for example provides each process with it's own filesystem view, and this is expected to be used more and more in the future. The only save protocol would be to tansfer the file contents and name through the x-server (a selection for example), and keep the gimp-remote around to receive the file on saves, which is an awkward solution. I think having the option of using gimp-remote with clearly defined limitations (same filesyetm view required) and using gimp to ensure correctness is preferable over some heuristic that gets it right for 95% of the users or so. What advantage does an integrated solution bring? As far as -i can see, it's only badly written programs that mindlessly use gimp when they should offer the option of using either gimp or gimp-remote. -- 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 08:08:29PM -0800, Manish Singh [EMAIL PROTECTED] wrote: 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's a very good approach, as it can be configured system-wide and without requiring commandline args. That should make everyone happy. It certainly would make me happy. -- 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] file handling, something for GIMP 2.4 ?
Alan Bailward [EMAIL PROTECTED] writes: Maybe when accessing files through gnome-vfs files are copied to the local system and then opened so that plugins or file ops that need to access the file directly can. Regardless of how it's done, emphasis should be put on what the user expects to happen. In this case (IMHO as a user) the user expects that if they can access and view the file on a sftp connection to a remote server (through say, EOG or nautilus), they should be able to use the gimp on the same file. That's exactly what is almost implemented in CVS HEAD. More stuff to come. BTW, gimp 2 kicks ass, keep up the good work devs! Thanks :) ciao, --mitch ___ 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: Yes, you miss the first and last error causes given above. A local process proves nothing about file accessibility. Think about it, X11 is a networked environment. Processes share an X-display, but not the filesystem view. Linux for example provides each process with it's own filesystem view, and this is expected to be used more and more in the future. local of course means on the same file-system, which can easily be checked by looking at a pid file on that very same file-system and checking that it corresponds to the GIMP application that announces itself using an atom on the X server. I think having the option of using gimp-remote with clearly defined limitations (same filesyetm view required) and using gimp to ensure correctness is preferable over some heuristic that gets it right for 95% of the users or so. What advantage does an integrated solution bring? As far as -i can see, it's only badly written programs that mindlessly use gimp when they should offer the option of using either gimp or gimp-remote. The question wouldn't come up so frequently then. Lately things have improved a bit because the desktop entry specification has become widely adopted. That doesn't work for all platforms/desktops though. 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, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: 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. 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. This is however completely in the GTK+ realm. It could probably be improved but that would have to be done in GTK+. 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. 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 or any other dock is focused, can you use these shortcuts. In GIMP 2.2 you can set keyboard shortcuts for almost everything. You aren't even limited to what appears in the menus. Perhaps you should explain that to the people laughing. Laugh about their ignorance. 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 ?
Hi, Alan Bailward [EMAIL PROTECTED] writes: Maybe when accessing files through gnome-vfs files are copied to the local system and then opened so that plugins or file ops that need to access the file directly can. Mitch is implementing just that right now. It's already almost working in the CVS version. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Inkscape-devel] common interface for graphics apps on thefree desktop
Sven Neumann wrote: Michael Natterer [EMAIL PROTECTED] writes: Perhaps we should just swap the Shift and Ctrl modifiers for display scrolling to be consistent with the HIG and across graphics apps. Sounds like a good idea. Let's do this for 2.4. Two questions about the current GIMP behavior (unrelated to modifiers): 1: Ctrl-Scroll up/down scrolls left/right. Wouldn't scroll up/down scrolling up/down be more logical? What happens on mice with scroll wheels for left/right? Does it just work out? 2: Shift-Scroll up/down zooms in/out from the center of the image. Would it be more useful if the zoom in feature zooms at the current cursor position? Is that possible, or would it be too confusing? Chris ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
