[Gimp-developer] ANNOUNCE: GIMP 2.4.3
GIMP 2.4.3 is another bug-fix release in the stable 2.4 series. The source code can be downloaded from ftp.gimp.org. Binary packages are expected to become available over the next days. Changes in GIMP 2.4.3 = - avoid filename encoding problems in the WMF import plug-in (bug #499329) - fixed horizontal flipping of linked layers (bug #499161) - raised the priority of the display idle renderer to improve performance on Win32 (bug #499150) - fixed a missing update in the Lighting plug-in UI (bug #500317) - fixed a potential crash in the projection code (bug #500178) - fixed a minor Makefile issue (bug #500826) - removed some pointless warnings from the JPEG and TIFF load plug-ins - fixed size calculation for the image size warning dialog (bug #329468) - fixed loading of tool options for the rectangle tools (bug #498948) - push/pop a context in the Fog filter - fixed potential crashes in the Python binding - corrected grid drawing with non-integer spacing (bug #502374) - fixed grid snapping for coordinates less than the grid offset - made the healing brush work properly when dragged (bug #492575) - update tool state when a device change happens (bug #493176) - improved validation of strings sent over the wire (bug #498207) - fixed integer check in Script-Fu (bug #498207) - fixed potential out-of-memory problem in Script-Fu - fixed compilation on msys/mingw (bug #503124) - fixed localisation of Python plug-ins on Win32 (bug #502506) - translation updates (ca, cs, de, gl, it, ko, lt, sv, uk) Contributors: Jesper de Jong, Bill Skaggs, Michael Natterer, Sven Neumann, Martin Nordholts, Kevin Cozens, Tor Lillqvist. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
On Dec 17, 2007 10:32 AM, Sven Neumann wrote: As you already noted, this plug-in does not have much use for the casual user. Quite in opposite. Edge detection is one of the steps to make sky not look pale on photos ;-) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Some changes to the Edge plug-in
4) Removed the wrap-style radio buttons from the interface [...] This was a little bit controversial. Let me add that as far as I can see, it was a mistake to create these options in the first place. The idea behind the Wrap option was to let a user make tileable patterns, but it will actually have the opposite effect, by almost always drawing an edge at the border of the selection. I don't believe that anything except Smear is actually useful. Certainly showing users a set of choices labeled Wrap, Smear, and Black must be a bad thing to do -- even for sophisticated users. Please, don't remove the Wrap and Smear options, because it are useful (tileable patterns is a example). Removing the functionality of GIMP isn't usability. You can put them under a label named border options like the convolution matrix plug-in. Sorry if my English is poor. __ ¿Chef por primera vez? Sé un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
From: Csar Rolln [EMAIL PROTECTED] Please, don't remove the Wrap and Smear options, because it are useful (tileable patterns is a example). Removing the functionality of GIMP isn't usability. As I tried to explain, Wrap is not useful with edge detection. It is very useful with blurring, because it makes opposite edges look similar. With edge detection, all it does is to cause an edge to be drawn at the border of the selection -- an ugly, uneven edge in the great majority of cases. For tiling, the goal is to *avoid* making the border of the selection visible. I think you probably have never actually tried to use the Edge plug-in in this way, or you would have seen this for yourself. -- Bill___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
Sven wrote: You have a point here. But you also need to look at the costs of renaming a menu item. The documentation needs to change and users need to learn the new name. With the amount of plug-ins that we have it is rather difficult to keep track of changes so IMO we should try to avoid them. I don't agree. I think that many changes are needed, and that the way to make things simple for documentation writers is to do them quickly and coherently. The thing that is *really* difficult for doc writers is to document things that they don't understand, or that have bad interfaces. I believe, and I know that Peter believes, that the current collection of filters is an incoherent mess, assembled without any underlying concept of usefulness. Are we doomed to live with this forever? I am only an average programmer, and there are many things about GIMP that I don't understand, but I *am* an expert on image processing. I have a pretty good understanding of algorithms and their advantages and disadvantages -- I can tell you, for example, why Gaussian blur is much faster than Selective Gaussian Blur, and what will go wrong if you try to apply the same speed-up trick to Selective Gaussian Blur. I know the difference between the Sobel and Laplace algorithms for edge detection. I can tell you why Lighting Effects creates ugly artifacts on the pixel scale, and how the algorithm should be changed to fix this. And so on. As an expert, I have a pretty good sense of which techniques are useful, both for experts and ordinary users, and what it takes to use them. I can tell you, for example, that it is quite wrong to say that edge detection is only useful for image processing experts. It is essential for all kinds of artistic effects: just try putting an edge-detect layer on top of an image, and playing with layer mode and opacity, and you will quickly get a sense of the possibilities. So I have a pretty coherent vision of which filters are useful for which tasks, and what sort of interface a user needs in order to make use of them. I feel that, given a free hand, I would be able very rapidly to turn GIMP's filter collection into something that the great majority of users, both experts and non-experts, would be much happier with. I wouldn't get everything right, of course, but I could make it a lot better. The frustrating thing is that there seems to be no way to move in that direction. Any suggestion for change is met with, please raise this question on the developer's list, which simply means no, because it is easy to see that topics raised on the developers list never lead to decisions. In any case, as Peter has pointed out, discussing each individual change separately is a bad approach, because it is impossible for people to understand the coherent vision that the changes are directed toward. This can be discussed. But going ahead and doing the change before it is being discussed is not acceptable. That simply means that no change can ever be made. This is really the heart of the problem. Fixing it doesn't mean ignoring people's opinions, it means having some way to override opinions that are uninformed and arrive at a decision that can be implemented. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
Hi, On Mon, 2007-12-17 at 20:21 +, William Skaggs wrote: As I tried to explain, Wrap is not useful with edge detection. It is very useful with blurring, because it makes opposite edges look similar. With edge detection, all it does is to cause an edge to be drawn at the border of the selection If it actually does that, then the implementation is buggy. Bill, please revert all your changes to the Edge plug-in. When that that has happened, we can look at the plug-in again, isolate its problems and try to fix them. When this development cycle started I said that I don't want to see any changes in SVN that haven't been announced and discussed beforehand. I was serious about that and I am not willing to accept that this policy is broken. I know that this can be annoying but I don't see how we can get 2.6 done in time otherwise. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
William Skaggs wrote: So I have a pretty coherent vision of which filters are useful for which tasks, and what sort of interface a user needs in order to make use of them. I feel that, given a free hand, I would be able very rapidly to turn GIMP's filter collection into something that the great majority of users, both experts and non-experts, would be much happier with. I wouldn't get everything right, of course, but I could make it a lot better. And you do feel that the way to do this is to just commit things, and everyone else has to keep up with the changes without knowing what others are to be expected, and if something isn't right, we'll just have to revert it? Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
Hi, On Mon, 2007-12-17 at 20:51 +, William Skaggs wrote: You have a point here. But you also need to look at the costs of renaming a menu item. The documentation needs to change and users need to learn the new name. With the amount of plug-ins that we have it is rather difficult to keep track of changes so IMO we should try to avoid them. I don't agree. I think that many changes are needed, and that the way to make things simple for documentation writers is to do them quickly and coherently. The thing that is *really* difficult for doc writers is to document things that they don't understand, or that have bad interfaces. I believe, and I know that Peter believes, that the current collection of filters is an incoherent mess, assembled without any underlying concept of usefulness. Are we doomed to live with this forever? Of course not. But I don't see how changing a perhaps badly chosen menu name to something that is as arbitrary and meaningless is going to help anyone. The only thing it does is causing confusion among our users. They will ask themselves why we keep changing the names of filters without any good reason. The frustrating thing is that there seems to be no way to move in that direction. Any suggestion for change is met with, please raise this question on the developer's list, which simply means no, because it is easy to see that topics raised on the developers list never lead to decisions. If no discussion happens, then you can take that as consensus that what you proposed is fine and that noone will object to see this change being made in SVN. In any case, as Peter has pointed out, discussing each individual change separately is a bad approach, because it is impossible for people to understand the coherent vision that the changes are directed toward. Perhaps. But just going ahead and doing individual changes on your own without even letting us know that you see yourself on a greater mission is definitely not the way to go. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
Sven Neumann wrote: Moin, I would like to propose another project. Whether we want this for 2.6 or later pretty much depends on whether we find someone who wants to work on this. But I think we absolutely need this if we want to improve our user interface. What I am talking about is size entries. Widgets that allow the user to specify a size either in pixels, physical units or relative to some other size. Such widgets usually show up in groups and the relationship between them needs to be considered as well. We currently have a widget for this and it is (a) cumbersome and error-prone to use from a developer point of view (b) cumbersome to use from a user point of view (c) ugly and needlessly large It would be great if we could develop something to replace all our size entries. We want something that is flexible enough to cover the complex cases (see for example the Print Size dialog or the SVG import plug-in), but it should still be straight-forward to use for the simple case. We definitely need an architecture here that follows a model-view concept. Code that deals with changes to sizes shouldn't have to care about the widget that the user actually deals with. At some point I have experimented with something into this direction. The result is GimpUnitStore and GimpUnitComboBox as found in the app/widgets directory. Definitely far from what we need, but perhaps looking at this code can give some ideas about how one could tackle the problem. On the user interface side we would want a variety of widgets that can be used with the size models. Scales/sliders should be supported as well as spin-buttons with unit menus and entries that allow the user to input text such as 4.5 cm. I think it is important to first get a very good idea of what the requirements are. It would be good to have a list of use cases and a pretty good specification of the user interface. Then we can think about a model to cover this. Sven Hi I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool. Wouldn't some kind of hierarchical model-view be useful here? One would associate a unit-dependant widget with a list of unit-models(model as in model-view) in a hierarchical manner, where the bottom unit-model would be the unit-model in use for the image worked on. Let's discuss this with the Size-entries in the Rectangle Select Tool Options as an example of how this hierarchy could be set up. The Width entry would be associated with unit-models in the following order: 1. its own unit-model 2. the other (Height) entry unit-model 3. The image unit-model. This would mean that if no units were specified in the Rectangle Tool Options, the unit for the Width-entry would be the unit of the unit-model of the the image. If the Width-entry contains 100 and the image unit is mm, changing the image unit to cm would change the Width-entry to contain 10. Maybe even writing out 10 cm would make sense. If the user then wrote 3 m (meters) in the Height entry, the Width entry would start to use the unit of the Height-entry instead since that is closer to it in the unit-model hierarchy, so it would display 0.01m. Finally the user could write something like 0.01m in inches in the Width entry and the Width entry would then activate it's own unit-model and use inches instead. Erasing the unit in the Width unit could deactivate its own unit-model and it would fall back on using the unit-model of the Height entry if that would be active, otherwise use the unit-model of the image. Now, the UI and coding details here are very fuzzy, and the exemplified unit-model hierarchy is questionable. I just wanted to throw the idea of hierarchy-based unit-models onto the list and maybe get some feedback on it. This would need a lot more thought, and my current plan is to put more thought into this whenever I have some GIMP hacking time over. The general approach would be to create independent families of classes of which objects then could be combined in different ways to create the desired widgets and families of widgets with the desired behavior. - Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
Martin Nordholts ([EMAIL PROTECTED]) wrote: I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool. I have a prototypeish parser running here, specified with yacc: $ ./parseunit 2m + 3in Result: 2.076200 m 40cm / 2in Result: 7.874000 2m * 3ft syntax error 2m * 3ft / 2in Ergebnis: 35.998171 m It kind of tries to track the dimension of the value entered and currently bails out for dimensions 2. Not very reliable but it might help for a good start of the parser. If you're curious I'll put the code online somewhere. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
Michael Schumacher wrote: And you do feel that the way to do this is to just commit things, and everyone else has to keep up with the changes without knowing what others are to be expected, and if something isn't right, we'll just have to revert it? No! The way I did it was broken. But the whole process is broken. It is impossible to fix the interface if every tiny change can be vetoed by any random person. The question is, how to find a process that actually allows change to occur. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
Simon Budig wrote: Martin Nordholts ([EMAIL PROTECTED]) wrote: I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool. I have a prototypeish parser running here, specified with yacc: If you're curious I'll put the code online somewhere. Please do, it would be useful to have a look at it. Thanks, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some changes to the Edge plug-in
Hi, On Tue, 2007-12-18 at 00:23 +, William Skaggs wrote: No! The way I did it was broken. But the whole process is broken. It is impossible to fix the interface if every tiny change can be vetoed by any random person. The question is, how to find a process that actually allows change to occur. I would actually rather call that what you did random changes. I am quite confident that if we had a look at the plug-ins and isolated their usability problems, then we could find solutions that we can agree on. One thing that would help is to improve consistency in the plug-in user interfaces. For example, if there are several plug-ins that need to have a user interface for the border behavior, then this part of the user interface should look and feel the same in all those plug-ins. That would help our users more than if we removed this part of the user interface on the assumption that it is not useful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
