Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends
On Tue, Jan 19, 2010 at 10:38:40PM +0100, yahvuu wrote: Hi all, recent discussion on gimp-user brought up some usuability issues of the JPEG export dialog [1]. Actually, there's nothing new to say about it... the big JPEG quality thread did cover it all [2]. However, due to the sheer size of that thread, i think a summary of open issues is useful. Can't recall if there was ever a discussion there about the possibility of entering a starting desired file-size in the dialog, whereupon the slider would be adjusted, from where it could be tweaked up or down. Having limited storage space on my server, I am always doing the quality/size compromise. Would be handy if the default starting-point could be adjusted to size rather than quality. Scott. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] PF_FILE of the register functi on in python plugins with 'new file' support (Sco tt)
My way around this was to use a PF_DIRNAME immediately above the PF_STRING and combining them for the total path. Ah, thank you very much. I wasn't aware of PF_DIRNAME. It's missing in the GIMP Python docs. This way I have a nice workaround which totally fits my needs. What else PF_ data types are missing in the docs? Or the other way around: Where can I read about all currently existing types? _ You know, I'm not sure where I first found it. I might have just changed SF-DIRNAME to PF_DIRNAME, assuming it would translate, which it did. Finding a single source of current documentation on Python scripting in GIMP is darn near impossible. I just fire up my google-fu and burn some bandwidth. Experimentation is also key. Not sure if something works, try it out. What's the worse that could happen? ;) -- Scott (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] PF_FILE of the register function in python plugins with 'new file' support
Hi Imagine a python-fu plug-in with a GUI that is initialized through the register function. One of the elements is of the PF_FILE type to select a file. Unfortunately, the dialogue that pops up when entering a file only allows the selection of an existing file. But I want to select a new file. So there should be a text box either in the file dialogue or in the plug-in GUI that allows to enter any file name. The only workaround in the moment is a PF_STRING element. But this is really inconvenient because the whole path has to be entered. A graphical selection is much easier. Thanks in advance! Mathias My way around this was to use a PF_DIRNAME immediately above the PF_STRING and combining them for the total path. -- Scott (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
On Fri, Oct 30, 2009 at 09:13:55AM -0400, Monty Montgomery wrote: We could fork the project to only include Christian developers, thus... uh... you all *are* getting this is sarcasm, right? Way OT, but speaking of getting in trouble with acronyms, I remember years ago at law school when someone founded a Christian Legal Association there, and they would post bulletins on the walls. Somebody (hmmm, wonder who?...) started posting bulletins about upcoming meetings of the PLO - Pagan Legal Organization. My 2 cents on the issue; the name doesn't bother me, just as the names of other programs I use every day such as emacs, mutt, lynx etc do not bother me. You gotta love mutt's bug list on the manpage (Mutts don't have bugs; they have fleas.) Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] translation related - who's right ?
On Fri, Sep 26, 2008 at 09:50:01PM +0300, Cristian Secar?? wrote: I have this string in the .pot file: Add Sample Point Some other translations use this: (fr) Ajouter un point d'échantillonnage (it) Aggiungi punto di campionamento Not 100% sure, but it appears that these translations correspond to what in English would be ???Add Sampling Point???. Because I don't know where this string is in practice, my question is who's right, I mean I like to know what is the right version I should follow for my translation (Romanian). Cristian, English is a language which is often mangled by its users. Although I do not know where the phrase appears in the gimp, I would guess that sampling point is more nearly correct, presuming that it is a point which is being sampled, rather than a point randomly picked from a collection of points and offered up as an indication of what the points generally look like, which is what sample point would mean. Perhaps someday a correct_english.pot could be prepared Good luck in your endeavours! scott swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc
On Thu, Jan 17, 2008 at 05:39:29PM +0100, peter sikking wrote: There are some traits that make Bill's idea obsolete. First one is the hierarchical organisation of resources. A tagging system allows multiple ways to find a resource again (instead of a unique one) by attaching many different properties to it (a single brush can be: small, ragged, subtle, project XYZ, project ABC, old skool). And this can only encourage reuse of a resource. Okay, if there are multiple tags enabled, that is great! Just call one of them 'workspace' if you want. Just so long as there is an easy way to set/unset a tag, both by browsing the whole set, or by just browsing within a tag. And a nice way of selecting the current tag, possibly with unions (all of the project ABC tags plus all of the old skool tags that aren't already included in ABC, plus the subtle tags that are in XYZ minus the subtle tags in ABC...) - then if the selection could be given a new 'project DEF' tag. I drool. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc
On Thu, Jan 17, 2008 at 08:37:34AM +0100, Sven Neumann wrote: And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available. Sure. That is the set of brushes that match the currently selected tag. That would be the name of the project you are currently working on, or a category that describes the kind of brushes that are currently needed. As a user, I have been following this thread with interest. The workspace idea certainly made a great deal of sense to me. The whole 'tags' idea is fine too, but if I understand what is being said there would only be one tag per brush. So say I have a set of brushes I have tagged as 'funky', another one as 'staid', another as 'workhorse'. But maybe the project I am currently working on wants one from each category. So, using the tags, I pick the 'funky' one I want, then the 'staid' one, maybe two 'workhorses', etc. and move (link, copy) them into the workspace, where they are instantly available during the duration of the project. Done with the project, delete the workspace (or just some of its brushes, depending), start on the next one. I don't know anything about gimp programming, but I can't imagine this would involve extra fs-access as was mentioned as a negative; wouldn't the workspace just consist of pointers to the actual brushes? Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote: I think that use image file quality unless defaults are 'better' is not thee problem. Problem is inheriting image quality between different images in one GIMP session. I have a default quality of 85. Then I open DSLR image with quality 95. Save it with that quality. Then I open and save low quality cameraphone image. But I am not offered my default nor the original cameraphone quality (which would be both understandable) but the DSLR quality of 95. Huh? These images have nothing in common except they have been opened in the same editor session. Do not mix them up. There are times I definitely *want* to save the settings from a previous save. A common task for me is to edit ten or so images to present at 300x225 pixel size on the web. Of course, I don't want to save exif or thumbnail, so the carrying-over of these choices (and I don't know if this is fixed in 2.4 or not) is appreciated. Not wanting to use *too* much memory on my server, I will usually tweak the jpeg quality factor down to something less than the default 85, and I like having this carry forward from image to image when I am doing this task. If one looks too degraded at the new setting, then I can tweak it upwards, or if one is too big, then I can try lessening the quality, but I certainly wouldn't like to have each new image return to the default, or to some value determined by the image itself. I want to be in control but not have to control too much, if you know what I mean. I want the software to remember what I am doing. Couldn't there be a button somewhere to forget previous settings or begin new task? Actually, that would be helpful in many other situations, such as the file-save directory (and this is probably a GTK issue, I suppose). Now, I have to select the directory *every time*, even though I obviously want to save all 10 images to the same directory. Sort of like fifty first dates Actually, the more I think about it, the idea of a begin task - end task pair of buttons makes sense to me. Perhaps there could be pre-defined task parameters which the user has set up for different ones. Such as defaults for the resize-image, crop image, save directory, etc, etc. Maybe something like this already exists and I don't know about it. Who knows scott swanson just a user. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
On Fri, Aug 31, 2007 at 12:19:23AM +0200, [EMAIL PROTECTED] wrote: I think what you describe could be put under Save as. It is not Save though. Probably misusing the defaults. You're right, of course. Doh. I always use save as. And it works fine for my purposes (other than the save-to directory which I mentioned), and I hope it does in 2.4. Sorry to have misunderstood. Scott Swanson -- (or ss - hey, you've given me ideas, except it looks like something from a notary seal or the nazi era - my middle initial is 'O' - that's probably not a good idea either.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Ruby
I suppose I'm most qualified to answer that. (I still lurk on the mailing list) It hasn't been forgotten, just put on the back burner. At the moment, I'm unsure what to do with it as it requires Gimp 2.3. I tried doing a bit of advertising on a couple Ruby sites, but nobody seemed interested in installing the development version of Gimp to try/use it. With only a couple people that I know of using it, the motivation level for working on it is pretty low compared to some of my other projects. Several times I've considered backporting it to 2.2, but there were a couple of things that it would use that are becoming deprecated as of 2.4. Waiting out the 2.4 release seems to be a bit of a mistake perhaps as I've been doing that for almost a year now. What do you mailing list folks think I should do? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
On Sun, Jul 08, 2007 at 09:59:18AM -0400, Robert L Krawitz wrote: Think of the quality setting as an indication of expectations rather than a specific outcome. It may not be possible to get the exact same outcome (and obviously -- at least to us -- there's no way to retroactively improve the result), but the quality setting could be treated as the user's expectation for the result. Just a stupid user here, but interested in this thread since it is something I do all the time. I have Shift-S configured to change the image size, and of course Ctrl-S is by default configured to save file. I can't remember how many times I have hit the Ctrl by mistake, and now am quite distressed to understand that the image which I uploaded from my camera and then deleted from the memory card has now been degraded to a different quality than it was Definitely a bug, not a feature, IMHO. Just curious, what would be so wrong with saving the original file as a backup before doing a destructive save? Emacs only bites me when I'm *really* stupid I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this feature. If more of us users would be as persistent instead of just going away after the initial knee-jerk you don't know enough to even be talking to us response which seems too prevalent here, maybe the Gimp would become all that it can be. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
On Mon, Jul 09, 2007 at 08:18:44PM +0200, Sven Neumann wrote: Hi, On Mon, 2007-07-09 at 11:36 -0600, Scott wrote: Just curious, what would be so wrong with saving the original file as a backup before doing a destructive save? Emacs only bites me when I'm *really* stupid There's nothing wrong with that. It's even on the list of things that the file plug-in library should have. The file plug-in library we would like to port all our file plug-ins to. If you are so much interested in this, perhaps want to offer your help with this task? Well, if I had any development skills, I'd be more than happy to do so. I used to enjoy writing code for totally text-based programs under cpm and msdos, and still write some for linux, but graphics-based programming is a bit beyond me. I tried once to compile the Gimp from SVN and failed miserably, so I doubt I'd be a good candidate, though certainly would be willing to help. I am so glad that Guillermo stuck by his guns and apparently *finally* got the developers to realise the illogic of this feature. If more of us users would be as persistent instead of just going away after the initial knee-jerk you don't know enough to even be talking to us response which seems too prevalent here, maybe the Gimp would become all that it can be. If more users would be so persistent, as you call it, then there would probably not a single developer left who would feel that developing GIMP is fun. There would probably be noone who would be willing to spend his/her free time on it. As I perceived the thread, Guillermo's approach would not take the fun out of anything. He merely was pointing out a serious problem with the way Gimp implements the 'save' as regards jpeg files; something a developer probably never thought of, but something with serious adverse consequences to a normal user. I don't see the point in your mail. We listened to Guillermo and his issue was addressed in almost no time. It was absolutely not needed to stick to any guns. And it did eventually get addressed, but only after an attempted brush-off or two. Read the thread. We are working very hard to finally get 2.4 out and because we are taking this very seriously, we are in this pre-release mode for a long time already. It would help a lot if we could concentrate on the important things now which is to bring out GIMP 2.4. The users could finally benefit from the hard work the developers have put into GIMP over the last years. Perhaps than the users would finally realise that a lot is happening to make GIMP better and easier to use. Don't get me wrong, we users *do* obviously appreciate all of the work you guys do, or we wouldn't be using the program on a daily basis. It's just that we often get the perception that when any suggestion is made on this list that something isn't quite working as it should, there is a we know better than you do attitude. I'm sure it isn't intentional? Can we settle this now and get back to work? Thanks. Fine by me. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] default setup for 2.4 comments
On Tue, Dec 12, 2006 at 10:04:38PM +0100, Sven Neumann wrote: to avoid misunderstandings, I would like to point out that I very much welcome the discussion about the defaults for 2.4. But I think that we should better have it on the gimp-users list. I don't think that developers are good at doing user interface decisions. Well unfortunately we users are ultimately at the mercy of you developers, so all we can do is *hope* that you are good at the UI decisions, since we have to live with them That doesn't mean that we should do whatever the users tell us to do. By no means. But we should listen to them and give them a chance to participate in such decisions. I would very much welcome a merge of the users and developer lists. That is an excellent idea! I, as a user, got onto this developer list some time ago for some forgotten reason. But it has been fascinating to watch you discuss the evolving 2.4. There seem to be some who are interested in what we poor schmucks out here in Userland have to say, while others seem to take the attitude of Let them eat cake. Free software is a wondrous thing. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP
On Wed, Dec 06, 2006 at 10:06:07PM +0100, Sven Neumann wrote: Hi, I'd like to do the following change to the comment at the top of all source files in the GIMP tree: -/* The GIMP -- an image manipulation program +/* GNU Image Manipulation Program Any objections? How about /*--G nu--I mage--M anipulation--P rogram-- Just a thought Scott. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: More interface rantings
On Wed, Nov 01, 2006 at 11:14:24AM +0100, news.gmane.org wrote: Gimp's bug tracker is Bugzilla and can be found at http://bugzilla.gnome.org/browse.cgi?product=GIMP. Bugzilla is used in many open source projects (and presumably many other projects as well) and was first created for the Mozilla project; it has its own website at http://www.bugzilla.org/. Thanks. I went and looked under interface issues and then specifically searched for crop tool, which we've been discussing. Saw one 'bug', with last activity 09.17.06. Most salient responses: The new tools are still under construction and subject to changes; and IRC works much better than bugzilla for these kinds of issues. Ignore that man behind the curtain! Also saw bug #10686 - why is that sort of thing kept on the system? Entertainment value, I guess. Sheesh. scott swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: More interface rantings
On Tue, Oct 31, 2006 at 10:30:07AM +0100, Michael Schumacher wrote: Scott wrote: /rant Hm... don't you think that sticking to the current problem - crop tool - would make this thread more useful than expanding it into a generic rant once again? Well, I guess if the subject said Crop Tool rather than More Interface Rantings, yeah. Didn't think it appropriate to open a new thread called Interface Rantings - the Sequel. There are so many things to rant about, I guess I could go II, III, IV, etc Of course, there are a lot more things to *rave* about too! Just a reminder that we users do appreciate the developers' hard work. Scott. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: More interface rantings
On Wed, Nov 01, 2006 at 12:13:33AM +0100, Sven Neumann wrote: Hi, On Mon, 2006-10-30 at 15:01 -0700, Scott wrote: I have yet to hear any feedback regarding my idea of allowing the options for a tool like the current crop to be customised by the user to make it do what s/he wants it to do as a normal case. GIMP allows you to configure the default values for all tool options. It even allows you to save them as named settings so you can have several settings per tool. Okay, so I could, eg, make it so that the rectangle submenu on the crop tool option is shown by default, with the rest of the selections now appearing in the menu put into a submenu? That was what I had suggested. I don't think it's implemented, AFAIK. But I will explore. Just a small case in point: The Save As menu as applied to jpeg images. [ snip a bunch of idiotic rantings ] Because noone has implemented this yet. There's a long-standing bug report for it. This holds true for almost everything that you are ranting about. A little search on Bugzilla would have shown that we are aware of all these issues and plan to improve them as time permits. Okay, I'm ashamed to admit that I don't even know what a bugzilla is. I guess I always thought a bug was something that actually made a program non-functional, rather than the things that make it only function at a sub-par level, so I wouldn't have even thought to look in a bug report for interface details. Sorry to have wasted anyone's time. Keep up the good work. Scott. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: More interface rantings
On Sun, Oct 29, 2006 at 02:00:48PM +0400, Alexandre Prokoudine wrote: On 10/27/06, Juhana Sadeharju wrote: Your text gives an impression that the old crop tool is not anymore there. Is that the case? Yes, it is The fact is that people have different ways of working and therefore having two (or more) versions of the tools would be perfectly ok. Can you provide examples of real first-class applications where two or more versions of tools are used and users are perfectly ok with it? Can you provide results of a usability research for any application out there that would prove that having two (or more) versions of the tools would be perfectly ok? Whoa, let's not get so defensive here, let's discuss the issue. I'm not sure what is meant by the old crop tool not being there, but I presume you are talking about the new expanded crop tool which I grumbled about in my original post. I have yet to hear any feedback regarding my idea of allowing the options for a tool like the current crop to be customised by the user to make it do what s/he wants it to do as a normal case. Every user has different workpatterns, preconceptions, etc. A program that lets the user tailor it to suit those will be welcomed and used and loved as only a comfortable old pair of sneakers can be loved; one that imposes its own rigid default design which can only be changed by *endlessly* having to click on other options or the like only tires the user to the point of looking for something else with a better fit. Just a small case in point: The Save As menu as applied to jpeg images. I personally am always saving these for use on the web. Do I want to save the thumbnail and exif information to bloat my images? Of course not. Do I always have to click the advanced options button to turn these off? Yes, I do. Why? Why can't I set these to the defaults that make sense to *me*? And directory paths. Probably a gtk issue, but why? A case in point is the gtkam application, which has been updated to use the gtk stuff. In the previous version, I would always save my digicam photos to, eg, ~/photos/2006/10. And it would remember between instances, so I'd only have to worry about changing anything when the next month rolled around, and then the next year. Now, it defaults *every stupid time* to my home directory and I have to waste numerous key/mouse strokes to get to where I want to be. The Gimp has been similar in its forgetfullness forever. Again, a tool which will remember what I want it to do will be appreciated as a wise tool. Take a look at the way Gqview does directories. Then wonder why most users use it as a front-end to get their pictures into the gimp to edit. Then ponder why the gimp couldn't do that itself /rant Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Troubles with Make
I had earlier asked how to do CVS so that, as a user, I could have the latest version and could have a greater chance of commenting semi-intelligently on UI issues. Some of you were kind enough to point me in the right direction. After about 5 hours over a dialup connection, I managed to get the CVS. Then it wanted intltool, and I found and installed that. It also wanted gtk-doc, but I wasn't able to make that for some error I can't remember, (something about missing stylesheets - sorry, I am sending from a different place and don't have the info with me...). So I used the --disable-gtk-doc flag that it suggested. However, ./autogen.sh still gives me error messages which my inexperience does not allow me to understand. Thanks if anyone can point me in the proper direction, bearing in mind that I am not a wizard at make or any of these tools. I did look at the info '(automake1.8)...' which was suggested, and it was entirely over my head. My apologies if this duplicates a post I sent earlier from a non-registered address which appears not yet to have materialized. scott swanson Here is the output from ./autogen.sh: I am testing that you have the tools required to build the GNU Image Manipulation Program from CVS. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information... checking for libtool = 1.4 ... yes (version 1.5.20) skipping test for gtkdocize checking for autoconf = 2.54 ... yes (version 2.59) checking for automake = 1.8.3 ... yes (version 1.9.6) checking for glib-gettextize ... yes (version 2.12.3) checking for intltool = 0.31 ... yes (version 0.35.0) checking for xsltproc ... yes I am going to run ./configure with the following arguments: --enable-maintainer-mode --disable-gtk-doc 2 /usr/local/share/aclocal/parted.m4:16: warning: underquoted definition of PARTED_CHECK_LIBPARTED run info '(automake1.8)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/local/share/aclocal/avifile.m4:21: warning: underquoted definition of AM_PATH_AVIFILE aclocal:configure.in:416: warning: macro `AM_PATH_GTK_2_0' not found in library WARNING: You have disabled gtk-doc. As a result, you will not be able to generate the API documentation and 'make dist' will not work. configure.in:426: error: possibly undefined macro: AM_PATH_GTK_2_0 If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More interface rantings
On Fri, Oct 20, 2006 at 10:11:25PM +0200, [EMAIL PROTECTED] wrote: You should probably give yourself more that a few crops to get used to the new layout before shouting too loud, you may actually like some of the new features once you've found them. Yes, it *does* have lots of new features, and I'm getting sort of used to it, but the amount of mouse-clicking required is annoying. One suggestion: When a tool starts trying to be all things to all people, it becomes difficult to use for everyone. Here's my idea, FWIW, on the tool options: The 1st time an option menu is selected for a tool, a window pops up with every option displayed. They are grouped into groups, and each group has a checkbox beside it. Display all the time, or not? Eg, IIRC, in the case of the crop tool there would be Crop/Scale as one group, Operate on single layer and whatever else as another, the rectangle section as another, etc. Once the user has figured out which areas he/she would normally be interested in seeing, there is a Save Preferences button at the bottom. (Also, there could be a final checkbox like Always display option menu when using this tool). When the preferences are saved, the next time the option pops up, it only shows those which were checked. At the bottom of the menu, there is a down arrow showing that more options are available, and left-clicking this brings up the rest that were not checked. *Right-clicking* the arrow brings up the original full-menu with check boxes so that one can change the preferences again. This would make it a lot easier for the user to customise a tool to fit his/her usual work-flow with a minimum of mousing around in a menu. And the full arsenal of other options would be just one click away. As it is, the user is stuck with the order which the developer thinks is important, and in my case, where I normally always want to see the rectangle features, I have to go over to the option, click the rectangle pointer, then scroll down to get what I want. Whereas I couldn't usually care less about the crop/scale option that is first on the list. Maybe not a big deal, but just annoying enough to make me gnash my teeth. not a good choice go bug Mandrivel about that. The fact that they are already distributing something called 2007 clearly shows their numerical marketing strategy. Completely OT: I remember the days when US carmakers brought out their next-year's designs in the fall - eg, the 1964 models were introduced in fall of 1963. So maybe this is Mandrivel's strategem. My grandfather was a Ford dealer, and always took great pains to conceal the newly-arrived models from the public until the Grand Unveiling. To the point that he would drive a model from his garage to the public display the night before with bedsheets over it, driving down the back alleys in the wee hours of the morning. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More interface rantings
On Fri, Oct 20, 2006 at 11:36:48AM -0700, William Skaggs wrote: Scott, thanks for the feedback, although you could try to be a bit less emotional about it, since this is after all a development version. Sorry, I tend to get emotional over tools like the Gimp that I have known and loved for many years Several of the things you complain about have already been changed in the most recent builds, motivated by feedback similar to yours. good.. Others simply reflect that you haven't learned yet how to use the new features. For example, if you always want a 300x200 crop region, you can set the width and height in the options, *and activate the checkboxes next to them*. If you do that, then the width and height will stay fixed no matter what you do with any of the corners. So two more mouse clicks. I'll learn, I'll learn But the deal with the lower-left/upper-right handles being movers and the other two being stretchers has been a feature of gimp for a long time. I checked on the version 1.0.4 on this ancient machine I use at my real workplace, and it is the same there, and was until 2.2. Why would that suddenly be changed? Very disconcerting. I also completely fail to see any reason why areas outside the image should be selectable by a crop tool. If I lay a paper photograph on a table and take an xacto knife to it, do I reasonably expect to cut out part of the table along with what I cut out of the photograph? It is nonsensical. Can someone point me to a hint on how to get the newest CVS version? I don't have lots of time, but I guess if I have further comments I ought to be looking at the newest bleeding edge. Thanks for your help, I'll check out the checkboxes tonight. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, Oct 13, 2006 at 09:19:29AM +0200, Michael Natterer wrote: On Fri, 2006-10-13 at 01:04 +0200, Michael Schumacher wrote: No. You don't want to look at emacs code. Really. Such an interface is easy enough to implement, should we ever decide to want it. I seriously doubt its usefullness for the vast majority of GIMP users. Why not??! As a user, I would very much welcome an emacs-style interface. Ctrl-H a (apropos) would logically do what is being discussed here. Ctrl-H c to describe the command associated with a key would be excellent as well. Those commands run lightning-fast in emacs compared with the snail-like workings of the gimp/gtk. But whatever you do, please, please, PLEASE do not do as one poster suggested and eliminate single-keystroke commands!! The ability to assign your own keys to gimp commands on the fly is one of its shining features, IMHO. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-ruby progress
I've been working on the gimp-ruby binding. The project is almost complete except for an interactive console, gettext support, and documentation. Otherwise you can register procedures in a way similar to script fu, call procedures as Ruby methods, and use GIMP types as Ruby objects. The interactive dialog is missing some of the features that the script fu dialog provides, but is otherwise functional. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fact roundup
On Thu, Jul 20, 2006 at 03:02:52AM +0200, Simon Budig wrote: Well, we (as in old gimp farts) are dealing with this kind of shit for at least four years now. If anybody of us would be able to understand what Carol is asking for then there would be no issue - we would answer her question and the issue would be no more. Hey, I am a new gimp fart - just a user, and don't know why I am even subscribed to this devel list - but have seen the cryptic messages from Carol and found them somewhat entertaining, though cryptic. As a newcomer to a list, not knowing the history, one wonders at the obscure references to 'someone's girlfriend', etc. My suggestion would be that Carol either lay the cards on the table, giving a logical point-by-point list of her complaints, stated in language that even a newcomer like me could understand, or cease and desist. Just 2 cents from a one-horse town. Scott Swanson Pendroy, Montana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thanks developers
On Thu, Mar 23, 2006 at 07:07:19AM -0800, Simon Roberts wrote: I've watched, somewhat intrigued, the discussions about abbreviations, user interfaces, and whether it's more important to have elegant, largely unused code, or massively popular code that perhaps isn't entirely clean. I'd like to add my perspective as a user. And mine: I've never used photoshop, so I have no idea what its UI might have that I would like. The point is, I am *used* to the gimp UI, flawed or not. If, for some strange reason, I were to find myself forced to use photoshop, I'm sure I'd be grumbling because it didn't act like the gimp. From a user's perspective, there is nothing more irritating than to have a familiar interface suddenly undergo drastic changes. So please consider very carefully before performing major surgery on it. As to tabbed image-windows, which was mentioned in the discussion, that is easily-achievable with the gimp in fluxbox. Seems to me to be more of a wm issue, unless I'm not understanding what's being discussed (highly likely...) So, I'd like to offer my thanks to the developers: it's a fantastic tool. I'd like to offer my encouragement too: you're doing a great job with very limited resources. Hear, hear! Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] possible mail handling software to consider
On Fri, Mar 10, 2006 at 12:45:08PM -0800, Carol Spears wrote: On Fri, Mar 10, 2006 at 09:08:57PM +0100, Sven Neumann wrote: Hi, Carol Spears [EMAIL PROTECTED] writes: any thoughts about using this software to help manage the berkeley gimp mail lists? We don't need any nazi software that forces people on this list to behave in certain ways. You and anyone else subscribed here is free to ignore any posts that he/she dislikes. i dunno, i was trying to start a discussion and i thought that i asked nicely. I can imagine such software being put to useful purposes. Think about it; how many lists are you on where someone eventually grows weary of a blatant top-poster and sends a flame, which goes out to everyone else and, I suppose, gives each a smug little feeling - but what a waste of time. What if the software were used to: 1. Reply to the poster with a link to a netiquette page; 2. Prepend to the post a brief note saying that the poster has been warned about the evils of top-posting; and 3. Just send the post on to the list. Hardly nazi-ish; just doing automatically what we as good netizens now do for ourselves... This is presuming that the software does fairly reliably catch top-postings. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
On Sat, Feb 11, 2006 at 01:25:21AM +, Alastair M. Robinson wrote: Firstly, I generally have GQView running behind the GIMP and use its internal image browser to locate files. I just drag-n-drop them into the GIMP's window. (You really need a window manager that will allow you to disable click-to-front for this to work well, though - i.e. not Metacity, unless you're up to patching it. That's another issue that's caused similar rows.) That is a good idea. I usually use gqview to find the 1st file I want to edit, then Ctrl-1 - being very unmousy, I never thought to drag-n-drop. I'm using fluxbox, so I'm sure I can get it set up to work for me. Thanks! And for the gr tip too. Ironic, isn't it, that a UI simplification intended to make newbies more comfortable results in me resorting to the shell... I wonder; are we witnessing the coming-of-age of a new generation of programmers who grew up *not* using the shell, and who therefore overlook the importance of shell-like features in the GUI? Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Bring Back the Keyboard!
Hello, I don't know where else to vent other than this list, so forgive if inappropriate. I have just upgraded to mandriva 2006, which includes Gimp 2.2 (IIRC - I am writing from my old office machine which has 1.0.4). I was well-used to 1.2. Haven't had time to extensively check out the newest version, and I'm sure it has a lot of nifty new features: BUT one think that irks me right away is not having any option to type in a filename on the 'open' dialogue! The tab-completion feature of the older gimps were excellent and very useful. I usually know that the image I want is in, eg ~/web/hvr/webready/raw, and typing that in, especially with tab-completion is *WAY* faster than mousing through some list of dirs. Also, I sometimes want to work on files in a dot-prefixed directory, like .fluxbox/backgrounds. Guess what? They don't show up in the list! This problem seems to be rampant in other 'new and improved' apps - gdm, for instance. No way to get any .fluxbox/backgrounds in the gtk+ greeter, that's for sure! IMHO, any app which is asking for a filename as input should give both a keyboard-oriented and a mouse-oriented means of providing it. How much extra work is that to program? *Especially* when it has already been done, and done well, in previous versions??! /rant Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
On Fri, Feb 10, 2006 at 02:36:19PM -0800, Carol Spears wrote: On Fri, Feb 10, 2006 at 02:06:52PM -0700, Scott wrote: IMHO, any app which is asking for a filename as input should give both a keyboard-oriented and a mouse-oriented means of providing it. How much extra work is that to program? *Especially* when it has already been done, and done well, in previous versions??! well, welcome to the free world. i suspect that you have to buy this functionality from novell. Sorry, I seem to have unwittingly stepped into some hornet's nest. Novell? I have no idea what is meant. I'm just an ignorant user who used to like the way gimp worked, I have no clue what Novell would have to do with it now not working. It must be an inside joke. I thank Alexandre very much for his suggestion to use Ctrl-L. And all of you developers for an excellent program. My uncle used to be heavily into graphic design; he was up here for vacation one summer and I was telling him about the gimp. He sort of rolled his eyes at the thought of using anything that was free, but he took a look and soon his eyes were popping out of his head instead. Cheers, Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp-developer Digest, Vol 21, Issue 33
William Skaggs wrote: First, it's not clear whether you are bothered by the resources Gimp consumes in creating lots of layers, or by the nuisance of managing them. If it's the former, don't worry about it: text layers are very lightweight, and you can create hundreds of them without putting much of a burden on Gimp. If it's the latter, that's a different story. At some point Gimp will get the ability to group layers together and collapse the groups in the Layers dialog, but not quite yet. That will be great when it happens. The short-term problem is that the files I generate are very large (12,500 x 2500 pixels x 15 layers that I need to access easily). Here's the example that I'm currently working with: -rw-r--r-- 1 skod staff188878323 Jun 29 10:08 image.xcf That's not a typo... In any case, stacking up a large number of text layers on top of the layers with the graphical info I need is a bit painful. And you can imagine that major layer manipulations on layers that large can be very resource-intensive. A simple save of that file takes 4 minutes and 20 seconds. Since yesterday, I've found a couple of useful workarounds: First and most importantly, do *not* create an empty full-image-size layer for the text before adding it in. Doing so was required in the old Gimp, but in the new one it makes the merge with the many tiny layers that get created with each 2- or 3-letter annotation very slow. Instead, just add text and repeatedly merge so that only the first new text layer is retained, dynamically growing with each merge. This makes the rendered text layer (significantly!) smaller than the entire image size. The smaller dataset helps keep Gimp away from the swap thrash that it would otherwise encounter, and makes the merges remarkably faster, especially when first starting the annotation process. That might be worth mentioning in the doc... Secondly, merge all the text layers every 30 or 40 annotations, *especially* before attempting to pan the view into a new area of the overall image- also to minimize the overall data structure, presumably make viewport clipping easier, and avoid the swap thrash. Minor aside: dynamic key bindings are a godsend. I long since bound the merge-down to lowercase L on the keyboard, and I'm getting a bit more used to it now... Due to the enormous datasets I need to work with, I seem to be constantly running right up against the thrash limits of the tool (tile cache set at 256Mb on a machine with 1Gb physical memory). It's the nature of the work I do. The bottom line is that I'm probably working with slightly larger images than the average user. Time for a dual-2GHz G5 with 4+Gb of main memory, I think. Nothing succeeds like excess! The best suggestion that I can think of, if you really want the old nasty behavior back, since your situation is probably so unusual as not to be worth supporting in the core, is that it would be possible to write a plug-in that would behave more or less like the old text tool: you would make a selection, activate the plug-in, a dialog box would pop up allowing you to type some text, and when you press Okay the text would be written onto the image at the site of your selection. I might have to work on that at some point soon, once I can get this dadgum paying work out of the way. Coding is not my primary forte, but I'm sure that there is some unsuspecting plug-in out there that I could shamelessly plagiarize as a framework. My needs are pretty simple here- black text in 10-pixel Helvetica in the currently selected layer will always work for me, for example. It could even auto-anchor: I don't even need to be able to move it after it is placed. Or if I do, I'll select it as a separate action. Still, I'll bet that I'm not the only stick-in-the mud out here. (;-) There are technical applications for this tool, like mine, that far exceed what it was probably intended to do at the outset- and are probably orthogonal to the original authors' intentions. And there are probably other nerds like me that will run aground on this, and will wish for the old nasty behavior. If it isn't too painful, it might be worth considering a backwards compatible mode, even though it is ugly... The true magic of the Gimp is that it works as well as it does on these enormous datasets. Thanks for the quick responses! All help is appreciated. -skod -- Scott Griffith ISES-LLC 9745 Steeplechase Drive Franktown, CO 80116 303-660-2541 303-660-2542 fax [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Text question
Just upgraded to Gimp 2.0.0 (under Mac OS X 10.3.3). Everything works well, and most things work *much* better than the great old Gimp 1 under Solaris I've been using for years. The 1Ghz Mac does outrun my old 400MHz Sparc machine by an enormous margin. Big win. Thanks to all you developers for a job well done... Except, unfortunately, for text- and it's a just user-expectation problem. The new behavior of creating a new layer for each individual text object by default breaks my workflow. My tasks using Gimp involve adding literally hundreds of individual text annotations to very large (~200Mb) multilayered image files. I realize that having text set up to go onto separate layers and remain editable will be useful for almost every user of the tool. But it is broken for me, since there doesn't appear to be a way to turn this behavior off and return to the old simple approach. My whole working style has evolved around the old method of simply and quickly rendering it onto the active layer, which I treat as a generic scratch layer while doing the image analysis chores I need to do. The only way I've found of imitating the old Gimp behavior is to tediously merge down the newly created layer after each item is entered- a very, very painful and extremely time consuming process when working with extremely large files (each merge takes 25-30 seconds in the file I'm currently working with). Is there a workaround? Failing that, can this be regarded as a plea for a backwards compatible render-to-active-layer mode in the Preferences (or tool options) for those few of us users who actually liked it (and depended on it!) the old braindead way it was? After RTFM and finding no workaround, I tried to check the archives of these mailing lists for clues, but the archives I was able to locate at lists.XCF.Berkeley.EDU haven't been re-indexed since September of 2003. A search of the rawfiles produced only discussion of the new features, and Google searches did not provide any useful information either. So: I'm going to the source, so to speak. (;-) Thanks in advance for your help, and for all your efforts. Adding this new functionality into the text tool has clearly required a lot of effort from a lot of folks for a lot of years: sorry for the semi-negative feedback. As I said, kudos to all of you for the hard work it has taken to make this tool what it is! -skod -- Scott Griffith ISES-LLC 9745 Steeplechase Drive Franktown, CO 80116 303-660-2541 303-660-2542 fax [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
