[Gimp-developer] [long] Suggestions + Patch, Redo (please dont flame), Part 1
on IRC Sven said i really should put these changes to the list for discussion I will try and make keep this simple but I have a few loosely related changes all of which are against gimp/app/gui/image-menu.c The patch is here http://bugzilla.gnome.org/showattachment.cgi?attach_id=17739 Attached to this bug report http://bugzilla.gnome.org/show_bug.cgi?id=92468 The patch itself is simple, but I expect it will be controversial. Firstly (and most likely to be incredibly unpopular) I want to change Redo Control+R to Redo Control+Shift+Z Reasons: Ctrl+R is not unreasonable, as R is the first letter of Redo (in English at least) and it probably comes from something older than me that I am unaware of but very few other applictions use it, which makes it inconsistant and harder for most people to learn. I will qualify what I mean when I say very few: Microsoft Windows doesnt use Ctrl+R, usually it uses Ctrl+Y the twisted logic being that Y comes before Z and Z is used for Undo. (Mozilla uses Ctrl+Y for Redo as well). Apple OS X uses AppleKey/CommandKey + Shift + Z, older versions may have used CommandKey + Y but I cannot remember clearly. The logic is to use a Shifted version of a keybinding for closely related actions across the whole desktop which makes it slightly easier to guess unknown keybindings (and means you can use Ctrl+Y for something else). Gnome uses* Ctrl+Shift+Z for Redo. [* most Gnome apps do already or will follow the Gnome Human Interface Guidelines. This guideline does makes sense, they are just following Apples logic] KDE also uses Ctrl+Shift+Z http://developer.kde.org/documentation/standards/kde/style/menus/edit.html (These are based on a google search:) Abode Photoshop also seems to use Ctrl+Shift+Z for Redo Jasc Paint Shop Pro is a bit strange and uses Ctrl+Alt+Z, because Ctrl+Shift+Z is already taken by Undo History (using Ctrl+Alt+Z for Undo in Gimp wouldn't be a terrible idea, but i know using Alt cause some minor problems in places). So I have made it pretty clear that many many people would be more comfortable with having Ctrl+Shift+Z but I have not forgotten about those of you who have been using the Gimp for a very long time. One option is to reassig the keybinding manually. There also already exists a Menu Configuration File for Photoshop users, I propose a Menu Configuration for users who like the current menu configuration and dont want things changed (there was a bug report about being allowed to change and reset the menurc from the preferences dialog but i am not sure of its current state). I also want Ctrl+R for a different keybinding. This message is getting really long so I will explain the rest of the patch in other emails, please hold off critiquing the rest of the patch for a while so that I have a chance to _fully_ explain my reasoning. I have put a lot of time and thought into this, but I am not an expert I just know what I like and have a reasonably good understanding of why so please consider your criticism carefully. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ PS Please leave my address in the CC line, I am subscribed to the list digest and it will take me a while to give carefully considered responses to any questions. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Thu, 10 Jul 2003, Sven Neumann wrote: The point is that the GPL explicitely asks to present the user with You are telling me that most of the programs in Gnome and KDE are wrong and the GIMP is right. I will go and read the GPL again and I will read the GPL FAQ and see if I can figure out where is this explicit requirement to display the license. this copyright notice on very startup. I think it is good style to do so at the very first startup at least. Find it annoying, I find it amusing and it definitely doesn't hurt. The changes are not in CVS yet. There was no way for me to know what the recent changes you made are, could you please say what they are? This is a bad example since there are other reasons for this being a separate menu entry. Bad example, fine I'll try another. The GIMP hides information, the GIMP hides the menus in a context/right click menu instead of up front in Menu (at least until recently, now there is at least an option which I am very thankful for). This is hiding useful information, this is adding one extra click to many operations. Many gimp users swear by hiding this information away and many more swear at it. I believe the standard excuse is screen space, but if screen space is really important to you then you would run the GIMP in fullscreen view (with or without a menubar*) which gets rid of the pixels wasted by the window manager (another recent addition it seems). (* Photoshop allows a menubar in fullscreen mode which really allows you to make the most of the available space and still have the convenience of a menubar. If the GIMP does I have not yet figured out how to keep the menubar turned on in Fullscreen mode) Take the example of Red Eye correction, you can do Red Eye correction in the GIMP but many programs have a dialog specifically for doing this task which makes things easier but does not make the program any less powerful. I thought this might be a better example of how hiding unnecessary detail make an application more useful not less useful. If asking all these questions at startup is such a good idea why not ask the users even more questions, why not get them to set every preference? If this is such a good idea why are no other Gnome or KDE programs doing this? Does the operating system or distribution you use include many programs that ask you many questions before you are allowed to use them for the first time? just don't see why we should put valuable developers time in removing I am not asking you to do it. I am asking you to let it happen. The attitude I keep encountering is a strong resistance to progress. I know I probably should have fough for these changes earlier in the 1.3.x cycle but most distributions still ship Gimp 1.2.x. The bulk of GIMP users are not using 1.3.x yet. For most users the changes are going to be quite dramatic anyway which is why I dont understand why my suggestions are so contraversial. I want you to accept that changes like these could and should be made and to stop dragging your heels just because that is the way things are now and have been before instead of giving real reasons for things being the way they are. If you were more receptive then I would be able to go off and worry about getting a suitable patch done (by me or with help or whatever). Sincerely Alan Horkan. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Menubar in fullscreen mode [Re: [Gimp-developer] the user installer]
Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. - Alan (had to disappear for a few days been busy with other stuff) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
On Wed, 16 Jul 2003, Sven Neumann wrote: Date: Wed, 16 Jul 2003 13:57:18 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Menubar in fullscreen mode [Re: [Gimp-developer] the user installer] Hi, Alan Horkan [EMAIL PROTECTED] writes: Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. I don't understand your answer but just to clarify my sentence I will describe the behaviour of fullscreen mode for you. By default, if you I expected the menubar to stay on in fullscreen mode. I just wanted to point out that my expectations were different from what happened, which I realise is unneccessary information from your point of view. (I only have a recent build at home so it takes me a while to check these things). Having to turn it back on for full screen mode is sensible enough, and an entirely reasonably solution. Adobe seems to think Fullscreen with menu bar is an important enough option to give it a toolbar button and menu item. Perhaps the GIMP would consider giving it a menu item (and that menu item would allow a keyboard shortcut which is what I really want. if i recall correctly Photoshop uses Shift+F, instead of just F for fullscreen). normal mode and this state is saved and will be used again when you switch to fullscreen mode again later. I hope this clarifies things. Thanks for the clarification. Should I file a request in bugzilla, asking for a Fullscreen with Menu option or do you think it would not be worth adding? Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
This actually could be a serious usablity issue, since a user who has the menubar on (which a distro might set as default) after going to fullscreen mode might not be able to figure out how to get the menubar back, or even how to return to windowed mode. Hit Escape (Esc) should work. Also the keybinding for Fullscreen mode should take them back. Many programs do also provide some sort of extra clearly obvious button that takes you out of fullscreen. (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) I have to be regularly reminded that most users dont use software on a regular basis and essentially have to relearn from scratch each time they try to use an appliction. Seriously, though, it would be a much better behavior to keep the menubar when the window is made fullscreen. A user that prefers a menubar will probably prefer one in fullscreen mode also. Besides, a user with a clue will be able to turn off the menubar anyway. I am just really glad to have the menu bar at all. (Thanks to who ever added it) - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003 [EMAIL PROTECTED] wrote: If we really are in brainstorming mode here, following the suggestions listed above, how about a format something like the following, which is essentially just an XML preamble, followed by raw binary data: The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional Fully parseable XML until it is isn't :) It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). The proper XML way to do what you describe would be to take the raw binary and base 64 encode it (ick) which is grossly inefficient for anything large. The more sensible way and still valid way is to use a container format and to link to the raw BLOB (binary large object) that would be another file in your container format. I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Zip allows you to grab just one file out of the archive if that is all you want, you can have differnt files inside a Zip archive each with different amounts of compression (including no compression). program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If GIMP were to use Zip/Jar only as a conatianer and not use the Zip compression then the whole container could be compressed using different / better compression if that is what you want. (I say better very guardedly because compression is often a trade off against how long you want to spend compressing or decompressing). yosh wrote: data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere. Another downside: needing a special tool to manipulate it. To reiterate what Yosh said, Needing specialised external tools would require more developement work, and add complexity not make things simpler. By reusing standards you can leverage existing tools, libraries and other peoples work, leaving more time to focus on image manipulation. That's the advantage of using a standard format. Using standard tools to manipulate it. More likelihood of a machine having a tool installed, and less work for the GIMP team in maintaining special tools. You're right about simplicity though, and ar is simpler than tar or zip/jar, which is why I prefer it. zip/jar is especially crappy since the file index is at the end, which means it's harder to recover from a partial file. I think the JAR format gets around the Zip crappiness by putting the manifest.xml at the start of the file. I could not say how hard it is but Winzip seems to do a pretty good job of repairing any broken zip archives I throw at it, at least allowing me to get some of the files out. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Roger Leigh wrote: Date: Thu, 17 Jul 2003 22:22:17 +0100 From: Roger Leigh [EMAIL PROTECTED] To: Manish Singh [EMAIL PROTECTED] Cc: Alan Horkan [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] Manish Singh [EMAIL PROTECTED] writes: I don't see a compelling argument to use zip/jar. It's complexity that doesn't buy us anything over ar. $ ar t gimp1.2-print_4.2.5-4_i386.deb debian-binary control.tar.gz data.tar.gz The Debian dpkg .deb package format uses an ar archive with gzip compressed members. It's very robust, and it's simple to extract information from any of the members as needed. e.g. $ ar p gimp1.2-print_4.2.5-4_i386.deb control.tar.gz | tar xfz - ./md5sums you used a pipe what happened there is that you just unzipped the entire archive then in a seperate operation you extracted just the files you wanted. there is nothing wrong with that, you get better compression that way. In a zip archive you really do just extract the single file, there is no unzipping of the whole archive first, which is useful if you just want to grab one or two files quickly from a large archive. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On Thu, 17 Jul 2003, Christopher Curtis wrote: Date: Thu, 17 Jul 2003 17:10:02 -0400 From: Christopher Curtis [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol 10, Issue 18] It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not On The Other Hand, it does not prevent any of the things you are suggesting. Using a container at all is OTOH. run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. I made a terrible mistake of generalising from one instance. It is doable it but it was just coincidental in that it was done that way in the file I looked at. While I am apologising, I may as well repeat what I said offlist. I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). I expect there must be command line tool for unix zip files, i just dont happen to know what it is yet. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] (LONG) Problems with the GIMP
1) User feedback on the development series is poor Mozilla has nightly builds. Mozilla gets lots of feedback. When I asked if there were binaries (RPMs) of the Gimp 1.3.x releases I was told in no uncertain terms that I should be building from CVS. Some RPMs of some of the releases were available on RPMFind.net which allowed me to get started looking at Gimp 1.3 although I did eventually make the effort to build from CVS. If there are any win32 builds of the 1.3.x series then I have not seen or heard anything about them. If you want more feedback then binaries for every release would be very helpful to allow people to test and give feedback on the GIMP. I guess this ties in to the release cycle. Proposal 6 - allow people to submit bug reports without a bugzilla account. I would like it if Bugzilla could get their In order to maintain some level of quality bug reports this is not such a good idea. Some small barrier to entry is actually useful to keep up the quality of bug reports even if you do unfortunately lose out on quantity. Bug-buddy to an extent allows people to submit bugs without a bugzilla account. If asked to do so the user lists may be willing to listen carefully to feedback and help file some bug reports when they see fit, or encourage people how have problems and help them to file bug reports and confirm that the problem exists. Normal users can be very good at turning unhelpful flames and unconstructive criticism into useful constuctive bug reports, filtering out the bits and hopefully forwarding on what the developer need to know. I have more comments but I'll leave them for later. The current situation is good in many ways and the GIMP has come a long way but I hope that even more can be done and the GIMP get better and better. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Me too, or should I say me 2.0
I was asked to make my opinion known on-list, there is no need to reply to this message. On Sun, 20 Jul 2003, Sven Neumann wrote: Various Gnome projects decided the move to GTK2 and additional feature changes were a big enough change to merit a major number revision. Given the progress, the improvements and changes that have been made to the GIMP since 1.2 a major number change is understandable and reasonable. Just thought I should mention that I agree with you on this one, not that I would appreciate if you could tell the list about your opinion on Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [FEATURE] Some plug-in settings should be persistent accross sessions
In another bug report (which I am having difficulty finding) a users complians of being asked too many questions during Save. To solve this i suggested that there should be a section in Preferences allowing you to set save options on the basis that you dont need to set these options every time you save, usually you will want to use the same ones most of them. There would also need to be an [Options] button in the save dialog to access it quickly and change a save option when needed. I would be very much in favour of having a Prefernces section Export (and possibly Import). Hopefully I can help recommend how this might be added. I would be inclined to push the feature request to Future. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Original message included below: [and list digest options finally changed to MIME so i can reply to stuff properly in future] From: David Neary [EMAIL PROTECTED] To: Gimp Developer List [EMAIL PROTECTED] Subject: [Gimp-developer] [FEATURE] Some plug-in settings should be persistent accross sessions Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 MIME-Version: 1.0 Precedence: list Message: 11 Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=63610 Notably the Gif and Jpeg plug-ins have defaults which people change fairly frequently. It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal preferences dialog (this might be handy enough although Sven might have something to say about it). Basically some discussion is needed. Currently, the jpeg defaults suck. I would suggest following the advice in this bug and changing the default quality to 85%. Currently this is hard-coded in the plug-in. If someone were to spend a bit of time figuring out how we could do this better (and reporting here, and claiming the bug) that would be great. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On 26 Jul 2003, Daniel Egger wrote: Date: 26 Jul 2003 17:03:09 +0200 From: Daniel Egger [EMAIL PROTECTED] To: Roman Joost [EMAIL PROTECTED] Cc: Gimp Developer [EMAIL PROTECTED] Subject: Re: [Gimp-developer] writing german online help Am Sam, 2003-07-26 um 13.07 schrieb Roman Joost: I cant find anything related to the gimp-help project at the newer webpage. You're right. There isn't... :( So, if someone could point me to a ressource regarding this project it would be fine. Ressources: - This mailinglist (there had been a big discussion here the last few days), you might want to check the archives the archives are either completely broken or just severely delayed. it is the 26 of July and the archive still does not show any messages for July. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On Sat, 26 Jul 2003, Adam D. Moss wrote: Sven Neumann wrote: Miguel Ibarra [EMAIL PROTECTED] writes: Here's a patch to add optional libstartup-notification support to The Gimp. This will allow desktop managers as Gnome's to entertain users with a *so* funny clock cursor, while Gimp launches and initializes itself. GIMP-1.3 does this already. We will not include it in 1.2 since only bug-fixes go into 1.2. Some projects are not so strict and would allow something like this because it is quite unlikely to have any unwanted side effects. Also if someone goes to the trouble of providing a patch the rejections needs to be less abrupt if you want people to keep making that effort. I'm interested, from a project point of view, why many (a good proportion) of the patches that we get on this mailing list or in bugzilla from 'external' (non-CVS-account) contributors are against 1.2.x. There has been too long a space between stable releases, I expect many people are blissfully unaware that GIMP 1.3 even exists (and will remain unaware until a new release ships with a major Linux distribution). Are developers not very well aware of the positioning of 1.3.x (development) versus 1.2.x (stable)? Is it too hard to get a 1.3.x build to patch against? Miguel, or anyone else, can you comment? Identifying the cause of this weakness would help to smooth the bumps in accepting (very welcome) external contributions. I am optomistic that there will be an increase in outside contributions when 2.0 comes out. (I dont think a CVS account has anything to do with this, there is anonymouse CVS access and I doubt a Ximian employee would have much difficulty getting a CVS account if he wanted it). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
On Sat, 26 Jul 2003, Michael Schumacher wrote: Date: Sat, 26 Jul 2003 03:04:12 +0200 (MEST) From: Michael Schumacher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer] tentative GIMP 2.0 release plans) Michael Schumacher writes: According to Tor Lillqvist, there was something missing from Pango 1.2.3 and fixed shortly after the release. BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier. Thanks. I've succeeded in building GIMP 1.3 on Win32 using these packages. Any chance of binaries for testing? And what compiler did you use (wondering if I'll be able to get gtk-wimp to work with the Gimp 1.3 on windows). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Sat, 26 Jul 2003, Carol Spears wrote: the archives are either completely broken or just severely delayed. ^ it is the 26 of July and the archive still does not show any messages for July. http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer try the url right above ^ that mail archives site, who knows where it came from, if i understand your problem correctly. carol That is very condescending, rude, and entirely unhelpful. I checked the archives several times this week and I also checked them before posting my previous message. I checked them again just now. July is still not listed. The search doesn't seem to work either Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On Sat, 26 Jul 2003, Patrick McFarland wrote: On 26-Jul-2003, Daniel Egger wrote: I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally. Wrong, Im an artist, and I prefer 1.3 over 1.2. One Swallow does not a summer make. Normal users in general abhor using anything labelled beta, consider your self extraordinary. The quality of most proprietary software has even caused users to distrust N.0 release and wait for the first or second service patch. If you can build from source then you are probably more developer than user anyway. While it is great that there are GIMP users willing to make the extra effort to use 1.3 I really hope to see GIMP being used by everyone else. The sooner we stamp out piracy of Adobe Photoshop the bettter :) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Summary of outstanding 1.3 bugs/featurerequests.
On Sat, 26 Jul 2003, David Neary wrote: I have been pretty brutal in chopping a bunch of enhancement requests today. What's left in the 1.3 milestone is a few bugs with patches outstanding and about 20 feature requests, most of whioch are claimed by someone or have patches outstanding. It would be a really big help if those in the know could please add the easy-fix keyword whenever they know a bug is easy to fix? A pointer the relevant file in the source code is always a huge help to those of us less familiar with the codebase (and that goes for any project). I dont know if Count Colours is anywhere in the list of bugs Dave mentioned but the ColorCube Analisys plugin effectively gives this functionality but unfortanately was only available for GIMP 1.2 on windows. This seems like it might be a relatively easy feature to get working but then again I dont really know, and it is probably one of the features that got bumped. - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On 28 Jul 2003, Daniel Egger wrote: Date: 28 Jul 2003 18:52:41 +0200 From: Daniel Egger [EMAIL PROTECTED] To: Joao S. O. Bueno [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] writing german online help Am Mon, 2003-07-28 um 17.47 schrieb Joao S. O. Bueno: In Portuguese, the current use is for a male article - and trying making it female would be pretty bizarre. As fa as I can recall, all computer prograns or aplications are refered as male here. But anyway, many words have their genders swapped between German and Portuguese anyway. I'm pretty confident that die GIMP (female) is wrong, it's either der GIMP (male) or das GIMP (no gender). I'd say it is das GIMP because the P stands for program which has no gender and for acronyms typically the last word determines the gender. However since no article is not a problem at all in most cases I'd rather go with this Foreign words generally use Das if i recall correctly. Does German have a translation or share the word for the other type of Gimp? :) -- Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
On Tue, 29 Jul 2003, Phil Harper wrote: The shape displayed is what's used to sample, that's not a question. Make it configurable doesn't seem like a good idea here. I guess most people will agree that a circle is the natural choice. I don't. The colorpicker ist quite handy to determine the average color in some area and a square is much more natural to handle. Also for a circle to be somewhat usable you'd have to take the in/out coverage of the pixels under the radius into account or you'll get disturbing results for small sizes. i would tend to agree, if i want an average for an area i will usually be after a square anyway, however, it would be good to have a checkbox to switch between circular and classic behaviour, i don't know how much of a concern this is but surely you should be keeping inline with what the installed userbase are used to and are happy working with more than pandering to the Photo$hop audience... I am inclined to believe that the different colour pickers are useful for different tasks and that it is worth while to include the various different colour pickers for the various different use cases. (Although it is entirely possible that you are not talking about exactly what I think you are talking about. Tired, need food.) -- Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
Welcome back. On 30 Jul 2003, Jay Cox wrote: RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into the users folder when it is launched for the first time. Single user systems will never miss the meg or two this takes. On multiuser systems the admins can prune the system brush library. You have a point, I dont much like the proposed solution though. The round brushes shipped with gimp should be editable. RECOMMENDATION: recreate the round brushes as .vbr brushes. New file formats to be discussed at Gimp Con [1], but recreating the Round brushes as standard brushes sounds good. While we are on brushes I am wondering what kind of information needs to be stored in a Brush file and why does it need a special file type of its own? RECOMMENDATION: Move aforementioned script-fu to the bottom the the main select menu. Do the same with to-pattern and to-image items? (Should probably rewrite the script-fus as native functions) (should the main select menu be renamed to selection???) Please dont. The Select Menu is for making a selection, not manipulating the contents of a selection. Once you have made a selection then the contents of a selection is an Object/Image/Layer and then actions get applied to it, the current image. It requires two key presses (shift and =/+) to zoom-in which is one of the most common operations that gets used. (this is on US keyboards) RECOMMENDATION: accept '=' and '+' to zoom in. http://bugzilla.gnome.org/show_bug.cgi?id=94910 Both + and = should work, with + being the default label. Anything else is just a nightmare for international users. I would prefer if GIMP used Ctrl++ Zoom In and Ctrl+- as the default labelled keybindings in the menus, as well as the above keybindings. Additionally setup mouse button shortcuts for zooming in and out. Perhaps ctrl-middle for zoom in, and ctrl-shift-middle for zoom out. This will keep peoples left hand on left side of the keyboard and their right hand on the mouse which is exactly where they belong. (is it a pita to have multiple keyboard shortcuts for the same item?) I dont know about old Unix three button mice, I expect more users have Wheel Mice instead so I really hope any changes you make wont adversly affect them (and me). Zooming with a Wheel Mouse should definately Ctrl+Wheel (up down == Zoom in out) users already expect this from other applications. Wheel should scroll the page up and down, and Shift+Wheel should Scroll sideways. I know Paint Shop Pro uses the Middle Click of a Wheel Mouse to Zoom In but I never considered trying to use it with a Shift/Ctrl modifier. Thats enough for now. I'll add the important stuff in here to bugzilla tomorrow. PS: I was skeptical at first, but I am happy with a 2.0 designation for the next release of gimp. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ [1] Snowballs chance in hell I'll be able to afford to go to GIMP Con, I only hope that people will take some notes and put up a short summary of some of what gets discussed. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
On Fri, 1 Aug 2003, Sven Neumann wrote: This functionality was recently added to Dia, you could probably take a look and substantially borrow the same code. GIMP zooms on Shift-wheel since some early 1.1 version. damn, another inconsistancy. so how do you scroll sideways (using the wheel)? is this the same keybinding as Photoshop? - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
On Mon, 4 Aug 2003, Simon Budig wrote: Date: Mon, 4 Aug 2003 00:51:13 +0200 From: Simon Budig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] A fresh pair of eyes. David Neary ([EMAIL PROTECTED]) wrote: The point, as I see it, is that there's no reason *not* to follow the leader when it comes to keybindings - it makes migration easier for people used to the other app, and makes your app more attractive as an alternative, without removing any functionality, or necessarily making things harder for experienced users. So if it costs nothing (or very little), why not? Uh, making all the long time GIMP users grumpy because the shortcuts they are used to use do no longer work and they have to reconfigure them to the old default costs nothing? You mean the existing GIMP users dont already have custom menurc files? You mean if we provided a GIMP 1.2 menurc for those who wanted it, our current users dont already know how to change a menurc? (we need an Inteface for this, and I need to make sure there is a bug report about it). You mean GIMP doesn't allow you to migrate your old settings when you upgrade to a new version? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
GimpCon Thanks [Re: [Gimp-developer] Third big serious meeting fromGIMPcon]
On Sat, 9 Aug 2003, Dave Neary wrote: Date: Sat, 9 Aug 2003 20:36:10 +0200 From: Dave Neary [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Gimp-developer] Third big serious meeting from GIMPcon Hi all, Here are the minutes of the meeting we had this afternoon, written up by Raphael. I want to say a big thank you to Dave, Raphael and anyone else who took the effort to record the proceeding for those of us who cannot be there. Keep up the good work. I expect these notes from Gimp Con will be similarly useful as a review for those of you who did make it. Hopefully someone will post links to these on the news page, and gnomedesktop.org when the talks are all finished. Sincerely. Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Ideas for Gimp/GEGL file format.
On Fri, 8 Aug 2003, [iso-8859-1] Øyvind Kolås wrote: Date: Fri, 8 Aug 2003 21:36:05 +0200 From: [iso-8859-1] Øyvind Kolås [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Ideas for Gimp/GEGL file format. Sven could you forward this to the list, my mailing possiblities from the camp is kind of braindead. What follows is a proposal for a format to save a GEGL processing graph and it's associated data. It is not completly thought through, but it could serve as a starting point. Since a GEGL processing graph is basically somethings that ties different kinds of data together and describes how they relate to each other, separate files seems like a good idea, the files should be bundled together either in an archive, or directory. As a baseline directory access should be supported, and some other archive format like tar or ar should be chosen. sounds good. it makes sense, a GIMP file is more like a project file than a merely final image format. Being able to use popular file formats directly as layers would probably be very useful to help prevent unnecessary decoding and reencoding of files. Gimp will eventually use GEGL for compositing images, it almost makes sense to define the format used as a GEGL format instead of a gimp format, by doing this applications using GEGL, will have an easy time importing and exporting processing graphs. Eventually, that worries me deeply however the idea of doing this through GEGL and having a clearly documented standardised file format that third parties can use, and more importantly would want to use sounds fantastic. some random ramblings follow,.. my favourite kind of ramblings :) a text layer?,.. (thats kind of easy with a text filter, font parameter, and text parameter).. seems wise. a vector layer?,.. could be just a vector filter,. taking a long list of coordinates,.. vectors in text files aren't very human readable anyways,.. seems very wise. ideally would use SVG for the XML backend to allow for better interoperability with other tools, ideally GIMP and Sodipodi will eventually play together even better than Adobe Photoshop and Illustrator. For expediency you might allow legacy gfig files to be embedded (and include the associated brush information for rending the line). i have been playing with gfig quite a lot and since noticing that you can tell gfig to render as a new layer instead of on top of the current layer I have not gone back (and i seriously think it would be a much better default). Given the limited undo stack in the GIMP, having it as a seperate layer makes it so much easier to remove the whole layer rather than to try and undo each and every stroke (although again because of the limited undo stack I have tried try to make my gfig stencils using as few continuous lines as possible). I wonder why gfig even has render to current layer, users could merge layers if they really wanted. Rendering each line to a seperate layer seems like overkill for simple drawings but for much more complicated drawings or if anyone was trying to turn a gfig drawing into an animation I see how it could be useful. Later Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XCF
On Fri, 15 Aug 2003, Tor Lillqvist wrote: Date: Fri, 15 Aug 2003 13:49:41 +0300 (EET DST) From: Tor Lillqvist [EMAIL PROTECTED] To: The Gimp Developers' list [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Portable XCF I won't take any stand on either side (or how many sides are there?) in the ongoing discussion, just air some fresh thoughts... Many of the image formats suggested are some kind of archive formats (zip, ar) on the outside. I understand that one important benefit from this is that you can store layers and whatnot objects as different files in the archive, and easily access them separately. Even with other tools like ar or unzip if need be. However, these formats have the drawback that even if you can easily have read access to just one of the component files in the archive, it is impossible to rewrite a component if its size has changed (well, at least if it has grown) without rewriting at least the rest of the archive. (Or, maybe leaving the old version of the component as garbage bits in the middle, appending the new version and updating the index, if that is estimated to be less expensive than rewriting.) For the XML files you can use whitespace padding, I was reading the Adobe XMP specifcations and they do this in some places. It is less than ideal but it is an option. The fact that others have already lead the way with these types of file formats means there is plenty of existing examples to learn from and solutions to potential pitfalls. Now, what concept do the ar, zip, etc formats closely resemble? What other thingie is it that you store files in? Yeah, file systems. Wouldn't it be neat to use a real file system inside the image file... I.e. the image file would be a self-contained file system, with the image components (layers, XML files, whatnot) as files. What file system would be good? I don't know. Presumably something as small and simple as possible, but not any simpler. Maybe FAT? ;-) Early V6 Unix style file system (but with longer file names)? Minix? Or something completely different? ISO9960 (I have no knowledge of this, it might be way too complex)? UDF? I am pretty sure you can have a Zip Filesytem. (I found a request for similar on the linux kernel mailing list but having difficulty finding something more substantial). Hopefully someone who knows more about Zip or virtual filesystems can provide more substantial information. I recall mumblings about Gnome doing away with the need for programs like the predecessors of File-Roller and having Gnome-vfs sort it out and use Nautilus instead. This looks more promising http://www.hwaci.com/sw/tobe/zvfs.html http://webs.demasiado.com/freakpascal/zfs.htm hopefully someone else will come up with better links. One neat benefit would be that on some operating systems it would be possible to actually mount the image file as a file system... Zip is already in wide use and as it is more popular it is therefore more likely to be available as a filesystem if it is not already available than an 'ar' based solution. To change the subject slightly the adhoc name 'Portable XCF' might be a bit misleading. Portable implies web formats and I think that PNG/MNG/JNG and others largely have this area covered and that the next genertion XCF will needt to many things and hold a fair bit of raw data and be reasonably fast which goes against being a web ready portable format (or at least makes it a low priority). At this early stage hopefully no one will get too attached to any particular name and that can be left until later. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro8
On Sat, 16 Aug 2003, Phil Harper wrote: Date: Sat, 16 Aug 2003 14:15:08 + From: Phil Harper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro 8 From: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) To: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro 8 Date: Sat, 16 Aug 2003 14:23:57 +0200 On Sat, Aug 16, 2003 at 01:21:05PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: (Keep in mind that users might be using text sizes larger than the defaults so static widget layouts are a really bad idea). In general all GIMP dialogs can be maximized and widgets reflow as you described. What are you talking about? File-New is the exception (it's fixed-size), but that's the only dialog I could come up with that has this problem. Because that's the dialog most often perceived as dialog, maybe he was assuming all others are the same? hmmm, yes, it does make you wander if he's ever used the GIMP if he's making such suggestions... That was incredibly rude and entirely uncalled for. - Alan /me resisting the urge to say more ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro 8
On Sat, 16 Aug 2003, Sven Neumann wrote: I was playing around in Paint Shop Pro trying to see what it does well and what caught my interest today was that in seemingly every dialog window you are able to maximise the window unlike standard dialogs where this functionality is usually disabled/greyed out. This is more useful than it sounds, take for example the File Open Dialog. If you maximise the window the widgets reflow and the space with the document list exands to fit the avialable space (and I think the preview box expands too, but I dont have it in front of me right now). If the GIMP was to consider this feature would it require a whole lot of work to make sure the dialogs reflowed properly when maximised? (Keep in mind that users might be using text sizes larger than the defaults so static widget layouts are a really bad idea). In general all GIMP dialogs can be maximized and widgets reflow as you described. What are you talking about? Sorry I took so long to reply, thank you for replying to my original question. I took a much closer more careful look at the GIMP 1.3.x on RedHat and the short answer is yes most widgets do reflow as stated. I'm quite impressed actually, with the glaring excepting of Gfig most dialogs do resize as they should. The problem is that to resize the windows you need to grab the window edge and drag, so this useful and worthwhile feature is wasted. If a window can be resized then it really should have the Maximise Window decoration (with the rare exception of a few message dialogs). (Similarly you there should probably be a minimise icon for any of the non modal dialogs). By the relatively simple step of making sure the maximize window decoration is shown we can make this useful feature much more convenient to use and easier to discover for new and old GIMP users. I am using Gimp 1.3.x on RedHat 9 with is Gnome 2, the default Gnome 2 window mangager Metacity, and I have not ruled out the unlikely possibility that this is the fault of metacity. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ PS You can ignore this next bit if you already understand what I mean. I went to the trouble of writing these notes earlier and I feel I may as well paste them here. RedHat 9 (Gnome 2, using the default Gnome window manager, Metacity). Dialogs that dont resize New Dialog but not much point in making it resizable Open Dialog does resize, so why doesn't it have the maximize window decoration? Save does resize, so why doesn't it have the maximize window decoration? Save As does resize, so why doesn't it have the maximize window decoration? Send to Mail reflows, should have maximize window decoration but doesn't Layers Dialog reflows and resizes, but still no window decoration. Gfig does not resize. The only way to resize gfig is to start gfig with a differnt size of image. The ImageMap plugin is one of the Few plugins that does actually have a the Minimize and Maximise window decorations. To make it explicitly clear: Any window that can be resized, should have a maximise window decoration. (Caveat: Almost any). Since people have gone to the trouble of programming these Graphical User Inteface for these items so well it should be made both explicitly clear and obvious to users as well as easy to use this feature. Why hide away useful features that actually make things easier and more powerful? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Manners.
On Sun, 17 Aug 2003, Carol Spears wrote: Date: Sun, 17 Aug 2003 09:41:49 -0400 From: Carol Spears [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Manners. Adam D. Moss wrote: Guys and gals, Would people please simply think a bit about the tone of their emails before posting? It seems that gimp-developer is increasingly perceived as a hostile, rude, or elitist mailing list, and some small effort on the part of posters would help to alleviate this enormously. Making GIMP's development communication environment more friendly is the key first step to winning more developers. (IMO #gimp has largely lost the battle already, and I'd hate to see the mailing list fall.) Conversely, it would help if people were also slower to take offense. :) It's easy to forget that many if not most of the people here are not native English speakers and might not be able to easily gauge how antagonistic their posts consistantly sound (I've met some of the worse offenders and they're generally not at all antagonistic people :)). Kind regards, --Adam i dunno, this is sort of what keeps me reading it. saying that people are clueless merely because their area of interst or expertise does not match yours is not good. give people some benefit of the doubt. users may make reactionary complaints such as that things are not the same as photoshop or other complaints. they may be wrong but calmly explaininig why things are done different or pointing out that the project is run by volunteers and something a little more polite than 'you get what you pay for' will have the same result. I may not explain things well but if asked to explain further I will do my best. Calling me clueless is not funny, nor is it true I have used the GIMP more than any other Open source application I can think of (thanks Tor for the windows port) and it was a big factor in my using open source software. aside from mspaint i cannot think of an image editing program I have used more than the GIMP. this list has been rude, over-reactive and jumpy for a very long time. gimp also works really well, for the most part. Adam: define rude. disagreement is fine, disagreeing without some how backing up your point of view is usually just unhelpful noise, unhelpful criticism. I often forget that most of you dont have English as your first language and will try and keep that in mind in future. Notice that despite my being very annoyed rather than flaming back and criticising his spelling :P i pointed out that I was offended and tried to leave it at that. The problem is that if someone gets a harsh reaction on their first post they wont stick around to find out that it was a joke or that no offence was intended. The GIMP is too important to the community for me not to at least try to do something about the problems I see. We are all strangers, despite the level of familiarity email and the internet provides it helps to keep that in mind Sincerely Alan Horkan. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro 8
On Sun, 17 Aug 2003, Sven Neumann wrote: Date: Sun, 17 Aug 2003 19:25:54 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint Shop Pro 8 Hi, On Sun, 2003-08-17 at 19:05, Alan Horkan wrote: The problem is that to resize the windows you need to grab the window edge and drag, so this useful and worthwhile feature is wasted. If a window can be resized then it really should have the Maximise Window decoration (with the rare exception of a few message dialogs). (Similarly you there should probably be a minimise icon for any of the non modal dialogs). We certainly don't fiddle with the window decorations. It's entirely the fault of your WM. Bet you Five Euro Havoc Pennington will disagree and that the GIMP should be setting additional hints or suchlike. The ImageMap plugin has the a maximise window decoration but very few other windows do, so even if it is the Window managers fault the GIMP will have some blame to shoulder too. I think there is a distinction between a dialog and a normal window that is not clearly defined somewhere. I'll try and find a solution to this as you clearly dont have a problem with the principle and it would shame to have a useful feature going to waste because users fail to realise it is there. I'll probalby file a bug report to keep track and help me remember. I'll assign it to myself, please dont close it invalid until I can properly verify that the problem is not with the GIMP. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, 19 Aug 2003, Daniel Rogers wrote: Date: Tue, 19 Aug 2003 08:00:55 -0700 From: Daniel Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] [EMAIL PROTECTED] spam getting a little out of hand -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone else noticed how the [EMAIL PROTECTED] spam is getting a little out of hand? perhaps now would be a good time to change that address. Banning attachments and HTML email might be a tolerable compromise. At worst any real people sending to bugs will know to resend or use http://bugzilla.gnome.org instead if they are unwilling or unable to not send as HTML. Just a suggestion to consider, feel free to kill the address if you prefer. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fun with Adobe forums
On Tue, 26 Aug 2003, Joao S. O. Bueno wrote: So, did you guys know that Disney considered using the GIMP and/or Cinepaint, but instead paid some coders to make sure PS runs in WINE? http://www.eweek.com/article2/0,3959,1210083,00.asp Yup. When this was on Slashdot I did mention at least in a PS at the end of one of my mails. /me thinks of searching the archive but is the archive working again? will the alternative link suggested be up to date (last time I looked it was lagging by a few days) ... but anyway I am logged in on a console, so I'll skip finding a link this time. I saw this over on slashdot. And when I commented there something about preferring to see th GIMP, if not for anything else, for the free-software question, I got some 15 replies flaming me all over. 1) You will probably get flamed no matter what you say on Slashdot, although I am would be interested to read exactly what you wrote. 2) Gimp and CinePaint were incidental to the article, the big deal was that Disney *EVIL* actually spent some money and helped improve WINE *GOOD* (although some looonatics object to WINE on a twisted notion that compatability with legacy applications is a bad idea). 3) They probably only evaluated GIMP 1.2, and even though GIMP 1.3 is a lot better I dont think any of you will deny there is 'room for improvement' 4) Although there are some tradeoffs CinePaint better fills the niche for a movie studio, higher colour depth and support for file formats such as OpenEXR are important. 5) Adobe Photoshop users, particularly proffesional artists love Adobe Photoshop. Price is not really an issue when the company is paying (up to a point, companies will eventually draw the line (no pun intended)) GIMP/CinePaint needs to be more than just as good, it needs to be significantly better for that kind of specialist user to make the effort to change. The killer feature(s) in the GIMP is freedom, and so cheap it is free. Proffessionals who depend on Adobe Photoshop are probably the last people that will convert to the GIMP. The value they place on Photoshop is not just the box price, it is the years of time and effort invested into learning it inside out and more. However after saying all that a whole lot could have been done to improve the GIMP or (and you are not going to like me for saying this) more likely CinePaint, with the hefty amount of money that Disney was willing to spend on this project. Perhaps if Adobe Photoshop 8 fails to maintain WINE compatibility they will look this way again. Has anyone mailed the man at Disney yet? I probably will, and encourage him to provide feedback, hopefully with a little more detail than just make it more like Photoshop. He seems to be in some way affiliated with CinePaint already (I forget his name but I looked it up when the article was first mentioned). - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fun with Adobe forums
On Wed, 27 Aug 2003, Joao S. O. Bueno wrote: So, did you guys know that Disney considered using the GIMP and/or Cinepaint, but instead paid some coders to make sure PS runs in WINE? http://www.eweek.com/article2/0,3959,1210083,00.asp I am finding out that trying to defend free software brigns more flames and bad moderation than other subjects. :-) I will try to find my post and paste it at the end of this message. 4) Although there are some tradeoffs CinePaint better fills the niche for a movie studio, higher colour depth and support for file formats such as OpenEXR are important. Dunno. The only cinepaint I had seen was called filmgimp Well now they call it CinePaint, which better distinguishes the niche it is trying to fill. I believe there is an important place for CinePaint, and that its clear focus is admirable. I can only hope that in future some compatibility can be regained and become more like different parts of the same family, if you'll forgive the comparision more like Adobe Photoshop Elements is to Adobe Image Ready. 5) Adobe Photoshop users, particularly proffesional artists love Adobe Photoshop. Price is not really an issue when the company is paying (up to a point, companies will eventually draw the line (no pun intended)) GIMP/CinePaint needs to be more than just as good, it needs to be significantly better for that kind of specialist user to make the effort to change. The killer feature(s) in the GIMP is freedom, and so cheap it is free. Proffessionals who depend on Adobe Photoshop are probably the last people that will convert to the GIMP. The value they place on Photoshop is not just the box price, it is the years of time and effort invested into learning it inside out and more. Actually, one of the many replies pointed to this: Disney, better, the departament that went Wine/photoshop, actually tried pushing GIMP or CinePaint, but got a big No from the artists. That means you are completely right, Alan. I can only hope that the developers will consider copying Photoshop more often unless there are particularly good reasons to do otherwise. My post on /. on this subject was: (I am Pope Raymond Lama there) Re:Disney supporting open-source? (Score:*, Insightful) by Pope Raymond Lama (57277) on Tue Aug 05, '03 12:25 PM (#6616021) (http://www.geocities.com/gwidion23) No. Disney non-supporting Open Source, as it has always been. supporting Wine, is supporting open source. it would of course be more forward looking to support the Gimp rather than a back-compatibility layer, but I am pleasantly surprised if Disney makes any contribution at all to open source or free software. Now, instead of using, and helping improving The GIMP, linux people will just run their pirated Photoshops and be happy, as oftenly such users do not know the difference between free and proprietary software. I might have moderated that Funny, although it was more likely to be considered harsh. People take accusations of 'piracy' (unlicensed use) of software personally, guilty conscience methinks. I also really doubt that someone would go to all the trouble of running Linux, and Wine to pirate Photoshop on Linux instead of taking the easy option and just using Windows. Usually on slashdot people say it differently more silly like free software, what do you mean it is not free, I downloaded it off the internet In reply to: Disney supporting open-source? (Score:5, Funny) by Prince_Ali (614163) on Tue Aug 05, '03 12:13 PM (#6615846) (Last Journal: Sun Oct 27, '02 05:19 PM) I can feel the slashdotters' brains explode with conflict. -- Money follows votes; it does not buy votes. Two legs better! I have learned to expect little intelligent feedback from slashdot, there are a few exceptions but they only prove the rule that most of Slashdot is utter dross and not worth reading at below Score:4 or 5. The GIMP user and developers lists is one of the few places where you are most likely to get well thought out feedback on the GIMP. Everywhere else you will probably get flamed, although I expect there will be some really positive feedback when Gimp 2.0 is released (much more than any criticism over the number jump). Later Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
On 1 Sep 2003, Willie Sippel wrote: Date: 01 Sep 2003 20:09:23 +0200 From: Willie Sippel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] Gimp interface streamlining Hi there. First post, so please go easy on me ;-). Also Gimp always gets better and more powerful, the interface still needs a lot of work. It almost looks like yet another Photoshop clone - I really dont think GIMP looks at all like Photoshop although ... and even if Photoshop is some sort of de facto standard, it's interface is pretty clumsy and inefficient. ... I agree Photoshop is far from perfect either. 1.) Remove unnecessary buttons from the main toolbox to reduce clutter: Smudge, Dodge or Burn, Blur or Sharpen, Erase, Zoom, Color Picker; I also would love for the toolbox to be customizable http://bugzilla.gnome.org/show_bug.cgi?id=105764 but comletely removing the buttons as you suggest without anyway to add them back will likely displease many different people depending on which features they happen to use, personally I would miss the Zoom button. It might also be worth considering better to do like Photoshop and Sodipodi and have button submenus, that when you click and hold you get more of the related items. Screenshot of Adobe Photoshop toolbox submenu http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/screenshots/photoshop/AdobePhotoshop-clicknhold.png shorter link to Photoshop screenshot http://tardis.linux.ie/1653/matrix.netsoc.tcd.ie 5.) The Color Picker should become available when you click the foreground or background color in the main toolbar, and should set the respective color (set foreground when you clicked the foreground color); This is already the case in GIMP 1.2, just double click on it. 6.) Add 'Alpha' to the Color Picker; Consider carefully if the more user friendly term Transparency should be used. 8.) Remove the giant FG/ BG preview at the bottom of the 'Colors' window to make the interface more compact; There is an option to hide the brush+pattern preview, an additional option to hide the colours widget might be an acceptable idea (but there is always the matter of getting some one to write the needed code). 9.) The remaining buttons on the main toolbox should be reordered: Brush | Pen | Airbrush | Ink | Text | Fill | Select | Transform | Create paths | Measure tools care to explain your reasoning for this reordering? 15.) Remove the brush and pattern preview from the main toolbox, because it clutters the toolbox - it's redundant, anyway, because there is allready a preview in the tool settings window. It might be even better to also remove the pattern preview from the tool settings and show the selected pattern on the color preview of the main toolbox; There is already a preference to remove it. Toolbox, File, Preferences... Interface, [] Display Brush, Pattern and Gradient Indicators. 16.) The color preview on the main toolbox should be redesigned: some paint programs have differnt designs, some even allow you to choose which design you like best but I dont understand what is wrong with the current design, please explain why your suggestion is better. Some other small suggestions, as well as many of the described suggestions are on the mock-up, http://www.zeitgeistmedia.net/gimp/gimpstreamline.png Suggestions and comments are very welcome and appreciated. It is great that you took the time to thnk about how to improve the GIMP but keep in mind that you suggested a whole lot of changes that could take a long time to get done iff there is a developer interested in making the changes you suggest. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
On Wed, 3 Sep 2003, Joao S. O. Bueno wrote: Let's check your ideias. One thing, from reafdign your e-mail I guess you are using 1.2 GIMP series. A lot of what you comment has changed to the 1.3 series. To be fair from his screenshot he is clearly using some version of 1.3 http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png Sincerely Alan Horkan http://matrix.netsoc.tcd.ie/~horkana/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshot plug-in status
On 11 Sep 2003, Sven Neumann wrote: Date: 11 Sep 2003 02:04:24 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Michael Schumacher [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Screenshot plug-in status Hi, Michael Schumacher [EMAIL PROTECTED] writes: While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user. Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP. Perhaps you should use GNOME then ;) I do use Gnome, just not all the time. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Apple has no Delete Key [Re: [Gimp-developer] Gimp interface streamlining]
On Fri, 12 Sep 2003, Daniel Egger wrote: Date: Fri, 12 Sep 2003 12:20:13 +0200 From: Daniel Egger [EMAIL PROTECTED] To: Gimp Developer [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Gimp interface streamlining Am Fre, 2003-09-12 um 11.25 schrieb Simon Budig: It would be nice to have more keys available to the tools. I'd love to get the Del-Key working for deletion of nodes in the path tool... The del key is a bad choice. Quite a few GIMP users have Apple machines which don't have a del key. I think Apple is exceptional in that regard and didn't they put some of the keys back in the later iMac designs? Delete is such a particularly good and obvious keybinding for Deleting things with on other platforms couldn't we use delete as well as another keybinding for the benifit of Mac users? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Apple has no Delete Key [Re: [Gimp-developer] Gimp interface streamlining]
On Sat, 13 Sep 2003, Marco Wessel wrote: snip It is true that the Apple keyboards that used to come with the iMacs, B/W G3s and G4s don't have a del key. However, this keyboard has long since been replaced with the full-sized keyboard, which does have the key. As does every older mac keyboard in existence, save the PowerBook keyboards. Simply put, most people should have the key. However, how about using backspace, which IMO is more intuitive for deleting things. (Though it could be used by something else, I'm not entirely sure.) Backspace is used to clear a dynamic a dynamic menu keybinding. (Not to rule out the possibility of that specific context being made properly isolated to allow use of Backspace else where). sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Berkeley, Bug Isolation Project
I had not seen this mentioned on the developer list, so sorry in advance if you already knew about it. The bug isolation project is an effort to track crashes but also to track user behaviour and help figure out how to make software better. http://www.cs.berkeley.edu/~liblit/sampler/ There is a sampler program for the tracking as well as special builds of open source softare including the GIMP 1.3.20 on their download page http://www.cs.berkeley.edu/~liblit/sampler/downloads/ Their contact page also has detials of their mailing lists http://www.cs.berkeley.edu/~liblit/sampler/contact.html Anyway, I just thought it might be of interest and I hope to try it out myself soon. Sincerley Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
On Tue, 23 Sep 2003, David Neary wrote: Henrik Brix Andersen wrote: According to http://registry.gimp.org/changes?max=15 the last change to a plug-in was done only a couple of days ago - so it seems the registry works at least for some people. Perhaps, but there are several things which should be possible which aren't. First, the majority of the plug-ins in the registry appear to be abandonware - 1.0 plug-ins that have never been updates to 1.2, never mind 1.3/2.0. We need a way to clean out the cruft (or at least hide it away). Second, the registry could do with a ranking system to have the most common and/or popular plug-ins appearing on the top of the lists of plug-ins. The only sorting system I've seen is alphabetically, which severely limits the usefullness of the site. Third, it is not possible to attach patches for existing plug-ins to a plug-in without being a plug-in maintainer. It would be nice if this were easier to do, perhaps with a comment system? Although I guess an inscription system makes some sense... This functionality sounds a lot like MozDev, which has a very useful list of active projects, or Sourceforge (or Gnu/Savannah/Whatever). Changing to a full blown project management system might make things easier to manage in the long run. Something to consider at least. - Alan H ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mailing list archive out of date
On Thu, 25 Sep 2003, Tino Schwarze wrote: Date: Thu, 25 Sep 2003 13:54:47 +0200 From: Tino Schwarze [EMAIL PROTECTED] To: Gimp Hackers [EMAIL PROTECTED] Subject: [Gimp-developer] Mailing list archive out of date Hi there, I just tried to figure out where to get Windows binaries for 1.3.=19 and couldn't find any. So I tried to search the archives. The archive is a) out of date (last message from July 26) There is another archive for the developer list here http://www.mail-archive.com/[EMAIL PROTECTED]/maillist.html There is a windows gimp users list at yahoo and they also have a list archive there too and I know that Tor (aka tml) announced binaries of 1.3.20 for testing there last week. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
On Sat, 17 Jan 2004, Marc wrote: Date: Sat, 17 Jan 2004 20:22:05 +0100 From: Marc [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: Alternative zoom algorithm On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Get used to it, that's how gimp-developer works :( Marc, your comment is highly inappropriate. Eh, really? Yes, maybe I should have said that's how gimp developers work, which would be more approriate. I commend Sven for his diplomacy. I am very pleased by Simons explanation. This may have been the way some of the GIMP developers have worked in the past but I hope that in future the GIMP developers will do just like Simon has done and explain his criticism in a fair and clear manner so that no one will have reason to get offended. I think that more developers will be attracted to the GIMP if they are forgiven for impatient mistakes and the over enthusiasm of beginners and not knowing how things work around here but are given the chance to learn. Sincerely Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. Every reference I've ever seen to MDI refers to window in window. I don't understand the purpose of that at all (and I happen to really detest it, in any event, since it wastes a lot of screen space). When using the GIMP I prefer to have the document window maximized. On windows this means that the Toolbox will get pushed behind and it is extremely awkward and I believe this is a significant part of the problem that most users want solved. Something as simple as an always on top option for the toolbox might be enough to make things easier for users like me who occasionally use crappy window managers. Speaking of maxmising the avialable workspace and it does seem to be of interst to more users than just me (I love the fullscreen mode by the way and) is there any way to hide the scrollbars? I would like to be able to get rid of the scrollbars and use keys for scrolling* up and down the page or alternatively use the overview/navigation widget. [the following bug is asking for the ability to use specific keys for scrolling, currently there doesn't seem to be ANY way to assign ANY keys at all to scrolling http://bugzilla.gnome.org/show_bug.cgi?id=53988 ] Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
On Fri, 6 Feb 2004, Sven Neumann wrote: Date: 06 Feb 2004 11:50:54 +0100 From: Sven Neumann [EMAIL PROTECTED] To: David Neary [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one) Hi, David Neary [EMAIL PROTECTED] writes: You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags. Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do If you _asked_ people might post the news but unless you asked for others to do it then I would assume that you wanted to do it yourself and have it done your way. And I'm on the list digest so I usually read the announcement on GnomeDesktop.org before I read it on the list. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Last day for abstracts
On Mon, 16 Feb 2004, Carol Spears wrote: Date: Mon, 16 Feb 2004 06:49:06 -0800 From: Carol Spears [EMAIL PROTECTED] To: Dave Neary [EMAIL PROTECTED], GIMPDev [EMAIL PROTECTED] Subject: [Gimp-developer] Re: Last day for abstracts it is going to be a tough act to follow robin rowe and cinepaint. gimp-1.0 rox! carol Carol I know you are funny sometimes but we all know Robin reads this list and such comments dont help anyone. Can't we all just get along? Barney the purple dinosaur says Lets be fwiends? - Alan H ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Re : Fwd : Re : Re : [Gimp-developer] splash pictur [jean-luc.coulon@wanadoo.fr]
On Sat, 13 Mar 2004, Jean-Luc Coulon (f5ibh) wrote: Date: Sat, 13 Mar 2004 16:42:37 +0100 From: Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [iso-8859-1] Re : Fwd : Re : Re[iso-8859-1] : [Gimp-developer[iso-8859-1] ] splash pictur [EMAIL PROTECTED] Hi Sven, Le 13.03.2004 16:20, Sven Neumann a écrit : Hi, Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED] writes: I don't think my font size is so huge ;-) Well, your font isn't that huge but you've choosen a very wide font. It's of course up to you, but you will be suffering from this problem in all dialogs. I suggest you don't use an oblique font for your desktop. I've always been told that for localisation reasons you have always have to leave extra space anyway, most noteably up to 2/3 extra for the talkative Germans (I think that is the usual figure that gest mentioned but dont quote me on it). For accessibility reasons space for larger fonts would be also be needed. I think it would be an interesting change if the GIMP had splash screen that was Landscape, but that it really up to Jimmac of course but it would help cover up this glitch. While we are speaking of splash screen a 3:2 ratio or 4:3 ratio or magic number ratio rectangle instead of a square shape would looks even better, but it is a matter of taste ;-) aha! but do you try and anticipate the size of the status bar, window and window decorations and attempt to have it so that the overall ratio is 3:2/4:3 or do you just do it for the image? (consider that a rhetorical question). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ PS How are the Splash and About images still PPM format* because I was wondering why they aren't in a smaller format like PNG? (* I dont have the latest copy of GIMP 2.0 handy otherwise I'd check) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Re: Re: Fwd: Re: Re: [Gimp-developer] splash pictur [jean-luc.coulon@wanadoo.fr]
On Sun, 14 Mar 2004, Sven Neumann wrote: Date: 14 Mar 2004 02:31:43 +0100 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [utf-8] Re: Re : Fwd : [utf-8] Re : Re : [Gimp[utf-8] -developer] spl[utf-8] ash pictur [jea[utf-8] [EMAIL PROTECTED] nadoo.fr] Hi, Alan Horkan [EMAIL PROTECTED] writes: PS How are the Splash and About images still PPM format* because I was wondering why they aren't in a smaller format like PNG? (* I dont have the latest copy of GIMP 2.0 handy otherwise I'd check) Please get a recent copy then or refrain from commenting on our code. These files are PNG for more than 2 years now. You could have downloaded a new version in the meantime. I have previously used the GIMP 1.3.x builds but I just didn't have a copy conveniently in front of me that I could check against. So it was a dumb question. Of course we know about the problems that l10n can introduce. I phrased the comment about localisation poorly, I realise it doesn't read well and of course I wasn't suggesting you dont know about localisation. However the solution to this problem is not to add some arbitrary extra space but to adjust either the widget or the font size dynamically. Adjusting thing dynamically was the problem! The minimum size for the widget wasn't big enough so it kept resizing and that resizing was the annoying glitch in question. Usually the widget is adjusted but for the about dialog we adjust the font size and I consider to do the same for the splash. I dont know why distributions that support startup notification dont just disable the splash screen since they dont have any technical reason for having it. I'll just disable the splash sceen on my machine and not mention it again. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp2 on a 486
so, you decide if i am a troll or not and be my guest -- delete the mails or even better yet tell your spam filter about me. spam filters are no use for blocking people if you use the mailing list digest. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Press pack
On Sun, 21 Mar 2004, Branko Collin wrote: Date: Sun, 21 Mar 2004 14:22:08 +0100 From: Branko Collin [EMAIL PROTECTED] To: Gimp Developer [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Press pack On 21 Mar 2004, at 19:17, Jakub Steiner wrote: I made a couple of demos of the new GIMP 2 functionality. I believe it works a lot better than just a list of new functionality. They are divx avis and it's approx 80MB. Feel free to mirror it on the gimp.org website and use it for the 2.0 release extravaganza. http://jimmac.musichall.cz/gimp2demos.php I have tried to play these demos using Windows Media Player (Microsoft) version 2, 7 and 9, and in all instances it crashed my mediaplayer. The error messages says something about a divx module; probably just the decoder I am using. Still, it would perhaps be handy to test this on other Windows installations if this URL is going to be sent to any other than GNU/Linux using journalists. If the video needs to be recoded may I humbly recommend using Xvid. http://www.xvid.org (although perhaps you are already using it merely referring to it as DivX for convenience) It is almost at 1.0, in the prerelease/release candidate stages at the moment. It is a proper open source MPEG 4 implementation. - Alan H ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The issue of JPEG Patents?
On Fri, 23 Apr 2004, Daniel Rogers wrote: Date: Fri, 23 Apr 2004 22:47:49 -0700 From: Daniel Rogers [EMAIL PROTECTED] To: Joao S. O. Bueno [EMAIL PROTECTED] Cc: Alan Horkan [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] The issue of JPEG Patents? Joao S. O. Bueno wrote: On Friday 23 April 2004 18:39, Alan Horkan wrote: http://www.theregister.co.uk/2004/04/23/forgent_jpeg_suit/ Has the issue of Jpeg Patents been brought up yet? (a quick but not thorough search suggests not) hmmm...What about waiting until october, and THEM start the Gimp Foundation? You can't sue what does not exist Honestly...I got scared for the GIMP when I read about the thou shalt not open scanned-up money images blurbs ... when I read about this JPEG patents, I did not even thought about the GIMP, because it's just too stupid. But..who knows where human greed can take us? Well you could still sue the plugin maintainer. but that is no point. It is greed drivin, thus there is a second, implict rule, thou shall not sue that which has no money. I was thinking that Jpeg support might have to be preemptively removed like Gif support was removed. (Although the Gif patents have expired in America and will expire in Europe in June) On reading more, some comments suggest that this issue might not be specific enough to effect the Gimp but then I always believed Gif could have been included in the Gimp if parts of the Gif compression had been disabled but these issues are always more complicated than they seem. http://slashdot.org/comments.pl?sid=105099cid=8948562 - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image Info Dialog
On Tue, 27 Apr 2004, Dave Neary wrote: Date: Tue, 27 Apr 2004 11:42:33 +0200 From: Dave Neary [EMAIL PROTECTED] To: Carol Spears [EMAIL PROTECTED] Cc: GIMPDev [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Image Info Dialog Hi, Carol Spears wrote: since day one with the gimp, everytime i want to get the info dialog i first search the Image Menu. my reasoning is Image --Info. i am really not thinking of viewing anything, more like knowing I always though of 'File, Properties' (or 'File, Get Info' because there is lots of kinds of file metadata, not specifcally related to the image drawable. This is a reasonable suggestion. Out of interest, are there other menu items that people would like to see elsewhere? This is not very difficult to do, but there has not (yet) been a I very much want menus in other places. I filed this bug less than two weeks ago and it was rejected. http://bugzilla.gnome.org/show_bug.cgi?id=140439 I'm convinced that there will always be people who want menus in different places and that runtime customizable menus will eventually be needed. (It doesn't seem possible to have menus that will be comfortable for longterm Gimp, Adobe Photoshop, Corel Painter or Macromedia Fireworks users). If the improvements to Script-Fu allow scripts to exactly place menu items (this seemed to be part of the plan) and assign shortcuts (but this wasn't mentioned) I will at least be able to use scripts to put some features exactly where I would like them to be. (It doesn't seem to be posible to use Script-Fu to add seperators either, I just get a menu item labelled ---). proposition on where to put menu entries. ... so many things I'd like to mover around I wont even start to list them. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image Info Dialog
On Tue, 27 Apr 2004, Carol Spears wrote: Carol Spears wrote: since day one with the gimp, everytime i want to get the info dialog i first search the Image Menu. my reasoning is Image --Info. i am really not thinking of viewing anything, more like knowing I always though of 'File, Properties' (or 'File, Get Info' because there is lots of kinds of file metadata, not specifcally related to the image drawable. i can see the logic of File --Info i just never thought that way myself. i always want Image Info, and the truth is, this dialog is so limited that it is still quicker to get the scale tool and pop up the scale dialog to get the width and height information which is usually what i am looking for. crap, i am working so much on web pages with my wysmythingie (mozilla) that it is actually (truthfully) quicker to right click on the image and load that into the web browser for the height and width information. I've gotten into the habit of hovering over the bottom right corner and rounding up to figure out the image size. I'm thinking if we are both finding it a little bit awkward to quickly know the image dimensions then it is unlikely that we are the only ones and that it would be something worth improving. Perhaps additional information in the status bar messages showing the selection dimensions and offsets would work? (Shown as a standard transient message, I am definately not advocating permanently grabbing a chunk of the statusbar.) I think, I hope something non-intrusive and relatively trivial could be done to make things a little bit easier, ideas? Should I file a request for enhancement? - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
This dialog is still available but it isn't any longer bound to the By Color Select Tool. Choose Selection Editor from the Dialogs menu. Move the 'Fill' and 'Stroke' functions to the 'Selection' menu. I don't think these belong there since they do not manipulate the Selection. Where do other apps put Fill? IMHO it belongs into the Edit menu and I am surprised that the users didn't look for it there. Fill and Stroke definately don't belong in the Selection menu (you could be filling or stroking a Path not just a selection). The Select menu keeps the selection options nicely seperate from manipulating the image (or drawable ie the contents of the selection). Although there was a problem adding things to Select menu does not seem like the right solution and it was one of the few suggestions in the report I strong disagreed with. The suggestions to provide much more information in the status bar (like the way Inkscape does) sounded like a good idea but would probably be rather time consuming work. Adobe Illustrator uses Edit, Stroke and Edit, Fill... (just one item for Fill which pops up a dialog with lots of options and fill types of all kinds). Photoshop also has Layer, Filled Layer (or similar) which allows you to choose a texture/pattern and inserts a new layer with that fill. I dont recall Jasc having any extra fill options besides using the bucket tool (and I double checked by looking at various sites including this one http://moonsdesigns.com/tutorials/psp8/tools.html ) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Re: Blur plug-in
On Mon, 7 Jun 2004, GSR - FR wrote: Date: Mon, 7 Jun 2004 15:10:30 +0200 From: GSR - FR [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [Gimp-user] Re: Blur plug-in [EMAIL PROTECTED] (2004-06-07 at 1149.52 +0200): The plan is to remove the randomize and repeat functionality. That would allow us to also remove the (quite confusing) dialog. Filters-Blur-Blur would then be a simple blur with a 3x3 convolution kernel. It would be fast and easy to use but of course we it would be less powerful. So the question is, is anyone actually using this functionality? Are there scripts out there that rely on plug-in-blur-randomize to be available? Why not just ditch it completly then? If it just a 3x3 convolution that you have to manually repeat, and there are already other filters and scripts that do the same. The point of repeat is not having to rerun manually to get a bigger radius blur. If there was a more convenient way to save a 3x3 convolution matrix than having to write a script-fu script around the convulotion matrix plugin then there would not be any reason to keep the blur plugin but at the moment manually typing in a convulation matrix gets really annoying really fast. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] a few script-fu
I've been doing some scripting http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/script-fu.html and I'd like to return my scripts for inclusion in the Gimp. New File Dialog is poweful and flexible and makes it easy to create new images, it is better to have script work off the current image if possible, than trying to reinvent the new file dialog inside a script. I have changed Camouflage and SwirlTile to work off the current image (they are added to the menu at Filters/Render/Patterns/ although I'd prefer if they weren't so deep but hopefully the menu reorganisation will allow the menu structure to be flatter). Direct links to my Camouflage and Swirl Tile scripts http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/camouflage.scm http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/pattern-tileable-tempest.scm I have also worked on the round-selection script-fu, the most notable change is that it can now do concave as well as convex edges. http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/selection-rounded-rectangle.scm Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Scheme [was Re: [Gimp-developer] OSCon attendance]
On Thu, 15 Jul 2004, Markus Triska wrote: Date: Thu, 15 Jul 2004 18:52:36 + From: Markus Triska [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Scheme [was Re: [Gimp-developer] OSCon attendance] On Thursday 15 July 2004 02:25 pm, Shlomi Fish wrote: Each of the nominated projects is very good (see Dave's post for some details about the GIMP). The Arch - GIMP relation was a joke, if you don't mind. The fact remains that Tom's Pika Scheme has Unicode support, which TinyScheme lacks, so it could be worth a look. As there was some talk about the GIMP using Guile and if much work has been already done in that direction it it might also be worth mentioning that there is someone actively working on a Guile wrapper for Pika http://lists.gnu.org/archive/html/pika-dev/2004-01/msg00067.html - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] removing gimp toys, second opinion please?
http://bugzilla.gnome.org/show_bug.cgi?id=148027 Given that some less used file formats have been removed in recently releases on the basis of less code to maintain and less general clutter I suggested that the old Toys be removed from the Gimp for version 2.2. To my surprise Mitch rejected the idea (without much explanation), Adam who wrote the toys didn't seem to think it was a terrible idea so I'm asking onlist to try and get a second opinion. If toys like Gee-Zoom were built on top of a useful plugin (eg some sort of a kaleidescope plugin for example) I wouldn't even be asking but they toy are not useful at all sso users are just presented with eye-candy and left wondering how they can get that effect on their actual image but they cannot. If you still reject the idea I would ask you to keep the toys in mind when it comes to menu reorganisation. (Wiki is still down otherwise I'd add this to the menu reorganisation document we had there). The Gnome HIG recommends: http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu Do not create submenus with fewer than three items, unless the items are added dynamically (for example the File-New Tab submenu in gnome-terminal). - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] removing gimp toys, second opinion please?
If you still reject the idea I would ask you to keep the toys in mind when it comes to menu reorganisation. (Wiki is still down otherwise I'd add this to the menu reorganisation document we had there). The Gnome HIG recommends: http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu Do not create submenus with fewer than three items, unless the items are added dynamically (for example the File-New Tab submenu in gnome-terminal). Looks as if we need a third Toy then. Any volunteers? Putting them somewhere else in the menus would be easier. (Misc? Distort?) - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2 (fwd)
Forwarding to the list in case others are interested relevant to bug report http://bugzilla.gnome.org/show_bug.cgi?id=145145 plan: moving patterns from Toolbox to the current image -- Forwarded message -- Date: Mon, 9 Aug 2004 18:52:24 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Subject: Re: [Gimp-developer] preparing GIMP 2.2 Status on my pattern changes, in case you are wondering This list doesn't include tasks that have already been started but I have most of the patterns done. Now most of them also work off the current selection if there is one. Problems. I started this work based on Gimp 1.2.x scripts (I presumed the changes would minor and would likely be rejected so I did what was best for my own purposes at the time) and as a result I have had difficulties forward porting Truchoid. I could probably redo my changes staring againts the 2.0 version but it will be a real pain and this will likely delay me significantly. I have also rewritten Swirly to be between 3-4 orders of magnitude faster. I made it work off the current image too but it adds a new layer containing a square to the current image and I have not sorted out tiling it to the current image yet. I'll try and get more done this week, with any luck I'll get my head around Swirly and only have Truchoid left to do. Either way I'll post most or all of what I have on my site later in the week and file additional bug reports for the ones that are finshed. I have spent a lot of time but I have other work I really should be doing and I am not confident I'll be able to spare enough time to get them all done in time for 2.2 but I'd be very dissapointed to have my work left out. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] script-fu gimp-flip problems? procedural database execution failed
I'm trying to port a script from gimp 1.2 to gimp 2 everything else works fine except gimp-flip procedural database execution failed i tried searching for an answer but the only remotely similar thing suggested 'missing fonts' might be a problem gimp-flip works fine in the script CoolMetal. I cannot see what I'm doing differently, my script worked fine in gimp 1.2. gimp-flip is also in 3dTruchet but strangely commented out and didn't work for me when I uncommented it (and drawable is mispelt on the same line). (i think gimp-flip might have worked in truchet but i dont recall) Any ideas? - Alan PS it is inconvenient for me provide the script right now but I'll be submitting it soon anyway. (it is a rewrite of swirly-pattern.scm). ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: script-fu gimp-flip problems? procedural database execution failed
On Tue, 10 Aug 2004, Alan Horkan wrote: Date: Tue, 10 Aug 2004 22:26:39 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: script-fu gimp-flip problems? procedural database execution failed I'm trying to port a script from gimp 1.2 to gimp 2 here is the currently slightly broken gimp 2.0 version, you can find the relevant part of the file by searching for gimp-flip and it is clearly marked by cursing in block caps which some may find offensive http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/pattern-swirly.scm and here is the perfectly working gimp 1.2 version http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/script-fu/scripts/gimp-1.2/pattern-swirly.scm there is a commented out line ;(gimp-flip temp-drawable2 0) as well as (script-fu-transform temp-image temp-drawable2) which is simply a wrapper for (gimp-flip drawable 0) because I was trying various differnt things (invert, rotate, and I eventually decided on flip). I did try various combinations (gimp 1.3.x and gimp 2.0.x on windows). I haven't yet tried gimp 2 on linux becuase I do not have a copy conveniently available at the moment. everything else works fine except gimp-flip procedural database execution failed Any ideas? thanks for the suggestion Simon. Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit (ie. with translations) if it isn't fully ready yet by exposing it to more users but what is in the best interest of GIMP and its users? I know I'd much prefer another stable release with Script-Fu in it first, but that is my entirely subjective opinion. I fear having to rewrite some of my scripts having already written gimp 1.2 and gimp 2.0 versions. Compatibility is important to me, even if only small changes are necessary it causes problems. I dont relish the prospect of new scripts I write not being usable by people who still have gimp 2.0.x or even 1.2, users are still requesting backports of scripts to 1.2. It may seem like Gimp 2 has been available for ages, particularly for those who have been using gimp 1.3 but Gimp 2.0 was only released this summer. That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and sort things out after 2.2. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] split GIMP into even more packages
On Wed, 8 Sep 2004, Sven Neumann wrote: snip to be clobbered with more stuff simply because we are too lazy to add some simple notes to our web-site and FTP server. In the long run we will want to split GIMP into even more packages. Slimming down the core by moving things out to other packages is very sensible. It keeps the core smaller and easier to build without having any significant impact on users, so long as packagers are smart about it. (On a side note, I really dont like Firefox because they threw out some many little bits I actually liked without rolling them out as a package of plug-ins, which is a mistake I am very glad the gimp has avoided. Adding back in the bits you like - if they are even availabe as plugins - is far less convienent than sticking with Mozilla.) Do you foresee a gimp-plugins package? gimpressionist (and its nonstandard data files), gfig, and imagemap add a quite lot bulk to the gimp and I would think of as prime candidates to be rolled out to such a package. I dont ever expect to be using Dicom (a medical file format) but I dont think getting rid of it would necessarily be a good idea either. The way I see it at a minimum gimp core would only really need XCF PNG and JPEG (I'd immediately add in PSD but I think that is probably just me). Is this remotely like what you have in mind because I would be interested to hear more. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
On another note, I'm not sure this is a desirable goal. splitting stuff off feels an awful lot like putting it out to pasture. The that does seem like a valid risk to consider goal of just having the core application, with no plug-ins, no image data structures, no scripts, and a minimum number of brushes, patterns and gradients doesn't seem to be the direction that people want to see the GIMP taking, from what I can tell. I think a lot more of the patterns really should be moved to gimp-data-extras (there are three different types of wood included in the basic patterns, one should really be enough in the base) so that those who want less will have less and those who want more will realise that they should install gimp-data-extras and get a lot more. People would like more brushes, more patterns, more gradients, with the ability to delete the ones they don't use/like, and more scripts/plug-ins with a way to organise the menus according to the ones they use most often. I do think users want this but I do not think users care how it is achieved. Things can be split into seperate packages but the real problem occurs when distributions do not fully realise the intention was only to modularlize not to remove the features and that they should install it _all_ unless they have a really good reason for doing otherwise. Some of us are at the mercy of systems adminstrators who install only the default packages. I know that you believe that we should work on the core application and a few plug-ins, and leave most of the plug-in development to 3rd party plug-in maintainers, I'm not sure I agree. I think that we should be almost promiscuous in what we accept into CVS, but equally vicious in removing things from CVS when they become unmaintaned. I think that most people don't want to have to install several packages, they want to install the GIMP, and automatically get plug-ins like gap, refocus, and even DBP. I would like to think that all these things would be installed by defualt on most distributions, that the users would have to specifically opt out if they didn't want the extras (and distributions like Knoppix would have to strike a careful balance on what they leave out) Note that I'm not saying that all this should happen for 2.2, but I am speaking to the general goal of a lean, mean GIMPing machine versus an application which comes with everything including the kitchen sink, which you can modify to your own usage patterns, buut which has sufficiently sane defaults as to not have a huge complicated menu structure at the same time. Maybe I'm foolishly optomistic to think that we could have both a small seperable core but have everything and the kitchen sink nicely packaged so that the developers can get on with things with the minimum of fuss and users can still have it all. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: New Image dialog usability bug
On Mon, 13 Sep 2004, Danni Coy wrote: Date: Mon, 13 Sep 2004 22:36:07 +1000 From: Danni Coy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] Re: New Image dialog usability bug Why not have the entries for size have drop down menus allowing the user to select the last 8 or so amounts entered. That might work but it would clutter the dialog and you could just use templates instead. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp GUI
below the layer menu. A navigator screen should be in place always - this is a feature I find essential, and makes it impossible for me to use the GIMP - while i can zoom in and out, its very difficult to drag the screen around to the place where I want to work. if you have a wheel mouse or three button mouse you can middle click and drag/pan (although I still wish I could use Page Up and Page Down to navigate the page). if you like how Adobe Photoshop does things you should definately take a look at the psmenurc which is a settings file to give the gimp keybindings similar to photoshop. there is also an excellent plugin called pspi by Tor Lillqvist which allows you to use (some) Photoshop plugins with the gimp. As for Illustrator / Fireworks / Dreamweaver / Flash: (my own 'essential' tools) Illustrator is a print design tool, on the level of GIMP. At the moment Try Inkscape, http://inkscape.org for print work people seem to be combining it with Scribus (Desktop Publishing Software) http://www.scribus.net/ Fireworks is a vector design tool. Although Fireworks acts very much like a vector design tool as it part of the family of Macromedia products but it claims to be Raster graphics. Perhaps you meant Freehand which is the Vector graphics tool from Macromedia which is equivalent to Adobe Illustrator and seems to be competing quite successfully. an optimising screen for jpeg/gif (ewww, but essential). Fireworks allows you to slice the image and export the slices to HTML or simply to there are some slice tools for the gimp, the first thing you should try is adding some guides and choosing Image, Transform, Guillotine but there are more ways. Flash is an absolute essential - we have no tools at all at present for animation. Flash uses vector graphics as well as being able to import There are some open source Flash tools available if you look hard enough but few are advanced enough to be included with most Linux distributions and you will very likely need to compile them for yourself if you want to try them out. Macromedia did eventually make Flash a freely available standard that others can implement (but which they control) but open source tools have not caught up in that area yet but some people are certainly trying. Personally speaking, I'm just sad that I can't use Free software for my design work, and would love to be able to migrate entirely to GNU/Linux. If you are determined Wine might be an option to ease the migration http://winehq.com/ or if you have money you might buy VMWARE to run windows inside Linux. A thought - the older SGI IRIX O/S had many of these tools - perhaps free ports of these may be easier to implement. 3D design is nicely taken care of by Blender, which has become an essential on Winblows machines also. I'm surprised you have not mentioned Mac OS X which has much of the tools that graphic designers and desktop publishers love and has versions of free software like the gimp available for it (although not as perfectly beautiful native applications). Hope this is of some help at least... I'll get back to you with more details, and feel free to ask. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] first impressions of GIMP 2.0
On Mon, 25 Oct 2004, Gezim Hoxha wrote: Date: Mon, 25 Oct 2004 13:36:47 -0700 (PDT) From: Gezim Hoxha [EMAIL PROTECTED] To: [EMAIL PROTECTED], gimp dev [EMAIL PROTECTED] Subject: Re: [Gimp-developer] first impressions of GIMP 2.0 One of the tools that I absolutely love is the dynamic shortcut tool. If you set this in the preferences, then go to one menu highlight a tool then just press a letter, this letter will become the new shortcut of the tool and it's sweet :) (I should say that it took a while to discover this nice thing). And I haven't really used photoshop since 5.5 and the other day I see this guy makes a selection and then the selection gets some handles on it...he just drags the handles and makes it how big he wants it to bethat was really amazing to see, had never seen it before...so if gimp were to implement this I would love it. Try the scale tool in the toolbox, it allows you to do something very close to what you are describing. (In Gimp 2 it is between the rotate tool and the shear tool, I find the icons confusingly similar but look carefully and you will see it is available). - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] directory organisation [was Re: [Gimp-user] Installing plug-ins (fwd)]
One thing I have always admired about the gimp is the logical organisation of its files on disk. Unlike most other programs the gimp developers had the foresight to create a sensible directory structure /usr/share/gimp /usr/share/gimp/2.0 /usr/share/gimp/2.2 whereas most applications are less sensibly organised and create files like /usr/share/appname /usr/share/appname2 /usr/share/appname3 The message below from the user list reminded me and I was wondering Would it be possible to continue this elegent and logical organistion sense to the same for files in the user home directory and in future have something like this? ~/.gimp/2.2 ~/.gimp/3.0 (I'll file a bug report and try and make a patch if this idea is deemed acceptable) Sincerely Alan Horkan -- Forwarded message -- Date: Tue, 26 Oct 2004 15:14:22 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Carol Spears [EMAIL PROTECTED] Cc: GIMPUser [EMAIL PROTECTED] Subject: Re: [Gimp-user] Installing plug-ins Hi, Carol Spears [EMAIL PROTECTED] writes: actually, i was wrong. the cvs version of gimp is now installing things into ~/.gimp-2.0/ i guess until the plug-ins catch up with the version numbers. GIMP 2.2 will be using the ~/.gimp-2.2 directory. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Do what I mean [was RE: [Gimp-developer] first impressions of GIMP 2.0]
On Wed, 27 Oct 2004, Austin Donnelly wrote: Date: Wed, 27 Oct 2004 09:23:32 +0100 From: Austin Donnelly [EMAIL PROTECTED] To: 'Sven Neumann' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Gimp-developer] first impressions of GIMP 2.0 [Adding a layer mask] Huh? Go to the Layers menu, choose Add Layer Mask. Also available from the right-click menu in the Layers dialog. I couldnt actually access this - it was greyed out completely. You can't add a layer mask to a layer that doesn't have an alpha channel. Hmm - perhaps the best interface here would be to always have the Add Layer Mask menu option available, but if there's no alpha channel then popup a dialog saying something like Adding a layer mask requires the image to have an alpha channel. Would you like me to add one? Yes: / No (default yes, tickbox (unchecked) for don't ask me again). This is similar in spirit to the file export dialogs that automatically convert your image into something the file save plugin can handle (ie flatten etc). It's the DWIM (Do What I Mean) school of UI design, where you try and guess what the user is actually trying to do :) Austin, thanks for filing the bug report and thanks Sven for fixing it so quickly. http://bugzilla.gnome.org/show_bug.cgi?id=156676 I was hoping you would file more general bug report to capture the idea you mentioned of Do what I mean (I cannot think of any other way to describe it, sorry) and see if there were other areas where similar problems were occuring. There might be other areas were it would be better to do something rather than do nothing. There is a case that I think is similar: if you are moving a layer down the stack and the background layer has no alpha channel you get the message Layer 'Background' has no Alpha. Layer was placed above it. [ OK ] the way I see it there are a few possible improvements 1) just add the Alpha Channel as in bug 156676 2) dont use a message dialog, explain using a less obtrusive status bar message 3) change from a message to a dialog something like this Layer 'Background' has no Alpha. Would you like to Add Alpha? [ Close ] [ Add Alpha] I looked at a few other greyed out menu items that could potentially be reenabled: Select Invert when there is no selection; Engrave plug-in seems to be disabled on layers that do not have an alpha channel. Maybe there is not any need to create a tracker bug for these loosely related idea but should I file bug reports or try and group these and others together as part of one big idea? Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Offtopic] Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
purge from our minds the the idea of getting them to switch and to instead hope that the gimp can become another useful tool in their paintbox. Also - anyone have an address for the Inkscape-devel and Sodipodi-devel lists? I've been trying to test these and contribute also but havent This is probably considered offtopic and I'm more than a little surprised you were unable to find the answer on your own. Given that you know the lists are called inkscape-devel and sodipodi-devel you might have even been able to guess that they were @lists.sourceforge.net Alternatively the Inkscacpe Website http://inkscape.org/ inlcudes a link to the mailing lists on the left sidebar about 11 items down, http://inkscape.org/mailing_lists.php and the subscription page for the Inkscape developer mailing list is here http://lists.sourceforge.net/lists/listinfo/inkscape-devel The layout of the Sodipodi website is a little more confusing, there is a link to the mailng lists from the Developement page and probably other places too http://sourceforge.net/mail/?group_id=4054 found the lists yet. Inkscape is impressive, but could do with some 'eye candy' - thats another important factor for designers, we're competing I thought the screenshots and tutorials were a good start when it comes to eye candy http://inkscape.org/screenshots/index.php and the OpenClipart.org project includes many examples of what Inkscape (and Sodipodi and other SVG software) can achieve but maybe I'm being overly generous. with the Windows and Mac toolkits, and frankly GTK looks pretty darn strange and ugly to a designer - it'll put them off using a really good You would probably be more forgiving of GTK if you were using it on Linux and were taking advantage of themes. tool. Inkscape on the whole did what i wanted when i learnt how it 'thought', but wouldnt open and reopen from Illustrator. I'd very much like to report these experiences to their list and see how they are tackling them. The Inkscape developers would definately like to hear your opinions and are willing to ajust things to accomdate Illustrator users (up to a point) as things are being changed around a lot at the moment that means there is both room for flexibility and it also means that it is essentail that you make sure to try a fully up-to-date Nightly build. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
Miriam okay... since i'm in the Hotel California where you can check in but never check out Sorry that the you were unable to unsubscribe, I have no idea why the unsubscribe system didn't work for you but I'm pretty sure the developers were joking and that if you are still unable to unsubscribe having done your best to try the various methods available that they would be willing to take you off the list but I hope you will volutarily stick around a little longer. Is it possible to design a GUI implementation of the same script? The Select-To sounds good but its gotta be a short menu - preferably within the Brush palette itself... thats where we'd think to look for it... I'm not sure you realise there already is a script under Script-Fu/Selection/To Brush... which will take the contents of the current selection, ask you to give it a name and then save it to the brushes folder. Script-Fu is totally incomprehensible to graphic designers Not just graphic designers :) Scheme is an 'interesting' programming language but it sort of has its charms if and when you can eventually figure it out. I'd still like an automatic script recorder though. - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Sven Neumann wrote: Date: Fri, 12 Nov 2004 15:39:58 +0100 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] canvas background options Hi, Alan Horkan [EMAIL PROTECTED] writes: I can understand how that would require you to change it regularly and why you might want a menu item for it. How did you like how the feature was presented in 2.0 or were you unaware of it until it was given a prominant menu item? Hiding useful functionality in some obscure button with a right-click popup menu in the image corner is not really good user interface design and I am very much surprised that you don't consider this change an improvement. Given my previous comments that is understandable and I think discoverability is important but it doesn't make sense to have a seperate menu item for every obscure feature and to me this is most definately an obscure feature. (most of the time I shrink wrap my images and dont even see the canvas padding, if I wanted to regularly preview images against a black background I would probably configure the Fullscreen mode for that purpose) Perhaps I might have been less quick to complain if it had been only one menu item that shows a dialog but it is not, it is a submenu with several menu items and that seems a lot like clutter to me. We also needed that space in the upper right corner for a more useful and less obscure feature that is also being offered in other applications: linking the image zoom ratio to the window size. That does seem like a good idea of itself but I dont think it makes the menu items for Canvas Padding idea any better than a workaround. I'm surprised that enough users would be changing the setting often enough to want to be able to set it on a once off per window basis, I would have though that a single global preference would to override the toolkit default would have been enough (which is as far as I can go towards offering an alternative implementation). Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Jakub Friedl (lists) wrote: Date: Fri, 12 Nov 2004 16:57:51 +0100 From: Jakub Friedl (lists) [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED], GDev [EMAIL PROTECTED] Subject: Re: [Gimp-developer] canvas background options I'm surprised that enough users would be changing the setting often enough to want to be able to set it on a once off per window basis, I would have though that a single global preference would to override the toolkit default would have been enough oh please no. or is the gimp supposed to be used only by beginners and not by advanced users? That line of reasoning can be used to justify adding a whole lot of crud to the gimp that only really benefits the advanced users. if anything recent development has been removing little used plugins to reduce the maintainance burden. the gimp is the de facto standard for image editing on Linux, FreeBSD, Solaris, and I'm sure a few others. I there hardly any other piece of graphics software as likely to be available as the gimp. As such is extremely important to cater to ordinary users. I don't want to make the gimp into something that advanced users cannot use quickly and efficiently either, but an uncluttered streamlined user interface should be of benefit to everyone. I wish you would have resited the urge to overreact, all this is just dicussion and although I would prefer not to have the Canvas Padding feature I do not think my suggestions have yet been convincing enough. a month ago i was making three images to be placed on a wall, each of them on different one, painted with different colour. i was painting them at the same time (they were a series) and i enjoyed the possibilty to see them all against the proper colour. I'm still convinced it is a minority feature and although it may be useful I'm not convinced it is useful enough for most users to deserve such prominant location in the menus. Gimp 2.2 seems to be largely decided, and it is unlikely that my suggestion would be taken on board until after 2.2 has been released. BTW: if you feel that the gimp should be simplified as possible for beginners, I believe it should be simplified for everyone, most usability improvements are optimisation of a different kind and just as accessibility benifts more than just the disabled so too should good usability benfit everyone. I'm not arrogant enough to claim I'm an expert, but I thought I should be able to discuss the change before 2.2 and if I didn't do it now I'd probably be berated for not having mentioned it sooner. wouldnt be possible to keep advanced features visible for advanced users but not for beginners? but not remove them completelly? single option in preferences (or in gimprc file) which would enable more advanced features which some consider as interface clutter but others may need them? Did you use Nautilus when it had a Normal mode and an Advanced mode? It was a disaster because most users wanted one or two of the supposedly Advanced features which meant turing on a whole lot of other advanced features. It is better to think of the task and the results you are trying to achieve and see if there is a way to stream line the process. I do not doubt that it is useful for you to have a way to easily compare your image against various backgrounds. What I am asking is if the current implementation is really the best way to provide that feature? You have made it clear that you want to be able to set a different background colour for each image. Do you set different colours for different views of the same image? If so might it not be beter even better to reorganise this functionality in a way that allowed you to more quickly preview an image with various different background rather than having to choose a different back colour each time you wanted to make your comparisions. If you describe in more detail how exactly you go about your work I might be able to refine my suggestions. I'm trying to make things easier for _everyone_ including you :) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, 12 Nov 2004, Sven Neumann wrote: Date: Fri, 12 Nov 2004 23:42:42 +0100 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] canvas background options Hi, Alan Horkan [EMAIL PROTECTED] writes: 'Useless discussion'. Thanks for the encouragement, with that attitude is it any wonder more people dont try and provide feedback and try and improve the gimp. Alan, the discussion became useless after the facts had been exchanged and several people explained you that the feature is indeed useful. That makes further discussions on this topic rather useless. I am still hoping to get more information on how the feature is actually use to try to better solve the problem rather than dwell on the implementation any further. I was unable to get to use the gimp 2.1 series until recently. I cannot provide feedback only when it suits your timetable. When I pointed out problems with 2.0 you gave out to me for not mentioning them during the 1.3 cycle so I am making my points before 2.2 is released. Especially during times of string and UI freeze. All that means it that no changes will be made until after that freeze, not that changes shouldn't be suggested. (I really hope Gfig will be rolled back as the developer working on it has previously suggested, it is definately not ready for 2.2) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Sat, 13 Nov 2004, Simon Budig wrote: Date: Sat, 13 Nov 2004 00:41:18 +0100 From: Simon Budig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] canvas background options Hi all. Alan Horkan ([EMAIL PROTECTED]) wrote: On Fri, 12 Nov 2004, Sven Neumann wrote: Alan Horkan [EMAIL PROTECTED] writes: Given my previous comments that is understandable and I think discoverability is important but it doesn't make sense to have a seperate menu item for every obscure feature and to me this is most definately an obscure feature. It has been requested over and over again so there are certainly people who see a need for it. I never claimed some people wouldn't find it useful. You did however harp on the uselessness of this feature and advocate its removal. Despite numerous people supporting it. Just because you don't see the use of this feature that doesn't mean that it has none. In hindsight I should have been more diplomatic, and I repeated the comment excessively. Perhaps I might have been less quick to complain if it had been only one menu item that shows a dialog but it is not, it is a submenu with several menu items and that seems a lot like clutter to me. It is a submenu, so it is only a single menu entry i dont follow that logic Simple: If a menu entry pops up a dialog or if a menu entry pops up a submenu is irrelevant for the menu itself. It is exactly one menu entry in the menu. It doesn't clutter less or more than a dialog. My counterpoint is that even though a submenu means only one extra menu in the parent menu it means another level and more items to search through. It doesn't make the specific feature any more difficutl to use but more menu items overall can complicate the task of finding anything. I'm not trying very hard to find it, finding problems is relatively easy finding solutions and finding the time to provide feedback in way you will actually listen to is what is time consuming. From my point of view the most things brought up by you are details. While I like attention to the detail I don't like that these things tend to need lots of discussion. The issue here is a perfect example: Configurability of the border color. This discussion should have been over when everybody except you agreed that it is useful. Suddenly about 14 Mails pop up, 5 of these by you not understanding the point of the others. This does not help. As we had started I had hoped to finish and move some way towards improving the feature for those who want it and possibly making it less obtrusive. If the task is to compare an image with a Black Background, a white Background and a Blue background, changing it one at time would be slower than firing off a script that made copies and added a border in a selection of colours (that is just a possible scenario, maybe there is no room for improvement but if I'm not allowed to discuss it I'll never find out). I'll try and show more restraint and not drag out discussions longer in future, I admit I got a little carried away. In other mailing lists normally only those interested in the thread would keep reading and responding to it. - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Tue, 16 Nov 2004, Sven Neumann wrote: Date: Tue, 16 Nov 2004 12:07:31 +0100 From: Sven Neumann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] comparing gimp speed Hi, while we are discussing this. Would anyone object if we changed the default tile cache size from 64MB to 128MB? Memory is becoming cheap these days and IMO it is reasonable to adapt the default value from time to time. Would it be difficult to query the operating system and to automatically set the tile cache size to some percentage (50%?) of available RAM? Increasing the default size sounds sensible given that even most low end computers come with at least 256MB of RAM. I dont know about other linux distributions but the Memory recommendations for Fedora 2 are as follows: Minimum for graphical: 192MB Recommended for graphical: 256MB http://fedora.redhat.com/docs/release-notes/fc2/x86/ - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: whishes for Gimp
On Thu, 18 Nov 2004, Juhana Sadeharju wrote: Date: Thu, 18 Nov 2004 13:21:49 +0200 From: Juhana Sadeharju [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] Re: whishes for Gimp From: Sven Neumann [EMAIL PROTECTED] Adding more tools has the disadvantage of cluttering the toolbox. Just suggestions: Solution 1: everything goes to menu (tree) and each non-default menu item would have toggle which would append it to the toolbox. The toolbox can already be customized, you can see for yourself if you try one of the version 2.2 prereleases. Go to File, Dialogs, Tools, and if you have an up to date version there will be an 'eye' icon next to each tool allowing you to show/hide whatever tools you want. Sven's point still stands though, adding more tools to the default toolbox is not a great idea. Sincerely Alan Horkan Free SVG Clip Art http://OpenClipArt.org Abiword is Awesome http://abisource.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable?
On Sun, 12 Dec 2004, Robert L Krawitz wrote: Date: Sun, 12 Dec 2004 17:00:24 -0500 From: Robert L Krawitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Why not allow the name to be configurable? From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 12 Dec 2004 18:05:46 +0100 Alan Horkan [EMAIL PROTECTED] writes: I have to ask why reject such patches? Because IMO the name is important. If we allow the name to be changed easily, It would also make it way too easy for anyone who wants to make some quick money out of The GIMP. We must not allow people to change the name by means of a simple configure option and let them benefit from our hard work. Changing the source code and documentation is the easiest part of it. The hard part is changing the web site, references all over the net, etc. I speak here from ongoing experience -- the Gimp-Print project is in the process of renaming to Gutenprint. I am not asking the GNU Image Manipulation Program to change name. I was asking why patches that might make it possible/easier for others to change the project name and branding would be rejected. I am aware of some the difficulties that would occur if the GIMP were to change name tomorrow which is why I want to make it clear that wasn't what I was asking. It is also extremely unlikel for a name change to ever happen which is why I was asking a subtley different question. I have accepted Svens answers on this matter and do not intend to push it further. I dont find the name amusing or clever but it does not get in the way of my image editing. Changing the source took Roger Leigh perhaps a week or so, but the web site, hosting, etc. are still moving along very slowly, and we have a lot of work to do. While going through this process did Roger Leigh replace the name or did he abstract the name so that if some one was ever forced to change it again it could be done more easily? (the latter would of course take much more time) This is probably the primary reason that 5.0 wasn't released perhaps a month ago. I'm surprised the rebranding was not done seperately from the release, but that is probably only something that is obvious in hindsight. I would guess you changed the name of gimp-print to guten-print first and foremost because the project is seperate from the gimp but presumably you were aware that a small minority find the term gimp somewhat inappropriate and that it might be easier to market a different name. I wish Guten-Print the best of success with the new name and I encourage you to make as much publicity out of it as you can. (Still haven't seen any stories on it yet, just mailing list posts but I suppose I'll hear a lot more about it when 5.0 is released.) If a project as big as Mozilla Firefox allows it name to be changed, why would it be an issue for the gimp? For Firefox having the name configurable is part of the business plan. I can't find any such note in the GIMP's business plan. Heck, I can't even find the plan. Firefox had a little legal problem on their hands, and didn't have much choice. Firefox started off as a fork of Mozilla, was codenamed mb2, then Pheonix then Firebird. I really doubt the clean abstraction of the name had anything to do with the legalities but as Sven suggested much more do to with the business plans of Netscape and the Mozilla foundation to allow rebranded versions of their browser. Better a hundred branches than one fork. The project name could be have been changed crudely using grep and other tools or by messing around with the translations (something I may still look into) but it is another matter entirely to improve the abstraction of the code and make it so that the name is configurable and need only be changed in a few key places. The Mozilla foundation does want to encourage commercialisation of their product and the GIMP doesn't, fair enough. Sincerely Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)]
On Sun, 12 Dec 2004, David [iso-8859-15] Gómez wrote: Date: Sun, 12 Dec 2004 17:19:26 +0100 From: David [iso-8859-15] Gómez [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Why not allow the name to be configurable? [was [Bug 160890] Change Gimp name (fwd)] Hi Alan, I don't think it is a good idea to change the project name. So you kind of answered to yourself... No that is the answer to quite a different question. I asked why not accept patches that make it easier to change the name. It is a good sign that the gimp has improved so much that people are only left with the name to complain about :) I don't complain about the name. I never claimed you did. I think it would be a fair compromise to accept patches that make it easier for those who would like to configure the name. That a non-sense claim. I think that people that get offended by a name have deeper problems. You can say it is trivial or silly but you cannot deny that it happens to bother a small minority of people. I do not know if you are a native English speaker but the term gimp is has a very similar meaning to cripple. If you look at the bug report I point to some comments where people other than me say they have encountered difficulties, notably the embarassment of explaining the name really was the gimp to a person in a wheelchair and that the user was not mocking them. And they should worry first about them instead of changing everybody's minds to their way of thinking. I say again that I was not asking to change what everbody else calls the GNU Image Manipulation Program but I was asking why it would not be acceptable to make it easier for other to change the name (and Sven has explained the reasons for it). I answer to you, because i work on a window manager with a name that could be considered offensive by spanish-speakers with similar What is the name? ideas to the users who claim that gimp should change its name. But we didn't intend to offense anyone when we choosed the name, it was just a joke. I'm not a big fan of funny project names because different people find completely different things funny, and I much prefer names that give some idea of what a project does (which the long form GNU Image Manipulation Program does serve that purpose). But this is all beside the point, I'm not trying to force the majority to change their ways but I wanted to make it easier for the small minority to help themselves. People who complained about the name understood this when we explained it to them. If a project as big as Mozilla Firefox allows it name to be changed, why would it be an issue for the gimp? There was another project called Firebird, so there was a good reason to change it. As Sven explained and I pointed out in other posts the fact that Mozilla and Firefox can be so easily rebranded has far more to do with Netscape than it does any legal issues. Why require people to fork or maintain their own patchsets for the sake of a little extra configurability. I wouldn't call it configurability. What would you call it then? - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] panel and winning splash
On Mon, 13 Dec 2004, Carol Spears wrote: Date: Mon, 13 Dec 2004 12:06:21 -0800 From: Carol Spears [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED], GIMPDev [EMAIL PROTECTED] Subject: Re: [Gimp-developer] panel and winning splash On Mon, Dec 13, 2004 at 07:48:57PM +, Alan Horkan wrote: On Mon, 13 Dec 2004, Carol Spears wrote: i am waiting to hear what the panel decided for the winning splash. Any word on this yet? It was decided that it was very important to get some input from artists namely Jimmac Tigert and drc. okay, so what was the reason to have a panel then? they were asked for comments on a shortlist of choices. they were not asked to make the final decision. looks like the best thing would have been to skip the panel It is far too late now and the time for such comments has long passed, but I'm sure lessons have been learned and future competitions will be run differently. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable?
On Mon, 13 Dec 2004, Sven Neumann wrote: Date: Mon, 13 Dec 2004 21:26:37 +0100 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Why not allow the name to be configurable? Hi Alan, didn't you say you would stop arguing on this stupid subject? That was unnecessary. What kind of reaction to you expect to a comment like that? I thought I also said I wanted to reply to the other messages first (but I perhaps I didn't). I did not want to ignore the posts people had made, as they might consider it rude. I had planned to add your answers to the User FAQ which I thought existed in Wiki, but according to the Developer FAQ there is no User FAQ. Thank you again for taking the time to explain your reasons. Now I'm really finished and wont make any further comments on the subject. - Alan. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable?
Date: Sun, 12 Dec 2004 18:05:46 +0100 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Why not allow the name to be configurable? Hi, Alan Horkan [EMAIL PROTECTED] writes: I have to ask why reject such patches? Because IMO the name is important. If we allow the name to be changed easily, our users will not any longer know what software they are using. Contributors will be lost because they will look for the Foo project instead of the GIMP project. (Sven I know you understand what I'm saying but other do not seem to get exactly what I'm asking) To make myself as clear as I possibly can I'm not asking for the project to change its name but to accept patches that allow others to rebrand the gimp if they want. It would also make it way too easy for anyone who wants to make some quick money out of The GIMP. This has happened already, people already package and sell the gimp and their failure to provide adequate support has hurt the gimp brand. If it was easier for them to rebrand it would be reasonable to expect them to do so and make it clear that their product is not officially endorsed by the gimp project. (I'm referring to this widely reported incident of a Mac user who paid for the gimp and got no service from the vendors and as a result was excessively critical. http://www.wpdfd.com/editorial/wpd0504review.htm ) We must not allow people to change the name by means of a simple configure option and let them benefit from our hard work. First of all thank you for providing a clear explanation. If the issue comes up again users wont be left in any doubt of how things stand and I can direct them to your comments. I will add this to the wiki, as I think it has been asked enough to be considered a Frequently Asked Question. Free Software already allows them to do exactly the kinds of changes you would rather not allow people to make. Despite the fact that it it might happen anyway I can understand that you dont want to make it easy. You are in the lead developer in charge and can do anything you want and I certainly wouldn't expect you to make the changes but I'd feel a lot better if you gave a good reason to reject patches that would make it easier to get more people to use Free Software? I seriously doubt that the name is effectively keeping GIMP from being used. I am all happy to ignore the very few people who are so narrow-minded as to having a problem with the name. I'd rather see more people use Free Software. I'm disappointed that people here do not seem to understand or accept that some people (and it seems only to be a small minority of native English speakers in particular) have issue with the name and that their concersns are being dismissed as as some sort of narrow minded political correctness. I dont believe the complaints will go away but as you are happy to ignore the complaints I'll accept that and when I've responded to the messages in this thread I will try not to bring the issue up again. If a project as big as Mozilla Firefox allows it name to be changed, why would it be an issue for the gimp? For Firefox having the name configurable is part of the business plan. I can't find any such note in the GIMP's business plan. Heck, I can't even find the plan. I think it is a shame there is not a clear plan for the gimp and I think it would be a very good thing if there was a plan and efforts made to commericalise the gimp to allow developers like yourself (or others) to get better rewarded for the work you do improving the gimp. Why require people to fork or maintain their own patchsets for the sake of a little extra configurability. So that it becomes harder for them to do this. And if they really think it's worth all the hassle, well, then they can do it. I suppose it is reasonable to draw the line somewhere. Thanks again for making a clear decision and explaining it. Sincerely Alan Horkan. http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
On Wed, 5 Jan 2005, William Skaggs wrote: Date: Wed, 5 Jan 2005 07:47:10 -0800 From: William Skaggs [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Cc: @mail.primate.ucdavis.edu Subject: Re: [Gimp-developer] jpeg-exif development summary Robert Krawitz wrote: 4) When the exif specifies that an image is rotated, the plug-in pops up a query asking the user whether to rotate it into standard alignment. I thought it was better to ask rather than do it automatically, because there are probably a substantial number of existing images that have been edited without having their exif information properly updated (for example, by earlier versions of GIMP). When an image is saved with exif, the orientation is set to top-left, as the exif specifications require. (See bug #121810) I'd suggest making this a preference. If someone's careful about maintaining their images (or hasn't edited them before), they'll get very annoyed by having to answer this question every time they open an EXIF file that's rotated. Wouldn't earlier versions of the GIMP have destroyed the EXIF data? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. I hope you will consider that the simplest thing to do is to follow the specification and try to do things in such a way that in the long run there should be no need for a prompt or a preference? I do realise thatrotating the view without rotating the image itself is making things complicated but perhaps it would be possible to have the importer take care of the rotation and the exporter rotating back as needed, and still preserving all EXIF metadata? - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xtns-extras ?
On Sun, 23 Jan 2005, Joao S. O. Bueno Calligaris wrote: Date: Sun, 23 Jan 2005 01:50:27 -0200 From: Joao S. O. Bueno Calligaris [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] xtns-extras ? Hi, a few weeks ago I wrote mentioning that it might be a good idea to rename the Xtns menu entry to Extras. Abbreviations are a bad idea, some languages inevitably require longer strings which is why most menus will have lots of spare space to the right. Therefore, I am trying it again: What do you say about renaming Xtns to Extras? I think it would be a good change to the GIMP's general look and feel. I dont think it will make much of a difference either way. If this change were going to happen it might be best to make it part of the extensive menu overhaul that was considered but stalled. - Alan H ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Inkscape-devel] common interface for graphics apps on thefree desktop
On Thu, 3 Feb 2005, Jakub Steiner wrote: Date: Thu, 03 Feb 2005 20:57:45 +0100 From: Jakub Steiner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu Subject: [Inkscape-devel] common interface for graphics apps on the free desktop One of the good things about Adobe's product line is that they work together. Same tasks require the same interface. Shortcuts are consistent. On the free desktop we have two major graphics applications, Inkscape (http://www.inkscape.org) and GIMP (http://www.gimp.org). It will not be uncommon to have users needing both apps in their workflow. I hope you guys agree trying to have similar consistency helps to provide a sane user experience. There is definately some room to improve consistancy that wont bother either project but as I'm sure you are aware Inkscape quite deliberately has a different user interface from the GIMP so hopefully we can stick to the bits everyone can agree on. It is probably worth mentioning that Inkscape is likely to implement some form of dock to help manage the Palette windows. It is also likely in the long term that the toolbar widgets in Inkscape will become more flexible allowing a somewhat more flexible layout of the user interface. To be specific, there are areas where GIMP Inkscape provide similar functionality in a slightly different way. For now I will ignore the path tool. An inconsistency that came up while I was working on something is the mouse wheel behavior. GIMP uses shift+scroll wheel to zoom, Inkscape Ctrl+mousewheel. GIMP uses Alt+mousewheel to pan horizontally, Inkscape uses Shift+mousewheel. I've filed this as http://sourceforge.net/tracker/index.php?func=detailaid=1115612group_id=93438atid=604306 According to the GNOME Human Interface Guidelines Inkscape is using the preferred behaviour (and although I would need to double check I am reasonably sure this behaviour is consistant with Apple and Microsoft guidelines). http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons Ctrl-scrollwheel-up should zoom into the window or control under the mouse pointer, and Ctrl-scrollwheel-down should zoom out. Zooming in this way should not move keyboard focus to the window or control being zoomed. It would be cool if somebody found the motivation to write up some extension to the Gnome HIG, defining a standard behaviour for gfx apps (*hint* *hint* ;). I do agree that a section describing how best to design Palette Dialogs is needed as they need to be compact and are quite different from the standard transient dialogs described by the current guidelines. Sorry for cross posting, but I hope to initiate some discussion among both camps. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ (Feel free to reply to one list or both but please don't CC me) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] use stock gtk about dialog in plugins?
I was looking at version 2.3 and was pleased to notice lots of little details that have been polished or tweaked. For no particular reason I noticed some of the plugins have an About dialog and since the GIMP requires gtk 2.6 I started about getting them to use the GTK_STOCK_ABOUT button and the standard gtk about dialog. I spent quite a while checking which applications use an about dialog and the list was extremely short: Fractal Explorer Gimpressionist ImageMap (Gfig used to but doesn't at least not in version 2.3) Rather than getting these applications to use the new GTK About dialog I also considered removing the about dialog entirely (the information is still availalbe from the Plugin database if anyone wants it). However I didn't think this was a change developers would be eager to make and wasn't going to bother suggesting it until I read this existing comment by Sven which suggested completely removing the about dialog from the Fractal Explorer. http://bugzilla.gnome.org/show_bug.cgi?id=140202#c13 So would it be acceptable to remove the about button and dialog from both Fractal Explorer and Gimpressionist? If it is I'll file a request and try and provide a patch at some stage. Either way ImageMap should probably use the gtk stock about dialog, so I'll give that a try for starters. Sincerely - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Idea for new plugin
On Tue, 24 May 2005, Chin2 wrote: Date: Tue, 24 May 2005 12:34:42 +0530 From: Chin2 [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] Idea for new plugin hi everone around i have an idea for a new plugin for gimp. i may not be able explain it very well. but for those who wuold understand it would be nice.. http://www.freewebs.com/chin2online/plug1.jpg The picture explains it well enough. When people refer to the selection I would like to make it clear that you are distorting the image (contents of the selection) rather than the selection (the shape of the selection), but I understand it can be difficult to explain these things clearly. This is essentially a distortion and hasn't much to do with the selection. Such an effect can be achieved by creating an Elliptical selection and then using the Perspective tool to invert and distort or rotate the selection as desired. It should be possible to automate the process using a script or a plug-in if a programmer was interested enough to do it. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Reply to Considered Harmful [Re: [Gimp-developer] Gimp server startup [OT]]
On Tue, 31 May 2005 [EMAIL PROTECTED] wrote: Date: Tue, 31 May 2005 18:48:58 +0200 From: [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Gimp server startup [OT] On Tuesday, May 31, 2005, 17:24:01, Michael Schumacher wrote: This is intentional - google for reply to considered harmful. This might have been of concern years ago, before people were used to mailing lists which do set the Reply-to header. Nowadays, I'd say that the opposite is true, since setting the Reply-to header seems common practice (at least if I look at the mailing lists I'm following, there are only 2 that don't set the header). The problem is still the same. It is better to accidentally mail only one person and need to resend to the list than it is to accidentally send mail to many people. - Alan ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Apply palette to image colormap
And... it is buggy. It failed me when applying 256 color palette to a 256 colro image with the message: --- Error while executing (tiny-fu-set-cmap 6 12 Gold) Error: car: argument 1 must be: pair -- Not to mention: WARNING: Plug-In tiny-fu (/usr/local/lib/gimp/2.0/plug-ins/tiny-fu) called deprecated procedure 'gimp_image_set_cmap'. It should call 'gimp_image_set_colormap' instead! Normally I'd be in favour of expanding abbreviations to make things clearer but in this case the shorter deprecated name avoids the confusion caused by the American mispelling of Colour (damned Webster and his patriotic neologisms). - Alan H ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]
On Mon, 6 Jun 2005, Sven Neumann wrote: Date: Mon, 06 Jun 2005 00:24:47 +0200 From: Sven Neumann [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Cc: [EMAIL PROTECTED] Subject: [Gimp-developer] The GUADEC meeting Hi, now that GUADEC is over and everyone's back home, you will probably want to know what has been happening related to GIMP at this year's GUADEC in Stuttgart. Let me try to give a short summary of the GIMP meeting we had on Monday. The menu reorganisation effort was raised. It seems that Akkana's proposal is widely accepted. I wasn't previously aware of this proposal (no mention of it in the wiki and I thought I was on the bug CC list but apparently not) but I eventually found a patch by Akkana which I assume is the one to which you are referring. bug report on menu reorganistion: http://bugzilla.gnome.org/show_bug.cgi?id=116145 Patch by Akkanna to get things started: http://bugzilla.gnome.org/attachment.cgi?id=46852action=view The proposed patch can be improved but it is a good start. If Akkana or someone else has time and motivation to continute to work on this, then the patch can be committed right away. The patch is a substantial improvement, an excellent start by Akkanna. It will be a big improvement to have things grouped by what they do rather than how they do it. I think it is worth mentioning though that Adobe Photoshop didn't even attempt this and instead they copped out and buried their scripts in a seperate Actions dialog, so it may be difficult to keep things managable as people want to add more and more extensions (but I still think the patch is a very good and necessary first step). http://wiki.gimp.org/gimp/GimpMenuReorganization I was thinking fo doing something similar for the python plugins (and making sure to add ellipses where needed). However some of the python plugins duplicate existing functionality so putting two Clothify plugins beside each other would only confuse users. I see Akkanna tackled this by marking the Script-Fu unsharp as Unsharp 2 but if people have idea on how to tackle this duplication of functionality I would be interested to hear it. (I must say when it comes to learning to port scripts to python I found it very helpful to have similar examples written in a different language) plugin written . One possible way to disambiguate similar plugins might be to give them different menu icons but expect you can probably come up with something better than that. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]
On Tue, 7 Jun 2005, Joao S. O. Bueno Calligaris wrote: Date: Tue, 7 Jun 2005 10:39:30 -0300 From: Joao S. O. Bueno Calligaris [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting] written . One possible way to disambiguate similar plugins might be to give them different menu icons but expect you can probably come up with something better than that. I always saidthat tehere should be some way to identificate a menu entry. Not only there will be up to four (C, script-fu, Python-fu, tiny-fu) equivalent entries on a row, as you point out - but I think one has the right to know how each menu entry got there. 'kay, menu icons clearly aren't the best idea. I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable dynamic shortcuts) I really like the idea of providing information about menu items but not the proposed implementation. The way many other Gnome and GTK give the information applications do is to show a description of a menu item in the status bar. Perhaps the existing short description/summary/blurb in most plugins could potentially be repurposed for this, what do you think? Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Akkana Menu patch
On Tue, 7 Jun 2005, Akkana Peck wrote: Date: Tue, 7 Jun 2005 10:20:21 -0700 From: Akkana Peck [EMAIL PROTECTED] To: The GNU Image Manipulation Program gimp-developer@lists.xcf.berkeley.edu Subject: Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC meeting] Alan Horkan writes: I was thinking fo doing something similar for the python plugins (and It was my intention to include python-fu as well. I must have missed Excellent. If you could add the ellipses (...) too I'd appreciate it. Nobody's commented on any of the other questions I asked in the bug, I'd like to get your changes in as it is so difficult to get everyone to agree and then start to make more changes as we can get some sense of what changes are uncontraversial and people are happy with. like whether it would be a good idea to fold the short Glass Effects menu into Light Effects, go for it (it is probably worth mentioning though that Photoshop puts Lens under Distorts and now it the time to consider incorporating things from Gimpshop) or moving Enhance up to where it's just under Blur, or whether there's a reasonable place for Show Image Structure since it's now the only item in Utils. I thought it had been changed already but abbreviations like Utils and Decor should be avoided. I'll go ahead and move Enhance since no one objected; maybe I'll try to come up with some place to stick Show Image Structure. I'm really not sure, I think that might require a rethink of what categories are needed to accomodate third party plugins and scripts. (I'd be tempted to dumpt it beside Colour Cube analysis because I use both for similar puroposes but I know that isn't a good answer). (The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if anyone wants to comment there or read the questions in more detail.) I'd be interested too. I don't like Unsharp Mask 2 but strings like Unsharp Mask (script-fu) are likely to make the menus too long. Anyone have a better idea? I didn't want to mention it earlier but as you intend making another patch I should mention you used _U as the mnemonic for both Unsharps. A lot of my opinions have been added to the Wiki page but it doesn't lend itself to discussion or otherwise sorting out which ideas people really want, I suppose I should try and catch people on IRC sometime this week and thrash out which other ideas people feel strongly about rather than cluttering the list with too many little details and slowly churning through them one by one. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[OT] RE: [Gimp-developer] Re: Akanna Menu patch
On Thu, 9 Jun 2005, Phil Lello wrote: Date: Thu, 9 Jun 2005 00:48:29 +0100 From: Phil Lello [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: RE: [Gimp-developer] Re: Akanna Menu patch And of course, not everyone has a right mouse button... or do new Macs have more than one button? Rather than picking on Apple for choosing a single button mouse (which I actually like for reasons not worth going into again) point is not all pen and tablet devices have a convenient equivalent to right click which I think you will agree is more relevant to the gimp. - Alan ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Script Fu and stuff [was Re: Akanna Menu patch]
On Thu, 9 Jun 2005, Kevin Cozens wrote: Date: Thu, 09 Jun 2005 17:57:50 -0400 From: Kevin Cozens [EMAIL PROTECTED] To: gimp-devel gimp-developer@lists.xcf.berkeley.edu Subject: Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting] Alan Horkan wrote: I really like the idea of providing information about menu items but not the proposed implementation. The way many other Gnome and GTK give the information applications do is to show a description of a menu item in the status bar. Perhaps the existing short description/summary/blurb in most plugins could potentially be repurposed for this, what do you think? Most users will invoke items from the menu and won't care what carries out the action (ie. plug-in, or script) so I don't feel the menus should provide any such information. If all else fails trial and error is an adequate way to learn more about what the various scripts and plugins do. What would be useful is for the Procedural Browser to include the menu path as is currently done in the plug-in browser. This would be somewhat helpful but .. While working on Script-Fu/Tiny-Fu scripts I often use the browser to determine which PDB call I need to use for a given task. What I do sometimes is leave an image open and then in the Script-Fu Console to find it value I use (gimp-image-list) and then pass that to the functions I want to try out. The proposed Logo/script browser[1] in bug 158980 might be able to make this process even easier and apply a function to a current image. (I made a really awful attempt at this using the Python based PDB Browser and by passing dummy values to get plugins to pop up) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ [1] Full Link to bug 158980 http://bugzilla.gnome.org/show_bug.cgi?id=158980 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Fri, 17 Jun 2005, Leon Brooks wrote: Date: Fri, 17 Jun 2005 09:05:30 +0800 From: Leon Brooks [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? The closest I could find was a vague reference to a pre-2.0 KDEified version of The GIMP, apparently called KIMP... http://dot.kde.org/1096230607/1096270511/ ...and this discussion, which is obviously approaching the issue from the KDE end and not the GIMP end of things (IMESHO, starting from the wrong end): http://lists.kde.org/?l=kde-develm=92756018422117w=2 I am guessing that a zero overhead (at least for GTK, I'd envision this as a 1:1 mapping using #defines) toolkit mapping layer at the source-code level would make ports for Qt/KDE, Carbon, wxWidgets or whatever considerably easier. Then there'd be only alternative shims to maintain, not a whole raft of debris integrated with The GIMP proper, and toolkit bugs would all be located in very few files. I am optimistic project like metatheme will help improve consistency between Gtk and KDE applications and help leave the choice of toolkits to the developers. If you are interested in looking into it futher here is their website: http://metatheme.advel.cz/ Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP is not a GNOME application
On Fri, 17 Jun 2005, Sven Neumann wrote: Date: Fri, 17 Jun 2005 23:11:25 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Leon Brooks [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP Hi, Leon Brooks [EMAIL PROTECTED] writes: This may seem like an oxymoron, given GIMP's heavy defacto relationship with GNOME-flavoured GTK, but is there any GIMP equivalent to OpenOffice's KDE integration (http://kde.openoffice.org/)? GIMP is not a GNOME application, This point has been made before and I hope Sven is willing to clarify this point a little more as I do not entirely understand his purpose in saying it or putting it exactly that way. People have different ideas of what it means to be a Gnome application. For a long time the prevailing view has been a Gnome application is an application which uses Gnome libraries and applications that are part of the Core Gnome desktop. In this sense the GIMP is not a Gnome application as it does not require libraries outside of GTK. it uses GTK+, the GIMP toolkit. This is by chance the same toolkit that GNOME uses, so integration with GNOME is easier to achieve. That doesn't mean though that we wouldn't try to make GIMP work well on KDE. Most mature developers recognise the benefits of working closely with KDE, following standards from Freedesktop.org and making applications integrate better. A desire to work well with both Gnome and KDE is no certainly barrier to an application becoming a Gnome application. GIMP supports most of the cross-platform specs that the KDE and GNOME people are developing to make this happen. What is missing to achieve better KDE integration is someone who tests GIMP on KDE, gives feedback and points out what's working and where there are problems. There is the strict sense of what it means to be a Gnome application which I described above and is what I believe Sven means and then there is the broaders sense of Gnome applications I will now try and describe. Some people carelessly refer to all GTK applications as Gnome applications, acronyms dont slip off the tongue quite as easily as words do but this really is not accurate or helpful. (Acrobat Reader 7 and Realplayer 10 are Gtk applications but about as far away from Gnome as you can get.) Increasingly there are many Gnome applications which no longer require any Gnome specific libraries and even the concept of Gnome libraries has changed with more and more work being done to improve Gtk instead of rebuilding uncessary layers on top of it. The older technical distinction is not as obvious or as clear anymore and many applications optionally use gnome libraries (compile time options) and can be quite different depending on what you choose. Gnome has a wider community beyond the core desktop applications and there are other vaguely defined areas such as Gnome Office, Fifth Toe, and others which are sometimes considered to be Gnome based on developers showing an interest and being willing to consider themselves as part of Gnome in the much wider sense. The GIMP is sometimes described as being part of the Fifth Toe, part of the wider community and well integrated with Gnome. Following the Gnome Human Interface Guidelines is something by itself which many people consider enough for any application to consider itself a Gnome application. Some people think applications which use Gnome CVS, and Gnome Bugzilla, the Gnome Translation Project and maybe evne the Gnome Help browser to be a part of Gnome. If a developer has asked for their journal to be included on Planet Gnome one might be forgiven for getting they impression they considered themselves part of the wider Gnome community. If the GIMP developers decided tomorrow to start saying the GIMP was a Gnome application without chaning anything else I sincerely doubt any Gnome supports would disagree and in fact I think many would welcome the gesture. Making a firm commitment to supporting the needs of KDE users and make promises not to require Gnome libraries certainly does not mean the GIMP needs to publically distance itself from Gnome. I firmly support efforts for better interoperability and work to keep the GIMP clean and portable. Perhaps Sven can clarify, I hope when he said GIMP is not a GNOME application he was describing it from a strict technical point of view and did not mean to distance the GIMP from the wider Gnome community which unfortunately was the impression I got in the past and one I think others might have also mistakenly gotten too. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, 22 Jun 2005, Robert L Krawitz wrote: Date: Wed, 22 Jun 2005 07:32:11 -0400 From: Robert L Krawitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 10:12:05 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Sven, you've been offered a solution -- just add an entry with tab completion. You may not agree with it, but it's not accurate to say that noone has made a proposal on how such an entry should be integrated with the current dialog. Just stick it on the bottom of the dialog, just above the OK/cancel boxes, and Marc and I will be happy to shut up. This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. This one seems to be attracting a disproportionate share of complaints. Usually with other controversial interface issues I see a few comments, and then people start to converge. This one is different. It is unfortunate that the new file chooser is bad at exactly the things the old file chooser was good at, a case of six of one half dozen of the other. (I always have a terminal open and make frequent use of gimp-remote so I dont mind to the new file chooser too much.) In what way is just adding an entry with Tab completion going to ruin the whole thing? If it's there, but isn't used, it isn't going to interfere with anything else, is it? It does indeed interfere with the rest of the dialog, otherwise it would probably have been added a while ago already. But I already explained the problems of this approach in another mail that I sent last night. If I understood correctly, it's a conflict between the use of tab for completion and tab for jumping between widgets? If so, how about using a different keystroke for completion (escape or ctrl-tab, for example)? Perhaps another approach would be for the integrated text input to be initially hidden, but with a More button that makes it visible. The state of the More button is saved, so that the next time the dialog is popped up it has the same components as it did before. And why is it so important that there be a concept for the entire dialog beyond what works best for people? The problem (to me, and I daresay to Marc) is very simple -- there's no obvious way to simply enter a pathname with a simple form of completion that's only activated on demand. A file dialog without this is just plain fatally flawed. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. The problem is that there's no one method that works best for people. People like Marc and I find the old dialog much more suited to our needs than the new one. Obviously the problem is a GTK issue, not a GIMP issue. There seems to be a big benefit to developers in using the new File Chooser API. I am a little surprised no one has ported the old file chooser to the new API, or written any alternative file choosers that work with the new API. (There was definately some talk of adding support for the KDE file chooser to use the Gtk File Chooser API by developers connected with Freedesktop.org or Redhat I think but I am pretty sure nothing ever came out of those wild ideas but the Gtk Developers would be the ones to ask I guess.) I notice some projects have added support for the new file chooser to make it a compile time option but mostly as a way to avoid forcing their users to use the latest version of GTK. I expect the gimp requires an up to date version of GTK for other other reasons but perhaps support for the old file chooser could be added as a compile time option (horribly inelegant and another unpleasant configuration option I know but I wanted to put it out there as a possibility). - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
On Thu, 23 Jun 2005, Sven Neumann wrote: Date: Thu, 23 Jun 2005 00:14:55 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: The GNU Image Manipulation Program gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Integrated Scripting Hi, Alan Horkan [EMAIL PROTECTED] writes: The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, I'm irked that we have both Dialogs and Dialogues Sorry, would you mind to explain that? We only have a menu called Dialogs. Everything else is a translated menu entry. It is ugly little localisation issue that I wish was not an issue at all. I should probably take it up with the en-GB translation team but if the menu item used a word that was the same in both American and British English my problem would go away. Seeing the most recent version of the gimp with the word Dialogs localised to Dialogues looks really really weird and disturbing. I've always thought of Dialogs (American spelling) as the computer kind and Dialogues (British spelling) as the conversation kind. Software manufacturers so rarely bother to fully localise computer terminology I have grown to think of the American way of spelling things to refer to the computer terminology. I wish I could find other examples of using local spellings to have a subtely different meaning but off the top of my head I cannot think of any non computing related examples (analogue, dialogue, programme, favourites, etc) but maybe you can think of examples of German words that have ambiguous meanings depending on which German speaking country they come from. I hope that makes some sense. and I would like to see it replaced with a term that doesn't require extra localisation work and yes I wouldn't be averse to slapping the slightly inappropriate Windows label on it (benefit of consistency with other software) but Palettes or even Docks which actualy describes the type of dialogs might be better. Windows is usually used for a list of opened windows. Photoshop is a bit weird I admit but the Windows menu is where it puts the menu items to control what Palettes are shown. The list of Open Windows is also included in there somewhere, and also an option to save workspace which will make sure window positions are remembered and a few other bits and peices (like maybe Close All, but I dont have convenient access to Photoshop so I'm really not sure what is in there). So if we used that we would use a term that is consistently used in other applications for something completely different. In theory the View menu would be the place to put menu items to control what windows/dialogs are shown or not shown but in this case it is not at all pratical. It may not be consistent in the general sense but graphics applications do what is consistent with Photoshop for better or worse. The menus are being reorganised anyway and this would be one less thing for them to complain about, so if ever there was an appropriate time for me to mention it I think this is it. And we should actually consider to add a Windows menu that lists all open GIMP windows. Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
to the number of happy users? We can hardly decide anything unless we know the answer to these questions. I've seen quite a number of people -- Marc, Alastair Robinson, Bill Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael Thaler, and myself -- complain more or less vociferously about this, for what appears to be more or less the same reason. Alan Horkan appears to have at least some complaints about it, I do not disagree with Sven on this. Please do not count me in on this arguement, I probably should not have commented at all. On balance the new file chooser is better, it just happens to be worse in some of the ways the old file chooser was good and I do recognise it has issues. On balance I support the new File Chooser. I see the problems with it as mostly GTK problem. You cannot really argue against the merits of a clean API that allows you to go ahead and write your own replacement. Now that i think if it GPE are one of the few groups who have gone ahead and done this, and I am increasingly tempted to attempt it myself (but dont hold your breath it would take me a long time to develop something I would be willing to show in public). - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting (fwd)
To: Nathan Summers [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Integrated Scripting I've used plenty of applications where the Windows menu does double-duty, with the kinds of windows that can be opened, followed by a separator, followed by the current open windows. Come to think of it, I'd say the only apps that I've used that don't do it that way are ones were all the windows are the same kind, anyway. what windows/dialogs are shown or not shown but in this case it is not at all pratical. At least to me, the View menu is for stuff that affects this particular view of this particular image, not dialogs and windows unrelated to it. Some simpler applications use the View items globally so that if you turn off the View of the status bar the next window will not have a statusbar but already open windows will remain unaffected. (this is a simplification I'd like to seem more applications make use of, but it slightly reduceds flexibility so I have been reluctant to suggest it for the gimp) And we should actually consider to add a Windows menu that lists all open GIMP windows. Listing all the open window list might help reduce the requests for a tabbed interface to the gimp many of which seem to be due to difficulties in managing lots of open windows. That would be a nice feature to have, but I don't think it would be a complete substitution for tabs. I'm not a fan of tabs. All too often the task list and window management are being reinvented for every app. My comment was basically a bit of a pot shot at Tabbed interfaces (a lot of users want them everywhere because they work well in the web browser) and encouragement to anyone who might want to implement the feature because I do agree it is a useful feature. Later - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pygimp on windows? success!
On Fri, 24 Jun 2005, Michael Schumacher wrote: Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each of the officially supported platforms. Hm, how about letting Script-Fu/Tiny-Fu die in favor of it? ;) The best thing about Script-Fu has been knowing it would be available and included in the 'default install'. Many existing scripts are written in Script-Fu and as you know we still regularly get users asking how to get and old script to work with the current version. From a technical standpoint it is great that Python and Perl subsystems are well achitectured and entirely seperable but the failure of distributors to include them in the 'default install' or even bother to build them has dicouraged people from using them. Making it possible to leave things out is different from it being a good idea to leave things out and I do not think users are given the best impression of the GIMP because to the ordinary user if it is not installed it may as well not exists. My point is Script-Fu remains useful despite it's flaws and I am concerned by the potential side-effects of killing it off. Better go and improve my python skills... - Alan H. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
