Re: [Gimp-developer] Status OpenUsability student project
Sven wrote: just a quick note to inform you that the usability weekend was a great success. Thanks. Inspired by the weekend I thought it was about time I joined this list. Sometimes (but not always) I will chip in to inject some interaction concept into the discussion here. I have blogged about the weekend from my point of view. teaser: Along the way some hard choices had to be made by the team about what workflow to support, and what to leave to other applications. Moreover, essential functionality has been identified during the weekend and implementation of some of it started right there and then. read more: http://www.mmiworks.net/eng/publications/2006/11/creating-user- scenarios-with-gimpteam.html --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Status OpenUsability student project
GSR wrote: One question: creating original art, from 'found images;' is creating original art like concept art or full illustrations, be it realistic, comic, abstract... (that is what I understand for original) using references; or do collages and other photo composition (that is what I would understand as 'original' from found images)? The scenario for this actually includes the words 'collage' and 'wild brush work' to catch the vibe. The results need to be new art, and we are sure that bitmaps, scans and/or vector graphics need to be imported/opened in GIMP to do this successfully. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Status OpenUsability student project
GSR wrote: The scenario for this actually includes the words 'collage' and 'wild brush work' to catch the vibe. The results need to be new art, and we are sure that bitmaps, scans and/or vector graphics need to be imported/opened in GIMP to do this successfully. What is wild brush work? the words are used to catch the vibe, you know... ^} not too subtle alterations using brush tools. Alienating the resulting image from the found images that went into the process. And is just painting or colouring nowhere in the cases (as separate case, it is clearly not)? There are simply other applications that are better adept to painting from scratch, one of them is called Painter, I believe. Second of all you have to realise that the user scenarios are the essential description of the essential use of GIMP. That's two distillations. But they focus our minds to get things done. Lot's of in-between and borderline cases do not need to be described. They would just bloat up the user scenarios and make them useless as a tool for us. Painting from scratch is simply not in the product vision, the GIMP team has set other priorities. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Status OpenUsability student project
GSR wrote: There are other apps for icons too (a from scratch task in some cases, btw). We are sure that icons will be first constructed as vector graphics and then finished in GIMP. Seeing that one and not seeing painting, colouring or creating textures looked strange among all the other more photo-related tasks specially when for past years people have being colouring their comics, creating textures for 3d art and so on with gimp. Again you are taking things too literal. Not having your exact personal use case named one of the essential for GIMP does not mean we are going to forget about you. We are covering thousands of specific use cases for GIMP by the sheer number of linear combinations you can make from the essential use cases we are considering. That's the power of the methods I use. But to save GIMP from the dying like a dinosaur, we had to set some priorities. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [Gimp-user] Color selectors, which one do you use?
CMYK I find most unintuitive. The purpose of the CMYK selector is not to allow intuitive color selection. Actually, during the user observations we found out that print-oriented professionals have learned to thing in CYMK. So we need this mode for them. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Polygonal Selection Tool Re: Bug 119646
Paul Gnuyen wrote: I don't know what full specifications look like for tools in the gimp but here's a shot. The Polygonal Selection Tool Selects regions by connecting points clicked with line segments There is a cost (complexity, usage of UI bandwidth) to every tool that is added to GIMP. May I ask why are you trying add a tool that does a small part of what the path tool does, and then an automatic path-to-selection? If you can tell me why it is worth the cost, I can help you to make the specification better. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] string freeze for 2.4
Sven wrote: If you feel that it's too early for a string freeze or have larger string changes pending, speak up now! If you want me to sort out and simplify the crop and selection options berfore christmas, then I need the freedom to change any string displayed there. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] string freeze for 2.4
Sven wrote: If you feel that it's too early for a string freeze or have larger string changes pending, speak up now! If you want me to sort out and simplify the crop and selection options berfore christmas, then I need the freedom to change any string displayed there. I mentioned that string changes that fix bugs are fine, didn't I? Hey, I worked with companies where 'making the UI work for humans' were nice enhancements, not bug fixes, in this stage of a release ^} --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.4 workflow break
Bart wrote: So what about if GIMP could recognized what was the last used image window and if you press a specific shortcut that woks only on the image window GIMP will call the command on the last used image window? A very reasonable request. Although Sven is surely going to tell us that things are very tangled in reality. Assuming there are no duplicates in the shortcuts for the main window and all the tool windows (they are not really windows, they have the roles of inspectors and palettes). The only exception I see is for cut/copy/paste et al. That should be possible with text is focussed textfields, and ideally also with other objects, like colors and other atomic items users manage in lists (paths, layers, etc)... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Well what do you know? At the moment Kamila and I are very busy with our (interaction architecture) expert evaluation of the current GIMP, and this morning we happen to stop by the screenshot plugin. We actually took into account all comments made in this thread up to that moment. Here are our findings: Absolute number one: Yes, taking screenshots is a task for the OS/desktop environment. That guarantees that it is available in every app. Also looking at the product vision I do not see screenshots as something essential that GIMP must do. But the the GIMP team consist of nice guys and girls, so they leave the screenshot feature in. Also OK with us, the interaction architects. One delay or two? After looking at the old UI, and the UI in 2.3.13, taking into consideration - the complexities of taking a snap of a window with a menu flapped open or a button being pushed; - traversing trough virtual desktops; - how window managers treat menus; - relative obscurity of the use cases; - the stress on ease of remembering (used every once in a while) of this feature; - the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out). we are positively sure that the solution shown in 2.3.13 is the better solution. One delay, with one meaning. We would like to see however two improvements: 1) A big, fat visual countdown of the delay. I can see a big (200 point font) semitransparent numbers overlaying the screen counting down 4-3-2-1. No more guessing how long do we still have to get that other window in front. 2) A better explanation of the delay. Move the delay value spin-box up a line, behind the word Delay, and take some room below it for a two-line sentence that confirms what will happen next. Use 3 different texts, one for each of the shot modes (window / screen / region), because what you can do with the cursor after the delay is different for each mode. BTW: we did not take into account the use of GIMP by grandmas, only used-in-anger by hard-boiled 'pros' according to the product vision. I think that puts an end to any doubts, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Sven wrote: We would like to see however two improvements: 1) A big, fat visual countdown of the delay. I can see a big (200 point font) semitransparent numbers overlaying the screen counting down 4-3-2-1. No more guessing how long do we still have to get that other window in front. Unfortunately that is probably not possible to implement in a portable fashion. Yeah, only a desktop environment can pull something like that off. Which brings us back to absolute number one: Yes, taking screenshots is a task for the OS/desktop environment. One thing that I could imagine that might work is to use custom cursors. While the pointer is grabbed, we could let the mouse cursor count down the remaining seconds. The delay has one purpose: to allow the user to get her window/ desktop in order, ready for the shot. Maybe better leave the cursor normal during that. Akkana Peck wrote: peter sikking writes: P At the moment Kamila and I are very busy with our (interaction P architecture) expert evaluation of the current GIMP, and this P morning we happen to stop by the screenshot plugin. [ ... skip to end of message ... ] P I think that puts an end to any doubts, Oh, well, that's it, then. There's no point in mere users trying to offer any input. input is fine, if you tell me something that makes me doubt about the decision that I have taken, then I will re-evaluate the whole thing, taking into account all old and new input. P - the fact that it is a piece of cake to cut out a rectangle Pout of a image in GIMP, or two added rectangles (window + Pmenu sticking out). Peter, I have to ask: how much have you actually used GIMP for screenshots? Have you done a lot windows cut from full-screen screenshots? Or talked to users who do? I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users, in order to make 1% happy. The decide to make 99% happy in the standard distribution, and the 1% can use the (already released! go open source!) super screenshot plugin, or a load of other ways of getting the job done efficiently. Peter, I couldn't find in your message where you explained why you concluded the pre-selection delay is worthwhile, while the post-selection delay is not. Can you explain that more clearly? I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. Hence the delay. Taking screenshot of something on the screen is a field that is one or two orders of magnitude broader than taking screenshots of transient user interface elements. Combined with other factors (need exactly the window, user sees GIMP actually as the right tool for this job...) we get to my estimate useful at max for 1% of our users. Clarence Risher wrote: On 1/30/07, peter sikking [EMAIL PROTECTED] wrote: - the fact that it is a piece of cake to cut out a rectangle out of a image in GIMP, or two added rectangles (window + menu sticking out). For the record, windows are not always rectangular, or do not always fill their bounding box. You see, you had me doubting there, but then Sven wrote: The windows are still rectangular […] else I would have given the whole thing a re-think. Marco Ciampa wrote: See ksnapshot for an example of a better interface. So I had a look, one delay, but they also gave me an idea how we can make everybody here happy, without the cost of two delays: In 'snap window' mode the shot shall be taken: a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down. The latter captures menus being open or pushbuttons being down exactly when the timer expires. So you can set a single timer, go to the app, push open or down whatever needed to be pushed and wait for the delay to expire: snap. So this mail has become a running narrative towards a better solution. I thank everyone for their extra input. It helped us to improve GIMP. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Akkana wrote: I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users, Not being an interaction architect, I'm still not understanding. How did you arrive at the 99% number? I explained how I got to the 1%, the 99% are the rest of GIMP users. And 1% is already a very generous, on the safe side, estimate. Do you really think you can round up ten thousand GIMP users who ever have to take a screenshot of a window with something pressed AND consider GIMP actually the right tool for this? You'll struggle to find one thousand, exactly because most would not choose GIMP. But 1% is a convenient number and it drives the message home. I simply want you to concentrate on 99 GIMP users, who will never ever take a screenshot of a window with something pressed, with GIMP. Confront them with two delays, and you make them think what the difference is. You just stopped them working... Now you take the same decision as I had to take. [pre- vs. post- selection delay] I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. To get the screenshot dialog out of the way, you mean? No, to get GIMP out of the way. The 800 pound gorilla that eats a million pixels of screen real-estate for breakfast. Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time? To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case). In general the delay is 'time to get ready'. Get GIMP out of the way. This can be done in a multitude of ways, of which switching desktops is one. I also wonder about discoverability: Sometimes I have to click on the window after the delay, but sometimes I don't. Will people figure out that having a mouse button already pressed is what makes the difference? I already asked for the improvement that we use two lines of text to explain what happens (depending on the snap option) during and after the delay. Everything is cool with the interaction syntax, when the delay expires, the user says 'this one' by either clicking on it, or already holding it up by the ears. And you know what? It feels really good that I have sped up your workflow, compared to 2.2, without making 99 other users pay for that. Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior. Only if you have been taking many screenshots of stuff pressed in windows with GIMP for the last few years. Putting the two delays in the UI on the same level is a big mistake, actually. Makes one even more think what is this selection..? The 2.2 dialog did that better. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Thorsten Wilms wrote: I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for? Yeah it can go. It would only make sense if a Cancel on the jpeg options would get you back to the Save_Image dialog, in case you see that the jpeg compression is not appropriate, you change your mind and go back for png or so... Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling. There's quite a number of ways it could be organized, my mockup shows just one: http://thorwil.affenbande.org/wp-content/uploads/2007/02/ save_as_jpg_integrated_01.jpg I just had a quick look. Later in the expert evaluation we will get to the save for web scenarios and I will be in a better position to deal with this. But for now: If we try to do an all in one, then the result has to look and feel like a dialog, not like a main window, because of the modal nature (finish this first) of the task. It is difficult for me to say whether sawing off more main window bits (no menu bar, tools, palettes, inspectors or rulers; default to magnification tool) and adding more dialog-ness (get buttons out of the status bar) to what you have drawn, or start from scratch on a BIG-preview dialog would be the better way to go. Advanced options hide 'under' the expander. There could be a button to bring them up in a dialog instead. My gut feeling says that there is a better solution available here, but I am only able to work on that after the expert evaluation. File size can be read in the statusbar. Better keep the quality slider and file size (main cause and effect) physically together. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Thorsten Wilms wrote: If we try to do an all in one, then the result has to look and feel like a dialog, not like a main window, because of the modal nature (finish this first) of the task. But this would not be like your common dialog that disappears after Cancel/OK, but rather a window that changes state. I have nothing against the idea of reusing the main window, but as said, because the task is modal by nature, the UI UI has to reflect that with dialogness. It is simply a UI law of nature. That means big changes to the main window, as quoted right below:. It is difficult for me to say whether sawing off more main window bits (no menu bar, tools, palettes, inspectors or rulers; default to magnification tool) and adding more dialog-ness (get buttons out of the status bar) to what you have drawn, or start from scratch on a BIG-preview dialog would be the better way to go. I thought about removing at least the menubar but decided against it, as you can still zoom, toggle guides ... Might be better to not allow access to editing options, though. Toggle guides? There is only one thing to do, and that is set the size vs. apparent quality ratio (with the advanced saving options, I know). The zoom is taken care of with the zoom tool and the controls in the status bar. File size can be read in the statusbar. Better keep the quality slider and file size (main cause and effect) physically together. I wanted to, at first. Then moved it to save width for small images. If windows re sized for the menu bar to fit in (quite natural except on the mac) then I am sure we can get the quality slider and the calculated file size in. BTW, some apps have web export dialogs with side by side panes original/compressed. I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. It's important it can happen with a single click. Yep, well observed... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] healing the healing tool
Helmut wrote: Painting with a brush is just a way to select an area. And a very nice and intuitive one also. The problem with the current implementation is however that it tries to heal while you are painting. This doesn't quite work. I think it would be better if, while you are painting, the tool would work like the clone tool. Then, when the mouse is released, the healing algorithm should be applied on the area selected by the paint stroke. This has two disadvantages. First, you won't see the real effect until you're finished anyway. this I can agree with. Second, this might give many disjoint sets of points, which is difficult to handle in the algorithm. whenever I have to choose between the user sweating a bit or the developer, it will be the one that starts with a d... let's have our priorities screwed in the right way around. There are a bunch of selection tools including the quick mask. Using these it's much easier and quicker to select a region than painting it with a brush. boy, am I glad we went out and did workplace observation as part of the project I am running. that means I can say with confidence that the brush is the way to go. actually healing is applied extremely local, with the tiniest brush, to take out only the irregularity, and not to destroy the all important texture around this spot. In most cases the lasso tool would do. Since the healing tool is of more 'global' nature, being forced to use a local tool like a brush seems misleading. What could make sense would be to use a selection (one in the destination area and a translated one in the source area) first, compute the 'healed' area without pasting it into the destination area, yet. Now the brush could be optionally used to copy parts of the healed area into the destination area. now that we got the brush part nailed, we need to find something for the user to set the source area. To me as an interaction architect the healing brush looks like a smart clone tool on steroids. that means we can use exactly the same interaction as the clone tool. both tools need a bit of cleaning up in the tool options I think. set a source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. set a new source location, heal a tiny bit of the photo. looks as straightforward as it gets to me. A bug has been reported when source and destination areas are of different depth. Since, IHMO, the healing tool doesn't make sense in that case, I'd suggest to simply abort with an informative error message. Why does it not make sense to heal a region in an image using a texture from another image, or from another layer in the same image? The clone tool supports this nicely, so it seems to make some sense that the heal tool supports it as well. The main difference between the cloning tool and the healing tool relies on first computing the quotient of the pixel values in the destination area by those in the source area. Then, these factors are 'smoothed out' by solving a Poisson equation. Finally the source pixel values are multiplied by these factors before they are put into the destination area. Currently the R,G,B values of the destination and source area are divided by each other. How can this be done if there are, say 3 values in the destination area but only 1 value in the source area. the healing brush looks like a smart clone brush on steroids. the solution is already there in the clone tool... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] healing the healing tool
Helmut wrote: Hal wrote: I wrote: that means we can use exactly the same interaction as the clone tool. This is exactly the way this works in photoshop and I can't think of any reason to do it differently. In fact this is exactly what I would expect as a user. Let me explain the difference between the clone tool and the healing tool in more detail. [snip] I get the picture, smart blending clone tool on steroids... Therefore one does need an area D which includes the defective parts but whose boundary must not contain any defective pixels. Please have a look at the example given on page 3 of http://www.tgeorgiev.net/Invariant.pdf can we first of all agree that no photographer would put the source cursor in a highlight area when repairing a shadow area? I am sure that T. (doesn't he have a first name?) did that to show off how cool the algorithm is. If the healing tool were to applied on the fly while the brush is over a defective part, its boundary will most probably contain defective pixels. Let the computer do the work. Add just one pixel around the user brushed area, and bingo! condition met. So, if the 'brush style' of the healing tool is a must, I'd suggest to do away with the healing tool altogether - as a separate tool. Instead one could add a post-processing option to the clone tool which tries to call for the chameleon described above. now there is an idea: healing as a clone option, one tool less. cool. Of course the post-processing part is should be unnoticeable by the user. I can live with a bit of cheating where the user sees an immediate feedback that is just cloning++, and within 0,5 seconds the real healing algorithm catches up. For that to implement, one would need to gather the (set-)union of all the regions having been touched by the brush in the source as well as in the destination area. no. a photographer will be concerned with image fidelity and be moving the source cursor all the time. you will get many tiny disjunct and fundamentally different (different source offset) healed areas. which can be calculated individually, which will be temporised by the speed the user works. In case of your long scratch: even in the unlikely case of the user not using several source cursors along its path, the actual brushing of the scratch will be a painstaking affair meaning relatively slow S and D area growth. Use these assumptions for your optimisation. Forget rectangles, the brushed user selections are it. looks ideal that the user is specifying which pixels belong to S and D. Remember that for the high-end photo manipulation tasks we are designing for here, the users are so discriminating that in principle no computer algorithm is good enough to do things automatic. However that must be painful to a mathematician, we saw this during the user observations. So the healed area will be the absolute minimum, to not destroy photo-realism. Transparency will be used at the edges of the brush to blend the healing, guided by the eye of the user. which is all that counts at the end... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Mark Lowry wrote: It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. like this? http://www.creativepro.com/img/story/20051219_fg5.jpg assigned to a spring-loaded key (push down: magnifier appears, release: disappears). Settings need to be adjustable on the fly, hmmm. magnified area can stay out of the way automatically, without jumpy behaviour, like magic. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Steve Stavropoulos wrote: I really _miss_ this feature! One of the things I do all the time, is selecting rectangular regions from an image, with pixel perfect precision and then copy + paste as new. The important things in implementing something like this are: 1) You have to have an unobstructed view of the image (that's why I don't like peter sikking's proposal) here is the workflow that I am seeing for you: - set the course selection rectangle - grab a side or corner handle, set it pretty damn close, press magnifier key, see magnified view out if the way of your cursor, set corner/edge pixel perfect, release handle, release magnifier key - repeat last step for the other 3 corners/sides unobstructed and precise enough? --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Mark Lowry wrote: Good point. A GIMP magnifier such as we are discussing should magnify the actual image, not just the desktop portrayal of the image. Yes of course. Sorry not to have explicitly written this. If a second, stationary window is used rather than a moving lens, I would suggest that it should have its own buttons for controling the magnification level. also the temporary loupe can have its own zoom level and also I will give it an option to work absolute (to the image data) or relative (to the zoom level in the actual image window). This means you can set it to display the image data at 400%, or 400% of the window level (window is at 33%, result in the loupe is 132%). And all this of course not far away in the preferences, but there when the loupe is there. A few people here seem to favour a permanent loupe window because it would not cover the main image. Now let me first say that additional view windows (different from the cloned main window that the GIMP already had now) tracking the mouse pointer, already have been identified as a requirement in our UI evaluation. These however, do not solve the problem we got here. Now, a permanent loupe window does cover the main window, in a way. It simply eats screen real estate. Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale. I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way. everything speaks for a key-triggered loupe. during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way. the next moment when one is focussed on the macroscopic image, the loupe is gone, taking no screen real estate. gg: mouse wheels are not universally available, so they can never be part of the primary solution. Like second monitors, they are extras, and we provide extra UI and shortcuts to help the people who have them, and actually like them. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven wrote, GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. easiest to implement, yes. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up. Again, I have nothing against a tracking view with a different magnification than the main window. But it does not solve most of the use cases that came up in this thread, only the exceptional ones Raphael came up with. Let's look at a couple of aspects: affordance: I see a lot of value in supporting work macroscopic, adjust/paint microscopic. there is a lot more than selections that can benefit from this. That is why I find it a pity to solve it in a way that can only be afforded by users with seriously big screens. I would like everyone with smaller than 1600x1000 screens to look at their GIMP set-up and figure out where to put an extra 200x200 view. I am on 1280x854 and would not know where to put it. This is what I mean with 'the cost is too high to have it open all the time.' closeness: Experiment for everyone: move your mouse cursor dead centre of your screen. Focus your eyes on it. Now look quickly at one of the corners of your screen (where the permanent view would sit). If you did not turn your neck, you strained your eyes. Is this supporting working swiftly, at a pro's pace? Do you want to strain yourself like that all day? Now compare this to focussing on the dead centre mouse cursor, and quickly looking at an area beside it. Quicker and painless, no? This is what I mean with 'it has to be close (but out of the way) in order to support working swiftly.' size matters: The permanent dialog has to be compromised in size, exactly because it is permanent. 200x200 is a lot of pixels in this context. A pop-up loupe however, can easily be 400x400, showing a lot more image data at the moment that is is needed. final plea: Again, I have nothing against a tracking view with a different magnification than the main window. But is you want to make a real, substantial and general improvement in GIMP and support work macroscopic, adjust/paint microscopic, then a pop-up loupe is the way to go. It is a cool cairo project, and I'd be happy to specify it. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
Sven wrote, Here are some comments to get us started: Resource management This looks like a nice project but perhaps needs to be specified better. This needs a concept, to start with, which will roll out of the evaluation project. It is more about where do we want to go with brushes, gradients and patterns, than about categorising the current stuff and mechanisms. Example: I foresee the four basic brushes (pencil, ink (nib), brush, airbrush) being tuned up and specialised as pure algorithm based brushes, with bitmap or vector based brush as a secundairy option. Create an SDI manager widget Do we really want to ask someone to waste his/her time with this? It is in my opinion not implementable in a sane way and we would likely not accept the results then. If this is supposed to be kept on the list then we need to agree first that we really want such a thing. could convert this into the what is GIMP without an image file? and why are the inspectors/toolboxes actually real windows? project. Additional file format plug-ins Shouldn't this perhaps be titled Improve MNG support? is this really part of core-GIMP (as in fits the product vision?) On-canvas text editing Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing? I am not sure on canvas-editing is that desirable, it clashes with the toolbox shortcuts. To be able to style every single character in a piece of text differently is nice though. Well maybe more than nice. Fits the collage and web-pieces scenarios. We are developing a concept of consolidating multiple text blocks in specialised text layers (not sure if we can get rid of the latter), editable for ever-and-ever, GEGL style. Search-based menu browser Nice and probably even reasonably well specified. The student should perhaps do some usability work on this him/herself (with the help of an expert). now here we got a user interaction can-of-worms. It starts with why do we need this. There is no easy answer from my side to this first point, the issue is very deep, but it smells to me like flagging usability defeat. Maybe tackle the reasons for this request in another way? After this has been answered, moving on to actually giving this idea a user-centred concept (vs. technical) is quite a job. very, very tricky... Redesign and reimplementation of Save and Export in GIMP. We really need to do this, finally. concept for this will come out of the evaluation. SVG brushes Sounds like a nice project for the SoC. see resource management. already old-fashioned? --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
Alexandre wrote: On 3/6/07, peter sikking wrote: On-canvas text editing Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing? I am not sure on canvas-editing is that desirable I would kindly suggest you to install some old version of Inkscape where text selectiion could be done via dialog only and rotating/kerning single glyphs wasn't possible at all :) well, I put that observation immediately in question in the next sentence,that you did not quote. Of course I would not think of doing typography in a separate dialog... it clashes with the toolbox shortcuts. That is a different thing. In my opinion shortcuts need revisiting. now there is a thought-provoking idea, want to discuss it? (off-list if this is a repeatedly-flogged dead horse on this list) --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] have a look in our kitchen...
guys + gals, thanks to Sven, the GIMP UI redesign team has now a wiki where everybody can follow our progress: http://gui.gimp.org Right now we are filling it with our raw evaluation notes. Some of the latest added stuff is so raw that you can track us clarifying it a couple of days afterwards. The wiki is an exiting experiment (for me) in collaboration and communication. It functions as our documentation and for your insight and entertainment. It is not meant to start a flame war. Enjoy reading about our journey, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Chris, First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. don't worry, I am also fired up about this one. here is why: people have talked to me a week or more ago on the irc along the line of: what's the big deal, one way or another will do. here is the big deal: for my pov the dockable magnifier is just-another-feature, it will make some people happy in some situations. the pop-up loupe however, has the potential to be a transformational feature. It has the potential (when properly designed) to fully transform the way most people work with GIMP in work-macroscopic/change-microscopic situations, that go way beyond the mentioned setting selections pixel-precise. saul on the irc made this film (thanks): http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change. I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. practically speaking, this will have to wait for cairo, and I see you are already off the mark. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. I am not sure if Sven wants another feature request in bugzilla. If so I will write it. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven wrote: I am not sure if Sven wants another feature request in bugzilla. If so I will write it. Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports. just checking, because of: I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. then saul wrote: I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area. Indeed, the handle of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). my thanks for you and the 'puter, again. Firstly, there is an effective warping of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). the last point is exactly how it works (also for humans) and means no HIG felonies. Nonetheless, this behavior can be disorienting. It should be noted that the overly-long handle shown in the simulation exaggerates the severity of this problem. the point of my 'must be close, but out of the way' guiding principle. More important is the general nature of the tracking of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port). that is at the user's discretion. I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. excellent point. since the point of the loupe is working precise, the mouse must move at the speed of the zoomed view. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available. your solution really got me thinking. there are multiple other alternatives. at the end it is about having the most stable, predictable loupe placement, and technical feasibility. The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. well, if you want to see the spec of dust to the top-left of your current view better, you move the mouse top-left, and you see the spec of dust centred. sounds good to me... While there are certainly similar loupe gadgets present in a few other programs, the only ones I have encountered are more interested in _viewing_ things at a microscopic scale and not actually _working_ at that level. I am suspicious that the more intense focus of the user entailed will exascerbate the disparities in the screen response to mouse movements. we really will have to work hard to make this reach the transformative potential it has. Working with it is the highest goal. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] internal representation of a selection
Helmut Jarausch wrote: My current plan encompasses a few steps outlined below. Perhaps I'll add a quick mode which would be similar to the clone tool lateron. I have no idea who we will help with a non-quick mode. I see that this tool can be integrated in the clone tool, for an interaction architect that is a 'done deal.' For the quick mode the user starts by specifying a point somewhere within his source area. Then - exactly like the clone tool - he paints the destination area. BUT, once he/she releases the mouse button or lifts the pen, the healing algorithm would be started. I can live with a clone, and then see the paint dry effect, as it gets the job done. It will give bad results if the boundary of the destination area still contains defective pixels. So if you do not heal all defective pixels, you will not have complete healing? sounds fair enough to me. I would like to ask you if you can help us with two things: 1) is it possible for the user to incrementally include the defective pixels in the healing (heal these additional pixels with the brush) and in a relatively short time, the healing would be 'perfect.' 2) can you in very clever way pretend the defective boundary pixels should also be healed in order to do a good job on actually to be healed pixels? Thanks, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] LGM: top-10 feature requests...
Guys and gals, For our presentation at the LGM meeting we would like to show some results from our UI redesign projects. To keep it interesting for the GIMP crew and the users in the audience, I would like to centre this around the top-10 most requested features in GIMP. You know the ones that make your eyes roll when they get posted here or in bugzilla, again, and again, and again. Of course I am looking for the ones that are UI related, so 16-bit color is not interesting, but adjustment layers is. Please help us to make this list by suggesting these top-10 bugs. Please, please, please do not take this as an invitation to post new requests you just made up in this thread, or to discuss the merit or solutions for any of them. Please, please, please don't. Just post the three-word descriptions of these requests that you have seen a thousand times, and make your toes curl or your blood boil when you see them. Thanks for your help, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list [EMAIL PROTECTED] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] top-10 feature requests...
I would like to thank Bill and Raphaël for their help. From the further deafening silence I take that the consensus is that they hit the nail on the head. See the results at the LGM, or as a download afterwards... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] lgm 07, GIMP project overview...
guys + gals, for all of you who missed our presentation at the lgm, I have converted the talk into blog entries. The first part (of three) is online now: http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project- overview.html ps Alexandre Prokoudine: you can link to these as the definitive report of our presentation. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, GIMP project overview...
Sven wrote: for all of you who missed our presentation at the lgm, I have converted the talk into blog entries. Thanks a lot. To give this a wider audience, perhaps you should ask Mukund to add your blog (or just a feed with GIMP related posts) to http://graphicsplanet.org/. I already have the blogger label in place: http://www.mmiworks.net/eng/publications/labels/GIMP.html but there is no rss for it. I'll ask Mukund when he gets back from travelling. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
Thorsten, Image window and Save Changes dialog turned into one: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ Somehow I do not know what structural problem you are trying to solve for one million users. I am all for reusing the main window (save for web, preparing a print) but not for this task. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
Thorsten, http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ Somehow I do not know what structural problem you are trying to solve for one million users. The current Save Changes dialog tends obscure the image. It is a modal dialog situation: we need a decision now. The dialog is a (hopefully) friendly reminder that some of your last steps were not saved. If users would be damn sure about closing a window with unsaved changes every time, there would be no need for asking back. So the user should be able to see _what_ he's about to save or discard. The image itself is likely to be much more informative than filename and changes from the last x minutes. I find this stress on looking at the image very worrying. What drives the decision is the state of mind of users: these changes in the last xy minutes were useful/useless. Either this state of mind is there, because the one just worked on the file, or it is not there, because one worked yesterday on the file. In that case I am not going to invite anybody to investigate that within a dialog. Back off (Cancel) and investigate with all of GIMP's capabilities, I say. If I were to evaluate/improve the dialog, I would start with that state of mind. BTW, from my own experience, hitting Save when the prior version was actually better and something to be kept is much more of a danger than not saving something you wanted to keep. The first thing you have to do when you want to help one million users is to forget about yourself. Now that I write about it, another idea comes to my mind: The Save Changes window could have a toggle to display the last saved version. The dialog is very closely tied to the image window, but still presented as its own window. Transforming the image window into a Save Changes window is as clear as you can get about the relation. I do not think so. First you have to realise that this decide to save the unsaved is an error scenario, a non-task if you will. You are building a full-fledged UI for a task that does not exist on users' radar screen. That is a misfit. One can get rid of the visual noise of a dialog with titlebar and border and avoid obscuring the image in one go. So this removes unnecesary elements from screen, something that I think is quite helpful if you deal with several image windows. Having the dialog there is not a long-term situation, no? It may be jarring, but it needs to be, for a transient moment. It is actually architecturally very worrying that you try to harmonise the dialog into the main window. It does not lessen the interruption in users workflow, and the overall presentation is more of a misfit of what is actually going on. Somehow I do not know what structural problem you are trying to solve for one million users. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] lgm 07, top‑10 GIMP user req uests...
guys + gals, part two of three of our lgm presentation is online: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests.html --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...
Thorsten wrote: 10. better printing support Paper, maybe better called media, could be handled as special kind of layer that is restricted to stay below all image layers (unless hiding stuff below it makes any sense). Think workflow, not about highjacking a image concept (layers): _putting_ it on paper will be handled as a dedicated workflow. It looks logical to reuse the main window for that, to reuse all that space, looks logical to us. But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/ pdfboxen.htm Wow scribus, a pre-press oriented (that is their product vision) dtp app. GIMP's ambitions to not reach that far. The essence of working on the user interaction level is to concentrate on what in GIMP will enable the user to deliver artistic results, and to handle all that technical gobbledegook in the code. 7. save for web Should include indexing for GIF (mandatory) and PNG (optional). If one needs to create a number of images in indexed colour mode that share some colours and where deviations are not acceptable, there should be an alternative to indexing them all as one image to then cut them apart. I would really measure this static-indexed requirement against the product vision before throwing in yaUIc (yet another UI complication). And why are we talking teensy little details here when the presentation and blog entry was about solutions models: the general direction forward? --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...
Thorsten wrote: 10. better printing support Paper, maybe better called media, could be handled as special kind of layer that is restricted to stay below all image layers (unless hiding stuff below it makes any sense). Think workflow, not about highjacking a image concept (layers): I thought I did. Think about workflow. Then how do you end up selecting an intra-image concept (layers) to support the task of putting the actual image itself on another medium (paper)? If you concentrate on understanding the task, then thinking about layers feels wrong within a second, and you can move on to solve the problem in another way. But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/ pdfboxen.htm Wow scribus, a pre-press oriented (that is their product vision) dtp app. GIMP's ambitions to not reach that far. The nature of Scribus is not of interest here, Ther just happens to be an english language description of the terms in their bug tracker. The different nature of scribus is of interest here, because its users that fit their product vision (pre-press) need awareness of this technical pdf stuff. It doesn't matter if you deal with complex page layouts or just images. It also doesn't matter much whether you target your desktop printer or a larger machine. The issues of media size, printable area, bleed and desired final size are just there. All those concepts fall within GIMP users' awareness and are actually named in the blog entry as interrelated textfields that support the placement. But they will be handled in the UI in a way that gets artistic results done, and not in technical pdf file format terms. And why are we talking teensy little details here when the presentation and blog entry was about solutions models: the general direction forward? It doesn't look to me like there is anything to discuss about your solutions model. I would mean this in a bad way if it didn't look like you know what you are doing there and if what I read didn't seem all agreeable. What I mean to say is: can you see that all this detail stuff does not really matter at this moment, unless one of these details invalidates the overall concept? This is the way to cut through the jungle of small details, and to concentrate on major problems that need to be solved first. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top?10 GIMP user requests...
Saul wrote: Quoting peter sikking's weblog: (http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project- overview.html) ALSO NOT PAINTER the focus for GIMP is to work with ‘found’ images; I do not understand the reason for this restriction. Myself, I am not a painter. I do not use the GIMP for painting but I recognize that there are many who do. having a vision means saying no. --Steve Jobs There is no obligation for GIMP to come to the rescue of every pixel pusher under linux. And if there are enough desperate painters out there who want really oil/water/finger paint in GIMP, then they can get _their_ act together and have some plugins written. There is a long, hard road ahead of the GIMP team to get the product vision implemented by core GIMP. It seems such a short stretch for the GIMP to extend its already powerful paintbox toolset to incorporate other painting concepts that I fail to see why development in this direction should not be encouraged. If you going to support it, you have to support it well. To give you an idea how this works out in user interaction terms, imagine that for supporting natural painting, or website mock-ups or page layout, an extra leg has to be sewn on the GIMP. The GIMP will walk better and better, which each extra leg, no? (sorry Sven, for using _the_ GIMP). On a similar note, I wish to express a related concern with another category of user who, in my opinion, is not being sufficiently addressed in the current focus on user interface design: the developer. These are the makers of software. This is the difference between the coolness of making movies, compared to just going to the movies. In the Free Software universe, the most important users of software are the ones who contribute to the project; whether through documentation, language translation, meaningful bug reporting, or actual programming. It would seem that minimizing the demands on potential contributors should be a major focus of proposed changes in the GIMP's user interface Then I would like you to tell me how to make life easier for my fellow GIMP team members. then Valerie wrote: Well, I'm among those who would like to use GIMP for painting, and I have tried in the past. But having seen that blog recently, I can accept that the developers would like to concentrate their efforts in a particular direction, so recently I've been looking to other open source programs such as Inkscape instead. They have limited resources as is, so you can't blame them to want to do one thing Well, even if it means setting aside others for now. I think the best alternative as a result would be to create a separate, painting program, based on Gimp, but with more emphasis on painting options and less on filters and tools mostly used for photo manipulation. Maybe it could incorporate Martin Renold's Mypaint and Levien's Wet Dream for example. So an Open Source painting program would center around things different than a photo manipulation program. I could not agree more with Valerie. There is a 'marketplace' for a painter-like application under linux. And also from a user interaction perspective a new application would be much easier to totally optimise for your painting user experience. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] lgm 07, top‑5 GIMP user requ ests...
guys + gals, the final part of our lgm presentation is now online. whew, that turned out to be a long post to write, more pictures than ever: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html ps: I am enjoying the feedback I am receiving, here and in the blog comments. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
Thorsten wrote: On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote: Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all. As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. yep. You can see a screenshot of my current tool layout in gimp using that idea here: http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times) Thorsten has got a point with the preferred proximity of the tool options to the tool palette. As it looks and feels at the moment, these need to be close to each other to show their connection. One solution for this is to start tying the options to what actually gets done with the tool to the image, and start putting the options in heads-up displays near to where one is working. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
damianzalewski wrote: What gimp is not: not a web page mock-up application I brought up web mock-ups, but we realised that seriously supporting this would mean introducing a ton of functionality; it is better done in a specialised application I really don't understand what tons of functionality you mean. Well, let's see: First we would have to support the task of figuring out the right page structure and proportions by the designer. This would mean multicolumn layout, aligning sections vertically. This all of course in modern fluid (resizing) web layouts. This is all vector oriented work, because it is about structure. Next: although the structure of html text mark-up and the typographical capabilities of css do not need to go 100% into the GIMP text system, a complete _understanding_ of the structure of html text mark-up and the typographical capabilities of css does needs to go into GIMP. Can those links highlight on mouse-over? yeah sure, we should include that. Can we then click those links to go in the mock-up from page to page? yeah sure, we should include that. When that all works, can GIMP export a click-dummy in html, css and images? yeah sure, we should include that. And I am sure there is more... That is serious work to implement. And all the interaction elegance of sewing a third leg on the GIMP. The most bothering shortcoming for webdesign workflow is slice tool and save for web (integrated into one app). Those both will be in GIMP, in the future. Maybe your research methods are wrong. Webdesigners DO NOT design elements of page separately. Webdesigners DO NOT slice page and then open sliced files to save them for web. It would be great waste of time. We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action. As a matter of fact approach 'not a web page mock-up application' means that gimp is useless for any modern form of webdesign. Designing the structure of web pages and building mock-ups is the work for an interaction designer, and there are other apps to do that in. The production of high quality image pieces for the final web site is the work of a graphics artists, and GIMP is the application for that. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...
Sven Neumann wrote: On Fri, 2007-05-25 at 19:03 +0200, peter sikking wrote: BTW, the dialogs that you consider to be unnecessary can already be skipped using the Shift key. Then the perfect solution is that we reverse the logic of that shift key. Only with the shift key down the dialog is shown. Our users will be eternally grateful... Oh come on, you are really making things simpler than they are. that is because from the perspective of my profession and after the systematic effort put into evaluating this, it is really clear that doing this benefits GIMP. Either a dialog is really redundant, then it should be removed. Or a dialog is useful and even necessary for certain important tasks. I found 'reversing the shift key' a beautiful solution because the dialog already exists and GIMP is full (rightly so) of these power features. It fits the interaction principle that straight ahead user concepts (new layer) have a straight ahead UI. Then we can not only make it available by pressing some obscure modifier key. It would be more or less undiscoverable and we had effectively removed an important feature. The choice it to make either the dialog or 'no dialog' a tricky power feature. I choose, without a doubt, the former. We will have to stay with the current solution until we have found other ways to provide the functionality. But if like with the layers dialog, I see zero function 99% of the time The dialog saves you the extra step of filling the layer. In my opinion it is very useful and speeds up the workflow. After all the user just needs to press the Enter key to acknowledge the last used settings. When I look fundamentally at what layers are, the optional character of all functionality (name, size, fill) offered by the dialog, combining that to realise the percentage of times that each will be useful and the alternatives to reach the same goal, take into account that this is part of user request #5, then dealing with this dialog dozens of times a day is a burden on GIMP's user experience. All I ask for is to give it a chance. GIMP has what adobe has not, a community. They want to participate by using developer versions in real life situations. I say let them help. Try this in an early development version (like 2.5.2) and wait for the learning effect (you changed it!) to go away. Then after a while evaluate. If it then turns out to be the wrong idea, I'll be the first one to admit it. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...
Sven Neumann wrote: On Sat, 2007-05-26 at 16:50 +0200, peter sikking wrote: The choice it to make either the dialog or 'no dialog' a tricky power feature. I choose, without a doubt, the former. I explained you why that choice is not acceptable. If you did not understand my last mail, why don't you just ask? I think we are talking now past each other... When I look fundamentally at what layers are, the optional character of all functionality (name, size, fill) offered by the dialog, combining that to realise the percentage of times that each will be useful and the alternatives to reach the same goal, take into account that this is part of user request #5, then dealing with this dialog dozens of times a day is a burden on GIMP's user experience. Please stop reiterating these buzz-words; it starts to become annoying after a while. If user interaction problems need to be solved, then it needs to be discussed in user interaction terms. If I would translate this totally into user-space or developer-space, then it would trivialise the issue. So that's it then, for this issue... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image indexed mode, major hole
Henning wrote: I can see good software-engineering reasons to want to eliminate indexed representation internally, but from a usability standpoint it will be a loss not to be able to restrict the possible color values to a predetermined palette. I see it as a boost for usability when this whole indexed mode disappears from the UI. To many user complaints are being triggered by the possibility of working in different modes. It is good thing when working in gimp is unambiguously in full resolution and indexed becomes a matter of importing and exporting. This will enable us to have a less schizophrenic UI. And while exporting, one deals with the problem you describe here: Imagine finding out only after several hours of editing that some of the pixels you intended to be (255,192,53) accidentally became (255,192,54), and others became (255,188,53) and a few of the (64,64,0) became (64,64,3), and this is a source of immense confusion to software later your build process, which recognizes exactly those colors to have a special meaning, and now you have to go through a few dozen layers to find all of the misfit pixels and correct their color one layer and color at a time. Indexed editing prevents making the mistake in the first place; if I have not explicitly added (255,192,54) to the palette I know that I'll not risk finding it in the output. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] crop isn't stopped at image borders
Alexander, I have read your concerns and can tell you that at the end GIMP will work as you like to. I would prefer to have this feature switchable with a checkbox the development of the tools is not finished. I have to move first here, updating the spec of this feature and filling in some holes, thus giving developers an easier time and encourage implementation. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David, peter sikking wrote: We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action. I don't see how this can work in practice. I often need to hide or isolate layers before exporting the selection they affect we were thinking the same, so a cutting mask is not part of a layer... and many selections are a very small part of an element's area (say 1 pixel wide) because they will be tiled by the browser as part of a background image. that is what we expect, too... In other words, some manual work needs to be done with the majority of web graphics taken from a concept. can you tell me what you mean with manual work needs to be done? that can help us with our work. Comparatively few images are cut out as they are. I can clarify that in general we do not expect that some mock-up is taken, and then the bits are cut out, and finished. in general we expect that graphics artists set up the canvas and layers in any way that works for them: sometimes a creating continuous area and cutting out pieces from there, sometimes laying out pieces just as a set adjacent to each other. Set up variations of sets of graphics by duplicating layers, or by switching layers on and off, or by switching GEGL operations on or off? do whatever you want, we can handle it. use any combination of hand-made selections and one or more cutting masks (these contain any number of selections), be our guest. we feel that with this flexibility we cam truly support web graphics work in a flexible way. thanks for your feedback, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David wrote: peter sikking wrote: can you tell me what you mean with manual work needs to be done? that can help us with our work. Well the most common case is simply selecting a slither of an area to be tiled as a background image. yep, we expect this kind of stuff to be your daily routine. actually right now I am specifying how the selection tools should deal with long, very narrow selections, with the web guys in mind. Sometimes you have to hide a foreground layer before making the selection such as filler text or an image. You will also want to pick a colour with the pipette tool that will be used as the background colour of the element. Most of the background images I deal with are gradients, so the colour I want to use is either the darkest or lightest colour of that gradient. Otherwise you often need to select the right combination of layers. I've already mentioned foreground layers that might need to be hidden. Other times they might need to be isolated. In Photoshop the issue is further complicated by the use of adjustment layers. Transparent gifs or pngs will need to be isolated altogether. Sometimes a background image will be larger than the dimensions of the containing element so the final thing you'd want to do is toggle a layer mask to get the whole image. lot's of layer action to get the right combinations _visible_, that is what we also thought would prelude the cutting of web images. This is the routine I tend to follow when using PS 9: 1) Toggle visibility of layers and masks until I can make a selection of the area I need to save. 2) Select area with marquee tool. Can be very annoying when zoomed in because selection always overshoots when I scroll. PS does not share Gimp's sensitivity when zoomed in. 3) Copy visible. Gimp should probably have a short cut key bound to this operation as it is always required. there we go: visible. what you see is what you export. we are thinking in the same direction. 4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. The only editing I ever need to do here is convert background to transparency. sounds to me that this whole new canvas is superfluous. the transparency thing is noted. 5) Save for web. Compare compressed images against original. Adjust for best compromise of size and quality then save. interesting to see Compare compressed images against original, would it be enough to see the compressed one and balance that against the size and what your customer expects? With a save *selection* for web feature, steps 3) and 4) could probably be omitted altogether for most of the time. Step 5) is often made cumbersome by the fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in preferences (maybe it can and I don't know about it!). yeah, we are seeing that for these individual saves, but also for saving 20 images from a cutting mask in one click, working with fixed and also variable destination directories is part of the game. we need to support you guys there. It's getting late so I'll leave it there. I think I may follow this email up with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature. now it is getting late here too. if you can make that description really fundamental (like in principle for tens of thousands of web graphic designers), and filter your own biases out, then that would be great input for us. but you better be sure it is fundamental ^} thanks, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
Liam, actually right now I am specifying how the selection tools should deal with long, very narrow selections, with the web guys in mind. Please don't forget other users :-) I routinely have a selection that's, say, 10,000 pixels by roughly 40 pixels. This might not be a usual case for Web graphics... an aspect ratio of 1000 to 4. cool. at what zoom level(s) do you adjust this selection? and why? thanks, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new rectangle tool specification
Sven wrote: you have been working on an updated specification for the rectangle tools in GIMP 2.4. The current state is here: http://gui.gimp.org/index.php/Specifications under construction, btw... First of all, could you please move this specification to its own page and link to it from the specifications page? We will want to have lots of such specs and the current page is already getting too long. Yeah, might as well do it now... done. Then I have some comments. These affect two things, the handles and how they are drawn and the handling of the cursor keys. Both are aspects that already worked pretty well over the last development releases and it is somewhat unfortunate that you suggest that they are changed again. But my critiscm is not due to that fact but simply because the suggested changes feel like a regression. 'Worked pretty well' is not the same as solving the problem, and achieving a result that I'd be proud to show my user interaction or usability colleagues. Martin already implemented aspects of the new corner handles in SVN, so one can easily try it. I had to revert my svn to see what you are seeing. I had a sunday evening patch from Martin applied. Once again thanks from my side for Martin, he's been 'on fire' all weekend. It is a pleasure to work with him on getting the spec implement, and use the in-between results to fine-tune some of the handle proportions. When the mouse is moved over a side handle, a side handle and two corner handles are drawn. If I want to reach the corner, I aim for the highlighted rectangle. But when my mouse reaches it, it turns out that what was highlighted as the target area is actually a dead area and nothing happens when I click and drag there. I don't think this is acceptable behaviour. The highlighting of the side and corner handles before the change was much easier to predict. Perhaps we should go back to that? I see what you mean. I realise now that I have been looking at these highlighted side handles since the weekend and thought: 'ah, a corner-handle-and-a-half.' The problem is the 1-pixel solid line, and I have changed the spec to make them stippled. That will make them subtler and different... done. The other aspect is not yet implemented. The spec suggests that when the mouse is over one of the corner or side handles, and one of the cursor keys is pressed, the rectangle shall be resized by one (shift: 15) image pixel in that direction and (new) the the canvas shall be scrolled in such a way that the position of the bounding rectangle under the sprite shall be constant. I don't think that scrolling the canvas is a good idea. The reason is simple. We can't currently scroll beyond the canvas. As soon as that is changed (probably not for 2.4), we can review this part of the spec. But currently it would just feel akward. Sometimes the canvas would scroll, sometimes it wouldn't. For the user it is hard to predict what will happen. So I suggest that we don't do any scrolling and that a note is added to the spec that this part should be reviewed when bug #362915 is fixed. OK, all things considered, I am going to put on ice the goal of keeping the mouse sprite stable on the handle. Changed the spec... done. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new rectangle tool specification
Sven, On Wed, 2007-07-04 at 17:24 +0200, peter sikking wrote: If I want to reach the corner, I aim for the highlighted rectangle. But when my mouse reaches it, it turns out that what was highlighted as the target area is actually a dead area and nothing happens when I click and drag there. I don't think this is acceptable behaviour. The highlighting of the side and corner handles before the change was much easier to predict. Perhaps we should go back to that? I see what you mean. I realise now that I have been looking at these highlighted side handles since the weekend and thought: 'ah, a corner-handle-and-a-half.' The problem is the 1-pixel solid line, and I have changed the spec to make them stippled. That will make them subtler and different... done. Sorry, but how does that solve the problem? by using different graphics (stipple) we avoid that these two lines are interpreted as showing corner handles. They don't. They show the edges of the side handle area, giving feedback, confirming why and training where the side handle highlights. You can see that compared to the previous 2/3rd side handle, these ones fully use the predictability the the corner handles gives us, by being in one dimension exactly the same size as the corner handles. They are shorter in the other dimension, to create a gap so one can reach the corner handles. This gap is actually bigger than in the 2/3rd situation. The result is a side handle where it is easier to predict its boundaries, making them slightly quicker to grab. Not only are the new handles larger in area, they are also more 'square' in aspect ratio than the long and slender 2/3rd situation. Each of these factors make the new handles again slightly quicker to grab, on top of the one above. That is three speed factors accumulated, and they together deliver the increase in ease of use that I envisioned when going for big handles for the select + crop tools. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new rectangle tool specification
Sven, On Wed, 2007-07-04 at 21:04 +0200, peter sikking wrote: by using different graphics (stipple) we avoid that these two lines are interpreted as showing corner handles. They don't. Well, if they don't show the corner handles, what do they show then? The exact area where the side handle is sensitive for mouse-over. This creates a cause-and-effect relationship for the highlight and helps to stay inside, showing the edge so that you can see that you are close to the edge. And isn't it important to show the corner handles? Not when highlighting a side handle. The corners have nothing to do with that. The user might be heading for the corners. Unlikely, since the corridor to get from the centre to a corner handle is bigger than ever. So chances of unwanted flashing are lower than ever. With the old setup, the corner handles were always present, even if the user moved over the side handles when moving towards the corners. No. They never were. Spec and implementation up to now have been that when a a side handle highlights, no corner handles are shown. This is to show that you move the whole side, and nothing but the side. Now quite often when I try to reach a corner handle, the side handle jumps in my way and the target area that I am heading for disappears. This is slowing me down. A lot. I don't see how this is an improvement. Not reproducible with svn of noon today. May I ask if you are really doing graphics work, or trying out the new rectangle code? The side handles are fatter, fitting exactly with the corner handles (the whole purpose in sentence). And they are easier hit, if you are heading for the side handle. But with 100% predictable new side handle size and larger go-to-corner corridors, there is no doubt that this is a real solution for what we are trying to achieve. Like everything in GIMP I must design for what is most efficient in the long run. This goes at the cost of having to get the hang of it. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
guys, what a thread. I say that the solution for all this lies in treating these lossy (my spell-checker proposes lousy) formats the same we are (gonna) handle indexed mode: import + export only. This would prevent the misunderstanding that there is a continuous lossless workflow for these type of files, and that it is OK to save intermediate files in these formats. The import part means that when you open a jpeg, you get a GIMP file. original_filename.xcf, it says in the title bar. Press save the first time after import and you get a 'save as' dialog with the location of the original jpeg and that original_filename.xcf as defaults. now you have a workflow in full fidelity. The export part means that jpeg and other lossy formats are not available for Save (as), but only under an explicit Export command. After an export to jpeg, you are still working on the GIMP format file. I have hard time believing that the reason a file is jpeg on your camera memory card is the same as being jpeg at the end of your workflow in GIMP. Afterwards it is about saving space on your disk or saving bandwidth on the internet. Different requirements == different quality factor, I say. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
Raphaël wrote: I say that the solution for all this lies in treating these lossy (my spell-checker proposes lousy) formats the same we are (gonna) handle indexed mode: import + export only. Eek! That would significantly break the flow for what must be the most common image format for photography. Really? Let's have a look at the product vision. 'High-end' is the word I want us to focus on. I can understand that a high-end workflow can start with a jpeg because due to a mishap nothing better is available. I can also understand that a jpeg version can be part of the final result. But in between, as long as it is not finished, there is no role for jpeg. Only one decompression at the beginning and a compression of the end result is defendable in high-end graphics. There is also a real benefit in opening a jpeg and then saving the result in another (GIMP) file. We see from the explanations in this thread that opening a jpeg and then saving it again means a loss of information. So overwriting an original is a loss. Working on a full-fidelity copy version is preferred. The early part of this thread is full of misunderstanding at which point working with jpeg incurs quality loss. I say it is because of the you can work in jpeg myth. I am still confused that you talk about saving intermediate results while working on a jpeg. Either each save reduces quality (implicit save and reload, ouch) or there is a penalty for closing the file and reopening it, because you lost the full-fidelity internal (GIMP) representation, ouch. So I see real benefits for a high-end image manipulation program that lossy formats are pushed out to the very beginning and very end of the workflow. That the working copy of the file is GIMP format, in full fidelity, any GIMP operation naturally possible, and with no penalty for opening and closing the file. We need to actively support the high-end workflows, with minimal effort. Consumer mid-fi workflows (open jpeg, edit the image, save (overwrite) the jpeg) are still possible, (open, edit, export) and it does not look like any more effort than the current situation. If users get the hint that opening and saving the same jpeg again and again is a pain (also for the quality) and that either adopting a high-end GIMP file workflow or moving to another (mid-fi) app to work in their lossy jpeg way. Before I started shooting only in raw format (so before I bought larger memory cards for my camera), I shot a lot of JPEG pictures. Can you relate why you moved up to raw to the requirements of high-end image manipulation? I can. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
gg, my dear agent provocateur, creating interaction requires making hard choices, because you cannot make an application for everybody. For that you use the product vision that you set as a team at the beginning of the project. And then you don't fudge when the moment is there. You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts. Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level. That means I make hard choices, based on the vision, the way thing work technically and our workplace observations. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
Raphaël wrote: creating interaction requires making hard choices, because you cannot make an application for everybody. For that you use the product vision that you set as a team at the beginning of the project. And then you don't fudge when the moment is there. I would like to temper this a bit (not agent provocateur as gg, but maybe devil's advocate): a team that is too rigid about its vision and never adapts it over time runs a real risk of becoming irrelevant after a while. On the other hand, having no vision at all or ignoring it and running like headless chicken is usually worse. I agree that a product vision, like a national policy, should be reviewed every, say, 5 years. Do realise that when you chance the the vision, that you restart, from zero, a process that takes about 5 years. And thanks for saying that ignoring the vision is worse. You make hard choices about which features to include and which not. Which workflows to actively support and streamline, and which go on the back seat. About beginners vs. Experts. But one should always balance the interest of the few who are targeted by our product vision with the interest of the majority of the users who are not necessarily part of that vision. Few? there are millions of users within our vision out there. And if we work to make GIMP represent this vision coherently in the UI, then GIMP will become a viable, natural choice for the people we want to use it. And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. We cannot make GIMP for them if we want to make it for the high-end market. One of them has the priority, and the other can use GIMP at their own risk. It took me 5 second to agree with the maintainer of Krita to agree that GIMP and Krita are not competitors, they serve two different markets, and can happily live side by side. In other words, a decision that provides a small improvement for the target users but implies a significant regression for all other users should be considered very carefully. Actually in this case it the other way around. There is a significant improvement for target users, with clarification of image degradation of everyone, and little or no regression for the lossy-jpeg users. Our current vision is rather elitist. This is not a bad thing because this is often the only way to make real progress. But we should also be aware of its consequences. Well, you have chosen that GIMP is a fast driving machine, able to compete with the best. Do you mind that I try to focus us on that when the question is what about going shopping? or what about taking driving lessons in our machine? Sven did not set the product vision, the GIMP team did by consensus. I only moderated that session. But I am here to implement that vision on an user interaction level. Again, to temper things a bit: this was only a subset of the developers present at LGM last year (GIMPCon 2006, see the minutes at http://developer.gimp.org/gimpcon/2006/ and read the section GIMP Vision). This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their yeah, but what about me feature into svn, then we are back at the headless chickens state. Please, do not get cold feet when the law of nature that we cannot make everybody happy becomes apparent. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David, first of all thanks for taking the time to give us input. There is one phrase here that I am not sure how to interpret: I'm not entirely sure how I'd go about designing a website in gimp to deal with this problem The designing a website in gimp sounds scary to me because I then immediately think of the overall layout and how it fluidly resizes. I can only hope that for you it actually means producing the actual images that go into a website. Overall, I see that you call for support in GIMP to evaluate how a certain image will work over a solid background color (hmmm, that could be also over a background image), and support for flexible masking to evaluate how things work under resizing. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
Raphaël wrote: let's see how short I can keep this. We also have to be humble and remember that writing down the current vision only took us a couple of hours, not 5 years (basically one hour of discussion at LGM plus some e-mail exchanges while we were polishing the minutes). Two hours. The vision has been simmering in the back of the minds of everybody involved for all the years that they have been working on GIMP. That is was externalised (written down) in such a short time is the added value _I_ deliver to my customers. And let me repeat: if the we had not reached this result in these few hours, I would have interpreted that as the GIMP team having no clue about what they are trying to achieve, and I would have not gotten involved. No vision (or a constantly disputed vision) == no clue == no chance in hell for anybody (including pros like me) to achieve decent interaction == a project I do not need to ruin my professional reputation on. Few? there are millions of users within our vision out there. Sorry, but I have to disagree here. If you just look at the part of the product vision that says GIMP is ..., then it could apply to a large number of GIMP users. But if you look at the context of the vision (which is not explicitely written in that section, but is part of the Targeted user base in the meeting minutes and the user scenarios + expert evaluation on gui.gimp.org), then it is clear that the vision is targeted at experienced, professional users. I take the vision as broad as it can be explained (it was phrased not so specific for a reason), but not broader. I actually do not like the word professional, it just means earning money. To sum it up I like to think of 'intense use', you either put in a lot of hours with GIMP, or you have paid your dues and know what you are doing. This is at best a small percentage of the current GIMP users. [...] But we have to acknowledge that the vision (or the way we use it) is targeted mainly at a minority of users. This minority is almost certainly the most interesting subset o I do not believe that. And I thought that we all understand that there is a choice of several free software programs out there for users who want to do simple red-eye removal from their holiday jpegs. Unfortunately, until that choice really exists this is a moot point. we agreed at the vision meeting that the choice is there. And I would let Krita, F-Spot, digikam et al. worry about serving their market optimally, and actually give them a chance by keeping GIMP out of their markets. Since we are not in it of the money, we can actually improve our own situation by letting some room for other software developers. This is a slippery slope. If anybody can excuse themselves from the vision when they personally do not like the logical outcome of applying it to a hairy UI design question, and bang in their yeah, but what about me feature into svn, then we are back at the headless chickens state. Unfortunately, you skipped the part of my message in which I wrote: It is always possible for someone to propose someting that goes against the current consensus and hopefully convince others that this is the right thing to do. Your wish is my command ^} Luckily, GIMP has a core and plugins. The core has to be redesigned according to the product vision. This includes the standard distribution of plugins. I will measure anything that has to do with interaction against the product vision to see if it interferes with it. If it does not bloat the interface and stays out of the way of achieving the vision then it is fine with me. See the following frivolous extra: http://gui.gimp.org/index.php/Selection_% 2B_crop_tool_specification#mathematician's%20Easter%20egg I did not chop its head off. Any other counter-vision stuff (example: GIMPressionist) must stay out of the core (distribution) and live happily as a one-click installation on a web server (even on gimp.org). --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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.
Akkana wrote: I'm seeing an unspoken assumption in this thread that most photos are edited in multiple sessions: read into gimp, do a few operations, write to disk, read back in (perhaps hours or days later), do a few more operations, write back out, repeat. I was more thinking from the point of it is never finished. Either as an artist you grow and want to revise your work, or people you work for ask you for another revision. 'and you just thought that first jpeg was the final result' So giving priority to saving files in full-fidelity is the way to go for me. If users get the hint that opening and saving the same jpeg again and again is a pain (also for the quality) and that either adopting a high-end GIMP file workflow or moving to another (mid-fi) app to work in their lossy jpeg way. Another thing I'm unclear on in this thread: when I first heard the idea of forcing Export instead of Save, the plan seemed to be that Save would always save XCF, and anything else would require Export. Writing that a few days ago I realised that that is where you end up when you systematically apply the argument: only xcf is full-fidelity. So you Save (as) in that format, and the rest is exported. But I thought that would be to hard to swallow at this point in the current discussion. But the Raphael writes: So I think that the statement from Peter that singled out indexed image formats and JPEG was slightly misleading (and this triggered my initial reaction). Basically, only XCF would be saved and all other image formats would be exported. Sorry for the confusion then, we all seem to be moving in the same direction. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 58, Issue 51
Esteban! we talked on the ixDa list before, remember. design.I am studying Computer Science and Product Design, happy to see you took my advice on the latter. later planning to study and work in Interaction/Interface. I would like to volunteer for the UI design of GIMP. I am afraid that I do not have positions open at the moment (we also talked about that before). Were can I upload a mock-up of UI changes? That is a good one. A drop-box where people could contribute their ideas for GIMP, as long as it is a picture (jpeg, png, gif. no polemic, please). Sort of a visual brainstorming. Everybody could see it as a gallery, but again, no comments. My team would sort out the spam and the obnoxious. A sort of dialog could still ensue between contributors, as long as their pics make is past moderation (what was that with the obnoxious, again?) In my experience no idea is too wild to trigger a sound UI solution at the end. What's the point of a wiki that cann't be edited (there's no option for creating an account in http://gui.gimp.org) the wiki is there for my team to work together and have everything in one place, versioned. And to work out in the open, so people like you can see how these things work. If that wiki was publicly editable, then the opinion of a thousand guys would flush out my teams diagnoses in a week, and we could start working in another wiki. Just keep the layer modes. hot topic, no? I want you to remember this: everything you can do with layer modes, and even more powerful stuff, can be done in other other ways these days that are 10 times more intuitive you will that see one day in GIMP, nut not layer modes. have you read this already? http://www.mmiworks.net/eng/publications/labels/GIMP.html this is just about my last mail before my holiday, so further discussion will have wait a couple of weeks. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp (current svn) crop tool
Guys, the fixed ratio/width/height/size functionality is optimised for applying that constraint many times over a period of time (all day long). You set it up, then you use it for a while. If you quickly want to set the width/height/size of the bounding rectangle then there are the width and height fields, that is what they are there for. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Default values for the Fixed: Size entry
hey Enselic, (It was an odd time stamp on your mail. are you back from vacation yet?) suddenly I am in Kansas, on a very cool project for 2 weeks. The spec asks for ideas for good default values for the Fixed: Size entries. yeah, the 100x100 is arbitrary. How about having 100x100 as default when there is no pending rectangle and rectangle width x rectangle height when there is one? This would be the case for both the selection tools and the crop tool. we cannot base the default of fixed size on the current rect, because it operates on the current rect. This would freeze up the rect in a positive feedback cycle. we can base it on the image size, but that would make no sense for fixed size. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP UI brainstorm...
GIMPsters, before my holiday (1-8-7) there was this email from Esteban, asking where he could show his ideas for GIMP. In my answer to that mail I see that I already used the words 'visual brainstorming.' During my holiday I thought about it some more, how this could work and a cheap (in labour) and easy way to implement this. And I have done so yesterday: http://gimp-brainstorm.blogspot.com/ So I want to ask you guys + gals: from just looking at that page, if the whole idea is clear to everybody. Also after discussing on the irc a bit (thanks 'ari'), I put this CC licence on it and I want to be sure it is the right thing. If all is OK, this can be than the GIMP channel where everybody can contribute their bit to the GIMP UI. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI brainstorm...
Guillermo, It's a good idea, but I think you should add a little explaination thanks for reviewing, I will add some. and a voting system (like digg's one) to get some statistics of the degree of popular aproval of each idea (but I'm not saying that the voting should be considered for implementation, just statistics). well, first of all a voting system is another way of commenting. In a brainstorm there simply cannot be any kind of that sucks kind of commenting, it kills the flow of ideas. A series of zero star votes for an entry would be just that. Second, for me as an interaction professional, these votes are meaningless. Putting together a functioning UI for GIMP is a big architectural puzzle. It is not a matter of just putting in the popular ideas. A little text explaining the idea would let the visitors understand better the idea. yep. In the mockups I sent you can clearly understand the basic behaviour just looking the screenshots and the title, but there are other aspects that are important too, about the grouping of the windows in a single taskbar button, the new menu arrangement and the tool windows being dependant of the splash or the document windows. It would be nice to have that kind of clarifications too. like Henk said: put this in the images you send. Combine it in one graphical package. Comment your idea text balloon style, instead of writing that long essay in your email (I did not read it). The text in the blog is the voice of GIMP UI team. It would be awkward there to mix the opinion of contributors with the analysis of our team. Also I think that not allowing comments avoids the possibility to participate in an existing thread and suggest improvements. as Michael Schumacher pointed out on the irc last night, the whole text discussion thing has been tried before on openusability.org. It failed miserably, because the wrong people (non-interaction types) were discussing on the wrong level (non-interaction). I see this working in a visual way. Because of the CC-SA-BY license, anybody could take your image, modify it with their own ideas for improvement, and send it back to the brainstorm. visual dialogue. The image requirement forces contribution, instead of naysaying. But otoh, it would require someone moderating that blog, so I understand why not. you know how the commenting on GIMP topics works: 200 comments with the top-10 user requests and venting of peoples current frustrations with GIMP. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI brainstorm...
Guillermo, Comment your idea text balloon style, instead of writing that long essay in your email Ok, but... Balloons are good for a few comments but they tend to clutter the image and obstruct the legibility if they're too much. More complex ideas will require more balloons or more screenshots (and you said you want one or two). you are seeing I am encouraging everybody to keep it short (few images, a little text, pointing out what is really new), and think of it: if you feel you need more than that, maybe your mock-ups are not working on an interaction design level. Maybe something like this would help to keep the presentation simple: sorry, no text. Make your images speak. (I did not read it). I'd really appreciate if you have a moment and read it. It took a couple of hours of my time trying to get a decent solution for a longstanding and polemic issue in gimp. why did you need so much text? Good UI solutions speak for themselves. why do you need to explain me anything, when you know it will not end up in the blog? I'd really love to know what do you think about it. Of course I don't expect I love it or it sucks, but your expert oppinion. as the brainstorm moderator I have to be nice to everybody (difficult, that) and let the contributions speak for themselves. let the contributors get inspired by each other. I don't see the point of the whole blog if there are only screenshots and nothing else. If nobody but the UI team will get something out of that blog, maybe the best idea is just to receive the files via e-mail and don't publish them. in a brainstorm one idea triggers off the previous. No matter how wacky an idea is, spit it out. Because either a counter-idea of the next person will be a step in the right direction, or associating along in the wacky direction will be the breakthrough we are looking for. People who contributes usually want to have a feedback. well, this is not interaction design school. Feel good about that you are the one that kicked off the what do we do when no files are open? flow of ideas... it is good discussing this, I will have to sharpen the 'blurb' on the blog again after this mail. Tomorrow... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI brainstorm...
Henk, those verdomde licences. On 11/09/2007, peter sikking [EMAIL PROTECTED] wrote: I see this working in a visual way. Because of the CC-SA-BY license, anybody could take your image, modify it with their own ideas for improvement, and send it back to the brainstorm. I see one problem. CC-SA-BY requires attribution, and the blog doesn't give it. the contributors have to take their credit, to get attribution. I did that so I cannot mess up the anonymous part and the 'fish out the right name out of the email' part. if somebody does not take credit then (s)he fall out of the attribution chain. If the there is no contributor to attribute to then 'GIMP UI brainstorm blog' will do. Attribution would also be necessary in the modified works. yep, but a bottom edge of 1024 pixels is pretty long in 9 point type. Attribution makes things messy, and (IMHO) it's not that important for something like a brainstorm in any case, so perhaps a license change would be helpful? I think people who take credit should get attribution. Could be a reason not to contribute because the licence is too lax. I dread having to check that the whole attribution chain is in place on a new contribution... --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] transformation tool
Igor, I like Gimp a lot, and using it for every day job. I want to repay to Gimp community by giving advices for making him better and faster for use. we have the GIMP UI brainstorm for this: http://gimp-brainstorm.blogspot.com/ please send your contribution there. Thanks, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adjustment Layers - How can I Help?
David Gowers wrote: there is http://gimp-brainstorm.blogspot.com/ for working out the UI (and http://www.mmiworks.net/eng/publications/labels/GIMP.html , the precursor). let me clarify a bit: http://gui.gimp.org is the place where the interaction team works. http://www.mmiworks.net/eng/publications/labels/GIMP.html is where I write about working on GIMP. I plan to write more there about the direction the GIMP UI will take. http://gimp-brainstorm.blogspot.com/ is the place where everybody can contribute with their ideas for the UI. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmapping, the UI part of it...
GIMPsters, 2.4 is out and I want to thank Sven, Martin and Mitch for working with me on realising a substantial part of the select/crop tools specification. For me the transition into the 2.6 development cycle also marks the start of where working on the UI revamp of GIMP will be more strategic, architectural and structural. A sharp reduction of expert interaction design on a fire-fighting, slap on a band-aid basis. Roadmapping what over-arching UI topics will be dealt with in this release will be necessary to have UI specifications ready _before_ implementation starts. During 2.4 it has already been shown that having a UI spec encourages new developer participation and that can only be a good thing. From my UI-redesign point of view, we need to get GEGL and Cairo in GIMP, else there is little chance of innovation in the UI. Also what the GIMP project needs right now is a short ( 6 months) development cycle. A short-distance run to get its heart beating faster. So it is a matter of not stuffing the roadmap and I can help there by not proposing to start working on big issues. I think that enough UI work will come our way as side effects: for instance: Half of the select/crop tools is still to-be-implemented, part of it (narrow situation) needs further specification and hmmm, Cairo is introduced. I say lets finish the select/crop tools making full use cairo, like transparency. Working on the problems we have easily moving the contents of selections, you pretty soon hit the floating selection mechanism. We already identified in our evaluation that as something that needs to be transformed from a headache that makes you think into something that you never notice but just works. It looks at the moment that at the user experience level just about nothing will come out of the GEGL introduction in 2.6. May I point out the elephant in the room by saying that if 2.6 could deliver 'better than 16 bit per channel' resolution that that would be seen all friends and foes out there as a huge step forward for GIMP? Yes, that is a huge job if you think of it in the context of the handful of people who work at the moment on development. But it is exactly the kind of roadmap goal that could attract a dozen new developers to help with moving all core existing plugins to the new system. Mitch has some plans where the GEGL move could impact in UI. I will let him outline that first, before proposing what could be improved in the same swoop. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] weekend 2.6 UI roadmap roundup...
hi all, let me see what since friday has been said (UI-wise) concerning the roadmap. Martin wrote: I suspect making use of Cairo won't impose significant changes to the spec? Well it does, because instead of the current 1-bit (invert) graphics for displaying the UI on the canvas, we could lighten/darken with a much higher 'bit depth'. Which means that the current workarounds (e.g. showing no side handles except on mouse over) can be replaced. Then Sven put these (UI related) projects on the map, but not necessarily on the 2.6 roadmap: * next generation size entries * finishing of: * Heal Tool * Sample Points * Foreground Select Tool * Floating Selections * Alpha Channel * Layer boundaries The ideas for these are mostly in sync with the conclutions the UI team reached during the expert evaluation. Here I want to say that what gets put on the 2.6 roadmap will be specified first because it has a higher priority. And then Guillermo opened the the debate about user request number one: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html#thebigone and everybody starts discussing _how_ this could be done... guys, roadmapping is about what you will deal with in the next release (s), absed on how hard it will be to implement. Now I really want to solve this mayor issue, it will be a multi-facetted solution, but the developers keep telling me that it is not going to be easy to implement. Even to do the bare minimum (Removed the extra menu bar, the inspectors have been made real floating windows, a first stage of usability bug fixing before) would, if I understood Mitch + Yosh right, involve patching all mayor window managers out there. I am all for it that we do this as soon as possible, but I can also understand that it is too much for 2.6. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI redesign: 1 Dimensional Menu for GIMP
Esteban, Hi all, This is the 2º draft for the 1 Dimensional Menu: http://www.zensui.org/IxD/1DM.html in your honour we created the GIMP UI brainstorm: http://gimp-brainstorm.blogspot.com/ please post your idea there. On another note, is a new mailing list dedicated exclusively to interface design needed? What would be the function of the mailing list? What is working really well with the brainstorm is that everyone is able to contribute, these contributions get reviewed by my team and we get new ideas out of them. The other good thing is that the noise factor is cut down by a factor of 1000. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a first step towards Cairo drawing
Chris Mohler wrote: Sven Neumann wrote: Currently we are drawing the rectangle using XOR. When we switch to Cairo this should probably change. But I am not entirely sure how to best draw a nice-looking outline that is visible on all images. Perhaps some of the artists out there could draw me some nice mockups? How about darkening the outside-of-the-view area and then adding a simple white border? http://cr33dog.fedorapeople.org/misc/gimp/nav.png yep, that is also what I came up with. overlay the outside with 50% transparent black, and a 1 pixel 50% transparent white border. that should work on all images. The percentages (the gray value or the alpha) can be adjusted when the darkening/lightening turns out to be too severe, like it is in the screenshot linked above. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions for 2.6: hopefully not very difficult
Sven Neumann wrote: Michael Grosberg wrote: My second suggestion - I think it was discussed before - is to switch the functionality of the add layer button in the layers menu, at least as an option: click will create a new empty layer, shift-click will open the new layer dialog. I am concerned that we are hiding important functionality here and that most users will never figure out how to get the dialog in case they should need it. But since even the UI team seems to suggest that we do this change, we should probably do it all over the user interface then. There are a few more places that use Shift suppresses dialog. yep, _even_ we think this is necessary from an interaction point of view. ;^} but watch out broad-brushing this over all dialogs that use Shift suppresses dialog at the moment. for every one of these the _right_ choice needs to be made, depending on our essential user scenarios and our product vision. Again, this should be rather simple and if Peter gives his OK, then we just need someone to preparse some patches. I say we put this on the 2.6 roadmap, the UI team can go through the list of all of these and publish a spec with rationale of which should be switched over, which can then be reviewed. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
I wrote: I do take the hart of the matter [...] serious. really, I did not mean an adult male deer, I meant 'the heart of the matter...' --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Sven wrote: So could we please stop talking about some completely irrelevant article and instead deal with the actual problem? Thank you. since I am responsible for this 'department', I do want to say something, but I'll keep it short. I do take the hart of the matter, which is behind that article and some of the comments in this thread, serious. there will be more innovation on the communication side from the UI team. thinking about expanding the UI team too (warning: interaction professionals only). the brainstorm itself is a method to open up the UI process and the team reviews are there to show what we get from them (apart from documenting it for ourselves). both were received enthusiastically. takes 2-3 hours btw, to discuss 25 brainstorm contributions. that should be communicated too. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Michael Grosberg wrote: Very simple: Peter has a blog, right? and very occasionaly, he posts something relevant to the Gimp UI, such as the post about the print dialog. uhm, the print dialog stuff is for openPrinting. That project plots the future of printing for all linux desktop systems. To add more transparency to the UI effort, all he needs to do is to post some more. and that, is exactly my plan... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] roadmap items from the UI team...
GIMPsters, I was away for a couple of days and I see that in the mean more task were volunteered that have an UI impact: * metadata stuff (jpeg dialog) * iWarp tool (right-on Tor!) * jitter and smudge and something about text (layers), that is not so trivial in the UI btw, text, svg and other vector stuff need their own stacking order within a layer and if you want to avoid the question are they above or in the layer pixels, then they need their own layer type. anyway, Sven also asked me to come up with UI items for the roadmap: 2.6 * make full use of cairo for the select/crop tools. out go the inverted lines, in come lightened/darkened planes; * solve user request #1, part 1: one menu bar, keep window with menu bar open when no image is open, true floating inspectors, transparency where inspectors overlap the image (found a way how it can be faked); (beyond?) 2.6 * solve user request #1, part 2: introduce one(!) single-window mode that users can opt for, it has to be done. dock and tear off inspectors + toolbox everywhere (single + multiple window modes); * color-neutral toolbox icons that are quick to recognise and work with, this task is 50% interaction design, 50% graphic design; really beyond 2.6 * geometry tools merge, this easy-move/rotate/shear/etc. then also goes into the selection-rect tools; * unleash the power of GEGL, full access to undo/redo any manipulation * layer dialog renovation; * all plugins to heads-up displays (no dialog) with full image preview (where performance permits); * blobs of paint palette and there is lots and lots more to do... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] roadmap items from the UI team...
Sven wrote: * solve user request #1, part 1: one menu bar, keep window with menu bar open when no image is open, true floating inspectors, transparency where inspectors overlap the image (found a way how it can be faked); I don't think that true floating inspectors are implementable at all. But perhaps you need to explain first what true floating means. let's see: always on top of any normal window, but under menus and dialogs; does not appear in taskbar; not visible when GIMP is not the foreground application. that is the mandatory bit, I think. I wouldn't like to put something on the roadmap that we can't solve for technical reasons. I was getting more positive because you were talking in optimistic terms about when 'always a window with menu bar' would be implemented. are we now back to 'you'll have to patch all window managers to do that'? Transparency is not a problem on the platforms where it is supported and we can easily enable this in trunk right away since we are using GTK+ 2.12 there. I get the feeling that all is not rosy there, but at least I know that I can always work around that... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] roadmap items from the UI team...
Sven Neumann wrote: Alexandre Prokoudine wrote: I'm not sure this is the right time and place to argue, but from my experience using Paint.Net, which has this functionality, transparent palettes will absolutely useless and even annoying. I agree. Transparency will be distracting. counter example: Aperture. it is all about using the right gray and alpha values. The really fat bonus of implementing this is that users get the impression (and associated speed-up in workflow) of being able to see the image on the whole screen. Even if part of the real precision work can only be performed in uncovered areas like now. Also, because the toolbox and inspectors are still visible, there is no penalty in how quick a click in either can be performed (this is the case for hiding minimising toolbox and inspectors). As it causes wrong color appearance, it is IMO a very bad thing to do in a user interface that is made for working with colors. well, obviously where one works with colors in the inspector that part is either never or on mouse-over not going to be transparent. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] roadmap items from the UI team...
Sven Neumann wrote: well, obviously where one works with colors in the inspector that part is either never or on mouse-over not going to be transparent. Where we are back at the point where this is not likely going to be ever possible on all supported platforms using the toolkit that we use and will continue to use. I am used to development teams telling me 'can't do that', but I am not used to them refusing to sit down with me to find a work around solution. It would probably help if your team seeked for less drastic changes. That would have the benefit that they might really be implemented one day. I really don't want to show users mockups of stuff that they will never receive. I tend to get 90% results in the projects I work on by setting 100% goals and working with the developers after they tell me we can only achieve 40%. That's how it goes for the last 10 years... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] roadmap items from the UI team...
Sven wrote: On Thu, 2007-11-08 at 00:06 +0100, peter sikking wrote: Where we are back at the point where this is not likely going to be ever possible on all supported platforms using the toolkit that we use and will continue to use. I am used to development teams telling me 'can't do that', but I am not used to them refusing to sit down with me to find a work around solution. We aren't refusing to find a work around solution. But so far we only talked about the short-term plans and we have not sat down at all to talk about the long-term goals for the user interface. Perhaps we should do that before we put these things on our roadmap. So for now it is probably best if we concentrate on the short-term goals that we agreed on and that can be implemented. Perhaps we can discuss the long-term GIMP UI vision at the next LGM then. fair enough. I am also uncomfortable with the fact of having to convince people of putting on the roadmap rather deep-going paradigm changing solutions without writing first a couple of white-paper type of blog entries where I show how all this stuff hangs together in a deep, complicated way. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap items
Alexandre Prokoudine wrote: Here is the list of proposed changes in 2.6 that Sven asked for: Tools - full use of cairo for the select/crop tools (?) - color-neutral toolbox icons that are quick to recognise and work with (?) The ? character after a name means that exact intentions of that person are unknown. why are there question marks after these two items? Let me know if I missed something. compiled from my own summaries: * next generation size entries * finishing of: Heal Tool, Sample Points, Foreground Select Tool * Floating Selections * Alpha Channel * Layer boundaries * skipping annoying dialogs by default (individual assessment first) * solve user request #1, part 1: one menu bar, keep window with menu bar open when no image is open, try floating inspectors --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
resending... Sven wrote, On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote: One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. I would like to get some feedback from the UI team and from some artists on this. And of course the patch would have to be reviewed before it is committed. I am not yet convinced that this is an important feature and I also have the impression that it's just added ad-hoc without seeing the big picture. It certainly has the potential to cause a lot of problems. yeah. Kamila came up with the plan for rotating guides and I could see then how it could have an impact on for instance web design by breaking the normal hor/vert grid. and after a few minutes I could come up with a decent on-screen UI. but the real question is the priority of this yet-another-feature. something like geometry tools integration has a much higher priority than this. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap items
Sven Neumann wrote: On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote: - vector layers (Henk Boom?) I would be glad to continue work on this Before we add this, we should get some feedback from the UI team. Well, this topic is not so clear cut. There are many factors: - the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two. - yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes. - GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable? Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
William Skaggs wrote: I've been working on using the new rectangle tool interface to allow changing the shape of a text layer by moving edges around. Sven suggests, and I agree, that it would be good to have input from the UI team before making changes to SVN trunk, hence this email. When 2.4 came out, I made a statement that that day was also the end of fire brigade mode for the UI team. So can we do this in the right order please: 1) we decide that this issue is worth our limited resources and has higher precedence than other issues (that will remain unsolved); 2) we therefore put it on the road map, stating what we will tackle, leaving out the ambitious stuff; 3) UI team creates a UI solution and writes spec; meanwhile a technical proof of concept (feasibility) can be lashed up; 4) real code gets written and tested; 5) user manual gets updated. So right now for this issue only the second part of point 3 (the lash-up) has been done. I am not sure this issue will pass point 1, at this moment. One of the biggest crimes in user interaction is to let a piece of existing code inform the shape of new interaction solutions. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
Tobias Jakobs wrote: On Dec 6, 2007 2:10 PM, peter sikking [EMAIL PROTECTED] wrote: When 2.4 came out, I made a statement that that day was also the end of fire brigade mode for the UI team. So can we do this in the right order please: That is only fair and I think the results will be better this way. 1) we decide that this issue is worth our limited resources and has higher precedence than other issues (that will remain unsolved); Who do you mean with our limited resources, the UI team, the programmers or the complete team? All involved in development: UI team, developers, documenters. 2) we therefore put it on the road map, stating what we will tackle, leaving out the ambitious stuff; Do we/you have a list with the impotents of the different issues? I think that is a consensus thing. Also everything is connected with the phased introduction of GEGL, which we have seen recently makes working on some urgent issues a waste of time, because a lot of code will be scrapped. And yes, I understand and support that 2.6 is going to be 'light' on UI changes, to get the phase-one GEGL work done. Can we use the road map for this or do we need a second list? Let's see: a roadmap is new for GIMP, as is a structural UI renovation project, as is a new engine. We need to get experienced with this and better integration of all big ideas out there. From my side I need to contribute by doing the analysis part of our UI process and make that accessible as blog entries (a GIMP issue a day?). I am really looking forward to a roadmap... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP lecture, berlin...
GIMPsters, This Wednesday (12‑12‑7) I will be presenting at the newthinking store in berlin. It’s berlin‐usability‐stammtisch‐Wednesday and I will do a lecture on GIMP, open source and interaction architecture. Apart from the announced focus on the run of the GIMP redesign project thus far and our professional approach to the top‑10 most requested features, I will also elaborate on the—partially novel— methods developed during the project. If you are in or around berlin this Wednesday, I hope to see you there. Tucholskystraße 48 10117 Berlin, it starts around 19:30. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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
Hi all, chiming in here (getting back to speed). 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. see: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp- user-requests.html topic 6. organise brushes, palettes, gradients in categories. Also, having to 'tank' the resources in and out of the workspace is a waste of time, especially if you do 5 or more different graphics jobs in a single day. Architecturally it feels a thousand times better to have 'zero-conf': all the resources (say brushes) are 'just there', and click a few tags (that match your needs) to narrow that down to the dozen or so to start working. Also the mentioning of both the file system and the preferences (aka. the graveyard of any good idea) makes that a couple of alarm bells go off here. There is no need for that. William Skaggs wrote: Here is the idea: 1) You have a workspace, holding the brushes that you are currently interested in using. The brushes shown in Gimp's brush picker are those that belong to the workspace. The user has complete control over the contents of the workspace -- anything in it can be edited or deleted. The workspace is saved from session to session, and automatically loaded at startup. 2) You have a set of extra folders, specified in Preferences. The brushes in these folders don't automatically belong to the workspace. To get at them, you invoke a Brush Chooser, which pops up showing a list of brush folders, and a view, which can be either a list or a grid. Clicking on a folder causes the contents to be displayed in the view. Double-clicking on a brush in the view causes it to be loaded into the workspace. Once a brush has been loaded into the workspace, it stays there until you delete it. 3) You can also use the Chooser to save a brush from the workspace into the currently selected folder, assuming you have write permission there. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
Hey all, sorry for fading out of view for a while. demanding projects (ongoing), a big flue and christmas got in the way. but that is just part of it. The other part is the lack of a roadmap. the lack is now so that I was prepared to write one myself, just to have something to work with. But I remembered somebody was on it, it turned out to be Alexandre. Even before 2.4 came out, I was warned that not to much UI work could be done for 2.6. GEGL first. OK. suits me, that leaves a period where the UI analysis can get (finally!) done and a transition can be made towards tackling the mayor UI issues in GIMP systematically, based on a UI masterplan. At the release of 2.4 I announced the end of fire-fighter mode accordingly. Then during the roadmap-2.6 items kept popping up that deal with UI problems. Fine, we can work on them, as soon as the roadmap is fixed. Yep, fixed. frozen. A roadmap is a tool for me to plan (assign tasks to my team) and also to say no to spontaneous initiatives that need a long, full spec (say, polygonal tool). When making the roadmap the rational decision can be taken what GIMP needs now: polygonal tool or fixing the floating selection. One gets the nod, the other has to wait for a next release to get worked on (UI spec, dev, test, doc, etc.) I see the list below of what needs input and they are all worthy problems to solve. But they look to be in part different problems than the ones discussed for the roadmap two months ago. There lies the problem. I will give direction for the small ones on the list below that have bug numbers. I am still putting out small fires. ^} the big spec ones need to be roadmapped to get done... Sven Neumann wrote: Merge toolbox and image menus Text boxes Keyboard Shortcut dialog Remove the add/remove alpha channel option for layers Show current aspect ratio in Crop tool Make it easier to select and move areas I hope that you and your team can help us to sort out these issues. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2008 UI new year's resolutions...
GIMPsters, a couple of more things for this year: First, Sven was right at my GIMP lecture last month here in berlin: the UI team needs to grow. So I want to add two more UI professionals to the team (double the size!). One more experienced person (3-5 years in interaction design) and one junior (right out of school/uni). question for the list: how to organise? advertise on gimp.org? Second: I have this plan to kick-start the analysis part gui.gimp.org by writing a long series of compact blog entries where in each I mop up the findings related to a certain UI issue and offer a general outline where the solution lies. Not a bullet (developer) proof, final statement. The content of each of these blog would go straight into its own page on the analysis part gui.gimp.org, where it would start living and evolve, driven by comment, input and further thought. question for the list: channel all this comment and input through this GIMP developer list? get the ball rolling... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] toward a plan for 2.8
Sven wrote: I think you misunderstood Peter's talk. These are the top 10 user requests, not the top priorities. It is very important to analysize user requests but it would be wrong to use this list as the basis for a discussion about the future roadmap. This should happen based on the product vision. right on. top-10 (as felt by the developers) user requests of the last years. and at the lgm we addressed them as well as we could at that time (printing? what can we say about printing? OK, a couple of things...) --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] no image open spec...
Sven wrote: Merge toolbox and image menus It would be very nice if we could get this done for 2.6. It would be a major user-visible change and as such it would give a clear sign that GIMP is moving. What's needed here is a mockup that shows how GIMP should look like with no image window open. And a specification that tells us what should happen when the first image is opened, what happens for the second image, what happens when the last image is closed. Purely due to the infectious enthusiasm of Martin on the irc, I have given that a start: http://gui.gimp.org/index.php/No_image_open_specification so far so good. After having defined what definitely not should be in that window, the question remains what actually can. I think now that the tip-of-the-day idea can get really old really fast, even if the tips are super and exactly what you need. To see them 10–100 times a day is too much, even though I do build in a slider to set the alpha of the whole tip thing. So after rereading the section in the spec about no gimmicks (please do): http://gui.gimp.org/index.php/No_image_open_specification#no_gimmicks here are some ideas I have for this window: 1) one of our designers (jimmac, garrett) makes a really nice, soothing, non-distracting, GIMP value improving wallpaper to show there; 2) like 1), but we ship with a whole series; GIMP shuffles through the series, shows a different one every time; 3) we have a repository of really nice, soothing, non-distracting, GIMP value improving wallpapers on gimp.org. When internet-connected, GIMP gets some new ones from the repository, ditches some others, shuffles like in 2). Users contribute new wallpapers, we weed out the crap. The 3 ideas above add a joy-of-use component to GIMP, not a gimmick. Another fundamental idea is: 4) a plugin system for this window; we ship a standard, good one like above. If somebody really insists he or she wants to see a file open dialog every time or the 10 last edited pictures (both not very good ideas to force upon one million users) then let them write a plugin to do that. and oh, note that the slider to set the alpha of what goes on in that window will be there anyway... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Sven wrote: On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote: and oh, note that the slider to set the alpha of what goes on in that window will be there anyway... This is not currently implementable, so I would rather not base the spec on this opacity slider. just to clarify: are you assuming that the whole window will become transparent and the desktop shines through? I am talking about making some stuff transparent against a window background, hardly rocket science for GIMP... I also very much wonder why the window should have something as useless as a slider to control the visual appearance the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction. but lack any useful widgets to give people quick access to the things they will most likely do next. What's wrong about a link to the recently used images and to the New image dialog? the thing to focus here is that GIMP is not going to behave like some kid yelling (yep, that is what a dialog is): that was fun, what are we going to do now... I mean now... really now! as long as we understand that, you will be able to understand the crucial decisions that I take here. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
GIMPsters, I am very busy, so I am going to weed out the actual contributions of y'all and respond to that: Sven wrote: We absolutely need to find a solution here that works for everyone. very well said. that's why the gimmicks section is in the spec. Thorsten raised a good point about the actual geometry of the 'no image' window. Of course this window is a nice drag and drop target for all those workflows that go to other apps of filebrowsers to open the next file or files. SO window not to small, not too obnoxious. Got me thinking again about always going to the minimal size when last image is closed. cool. Thorsten wrote: The opposite side of what are we going to do now would be see how you get along, I will not raise a finger to help you. Hmmm, menu commands, drag and drop on window and taskbar icon, menu shortcuts. A nice size window to find back in the window stack. saul wrote: The no image window should have a status line, as this provides useful feedback with regard to the hover-over hints of the menu commands. Good point. But then I realised which menu items would be available at all. Still thinking about this one. Bill wrote: If the user closes the final image by clicking the X in the upper right corner of the window, we must close that window or we violate a fundamental rule of window handling. Another good point to think about carefully. I evaluated both possibilities and in my minds eye leaving the window open is more elegant, less rupture. Sven wrote: I am talking about making some stuff transparent against a window background, hardly rocket science for GIMP... Even if this was possible, I still fail to see why this would be useful. To be honest, I am completely baffled to hear such a thing proposed from a user interface professional. What exactly, except for eye candy, is the purpose of this? Let me state that I wrote my first email in this thread because (yes) I am struggling what to put there. It is easy for me to make the list of gimmicks that not should go in there. Every on of those sucks so much... But what is left? The window needs to be there, already outlined above the functions it does. So instead of just plain bgcolor, let's do something a bit more stylish, without drawing any attention to it. Seriously, I would like to hear contributions here what to do (read the gimmick list first: http://gui.gimp.org/index.php/No_image_open_specification#no_gimmicks) the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction. Would you please care to explain this? I am going to let the slider rest until the window content is sorted out. Then redesign the whole package so it all fits together... Alexandre wrote: And we can't (yet) make GTK+ widgets translucent. Are you 100% sure? http://www.breakitdownblog.com/gnome-murrine-theme-gets-transparent- widgets/ that is cool (but not for this UI design). I would like to know how universally (all linux WMs, windoze, OS-X) that can be rolled out... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Tobias Jakobs wrote: I thought about it and I created this mock-up: http://hagemaenner.de/stuff/gimp/PlanB/6.png In the center of the area I've added a simpel text Drop Images here to open them. (Perhaps a native speaker should change the wording.) I have been moving in the same direction in the last days. If the main function of the window 'body' under the menu bar is to have a nice size drag + drop area, let's on its look + feel for that. As for the size of this window: just wide enough to fit the menubar for the running localisation,height of the window, 1/4 or 1/3rd of the width, some nice proportion. Forget about the slider, please. It belonged to another strategy, another time, another place... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] request for discussion: removing button relief
Bill wrote: I have been experimenting with ways of simplifying the user interface, and one very simple change that I think gives a rather dramatic improvement in appearance is to remove the relief from the buttons that appear at the bottom of numerous dialogs. This is a request for discussion. I have filed an enhancement request in Bugzilla showing a screenshot of what the result looks like, and a patch, see http://bugzilla.gnome.org/show_bug.cgi?id=515621 What do people think? I see that you and Mitch moved forward regardless. There are some deeper problems with those buttons (why are they there, allt the time, so prominently?), the ones in the layer dialog excepted. I would love to get this un-relief'ed look for most controls that are displayed permanently, would be a relief (no pun...) for everyone. Mitch and I tried to find a way last year. Alas, no cigar... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] request for discussion: removing button relief
Bill wrote: peter sikking wrote: There are some deeper problems with those buttons (why are they there, allt the time, so prominently?), the ones in the layer dialog excepted. I agree with this. I too think it would be best to have buttons only for the layers/channels/paths dialogs, since the others are not used as much and their functions can be accessed by the right-click menu. (Not for the Tool Options right now, but that could easily be done.) right-click is a shortcut for a primary way to do things. So in this case I see good chances for the not-so-often-used options to go in their own little menu that gets accessed from a small-no-relief-low-contrast-icon button in the corner of the dialog. I would love to get this un-relief'ed look for most controls that are displayed permanently, would be a relief (no pun...) for everyone. Mitch and I tried to find a way last year. Alas, no cigar... I would be interested to know more about why it could not be done. In my view, every unnecessary edge we can get rid of is a gain. find a legal way and you are my hero. Mitch and I could find no way how gtk supports showing the relief only on mouse-over, for things like pop-up menus. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Bill wrote: It seems to me that the separators are not that important, because the categories are pretty artificial in the first place, and were really imposed mostly to give the very long list some structure, as far as I can see. But this is something that you should consider. separators are very important in a menu, to be able to deal with many ( 5) items, by putting them in sub groups, you get your bearing for aiming. even arbitrary sub-grouping is better than none. Anyway, I would like to make this change, and I wonder if there are objections. yeah, this is also harder to use because you have to do a controlled sideways movement to get from one column to the other. sorry: no cigar... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
OK guys, here comes the moment where I have to cut the crap. Just like Sven or Mitch cut the crap when users keep discussing things that are technically not possible, I have to cut the crap when we keep discussing interaction that simply does not make sense. That is why I listed the gimmicks at the start of the UI spec: it has been checked, forget it, over my dead body. In difficult times like this I always go back to the product vision and GIMP is an high-end 'pro' app. It is used in an environment with other applications to get the job (or hobby) done. If you can see that whole picture, than you can feel where I am going. I'd rather spend some time now to show in the spec what I mean and to figure out what happens to the toolbox and inspectors when no file is open (hmmm, recent files dialog should stay open...). Sven wrote: we already found that using this window as a DND target has a severe usability problem who found that in what usability test? I must have missed that. You missed one of the mails in this thread then. If we use this window as a DND target, where should our users drop images when it is not there? I think the remaining question is: when GIMP is not the foreground application (toolbox and inspectors hidden, as they should) where can users d+d files apart from on the taskbar icon? I am thinking about that. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
sending this again: Sven wrote: Anyway, this is something that the UI team should specify. I hope that we will get some more input from Peter on this soon. after being drowned in work, I have time in the next days to wrap up this spec. writing a GIMP blog entry right now --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
Sven wrote: Anyway, this is something that the UI team should specify. I hope that we will get some more input from Peter on this soon. after being drowned in work, I have time in the next days to wrap up this spec. writing a GIMP blog entry right now --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ‘no image’ window: progre ss...
GIMPsters, some good news on this front, I have spent a couple of man-days rethinking and re-specifying the ‘no image’ window situation. It is now roughly complete: http://gui.gimp.org/index.php/No_image_open_specification If wrinkles need to be ironed out, let me know. The further fall-out of getting this done is menubar integration and getting the toolbox and inspectors off their main window status (no more dialogs in the taskbar). All to general users' relieve. Thanks to Martin Nordholts for encouraging me with true enthusiasm... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ‘no image’ window: progre ss...
hey GIMPsters, let me give you an update here. in the last 10 days the concept and spec has matured quite a bit. the feedback and plain old bug reports, both here and on the IRC went into what is being built right now. check it out when you have the chance. thanks, --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
