Re: [Gimp-developer] New adjustment widgets
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? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why artificially constrain toolbox window size?
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote: The GtkToolPalette widget that hosts the buttons is able to nicely distribute available space among the buttons, so I would like to remove the resize constraint and make the toolbox dock window freely resizeable. The attached patch does that. Do the buttons still flow/wrap then, or does this lead to a fixed n rows and m columns? Are there any important use cases or interaction design aspects I'm not thinking about here? I assume the icons force a minimum button size? There *might* be some advantage to fix sized buttons regarding a training effect. At some point the icons will looks strange, surrounded by too much empty space, but that's not really an issue as the user can keep it out of the silly range easily. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] some current 2.7 issues
On Sat, 2009-12-05 at 17:34 -0500, Liam R E Quin wrote: (3) in most programs, save mirrors open, and export mirrors import - if GIMP is erally an XCF editor, open should work for .xcf and .xcf.gz files, and File-import should be there for the rare 99% case when you want e.g. to touch up a photo, and open a non-xcf file. So, please add file-import, with import as the label on the dialogue box. (I think?) AFAIK the rule in other apps is to have all formats you also can save to in Open, while Import is either for formats you can not save to, an/or to import something that will become just one part of your document (linked or embedded). -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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?
On Thu, 2009-11-19 at 21:38 +0300, Alexandre Prokoudine wrote: http://www.omgubuntu.co.uk/2009/11/gimp-to-be-removed-lucid.html Did you see any links that prove this? Well, I didn't :) Neither most relevant ubuntu mailing lists provide any background. I have been in that session and can confirm it. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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...
On Sun, 2009-11-01 at 18:49 +0100, Sven Neumann wrote: I wonder why you need both hands on the tablet. The pros that I have seen working with GIMP always had one hand on the keyboard and the other hand holding the tablet pen. That's what I do, too. Wouldn't with a tablet-PC, though ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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
On Sun, 2009-09-20 at 23:49 -0400, Tom Rathborne wrote: (I also use focus-follows mouse and no-autoraise :) ) Interesting to see the focus-follows-mouse and no-autoraise combination mentioned several times. In contrast, I use focus-follows-mouse with autoraise (with 0 delay). It allows me to have a large image window that partly covers 2 palette windows on the sides. Quick access to tools and settings and large image view at the same time :) Now from my understanding, the reason peter doesn't want single-window with tabs combined with split views is simply that it would make it unclear, which image the palettes and menu refer to. No matter how you would try to deal with that, you always get a huge pile of additional complexity. Tempting to say: Allow split views via shift/ctrl-selecting tabs, have all commands either affect both, or for those where that doesn't make sense, disable them. Or duplicate the menu per split view. Also have the split appear in the layers, channels and paths palettes. Just thinking aloud :) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
On Fri, 2008-03-07 at 20:48 -0500, Rick Yorgason wrote: Has anybody come to a consensus about whether or not the no-image dialog should persist after an image is opened? This idea is new to me. The whole point is to represent GIMP if there's no image, right? So it's not even a dialog, but the main app window. Even for expert users, it might be useful to keep the no-image dialog open as a drop-target for opening more images, but I can also see how it would annoy some users. I can see how it would annoy pretty much all users. It would very likely end up hidden below the image window ... -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
On Mon, 2008-02-04 at 09:01 +0100, Sven Neumann wrote: I also very much wonder why the window should have something as useless as a slider to control the visual appearance but lack any useful widgets to give people quick access to the things they will most likely do next. What's wrong about a link to the recently used images and to the New image dialog? Same here. I think such a slider would be a waste of both developer and user time (a _million_ users wondering: ooh, what does this slider do? ... to never touch it again ;) Reasons against having Recent/New in the window: - visual noise - both are in the file menu already and duplication would lessen consistency in interaction / work against habituation. But then I would prefer a window as narrow as possible, not much more than just a title and a menu bar. Any image would get old soon and putting effort into exchanging it frequently would be wasted. Reasons for having Recent/New in the window: - fast access to the only 2 things a user might want to do (well, there's also accessing preferences) - avoiding a mostly empty window which will trigger uncountable complaints through all eternity ;) The audio application Ardour has a startup dialog with New and Open Recent tabs. The dialog has its issues, but feels very useful. I never use a file manager to open a project there. For GIMP, it should be possible to have New and Recent side by side. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote: the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction. You seem to assume that - users will adjust the slider repeatedly - this adjustment somehow reflects their mood (not just lighting conditions from day to night or whatever) I mean to recall that the product vision stresses serious, professional level work. I don't see how playing with such a slider is compatible with a getting-stuff-done mentality. I very strongly doubt that users would adjust it repeatedly, anyway. Then, even if they do: what does it tell us about their mood and what would we do with that information? the thing to focus here is that GIMP is not going to behave like some kid yelling (yep, that is what a dialog is): that was fun, what are we going to do now... I mean now... really now! as long as we understand that, you will be able to understand the crucial decisions that I take here. I fail to see how a full size window that is basically empty regarding its informational and interaction aspects could be a good thing. It manages to cover part of the desktop or other windows and distracts from the then only useful bit, the menu. Seen this way, your wallpaper window would yell, too, but it'd be: BLAH! The opposite side of what are we going to do now would be see how you get along, I will not raise a finger to help you. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] crop isn't stopped at image borders
On Tue, Jun 19, 2007 at 01:38:06PM +0300, Alexander Rabtchevich wrote: In GIMP 2.3.18 crop tool isn't stopped at image borders as it was in 2.3.14. It is a bug: if ratio is set it is violated by this. And even if no ratio is set crop should not affect pixels outside the image. Do you mean the ratio is not correctly applied if the cropping rectangle leaves the image borders, and only then? I disagree on the last sentence. While limiting crop to within the image borders is convenient in many cases, being able to freely change the canvas size for a layer or image is useful, too. I mean to recall it's in fact an option in the last stable release. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote: Turning Gimp into a MDI application will make several users happy, but IMO it won't benefit Gimp at all. I think it would be better to improve the way those floating windows work: - by creating only one item in the windows list, grouping GIMP's windows, instead of one item for each panel (it's quite confusing) - by making toolbox and dockers dependant of the canvas window. As it was discussed before, this brings a new problem: where should the menu bar be placed. Of course, the document window is the most ovbious choice, but as we use floating windows, it won't be any document window when we open the program. Maybe the best option is to create a new kind of splashscreen, where we get as options: -Create a new image (if you choose this, the new image dialog appears, with dimensions, templates, color mode, etc.) -Open existing image/s (if you choose this, the filer appears, letting you pick an image or a group of images). Once you made your choice, the toolbox and dockers will appear along the document/s window/s. (I'm thinking about something like the latest Adobe Premiere Pro initial screen, for instance, but in the GTK/floating windows fashion) As far as I got it, this is all in line with what Peter has been proposing. Where MDI would be an _option_ that could be tackled _after_ floating panels have been adressed. Another thing that was covered in your work is the use of the screen space. I agree that the current menu layout is a waste of pixels. But this is already possible to improve in Gimp using the small theme and putting the tool options panel in the docker window. This allows you to shrink the toolbox, gaining much window space. You can see a screenshot of my current tool layout in gimp using that idea here: http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg Fine if that works for you and nice to see docking put to work for a custom layout. But I shudder on the thought of having to move the pointer from one side of the screen to the other, for tweakink tool options after picking a tool. (Personaly, I learned the shortcuts for all frequently used tools, but I still use the tool palette at times) -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
On Fri, May 25, 2007 at 02:15:32AM +0200, peter sikking wrote: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html On 4. better painting tools: So you propose to have brush models in tools like dodge/burn. Why would this be preferable to having modes like dodge/burn inside brush tools? Maybe brush model and mode should be handled separately? A: The region/scope to work on - whole image - a layer/group/set - a selection - brush strokes as they happen B: Options for above - mainly brush model with parameters comes to mind C: The action or drawing mode to apply - transformations - filters - paint On power modes Sounds like a rather vague distinction, makes me wonder if is such a good idea to split the modes based on it. Shouldn't layer and paint modes be kept the same? dipping and smearing Considering GIMP is not and shall not be painter ... but this would be very nice especially for drawing from scratch ;) On versions and approaches I have been using layers for versioning, backup, too. It just works. Of course real, branched versioning would rock. How much I would like to see it everywhere. Maybe there's a chance of pushing part of the functionality out, so it can become part the environment and have a wider developer pool? Regarding adjustment layers and GEGL GEGL is graph based, somewhat comparable to the nodes in Blender, right? If so, the concept of a layer stack does not match GEGL. I would propose to go all nodes and have no layers, if the layer stack wouldn't match the common case so nicely. On window management I have been thinking: What if GIMP was represented by a window with just the main menu. Image windows could be dockable palettes. Requires docking side-by-side. For SDI style, one would dock one image window and the inspectors all to the main window. Several images could docked together to have tabs. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...
On Fri, May 25, 2007 at 05:25:14PM +0200, [EMAIL PROTECTED] wrote: If everything ends up dockable and there is no longer the freedom to place windows where you _need_ then to be I think it should stay as it is. Maybe that was the fundemental reason for this rather unusual set up in the first place. I talked about dockable, not forcing things to be docked. The only necessary restriction of placement of floating palette windows would be palette headers right above docking areas (as that should trigger docking). I'm confident this could be arranged to be no issue in actual use. Actually, if you think about it, docking would happen when you move a palette close to the bottom or side of another palette, so the then docked pallette ends up pretty much where you move it to, but tightly arranged, most space efficient. Or if you moved it on top of another palette, you get a tab and can easily switch to what would be completely obscured otherwise. I know this sort of thing is possible in win32 API but I dont seem to be able to find any linux progs, gtk+ or qt derived, that have freely floating windows or panels. So what if GIMP became the first? -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...
On Tue, May 22, 2007 at 01:24:34AM +0200, peter sikking wrote: guys + gals, part two of three of our lgm presentation is online: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests.html 10. better printing support Paper, maybe better called media, could be handled as special kind of layer that is restricted to stay below all image layers (unless hiding stuff below it makes any sense). Allowing n media layers would make working on and comparing several alternatives easy, I think. If all media layers are hidden, zoom best-fit could work on the image, otherwise on the media. But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/pdfboxen.htm 7. save for web Should include indexing for GIF (mandatory) and PNG (optional). If one needs to create a number of images in indexed colour mode that share some colours and where deviations are not acceptable, there should be an alternative to indexing them all as one image to then cut them apart. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...
On Tue, May 22, 2007 at 11:29:55AM +0200, peter sikking wrote: Thorsten wrote: 10. better printing support Paper, maybe better called media, could be handled as special kind of layer that is restricted to stay below all image layers (unless hiding stuff below it makes any sense). Think workflow, not about highjacking a image concept (layers): I thought I did. Think about workflow. But paper alone is not a sufficient model, I fear. There's the thing you print on and the final product (after cutting, perhaps) ... PDF has this media/crop/trim/bleed/art box model. Scary stuff ;) http://bugs.scribus.net/view.php?id=1041 Better written, but german: http://www.dtp-praxis.de/tipps/ pdfboxen.htm Wow scribus, a pre-press oriented (that is their product vision) dtp app. GIMP's ambitions to not reach that far. The nature of Scribus is not of interest here, Ther just happens to be an english language description of the terms in their bug tracker. It doesn't matter if you deal with complex page layouts or just images. It also doesn't matter much whether you target your desktop printer or a larger machine. The issues of media size, printable area, bleed and desired final size are just there. I would really measure this static-indexed requirement against the product vision before throwing in yaUIc (yet another UI complication). Sure. And why are we talking teensy little details here when the presentation and blog entry was about solutions models: the general direction forward? It doesn't look to me like there is anything to discuss about your solutions model. I would mean this in a bad way if it didn't look like you know what you are doing there and if what I read didn't seem all agreeable. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...
On Tue, May 22, 2007 at 01:17:38PM +0200, peter sikking wrote: I thought I did. Think about workflow. Then how do you end up selecting an intra-image concept (layers) to support the task of putting the actual image itself on another medium (paper)? If you concentrate on understanding the task, then thinking about layers feels wrong within a second, and you can move on to solve the problem in another way. If you concentrate on the can't-be-painted-on and has-to-be-below- image-layers aspects only. But a place at the bottom of the z-order is natural. The medium has size like a layer and relative positioning. Hiding/showing is surely useful. This plus the chance of making media/positioning alternatives available in a straightforward way is what came to my mind. The slight modification of putting it into a distinct section below the layers or if it has to be, it's own panel (which I would place below the layer panel by default) might be all that is needed to make the difference clear enough. But I have been thinking aloud. I'm terribly sorry. All those concepts fall within GIMP users' awareness and are actually named in the blog entry as interrelated textfields that support the placement. But they will be handled in the UI in a way that gets artistic results done, and not in technical pdf file format terms. I didn't say those names have to appear in the UI. It doesn't look to me like there is anything to discuss about your solutions model. I would mean this in a bad way if it didn't look like you know what you are doing there and if what I read didn't seem all agreeable. What I mean to say is: can you see that all this detail stuff does not really matter at this moment, unless one of these details invalidates the overall concept? This is the way to cut through the jungle of small details, and to concentrate on major problems that need to be solved first. As the overall concept seemed clear to me so far, I though it was ok for me to post what your points made me think of. As part of going from the general to the more specific. To avoid me forgetting about these things, if nothing else. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On Sun, May 20, 2007 at 03:29:37PM +0200, Sven Neumann wrote: Well, you have overlooked the main problem here. If you add user interface elements to the image window, then these will cover parts of the canvas and there will be no way to unobscure the covered parts. So if you think that it may be important that the user has a chance to check the content of the image window, then a popup dialog is the only way to go. No. Either being able to see the canvas is important, in which case adding the message and resizing the image window can be better than having the user move a window around. Even without resizing, scrollbars could come o the rescue. Or it is not important, so the window doesn't have to be resized and the message can obscure part of it (which might be less drastic than the dialog window jumping up right in the middle. With a dialog window, I wonder if it would be better to place it top right, though. Close to the Close button. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On Sun, May 20, 2007 at 04:29:34PM +0200, Sven Neumann wrote: There is nothing more annoying that a window that resizes itself. In particular because it is very difficult, if not impossible, to get this right with all the various window managers being used by our users. The window manager may even decide to completely ignore the resize request from the application. With a dialog window, I wonder if it would be better to place it top right, though. Close to the Close button. Placement of dialog windows is left to the window manager. And only because your window manager draws a Close icon in the upper right corner doesn't mean that other window managers do that. I didn't meant to imply the GIMP should or could take care of this. Taking all the feedback into account, here's another variation, now entirely targeted at the WM. Just so you know I'm not ignorant ;) I will try to raise this with the Metacity project. http://thorwil.wordpress.com/2007/05/20/save-changes-integrated-3/ -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Save Changes Integrated
Hi! Image window and Save Changes dialog turned into one: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On Fri, May 18, 2007 at 03:41:39PM +0200, peter sikking wrote: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ Somehow I do not know what structural problem you are trying to solve for one million users. The current Save Changes dialog tends obscure the image. If users would be damn sure about closing a window with unsaved changes every time, there would be no need for asking back. So the user should be able to see _what_ he's about to save or discard. The image itself is likely to be much more informative than filename and changes from the last x minutes. BTW, from my own experience, hitting Save when the prior version was actually better and something to be kept is much more of a danger than not saving something you wanted to keep. Now that I write about it, another idea comes to my mind: The Save Changes window could have a toggle to display the last saved version. The dialog is very closely tied to the image window, but still presented as its own window. Transforming the image window into a Save Changes window is as clear as you can get about the relation. One can get rid of the visual noise of a dialog with titlebar and border and avoid obscuring the image in one go. So this removes unnecesary elements from screen, something that I think is quite helpful if you deal with several image windows. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On Fri, May 18, 2007 at 05:38:19PM +0200, peter sikking wrote: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ It is a modal dialog situation: we need a decision now. Yes, the scope being the image. Regarding that one image window, a decision is needed, outside not. If users would be damn sure about closing a window with unsaved changes every time, there would be no need for asking back. So the user should be able to see _what_ he's about to save or discard. The image itself is likely to be much more informative than filename and changes from the last x minutes. I find this stress on looking at the image very worrying. What drives the decision is the state of mind of users: these changes in the last xy minutes were useful/useless. Either this state of mind is there, because the one just worked on the file, or it is not there, because one worked yesterday on the file. In that case I am not going to invite anybody to investigate that within a dialog. Back off (Cancel) and investigate with all of GIMP's capabilities, I say. Ok, you have a point here. The dialog is very closely tied to the image window, but still presented as its own window. Transforming the image window into a Save Changes window is as clear as you can get about the relation. I do not think so. First you have to realise that this decide to save the unsaved is an error scenario, a non-task if you will. You are building a full-fledged UI for a task that does not exist on users' radar screen. That is a misfit. You never witnessed people using the dialog with the intention of triggering a save and closing the window? I did. Of course I have no numbers :) Not that this changes anything here, I just thought does not exist on users' radar screen is bold, if not wrong. I think I understand your reasoning and maybe my proposal is not good. I'm not at all convinced about the presentation of this modal, tied to another window while looking like any other window itself dialog, though. It already shares focus and minimising with the image window. It being a semi-separate window is only good for moving it. Moving it is only good for getting to see the whole canvas. If it would not cover any part of the canvas, there would be no need to move it. If there's never a need to move it, it shouldn't be a semi-separate window. Of course something could be done on a WM level, like not drawing it with a titlebar and placing it right below the image window menu bar or whatever placement would emphasize the connection. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On Fri, May 18, 2007 at 08:33:38PM +0200, Thorsten Wilms wrote: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/ I'm not at all convinced about the presentation of this modal, tied to another window while looking like any other window itself dialog, though. It already shares focus and minimising with the image window. It being a semi-separate window is only good for moving it. Moving it is only good for getting to see the whole canvas. If it would not cover any part of the canvas, there would be no need to move it. If there's never a need to move it, it shouldn't be a semi-separate window. Of course something could be done on a WM level, like not drawing it with a titlebar and placing it right below the image window menu bar or whatever placement would emphasize the connection. http://thorwil.wordpress.com/2007/05/18/save-changes-integrated-2/ -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Canvas Size Margin
Hi! I often use Image: Canvas Size to add a margin. Recently mainly with mockups, where I want 12 px all around. Doing the calculations in my head isn't too difficult, but does eat time and makes me context switch. One solution would be allowing calculations in the entrie: 436+24 ... Typing +24 can be faster than erasing and typing 460. *2 is faster than switching to percent and 200. But that should be added on a GTK / per widget level, perhaps? Another solution would be having fields for the margins or differences. Would complicate the dialog, but could offer nice possibilities if one needs different margins left/right/top/bottom. -- Thorsten Wilms Thorwil's Design for Free Software: http://thorwil.wordpress.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote: Despite the idiot-user title of this feature (copied for PS it seems) ... If the user is so lame that they are going to click on a feature called save for the web If a user wants to save images for use on the web, save_for_the_web is high level thinking and not lame or idiotic. The choice of format is secondary. 1. save for web 2. use most appropiate format Someone choosing save for the web needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions. I know the characteristics of JPG, PNG, GIF. I can usually tell what will work best. There are border cases, though. Then I have to experiment and can't formulate save_as_jpg or save_as_my_png as my initial goal at all. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
On Tue, Feb 06, 2007 at 05:01:33PM +0200, Aurimas Ju?ka wrote: I've worked on a similar plug-in. It would be very interesting to hear some comments on it as I am planning to improve it. Here is a short introduction: http://img300.imageshack.us/img300/6571/saveforwebid4.jpg Peter, could you tell if it fits in save for web scenarios and what could be changed to make it better. If the formats are just JPG, PNG, GIF, radio buttons should be considered for faster access. I resize images requently when exporting for web, but almost never crop them. Like I said before, I prefer toggling one view over 2 side by side. I don't think separate scrolling is useful. The again, a single set of scrollbars for 2 panes might seem odd. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Save As JPG Integrated (mockup)
Hi! Whenever I save an image as JPG, I have to move both the Save_Image and the Save_as_JPEG dialog out of the way to check the preview. I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for? Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling. There's quite a number of ways it could be organized, my mockup shows just one: http://thorwil.affenbande.org/wp-content/uploads/2007/02/save_as_jpg_integrated_01.jpg Advanced options hide 'under' the expander. There could be a button to bring them up in a dialog instead. File size can be read in the statusbar. I moved the buttons down there as it's the standard location in dialogs and to take the place of the progress Cancel button. Mouse-miles could be less with the buttons in the new toolbar. They would also be less likely to cause an expectation of closing the window up there. Thoughts? -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Sat, Feb 03, 2007 at 01:13:56PM +0100, [EMAIL PROTECTED] wrote: On Saturday, February 3, 2007, 12:48:54, Thorsten Wilms wrote: Then the Save_as_JPEG controls could appear on the image window (inspired by the Firefox find bar) to further cut down on window juggling. Only as an option - some of us have multiple displays, and use the advanced options regularly. Do the save dialogs not appear on the same screen as the image windows? I see how if you have at least 2 displays, having the preview on one and the (expanded) controls on another would be nice. But if you have to manually move the windows far less so. I'm rather sure users of multiple screens who are at the same time frequent users of the advanced JPG controls are a small minority. Nobody likes to be ignored, though, of course ;) -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
On Sat, Feb 03, 2007 at 02:02:58PM +0100, peter sikking wrote: Thorsten Wilms wrote: I think the Save_Image dialog should just disappear after use, as both Cancel and Help are available on the second dialog and what else would it be good for? Yeah it can go. It would only make sense if a Cancel on the jpeg options would get you back to the Save_Image dialog, in case you see that the jpeg compression is not appropriate, you change your mind and go back for png or so... Good, that would make the process quite a bit more efficient (for me) already :) http://thorwil.affenbande.org/wp-content/uploads/2007/02/ save_as_jpg_integrated_01.jpg I just had a quick look. Later in the expert evaluation we will get to the save for web scenarios and I will be in a better position to deal with this. But for now: Hmm, ok. If we try to do an all in one, then the result has to look and feel like a dialog, not like a main window, because of the modal nature (finish this first) of the task. But this would not be like your common dialog that disappears after Cancel/OK, but rather a window that changes state. One could see this as argument for having a separate dialog with preview. This idea is about avoiding a 'jump' in interaction and using the image window which is likely in the right place and size already, though. It is difficult for me to say whether sawing off more main window bits (no menu bar, tools, palettes, inspectors or rulers; default to magnification tool) and adding more dialog-ness (get buttons out of the status bar) to what you have drawn, or start from scratch on a BIG-preview dialog would be the better way to go. I thought about removing at least the menubar but decided against it, as you can still zoom, toggle guides ... Might be better to not allow access to editing options, though. Advanced options hide 'under' the expander. There could be a button to bring them up in a dialog instead. My gut feeling says that there is a better solution available here, but I am only able to work on that after the expert evaluation. Surely the most problematic aspect. File size can be read in the statusbar. Better keep the quality slider and file size (main cause and effect) physically together. I wanted to, at first. Then moved it to save width for small images. BTW, some apps have web export dialogs with side by side panes original/compressed. I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. It's important it can happen with a single click. I say this because the thought that tabs might make it more clear what is what has occured to me ... this is the reason I don't want them. -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
On Wed, Jan 31, 2007 at 11:02:20AM -0800, Akkana Peck wrote: [pre- vs. post- selection delay] I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. To get the screenshot dialog out of the way, you mean? Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time? Yes. I always reserve a workspace for GIMP, though. To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case). In my case, I use a short delay just to switch workspace most of the time. Sometimes I need more delay for some menu or popup. Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior. I think so, too. -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Thu, Jan 18, 2007 at 02:57:30AM -0300, Manuel Quiñones wrote: I've had a similar idea than yours, and implemented it right away. But instead of changing zones with keystrokes, the zone can be selected using the crosspoint of two perpendicular guides. I know this is ugly, and maybe your idea about changing to next/previous zone is better. Here it is: (...) http://wiki.gimp.org/gimp/DrawingZones I like the idea of using a layer and a palette to draw the zones. Even though I talked about hard edges, I (and everyone else drawing) need anti-aliased ones in almost all cases :} The selection via 2 guides isn't practical, of course. I understand why you do it for now, lets hope there will be a solution. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Thu, Jan 18, 2007 at 08:04:28PM +1030, David Gowers wrote: I like the idea of using a layer and a palette to draw the zones. Even though I talked about hard edges, I (and everyone else drawing) need anti-aliased ones in almost all cases :} Well, the simple case of that is easily done -- I just inserted two lines in my zonemap tool that automatically antialias the zone mask using potrace. I think that repeatedly drawing in a non-binary selection is a mistake, though -- layer masks or 'preserve layer alpha' do it better. I rarely ever use antialiased selections for drawing, only exclusively for fills (either color fills, alpha-clearing fills, or editing layer masks). Drawing into AAed selections makes selecting objects a no-win (ie. cannot get a perfect result, because the colors along the edges are uncontrolled) situation, and dirties colors. I usually work with a bunch of alpha-locked layers (paint shape in flat-colour, lock alpha, paint shadows, light, texture ...) I guess the perfect zone implementation would actualy need some overlap to have the same effect of alpha-locked layers. In fact, the best simple solution could be to copy selection masks onto layer masks. Like, you have a 'painting' layer, and when you change zones: 1. Any changes are saved onto the underlying layer 2. The entire content of the underlying layer is copied to the paint layer 3. The layer mask is copied from the next zone-mask (channel) This would play well with my 'apply paint' plugin, which applies any paint on a layer (specially marked by name, beginning with the character '+') to the underlying layer and then clears it to a neutral color. In short, drawing zones happening on the level of layer masks? Another model I thought about would require a graph, so I guess it's really a bit far out for GIMP: Having a layer/node for compositing drawing layers/nodes. It would be like a free-form multi-split view on a number of layers. Drawing starting in one zone of the view and continuing the stroke outside of it could paint on the underlying layer/node, maintaining the advantage that using layers has now: you can draw below a layer and later change the shape of an upper layer without having to fill a gap. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, Jan 17, 2007 at 08:52:48AM +0100, Sven Neumann wrote: I start to realize what you are asking for now. But, instead of suggesting a solution, could you perhaps try to explain where the problems are when you try to use the currently available features to implement your workflow? You should be able to do this with layers or selections. If that doesn't work for you, then perhaps there's something that we need to change about how layers and/or selections are handled. I don't think that we need to introduce a completely new feature. # The goal: Draw on several areas of an image while maintaining sharp edges around each of them (in many cases they will touch, so before I talked about edges between them). With the least amount of interruption! # Motivation You often have parts of an image that need the same treatment, but are clearly divided (like hand and body on my example image). You draw with the same base colour, draw light and shadow, texturing ... all best done in one go. [Drawing from scratch might not be seen as typical use of GIMP, but I know I'm not the only one and the closest commercial counterpart, Photoshop is used for this alot, even though there's Painter. Check for example http://forums.cgsociety.org/forumdisplay.php?s=f49edc03bcbdb53f623009e1366edda9f=133] # Layers Using layers, you will likely end up with one layer per area. You need to switch between them. Just today I took notice it can be done with Page Up/Down, layer name appears in status bar. If you don't use the shortcuts, you need the layers dialog, taking away space from the drawing area. If you use them, it's just a keypress, but you have to take care in which layer you end up (drawing something on the wrong layer is a mistake i make often enough, even usuing the layers dialog). # Selections Loading selections to me means having to change between layer and channel tabs and a lot of mouse movement away from the canvas. This already makes me use layers with locked alpha everywhere I can. Only with exactly 2 areas, one could use inverse selection. # Drawing zones I think drawing zones would have to be organised in sets. The zones of a set would always cover a full rectangle like layers do. Inside a set you would add/delete zones and select the zone you want to edit. Editing could then happen with the current selection tools. Masking would require 1 colour for each zone. I admit this sounds a bit complicated. Now for the nice part: once setup, you just draw! If you move the pointer outside the zone you started drawing in, nothing happens (just like painting outside a selection). You don't have to hit a single button, but get to focus on drawing completely. # Stop lines My initial idea was to have just lines (non-closed paths), which you can't draw past. So they act like a selection boundary, but are not closed. You could even draw all around them, something that might be helpful on drawing armpits. I then thought it might be hard to check for this, so closed regions/zones might be easier. The management of stop lines might be more simple, though. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
On Wed, Jan 17, 2007 at 01:18:35AM -0800, Saul Goode wrote: If I am understanding you correctly, these scripts should be helpful to you in your workflow. You would still have to manually invert the selection; but I would point out that the Select menu can torn off so that Select-Invert is just a mouse-click away. Sorry, no. I don't see the benefit over switching between layers. Lets try another description: Drawing zones would be like 2 or more non-overlapping selections that are active at the same time. Which one is applied to a drawing operation is determined by where the mouse/pen-down happens. Implicit area selection (to not say Selection selection) :) -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More interface rantings
On Fri, Oct 20, 2006 at 02:29:31PM -0600, Scott wrote: I also completely fail to see any reason why areas outside the image should be selectable by a crop tool. If I lay a paper photograph on a table and take an xacto knife to it, do I reasonably expect to cut out part of the table along with what I cut out of the photograph? It is nonsensical. You're quick with a word like 'nonsensical', when in fact you just have a narrow view on this. You could for example have a photo and now you want to add a border around it. The canvas size dialog doesn't the same direct manipulation. The GIMP is also a nice tool for drawing. Here it can always happen that you want to change the composition. Perhaps the foreground asks for more space on the left. Easy to do with the crop tool, especialy now it has guides (center, golden cut ...). -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More interface rantings
On Fri, Oct 20, 2006 at 10:32:50AM -0600, Scott wrote: Using the 2.2 version, the interface of the crop tool was very handy for me. Typing Shift-c brings up the tool; a quick move of the mouse creates a selection area; over to the tool-option menu that automatically pops up, type in 300 and 200 for the dimensions; now grab the lower-left handle and move the selection as desired, click and it's done. The old crop tools was ok if you have a fixed target size. The dialog always got in the way for the cases where you crop the image to find the right aspect. I recently upgraded to Mandrivel 2007, which includes the 2.3. Did my first crop this morning. No tool-option. Okay, clicked on the tools, or view, or some danged thing, found the tool option. Hmmm, a whole bunch of stuff that doesn't really relate to what I am doing. Finally I find some hidden dimensioning menu and enter in the 300 and 200. The new place of the dimensions saves me from having to move a dialog out of my way every time. I'm less happy about the expander, though. Grab the lower left corner - whoops! All the corners resize the selection! Handy not. Resizing and finding the right cutout has become way easier now. Instead of automatically confining itself to the image as before, I can move the selection outside of the image. Now that's *really* handy - like I would ever want to select a certain size and then have part of it outside the image. Sometimes I need to crop extending to outside the current image. But there should be an option for confining to current size. On by default, as it's the right choice in most cases, I think. How can a tool so simple in concept and so frequently used as crop have been bollixed up so badly? To me it seems it's just that you see only a single use case ;) -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mock ups for vanishing point
On Wed, May 31, 2006 at 10:37:17PM +0200, Pedro Alonso wrote: I am Pedro Alonso, a SoC student working in the project Vanishing Point clooning. Great project. http://www.pedroalonso.es/mockups/plot1f.png http://www.pedroalonso.es/mockups/plot2f.png http://www.pedroalonso.es/mockups/plot3f.png I think it would be nice to get around having a modal dialog (one with Cancel/OK) for a more straightforward interaction. How about having a tab next to Layers/Channels/Paths for perspective planes? You would create a new one by just using the p-plane tool similar to how paths are created. Each p-plane in the list could be toggled on/off. Every tool, as far as possible, should be affected by p-planes. The p-plane tab would also allow creation of selections from the planes (like with paths). One think I'm unsure about is how to handle plane extension. With your example image, the same perspective is everywhere, so one would need a way to say the p-plane is defined in a smaller area, but covers all. But if there would be a vertical wall in that image, you would need a second p-plane. Saying that one of them covers all of the image, except where the other p-plane is, wouldn't be good enough in some cases. A solution could be to define for each edge, wether the plane extends in that direction. -- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Comments on gimp's interface
On Mon, Apr 03, 2006 at 01:14:07PM +0400, Alexandre Prokoudine wrote: I might have lost track. One of my tablet's pen buttons (I own Graphire3) does exactly panning in GIMP/Inkscape/etc. If one has a tablet without buttons on a pen, he can press Space on his keyboard and go panning. So, what is exactly wrong with panning via tablet? With GIMP and Inkscape, panning is on MMB. There's the option to put double-left-click on one of the buttons. If you do that, you can't have both MMB and RMB also available. If you don't, all is fine with panning. Space switches to the move tool here. --- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Comments on gimp's interface
On Mon, Apr 03, 2006 at 01:48:18PM +0400, Alexandre Prokoudine wrote: There's the option to put double-left-click on one of the buttons. If you do that, you can't have both MMB and RMB also available. If you don't, all is fine with panning. So it this considered GIMP's fault or tablet's fault? Either the fault of who ever set such defaults (where I don't remember the linuxwacom defaults, but i think on windows double-click on the lower button was default), or the user who keeps or makes it that way. One could say apps shouldn't rely on MMB. But there are so many features and options to have especialy in media applications, that working around this is too hard, when everyone can easily have 3 buttons. Now one could argue space should be for panning like in Photoshop, not move tool. I prefer middle-click drag for panning, anyway. Cheers, Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
On Sun, Jun 26, 2005 at 09:21:39PM -0300, Joao S. O. Bueno Calligaris wrote: On left-clicking on the layer-tree, where the current linked icon for each layer is placed, a drop-down menu would be displayed. This menu would contain 4 itens which could each be checked or unchecked: Transparency Lock Color Lock Geometry Lock Linked Linked is not like the locking options, so it should be kept separated. A dropdown menu is expected to disappear on clicking an entry, so changing several options would make for a click orgy. Color and Geometry lock are no way as important as linking. The fact your targets only appear after an initial action slows you down. Icons/Checkboxes above the list might be faster to handle, because you see them right away. If either of these get checked, an apropriate icon (which could be always the same) would displayed in that place. It's usualy difficult enough to convey a single action or state with an icon, but trying to combine 4 aspects with all possible combinations? The only possibility I see are 4 mini icons in the space of one, most likely making for a nice pixel salad. I'm all for icons above the list. --- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
On Sat, Jun 25, 2005 at 08:19:16PM -0300, Pedro Kiefer wrote: I've just made this mockup (attached) of how the locking mechanism should appear to the user in the layers tab. But that could be wrong, in not really familiar with the GNOME HIG. Clicking in an unlocked lock will lock the layer, clicking in a locked lock will unlock it. I think the lock should be in front of the layer names, right after visibility but before chaining, as it will block the later mechanism. There should be a third state for chaining, showing the symbol halfway faded out or something like that, to indicate it having no effect when the layer is locked. But I'm in doubt if locking is worth the space and additional visual complexity. I mean, if you don't want to change the contents of a layer, just don't select it. If you manage to draw/edit in the wrong layer, there's always undo and you should save frequently anyway. --- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] size-pressure relationship has been inverted for airbrush: complaints sought
On Fri, Dec 31, 2004 at 08:08:28AM -0800, William Skaggs wrote: Hi, I just made a one-line change in cvs head, suggested by Dave Ahlswede, that inverts the relationship between pressure and brush size for the airbrush, on the grounds that this more accurately reflects the behavior of a real airbrush. People who use tablets should try it and see if they approve, and complain here if they don't. I can't test that currently, but I imagine it's nice sometimes, but will be counterproductive in other cases - I would like to have it as an option. And if there should be no option, I would prefer the known, not inverted behaviour. BTW, how about using tilt for a closer airbrush simulation? That is, not having a fixed shape brush, but a tilt depending cone. --- Thorsten Wilms ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
I was very thankful for Greg writing somethink like I self could have written (allthough with less good and nice wording), therfor I want to show some support. On Sat, Jun 12, 2004 at 07:41:49AM -0700, Carol Spears wrote: i took on a project that no one wanted to do for the gimp. everyone whose opinions i was representing near to the end of this project were more important to me than the one or two people who destroyed it. my project was destroyed (the gimp web site for the users) by a man making decisions about what information users need who has, to the best of my knowledge, not even on the gimp-user mail list. I don't see the connection to your recent posts. What gives you the right to write such negative, troublemaking, prtly irrational posts (that are extremely hard to parse btw) on a public list? And you wrote about protecting some people. I wonder who's going to protect people from you? perhaps if you reseached the issues, asked some of the original developers what the deal is you would write something both unpleasant and factual about me. Most people wnat to be understood (even by broader audience). But you require research? until then, you are being unpleasant and unfactual. Unpleasant and in some way even unfactual was limited to posts from you Carol, IMHO. --- Thorsten Wilms ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Sat, Jun 12, 2004 at 09:09:26AM -0700, Carol Spears wrote: I don't care for your stress and bitterness, especialy since you show no understanding for other people in your recent posts at all. I'm not interested in your respect. I do not have to show contributions, because it's you who keeps making noise. Besides devs on many lists have an open ear for suggestions and not previously answered questions without asking for contributions. Those that do the actual work, AFAIK, are pretty relaxed, while you are radiating pure negativity. RTFM, remember volunteer work, ignorance is all ok with me. But even just following the list is not exactly fun, because of what you pulled of with Ellen, and are continuing in some way here. And how many people have to ask you to change your ways? (Even Sven asked you to stop regarding Ellen) You keep making negative remarks about devs, are disrespectful to anyone else. If you see it as your job to keep people you aparently think of as idiots busy, then I know what I have to do now. You are the very first person I will filter out from mail (you are already the first person receiving something personal from me on a list). Sorry to anyone else, I will shut up now. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Extended tablet functionality
Hi! I recently purchased a Wacom tablet and have been trying to use it not only for painting/coloring, but sketching/lineart. After some getting used to it control is not that much less than working on paper. But I soon noticed problems with long curves especialy in vertical direction. Working analogue I just turn the paper (or alter my own position acordingly). Something similar should be possible in the digital world ... Now Painter supports rotating the view without affecting the image, and so should the GIMP. There's a bug report here: http://bugzilla.gnome.org/show_bug.cgi?id=55367 Like stated there I'm willing to provide mockups, but after looking at Painter Classic there is not much to mockup. There should be a tool in toolbox for rotating the view. The icon would be an open circle with arrowheads (I offer to provide that ... are there any guidelines or notes how the existing icons came to be?). I think it should be a seperate tool from the existing rotate one, because it isn't destructive/undoable. Rotation would happen by just click-dragging anywhere in the canvas area. It could be nice to indicate the rotation center, but it's not needed. Resetting to 0 should be possible by clicking on the empty canvas area. A doubleclick might also do the trick. Of course for a fluid workflow there would have to be something faster than actualy switching tools. It's just great to have panning on middle 'mouse' button (one of the details where GIMP has an advantage over PS). Would it be possible to trigger rotation on left-drag, when middle button is held down? Else it could work with middle button and Ctrl. View rotation could also be triggered by right-drag on the panning tool in the scrollbar corner. Could also have it's own place instead of the 'Set canvas padding color' thing. However, in the popup window a line would be drawn from the initial pointer location to the actual one to indicate center of rotation and pointer location. Ok, something to mockup, but not before I hear something positive ... And now for something else: Because tablet and monitor aspect ratio don't match, and distortion free mapping is needed for serious graphical work, there's always some unused tablet area. Now there are those special fields (new/1, open/2, ...) on larger wacoms and special support from the Windows driver. But having to look at the tablet is stupid anyway. How about mapping the unused area to a special window, that will appear on the screen edge, when the pen is in that area? This window could be filled with editable commands and settings. I bring this up here, because GIMP is the only app with special tablet support on Linux (I know of), and the one where I would expect the largest benefit from such functionality. --- Thorsten Wilms ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
On Mon, May 17, 2004 at 06:26:16AM +0200, Jakub Steiner wrote: * The ratio control has been dropped, since it effectively duplicates the % unit. I think there should be fields for the aspect ratio (not starting on 1x1 but actual values). * Print resolution has been removed (discussed at task 6 below) For me, changing print resolution is an integral part of scaling. Say you have a scanned image and need to scale it down for a layout. Print resolution would go up without intervention. Being able to restrict it to the highest value that makes sense in one go would be a good thing. The problem I have with the current dialog, or that of PS, is that it's hard to understand what will change, when you enter a value somewhere. I think a solution might be to split things up into 3 areas: - Current values (just output, not editable) - Target values. Start with empty fields. The user can add target values until everything can be determined (left input fields will be disabled). Because all possible tasks are realy about defining target values, and having feedback about what else will change and how (see next one). - Final values (not editable). The consequences of initilal values and target values. The values are: - pixel or % width and height - print width and height - resolution - aspect ratio (important for artistic work, giving a work a nice shape) Oh, and finaly Quality/Interpolation should be in the dialog, because it's something to decide on per image. --- Thorsten Wilms ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
