Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
I eject mine every time. Gimp is the only program that has this problem. I use Inkscape with it and it works fine. --- On Wed, 1/7/09, Dotan Cohen wrote: > From: Dotan Cohen > Subject: Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog > To: "Jernej Simončič" > Cc: gimp-user@lists.xcf.berkeley.edu > Date: Wednesday, January 7, 2009, 6:11 PM > 2009/1/7 Jernej Simončič : > > On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann > wrote: > > > >> No, that is because your operating system of > choice sucks at file I/O. > >> Windows does not buffer access to flash and > network drives. > > > > It does this with removable drives because users > rarely bother to eject > > (unmount) them before unplugging them. You can enable > caching (which > > greatly improves performance), but then you have to > remember to eject the > > device before disconnecting it, or you risk filesystem > corruption. > > > > No, users rarely bother to eject (unmount) them before > unplugging them > because the OS works like this. If the OS said "bad > boy!" and lost > data _once_ then the users would stop. This is a case of > the OS > fostering bad habits by treating the users as idiots who > are unable to > learn something so simple as pressing an eject button > before > physically removing hardware. > > -- > Dotan Cohen > > http://what-is-what.com > http://gibberish.co.il > > א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת > ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي > А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я > а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я > ä-ö-ü-ß-Ä-Ö-Ü > ___ > Gimp-user mailing list > Gimp-user@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
Thanks for the information...BTW, Windoze isn't my OS of choice. I sometimes use Gimp at work, where we are pretty much stuck with Windows (Unless I want to go to the trouble of booting a Linux live CD). At home I have Linux and Mac OSX (Gimp runs kinda funky on OSX...but since I have Linux, I don't worry about it too much.) --- On Wed, 1/7/09, Sven Neumann wrote: > From: Sven Neumann > Subject: Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog > To: chrysalis_reb...@yahoo.com > Cc: gimp-user@lists.xcf.berkeley.edu > Date: Wednesday, January 7, 2009, 4:19 PM > Hi, > > On Sat, 2009-01-03 at 18:16 -0800, Elwin Estle wrote: > > I wonder if a problem I have had with saving files > from Gimp in > > Windows is somehow related. If I save direct to the > local hard drive, > > there isn't much of a problem. But if I try to > save to say, a flash > > drive plugged into the same computer running Gimp, or > to a network > > drive, then file save times get really long. Yes, you > expect those > > two situations to take a bit longer, but not that > long. I can save > > an .xcf file to the local drive and then transfer it > to a flash drive > > or a network drive and it is loads faster than trying > to save directly > > from Gimp. (which is what I typically do, save first > to the local hard > > drive, then transfer the file to the drive I actually > want to store > > the file on.) > > No, that is because your operating system of choice sucks > at file I/O. > Windows does not buffer access to flash and network drives. > So an > application writing a file with lots of file I/O calls will > get > miserable performance for slow drives. Copying the complete > file to that > drive will transfer the data in much larger blocks and thus > yield > reasonable performance. This is not the case on Linux for > example. There > the operating system will take care of combining many small > file I/O > operations into large buffer accesses. > > We might be able to work around this limitation by porting > the XCF load > and save routines and all file plug-ins to GIO, the VFS API > that was > recently added to GLib. Then we could use a > GBufferedOutputStream which > would do the buffering at the application level. > > > Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
2009/1/7 Jernej Simončič : > On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann wrote: > >> No, that is because your operating system of choice sucks at file I/O. >> Windows does not buffer access to flash and network drives. > > It does this with removable drives because users rarely bother to eject > (unmount) them before unplugging them. You can enable caching (which > greatly improves performance), but then you have to remember to eject the > device before disconnecting it, or you risk filesystem corruption. > No, users rarely bother to eject (unmount) them before unplugging them because the OS works like this. If the OS said "bad boy!" and lost data _once_ then the users would stop. This is a case of the OS fostering bad habits by treating the users as idiots who are unable to learn something so simple as pressing an eject button before physically removing hardware. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
On Wed, 07 Jan 2009 22:19:03 +0100, Sven Neumann wrote: > No, that is because your operating system of choice sucks at file I/O. > Windows does not buffer access to flash and network drives. It does this with removable drives because users rarely bother to eject (unmount) them before unplugging them. You can enable caching (which greatly improves performance), but then you have to remember to eject the device before disconnecting it, or you risk filesystem corruption. -- < Jernej Simončič >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
On Wed, 07 Jan 2009 22:11:37 +0100, Sven Neumann wrote: > The above mentioned plug-in will always only be a kludge as it can't > provide all the features that an internal file dialog offers. So the > focus should be on fixing the GtkFileChooser. There is absolutely no > reason why it can't be as fast as the native OS implementation. After > all it is using native OS-specific code. I personally find the GTK+ widget so bad compared to the native Windows one that I usually resort to dragging images from Explorer when I want them opened in GIMP (and I don't use Explorer for file management, but my usual file manager works in console and thus doesn't support drag and drop). -- < Jernej Simončič >< http://deepthought.ena.si/ > < Contact address: >< jernej simoncic at isg si > ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
Hi! Sven Neumann writes: > On Sun, 2009-01-04 at 01:24 +0100, Heinrich Moser wrote: >> I don't think I will further investigate this, since I don't see much >> point in this, to be honest. Yes, we could find out what's taking >> GIMP's file open dialog so long and make it be as "fast" as other GTK >> applications. But I really think the time is better spent solving the >> problem permanently (like implementing the above mentioned plug-in) >> rather than fine-tuning something that can never be as fast as the >> native OS implementation. > > The above mentioned plug-in will always only be a kludge as it can't > provide all the features that an internal file dialog offers. So the > focus should be on fixing the GtkFileChooser. There is absolutely no > reason why it can't be as fast as the native OS implementation. After > all it is using native OS-specific code. Well, that's how it should be in operating systems. To be honest, I don't think this is the case with Windows. Microsoft is well known for using undocumented OS features to make their applications more performant than their competitor's, so I guess they'd do that even more in something they consider part of the OS (rather than an application or a library), such as the file chooser. Nevertheless, as a user of GTK-based products, I really appreciate your effort on motivating people to improve GTK. And I don't want to leave this discussion without giving a big THANKS to all gimp developers for making such a great product! Please consider my request for a Windows file open/save dialog as an improvement suggestion (or as a plug-in suggestion, in case any motivated C developers read this) and not as criticism of your work or of your design decisions. Best greetings from snowy Austria, Heinzi ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
Hi, On Sat, 2009-01-03 at 18:16 -0800, Elwin Estle wrote: > I wonder if a problem I have had with saving files from Gimp in > Windows is somehow related. If I save direct to the local hard drive, > there isn't much of a problem. But if I try to save to say, a flash > drive plugged into the same computer running Gimp, or to a network > drive, then file save times get really long. Yes, you expect those > two situations to take a bit longer, but not that long. I can save > an .xcf file to the local drive and then transfer it to a flash drive > or a network drive and it is loads faster than trying to save directly > from Gimp. (which is what I typically do, save first to the local hard > drive, then transfer the file to the drive I actually want to store > the file on.) No, that is because your operating system of choice sucks at file I/O. Windows does not buffer access to flash and network drives. So an application writing a file with lots of file I/O calls will get miserable performance for slow drives. Copying the complete file to that drive will transfer the data in much larger blocks and thus yield reasonable performance. This is not the case on Linux for example. There the operating system will take care of combining many small file I/O operations into large buffer accesses. We might be able to work around this limitation by porting the XCF load and save routines and all file plug-ins to GIO, the VFS API that was recently added to GLib. Then we could use a GBufferedOutputStream which would do the buffering at the application level. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Win32: Use standard Windows File Open/Save dialog
Hi, On Sun, 2009-01-04 at 01:24 +0100, Heinrich Moser wrote: > I don't think I will further investigate this, since I don't see much > point in this, to be honest. Yes, we could find out what's taking > GIMP's file open dialog so long and make it be as "fast" as other GTK > applications. But I really think the time is better spent solving the > problem permanently (like implementing the above mentioned plug-in) > rather than fine-tuning something that can never be as fast as the > native OS implementation. The above mentioned plug-in will always only be a kludge as it can't provide all the features that an internal file dialog offers. So the focus should be on fixing the GtkFileChooser. There is absolutely no reason why it can't be as fast as the native OS implementation. After all it is using native OS-specific code. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
gimp-user@lists.xcf.berkeley.edu
sorry for x, please `cat /dev/mem > /dev/dsp` -- the new pure:dyne GNU/Linux leek&potato released! -- * ,--. * ,---. --.,--.--.--.,---. --.,-' |--. ,--.--,--, ,---. * | .-. | || | .--' .-. :--' .-. |\ ' / \ .-. : * | '-' ' '' ' | --.--. `-' | \ ' | || | --. . | -' `' --' `'--'`---' -' / `--''--'`' `--' http://puredyne.goto10.org `---' * . pure:dyne is an operating system developed to provide media artists with a complete set of tools for realtime audio and video processing. pure:dyne is a live distribution, you don't need to install anything. Simply boot your computer using the liveCD/DVD or liveUSB and you're ready to start using software such as Pure Data, Supercollider, Icecast, Csound, Fluxus, Processing, Arduino and much much more. pure:dyne will work on any x86 PC laptop, desktop, and single-board computers, including the intel-based Mac, Asus' Eee PC, and any x86 netbooks :) -- Get pure:dyne now!!! (CD/DVD ISO, liveUSB, Debian packages, etc) https://code.goto10.org/projects/puredyne/wiki/GetPureDyne complete software list: https://code.goto10.org/projects/puredyne/browser/press/deb/ -- /usr/share/soup !!! Each pure:dyne release come with a Free/Libre and Open Source Soup (FLOSS). This time we hope you will enjoy our leek and potato flavor :) Depends:Leek, Potato, Milk, Salt, Oil, Pumpkin oil Suggests: Thyme, Sage, Pepper, Parsley, Crème fraiche Build-Depends: Cookpot, BlenderkMasher, Frypan, Bowl make: default:serving tender potato: potato cookpot salt water 20min tasty leek: leek oil frypan 5min puree: tender potato tasty leek blender soup: puree milk herbs cookpot 5min herbs: thyme sage pepper serving: soup bowl parsely pumpkin oil crème fraiche for more details: echo "deb http://debian.goto10.org/debian/ lenny main" >> \ /etc/apt/sources.list && apt-get install souprecipe -- pure:dyne is a GOTO10 project, developed by Rob Canning, Heather Corcoran, Antonios Galanopoulos, Karsten Gebbert, Claude Heiland-Allen, Chun Lee, Aymeric Mansoux, Marloes de Valk and with the contribution of Robert Atwood (Openlab) and Jof Thibaut (Labomedia). pure:dyne is supported by Arts Council England and powered by GNU/Linux Debian, debian-multimedia.org and the great Debian Live project. We would like to thank bob the pbuilder and all the pure:dyne users for their ongoing feedback, suggestions and testing! -- :* ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Hiring a programmer and Gimp guru
Hello, I am the lead developer and current CEO of a small startup developing some kind of cool Web 2.0 product (this sure looks funny, but cannot say much more right now). I am looking to hire someone with a very specific profile, so I thought maybe this mailing list would be a good start. The ideal person would have: * excellent designer skills using open-source tools (Gimp, Inkscape, etc...); * be a efficient programmer (the best would be to have some knowledge of Gimp internals, or to have already written Gimp plugins) * good knowledge of Web languages (HTML, CSS, JS). The important part is that we need someone who can create great visual designs and images (this is absolutely needed for the role), but who is also a programmer, or has at least basic programming knowledge and is willing to become an advanced programmer. Knowing Python and the JEE framework (especially Spring and Hibernate) are huge bonuses as that's what we use, but more important for us is someone who can learn quickly (and enjoys doing this) new frameworks, languages and libraries. Oh, and he should be an open-source enthusiast. As you see, developers / contributors to the GIMP would constitute excellent candidates, if they have also great artistic skills :) Place is not important as we are able to offer full work from home opportunity to the right person, and we plan to follow a distributed agile approach for development. Small bonuses for candidates in France, Canada, the US or Russia as we have ties to these countries. We are currently based in France. We would be able to pay a really good salary, and we are interested in getting in touch with candidates right now (although we are still looking for funding, so are not sure to be able to hire someone until funding is secure). Feel free to pass this information along to whoever may be interested in the role. Jean-Noel Rivasseau PS: I am usually on the #gimp channel on IRC, by the nick elvanor. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] "Live" update of selected regions
Hi Marco, Marco Presi wrote: > Hi, > > I would like to know if there is a way to update a selection made with > any of the selection tools. After the selection is made I often would > like to make it smoother or to change the threshold (expecially when > selecting by color). Acting on the selection controls (smoothing radius, > threshold, ...) has no effect: in order to make the adjustments, I need > to re-select from scratch the region. > > Is there a way to do this without selecting from scratch again and > again? You could convert the selection to a path, and, at demand, proceed vice versa (path -> selection). Then you could, say, feather the selection, or whatever. This way, you wouldn't have to select the same area again. That's what comes to my mind instantly. HTH, -- Claus Cyrny : Webdesign | Grafik | Fotografie :: Web: http://home.arcor.de/ccyrny/ ::. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] "Live" update of selected regions
Hi, I would like to know if there is a way to update a selection made with any of the selection tools. After the selection is made I often would like to make it smoother or to change the threshold (expecially when selecting by color). Acting on the selection controls (smoothing radius, threshold, ...) has no effect: in order to make the adjustments, I need to re-select from scratch the region. Is there a way to do this without selecting from scratch again and again? Regards Marco ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
