Re: [nick lamb] UI again
So what happens when the four plug-ins in a dynamically generated sub-menu are called: _C_ool splash effect _C_ool burn-through _O_rangify _C_lout You shouldn't even have to worry about issues like this. Naturally, repeately pressing the "C" key would toggle through the list of available items that have "C" as the shortcut. Doesn't GTK already automatically provide for this? The only difference in this case, instead of instantly invoking the menu, only focus would be moved, and there you would have to press "Enter" to accept the menu. Again, that's common sense operation the user would expect from the menu. And since plugins provide a suggested location inside the gimp_install_procedure, you can always attempt (at least for stock plugins) that a separate, meaningful letter is used for each. One could analyze a string such as "Selective Gaussian Blur" in the context of other "blur" entries, and have something like: _B_lur Gaussian Blur (_I_IR) Gaussian Blur (_R_LE) _M_otion Blur _P_ixelize _S_elective Gaussian Blur _T_ileable Blur See, that wasn't so difficult, and we still have 19 letters of the alphabet left to assign around that particular menu. But now instead of doing a lot of little mouse motion, I can right click, and type "F-B-S" and I am at the Selective Gaussian Blur dialog. Pretty slick, considering the time to press those 3 keys is definitely less than moving the mouse and clicking the appropriate menus. Not to mention that if you make a mistake you gotta right click again and start over. I am not saying anyone should force new plugin developers to control how external plugins define these shortcuts, but as long as the core plugins follow a sane and intuitive naming, then there is no problem. And like I said above, even if there are conflicts, all it does is allow to cycle through the available "conflicting" choices, but instead of activating the first one, would require pressing "enter" on a particular focused menu. And if a plugin doesn't provide an underline entry, one could be automatically generated after eliminating all existing entries already assigned, then following First Letter Underlined, and if that isn't possible, to some other one etc. Hmm? That is the problem you must solve if you want there to be a useful underlined symbol in each entry in each menu in Gimp. You must also solve it for the multi-lingual and other cases, but just the "easy" case should be enough for now. I provided examples of the international use in my previous post. To reiterate it here, you either a) translate the underline, making sure it is still meaningful in the native language, or b) handle it the way asian software handles it, and that is adding a shortcut in parenthesis after the menu item name: "J(_O_)... Ctl+O" translation "Open(_O_)...Ctl+O" "I¹(_X_) Ctl+Q" translation "Exit(_X_) Ctl+Q" Gimp's ja.po already uses this scheme for the top-level menus in the gimp toolbox window. It should be kept to [ja|ko|zh].po though, because that's how they are used to using it. Latin-1 languages should use normal underlines inside the menu item name. Languages such as Russian or those with extensive alphabet entries below first 128 characters of the ASCII set should be handled no different than Latin-1 - that is menu entries translated, and an intuitive letter of the native alphabet underlined. Does GTK handle high-bit-set accelerator keys? It should, if it's going to be a useful GUI toolkit. These are guidelines most sane software follows which is written for that other desktop operating system. I may not necessarily agree with translating underlined shortcuts into a native language because it would confuse someone who deals with English version and gets used to the english ones, as I had to do (see previous posts), but I think number of these kind of people is less than one would have to worry about. And that's my personal opinion so it could be easily ignored. Hopefully this clears out some of the menu issues. A Window key - mapped to Super/ Hyper, and used for... Windows. Most people who care are using these to control their... Window Manager. A properly thought out way of using a GUI. Gimp already uses too many controls that are likely to be mapped away and then "mysteriously" not work. Any way the right key would be the Menu key, not the Window one, and mine is mapped to (duh) the system Menu. Hey, that's -YOUR- window key. Throughout this thread I felt like I was always being talked down because these are -MY- ideas. Nobody wants to hear them because they are -PERSONAL- and -YOU- don't -LIKE- them. Instead, why not make things like that configurable? That preferences dialog needs to be unkludged, and how about seeing an option like: "[x] Grab Win95 keys for Gimp" "Use [ Windows ] key to invoke the root menu" [ Menu] Naturally, clearning the "Grab" checkbox would disable the selection below, so those
Request To Revert Curve Tool
2000-11-29 Austin Donnelly [EMAIL PROTECTED] * app/curves.c: Applied patch from David Hodson [EMAIL PROTECTED] to fix Bug#33399: GIMP crashes when applying curve to Grayscaled image when preview is off. Previously the curves tool attempted a reset when changing image, but didn't correctly do this. Now it has the (more useful) behaviour of doing a partial reset, where the curve remains the same across multiple invocations, allowing you to apply the same tweak to multiple images. The internal state relevant to image type/depth is correctly reset, stopping the segfault behaviour seen before. Well, after two weeks of trying the new behaviour, I find myself not liking it and request that the initial range transform from old to new just be the identity transform, as it was before. Alternately, I request an added toggle button to set the preferred kinds of initial state. 1. I find the new behaviour useful only when my intended effect is "something like" what I tried before, but this is not always the case. Often, my intent from one invocation of the curve tool to the next is along different lines, and in those (very frequent, for me) disjoint cases, I find the best starting point is the one that applies no transform to the image at all: the (former) identity mappings. This permits me to start my explorations from the image I have to what I think I possibly want. Now I have to somewhat unapply the old transform before intuiting what the new transform should be. 2. Individuals interested in applying similar transforms to a variety of images already had a remedy (which is still in place), saving a particular transform to file and then reloading it again. The current interface change does make this work flow more efficient (no save/load), but, I claim, at the cost of the disjoint case workflow, the one I frequently (typically) follow. 3. The change in interface has introduced something of an initial state bug, which I will report if the group thinks the new behaviour should remain in place. When the curve tool recalls the previous (not identity) transform, the image itself remains unchanged, as if the identity transform is in place, and not the actual transform manifest in the curve tool. The tranform ought to be applied so that the image state matches the setting of the curve tool. The "flash" of tiles suddenly updating would also furnish a visual cue to the user that the transform inside the curve tool is currently something other than the identity transform. This is a fairly trivial bug to fix; one applies a "pseudo mouse move" to invoke image_map.c logic. If I fall into the minority in this issue, then I (alternately) request that a toggle button, somewhat like the preview toggle button, be put in place so that those of us who prefer the old behaviour (start from the identity transform) can put the policy in place. Thank you for your attention; I hope to hear alternate opinions. Be good, be well, Garry Osgood
Re: [gimp-devel] Request To Revert Curve Tool
Garry R. Osgood ([EMAIL PROTECTED]) wrote: 2000-11-29 Austin Donnelly [EMAIL PROTECTED] * app/curves.c: Applied patch from David Hodson [...] image, but didn't correctly do this. Now it has the (more useful) behaviour of doing a partial reset, where the curve remains the same across multiple invocations, allowing Well, after two weeks of trying the new behaviour, I find myself not liking it and request that the initial range transform from old to new just be the identity transform, as it was before. Add me! Alternately, I request an added toggle button to set the preferred kinds of initial state. Maybe a better Idea would be (but this is definitely a new feature) to have some kind of history, where you can recall the last three (or so) curves... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
RFC: The future of The GIMP
The future of The GIMP December 2000 by Sven Neumann Michael Natterer This document is meant to be a RFC (Request For Comments). Nothing described in here is a fixed decision, everything can and should be discussed. The reason for writing this document now is that the final release of gimp-1.2 is very close and we need a roadmap for the time thereafter. We will propose our ideas for the future of The GIMP here. A lot of these ideas are based upon the discussions we had at the 1st GIMP Developers Conference which was held in Berlin earlier this year (see http://www.gimp.org/gimpcon/). Our core proposal is to have three branches after the 1.2 release. We'll tell you later why we think this is a good idea. First let's have a look at the branches and see what they provide: The 1.2.x "Maintainance" branch --- This is the usual maintainance branch. Only bug-fixes go in here and only if serious bugs are found and fixed, there will be a gimp-1.2.x release. We will also consider putting upcoming stable releases of important plug-ins (like Gimp-Print) into the stable branch. Hopefully not too many releases will be necessary. Probably someone will port GIMP-1.2 to GTK+-2.0 once this becomes available and an 1.2.x release will be made supporting GTK+-2.0. This would be similar to what happended with gimp-1.0.3. Actually we think that it makes more sense to do the port to GTK+-2.0 entirely in the 1.3.x branch as described below. The 1.3.x "Cleanup for 2.0" branch -- This is a development branch, which means that new features go in here. As the name suggests, we would like not to include too many new features here but to focus on other goals: o Port gimp to gtk+-2.0 As soon as the GTK+-1.3 branch stabilizes and the API has settled (which seems to happen right now), the gimp-1.3 branch will start to require this development version of GTK+. o Cleanup some internal structures As explained in more detail below, the gimp-1.2 codebase is full of crap. The main goal of the 1.3 branch should therefore be to cleanup the internal structures without changing the external functionality and look and feel of the application. All data objects have to be converted to real GTK+ objects and all dialogs that provide a view on these data structures (think of brushes, layers, ...) should make use of a clean model-view concept. A proper controller interface needs to be provided to enable changes to the underlying data structures via a clean interface, no matter if the request comes from the main application's dialog or from some plug-in. o Implement a few, well defined, new features A lot of nice ideas have come up in the meantime (have a look at the wishlist on our bug database for some examples) and some of them should be comparibly easy to implement. We will need to make a well-defined list of features and accept new features only after thoughtful discussion on the mailing-list. Only if we limit ourselves to a short list here, we will be able to have an 1.4 release within the next year. o Think about a new way to handle plug-in distribution As more and more plug-ins go into the main gimp distribution (and a lot of plug-ins are wating to be included), it becomes difficult to maintain them all. Core developers are busy enough with the core application and shouldn't have to fiddle with all those plug-ins. If we can think of a better model for plug-in maintainance and distribution, we should try to implement it in this branch. Once this work is done there will be an 1.4 release. This release will work with GTK+-2.0 and will provide a backwards-compatible plug-in API. Probably we can not achieve this goal due to unavoidable changes to the plug-ins' Gtk+-code but it shouldn't be hard to port plug-ins to gimp-1.4. The 1.9.x "Building GIMP 2.0" branch This branch will start in a clean gimp-2.0 module on CVS. After setting up a directory structure (which should be much finer grained than what we work with now), work will begin to implement the design as discussed at the GIMP developers conference. Fortunately some work has already been done: o GEGL -- Gimp 'E' Graphical Library GEGL is an image processing library based on GtkObjects written mainly by Caroline Dahllof and Calvin Williamson. This library will provide the core gfx engine for gimp-2.0. It is available with lots of documentation in the gegl module on gnomecvs. o GCim -- The convergence integrated media object and utility library. We can't tell you too much about this yet, since this library has not yet been released to the public. This is something we (Mitch and Sven) and others have worked on during the last months at our employer, the convergence integrated media GmbH. We will release this as open source very
Re: RFC: The future of The GIMP
I realise that it's probably too late already, but dare I say C++? Did anyone ever even consider this? As for the plugin distribution, I think the nicest way would be to have a plugin manager that would enable you to download plugins from the web on the fly. Something Linux distributions have too, you just connect to the server, list the available plugins, let the user select what he/she wants, download and install them. That would IMHO certainly be the nicest solution. Lourens
Re: RFC: The future of The GIMP
On Tue, Dec 12, 2000 at 05:08:03PM +0100, Lourens Veen wrote: I realise that it's probably too late already, but dare I say C++? Did anyone ever even consider this? As for the plugin distribution, I think the nicest way would be to have a plugin manager that would enable you to download plugins from the web on the fly. Something Linux distributions have too, you just connect to the server, list the available plugins, let the user select what he/she wants, download and install them. That would IMHO certainly be the nicest solution. A good way for updating selectivly as well... I agree that the install should be the distro or main compile's job, but this should be an option as well. Ie: I personally update my system to the latest .debs every few days, while other people only upgrade every time a new release of their distro of choice (tm) is released. Two different meathods. How about these different ways: - distro packaging: the maintainer of the deb/rpm/tgz/whatever does their thing and sets up the package - compile packaging: When someone compiles gimp for the first time (or the first time they run it?) they get asked if they want to get the latest plugins (choice of all, minimul, normal, choose each one), and a little client goes and grabs them from plugins.gimp.org This could get weird for root vs user, but it could be a matter of "we've detected you are root, do you want to install plugins globally?" - user install: User chooses "update plugins" from the help menu and a similar, though gui based, thing happens as with the "compile packaging" and they get to install the latest and greatest into $HOME/.gimp/... Just my $0.02, as a user. Arc -- Arcterex [EMAIL PROTECTED] -==- http://arcterex.net "I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson
Re: RFC: The future of The GIMP
On Tue, Dec 12, 2000 at 05:59:56PM +0100, Fernando Herrera wrote: Tue, Dec 12, 2000 at 04:40:54PM +0100, Michael Natterer escribió: o Think about a new way to handle plug-in distribution As more and more plug-ins go into the main gimp distribution (and a lot of plug-ins are wating to be included), it becomes difficult to maintain them all. Core developers are busy enough with the core application and shouldn't have to fiddle with all those plug-ins. If we can think of a better model for plug-in maintainance and distribution, we should try to implement it in this branch. What about using a distribution system like helix-updater (or newer RedCarpet)? We can use a machine (i.e: plugins.gimp.org) where gimp itself (or gimp-udater) retrieves a xml list from(http), with all the plugins stored in the "system". The "system" can store a lot of precompiled plugins, with version numbers, priority for upgrading , etc Also a good interface for maintaners, to upload new versions is required and maybe a main coordinator yeah, indeed. I've put a little bit of investigation into this, but never pushed it too far. Just a matter of doing it seems. We have folks involved with Red Hat Network, Helix Updater, Eazel Services, rpmfind, and apt-get on this list and involved with the project, somehow I think we can figure something out ;- Adrian
Re: [gimp-devel] Menus, shortcuts, and internationalization
On Tue, 12 Dec 2000, Simon Budig [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: On most software packages (not for Linux, though), the "underline" action keys are generally organized well enough so that it's quicker to push that key instead of moving the mouse. For laptop users this is true especially since most laptop mice don't have as much control as standard desktop mice. If you ever tried to pick a menu item from a 1024x768, 10" laptop screen , using a kludgy input device like a touchpad or one of those pointing sticks, you would appreciate the ability to push a key instead of moving the mouse. Dont argue with speed: Pressing Alt-F + x to exit a program is definitely more complicated than pressing Ctrl-Q. This goes double for nested menus. (As a sidenote: I dont think, referring to bad equipment does help us much in this case. Everybody, who touches up photos on a 10" LC-Display with a touchpad and expects a seamless workflow is nuts. You could also expect Gimp to run smoothly without restrictions on a text-terminal... :-) Although I don't like timecop's style and arrogance (timecop, please change your style if you expect more constructive replies), I think that he has a good point. The example with Alt-F + X may not be the best, but the idea of allowing all menu entries to be reached by a sequence of keys is good (not that I would implement it, but still...) I do not think that I am totally nuts, and I do use the Gimp from time to time on a laptop that has a small screen and a crappy trackpoint. Of course I only use it for simple things (mainly web-quality images, not high-res photos), but it works reasonably well. I do the more serious editing on my PC at home when I want a better quality, but the laptop is sufficient for quick and dirty work. And indeed, I have wished several times that I could use the keyboard to access some of the plug-ins. And I do not know any better solution than the one that timecop is proposing, because the current way to assign shortcuts to menu entries is limited by the total number of keys that are available (multiplied by the number of modifiers) and it would be impossible to remember all of these unique combinations anyway. I believe you are missing the point. Nobody is complaining about general shortcut keys. Things like Ctrl+L are never going away. This has nothing to do with the issue I am talking about, which is putting accelerator keys on menu items to allow faster navigation once the menu is already open. You are talking about using Alt-F to open the File-Menu. Since you have to invoke the Image-File Menu to be able to save images the general shortcut "Alt-F" would be lost for normal operations. (like repeating the last plugin). This is something that should have been mentioned earlier, and it is a pity that timecop sent his inflamatory mail instead of calming down and trying to find the root causes of the problems that he described. The shortcuts in the Gimp lack some consistency in the way they use the modifiers. Alt and Ctrl are used everywhere in the menus and the combinations of letters and modifiers were more or less chosen on a first come, first serve basis (plus some influence from other programs). Some other programs stick to the (MS?) guideline: use Alt for opening the menus, and Ctrl or Ctrl-Shift for invoking some action directly without opening the menus. Using the Alt key for opening the menus (toolbox menu or image menu) would mean that the (very useful) Alt-F shortcut would have to go. It would have to be re-assigned to some Ctrl-key combination. A lot of other shortcuts would have to be replaced, but in the end I think that the final result could actually be easier to use for everybody. Please do think about it for a minute instead of throwing the idea away because of timecop's arrogance. I tried to think about the pros and cons, and I think that a more consistent way of assigning the shortcuts could help in the long run. Anyway, this is a major change that should definitely not go into 1.2, but maybe it should be considered for 1.3/1.4. [...] So you tell me that you would like to grab for the mouse to right click for the menu and then reach for the Keyboard to navigate through the menus and think that this is more optimal than a direct shortcut on the keyboard? I don't think that his idea of requiring a right-click in the image for opening the context menu and _then_ using the keyboard is a good idea. Instead, I would prefer that Alt-F opens Image-File directly, and so on for the other entries in the context menu. If you pointer is over the toolbox and not over an image, then it would open the File menu in the toolbox. [...] I imagine most of you *hate* the Win95 key that you get for free on most keyboards (all of them now, actually) - but why not put it to good use? Why not make it open the gimp's right click menu? Because Gimp already uses
Problem building gimp-1.1.30 RPM
Hello, when I try to build gimp-1.1.30 on RedHat 7.0 I get the following error message: make[2]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/redhat/BUILD/gimp-1.1.30« make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/redhat/BUILD/gimp-1.1.30« + strip /var/tmp/gimp-1.1.30-root//usr/bin/gimp strip: /var/tmp/gimp-1.1.30-root//usr/bin/gimp: Datei oder Verzeichnis nicht gefunden Bad exit status from /var/tmp/rpm-tmp.34439 (%install) Has someone a specfile that works with RedHat 7.0 ? Bye, Henning
suggestion for gimp 1.3 and later
I think it would be a good idea to add a grid function like some other programs have. It is hard to work with a guide grid at 10 pixels or something toggled visibly on and I don't think it snaps quite the same as a grid. So what about a grid that could be toggled on and off at a varying width where something could NOT be placed other than with starting and/or ending points on the grid. Like if a layer is moved or a selection it snaps in units of 10 and never lands in between. Also so the grid is not visible and can be started from a set point. My apologies for not being able to create this function myself, but I am not able to program. Also, is there any way to make dialogs so we can copy-paste from them? I at least can't seem to with my wacom. This would be nice for error msgs, author e-mails, etc. Thanks! bex
Re: [sven] UI again
On 12 Dec 2000, Sven Neumann wrote: I think it will not work. Your ideas are not actually new and we have discussed this stuff a lot coming to the conclusion that it's not that easy. Why not? Where is the "a lot of discussion" link so that I can see it for myself? This is a question unrelated to the above, but does GTK have a "forward focus" setting for controls? It is for situations like described in one of my emails, where user clicks or selects a text label, and the focus actually goes into the control next on tab-order, which is usually a text entry or a checkbox, or whatever, associated with that label. tc -- timecop at japan.co.jp | $B#O#ADL?.%5%S!<%93t<02q
Re: [gimp-devel] Menus, shortcuts, and internationalization
Date: Tue, 12 Dec 2000 15:31:07 +0100 From: Simon Budig [EMAIL PROTECTED] Dont argue with speed: Pressing Alt-F + x to exit a program is definitely more complicated than pressing Ctrl-Q. This goes double for nested menus. In this *particular* instance, faster != better IMHO. Exiting the program is a sufficiently destructive act (even if all of the files are saved -- you lose the undo information, the clipboard, etc.) so that it shouldn't be that easy to do unless the user wants it to be that way. That said, in emacs I've bound C-xC-c to a function that prompts me for whether I want to exit, but in the shell I unset ignoreeof (so that C-d exits me). It's a matter of personal taste here. However, I don't like that fact that C-q exits and C-w closes windows in a lot of applications (and exits if that was the last open window). It's probably due to emacs being in my fingers. This is a rather specific comment, and deliberately doesn't address the general issues surrounding accelerators.
Re: suggestion for gimp 1.3 and later
On Wed, Dec 13, 2000 at 12:27:42AM +0100, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: It is one of the things I dislike of GUI: you can not copy info from screen lots of times. In the GNOME GUI list there is a proposition to I think the best way would be to make any gtk label/text widget be selectable. I don't know why this has not been done so far, but it might be an interesting experiment. I, for one, always wondered why there is text that I cannot select. Except that it might be easier for the programmer to implement I don't think this serves a purpose (well, maybe less memory, but...) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: RFC: The future of The GIMP
Someone today mentioned something about a new way to manage plugins. I think the users would enjoy a plugin manager similar to the Helix Gnome Updater. Users could fire it up from time to time and be presented with a list of plugins to update or add. I think the Helix thing is open source. It might be possible to use it as a plugin manager. Thanks for your consideration and happy holidays to all gimp friends. -- Jon Winters http://www.obscurasite.com/jon/ "Everybody Loves The GIMP!" http://www.gimp.org/
Re: suggestion for gimp 1.3 and later
On Wed, Dec 13, 2000 at 03:29:41AM +0100, Marc Lehmann wrote: I think the best way would be to make any gtk label/text widget be selectable. I don't know why this has not been done so far, but it might be an interesting experiment. Yes, I've often thought this. And everyone knows that if Marc and I agree about something it must be right (?) or at least it's in no-one's interest to disagree... How do we put something on the GTK+ "TODO" list? Anyone from GTK+ still hang out on gimp-devel, or are the two worlds quite, quite separate these days? Nick.
Re: repetitive stress . . .
On Tue, Dec 12, 2000 at 09:46:21PM -0500, Andy Deck [EMAIL PROTECTED] wrote: The attached image demonstrates a problem that I think ought to be remedied... Basically, when the disk is full, there is not much one can do. BTW: what, *exactly*, is your problem? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
