Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On Wednesday 24 March 2010, saulgo...@flashingtwelve.brickfilms.com wrote: * no mnemonics are shown when menus are opened with the mouse * interacting with the menus via the keyboard (opening a menu with keyboard shortcut, or navigating with arrow keys or similar) will make mnemonics visible * mnemonics which cannot be activated are not shown; this includes insensitive controls * moving the mouse over a non-activatable menu item does not change which mnemonics can be activated This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? By seeing them when using the menu with the mouse - this is a sub conscious learning process going on, you see it the first time, the second time, the third you don't use the mouse but the keyboard because you remembered that this function is available via a shortcut without having to resort to the mouse. With this enabled you'll never find out and thus you have to replace an automatic sub conscious process with a conscious effort - something most people will not endeavor to do and is for the most part less effective. Thank you, GTK+ team. Yes, thank you for getting rid of a valuable function in a very unelegant way and making life harder for people to understand how to interact with complicated software! I just hope this can be deactivated even in a few years time, for the time being the setting gtk-auto-mnemonics = 0 will be added permanently to my ~/.gtkrc-2.0 - if that should ever disappear I'll phase out any application that uses GTK - even if that means switching to windows for my photo editing needs. But digikam is reaching maturity, maybe it's there when this bonkers development becomes standard, I'm already on the verge of giving up on the GIMP as it can't remember the last settings in many dialogs after a restart or even from one dialog invocation to the next - I'm getting fed up to reenter for example my copyright comment over and over even if I don't leave the GIMP when saving the edited image for publication. Little things like this menu change may push me over the edge and make me - and many of my friends, which I have supported over the years when editing images with the GIMP - dump it for good... regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Wednesday 24 March 2010, Sven Neumann wrote: If you don't consider a plug-in additional software, then you can already do that today. Sorry but I would consider this solution quite inadequate as higher color depths account for much of the leeway expected from using RAW image formats in digital cameras... The difference with a GEGL-enabled GIMP is that you can then work in the higher color-depths that the RAW format offers. Which only means that a GEGL enabled GIMP with appropriate input filters is the only way forward in this respect. regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The future of GEGL and Gimp: Questions
On Wednesday 24 March 2010, Sven Neumann wrote: Well, if you ever looked at the UFRaw Import Plug-in, you'd know that it gives you a lot of control over how the conversion to 8 bit is done. So you already get most of the benefits of the RAW format. It's just somewhat uncomfortable that you have to do all the color and exposure correction at the import step. The problem is that I recently read about the scaling problems in any non- linear colour space and as a result have tried scaling some of my images in a 16 bit linear colour space - with stunning results. So UFRaw helps with the first problem of doing the conversion but 8 bit GIMP is messing up things later in the editing process... For the moment I am living with the results but now knowing how much better they can look without having to compensate late in the editing process having a workflow which would start with the 14 bit depth my camera provides per colour channel and never drops to a non linear colour space before the final save to JPEG would be preferred and I hope that a GEGL enabled GIMP will do so in the forseable future... regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On Wednesday 24 March 2010, Alexandre Prokoudine wrote: On 3/24/10, Karl Günter Wünsch wrote: This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? This is default behaviour on Windows. Which is the first thing I disable on any Windows installation I do and the users are happy about that. regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
On Wednesday 21 October 2009, Ilya Zakharevich wrote: Good to know; so let me refine: is there ANYTHING in the move to single window which would not be achieved by a) restricting the maximal size of image window to the gap between two toolboxes; and b) making z-order changes syncronized between the main window and toolboxes? IMHO the move to a single image window with dockables would solve quite a lot of interoperability problems. For example there are plenty of broken window managers out there. Relying on them (WM developers) getting it right in the end for the GIMP is proving to be a long wait. As desktop environments go the window managers that work with the GIMP as intended tend OTOH to be the ones that don't play well with KDE for example (if you even have the choice, which you haven't really in KDE4). Oh and windows is a beast that isn't handled easily as well - the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure - which places the problem either into the GTK+ ballpark (a vital library once created to suit GIMP but which now is driven by people with their own development goals which don't necessarily match the GIMP requirements any longer) or forces the GIMP developers to avoid this area in the long run. Besides that there are things like split layer views that I'd like to see - for example editing a layer mask side by side the image area it belongs to which IMHO are next to impossible with the current multi window arrangement. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
On Sunday 20 September 2009, peter sikking wrote: so for everybody who feels this: why do you need windows-in-window or work-side-by-side? First of all a great idea to get some more feedback. I have one thing for which I had wished for side by side windows recently: When working on the layer mask of an image. There I would have very much liked to have the background layer, the top level layer and it's layer mask each side by side so that I could have judged where I was changing something and which effect it has immediately. It would have saved the me endless number of switches between the different views I needed to complete my editing... This may be something different than what you are proposing but if at all possible within the framework to have different layers and or layer masks in side by side windows would IMHO help me much! regards Karl Günter ___ 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 Monday 07 September 2009, Martin Nordholts wrote: On 09/07/2009 07:07 PM, Shashwat wrote: Whatever you guys do. Please make it work with KDE kwin windows manager. The current UI doesn't work with Kwin or Compiz. You'll have to file a bug report with those window managers, there's nothing GIMP can sensibly do about them not supporting the utility window hint in a sane way You mean something like: http://bugs.kde.org/show_bug.cgi?id=177025 http://bugs.kde.org/show_bug.cgi?id=178074 If you know of other people complaining, maybe we may sway the developers of KDE to do something about it by combining the reports. I have little hope though... regards Karl Günter ___ 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 Saturday 05 September 2009, Martin Nordholts wrote: A single-window mode would also turn 2.8 into a remarkable release, with both layer-groups and a single-window mode, none of which were originally planned for 2.8. Why not have it both ways - by simply making the toolboxes dockable... That's the way many programs handle things like that and it's working like a charm. IMHO this would sort out any complaints about a change in usability as the undocked toolboxes could behave as they would currently... regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Customizable Toolbar
On Monday 16 June 2008, peter sikking wrote: Simply said: a toolbar like this does not fit the UI of GIMP. What a lame excuse to exclude a time saver and great help to occasional users of the GIMP... Not everyone wants to cram his brain full of key shortcuts! Why not have the toolbar placeable at the side or top by simply dragging and dropping it at apropiate toolbar docks? That should be a simple task given that every good toolkit offers such functionality out of the box! -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Customizable Toolbar
On Monday 16 June 2008, you wrote: My hi-end definition boild down to streamlined UI for professionals. Much of the streamlined UI for the professionals can be had if the toolbar - as proposed - would be configurable in both position (there is no reason why it should not be vertically alignable at the left or right hand side of the window) and content. Then it would serve multiple purposes in that it allows quick access to often used functions (individually for the specific user) and allow for an easier learning curve (if preconfigured to have a set of common functions that a new user might want to have access to in the beginning). One thing bothers me even more now that you are insisting on this strealiming: Why isn't this applied to the whole set of plugins and tools? One thing I'd expect from any high quality software product is that settings I have chosen once are keeping their value even if the program restarted. In GIMP this only applies to a few tools but important things like all the filters are all falling back to their inadaequate presets every time the GIMP is started. Even if I have the option to save settings as default (such as in the JPEG save dialog) some settings of the set are excluded for reasons that are neither obvious nor in any way discoverable from the UI - in the case of the JPEG save dialog it's the comment field, most of the time I want to give a set of images the same or only slightly varying comments but I have to externally keep a copy of what I want to set in this propery around as even between images this contents isn't kept! The proposed toolbar does not solve any real issue. I've been spending a lot of time talking to graphics software users of all levels (noob to pro) for past years and none of them ever requested it or had problems because of not having it (I explicitely asked them about it a number of time). Because it isn't an option at the time of the initial contact with the program most users will not miss it and make do without. Offer something well designed from the beginning and it will be used and if you then remove it it will be sorely missed. At least that is my experience as a software developer who has made his living off his designs for more than 15 years... I have always been proven wrong when I had to resort to the lame excuse: It's for the experienced in (insert field of expertise here that doesn't involve programming) This toolbar *might* be good for a classic MDI application. In CSDI application al it does is cluttering interface. And all the users I ever dealt with are very vocal about cluttered UI. And for those there could be the simple option to switch this toolbar off. But I'd wager a bet that many would like to have this toolbar around reflecting their most used tools, filters and options. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Customizable Toolbar
On Monday 16 June 2008, Tobias Jakobs wrote: There is never enogth space if it comes to the work with big photos. And as photos are usully in 4:3 and a lot of modern monitors are 16:10 the vertical space is more important. You assume too much. In fact the majority of photos that professionals and quality conscious amateurs (which seem to be the intended target group of users) are working on are originating in 3:2 and 2:3 aspect ratio as this is the main aspect ratio that current DSLR are working with... But final results may well be in all sorts of aspect ratios. The important thing is that vertical space is truly at a premium but there is no rule that a toolbar needs to be placed horizontally when in fact a toolbar works equally well when placed at either side of the image. If you then add a way to dock the toolbox to the image window we would have a very nice solution. Having the toolbox docked is one of the things that would render a toolbar redundant. So yes, this is a working solution that I would look forward to. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Friday 09 November 2007, Raphaël Quinet wrote: No, that's wrong. And that's one of the reasons why I want to remove this confusing question. The EXIF standard defines precisely the list of tags that must be updated and the list of tags that must be copied unchanged. Unfortunately, older GIMP versions were violating that standard by copying the whole EXIF block unmodified and this caused many problems, including images having the wrong orientation. If the current version behaves correctly in this regard (which I gather it is from your comments) then I am all in favour of dropping the dialog and always rotate the image accordingly. EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs. IPTC tags are not part of EXIF. They are a different set of tags that are stored in another JPEG APP marker. The ability to edit and save them may be included in GIMP 2.6. That would be very nice and is important for me and probably a whole host of people out there that rely on the IPTC tags. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Thursday 08 November 2007, Raphaël Quinet wrote: The problem is that the question is not interpreted correctly by most users, as can be seen by the other replies mentioning camera sensors that sometimes report the wrong orientation. It does NOT mean: allow me to decide if each image should be rotated. If you do not let GIMP display the image according to its EXIF orientation tag, then the image will not be rotated by GIMP but its orientation tag will not be modified either, So you suggest that the GIMP is changing the orientation tag when it is loading the image. What then happens if later I decide to rotate the image again manually? If you want to go there, you are opening up a whole new set of possible scenarios which will end up confusing users and other programs. I always understood the question so that I either want to ignore the rotation flag or not but that the EXIF would stay untouched, no matter what I decide there... EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plu g-in enhancements
On Sunday 04 November 2007, Sven Neumann wrote: Hi, On Fri, 2007-11-02 at 23:55 +0100, Raphaël Quinet wrote: * jpeg plug-in + remove the prompt for EXIF orientation: it should always be done IMO the current solution of asking and allowing the user to skip this question is preferred. It requires a user decision once, but at least it doesn't force something on the user that he might not want to be done. Yes, I like that as well. As there is no easy way to get back those question dialogs though, I refrained from making that automatic as sometimes the orientation sensor in my DSLR is fooled... The only problem is that it is rather difficult to discover how to change that decision later. Currently you need to edit parasiterc. We might want to find a solution for these Don't ask me again questions that can be used from all over the place. How about adding some preference setting for this kind of decision. That would be my first instinct if I were to look for a way to change my previous decision (that the dialog decsion has been transformed into a preference which I can find again in there somehow)... regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Friday 02 November 2007, Raphaël Quinet wrote: There are also some improvements for the JPEG plug-in. As I mentioned some time ago, I would like to hide the current quality slider among the advanced options, and replace it by a smaller selection of pre-defined quality levels. Sorry to disagree, the precise selection of quality really is one of the many areas where I would not like any dumbing down of the interface. This would mean that each and every time I have to save an image as JPEG I would have to switch to the advanced options as every site I post my images to has stringent restrictions on file size - which are enforced by an automatic resampling (which is to be avoided at all cost due to a severe loss in quality) if I don't adhere to these limits! Having preset quality settings really is no option, it is a major annoyance in Photoshop new users I spoke to always are struggling with! regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature desperately missed...
Hello, maybe now is the time to get around to finally getting all the filter settings saved when exiting the gimp? Every single time I edit pictures I am annoyed that filters like unsharp mask, selective gaussian blur, decor border or almost any other one of them is loosing the settings I made during the previous setting. A radius of 5 on unsharp mask for example is whoefully inadaequate. Unfortunately I can't get my head around the program paradigmas of GTK+ to be helpful as a developer otherwise I might have tackled this myself (I program exclusively C++ now)... But speaking as a daily user: this is the single most annoying lack of a feature of the GIMP. regards Karl Günter ___ 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
On Tuesday 21 August 2007, Michael Schumacher wrote: Should it be more easy than writing e.g. a plug-in in Python? How about having a C++ virutal interface which you only have to fill in with your own methods and GUI elements in a set dialog interface... I have several things that I really would like to try and would require a native compiled plugin. But since there is no sound C++ interface to the innards of the GIMP :-(... -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
On Tuesday 07 August 2007 07:43, Sven Neumann wrote: 349340 Alt behaves incorrectly for new rectangle/ellipse selecti... Should probably be looked at. We should get the interaction right for the 2.4 release and not change it later unless absolutely needed. I just stumbled across a similar issue with the latest version (at most a few days old, I'll update to the head later tonight (GMT) : If I select the whole image (pressing CTRL-A) and then I select a rectangle area out of that image with the rect selection tool the area does not replace the previous selection as it did previously - so that cropping to selection doesn't work. Only after trying to crop to selection you see what has happned: the selection seems to be both the whole image and the selected rectangle! -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rectangle select tool specification
On Thursday 10 August 2006 00:50, William Skaggs wrote: Rectangle Controls: An expander containing a set of spinbuttons and checkboxes used for specifying the shape of the rectangle numerically. There are checkboxes for fixed width, fixed height, and fixed aspect. If any of these are activated, then the number entered in the corresonding spinbutton will be used to set the relevant dimension of the rectangle, and will not be affected by any mouse actions. Please don't describe aspect ratio as a single float as this makes it impossible to quickly and intuitively enter aspect ratios such as 2:3, 3:2, 16:9, 9:16 without having a pocket calculator nearby. When using big selections then the current float entry with four digits precision is imprecise when describing certain aspect ratios (neither 0. or 0.6667 is correctly describing 2:3 aspect ratio). Either go back to the old tool there, which simply allowed any multiple of the height/width values set when aspect was fixed or provide two spinbuttons for the aspect to be entered properly without having the user calculate the aspect each an every time. regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please bring back the old rectangle selection...
On Tuesday 08 August 2006 10:00, Sven Neumann wrote: Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them. And now you are making assumptions. The flag only alters the behaviour by resulting in a crash when trying to read or write the properties... This probably is the result of not using the macros every other tool uses to register it's properties. If that were not bad enough, the usability is partially much worse than before. The new tools are not ready yet. We know that there are problems and it is nice that you took the time to point them out. But rest assured that we don't plan to release GIMP 2.4 with the selection tools in their current state. And if you had read the followups on this (partially in the cited bug reports) you would have noticed that I started to work with the developers to fix the problems - part of the patches originate from me. My whole rant here was the result of the lack of feedback to those bug reports, which since has been cleared as a bad timing because of the holiday season... -- regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is there a way to update the cursor position from within a tool?
On Friday 28 July 2006 11:30, [EMAIL PROTECTED] wrote: Quoting Karl Günter Wünsch [EMAIL PROTECTED]: That's why I would like to update the cursor position after all of the calculations are through to reflect the results. Are you saying that you wish the pointer to be forced to the calculated corner of a (aspect ratio) constrained mouse movement? If this is what you mean then I am almost certain this is contrary to the GNOME Human Interface Guidelines (http://developer.gnome.org/projects/gup/hig/1.0/index.html). What is so wrong in this case to have the cursor follow the only possible path that is within the constraints. Because if you don't then you end up with a pointer position that doesn't correspond to the current selection anymore. In this case we have a corner of an aspect constrained rectangle selected. Both x and y movements are allowed but as these two have to a strict relationship any movement by the user that doesn't follow this relationship (for every 3 pixels horizontally move 2 pixels vertically) will end up having the pointer and the corner being so far apart that the visual relationship between the pointer and the selection isn't aparent any more. I have found a partial solution to this problem yesterday evening (still some quirks to work out) but the problem basically is only reduced by the code that tries to keep the selection as close as possible to the pointer, there still are times when they end up virtually in different corners of the screen... -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: It's getting worse... Now I really want the old rect selection tool back!
I just stumbled across the next level in annoyance, resizing does only work when grabbing one of the horizontal delimiter lines, using the vertical delimiters seems to be blocked by some aspect ratio calcuations - Bug #348807. regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 19:21, Michael Natterer wrote: Instead of repeatedly ranting i want the old tool back you should realize that you are using something that is explicitely labeled unstable and in development. So be constructive, thus helping fixing these bugs, or use the stable 2.2 version. I am constructive in reporting the bugs. Fixing for me is impossible as the new rect selection tool is undocumented, the interface it uses is unlike any of the other tools from where I could take a hint or two on how to get started understanding it and on top of that there is the complete gibberish of code which implements the object orientation. If code like this is unstable or in development it needs to be labeled clearly as such and not simply toss out the old tried and tested. It could easily have been implemented alongside the old tool without loosing much. I am using (as in productive use) the development branch of GIMP because of certain recent developments I need as a photographer to get my pictures edited, but every time the rect selection tool is taking up more and more of my time because it is very important in my editing and isn't very well thought through. It's all bells and whistles (guide lines, resizing possible) but some of the base functionality the old one had has been broken badly. So my comment is basically one of desperation. I need the current CVS for some of the functionality but at the same time the new rect selection is close of driving me nuts. regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: It's getting worse... Now I really want the old rect selection tool back!
On Wednesday 26 July 2006 19:52, Michael Schumacher wrote: Karl Günter Wünsch wrote: The whole 2.3 branch is unstable and in development... I know, but wasn't the 2.3 branch to be a short lived one, leading quickly to a stable 2.4? And this is why you did file the bug reports. One of the things I can't understand is why you do double your work by posting the same information here twice (and in a way that is very hard to read, btw - please use empty lines to split your messages into paragraphs). I thought a line break would be sufficient to trigger a paragraph, duly noted and will change my posts apropiately. As to why I posted the information twice: There are two reasons, first of all I needed a safety vent for the problems these bugs cause me. And then please have a look at the date I posted the first bugs in my first rant, it's three weeks ago. Besides the first one being classified quickly as confirmed, nobody really looked at them. In my experience (in our company there is a similar bug reporting system) this means that noone cares, or anyone who cares overlooked the reports. With them being given more exposure through the mailing list I can at least now converse with people about what is to be expected of the tool and if my ideas are completely off the trolley - or if they have enough merit as to be classified as true bugs. If the latter is true (as it seems by the comments I now received on the bug reports) then I can at least continue to test the features and if I stumble across something that I classify as broken I can post another bug report. Of course I would rather fix these broken things myself (I am a seasoned software developer in both C and C++, earning my living as a developer) but there is no starting point in the documentation sources for the tool itself - so there is no way for me to get my hands dirty and change anything for the better - except for starting over with a similar but functioning tool as a starting point and trying to carry over as much functionality as possible. regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Please bring back the old rectangle selection...
I have tried to like the new one. I honestly did. But there are some things that make life really hard when you have to work within certain contraints. First of all the new one doesn't save it's options. That could be remedied but the amount of changes (I'm a C++ developer and really can't get my head around doing the way object orientation is done in the tool, the documentation for all the stuff that has to be done is lacking or isn't easy located - so I can't do it myself, I tried and failed) seem excessive as the gimprectangleoptions.c is the odd one out and uses a completely different way of storing it's properties to all the other tools - Bug #346683. If that were not bad enough, the usability is partially much worse than before. Let me explain: the old rectangle selection tool didn't have the bells and wistles but it was more straight forward if you wanted to keep the aspect ratio to say 3:2 when cropping. You simply entered 3 into the x-dimension, 2 into the y dimension and ticked fixed aspect. Now you have to enter 1.5 into the aspect ratio box and tick the check box next to it. But what if you want 3:2 aspect (for a vertical compositional crop)? Now you have to enter 0. into the aspect ratio, and you already are suffering a loss of precision (it's off by a few pixels if your image is sufficiently large, because it's not 0. it's 0.666). Even worse - calculator on standby - imagine you want to have 16:9 or 9:16 aspect ratio because you want to use the image in your own DVD production. The old style was simple (took a bit getting used to but was workable), the new style of setting the aspect ratio is a pain in the proverbial... - Feature request/Usability Bug #346684. Then try to select some rectangular areas because you might want to make them partially transparent or only sharpen the remainder of the area. Now the new form of selection with the last selected area still visible is getting annoying to say the least. I cannot tell how often I find myself cursing at the new rectangle selection when selecting multiple rectangle areas to join them into a larger compound area because the last area stays visible and sometimes - I can't really pinpoint when - keeps me from selecting the next area. If I could pinpoint the culprit operation then I would file a bug. Then there are some usability issues with the way the last selected area is shown as stippled outline when you start resizing the area, there seems to be a random element to when the selection is supposed to be finished and what is supposed to be visualized - Bug #347945. My humble (well after this rant) request would be to resurrect the old rectangle selection tool and have the new one reworked so that the next milestone doesn't have to be postponed because of this (for me the first one is a true blocker, the other ones are very annoying to say the least). regards Karl Günter Wünsch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
