Re: [Gimp-developer] Webdesign is wrong
On 6/26/07, peter sikking [EMAIL PROTECTED] wrote: Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics... an aspect ratio of 1000 to 4. cool. at what zoom level(s) do you adjust this selection? and why? At one point a few years ago I was working on very large maps for MMORPGs stitched together from many smaller images. It was not uncommon for me to have a 1x250 selection. Not quite what Liam is doing, but still extreme. I generally created the selection at about 10x zoom, which meant I had to scroll 100 screens (1024 display width, 1*10x image width) sideways. This would be much harder today, as it seems that GIMP has lost a lot of its old scroll super fast if i drag far outside the window functionality in more recent 2.3 builds. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save for web plugin feedback
On 3/16/07, Morgan Christiansson [EMAIL PROTECTED] wrote: Hi, i have a friend who's just migrating off windows and is currently running Ubuntu which he's generally happy with. He complained about save for web functionality missing from the stock GIMP and had some good points on why it's needed, i found the save-for-web plugin through Linux for Designers blog ( http://my.opera.com/area42/blog/ ). I personally don't see much use for a save for web plugin. Any functionality that it would have should already exist in other save dialogs, or be added if they are currently unimplemented. A save meta-dialog that can compare multiple formats (gif vs jpeg vs png) is a plausible addition, but theres no reason to restrict it to web-friendly options, or to duplicate functionality that already exists in the format-specific plugins. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 2/5/07, Jakub Steiner [EMAIL PROTECTED] wrote: Personally I'd rather have the screenshooter be a separate application. There is a good number of efficient workflows using existing tools (`sleep 5 import (-window root) ~/Desktop/foo.png` [1], `gnome-panel-screenshot --delay 5 (--window)` , ksnaphot (don't know my way around that one)). Shouldnt a (possibly slightly less) simple one-liner be possible piping script-fu to gimp to call the screenshot plugin's APId function(s)? IMHO, we need to keep in mind that things accessible on the interface dont neccessarily define the capabilities of the back end. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/31/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Tue, 2007-01-30 at 19:09 -0600, Clarence Risher wrote: Sven's argument is true, but does not address my point. In every case like this the process will be more complex than just shot-clip-done. In cases of non-rectangular areas the clipping will be quite annoying. And in the rare case of alpha transparency it would be impossible to erase the parts of the desktop or other windows behind the window you are trying to capture. The point is that you are bringing up a completely new topic here. There is currently no support whatsoever for shaped windows or windows with an alpha channel. As long as no one adds such support (which would be extremely complicated to get right on all systems), there is no point in arguing about it. Perhaps there is no intentional support, but I guarantee you that gimp (as of 2.2, and i expect still in 2.3) takes screenshots of non-rectangular windows just fine. The result is a black rectangle containing the visible shape of the window. For a completely silly example, consider a screenshot of xeyes. Think about how bothersome it would be to manually crop out the window behind the eyes (which are oval) if you had to make do with a desktop screenshot and a crop tool. A less silly example is any window decoration theme with rounded corners, or bits that extrude off the edges. Also, my silly xeyes idea brings up a point on the primary topic as well... I need a delay before selecting the xeyes window to get to the proper desktop, or bring it to the front, and a delay after selecting it because I dont want it to look crosseyed (for anyone who doesnt know, xeyes is two animated eyeballs that stare at the mouse cursor). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] saving image doesn't create thumbnail in 2.3.14 for Windows
On 1/31/07, Alexander Rabtchevich [EMAIL PROTECTED] wrote: When Gimp 2.3.14 for Windows saves image, it doesn't create a thumbnail for it. To clarify, which thumbnail are you talking about? A GIMP file browser preview? A JPEG internal thumbnail? A Windows Explorer thumbnail? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, Sven Neumann [EMAIL PROTECTED] wrote: to propose a user interface that fits all needs. imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI. (sorry for the dupe email Sven) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, Sven Neumann [EMAIL PROTECTED] wrote: On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote: On 1/30/07, Sven Neumann [EMAIL PROTECTED] wrote: to propose a user interface that fits all needs. imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI. We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother. Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in. Well then, as crude as it may sound, consider this an intentional punch in the face, as much so as those people punched Ms Peck (great book, btw) in the face by making her waste time un-crippling the plugin. As soon as someone integrates the region feature into the 2.2 plugin, I will be running that. As has been mentioned in so many other threads time and again, you can't hold GIMP out as a viable replacement for Photoshop AND make it grandmother-friendly. The 2.2 interface was fine. Maybe it needs better tooltips and labels for some people. Hide one of the delays in an 'advanced options' panel if you must. But do not remove functionality just to make grandma happy. Removing functionality is never the answer. Removing functionality is the question. The answer is NO. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, peter sikking [EMAIL PROTECTED] wrote: - the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out). For the record, windows are not always rectangular, or do not always fill their bounding box. Or they may contain (alpha) transparent areas that are well nigh uncleanable when full-screen screenshot'd without sufficient prearrangement. (sorry for the duplicate peter, i always forget this mailing list doesnt set reply-to) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On 1/30/07, peter sikking [EMAIL PROTECTED] wrote: Clarence Risher wrote: On 1/30/07, peter sikking [EMAIL PROTECTED] wrote: - the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out). For the record, windows are not always rectangular, or do not always fill their bounding box. You see, you had me doubting there, but then Sven wrote: The windows are still rectangular [edit to restore context: even if they have a bitmask or alpha channel that makes their shape appear non-rectangular. Screenshots of such windows will always be rectangular so this doesn't really matter here. ] else I would have given the whole thing a re-think. Sven's argument is true, but does not address my point. In every case like this the process will be more complex than just shot-clip-done. In cases of non-rectangular areas the clipping will be quite annoying. And in the rare case of alpha transparency it would be impossible to erase the parts of the desktop or other windows behind the window you are trying to capture. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 splash screen
On 12/14/06, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-12-13 at 17:21 -0600, Clarence Risher wrote: Seems like tradition, every splash I can remember except 1.0 had a version number. The wording on the rules doesnt require it, but it seems to suggest it in more than one way. Would have been nice if you had replied to the list. Anyway, your reply doesn't give a reason for the numbers to be, there even though I would have been interested in hearing a good one. Sorry, I don't use many mailing lists without reply-to set, hard to remember to change the To when I reply here. I wasn't aware of the codified rules for splash images. Now that I have read them, I can see that you are right about the numbers not being required. But doing away with them seems to go against an unwritten policy that has been in effect for over 5 years. I am used to seeing the numbers every day when I start up 2.2 and 2.3, it is very helpful in remembering which version I am working with. Of course, the lack of numbers will make it somewhat evident with 2.4, but I fear it might be less obvious once I am using 2.5, and when 2.6 comes out if it continues the new trend. I DO like the new artwork, aside from its lack of version numbering. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 splash screen
Are we intentionally not having the version number in the art? On 12/13/06, Jakub Steiner [EMAIL PROTECTED] wrote: Howdy folks, as the release approaches, I'd like to propose a default splash screen for 2.4. It's 99.9% work of Paul Davey of Gant* fame. It's both polished and not super-serious at the same time. http://jimmac.musichall.cz/stuff/splash-mockup.png http://jimmac.musichall.cz/stuff/gimp-2.4polished.png http://jimmac.musichall.cz/stuff/gimp-2.4polished.xcf.bz2 Now all we need is someone to produce the Wilber-baloons for us! cheers * http://www.deviantart.com/view/3035321/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp certification
1) What does GIMP stand for?2) What does GNU stand for?50% is a passing score. 100% qualifies for Advanced rating.On 5/12/06, Olafur Arason [EMAIL PROTECTED] wrote:I think Gimp should have something like Adobe Certified Expert. This would ensure that gimp trained individuals could showthat they know Gimp like it's possible to test what you knowabout Photoshop.This test should be hard, but not it the memorize everything kind of hard, this would be to ensure that people that getthis degree actually know something about Gimp.What would you think a person with this degree shouldknow?Is anybody on this list willing to participate in this? Is certification such a bad idea that Gimp shouldassociate it self with it?LPI is interested, but there is nothing definiteOlafur ArasonP.S Please don't say it takes to much time, making true color management work in Gimp also takes time but I don't seeanybody say that we should not do it because of that. ___Gimp-developer mailing listGimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possibility of a stand in Siggraph
Just throwing it out there... It might be cool to have a stand split between the main LGM projects (GIMP, Blender, Inkscape, Scribus, Xara).On 5/10/06, Dave Neary [EMAIL PROTECTED] wrote:There's a decent possibility of having a stand very cheap (proper island stand, partially sponsored, in the main conference area) which we would share withBlender and some other projects (Ton from Blender's co-ordinating). I wouldlove to have the GIMP represented at a top flight conference like this, and think it's worth the money - the GIMP's part of the pie would be between $1Kand $2K, depending on the levels of sponsorship, whether we bed in with theGNOME guys, etc. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling gimp under debian with gimp-print support
On 4/16/06, Frédéric [EMAIL PROTECTED] wrote: I successfully compiled gimp-cvs under my debian testing, but withoutgimp-print support.What do I need to install to get it ? I can't find any gimp-print-dev or sopackage...I believe libgimpprint1-dev is the package that you need (sorry Frederic for the double email) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] File save plugins, preferred vs required image types
I am taking a stab at my first contribution in the form of an improvement to an existing file saving plugin. I have discovered how the plugin specifies which types of images it can handle (INDEXED*, GRAY*) but I have a small problem. Currently a dialog appears to asks if the image should be converted to indexed or greyscale, but if I add RGB* as an accepted type than that dialog goes away. I want some sort of prompt to still appear asking the user if they want to index the image. Is there any sort of image type 'preference' that would not have the force of a requirement but would still produce that dialog? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer