Re: [Gimp-developer] Please restore removed crop tool functionality
gimp-developer-boun...@lists.xcf.berkeley.edu wrote: Therefore I'd still consider the non-destructive crop feature at least a usability enhancement. At least personally I would assume that the crop tool of a professional tool like Gimp would offer this option as well. (Not sure whether PS has it.) I couldn't swear by it, but I don't think it does. I've had similar issues to you in Gimp regarding this issue. I've learnt to create a new layer above the image, fill it with with black and then apply a mask to it to reveal the image below. I'd quite like to have a way to be able to adjust the layer mask on canvas once it's been created. The nice thing about cropping with layers is that you can toggle their visibility, so you can check your old crop against your new one. This still doesn't solve the problem of making the mask in the first place because neither the mask nor select tools currently conceal the area of the image being masked. The crop tool applies a semi-opaque mask to the cropped area, but this isn't really satisfactory. In this case, your method of using the canvas window still has no replacement. However, adjusting the opacity of the mask has been specified for both the selection and crop tools and I'm trying to learn the gimp code with the hope of implementing the feature...cos I need it. :p I really only use the crop tool to remove unwanted data in order to speed up processing of the image from then on. This has proven to be an essential feature even for my (obsolete) 6.1Mpixel camera. David M. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Alexandre wrote: On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote: As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more gconf-editor, /desktop/gnome/interface/menus_have_tearoff And it's on 1st page of google searhc result for gtkrc tear-off for me Did you test that? Because it doesn't work for me. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
gimp-developer-boun...@lists.xcf.berkeley.edu wrote: Hi all ! This is a long post, replying to many previous posts, and adding some parts from IRC chats, and some even from discussions with Gimp developers. ... I have a degree of sympathy with this post although it seems to go to the other extreme. Backwards compatibility *is* overrated. Autotools is a great example of what happens if you don't trim the crud out of your software. No doubt, I can compile Gimp on every Unix platform ever conceived between now and 1972 but I still have to learn about 4 different languages before I can begin to start understanding how it works, let alone deciphering the scripts. Call me an idiot if you like, but it shouldn't be easier to learn the finer points of C++ than the tool that simply builds it. On the other hand, we have KDE 4. Plenty of improvements, no doubt, but no users left to appreciate them. :) As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more. Luckily for me, canvas right-click still provides the feature. I needed it, btw, because I wanted to add several guides to my project, one after the other. Rather than having to navigate all the way to that menu item every time, it's much easier to just have it available on the screen. That's not the only use of this feature, btw. Another good use is for learning keyboard shortcuts. No need to hover the mouse over an icon for half a second; just glance at the menu. Like I said, I don't know what's happened to this (really nice) feature but I did find a clue in some Java/GTK SDK documentation which states that usability studies have concluded that menu tear-offs are a bad idea and should be avoided. Oh dear, I thought. Someone's been conducting usability studies. Not that I have anything particularly against UI studies, but the method had better be sound, the assumptions had better be correct, and the results had better be applied appropriately. If the conclusion comes as a surprise, re-examine the experiment...carefully. Anyway, getting back to the Gimp, I'd be willing to bet real money that whatever ideas you have about a typical Gimp user are probably wrong. By all means, design for whatever you think the common use case is likely to be but remember that Gimp is (to borrow a programming term) a low-level IMP. That makes it even more likely that usage patterns from one user to the next will be radically different. If you don't enable Gimp's users to do the things that you can't think of, you'll just have non-plussed Gimpers. If you take away those things? Well, good luck with all the hate. :) ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Behavior when saving a selection to channel
Rob Antonishen wrote: I think that all of the channel use cases should be examined before deciding how these should act. My own experience with channels is limited to: 1) Image decomposition for masking/converting to greyscale 2) Saved selections ... Sven mentioned other uses, like spot colour and halftoning. I would add LAB to the list. Currently LAB implementation is via layers but it's really a colourspace. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Guillermo Espertino wrote: I understand. It's clear that everyone's preference may vary on this subject: -Photoshop users will ask for floating windows nested in a container window. They ask for an MDI structure because that's what they know, but I suspect they'll be happy with any solution to their problem that works well. All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the where goes the omni-present menu bar? problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed? Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen. I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example. I'd address the short comings in GIMP's window implementation first and then see if MDI is actually still demanded before thinking about implementing it. Of course, you'll always get some criticism, but I think the majority would be satisfied with a solution that works, even if it isn't like how PS does it. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: Am i thinking in a way that could possibly be implemented? or is the word extensible remotely applicable to my idea? So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things). It sounds to me more like a separate companion program that's used to construct plug-ins than a plug-in itself. I like the idea very much. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Missing button to confirm some tool actions (usability)
Michael Schumacher wrote: Von: David Marrs [EMAIL PROTECTED] Clicking inside the cropped region also implements the action. It's actually a feature I'm not sure I like because it deviates from the rectangle tool's implementation of the same action - to hide the handles. Well, I don't know if that's what the implementation is technically but that's what it effectively does and it's what I use it for. No, that's not what it does effectively. If applies the resizable selection frame to the selection mask. In any other selection mode than replace, you'll face the same problem with this behaviour as you now do with crop. Yes, I suspected I was over-simplifying. Nevertheless, the ability to hide the handles is very useful, maybe less so for selections but definitely for crops. Is the ability to do this implemented in some other way. If it isn't, can we consider adding it? ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Missing button to confirm some tool actions (usability)
Clicking inside the cropped region also implements the action. It's actually a feature I'm not sure I like because it deviates from the rectangle tool's implementation of the same action - to hide the handles. Well, I don't know if that's what the implementation is technically but that's what it effectively does and it's what I use it for. So my instinct with the crop tool is to do the same thing, to get a feel for how the crop might look. and it goes ahead and performs the action before I'm ready for it to. Undo fixes the problem but it's still annoying. I like the idea of an accept button to the right or left of the status bar. I don't think most users would think to look in the properties dialogue for the action and there's really no other logical place for it to go. I seem to remember buttons being in there for other tasks. I would presume that most users who don't know the keyboard controls aren't going to hide the status bar. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
peter sikking wrote: interesting to see Compare compressed images against original, would it be enough to see the compressed one and balance that against the size and what your customer expects? As an experiment at work I decided to work on just the one image when saving for web and found that I really don't need to do the spot comparisons between images after all. What's more important is the ability to change the quality of a jpeg with minimum faff. It turns out that PS's save for web has a couple of flaws in this regard: 1) No adjustment is made until *after* the slider has been released. This means that I can't just drag the slider up and down the scale to watch how the image quality changes. This wouldn't be so bad if it weren't for 2). 2) The slider's really small! It's easy to lose the slider after I've released it, especially as my attention is on the image, not the slider. Basically I just want a way to assess the quality of an image at different compression ratios quickly. One idea that appeals to me is to have a row of 10 images all compressed at 10% intervals. Then I could just click the best of those. This would probably be good enough for most cases. If it isn't, I could have an additional step: click two adjacent images (e.g. 70% and 80%) to reveal another row of 10 images, this time compressed at 1% intervals between 70% and 80%. --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
[EMAIL PROTECTED] wrote: Neither is chosing the appropriate format specific the web so save for the web concept is misleading. It should be select best compression format or so. I have no argument with this. If we can do away with a separate dialogue altogether, so much the better. It would be interesting to have a direct means of comparing various levels of jpeg compression side by side but this is not something you need to do in detail every time you save an image. There are so many variants once you have several formats and all thier parameters, that I think it would be hard to design an all encompassing interface. It would probably have to be done in several stages. A screen full of thumbnails with mouse-over zoom could eliminate the blantantly unsuitable formats and ratios. Then a second level do a closer comarison and probably a third level to fine tune compression options. I don't think it really needs to be that complicated. All we're talking about is the options already available in the export dialogue and 2 or more preview panes. The controls could change to reflect the active pane. BTW David I find jpeg quality param break-point is 82 -84 , beyond that as you say it gets bigger with no gain. You can drop to 65 if you're really byte conscious and quality is not important. Somewhere between 70 and 80 per cent is about normal for me, but on my latest project I've been getting good quality at as low as 60. You're probably right that I could just use my eyes but I always succumb to the temptation to do a direct comparison. :p --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
Akkana Peck wrote: I might have misunderstood this step (I definitely don't follow the comment about PS not letting you edit -- maybe that's a PS issue) but it sounds like if you did a Paste as New in gimp, you wouldn't need to create a new canvas or figure out any dimensions. Oh yeah. Thanks for the tip. :) --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
peter sikking wrote: interesting to see Compare compressed images against original, would it be enough to see the compressed one and balance that against the size and what your customer expects? I usually do comparisons when I'm trying to get the best image quality out of jpegs. There seems to be a threshold with jpegs beyond which reducing compression only has a negligible effect on quality. I usually search for that point by reducing the compression of a low quality jpeg until it looks the same as (or close to) a high quality one. I suppose I could just reduce compression until it looks good enough but I prefer to do spot-the-difference style comparisons. --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
peter sikking wrote: can you tell me what you mean with manual work needs to be done? that can help us with our work. Well the most common case is simply selecting a slither of an area to be tiled as a background image. Sometimes you have to hide a foreground layer before making the selection such as filler text or an image. You will also want to pick a colour with the pipette tool that will be used as the background colour of the element. Most of the background images I deal with are gradients, so the colour I want to use is either the darkest or lightest colour of that gradient. Otherwise you often need to select the right combination of layers. I've already mentioned foreground layers that might need to be hidden. Other times they might need to be isolated. In Photoshop the issue is further complicated by the use of adjustment layers. Transparent gifs or pngs will need to be isolated altogether. Sometimes a background image will be larger than the dimensions of the containing element so the final thing you'd want to do is toggle a layer mask to get the whole image. This is the routine I tend to follow when using PS 9: 1) Toggle visibility of layers and masks until I can make a selection of the area I need to save. 2) Select area with marquee tool. Can be very annoying when zoomed in because selection always overshoots when I scroll. PS does not share Gimp's sensitivity when zoomed in. 3) Copy visible. Gimp should probably have a short cut key bound to this operation as it is always required. 4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. The only editing I ever need to do here is convert background to transparency. 5) Save for web. Compare compressed images against original. Adjust for best compromise of size and quality then save. With a save *selection* for web feature, steps 3) and 4) could probably be omitted altogether for most of the time. Step 5) is often made cumbersome by the fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in preferences (maybe it can and I don't know about it!). It's getting late so I'll leave it there. I think I may follow this email up with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature. Regards, Davidm --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
peter sikking wrote: We do imagine that a set of website graphics pieces gets _produced_ on a single canvas, and when everything works well together graphically, with a single 'cutting mask' all pieces are cut out and saved in the right web format, in a single action. I don't see how this can work in practice. I often need to hide or isolate layers before exporting the selection they affect and many selections are a very small part of an element's area (say 1 pixel wide) because they will be tiled by the browser as part of a background image. In other words, some manual work needs to be done with the majority of web graphics taken from a concept. Comparatively few images are cut out as they are. --- Scanned by M+ Guardian Messaging Firewall --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Looking for GIMP developers
Nancy Parsons wrote: Essentially, we want to be able to provide our users a free basic image manipulation application that does what they need it to do, without overwhelming them with additional functionality of GIMP. Are we talking quite a specific application here like crop and resize images? If so, perhaps it would be better to write it from scratch using the GEGL framework. Does that compile on windows yet? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
Sven Neumann wrote: In my opinion we should stick to this rule. It would make a lot of sense to make it easier for the user to locate our recommendations for binary packages. If user agent detection helps to remove one or two clicks, then I am fine with that. But if there's a download button on the front-page that directly instantiates the download, then we are effectively providing binary packages. It doesn't matter if the packages are hosted elsewhere. To the user it will appear as if we would provide the binaries. I think opening in a new window/tab would be a strong indication that the user is leaving the gimp site. Whether or not I agree with linking to direct downloads will depend a lot on how fool proof and reliable the said binary turns out to be. But if it does (as I'm sure it will) turn out to be solid, then I don't really see a problem. Otherwise, I agree that cutting down on clicks is still a good compromise. We already get Gimpshop users coming to the mailing lists asking for help and, far from being linked to, I don't think it's even mentioned on the website, so I'm not sure the support thing is really in issue. You could paint it in red letters on the front of the website and someone won't read them. At the end of the day, we can always remove the links if they turn out to cause a problem. Davidm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
Dear all, It was suggested on the gimp-web mailing list that we could provide direct links to binary packages for popular platforms such as Windows or Mac, based on user agent detection. The link would be provide from the home page - see http://next.gimp.org/ for a taster. I liked the proposal (presuming reliable packages for 2.4 are made available) and can provide the necessary code. Sven indicated that this idea has already been considered and rejected by the team and that I should bring it up for discussion here before proceeding any further. My argument for including one-click downloads would be ease-of-use primarily for Mac and Windows users; I don't see the benefit for Linux users as we would probably want to install stable Gimp through our package managers. Please note that the proposal is not necessarily for hosting binaries on the gimp website but for providing deep links to the binaries from the website. If anyone has any issues with this proposal please raise them here. If I don't get any replies to this post I'll presume there are no objections. :) Regards, David Marrs ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
Akkana Peck wrote: Maybe that's the intent -- to set up a gauntlet that weeds out any potential participants who might be lazy or thin skinned. If so, no problem. But if you actually want lots of new participants, then how other people perceive the project matters. I don't think more automatically equates to better. It's important to discourage laziness. I'm happy enough if this discourages the lazy. One of the things that attracts me to this project is the level of attention to detail and enthusiasm from its contributors. Is there a FAQ URL? There's nothing linked from the top level of gimp.org. The developer faq is at http://developer.gimp.org/faq.html , linked from the menu. And the FAQ doesn't have anything on the language(s) used to write GIMP. If I write the answer, it'll be why don't you download the sources and check for yourself? :) Seriously, that's the best answer one can give. A contributor will need to do this anyway, the curious should be encouraged and for anyone else, the answer is irrelevant. Except I'm hesitant to run off and register for the wiki so that I can add it, given that it's not linked from the main GIMP site, no one refers to it and the page itself discourages anyone from using it. Then the situation is unlikely to be improved. The out-of-date disclaimer should probably be left up until at least one of the veterans reviews the Q/As. The majority of the FAQ is up-to-date, though. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
Michael Schumacher wrote: We do have a list etiquette at http://www.gimp.org/mail_lists.html. I'd like to suggest that it is moved above the mailing lists, maybe it will be read more often then. I recently submitted a patch to the gimp-web list addressing this page. I added a link to the etiquette section below. I considered moving the etiquette section above the mailing lists but didn't want to put the page's primary information at the bottom! I also added a reference to the FAQ in the wiki. Maybe we should advertise it a bit more - standard gimp.org message footers, anyone? I think this is a very good idea. We should also link to the FAQ directly. We could also utilise the monthly list subscription reminder. In addition, I think that the list etiquette should point to the smart questions guide: http://www.catb.org/~esr/faqs/smart-questions.html Yes, I know that some think that this document is rude, but it has been incredibly useful for me. I always go back and read it when I find myself asking too many simple questions per time frame. I think that it's going to seriously put off anyone who's still not adjusted to free software culture. I'd much rather we have our own version that concisely and sympathetically addresses the same points. It could go on the mail_lists.html page. I thought I'd included something already in the patch, but it looks like I forgot about it. Davidm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Sven Neumann wrote: Wouldn't it be easier if you could quickly zoom in (and back out again to the previous zoom level) without having to open a new view for this? In the SVN version you can already revert to previous zoom level. What's the point of doing this in a separate window? Sorry for such a late reply. I like to use a different view to make precision adjustments because it means that I can have both scales visible simultaneously and can see how my changes look at normal scale while I'm making them. Davidm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools
Alpár Jüttner wrote: On Wed, 2007-03-14 at 20:52 +0100, Michael Natterer wrote: On Wed, 2007-03-14 at 12:47 -0700, Federico Alcantara wrote: Hi I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it? What about downloading it and checking yourself? IMHO, refraining from posts like this could greatly improve the atmosphere of this list. Looks like a reasonable answer to me, given the nature of the question. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer Groups
jEsuSdA wrote: My question is why and when Gimp will include LAYER GROUPS or FOLDERS (more useful)? See http://bugzilla.gnome.org/show_bug.cgi?id=86337 for the current situation. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
