Re: [Gimp-developer] Isn't this behaviour unintuative?
I wrote: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] Isn't this behaviour unintuative?
Martin wrote: 2011/6/30 peter sikking pe...@mmiworks.net: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. It looks straightforward and I expect to be able to update the code for 2.8. One gripe: The spec says give secondary support to workflows where the input and output are the same non-xcf file and you just made this a bit harder (OK-ing the Export to dialog) no, nothing changed in the Overwrite workflows. today's changes can be summarised as: - in the cases where before Export to was insensitive, it is now sensitive and mapped to invoke Export... (the dialog) - in the cases where Overwrite blocks Export to out of the File menu, the shortcut of Export to is still active and mapped to invoke Export... everything else works like before For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut? I noticed the equivalence between the Export and Save departments a long time ago. Today's changes take that one step further. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] Isn't this behaviour unintuative?
On Jun 28, 2011, at 11:35, SorinN wrote: But there was already Ctrl + Shift + E which bring up the dialog for export Ctrl + E was for overwrite without confirm. Probably the logical order was inverse - many peoples expecting Ctrl + E to bring up the export dialog, first of all, ctrl-shift-e was chosen because it works like that cross application (inkscape and co). also think about it: when working on a project (serious work = our priority in design vs. hit and run editing) then there will be in quite a few workflows a lot more ctrl-E (equivalent to ctrl-S) for reviewing, than ctrl-shift-E (equivalent to ctrl-shift-S) for anchoring to another export file(-path/-format). this is why I am insisting that it is not going to change, in the future. since the GIMP team (and I as interaction architect particularly) have the duty not to encourage overwriting/destructing the original file by accident, there is no shortcut on overwrite by default. Users can set it by hand, it is their call on the convinience vs. danger balance. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Thesis about managing Open source projects-informantions about GIMP
Dear GIMP developpers, My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. I wolud like to help them by providing contact to GIMP leader project. Is it possible to be sent contact to project leaders or their mailing list, please? I look forward hearing form you Yours Faitfully -- Ing. Peter Fodrek, PhD. Research scientist Department of Informatics and Communication Technology Institute of Control and Industrial Informatics Faculty of Electrical Engineering and Information Technology Slovak University of Technology at Bratislava, Slovakia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thesis about managing Open source projects-informantions about GIMP
On Tuesday 03 May 2011 14:15:08 Alexia Death wrote: On Tue, May 3, 2011 at 2:46 PM, Peter Fodrek peter.fod...@stuba.sk wrote: My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. Send your people to #gimp IRC channel on gimpnet. However you seem to be looking for a rather mythical beast. What makes you think open source projects necessarily have project leaders? We have lead developers, we have one guy who does office manager stuff but I cant say we have a project manager... I think project founders, lead developers and code reviewers acts as project distributes leaders managers. Students task is to found how open source projects are organized. I am open source develloper but only in very smal OSS project HeeksCAD (3 founders/reviewers, 42 ever time commiters), HeeksCNC (3 founders/reviewers, 8 commiters) with centralized SCM systems. I am to think branch maintainers are managers as well. Thank for your answer I look forward hearing from you Yours faithfully Peter Fodrek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
Alexia Death wrote: Well, on developer side there seems to be a consensus forming that this ps- menurc file should and will be removed from git and I personally agree. such enhancements should be maintained outside gimp. So most likely, once this is over you are furher away from what you came here for than before. right, and I do not only think it is the right move (for GIMP to signal here is a free as in beer ps copy is exactly against the vision that GIMP is not a ps clone), I also initiated it. let me clarify that author/contributor Alexandre Prokoudine wholly agrees with the removal. now if nobody is faster than me, I will do this remove as my first act as resource maintainer. The docs will have to be updated to reflect this. what is the best procedure to set this in motion? --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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 and Tablets (or other extended input devices) with newer GTK2 versions?
I read the announcement on the Gimp home page regarding Gimp 2.8, which also mentions the broken graphic tablets support in GTK+ as a showstopper without providing any details. I personally can't get my tablet working with anything newer than GTK+ 2.18. I filed bug reports some months ago (for details see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593087 https://bugzilla.gnome.org/show_bug.cgi?id=627022 ) so far without any reaction. Even though the problem I have makes a tablet (or probably any X11 extended input device) almost useless, I also could not find any other reports about this issue - all messages about problems with tablets are either old, or referring only to MS Windows, so I am not sure if this is a problem only I have or if nobody cares because there are just not enough people using such devices (which I always suspected because at least on a dual-head display using a tablet for many years has been very cumbersome) Therefore I'd be very curious to know what problem that gimp announcement is talking about and if there is actually somebody working on it. If it's something totally different (recent postings on this list sounded like it was GTK3-related - I didn't' even know there was such a thing ...), I'd still like to know if the problem that I have is for some mysterious reason only affecting me or if if this is a known issue - and maybe even some hope for a fix ... (Until I find a solution for this, I am stuck with gtk2.12 and gimp versions old enough to work with it) Even though the problem itself is clearly in GTK and not in Gimp, maybe there is some interest here because Gimp certainly is the most prominent application that can use GTK's tablet support ... Regards, Peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New adjustment widgets
Cedric Sodhi wrote: I'd like to bring up an idea that does not seem too difficult to implement and that should replace the unusuable slider widgets for, say, brush size. If you are okay with that, I might implement it. The sliders are virtually useless because they cover a fixed range from 0 to insert big value here without any intelligent behaviour. For the brush size, for example, that means you can at best alter the brush size in 20px steps with a reasonably big toolbox. I think I have something there for us that is more straightforward: two things actually: #1 is what I got the Krita guys to implement during a sprint of theirs that I attended, it was based on my work on #2 actually. It works for long sliders in dialog boxes, not for our tool options panels. say you got a slider going from 1 to 1000. then divide the slider range (in pixels) in 3 equal parts, so that each handles a decade: |-- 1–10 --|-- 10–100 --|-- 100–1000 --| within each third the increase/decrease of value is linear. the Krita guys love this system (hardcore tablet users, btw), but as I said: only for long sliders. #2 is where I developed the whole idea. I was working on tool options widgets that would allow the whole tool options dockable to be exactly 2 toolbox icons wide (normal icon size, the need for the small theme goes away a.f.a.t. toolbox is concerned): http://mmiworks.net/test/small.png top to bottom those are are 1 popup selection list, 4 sliders and two 'checkboxes' (on/off switches), in real 1-to-1 size. yes, cut off texts are shown fully on mouse-over: this is GIMP and usage is trained, so position; (part) identification and feedback (could better on the checkbox, I see now) are what count. you can see here where the current experimental sliders in git come from. Krite did their #1 sliders in this form, but not the following: so how are these tiny sliders going to work? well click the mouse button down on the slider (not on the number) and this pops up: http://mmiworks.net/test/decadepopup.png with the current value right under the mouse position, so releasing in panic does not change the slider value. moving vertically you switch decades, horizontally everything is linear within a decade. one could easily add decades, having a range factor of a million for instance (e.g. 0.01–1) when that is needed. grocking is simple, motions (up/down, left/right) are linear, feedback always there. is there a flaw? yes: popping up at the screen's edge, and wanting the 'value right under the mouse' to work. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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 adjustment widgets
Thorsten Wilms wrote: On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote: http://mmiworks.net/test/decadepopup.png Aside of differences in labeling (of course not unimportant), it's the same concept as http://www.sidefx.com/docs/houdini9.5/basics/ladder right? vertically: yes, close enough horizontally: no (dragging in thin air?) single click popup, single move adjust: yes primitive text widget with no slider scale: no (just to be exact) --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brushes again...
GIMPsters, talking to Alexia today we came up with a matrix of different cases needing different cursor feedback: in one dimension: mouse up; mouse down + not moving; mouse down + moving in the other dimension: painting; touching up; textures/image brushes/ stamping multiplying this 3x3 matrix out we got 9 cases that all need their own feedback (or not) for assessing the 1) centre coordinate 2) outline of brush stamp 3) opacity of stamp pix 4) a fitted ellipse or rectangle that hints at the total brush area, aspect ration and angle. the goal of this mail is to getting this matrix filled for each case. share your experience, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] GUI enhancement patch from GIMP UI brainstorm blog
Bernhard Guillon wrote: I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see: What is wrong about a high fidelity prototype? It is a central task of the usability engineering life cycle [Nielsen]. Adding it to master might be wrong but usertesting is not bad. well, see here for my take on proper integration of usability: http://blog.mmiworks.net/2010/11/rise-of-proper-integration.html it is a very fitting post for our current thread: organisation, process, authority. clarification: at the moment there is interaction design at GIMP but no usability as defined in the post (empirical testing). usability testing for GIMP is tricky, because it is a power tool that has to be mastered. Discussing this a while ago with Ellen Reitmayr (a fellow openUsabilty founder) it became clear that any UI innovation has to be prototyped, let a group of users train for a month with it, then perform tests focussing on ease (read: speed) of use. http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html Improving Flexibility might help... I am not sure what you want to say with this. so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing. If you only do steps 2-6 you implement your mental model. Prototyping and user testing is not bad at all. so back to your argument: 1) there is no value in usability testing random ideas, as were implemented here. There are thousands of random ideas, with an infinite number of combinations. there is value in testing UI designs (step 2–5) to debug their concepts. 2) throwing out a prototype and getting some user feedback _is_ by definition the armpit of usability. proper testing is a whole other ball-game. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] GUI enhancement patch from GIMP UI brainstorm blog
hi しげっち, I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming. you do realise that the brainstorm is a 'sandbox' for ideas? the deal is that everything is OK within a brainstorm (so ideas keep flowing) but that is only _within_ the brainstorm. when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP. steps 2–5 are what I bring to any project and customer I work with. sometimes these steps are necessarily heavyweight because of the complexities involved, sometimes as lightweight as 15 mins of thinking and an email or irc exchange. it depends... for the patches you sent, only step 1 and 6 were done: 1 by the brainstorm participant and 6 by you. the steps in the middle are missing. this is not criticism of you, most (99.9%) of the software world does not do and know any better than that. but here at GIMP we do better. other folks here will be able to judge the quality of your code, but I can see your enthusiasm to work on UI issues that matter, and we have a backlog of that. I am gathering resources at the moment to get more done for GIMP on the UI design side, we could use your enthusiasm to have more power on the development side. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] GUI enhancement patch from GIMP UI brainstorm blog
しげっち wrote: I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list. I also spent most of a talk at an lgm discussing this topic. in the bigger scheme of things (space, how usable toolbars are) I do not see GIMP having a toolbar. 2011年1月4日20:46 peter sikking pe...@mmiworks.net: when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP. ==snip== steps 2-5 are what I bring to any project and customer I work with. I agree that these features must be reviewed by many people in official and commercial process, but we also want to have a prototype to get positive feed back. It's very good and superior point of the open source software to implement GUI freely by anyone and have review it by many other people. It's just a patch of the my private work for now, so we can review it and simply ignore many of them. Let's try step 2-5 based on the feedback from existing prototype. nice try, but: no. I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see: http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] unsharp mask
OK, now the interaction design input: yes, someone made a terrible mistake more than 20 years ago by taking a metaphor from the physical photo lab and using it in the digital software realm without taking the change of medium into account. this is a very common mistake, when metaphors are taken from one medium to another. so it should have never been called unsharp mask. I have nothing against correcting mistakes made in the past, but we are in this case stuck with the name. and as Sven pointed out, our product vision implies high-end use with thousands hours of (self-)training included. mastering any professional tool takes that amount of effort. no shortcuts. so we have to live with the pro' (in-crowd) name for this and not make ourselves ridiculous trying to reinvent this wheel. the best suggestion I have ever read (and this issue has been chewed on again and again since the first UI review I did with Kamila ages ago) is: On 8 Dec 2010, at 23:39, Sven Neumann wrote: About the menu, that's a good point. IMO it would be useful to have a Sharpen group in the Filters-Enhance menu, separated from the other filters. Here all sharpen filters can register and having Unsharp Mask in a group with Sharpen should be a good hint on what it actually does. clarification by context. good. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a reset...
GIMPsters, just FYI, but to escape out of a backlog of 641 GIMP devlist emails waiting for me with ever more not-so-trivial-as-one-thinks UI issues waiting for me, I had to set them all to read, and jump in again. on a more positive note, in order to get some UI work moving for GIMP again, I am in the process of creating (and paying for) two internships at my company. These two apprentices will work by default on GIMP under my direction. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] html layers
Lightning wrote: I don't agree with some of the product vision points as stated in the UI redesign wiki and by some developers (for example that GIMP is meant mainly for high end users and less for simple users - as we discussed on IRC yesterday) well, that is a tricky thing to say. It was the core GIMP team that was there at the first LGM, and they were really sure about this. The vision is not my thing, I was only there at that moment to function as a catalyst to get the vision on the table. So it really does not matter whether you or I agree if GIMP should be what is says in the vision. Because it is going to be what it says in the vision anyway. It is going to be UI designed and developed in that way, because GIMP as a project wants to to go there. Anything that gets done in another direction is just a detour and a (ultimately) a waste of time because it will get corrected in the long run. and no, the vision cannot be changed on the hoof, because most of the work that has been done since that first LGM and now would have the be redone. --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] html layers
Alexandre Prokoudine wrote: On 7/31/10, peter sikking wrote: so there is an explicit 'no' for GIMP as a web design tool. You probably meant web programming :) no I really meant the web design job: deciding how all information and interaction is gong to be represented on the page, how the layout handle fluid conditions of resizing browser width and browser font resizing. all the typography and readability. that combined with the 'master' visual design from which all the pages will be produced, at which point all the images for a site will be produced (which is where GIMP comes in). there is an explicit 'yes' for GIMP as a production tool for all graphics that are used on a website. This does mean that there needs to be better support for this, like automated cutting and exporting of all the parts from a working canvas, much more than the hack-ish slicing we have right now. But that would also involve saving information about slicing in XCF or whatever comes after current XCF, because one really doesn't want to do all the work over and over again. yep, one or more 'cutting masks' would be part of the file, because the (perhaps overlapping) rectangles where to cut are gonna be different for every file. --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] html layers
bob wrote: Smashing magazine linked to an interesting blog entry, where John Nack discusses the possibility of HTML layers in photoshop. If I understand the gist of his proposition/fantasy, the idea is the ultimately his image editor would have a feature that can import, present and edit html elements as components of a layer. I remember skimming that article. I thought immediately of what the GIMP team said during the discussion of the product vision. I brought up 'what about making mock-ups of web pages?' after a serious look at what it means to support that (like pro-grade html generation, support for fluid layouts), the team clearly felt that this is not what they wanted GIMP to be. so there is an explicit 'no' for GIMP as a web design tool. there is an explicit 'yes' for GIMP as a production tool for all graphics that are used on a website. This does mean that there needs to be better support for this, like automated cutting and exporting of all the parts from a working canvas, much more than the hack-ish slicing we have 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] Please fix Color and/or Value transfer mode
Rob Antonishen wrote: Would it not be simplest to add a corrected colour mode as a new mode, keeping the old one? Just call the old one Colour (legacy)? and give the new one a new internal mode number? yes it is, same for non-working overlay mode. There is no requirement to have back compatability, so trying to open an xcf file with this new layer mode would fail on an old version of gimp, much like any of the new features. hmmm, let's see if everybody thinks this is so cool... --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] Bug Bug 568150 With 'Resize window on zoom', zoom focus does not work when window is of maximum size
xianghang liu wrote: I think this bug can be fixed by the attached patch. great. I trust that the solution is the right thing because Martin pointed out in the bug what should happen and where to repair it. I have checked Photoshop CS5 and found it has a similar behavior. uhm, can I (without drama) say that that proves exactly nothing for us? in general, a the right UI solution for us is: - good UI design in general - fits the context of GIMP (metaphors, models, legacy) on both counts ps can be pointing in exactly the wrong direction. --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] Enhancement request: better utilization of mouse buttons
Bill Skaggs wrote: The global popup menu is certainly useful; I have used it very often. The context menu for the text tool was introduced as part of on-canvas text editing. It was introduced because on-canvas editing could not work without it -- there was no reasonable way to access text versions of Copy and Paste and other essential commands except by using a context menu. hoho, when that was discussed I was there and I made it very clear that the only acceptable way to do copy/paste in the text tool is via the standard commands in the Edit menu, with their standard command keys. Let me also give general guidance on what a right click menu is for, what its place is in desktop UI systems. The right click menu is a _secondary_ way to get things done. First of a primary way has to be UI designed to do something: like an item in the menu bar (see copy/paste), a tool options item, an on screen widget (text editing toolbar, a control node on a curve), widgets in dialogs. Only after the primary way is designed and implemented, is it time to think what could be in the right click menu. It is an 'acceleration' mechanism (although I consider it slow and finicky) like command keys, although more locally targeted. So the choice to make becomes 'what are the limited number of items that are so important they need to be also here in this menu?' One last note to those users who find right click menus incredibly useful and even perceive using them as fast (note, perceive): I do not have the numbers whether 30, 40 or an unbelievable 60 percent of users are like you, but it is certainly not more. So the rest of us is not enjoying using right click menus so much. And the right attitude towards right click menus is always to try to solve it in a better way first (see above). SO for instance our full-screen mode and the menu bar. I am asking myself: could we not show the menu bar when the mouse sprite is moved against the top of the screen (after a short, 0.5s, timeout)? fading or sliding in would be nice... --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] Help with new default resources in 2.8
hi all, the reason I talked myself into the position of 'maintainer of default resources' (is that a title like 'floor manager' at mcdonalds?) at the LGM is that I voiced concern over how they can either enhance or sabotage the product vision: http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision to give a fictive, crass, but clear example: if somebody checks out GIMP because she is looking for a 'high-end photo manipulation application' and is confronted by 213 (well-drawn) clown face brushes, then we are in fact killing the GIMP project. first of all, resources in GIMP are: - brushes - patterns - gradients - palettes - paint dynamics - tool presets so what are we looking for for each of these resources? well, apart from rule nr.1 formulated above (enhance the product vision? in; sabotage? out) I think it is either 1) the default resource is a 'must-have primitive' for the resource type. simply cannot do without it. this is analogous to that a graphics program 'must have' a way to draw squares, rectangles, circles, ellipses, lines. or 2) the default resource is general purpose, very versatile. example: a brush to paint grass is _not_. a brush that with some tweaking and combining can be used to paint grass, hair, fur, brushed metal and rain _is_. or 3) the default resource showcases the depths and sophistication of the resource type. the stress here is on being educational and a starting point for users to make their own deep, sophisticated resources. I am not having high hopes for these defaults also to be 'must-have primitive' or 'general purpose, very versatile,' so there is not going to be a lot of them and they better be classy. oh, and talking about classy, there is going to be a 'no cheese rule'. a Leopard pattern? no no no. then here some notes for some of the resource types: patterns a first look here tell me that application of the rules above will clear out (almost) the whole section. size matters here, large (thousands instead of 16–128 pix) patterns to avoid visible repetition. the one thing I can think of we need pronto is one or more believable film grain patterns for photo manipulation. gradients similar big cull coming palettes the websafe/visibone stuff looks really deprecated in 2010. something like the Tango Icon Theme palette is an excellent example of a resource the fits with the product vision (GIMP is Free Software and a high-end application for producing icons). paint dynamics paint dynamics are still fully in development, including the actual functionality. it is not useful at the moment to contribute paint dynamics presets. one last thing: we have a green pepper problem. it fails several of criteria outlined above, but the GIMP team seems to be emotionally attached to it. similar to the GIMP name, we seem to wear it as a badge of honour. so I am 50/50 on in/out. this may prove to be the hardest decision of my career ^} --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] Gimp UX: Paste
Gino D wrote: Having said that, if there is no need to merge layers together, but you simply want to manage the pasted object as indipendent layer, then the optimal solution is to use the Paste as New Layer command rather than the Paste command, which actually generates floating selections. According to me, the only small drawback of the former choice consists in the fact that such new pasted layer doesn't come centered on the target image (as it would be convenient), whereas, on the contrary, every floating selection (when pasted) does. as I said yesterday, this new-layer-from-clipboard workflow needs attention too. user efficiency (speed!) and flexibility are important here. one aspect (as Gino points out) is default placement of the paste on the new layer. but in the majority of cases it will be in the 'wrong' position and it needs to be moved to be 'right'. so I think the new layer should appear with the paste floating on it in default position, ready to be moved and/or anchored. In this new layer scenario I think the controls for opacity and blend mode should not be there (on canvas) because the new layer will take care of that. hmmm, thinking about it a bit more, this sounds like the solution is actually to have the new layer appear with the paste anchored in the default position, but with a selection around it active (same shape as used for floating paste) and the upcoming combined transform tool as active tool for moving, sizing and deforming. but that is a thing for the future... --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] Gimp UX: Paste
Jason Simanek wrote: but in the majority of cases it will be in the 'wrong' position and it needs to be moved to be 'right'. Paste to new layer currently pastes the copied pixels in the top-left. I think Gino suggested that it be changed to 'centered'. It sounds like you are saying it should be pasted to the exact location where it was copied from. I agree. The pasted pixels should end up exactly where I copied them from. moving it 'right' is a user thing, because GIMP cannot guess how the resulting art has to be. I have not made up my mind about the default but exact location (when available) sounds correct, else centred. sounds like the solution is actually to have the new layer appear with the paste anchored in the default position, but with a selection around it active (same shape as used for floating paste) and the upcoming combined transform tool as active tool for moving, sizing and deforming. Not sure about this. I actually think the selection should be removed. When you copy/paste text in a text editor the pasted result is just text, not 'selected' text. bad example, because there you set the cursor before the paste to control where the paste is inserted: total control. in GIMP there is no such thing. a paste is generally moved into position after pasting. Besides, if the pasted result is on a new layer there should be no need for a selection. The entire layer is dedicated to the previously selected pixels, so you should be able to manipulate the layer without the need for the initial selection. that's better. you are right about 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] Gimp UX: Paste
Jason Simanek wrote: Has there been any discussion about doing away with the 'floating selection' quasi-layer that occurs after copy/pasting in Gimp? hey, what a coincidence. actually last weekend at lgm there was a meeting (joao, pippin and me) about giving Elle Yan's 'on-canvas tool' SoC project a purpose. everybody agreed that the concrete goal should be tackling the 'floating selection', which involves some simple on-canvas controls and build/exercising the infrastructure for that. I don't mean to compare the Gimp to Photoshop, but it seems like this is a place where Photoshop does the right thing: when graphics are copy/pasted a new layer is created. In my experience the floating selection quasi-layer has little or no usefulness. A new layer is non-destructive. Why is there a need for this other type of layer? The name 'floating selection' isn't even accurate. This is a collection of pixels. It is not a selection. A selection is an ephemeral mask not a collection of specific pixels. yes, 'floating paste' is a much better term. another coincidence: during my talk at the lgm: http://river-valley.tv/a-first-outline-for-a-ui-for-a-fully-gegled-gimp/ I talked about layer abuse, not by users, but by applications that make certain things only possible by introducing a new layer. that has to stop: only users get to decide how many layers they need for organising their composition. so pasting is going to be _in_ a layer (or mask or channel) and the controls for opacity, blend mode and anchoring will be on-canvas. there will be quite a few things to take care of, like new-layer-from-clipboard workflow, and they will be. While I'm at it I also recommend that layer boundaries should be disposed of. yep, that will happen, one day. --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] GSOC - On-canvas tool project tasks and plans - Google docs link
Elle Yan wrote: I am sending the tasks and plans of my GSOC project to the mailing list. It is a made public Google document: http://docs.google.com/document/pub?id=1DESI4rzEoTe6dep_qPqcSJAklHdjGiw7VILuREftj3E it is good to see this overview, so I can see how wide plans are casting their nets. Joao has already requested a session at lgm, so we can put a solid interaction design basis under this, also aligning it with future directions in on-canvas interaction. --ps street photographer : ultra-fi builder : on drums... sound practices reading club: http://ultra-fi.blogspot.com/search/label/sprc --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 background removal tool like the one in Office 2010
Someone Somebody wrote: I think a background removal tool like the one that exists in Office 2010 will be very useful in GIMP. for GIMP a one-trick-pony tool like that is not appropriate. for the level of use (high-end) that GIMP is tuned for, the combination of foreground selection tools, invert selection and then do whatever you want, on any number of layers, is the power that users expect. --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] Addressing one of the gimp vision items...easy installation of plug-ins
Rob Antonishen wrote: I was reading the gimp vision again, and two things jumped out: - GIMP is easily user-extendable, by easy installation of plug-ins - GIMP should be easily extensible by the average user: one click-installation of plug-ins and was wondering if this could be implemented within the current codebase I thought I discussed this last year with somebody who really wanted to build us a repository... there is two things I want to say that are requirements for this one. one click _really_ means one click. this one click is either: - in some website; - inside a plug-in browser within GIMP; or - on the desktop, but only when it was not received by the 2 methods above (e.g. from a friend on a USB stick). the other thing that is important is that GIMP should not have to be restarted for the new plug-ins to appear and work. my 2 cents, --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] Creating a new Layer
Thales img wrote: We make a 100 x 100px rectangle selection on a 2000 x 2000px, and we want to create a new layer to paint the rectangle, so when we ask a for a new layer a popup is opened asking Name, Width, Height, etc, for the new layer, for default the Width and Height values are 2000px² (our document's size), we click Ok and we have a new layer. My point here it is that we have a 2000px² layer for a 100px² object, and as I can see - as a user - a 2000px² consumes more performance(I don't know if it's Memory or CPU) than a 100px². So my idea is to have a option when creating a new layer; maybe a checkbox with something like: [__] Follow Selection's Size this whole thing is way too much incidental to include in the dialog. users might even conclude that it is the preferred way to do it like that. since as noted we are going to solve the problem from the other end, I think all the copy selection + paste as new layer variants we have are enough to tie us over. That is a step in the wrong direction, the right thing to do is to make layer boundaries automatically managed so a user won't be bothered with the New Layer dialog at all. It seams to be much more difficult, don't you think? not for users. --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] GSoc - Brush Selector Widget
Zhenfeng Zhao wrote: Thank you for the quick feedback... now for the not so quick feedback... I think we want to have the 'from scratch' mode mutual exclusive with the 'from collection' mode. this separates nicely the 2 modes users are. this must be done by switching the mode at the top of the brush selection dialog (a copy of which also pops up in the tool options). of course a 'from scratch' brush can be saved into the collection. then it has become clear that the 'from scratch' mode is equal to the brush editor (which can definitely use improvements). OK, it sounds like a good solution. There can be two modes: choose from the brush selection/collection, and create a brush using brush editor. I call it subtly different: 'choose from collection' mode and configure using brush editor (there is no obligation to save it in the collection). just to be clear. ah, and when you implement a pattern like that, you will be required (I bet) to make the changes in such a way that they get applied to all resources (patterns, gradients, etc). How does the modification apply to patterns and gradients? Do you mean when using a brush shape and a pattern for the stroke? In Clone tool, pattern and brush can be selected separately to use together. If so, I can see there is some work to use a customized brush. Wait, if I make a vector brush using brush editor, and use a pattern source in Clone tool, it works and puts pattern in the shape that I just created. So, if I adjust the UI to have two modes, a newly created vector brush should work with patterns right away, right? what I meant is the interaction pattern of having a 'from collection' and a 'from scratch' mode in both the dockable dialog and the tool options pop-up for patterns and gradients 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] swimming in tabs
Martin wrote, it will not ship like this. I have problem with this attitude. Its not how open-source works. If its stable, you release it and then keep adding design and features in the next cycle. 2.8 has already taken too long. People who shoudn't be building Gimp from git are doing it. Heaping on does not match design goals exactly style roadblocks does more harm than helps. If it fills the basic requirements and is stable, its not a release roadblock. Id like to hear other developers opinions on this. I'm a big fan of open source, but I am also a big fan of interaction design and usability. For me it is not only software stability that is important, I want things to be pleasant to use as well. well I am happy with Martin's support, because without that there is no way to achieve results. what Alexia describes is not typical open source, it is how at the moment the whole (commercial) software world works: when the going gets tough, usability becomes a 'nice to have' what is counterproductive is that right at that point the management and development people stop working with the interaction design and usability people and start 'going it alone.' every time a developer stops working with an interaction designer on some project, a little bit this developer stops working with this interaction designer forever. this can only be repeated so many time (a cat has 7 lives) before this interaction designer stops working with this developer forever. so the solution is: when the going gets tough, you keep working with your interaction designer to achieve good usability I pride myself on being an interaction architect who design software with good usability and who works with engineers on getting it built in a practical way. I would prefer to do both of these (including the final call on what is usable) up to the last minute before releasing. --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] swimming in tabs
Liam wrote: The single window mode has tabs, with a tab for each open image. well, temporarily. there are no tabs in the design. it will not ship like this. but it is good to find out that the trivial just put some tabs like firefox solution shows its weaknesses. --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] GSoc - Brush Selector Widget
Zhenfeng Zhao wrote: I received a comment on my Gimp Gsoc proposal from Martin a couple hours ago. To answer Martin’s question, and think about what UI adjustments are needed for Brush Selector Widget, it may help to discuss here, to see whether my understanding is correct. After having some feedback, I can make some scratches on paper for the new UI, and also can use Gimp or Inkscape to design the UI mock-up. One of the goals of the project on UI is to allow more precise brush selection. For example, users can easily input and see effects with size, angle, and aspect ratio values. i think (and I have thought and discussed about it quite a bit with usual suspects like alexia and pippin) that trying out is best done with the full parameters of _this_moment_, on the canvas or a copy of the canvas. after I attended a sprint with krita, they have implemented a variant of that. you can see blogs about that. Currently, these cannot be done easily. Brushes are rather complex in Gimp. 1. In Brush Selection, basically there is a list of brushes to select. There is only parameter to adjust for the selection underneath is Spacing. and that one will be transferred to the tool options 2. To customize a brush, there are many parameters to choose in Tool Options for brushes. 3. Users can also right click on brushes to duplicate and modify it, or create a new brush, with input of size, angle, and aspect ratio. for a vector brush, yes. pixmap: I believe not. Therefore, there are these many places to choose a brush: Brush Selector, Tool Options, and Brush Editor. In this project, size, angle, and aspect ratio are important parameters for brush selection. after reading that a couple of times, I think you are talking about making a vector brush from scratch for temporary use. In the UI, my idea is to have widgets of size (radius), angle, and aspect ratio in Brush Selection Widget, maybe under where Spacing is. Then, users can have a brush that has these precise input parameters, without needing to create a new brush copy and adjust them there. This should be a small task, so that some frequently used widgets would be in a more accessible place. I think we want to have the 'from scratch' mode mutual exclusive with the 'from collection' mode. this separates nicely the 2 modes users are. this must be done by switching the mode at the top of the brush selection dialog (a copy of which also pops up in the tool options). of course a 'from scratch' brush can be saved into the collection. then it has become clear that the 'from scratch' mode is equal to the brush editor (which can definitely use improvements). ah, and when you implement a pattern like that, you will be required (I bet) to make the changes in such a way that they get applied to all resources (patterns, gradients, etc). --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] [GSoC] Mentor Request from GNOME Outreach Program for Women
Michael Schumacher wrote: we've been approached on the #gimp channel by Marina Zhurakhinskaya from the GNOME Outreach Program for Women. She has helped GSoC applicants with their applications and is currently looking for a mentor for the following project: Full version (minus personal data of the student, of course): http://www.fpaste.org/qLNt/raw/ so I read the whole thing. OK, it is a gnome project, not a GIMP project, and that is good because I am 80% sure that this kind of functionality is not desirable in GIMP. This kind of mechanism is part of the nuts and bolts of _database_ type photo management apps like iPhoto, and it works there, because users (in general) do not access the file tree of the repository. So getting an image on another drive or system literally means dragging the image out of the app, not from a directory to somewhere else. This makes it an explicit export out of the app and makes it plausible why those images cannot be reverted to original. I see this not working for GIMP because it is file system based, it does not mesh well with the GEGL lossless editing metaphor, and because moving GIMP files between systems/users where it gets worked on further (with full modification history) is simply a requirement for us. what Kamila and I presented years ago in Montreal was that what we need is a _simple_ versioning mechanism inside GIMP files, built on top of GEGL. that covers (for GIMP) the user needs that this proposal tries to address. --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] GSOC - Free Transform Tool
Stephen McKeague wrote: what needs sorting out is that after some manipulation the transformation frame can be any kind of shape that can be made out of 4 corners connected by 4 straight lines, including a twisted bow tie type of shape. this general shape is then clipped by the viewport of the image window, which is really a rectangle. This clipped general shape then needs to be manipulated. I still have to investigate what is reasonable for users to be able to do in these situations and how I can make this happen. Yeah, after a perspective change of close to 90deg in any one direction - even if this was actually a mistake - the frame will be rendered unusable because of the low resolution between the different handles. Given that currently you will not be able to undo just part of the overall Free Transform, good point, undo in steps during the use of the tool is on the menu. this may be aggregated for undo too after the tool is left. this will pose a problem (Large shears will exhibit the same behaviour). One possible solution would be that transform frame would only mirror the actual transformation up to a certain threshold. Otherwise the decision could be left to the user to accept (or undo) the current transformation and start a new free transform (and thus new transformation frame). Any update on your thoughts on this? well, this needs UI spec work, for these (valid) edge cases, but that needs to have context of users (when the intent is there) working at a magnification that is workable. but this is hard thinking work and TBD. --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] wiki down...
Alexia wrote: On Mon, Mar 29, 2010 at 9:09 AM, Liam R E Quin l...@holoweb.net wrote: On Mon, 2010-03-29 at 00:11 +0200, Sven Neumann wrote: So far no-one has approached me asking for the tarball that I prepared. Is there really no-one out there who's willing and capable to host this simple Wiki setup? Like you :-) I'm too busy right now, although I can provide server space. I'm not willing to host a wiki unless there are active anti- spam measures in place (same as for blogs) but otherwise it's fine. I think that wiki was not open for registration and nobody but Peter could edit it. close. There are (I think) 4 accounts up to now, 3 for UI team members and an administrator (Sven up to now). a new account is added (by admin) only when the admin and I agree. but maybe Liam had more sneaky modes of spam in mind. --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] GSOC - Free Transform Tool
Stephen McKeague wrote: this of course triggers a big update of the spec. there are also some rough edges in the spec that need to be defined: like when the frame is partially in view, or no edge of the frame is in view. On this note, could you please clarify for me where it says, Only the visible part of the transform frame goes into the size calculations. with the size calculations I meant the calculation of all the handles for manipulating the frame are done according to how big the transformation frame is on-screen. what needs sorting out is that after some manipulation the transformation frame can be any kind of shape that can be made out of 4 corners connected by 4 straight lines, including a twisted bow tie type of shape. this general shape is then clipped by the viewport of the image window, which is really a rectangle. This clipped general shape then needs to be manipulated. I still have to investigate what is reasonable for users to be able to do in these situations and how I can make this happen. Also, can you please confirm why the transformation tool would only perform the calculation when the user goes and does something else. yeah that passage is not clear. what I mean is that what is manipulated on-screen is just a preview of the real image data: it is just a limited amount of pixels (there are only 1 to 2 Mpix on a monitor) and it will, using all the dirty tricks in the world, 'instantly' reflect the transformation made by users using the handles. even while moving the handles. the real transformation of the real pixels in memory is then done with the aggregate transformation in one pass when users go and do something else. this is the maximum fidelity contract with users. --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] wiki down...
Sven wrote: As pointed out, spam shouldn't be a problem since the Wiki has a closed (and small) group of users and is not publicly editable. I'd prefer to have the Wiki hosted by someone who has been sticking around the GIMP project for a while. Someone who we all know as thrust-worthy. Please pick one of the volunteers and let me know who should receive the URL of the backup. I would be happy if Liam could host it. he seems to have the most direct control over his server. I do find it important that the DNS is also updated then. there is loads of linkage to gui.gimp.org and deep into the wiki: http://www.google.com/search?q=%22gui.gimp.org%22 --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] GSOC - Free Transform Tool
Stephen McKeague wrote: My name is Stephen McKeague and I am very interested in implementing the Free Transform Tool in GIMP for this years Google Summer of Code, originally proposed by Martin Nordholts. The project information page seems to still be offline, so I would like to discuss the bounds of the project. yes, it would give you quite a complete overview of how I see that tool working, I hope the site can be up soon. meanwhile, try this google cache: http://209.85.135.132/search?q=cache:5vLW1Vm8rQIJ:gui.gimp.org/index.php/Transformation_tool_specification however, last week I have updated the design of the shear and perspective transform handles and all opcities: http://mmiworks.net/test/no%20parallel.png and http://mmiworks.net/test/no%20parallel.jpg this of course triggers a big update of the spec. there are also some rough edges in the spec that need to be defined: like when the frame is partially in view, or no edge of the frame is in view. btw: getting the opacity part working may need some serious grunt work. ask the developers about it. Since the functionality is obviously in place for rotate, scale sheer and perspective separately, they could be combined in a Photoshop like fashion for the Free Transform Tool, presumably using shortcut keys to specify the details of the required transform. The new transform tool is indeed a combined transform tool: move, rotate, scale, shear, perspective. Since the GUI would have to be amended to include the new tool, would it be a good idea to have the icons for both a Free Transform and the existing separate transforms beside each other? This would possibly result in too much feature duplication but I would like to hear your thoughts on the matter along with anything else relating to the project. see my intro in the spec. but the short version is: the combined tool is to supersede the move, scale and shear tools and should be complemented by expert rotate and perspective tools. the flip tool is a goner. --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] [GSoC] About the idea: Basic gegl based paint tool
Jenny wrote: GEGL shipped an GUI application for test, with which user takes many OPs on the default image. But this application can not load images. I want to write a user-friendly GUI for GEGL as my GSoC project. I think this application should provide many drag-able blocks, where each block assigns an operation. User drags blocks and connects them to process image. Kinda like the simulink (http://en.wikipedia.org/wiki/Simulink ). Expecting feedback. the graph/boxes and hoses/visual programming metaphor will one day be in GIMP, because we have 'researching cutting edge image algorithms' in the vision. but it is certainly not how I see anybody creative or production working. that is much more hands-on, a continuation of the way you see right now in GIMP: hand-tools, a free combination of selections + filters/operations + layer techniques. the graph thing can be added _after_ all of these normal things have been adapted to GEGL. --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] Doubt in Google Summer Of Code Idea
Sven Neumann wrote: On Tue, 2010-03-23 at 21:30 +0100, Martin Nordholts wrote: The GIMP menu structure is a beast. But each item is well documented, in particular there are tooltips for most of them. The idea is to make the menu item labels and the descriptions of them searchable. It could be a text entry in the menu bar for example. It could be a text entry that replaces the menu-bar triggered by a keyboard shortcut, similar to how you can switch from the path-bar to a location entry in the file-chooser. Or it could be a UI that overlays itself on the image. The current work on the text tool UI shows what's possible in this respect with newer versions of GTK+. Would be nice to get some input from Peter on this subject. With a little help from the guiguru, this could turn out to become a very useful change to the GIMP UI. well, I have still mixed feelings about the whole plan. if there is a need for search in a menu structure, then how well is that menu structured? it really sounds to me like signalling UI design defeat, and sticking a band-aid (search) on it. however, going much further makes it useful. searching tooltips is one thing, digging into the manual is next. going further is needed before thinking about 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
Re: [Gimp-developer] wiki down...
Sven Neumann wrote: On Mon, 2010-03-22 at 23:11 +0300, Alexandre Prokoudine wrote: On 3/22/10, Sven Neumann wrote: Yes, it's down for a while already. I can't host this service any longer and already offered a backup on IRC for anyone who wants to take over. So far no one approached me asking for the data. I have over a gig of free space on my virtual server. What versions of PHP/MySQL are required? The current setup uses PostgreSQL 8.1.8 and MediaWiki 1.9.3. The PHP version on this server was recently upgraded from 5.2.11 to 5.3.1. Since this update the gui.gimp.org wiki is down, because the MediaWiki installation appears to be incompatible with this newer version of PHP. so that is what happened... If you are still interested in taking over, and if Peter agrees, I can make the database dump and a backup of the mediawiki installation with all uploaded images etc. available. yes, I do agree to getting gui.gimp.org (as-is, and under that address) running again a.s.a.p. --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] wiki down...
ehm guys, gui.gimp.org is down, or rather, serving up perfectly empty pages. --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] Toolbox UI/Docking
Jerry Baker wrote: For discussion... https://bugzilla.gnome.org/show_bug.cgi?id=610344 Add docking capabilities to the toolbox so it would be possible to dock another dialog to the top, bottom, left or right of the toolbox or dock the toolbox on the top, bottom, left, or right of another dialog window. (In multi-window mode and single-window mode) From an irc discussion: (08:44:36 AM) jbaker: speaking of ui, is it possible to move the toolbox to the right of the image in sw mode ? (08:48:33 AM) guiguru: jbaker: should be (08:48:55 AM) guiguru: it is free tear off and docking in swm (08:50:14 AM) jbaker: guiguru: i think the toolbox is a different widget than the other dialogs, as far as I can tell there is really no place to grab it... (08:50:43 AM) guiguru: it is different, but that needs to be fixed then (08:51:23 AM) Death: Grabbing wilber would make sense for me... there is a bit of confusion going on here about the toolbox. you can talk about the toolbox itself, and it is not a dockable right now (and as Martin said, quite a bit of work to make it). then there is the toolbox as a column with the toolbox always at the top and maybe some other dockables (like tool options) also docked in that column. right now that column sits in multi-window mode in its own floating palette type window. in single-window mode, that column should be able be docked to the left/right of the image or any other dockable column (the latter docked or in floating window). that is what I meant to say, --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] Hybrid window mode
Damien wrote: I'm so sad this proposal did not trigger any further discussion. I had not forgotten about it, but a serious reply is serious work. actually, a serious reply means solving the open issues around this theme, some of which you pointed out in your, ehm fiery, posting. --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] GIMP GIT: window hints and text move
Akkana, With GIMP 2.6 Metacity works fine. Seems a bit of a stretch to force people to change window managers with 2.7 just so it doesn't do this. Agreed. It works if you use Utility window as the hint for the toolbox and docks, but then they stay on top of the image window unless you hide them completely with Tab. stay on top is the intended behaviour. for toolbox, palettes and inspectors this is how it should work, in general. --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] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
Martin wrote: Right now GIMP has virtuall all of the UI imperatively constructed with code. This has a few problems: * Tweaking the UI requires re-building the app * A lot of code duplication * Not very modern The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct the UI. The purpose of this change is to introduce declarative construction of UIs in GIMP to give us experience in this area. The benefits of using Glade is: * Tweaking the UI doesn't requires re-bulding the app * Less code * Easier to start using a script language like JavaScript in the core * We make the GIMP code base more modern * UIs can be constructed through drag-and-drop with Glade well I see we have to be quick here to get a word in, as Martin has already gone ahead. as an ex-UI developer, planner of actual GUI frameworks and as a interaction architect I have a strained relationship with GUI builder applications. which of course are by themselves front-ends for declarative construction of UIs. discussing GUI builders fundamentally in recent years, I must observe that if GUI builders were offering the same flexibility as coding by hand, then using the GUI builder would be just as quick as coding by hand. speed vs. flexibility is a hard trade-off. rinse and repeat the paragraph above for declarative construction of UIs. now I can understand how a load of humdrum dialogs we have could be quickly build/maintained in the builder/declarative way. however, let it be really clear that I will _not_ entertain the following excuses in the future: your UI design cannot be build with the builder/declarative way. that layout can only be start-up/compile time static, because of the builder/declarative way. that custom widget cannot be used with the the builder/declarative way. theoretically we could write some code for that special interaction, but then we could not maintain it in the the builder/declarative way. yes that looks shit on platform xyz but we cannot do anything about it through the builder/declarative way. GIMP a high performance application that on the UI front should constantly push the envelope of what GTK has to offer. just for the record, --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] On bug 373060 - allow to easily switch to last used tool
Damien wrote: I started working on bug 373060 - allow to easily switch to last used tool and ran into design problems, so am I taking this here. I already have a strong idea on what the feature should be https://bugzilla.gnome.org/show_bug.cgi?id=373060 I think what needs to be filtered out of that bug is that users' need to have a small ad-hoc arsenal of tools + tools settings + resources (colors, brushes, etc.) to quickly switch between to complete their current task. the context swapping solution is both too simple with two (current/ previous) tools + tools settings slots, and too opaque in how it works UI-wise with only one shortcut to do two things: store and recall. so actually two shortcuts are needed to do things. and those are only shortcuts, where is the primary UI that it is a shortcut for? another plan, long-term per-tool presets, are not the answer to this too, because the ad-hoc nature of the users' needs is not covered by it. it is all to static and targeted at persisting user's favourite tool settings over time. looking at the nature of the small ad-hoc arsenal of tools + tools settings + resources requirement, I think that a brainstormed mix of something I proposed ages ago, 'blobs of paint' or file palette, see: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html under 4. better painting tools and something yahvuu has been brainstorming: http://gimp-brainstorm.blogspot.com/2009/05/palettes-smoking-carrots.html so a file specific working palette where any tool+settings (one thing), resource, plugin+parameters, color can be dragged in, dragged out and recalled to be the thing to use. this would form that small ad-hoc arsenal. --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] On bug 373060 - allow to easily switch to last used tool
Liam wrote: Another little usage scenario: For my part I've always wanted something like this with dodge/burn, because whenever I switch from dodge to burn on a grayscale engraving scan, I need to change the mode from highlights to shadows - the only combinations that really make much sense are dodge/highlights and burn/shadows, as otherwise you end up lightening the black stroke or leaving visible brush-strokes on the white background. I've never asked for it (Peter would say I was projecting my own really unusual workflow on other users :-) ) but the ability to save and switch between some combinations might be very useful. would you not be helped with 2 user presets for the dodge/burn tool, which you would choose alternating during using the tool? so per-tool presets would be the solution for your case (and, yes, millions of other cases where users _always_ use a couple of options setups alternatingly with a single tool) --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] new brainstorm...
David wrote: a brainstorm where anybody can contribute a tip-of-the-day for GIMP: http://gimp-totd.blogspot.com/ Just a quick note on something you might want to correct: Send your image to us, put the word ‘GIMP tip’ ^ image - tip hey thanks, corrected. and we have already a first contribution. I am curious to see how this takes off. --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] new brainstorm...
guys, I have pushed into service something that I brainstormed (no pun intended) ages ago with Roman Joost: a brainstorm where anybody can contribute a tip-of-the-day for GIMP: http://gimp-totd.blogspot.com/ I expect this to quickly give a lot of input that (with some manageable editing by the docs team) will grow our tips db by an order of magnitude (or two). when that point has been reached, we can talk again about the original plan to give tip-of-the-day a new home in the no-image-window. --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] Secure logging of GIMP actions
Alexandre Prokoudine wrote: On Tue, Dec 15, 2009 at 5:37 PM, meetthegimp.org wrote: I just had an interesting phone conversation with someone (sorry, I can't be more specific) who needs to log all actions that have been used to change an image. One should be able to reproduce all the steps that have been done. Is this possible to implement in GIMP? Of course. http://www.ingimp.org/ they have to skip a lot of user actions, interestingly for privacy reasons. --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] Making dockable tab style a global setting
Martin wrote: It is already possible to change the Tab Style for dockable dialog tabs. Right now however, this needs to be done on a per-tab level, using 'Tab Style' in the Tab menu for each dockable. It is cumbersome to manage the tab style on a per-tab level, so I suggest we make this a global setting. That is, changing the tab style for one tab changes the tab style for all tabs. We could also have it in Edit - Preferences - Interface, but I think it is better to have it close to where the action is. I do think it is better to do it where the action is, and because of that and some flexibility for users (it is their priorities and organisation), I would like to see that the setting is per row-of-tabs. because we have one setting thingy visible per row-of-tabs. so in your shots there would be a separate setting for the row layers+channels+paths+undo and for the row brushes+patterns+gradients. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Making dockable tab style a global setting
Martin wrote: peter wrote: Martin wrote: It is cumbersome to manage the tab style on a per-tab level, so I suggest we make this a global setting. That is, changing the tab style for one tab changes the tab style for all tabs. We could also have it in Edit - Preferences - Interface, but I think it is better to have it close to where the action is. I do think it is better to do it where the action is, and because of that and some flexibility for users (it is their priorities and organisation), I would like to see that the setting is per row-of-tabs. because we have one setting thingy visible per row-of-tabs. I don't understand who would want a UI where tabs doesn't have the same style, what a mess well, I am thinking about why docks get organised in rows of tabs, together, and why in different rows, paralleling. and then I _can_ see that it makes sense for some users to have (like in your shot) layers+channels+paths +undo in text for calmness and brushes+patterns+gradients in icon for briefness and the direct representation of the current selection. If you think it is a problem that the setting can be changed in many places, then I would rather put it in the Preferences. Making it a setting per row of tabs wouldn't be much of an improvement in my opinion. I would hate to see it buried in the preferences. --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] GIMP to be removed from Ubuntu Lucid Lynx?
Joao wrote: Yes, friend of mine was tehre, confirmed it too. (btw, it evenshowed up in slashdot). IMHO, stupidiest decision ever - they _want_ their users to be dumb and continue that way. well guys, GIMP has the vision to be a high-end/expert application, so we should not be amazed that a general OS distribution drops us off the finite-space disk. I see it as ubuntu giving us the respect we deserve. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
first, thanks for the help from those who replied (Liam: hilarious) Akira wrote: I usually click with a selection tool on any area outside the active selection. But this isn't always fast to do. For example another tool may be currently selected, or the selection method may be set to addition, subtraction or intersection. you hit the issue on the head. all of this is not very fast, except ctrl-shift-a, but that is a shortcut. also the tool changing feels awkward, and is simply likely if one has operated on the selected pixels. what I am missing is a direct way to end the selection state. brainstorm - like a close box [x] on the top-right of the marching ants - or (another shortcut actually) press esc (may be taken in some states) /brainstorm --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] ceci n'est pas une selection...
guys, would like to tap the wisdom of this crowd here. say I have made a selection in GIMP, done what needed to be done to the pixels in the selection and now want to get rid of the selection. the obvious way is Select-None. how many more ways are 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
[Gimp-developer] twisted GIMP fiction...
guys, cool story, sent by the user interface technology manager of symbian, who I am meeting next week for a workshop and a panel discussion. (symbian adopted the GIMP UI brainstorm method, btw). Begin forwarded message: You might find the following interesting. Augusten Burroughs is an acclaimed, twisted fiction author. http://www.nytimes.com/2009/10/22/garden/22burroughs.html On a recent afternoon, Mr. Burroughs, lanky and boyish despite the tattoos curling around his forearms, was stretched out on the king-size four-poster bed he has set smack in the middle of the apartment. Draped and swagged in a manner that would please the Libyan dictator, the bed is a sumptuous galleon and office for him. Little seating arrangements ring the tiny room, which he decorated this summer, downloading photos of art, furniture and objects found on 1stdibs, shrinking them to scale and laying them out on a floor plan using Gimp, a Photoshop-like program from Linux, the free operating system that Mr. Burroughs compared with Alcoholics Anonymous: “You can get help from total strangers anywhere in the world.” --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] Would single-window fix usability nightmares?
OK guys, the tone of this discussion is distracting from the real problems we have and a possible solution. and we do have problems that are in gtk (mainly on windows) and with a load of window managers that do not even implement the window hint that we are apparently the bleeding-edge users of for our docks. insight: I met with the openPrinting guys on tuesday and was telling them how this gtk+windows situation looked like a mini version of linux printing (_nobody_ can be bothered to work on print dialogs). the impression of one of the guys was that when it comes to gtk+windows, what you are talking about is GIMP and inkscape. these two seem to be the only clients (more than one way) that matter. what is not helping us is that outsiders expect this big application to have a big and active development team. to my surprise even the official commit stats come to that conclusion. meanwhile everyone who hangs around here knows that we have very limited resources. piecing all the contributions together I say we got about 3.7 full developers worth going on a at any given time. I am sure that the 1 million users who download GIMP for windows every month somehow expect that is was developed on windows. so the solution is not to ask the people who (and I am grateful for it) do their best to contribute now. the solution is to stop potential contributors having to find out by osmosis how they can help us. what we can do is be much more concrete on www.gimp.org and say on the home page: Help wanted. This is eerily close to job openings at companies, but that is what we have. and similar to companies we have to 'sell' our needs a bit. show that new developers can work on a coherent package of work where they can make an impact, pretty soon. I think for instance Martin and Alexia discovered that over the last years and they have carved out their niche(s) where they are having a large impact. GIMP is looking for an experienced windows XYZ developer who can really make a difference to our user experience on windows. I do not want this to be a high-maintenance thing like the SoC. The effort for the current contributors should be limited to: - coming up with a coherent package of work and requirements for the new contributor (has to know XYZ libs and ABC algos) - write the help wanted add (if you do one a month, it may become NEWS on all those GIMP tracking sites) - help the new contributor with the bug numbers and where to start in the source (oh, that is in gtk) - be really clear in what we want to achieve (I can help with that) - no further hand-holding another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone). --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
photocomix wrote: i knew that Peter Sikking (or somebody else from Gimp UI brainstorm staff)replied but the message get lost for technical problems (full storage disk) yes, I am (by default) the Gimp UI brainstorm staff, and I had about 3 threads going on here before the list collapsed. I am very interested to know the content of that reply,i hope you may send again now here we go: OK, I waited with replying because I wanted to think about this carefully. that is because quite a few issues are combining here. first two fundamental issues: 1) let's face it: this is a new feature request. it is not that we broke something in this 50 pictures a day (10 minutes each) workflow. actually, on balance things got a bit better for this with clear saving and exporting. 2) an even bigger picture: does GIMP has to solve this problem? since part of what you want is a no-brainer conversion from png to jpeg. sounds like a job for a batch tool. this way you would save your GIMP file, then ctrl-shift-E, return, return, and GIMP does remember if you wanted TIFF or png all the time. run the batch job at the end of the day. so why not add it anyway, doesn't hurt no? yes it does: - by associating 2 or more export files, Export to foo.png (ctrl-E) has to be redesigned and never be as good as now. - you have coupled saving to exporting of multiple files, hard. in general these things do not happen at the same time, saving work is a different thing then delivering. write times go up by a factor of 1+N, where N is the number of export formats. - so it is easy to set (well, you will have to 50 times a day) but how to stop it for a file? it was in the Save dialog, but to get there again? Save as? - UI also needs to be not-error-inducing and give a clear model to users to how things work. this proposal here is one of several to get a litle bit of export back into the Save dialog. each of these creates _a_ way to export, that users may figure out as _the_ way to export, because they are migrating from 2.6 to 2.8. No, it does not help that we have clear Export on the File menu. we simply cannot let these models of export develop. so that is why I am against 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
[Gimp-developer] test
mon 19, 16:09 --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] Icons for layer modes
yahvuu wrote: actually a question for peter (yahvuu): how complete is this overview? most notably, the porter-duff modes are not listed. I'll have a look to make the overview as complete as possible. I am interested in that. modes are like a box of chocolates, you'll never know what you gonna get. first, I know now why our Darken section is one Shorter that our Lighten one: we are missing subtractive (that needs a name not s close to our Subtract). yeah, in photoshop, the names are: 'subtractive' = 'linear burn' 'additive' = 'linear dodge' which is a lot better. It's still not perfect though, as the most prominent property of burn/dodge is the capability to increase the local contrast -- which is not featured by their 'linear' counterparts. But at least the confusion of 'subtractive' not actually using a subtraction term in the formula is avoided. well, we cannot rename addition (and it is a clear name at that), and linear burn is really not where I would like to go. After a look at the math (thanks for that) and a bit of brainstorming with nonsense names like addition against all odds or orchestral addition in the dark I arrived at something that does work: Dark addition (because it is an addition, shifted full range towards black). Actually, i think the old 'subtract' mode should be removed, when 'subtractive' gets added: just invert the blend layer and you get the old 'subtract' mode back. no no no. everything stays there and keeps its name. file and user backward compatibility is needed here. that sounds very 'developer', and I fight a lot of these battles on the other side, but in this case it is true. Along the same lines, what is the right to exist for 'divide'? - it's just 'dogde' with an inverted blend layer. it is a straightforward mathematical mode, maybe used to prepare a mask for further use. it is part of the difference group that provides all kinds of mind-bending (inverting) stuff. after moving grain merge out I am happy to leave that group as-is. An accepted pair of this type is grain extract/merge, for which useful techniques exist [1], but also for dodge/divide?!? If so, possibly the rest of the modes are candidates for 'mode bloat', too, say a new mode: 'multiply with inverted blend layer'... avoiding mode bloat is a good one. but please do not mix up the different reasons why modes are there right now. Like having a set of 'layer math' or simply results oriented (burn, lighten only). you see there are some very subtle reasons to add a new mode or not. I had some more fun with the heat maps in http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png and I think I start to understand the algorithm-aesthetics better. as you pointed out, the lighten and darken groups are exclusively red or blue, which means that something like freeze/reflect do not fit there. then our overlay group modes have equal areas of red and blue in it. this makes heat/glow a better candidate then the two rows above or the one below them. then again there is no artistic value in 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] Icons for layer modes
peter (yahvuu) wrote: Martin Nordholts wrote: [..] I have for a long time felt that layer modes is just a primitive and naive way to achieve some kind of non-destructiveness. yes, the evil plan which spun off my posting is to get rid of the layer mode concept. funny enough I had realised before your mail rolled in that that is impossible, for the following reason: the layer mode controls the mathematical operation used compositing of that layer. there is no _reasonable_ way (right now) to achieve the same results in a different way. here the fundamentals of what it does prove it to be unique. peter sikking wrote: maybe there are simply zero arguments to add modes... each new mode adds one finer step for adjustment of blending characteristics. If i want to darken a layer by itself, the curves tool allows nearly infinite different characteristics of darkening. If i want to darken a layer by another one, there are a total of 3(!) characteristics available: 'darken only', 'multiply' and 'burn'. Of course, there won't ever be enough layer modes, which is one reason why they have to die long- term... no, your analogy is wrong. layer mode sets the mathematical operation. - if you want control over the strength, that is what layer opacity is for - if you want fine control over the characteristics curve, use curves on the layer - if you want to mask where what is used, use the layer mask your thought of creating a 'tool' that could make this more hands-on is intriguing though. give it a shot. [..] but now I see that [..] applying an adjustment layer [..] [..] is completely valid, [..] i'd like to take the same line: if a layer is just a transparent sheet, and a composition is just a projection of a stack of sheets, then it's most natural to insert (photographic) filters in between. Say, a colorizing red glas or a freaky effect lens, in general: an adjustment layer. note that in the future a adjustment layer will be shown to be the natural choice when the same adjustment needs to be made on several (composited) layers. if it is one layer that needs an adjustment 'just doing it' on the layer itself will be the natural way. keep coming with the evil plans, there are helping us. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
so after writing in my last mail: layer mode sets the mathematical operation and seeing that the user requests for layer modes are not exactly streaming in, I was thinking during cooking: I should have a look at http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png again, and look for really different heat maps (you know yahvuu, they are good for that) and math formulas with discontinuities. actually a question for peter (yahvuu): how complete is this overview? (I think negation is looking for a mate, purely on symmetry grounds) lots of insights how current modes work, btw. so after an entertaining hour of map spotting, what have I learned? first, I know now why our Darken section is one Shorter that our Lighten one: we are missing subtractive (that needs a name not s close to our Subtract). then looking for interesting heat maps, with the overview much reduced (@18%) to find the really different modes. well, vividlight looks interesting and different. then there are quite a few modes that don't do much or not that different from what we have. freeze, heat, reflect glow seem to come as one package. but then glow seems to really 'do what it says on the tin' and may be a worthy addition just on its own. that's it really what I could fish out: subtractive, vividlight + glow --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
peter (yahvuu) wrote: peter sikking wrote: to have a reason to add these icons to GIMP, they really have to add something for usability, not just be different enough icons that happen to be similar in their group. what the icons have to deliver is additional _user_insight_ into the modes, in addition to the name of the mode. also this insight must _feel_ to be true, it must match users' experience. OK, i can't imagine that it's possible to visualize the subtle difference in _feeling_ between, say hardlight and grain merge. actually you are doing all right in the difference department, but I started seeing disinformation in the feel-true department. I think you can have a shot at trying to fix that. Surprisingly enough, the 'brightness diff' plots turned out to be so characteristic that i soon started to identify blend modes by their plots instead of by their names. But then, i've probably been looking at too many such diagrams lately :-) don't forget you have an engineering background and can do the math. I expect the majority of our core users to simply use this by feeling and build up a wealth of experience that that can retrieve by using the names of the modes. i guess that litmus test can be used in the opposite direction as well: if it is impossible to create suitable icons for layer modes, then they probably should not be presented as a drop-down list. no that is not true. what you run into is the very limited possibilities to express something (usable) in an icon of this size vs. the incredible richness that language has. I do admit that these mode labels have their legacy issues, nothing to be done about that. I wonder if the criteria are different for preset selection, e.g. for the curves tool. Here, any visual hint of distinction seems like an improvement over pure textual choices like 'curves 2009-08-01' or 'curves 2009-08-02'. Even if there's no correspondence with the 'feeling' of a certain curve. Or is this case within the same category as general icons? I have discussed ages ago with Mitch what is needed on the levels/ curves/etc. (remembered) presets. for the automatically created presets what is needed to help selecting is not only date + time, but also the the result: the thumbnail of the layer _after_ applying this levels/curves/etc. to it. this gives two orthogonal ways to identify an automatically created preset. for the presets that users saved + named, the richness of language is enough and no icon is needed. --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] Icons for layer modes
photocomix wrote: so I am sorry. no additions solely for digital-artists. I am afraid that you undervalue creativity of who use gimp for photo or image editing I explain better, even if the goal may be different (as photo- retouch differs from use gimp to paint) the tool used are often the same So as who use gimp for paint may also take advantage of filters and tools developed with the goal of photo editing...who use gimp to retouch or edit, (in other words the group that you focus as the main users )may well benefit of improvement of brush tool...because they use same tools In this case as example i will not exclude the utility of a mix brush for restore digital or scannered images you see, now we are talking. by taking the debate to how a certain addition can really improve the productivity or creativity of our core groups, how painting can be made better in general, there is much better chance of getting somebody to listen and to get it integrated, one day. --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] Would single-window fix usability nightmares?
Ilya Zakharevich wrote: However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses. the introduction of a single window mode is in no way related to that. When the windows are merged into one, STILL only one of subwindows has a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)? that is a serious bug. in what version(s) of GIMP does this happen? --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
Ilya Zakharevich wrote: To make a long story short: 3 stages is, of course, not enough - especially with applications which target SIMULTANEOUSLY professionals and first-time-Linux-users. I understand first-time-Linux-users as really newby linux desktop users, not beginner-GIMP-users (we have no priority to design for the latter). the help is there to help with GIMP functionality. not to help with the minimal differences of the linux desktop with mac and windows UI. so I am a bit stuck where the point is... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Akira wrote: [1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here: http://sourceforge.jp/projects/gimp-painter/releases/ I remember and checked: we discussed this in july 2008. even our brush mistress Alexia Death chipped in: GIMP is an image manipulation program (including wild brushwork over collages of found images) but not a paint-from-scratch app. so I am sorry. no additions solely for digital-artists. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Martin Nordholts wrote: On 10/01/2009 07:46 PM, peter sikking wrote: meanwhile, can the overlay thing be repaired file-backward- compatible? If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice but to fix it somehow. Probably by having a legacy compositing mode also when using GEGL. Making GIMP 2.6 XCF files not openable in GIMP 2.8 isn't an alternative. what I mean is that right now (2.6) when overlay is chosen, soft light is executed. I think we should have in 2.8 a working overlay mode (also for legacy compositing). I think the following plan can technically work and is usable: - overlay gets repaired and assigned new mode enumeration number - when any old gimp file is opened and an old overlay mode is encountered, soft light is substituted as the layer mode, also in the UI. this sub does not mark the gimp file as dirty (changed). this means old files display the same as before. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Alexia Death wrote: On Thu, Oct 1, 2009 at 3:17 AM, peter sikking pe...@mmiworks.net wrote: another thing I see here is filling the new tile immediately with the same thing as the parent one. Auto filling fits with blender UI concept but not with gimp-s. Its important to remember that in blender you can only have ONE project file open at any given time and all these tiles display different aspects of that same project. Not so in gimp. that is what I suspected about blender. and right: not so in gimp. then there is a the arbitrary splitting. I have a funny feeling about that. How a bout using a modifier to span the split. you know, the quest here is really is speed-of-set-up. It has got to be so easy to knock these splits up from scratch that only a minority of users will have a urge to ask for saving these configurations (they will eventually, and one day we will, eventually). so thanks to the challenge and discussion in Guillermo’s email and this one I am also getting there on the flexibility front. I now have a system where in 4 (four) user actions a 12-way split (3 rows, 4 columns) can be set up with the size of the main image and of the 11 other ones set ‘just right.’ and then there is the flexibility that when each of these 12 tiles/images is the current image, there can be a different sizing of the main image and the 11 other ones. and I am working on keeping the clutter further down. and how does blender define the current canvas one is working on? Actually, the current one is the one that has your mouse cursor and that's the only bit of info you need. ah, right, cursor. I already realised that when someone wrote here or in a comment on my blog ‘to do it like xyz code editor’ that these apps have a cursor. which defines the focus. we do not have always a cursor. or we have multiple (highlighted paths). or it is in the other image (cloning). again: not so in gimp. --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] Icons for layer modes
peter (yahvuu) wrote: first: let me say that there is some real innovative stuff in this post, it is surely intriguing me. here's an idea how icons for layer modes could look like: http://yahvuu.files.wordpress.com/2009/10/layermode-sshot-proposed.png The icons provide a color-coded overview of how blending affect brightness: - blue: reduced brightness - green: neutral, brightness unchanged - red: increased brightness Technically, these are diagrams where the x-axis is the bottom layer brightness and the y-axis denotes the top layer brightness. The brightness difference caused by the blending operation is then color-coded as described above. The full explanation is available at: http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#brightness_diff I oscillate here all the time between great and fail. I could go into smaller stuff like the use of (SGA!) color (UI theme colors must be taken into account) but there is a much bigger interaction-design-fish to fry: to have a reason to add these icons to GIMP, they really have to add something for usability, not just be different enough icons that happen to be similar in their group. what the icons have to deliver is additional _user_insight_ into the modes, in addition to the name of the mode. also this insight must _feel_ to be true, it must match users' experience. this is the ultimate arbiter and this plan needs work before it makes a chance of getting there. I actually doubt that icons can be made that pass the criteria above and not involve user-thinking of OK, a vertical ramp was overlaid with a horizontal one and... the current model for the use of modes is that users gather experience through trying modes and evaluating results. the regrouping we done after 2.6 is helping out in that regard, having alternatives in the same group. in that light this is also an interesting contribution: the reason for re-grouping is explained here: http://yahvuu.files.wordpress.com/2009/10/layermode-grouping.png one of the first things it shows is what is working in Martin Nordholts reordering (marked 2.7.1 in the pic above): that we have sections in the menu that are described by their first item: lighten(-only), darken(-only), overlay, difference. what the new proposal points out is: a) grain merge is in the wrong group, should be in overlay b) normal mode is should be in overlay group, is strongest of all c) dissolve is, ehm, special (btw: the icon of dissolve shown here really works according to the benchmark of insight _and_ feels correct) I say: a) yes I see the point, let fix that b) I am not sure and would like to know how users feel about this. I really do not like that suddenly everything is ordered strong-to-soft, the other groups are is soft-to-strong c) we are stuck with it (are we?) and it depends on b) if it need to be moved around. btw, here: http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png there is a grab bag of modes never seen in GIMP. do we want to (artistic need, not compatibility) and can (effort) add some of them? wait! am I proposing bloat? ^} --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] Icons for layer modes
Martin Nordholts wrote: http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png there is a grab bag of modes never seen in GIMP. do we want to (artistic need, not compatibility) and can (effort) add some of them? Effort-wise it is not a problem to add more layer modes, but I have for a long time felt that layer modes is just a primitive and naive way to achieve some kind of non-destructiveness. that is a good bit of reality-check. are we just just catching up with somebody else's legacy issues? well, I used to think that adjustment layers was just a primitive and naive way to achieve some kind of non-destructiveness. so '90s. ^} but now I see that - doing a (non-destructive) operation on a layer with a selection - paint (non-destructive) with a certain mode/tool/plugin (later) on a layer - applying an adjustment layer (non-destructive) with a layer mask can achieve exactly the same results and each of them is completely valid, simply depending on what each user finds more logical in the spur of the moment. Assuming the introduction of GEGL will be severely crippled if done within the limits of GIMP 2.x backwards compatibility and that we decide to go for GIMP 3.x, wouldn't it be interesting to try to get rid of the layer mode concept as it is now and instead couple it more with the rest of the non-destructiveness GEGL will provide? Or are people too used to the concept of layer modes that it would be suicide to make them less prominent? I think applying layer modes to layers with either 'found image' material or users' own painting is a way of working that can be the most comfortable for a lot of cases and users. removing it seems rather impossible. as I said: only artistic need (not one-upmanship) should be a reason add one or more layer modes to our arsenal. maybe there are simply zero arguments to add modes... meanwhile, can the overlay thing be repaired file-backward-compatible? --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] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
Akira wrote: If I may, I'd also like to add that I find absolutely necessary to maximize vertical space / resolution. It has become very precious resource lately as monitors are starting to adopt very squashed aspect ratios (16:10 was the normality until a few years ago, but recently 16:9 screens have been introduced with virtually no increase of vertical resolution despite the noticeable increase of horizontal one). this was actually my topic and conclusion at my lgm talk a year and a half ago. that was never blogged, because of time constraints. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
Jon A. Cruz wrote: I think I might have one that can count as subtly different. Working on a prime image and drawing pieces, reference, etc from other images. Especially since I tend to think spatially, this is one I do a lot. I also tend to combine this workflow with others you have already listed. is this 'compare and reference' as fully covered by the polaroids? In some cases it might, but in many it does not. The lack of items such as the rulers, etc. tends to slow me down when I'm constructing something. My impression is that the polaroids are an improvement for inspired by work, such as I often see designers hash out. Using a reference in my thinking brings a little more of the technical/ accuracy aspect such as measurements with the ruler, etc. OK, understood (also Akira, btw, thanks for more feedback) I am working on split panes right now, for both single-and multi- windows, focussing on keeping the clutter (explosion of edges, handles, rulers, scrollbars, title bars with close/minimise/maximise buttons) down stay tuned, --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Guillermo, What do you think about the method for splitting/joining views in Blender 2.5? It's fast, it kinda covers the idea of the image parade and it allows to float a section as a new window. The only thing needed would be something to mark which is the active image and that would be enough for most of the described cases. I prepared a brief screencast showing how it works. http://dl.getdropbox.com/u/255376/Blender-UI.avi thanks for that, I watched it a dozen times, even in slow-motion. first I noticed this set-up has no rulers or scrollbars. we have and I am avoiding the replication of the all over the screen. you can see here sort of the same problem that that control bar below the canvas is repeated for each of them. that sort of hides that they have to repeat that clever divider/split handle for each pane (OK, we could only show it for the current active pane, but that is slower) another thing I see here is filling the new tile immediately with the same thing as the parent one. I thought I wanted to do that too, but then realised that in GIMP an empty tile would be automatically a drag-n-drop target to open an image, from the parade, file browser, etc. being empty does give a requirement where the new tile has to appear: for l-to-r locales it has to be on the right, so it would have to be 'pulled in' from the right. which would put that clever split handle in the corner where resize corners are found: bottom-right. ouch. float a tile as a new window: could be for multi-win (but how to not introduce visual clutter for this), not for single win. then there is a the arbitrary splitting. I have a funny feeling about that. has to do with how arbitrary the result is. and how, and how fast, do I build 9 (halfway) equally sized tiles to start filling with images? I know a fast way for that (View-Tile-9-square) but that is incompatible with arbitrary splitting. and how does blender define the current canvas one is working on? I would expect the load of inspectors on the right and bottom of the screen to track the current canvas. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
Jon A. Cruz wrote: I think I might have one that can count as subtly different. Working on a prime image and drawing pieces, reference, etc from other images. Especially since I tend to think spatially, this is one I do a lot. I also tend to combine this workflow with others you have already listed. is this 'compare and reference' as fully covered by the polaroids? --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] We should go for a single-window mode in 2.8
Cole wrote: I think the term single-window mode is potentially confusing. It's how you dock the windows together that gives the user the *perceived* single-window or multiple-window mode. well, if I have to formulate it, then single-window is users' preference for a flat working surface, where nothing overlaps. Multi-window is a staggered environment. one thing is bugging/intriguing me and that is the (single) point where single-and multi-window 'lines cross'. That is when one image is open and for single window toolbox and inspector column(s) have been torn off. Forgetting the parade for a moment, single-and multi-window look the same in that situation. It is tempting to think that from there users can 'just go in four directions,' by opening a tab, a new window, docking toolbox or inspector column(s). that is just 3 directions, because exactly docking on a multi-window environment is not a viable route afaics, docking global stuff to image instances. But I said forgetting the parade for a moment because that exactly points at the kind of UI optimisation that can be done if it is known whether a flat or staggered environment is the goal. I'll also be damned to double a number of menu items because the result could be a new window or a new tab. this now works automatic according to the single-window mode setting. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
saul goode wrote: Citing a passage regarding the image parade on Peter Sikking's blog post: What I find very intriguing is that the notion of which file is open starts to blur. It should be noted that many plug-ins and filters provide dialogs in which the user is prompted (via drop-down lists) to select images/layers/channels/paths from amongst those available in currently opened images. It would seem unwieldy for the code to have to open previously closed files to search for these potential images/layers/channels/paths every time such a dialog is presented (and the resulting drop-down lists could contain LOTS of entries in which the user holds no interest). Thus it may be necessary to retain the concept of opened images and provide a means of distinguishing unopened images in the image parade (if they are to be included). you are pointing out a serious spanner in the works. and if I do not find a way to houdini me out of that one, then that will be it for fuzzy... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal
third try, the list should be undead now: OK, comments have petered out here (yeah, dead list) and on the blog post. So it is time for me to summarise the users' needs I was able to filter out of them: 1) drag a layer to another image 2) side-by-side working for - cloning - color picking - repetitive copy and paste - synchronising working a set of images, keeping them artistically together as a set (a deep one, this one) - working on the same image, different layer composition, zoom and/ or position 3) 'seeing the same', synchronised zooming and panning of 2 or more images 4) work with numerous (15+) images at the same time and that is it. I will start thinking about how to address this 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] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
Daniel Hornung wrote: I'm not planning to dive deeply into this discussion, but I feel that Peter's blog deserves its own thread. OK, I am picking up the thread here. as I just commented on the blog post, I am going to address this need for windows-in-window and work-side-by-side structurally. this means first finding out the user requirements behind these requests. so for everybody who feels this: _why_ do you need windows-in-window or work-side-by-side? Jolie and Daniel already had their say and it is noted, but I want have the complete picture before adjusting the plan (or not). so let me know... --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 new
Gerald Friedland wrote: That's a great idea. The idea would be to have only on foreground selection tool and make it automatically determine whether to use Magic Wand or SIOX I have been saying this for a while: every time I look at the 4 'content' selection tools (wand, scissors, SIOX and by-color) I think: that should just be one tool with some options, or even a mixer to get the balance of results of different algo's. it seems that there is a ramp-up in sophistication in the wand - by-color - SIOX order. scissors seems to be and handle quite different. but after discussing its usefulness today, we can add those 'different' components to the mix. --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] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
Alexandre wrote: What exactly do you mean? OK, I'll try to be clearer: mouse up/not painting/just hovering over the canvas: show the real brush pixmap, with all the contrast we can muster vs. the canvas under it, 100% true opacity for each stamp pixel, reflecting brush, scale, aspect ratio, angle + hardness (?) parameters and dynamics, but not opacity, spacing, jitter, color(gradient) parameters and dynamics. mouse down/painting/stroking on the canvas: the applied 'paint' is the feedback. show nothing but a cross-hair (again in all the contrast we can muster) at the mouse position. this is really just there to keep users 'rooted', a confidence builder. --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] We should go for a single-window mode in 2.8
Liam R E Quin wrote: OK, I am listening. can you explain to me how this worked better in 2.6? First, note that I said right now -- although strictly speaking I should have said a month ago, I need to update. Sorry that I did not follow up on this sooner, but it may have been a good thing. now that you have updated your build, can you please state how much of the grievances are left? I suspect most of them are gone, when things are implemented to spec. --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] Bug #164774
Simon Budig wrote: David Gowers wrote: peter sikking wrote: can somebody tell me why we have a tiny replacement for the menu bar right below the menu bar? The obvious answer here is that it's visible when the menubar is not. Well, it has been introduced in the times where there was *no* menubar and tablet-users (with no RMB) needed a way to invoke the menu. so now on the one hand there is the impression that this is legacy UI (aka old cruft) but on the other hand I am reluctant just to drive a bulldozer over it. it would however be fully reasonable is only ruler type of stuff would be dependent on rulers being displayed. even creating guides has to be one day be decoupled (don't know how yet) from rulers being there, to create a chance of having a clean image window and be able to create guides. --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] Bug #164774
Michael J. Hammel wrote:
On Mon, 2009-09-14 at 20:43 +0200, peter sikking wrote:
it would however be fully reasonable is only ruler type of stuff
would
be dependent on rulers being displayed. even creating guides has to
be one day be decoupled (don't know how yet) from rulers being there,
Isn't this already possible with Image-Guides-{New Guide,New Guide
(by
Percent)}? What would this decoupling add to this?
being able to place a new guide with your mouse 'just there'
by feeling using your expert eye.
--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] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
Alexander Rabtchevich wrote: That would be fine if GIMP only supported mouse click painting, not dragging. When one moves mouse while painting seeing brush outline and borders of analyzed area for healing brush is useful. peter sikking wrote: mouse down/painting/stroking on the canvas: the applied 'paint' is the feedback. show nothing but a cross-hair (again in all the contrast we can muster) at the mouse position. this is really just there to keep users 'rooted', a confidence builder. I think you are right in pointing out that not all 'painting' actions (like heal or dodge and burn, or just subtle painting) give strong enough results that can 'speak for themselves.' trying that out myself with heal, dodge and burn and the round fuzzy brush, I found the outline also utterly useless at showing me what was going to change how strongly within that outline. nice pair of opposing requirements during painting: 1) give a clear and exact impression of the effective brush, including its fuzziness, no matter what's on the canvas 2) get out of the way of very subtle 'painting' results --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] Bug #164774
Michael J. Hammel wrote:
On Mon, 2009-09-14 at 22:21 +0200, peter sikking wrote:
Michael J. Hammel wrote:
Isn't this already possible with Image-Guides-{New Guide,New Guide
(by
Percent)}? What would this decoupling add to this?
being able to place a new guide with your mouse 'just there'
by feeling using your expert eye.
You can already do this with guides - just drag them from the rulers.
I was aiming for this without involving rulers...
--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] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
(peter) yahvuu wrote: what about printing a semi transparent copy of the actual brush on the canvas? exactly what I thought. Even though I think the patch made the brush outline better for fuzzy brushes, it is still not without flaws. Let's ignore the patch and aim for the above instead i guess what works best is to display the brush outline while drawing and to use the brush stamp when idling. If you want to test-drive the look and feel, here's a flash applet featuring various outline designs: http://sites.google.com/site/yahvuu/stuff/brushtester-web.lzx.swf8.swf?attredirects=0 I tried that, and although I would not call that exactly a solution, it did help to observe some things: - it is fantastic to see a fuzzy/grunge brush as a real copy of the actual brush when one is not painting, but it has to _contrast_ with what is under it or else it just disappears. When it contrasts (some X-OR variation, or so) I think it should not be semi transparent anymore, just exactly reflect the brush alpha value for each of its 'pixels'. - that really opens up what (dynamic) paint parameters should be reflected by the brush when not painting: looks like brush geometry (brush, scale, aspect ratio, angle) yes, hardness: maybe, rest (opacity, spacing, jitter, color(gradient)) no. - when painting, first I feel that this outline is a lousy representative for a brush. next I notice that getting the 'brush' out of the way and showing the immediate paint result rules. so now I am thinking: what about no outline at all and just a cross-hair for mouse position when the mouse is down? --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] Bug #164774
second try sending this... Liam wrote: On Thu, 2009-09-10 at 00:00 +0200, peter sikking wrote: [///] grab the top-left square where the 2 rulers cross and drag+drop it anywhere on the canvas. the place that currently gives a pop-up menu? damn. yes. can somebody tell me why we have a tiny replacement for the menu bar right below the menu bar? --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] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
second try sending this... (peter) yahvuu wrote: what about printing a semi transparent copy of the actual brush on the canvas? exactly what I thought. Even though I think the patch made the brush outline better for fuzzy brushes, it is still not without flaws. Let's ignore the patch and aim for the above instead i guess what works best is to display the brush outline while drawing and to use the brush stamp when idling. If you want to test-drive the look and feel, here's a flash applet featuring various outline designs: http://sites.google.com/site/yahvuu/stuff/brushtester-web.lzx.swf8.swf?attredirects=0 I tried that, and although I would not call that exactly a solution, it did help to observe some things: - it is fantastic to see a fuzzy/grunge brush as a real copy of the actual brush when one is not painting, but it has to _contrast_ with what is under it or else it just disappears. When it contrasts (some X-OR variation, or so) I think it should not be semi transparent anymore, just exactly reflect the brush alpha value for each of its 'pixels'. - that really opens up what (dynamic) paint parameters should be reflected by the brush when not painting: looks like brush geometry (brush, scale, aspect ratio, angle) yes, hardness: maybe, rest (opacity, spacing, jitter, color(gradient)) no. - when painting, first I feel that this outline is a lousy representative for a brush. next I notice that getting the 'brush' out of the way and showing the immediate paint result rules. so now I am thinking: what about no outline at all and just a cross-hair for mouse position when the mouse is down? --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] Bug #164774
On 5 Aug 2009, at 7:39, Martin Nordholts wrote: I am only a month late... On 08/04/2009 01:29 AM, Christopher Howard wrote: http://bugzilla.gnome.org/show_bug.cgi?id=164774 Hi - I was going to look into this enhancement. It was a request to make it possible for the user to change the zero-point of the image rulers. There hasn't been any further discussion, but we should have one. The first step would be to figure out a UI for the feature that helps fulfill the product vision [1]. one way that is in use in graphics apps and which I diagnose as being pretty good is: grab the top-left square where the 2 rulers cross and drag+drop it anywhere on the canvas. the dragging around needs to auto-scroll the canvas just as dragging guides does (it does, does it?). also while dragging the coordinates of the bottom left corner of square (hmmm, do our rulers go r-to-l for r-to-l locales?) that is dragged around c.v. the up-to-then origin needs to be displayed. it would not be bad to comply with 'snap to canvas edge' when set. somehow it feels wrong to me to snap to guides for this action. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Liam wrote: Right now gimp is broken for working on multiple projects (the file/save changes have rendered it too hard to keep track of where images are being exported) but the use case is central (I think) to how single window needs to work. OK, I am listening. can you explain to me how this worked better in 2.6? thanks, --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
Omari Stephens wrote: The phrase single-window mode really means absolutely nothing to me. Can someone draw a simple mock-up to make it clear? I will blog about it soon, so you know what I am up to. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
Guillermo Espertino wrote: what about printing a semi transparent copy of the actual brush on the canvas? exactly what I thought. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture smime.p7s Description: S/MIME cryptographic signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] vector layers blogged...
hey guys, I have blogged about the work a group of students did on vector layers for GIMP under my guidance: http://www.mmiworks.net/eng/publications/2009/07/teaching-interaction-09.html teaser quotes: In our design project, there was plainly not enough functionality to be useful/usable. So before the interaction designing started, each team sat down to brainstorm and then decide on their essential set of functionality. As we will see next, functionality like vector layer management, managing and combining shapes and working with simple shapes (rectangle, ellipse, etc.) was integrated. enjoy, --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] keybindings
Liam wrote: First, a BIG thank you to Peter and others: the new menu item overwrite is much clearer. I do still have a problem in several gnomish scenarios, but things are indeed getting better. If I use the file manager and drag a file to gimp, or if I use the image thumbnail browser (e.g. gthumb, but others do this too) and say, open in gimp, then gimp now imports my original jpeg file (say). And a keystroke that I use literally hundreds of times in any one day, will silently, without any warning, overwrite that file -- control-E and control-shift-E (fit window to image, fit window to image, respectively). without warning? spec says that lossy format export will always show one combined export options dialog: http://gui.gimp.org/index.php/Save_%2B_export_specification#export_option So how about (1) no default keybinding for overwrite precious file at all. this is the best solution. When the menu item is Overwrite foo.jpg there is no shortcut key (by default, users can change this) and the process of invoking it becomes deliberate and visible, via the File menu. The other use of the menu item, Export to foo.jpg will keep the ctrl-E shortcut. and the double binding of ctrl(-shift)-R, that was a mistake and will be corrected. thanks for pointing out the concept bugs, --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] The Export spec should be augmented to handle an important usecase
Omari Stephens wrote: UI powers that be: any ideas/status on this? having thought about it quite a bit, here are some jots: as Omari pointed out himself, it is a tug of war of different use cases and it depends on what just happens to be worked on, what the right default is for any given user. what is right may change a couple of times per hour of use. any solution can only be in the Export file-dialog, I agree on that with Tobias and other people who discussed this on irc. I would like to have had some widgets in the file dialog that not only navigated to alternative destination folders (of imported file when there is one at all, of saved xcf if there is one at all, does not need to be the case, right?) but also set that as the 'default destination policy override'. but it is impossible/the hack of the month to put widgets in a gtk file dialog I was told. and I do not think it is worth it, the hack of the month. so the next best thing is for GIMP to populate the Places column (also used in the 'Save in folder' pop-up), with: dir of of the imported file that started this file (when there is one); dir of last saved xcf of this file (when there is one) last 5 dirs exported to (hell why not) now I would like to know how these (dynamically) added Places turn out in the dialog. then we can talk about 5 last dirs for Save... --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] Scrollwheel actions by default?
Jeremy wrote, Just a small thing. I noticed that by default, scrolling up and down with the mouse scrollwheel isn't configured to do anything at all. Especially as it wouldn't even be replacing something else, I propose that the scroll-up and scroll-down actions be configured, by default, to zoom in and zoom out. I just did this manually and it works great. I don't think scrolling vertically and horizontally with the scroll wheel is as intuitive, and you can do this anyway by holding down the middle button and moving the mouse. ho ho, not so fast. the primary function of a scroll wheel is to scroll. do not forget that 2-dimensional scrolling thingies, like trackballs (as also seen on mice) are part of the same family and principle. if people like you find it smashing to zoom with the scroll-wheel, then we should make that an easy preference, but not by default. --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 composition rendering
(peter) yahvuu wrote: hi all, here's a (totally unbiased ;-) summary from the previous composition rendering thread, intended as a discussion base: I must say that I have been watching this discussion with increasing amazement. if you just start with some unbreakable UI principles like: when users save their file everything is stored on the disk; when exporting a png, it is there at the end of the progress feedback; when an operation is made on a composition then it is done and users can see the result to take their next creative decision; when a file is huge then users' expectation of how long things take naturally scale accordingly. then that is what users know and need to know and that is how it works as far they are concerned. the rest is technical detail and for actually contributing developers to figure out. I have been pointing out ages ago that the screens users work on have only 1 or 2 or 3 million physical pixels and that is all that needs calculating asap, the rest can catch up in seconds. has an impact on how effortless zooming is, however... --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
