Re: [Gimp-developer] no-image-open redux
Has anybody come to a consensus about whether or not the no-image dialog should persist after an image is opened? Actually, yes, the mere fact that it is called a no-image window means that a consensus has been reached. Your points are reasonable, but when there are several reasonable alternatives, one has to make a decision between them at some point, and the decision we are working with at the moment is to use a no-image window. For what it's worth, even after an image has been opened, it will continue to be possible to open more images by dropping icons on the toolbox, just like you can do now. Also for what it's worth, I've been a bit worried about including a toolbar like the one I showed, precisely because users who find it useful would want to have it available even after an image has been opened. 4) The tips can be disabled. I suppose that's good, but all that space being used for the tip *could* be used for a more efficient start screen. For instance, the most recent images could be shown in a list instead of hidden in a drop-down. There are two problems with this. First, it creates visual clutter. Second, some people won't *want* their most recently edited images to be shown every time they start Gimp, for reasons that will probably occur to you. Slightly off-topic: I understand that people want to find a way to show tips in an unobtrusive way, but maybe we can take a hint (no pun intended) from video games here: the loading screen would be a great place for tips, since the user has nothing to do but twiddle their thumbs during that time anyway. I don't think this is off-topic at all. I thought about this a good deal, and it's a great idea in principle, but it won't work for the current set of tips: many of them are too long and complicated to be presented that way. If the tips were simplified, my enthusiasm for this would be a lot higher. Thanks for your input, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Size entry widgets could use some simple math (from Bug: 76616)
From: Fredrik Alstromer [EMAIL PROTECTED] As requested, I'm moving this discussion to the mailing list... for the history, see the bugzilla entry 76616. I don't have anything to say about how this should work, but I'd like to make some suggestions about the approach to development. Mostly it should be possible to do this in a modular way -- evaluating expressions doesn't really have anything to do with the details of size entries. So I suggest your effort should go into writing a function that looks like gchar *gimp_math_expr_parse (info, expression) where info is a structure containing any information you need to do the parsing (resolution, image dimensions, whatever), and expression is the string entered by the user. The code could go into new .c/.h files either in libgimpwidgets or perhaps libgimpmath. That way, the size entry code can simply call the function to evaluate the string before using it. It would perhaps be possible to set up the infrastructure for this in the trunk development branch, that is, to create the files and have the size entry code call the evaluation function, but with the function initially just returning expression unchanged. If it were done this way, it would be possible for you to work without worrying much about changes in the size entry code -- which, as Sven has pointed out, needs improvement in several respects. Please don't take the details here too seriously. The function name and form were written on the fly, without any serious thought. The only real point is that the code should be factored. (And if I'm saying things that you had already planned to do, I apologize, but it didn't come through clearly.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tasks list
From: Sven Neumann [EMAIL PROTECTED] Well, we have that for 2.6. We didn't put publish it. But we discussed these points and agreed on a roadmap for 2.6. The question is, do we gain anything if we published such a roadmap officially? I am afraid that the only result would be that people will expect us to stick to the release date no matter how far the essential features are developed. And at the same time they will expect us to implement all the essential features. I'm not sure it needs to be published officially, but it's at least essential for Peter to have a complete picture. I think it would also be good if people who follow this list could have a general picture of what is expected for the current cycle, even if no promises are made. I think it would be a lot more useful if we would just collect a list of tasks that we consider important, without sticking them into a particular release time-frame. That will make it easier for new developers to participate. And that's what's most important. That leaves the UI team with no way of influencing development, and no way to know what they should be working on. If the idea is to have a specification before something is implemented, then the process needs to have more structure. I agree with you that there is no sense in creating rigid roadmaps extending far into the future. I think, though, that the planning process should be a little more public (at least public enough for the UI team and potential new developers to be able to look at the current state), and a little more forward-looking. Everybody should realize that not all plans that are made will be executed, but if we want coordination between the UI team and developers, there must be an ability to create definite plans. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tasks list
From: Sven Neumann [EMAIL PROTECTED] Perhaps if we could first decide what the purpose of the roadmap/task list should be. I tried to raise that question when we started with this topic. But no one ever attempted to answer it. So before we start this again, can we have this discussion, please. That would probably help to get us somewhere. A roadmap should be thought of as a component of a full development strategy. In my view, each release cycle should have a set of target dates, and a set of essential accomplishments. The target dates are for soft freeze, hard freeze, and release. The accomplishments are the things that *need* to be done to have a release. For the current cycle, for example, I see the essential accomplishments as: 1) stabilize the new gegl code 2) merge the toolbox and image menus 3) change to a Cairo-based canvas That doesn't mean that nothing else can be done, just that nothing else will be allowed to shift the target dates. The main value of a roadmap, in this context, is in planning for future release cycles. Thus, the roadmapping that should be going on now is for 2.8 and beyond, not for 2.6. With a good roadmap, the UI team can work on specifications ahead of time, and developers can have at least some code ready to commit at the start of the release cycle. There actually *was* a roadmap for 2.6 already during the 2.4 cycle, but it was never made public. The fact that a roadmap existed can be seen in that (1) the first gegl work began immediately after branching for 2.5, (2) code had already been written for the merged menus, and (3) the first experiments with Cairo started immediately after branching. What is needed is for this sort of roadmap to be published, instead of just existing in the heads of people who read the ChangeLog every day and hang out all the time in #gimp. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
From: Sven Neumann [EMAIL PROTECTED] 8. improve the text tool Evaluation: Most of the points mentioned here would be relatively simple to implement. One of them -- the ability to have multiple text items within a single layer -- might not be simple, and it should be considered whether this would better be dealt with by implementing layer groups. Pango allows to change fonts and style in the same PangoLayout, so I don't see how this could be particularly difficult to implement. The idea I was responding to was, as I understood it, basically to have multiple PangoLayouts within the same layer. Even that would probably not be so difficult to implement, but I think it would probably cause more harm than good. I don't see a WiW user interface coming to GIMP, ever. This is so backwards, I can't even believe that it is still being discussed. While this is an often requested feature, almost all of us, including the UI team, seem to aggree that there are better solutions to this problem. So let's concentrate on them and migrate the GIMP user interface towards our vision which is an image-centred user interface without a pointless gray backdrop. This attitude strikes me as too rigid. Adding a WiW interface would be very unintrusive -- almost the only changes in existing code would be to make docks and images into children rather than toplevels. (There would also be some changes in menu code and sessioninfo handling.) So if somebody came along who wanted to work on it, I don't see any good reason for forbidding it. I understand the fear of confusing users, or of creating maintenance problems, but it does not seem to me that those worries are sufficient in this case. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] task list
From: Sven Neumann [EMAIL PROTECTED] I don't think we want to publish something and call it a roadmap. But we had the plan to make a list of important tasks that outline where GIMP is heading and what we consider important to work on. Since there doesn't seem to be enough interest among the developers and other people reading this list, we still don't have such a list. I believe there is quite a bit of interest. Here is my current understanding of the long term goal list. This is probably incomplete and no doubt incoherent in parts. I have tried to put the most important things first, but don't take the order too seriously. A few of these things are already under way, and expected to be finished for 2.6, but I include them because they are not finished yet. * Move to a Gegl-based image structure, in which an image is represented as a tree of gegl nodes. This is a prerequisite for many other changes, including: ** Implement layer groups. ** Implement Layer effects. ** Support 16 bit layers. ** Support clipping paths. ** Support CMYK internally. * Make canvas drawing use Cairo, and consequently not use XOR drawing. This will allow great improvements in the quality of tool-interface drawing. * Construct an optional MDI version of the gui. * Change the PDB so that plug-ins can be made into GObjects, with their parameters as object properties. This will make it possible to save and restore settings in a generic way. * Allow libgimp or something like it to be linked with the core, and implement actions and tool operations by means of it, so that it will be possible to record and play macros. * Enhance the text tool: ** Support basic text transformations. ** Properly support text along a path. ** Add a text layer api. ** Support on-canvas text editing. ** Improve the font selector widget. * Implement a tagging system to organize resources such as brushes, gradients, patterns, and palettes. * Make it so that sequences of transformations on a layer do not cause a steady buildup of error. (Yes, this is possible, because any sequence of affine transformations can be reduced to a single affine transformation.) * Reorganize tools so that the toolbox is less crowded. ** Merge the transform tools into a single tool, with the type of transformation as a tool option. * Merge the toolbox menu contents into the image menu, and get rid of the toolbox menu. * Implement vector layers, starting with lines, rectangles, and ellipses, then perhaps moving to full path layers. * Find alternatives to the floating selection when pasting. * Make it possible to apply filters using a brush. * Add a save for web feature. * Complete support for metadata. * Add ability to lock a layer/drawable. * Implement autsaving. * Make Iwarp into a tool. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
From: peter sikking [EMAIL PROTECTED] I see the list below of what needs input and they are all worthy problems to solve. But they look to be in part different problems than the ones discussed for the roadmap two months ago. There lies the problem. I will give direction for the small ones on the list below that have bug numbers. I am still putting out small fires. ^} the big spec ones need to be roadmapped to get done... There are two big things that are definitely roadmapped for 2.6 and need specifications from the UI team. The first is the merged menus. This was done at the suggestion of the UI team. Some infrastructure has already been created, but it is not possible to go farther without a specification -- or, to put it differently, it is not possible to go farther without making assumptions about what the specification will be, which Sven thinks would be hostile to the UI team. The other critical thing (less critical because it is not quite ready to be implemented) is that the canvas drawing will be moved to Cairo, which will give a lot more freedom to make the tool interface look better. It will soon be possible to improve the interface for the crop and rectangle-select tools, among others, and it would be very helpful to have a specification for what the interface should look like as soon as the Cairo-drawing is in place. In general there seems to be a misunderstanding here. I believe Sven is reluctant to definitely roadmap anything that will affect the interface without first getting input from the UI team. But it seems that the UI team is reluctant to create a specification until something is definitely roadmapped. I believe that the only way around this impasse is for both the roadmapping and the UI specification to be done interactively, by means of ongoing discussion between the UI team and the developers. The fault is not all just on one side. Peter in his LGM presentation has given a list of what he considers the top 10 priorities (linked from http://www.mmiworks.net/eng/publications/2007/05/ ), but there is no way he can know how easy/hard each of them is to implement, and it is up to the developers to give feedback. I will make a start on this in the following email message. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] input from the UI team needed
As promised in my previous email, I would like to look at the priorities that Peter presented in his LGM talk (at which I was not present), and try to give a sense of my impression of how much work each one involves. You can find a web version of Peter's talk at http://www.mmiworks.net/eng/publications/2007/05/ 10. better printing support Evaluation: It wouldn't be very hard to improve the page layout capabilities in Gimp. Most of the things mentioned in the talk should be straightforward to implement. 9. painting with brushes Evaluation: Although this is listed as a priority, the conclusion is that this should *not* be supported by the Gimp core, but rather by plug-ins. This is not, however, possible in the current Gimp architecture, because there is no way for plug-ins to get pointer movement information in real time, and it would take major changes to make it possible -- and even then, it would be challenging to make the painting happen fast enough. The conclusions here should be reconsidered. 8. improve the text tool Evaluation: Most of the points mentioned here would be relatively simple to implement. One of them -- the ability to have multiple text items within a single layer -- might not be simple, and it should be considered whether this would better be dealt with by implementing layer groups. 7. save for web Evaluation: all of this is easy. Given a specification, this can all be assembled very quickly. 6. organize brushes, palettes, gradients in categories Evaluation: we have already had some discussion of this one. Peter and Sven favor a scheme that depends on tagging each item with a set of labels. I can't tell how hard this will be to set up because I don't have a clear picture of how it is supposed to work, at the level of specific user interactions. Adding tags would be relatively easy; supporting them might not be. 5. avoid pop-up dialogs Evaluation: Nothing is easier than getting rid of a dialog, and simply using default values. Most of the dialogs are actually present for a reason, though, even if it isn't obvious. For the rotation tool, for example, if you make an error and need to make a slight correction (and the preview isn't enough to tell you what you need), then the only way to do it is to note the angle that you see in the dialog. There must be a better way to solve this problem, but until such a better way is found, getting rid of the dialog is impossible. So it is with most of the dialogs in gimp. 4. better painting tools Evaluation: Most of the suggestions here would be relatively easy to implement. The blobs of paint strikes me as a potentially a very nice UI feature, and it too should be relatively easy to implement. 3. layer trees Evaluation: this depends on Gegl, and will be implemented as soon as the Gegl capabilities in Gimp make it possible. 2. adjustment layers Evaluation: I'm surprised to see this prioritized so high, but in any case the evaluation is the same: this depends on Gegl. 1. single window interface Evaluation: This is straightforward, but it will take considerable work. The hard part is that the image-containing part of the interace must have pretty powerful window-management capabilities, and the code for this, as far as I can tell, would have to be written from scratch. If it was just a matter of tabbed images, or if we could somehow find a window manager written in pure Gtk+ code (with minimal X code), then it would be a lot simpler. In any case, nothing prevents this from happening except limited developer time. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A feature request
From: Nnyah Nyah [EMAIL PROTECTED] I have a feature request. Let me explain it with an example. This is a longstanding request, see bug #76616 (Size entry widgets could use some simple math): http://bugzilla.gnome.org/show_bug.cgi?id=76616 I'm a little scared of this myself, because it looks like the sort of thing that would be easy to implement but hard to support -- in terms of explaining it to users, fixing bugs, and explaining why all the things that some user thinks *ought* to work actually don't work. But the enhancement request remains open, waiting for somebody to contribute code. -- Bill (PS, in future please try to use more informative subject lines, since developers often end up going back through the mailing lists to look up an earlier discussion.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tagged resources such as brushes, gradients, etc
I guess the reason I'm in such a fog is that all of the tag-using systems I know about are cumbersome, and allow methods other than tags to be used to help. Google, for example, is in some sense a tag-based navigation system -- and it's great, but you wouldn't want to depend entirely on it for your web navigation -- you also need bookmarks, history, and the URL entry to get a usable system. Bugzilla also uses tags, but only as a component. If it were possible to point to a program that already implements the sort of thing you have in mind, it would be very helpful to me. In any case, let me ask a basic sort of question about user interaction. Suppose I'm a user, painting with a set of brushes. I decide that I want to use a certain grunge brush. (Let's say I have a specific brush in mind, but all I remember about its tags is that it is a grunge brush from a set I imported last week.) What are the steps I have to take, as a user, in order to find the new brush and start using it, without losing access to the other brushes I am currently using? (I'm willing to assume that if I load everything with the grunge tag, I will be able to find the brush I want in there.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] resource repository (thread renamed)
From: Devin Watson [EMAIL PROTECTED] I'm sorry to jump in on this so late. I was working on a new GIMP Plug-In Registry. It had been put on pause by me because of certain life-altering events. [...] This sort of got sidetracked by all the traffic. I'm not sure whether there is a need for a new plugin registry, since Ingo has recently set up a new one himself, but there seems to be still a strong need for a web repository for other resources. There was an SOC project to create such a thing a couple of years ago, but it did not ever get beyond a specification. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposal for managing resources such as brushes, gradients, etc
One of the most important usability problems with Gimp is the inability to organize resources such as brushes, gradients, patterns, and palettes. For each of these, you can designate a set of folders in Preferences, but everything inside those folders is automatically loaded at startup, and presented to the user in a flat, unstructured format. Furthermore, there is no way for an ordinary user to get rid of any of the resources that come with Gimp, even if they are essentially useless, such as the famous Green Pepper brush. Not only does this make for problems in finding the right brush etc when using the program, it impairs Gimp in terms of developing a user base. One of the things that some users really like to do, in my experience, is create collections of resources. This has happened many times for Gimp, but nobody uses the collections, for the simple reason that adding resources to Gimp generally does more harm than good: everything you add makes it linearly harder to find the thing you want when you use the program. (Note, please, that I am *not* talking here about making resources available over the web -- that is also very important, but it is not the same problem. Here I am talking only about managing resources that the user already owns.) This problem has been discussed several times in the past, and proposals have been made about how to address it. I have been thinking about it recently, and have come up with a somewhat different, and I believe simpler approach, which I have begun to study experimentally. I would like to describe the approach that I have in mind, and to some degree try to explain why I think it is the right thing to do. To make the following description easier to understand, I am going to talk in terms of brushes, but you should realize that gradients, patterns, and palettes are handled by Gimp in exactly the same way (technically, all of them are types of GimpData), and a method that applies to one will almost automatically carry over to the others. Here is the idea: 1) You have a workspace, holding the brushes that you are currently interested in using. The brushes shown in Gimp's brush picker are those that belong to the workspace. The user has complete control over the contents of the workspace -- anything in it can be edited or deleted. The workspace is saved from session to session, and automatically loaded at startup. 2) You have a set of extra folders, specified in Preferences. The brushes in these folders don't automatically belong to the workspace. To get at them, you invoke a Brush Chooser, which pops up showing a list of brush folders, and a view, which can be either a list or a grid. Clicking on a folder causes the contents to be displayed in the view. Double-clicking on a brush in the view causes it to be loaded into the workspace. Once a brush has been loaded into the workspace, it stays there until you delete it. 3) You can also use the Chooser to save a brush from the workspace into the currently selected folder, assuming you have write permission there. That's basically the story. One of the advantages (as I see it) of the approach is that it makes very little change in how Gimp is used. So long as the user stays within the workspace, everything works the same as now. The only new thing is the Chooser, used to load brushes into the workspace (or save brushes from the workspace into a separate folder). At a technical level, the workspace would be represented by the user's writable brush folder, that is, ordinarily, .gimp-2.5/brushes. This would be the only folder loaded at startup. The Brush Chooser would show a simple list of the other directories specified in Preferences (including the set of distributed brushes), and a DataFactoryView of the directory among them that is selected. At the level of programming, the only relatively difficult thing is to create the GimpDataChooser widget. Even this is simple in principle, although complicated in practice because it involves a lot of rather complex Gimp code. I have been experimenting with writing a Chooser, and I believe I have gotten through the hardest part, although there is quite a bit of refinement needed. Comments and questions are welcome, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc
From: Sven Neumann [EMAIL PROTECTED] Right. We have discussed this in the past and we have come up with a simple and IMO very good solution that has several advantages over the approach that you are suggesting now. The solution is to allow tags to be assigned to data files. This allows the same data file to show up in several categories and it makes it easy to search for certain files. This is also the solution that is approved by the UI team. Please, by all means, let's not introduce something as obsolete as the system that you are suggesting now. This mixes together two separate issues. Tags are, as I have already agreed, an excellent way of doing a search mechanism. They don't get rid of the need to have a workspace, though. Suppose I want to switch back and forth between five very different brushes. Must I remember and select a set of tags each time I switch? That would be very unpleasant. No, whether or not there is a tag-based search system, there still needs to be a way for the user to maintain a workspace holding a limited set of arbitrarily chosen brushes. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
From: Joao S. O. Bueno [EMAIL PROTECTED] What about using...tags... for that? [etc] These are interesting ideas, but they are fantasies at this point. The whole tags thing is a fantasy at this point. There is no infrastructure in Gimp to support it, so everything would have to be written from scratch. That's months of work for somebody with strong Gimp skills, even if a complete specification existed, which is not the case. Who is going to do it? And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available. The proposal I made -- simply separating the workspace from the other places that hold brushes, and giving the user a way to copy things back and forth -- solves the largest part of the usability problem, and is not incompatible with using tag-based search -- or a tag-based workspace -- if support for tags is ever written, which I am doubtful is going to happen in the near future. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [SVN 24537], SIGSEGV in Colors - Curves
From: Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED] - I've loaded a tif file (43M) - called Colors - Curves - got a SIGSEGV You can expect some instability for a while, because of the introduction of gegl into the tools. It probably isn't useful to file bug reports or send messages to this list until things have stabilized a bit -- or if you have a problem that persists for longer than a week. A mention on #gimp would certainly be appropriate, though. Best wishes, -- 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
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
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] finalizing the task list
I think I probably would be able to come pretty close to turning the list that Chris Mohler created into a more-or-less complete 2.6 roadmap, with one exception: I haven't been following the developments concerning gegl. I wonder, then, whether the people involved in developing gegl and applying it to gimp could comment on whether the following is okay: GEGL integration - write adapter/proxy functions/objects which enable GEGL graphs to read/write from/to GIMP PixelRegions - remove all color correction code from app/base and use GEGL operators instead - if feasible in the time frame, abstract some common color correction base API out of the above step and implement a simple color correction paint tool - look for more isolated spots that would allow us to get rid of legacy code in favor of GEGL operators. --- -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] new psd-load plugin
John Marshall has written a new psd-load plug-in, based on the old one but rewritten from scratch, with several new features added. To us (Sven and me) it looks pretty nice, but neither of us are expertson the PSD format, or have huge numbers of files to test it on. We would like to commit it to the trunk branch, so that it is available to everybody for testing, but thought it would be good to ask for comments here before doing anything. The source is at http://bugzilla.gnome.org/show_bug.cgi?id=448181 if anybody wants to look at it. So, if you have any questions or objections, now is the time to speak. (If it turns out that there is something terribly wrong with the new plug-in, it would be very easy to revert to the old one.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
From: Daniel Falk [EMAIL PROTECTED] From a user perspective, I think the ideal solution would be to treat strokes on vectors similar to how Inkscape does it. For those not familiar with Inkscape, it works by attaching line and fill properties to the vector, which can be changed at any time. This is different from GIMP, which simply renders a stroke straight into pixels, which is somewhat less reversible. Unlike Inkscape however, GIMP should display the stroke and fill in pixels at all times, so the user can preview what the rastered result would look like and modify the vector accordingly. Daniel, You're asking for what we call vector shapes or vector layers. That's a longstanding goal, and a lot of the code to support it has already been written, but there are still some problems that need to be solved, probably too many to allow it to get into the next version of GIMP (which aims to come out in 6 months or so). What we are talking about here are less extensive changes that might make it easier to work with stroking in the meantime. Anyway, thanks for your input, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Sven wrote: I don't see though why it requires massive changes to implement a preview of paint strokes. It should be possible to do this after some refactoring of the code. Stroking with a paint tool is implemented in gimppaintcore-stroke.c, by gimp_paint_core_stroke() or gimp_paint_core_stroke_boundary(), which are very similar. Each of these functions calls: gimp_paint_core_start() gimp_paint_core_paint() gimp_paint_core_interpolate() gimp_paint_core_finish() gimp_paint_core_cleanup() And each of those requires an attached drawable. Furthermore, each of them is actually a virtual function (mostly), implemented differently by each paint tool. And at least some of those object methods will break if you don't have an attached drawable. So I don't see how to make this work on anything other than an attached drawable by any sort of simple refactoring. It would require a major rewrite of the paint core code, and that's some of the worst code in all of GIMP to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
From: William Skaggs [EMAIL PROTECTED] I think I need to follow up on my last message, because it was read incorrectly by some people. I should say that the English skills of most of the people who contribute to GIMP are so strong that I normally don't worry about how I say things, but in this case I assumed too much. The phrase in question is, that's some of the worst code in all of GIMP to mess around with, which was taken by some readers to mean that's some of the worst code in GIMP. To a native English speaker, it certainly does not mean that. It means, approximately, it is dangerous to make changes to that code. The word worst applies to mess around with, not to code. This sort of construction is actually pretty common. If I say, he's a bad man to annoy, it doesn't mean that he is a bad man---bad applies to annoy, not to man. I hope this makes my meaning more clear. Whether it is, in fact, dangerous to make changes to the paint core code is, of course, a different question, but I don't think it is insulting to suggest this. Some of the best code in GIMP is very carefully written to deal with complicated situations, and very dangerous to change, in other words, bad to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposal for usability enhancements for Stroke dialog
I find myself doing Edit-Stroke pretty often, and there are a few easy changes that I think would make it signficantly better. 1) The most important is that the dialog should not go away after the Stroke button is pushed. It often takes several tries to get the settings right, and it is very annoying to have to bring the dialog back each time. The gain in usability would easily be worth the cost of an extra button-click to close the dialog, in my opinion. 2) The default for Dash preset should be Line rather than Custom. This is just obviously wrong. Also, it shouldn't be called Dash preset, but rather Line style, and the expander should be named something different, such as Stroke settings. 3) The Dash preset (or whatever it is called) control is by far the most important in the expander, and should be at the top. In fact, I think it should be out of the expander, since a user *always* wants to know what type of line will be rendered. These changes would take me less than an hour to implement, I believe, and I would like to do it. I filed a Bugzilla request for this; Sven asked me to bring it up here instead. The reason I tried Bugzilla is that as far as I can see, when things get brought up on this list, they never get resolved. They get discussed (sometimes); a few people are in favor, a few people are opposed; and it just drags on without any decision emerging. In Bugzilla, at least a bug report sits there visibly until some resolution is reached. Even so, let's give it another try... -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] removing toolbox menu
(I've changed the subject line, since changing the shape of a text layer no longer applies.) Sven wrote: But that code is all in SVN already. Just pass --disable-toolbox-menu to configure. Note that you need to do a full rebuild and a fresh install to make sure that the menu files are correctly updated. Great! I wasn't around while that development was happening, and missed it. The part that is not yet done is to have an image window that always exists. This depends a lot on the specification of the UI team so it probably doesn't make sense to work on that until that spec is done. Okay. I'll be happy to contribute ideas on how this could be set up, if that would be useful. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
From: Sven Neumann [EMAIL PROTECTED] We don't do this kind of Apply thing anywhere in GIMP. I think it would be rather inconsistent and confusing if we start to do it for some dialogs. Since the dialog already remembers all settings, I don't really see what you want to achieve with this change. Perhaps it just needs to be made easier to bring up the dialog again? How could it be made easier? And even if it were, consider the usage pattern you get: 1) bring up the dialog 2) move the dialog 3) set it up 4) hit okay 5) undo 6) bring back the dialog *) repeat steps 2-6 several times Note that since the dialog is transient, it generally comes up on top of the image, and needs to be moved aside each time. It's not clear how this could be avoided. 2) The default for Dash preset should be Line rather than Custom. This is just obviously wrong. Well, you would have to add logic then that changes it to Custom as soon as the user edits the custom dash pattern. And you would have to remember that setting also. When we did that dialog we decided that it's just not worth the hassle. Consider what this looks like to a user. I select libart stroking, open the expander, and see that the dash preset is custom. How can it be custom? Custom means something that I set up myself, but I haven't set anything up. What makes it even worse is that the default custom pattern only fills half the menu width, so it looks like a dash until you open the menu and see that line looks the same way. Also, it shouldn't be called Dash preset, but rather Line style, and the expander should be named something different, such as Stroke settings. Well, dash preset is programmer language, not user language. Something in user language is needed here. My guess is that the user almost always wants a line. Using a dash pattern is rather uncommon, isn't it? But yes, perhaps moving it to the top would help. It probably varies by user -- I personally use it pretty often. In any case, a user who chooses libart stroking will always, I think, want to see what is going to happen. Automatically opening the expander when the method is Stroke line would help some too. Anyway, I wouldn't want to get bogged down on the dashes part, when the really important part is streamlining the flow of changing settings and re-stroking. As currently done, it feels broken. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Okay, I can see that a preview would go a long way toward making the dialog more usable. I looked over the relevant code, though, and I'm not sure it would be very easy to set one up. Previewing libart stroking wouldn't be very hard, because basically all you need is a set of tiles to do the stroking on. Previewing paint tool stroking would be more problematic: it requires either an attached drawable, or massive code changes. So, as far as I can see, the only way to do it without massive rewriting would be to create a new temporary layer, attach it to the image, render the preview onto it, transfer the preview to the dialog, then remove the temporary layer. That wouldn't be hard to do, but it seems a bit, um, baroque. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
From: Sven Neumann [EMAIL PROTECTED] Or is this just about merging the toolbox and image window menus? Yes, that's what I meant. From a user's point of view, that's a pretty major restructuring. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
Excuse me, but I'm finding this whole roadmap process very confusing. When I look at Peter's web page, I find only one actual spec, for selection tools. There are lots of other partial specs, but this is the only one that seems to be completed. Does this mean that nothing else is ready to have code written? If not, what is in a state where it is useful to start writing code? In general, when I look at the tentative roadmap on the wiki, I see only one thing that seems to be available for somebody like me to work on, namely the healing tool (which I am looking at). Everything else seems to be either ambiguously specified or spoken for by somebody else. Am I missing something? -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
Peter, I would like to restate that I would prefer to work under the guidance of your team. If you can specify the most important change that you think can be made now, and if Sven agrees to let me work on it, and if I can see how to do it, I'll probably be willing to take a shot at it. I don't even need a full specification, just some definite objective to write code for. In particular, I would be happy to work on the menu restructuring if you and Sven can agree to go ahead and make specific changes, and if Sven is comfortable with that. From a coding point of view, it should be pretty straightforward. There are several other things in your partial spec list that would be pretty easy to write code for, if the objectives were spelled out precisely and fully agreed upon. Best wishes, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] thumbnail generation for nautilus via gimp
From: Eckhard M. Jger [EMAIL PROTECTED] there is a thing that i don't understand, my script is opening the file and so the thumbnail is generated by Gimp automaticly when closing gimp. ... Unless a file contains an internal thumbnail (as jpeg files sometimes do), there is no way to generate a thumbnail for a file without loading it. So probably you're hoping for something that is impossible. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
From: [EMAIL PROTECTED] I like the idea of having this functionality available. I have tried the patch and it seems very capable. There appears to be bug which presented itself when I did the following: ... Thanks for the bug report. I'll take a look at it. As a general comment, I would point out that this interface might present a problem in the future when in-place text editing is implemented. Since the primary function of the tool is text input, perhaps it would be better to require a modal key (ALT?) when adjusting the frame so that, in the future, unmodified mouse clicks could be used to specify cursor location and text selections. I hadn't thought about this, but it seems to me that it would be simpler to distinguish between clicking (used in in-place editing) and click-and-drag (used for modifying shape). But in general I am absolutely delighted to leave that sort of question to the wisdom of Peter and his cohorts. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using the GIMP donations
From: Martin Nordholts [EMAIL PROTECTED] The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see The problems are bigger than you currently see. Here are just some of them: 1) Do you really know how to make a payment to somebody in an arbitrary foreign country without violating either the law in your country, the law in the country where the GIMP funds are held, or the law in the country of the person who receives the money? 2) What will guarantee that you keep such good records that, should you suddenly disappear from the GIMP project, other people will be able to make sure that agreements are not violated? 3) What if somebody donates for a specific feature and then is unhappy with the result? 4) What if you pay somebody for a feature and then find that the code is not usable because it violates a copyright or patent? Etc, etc, etc. Let me point out that there is nothing to forbid a company from paying somebody to develop a GIMP feature, so long as the company itself manages all the finances and contracting. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gaussian blur in GIMP compared to Photoshop
Jesper de Jong wrote: Is Gaussian blur not a standard algorithm that has a well-defined meaning for the radius? See for example http://en.wikipedia.org/wiki/Gaussian_blur The answer is no, there is not a single well-defined meaning. From a mathematician's point of view, the equation contains an r parameter which it is natural to call the radius, but if you use that value, it will look to a user like the blur extends considerably farther outward. GIMP instead tries to use a scale such that the blur appears to a user to extend for approximately the specified distance. This is a matter of judgement, but the usage is consistent and seems to come close to matching people's intuition, as far as I can tell. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Tool enhancement] GIH brushes on Smudge tool
From: Isaque Profeta [EMAIL PROTECTED] Date: Sat, 17 Nov 2007 16:00:34 -0200 Hi guys, I'm a user and now starting read the gimp developers site and looking API and other things to see what I can do to help. So, I have a question: I'ts too hard to make a full support of GIH (Animated Brushes) in Smudge tool? Until now in version 2.4.1 when is used, GIH's with Smudge, just the first brush of a row is used in that. I would strongly recommend that you start with something easier. The brush-tool handling code is probably the most difficult to understand of anything in GIMP. If you don't believe me, look at app/paint/gimpsmudge.c, where most of the relevant code for the smudge tool is located. That being said, I just did a little experiment: I inserted brush_core_class-handles_changing_brush = TRUE; as line 95 of gimpsmudge.c -- this is enough to enable the animation. The smudge tool seems to work that way, but the result does not look like a smudge to me. It may still be useful. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Exporting Vectors to a SVG file
From: Lionel Tarazon Alcocer [EMAIL PROTECTED] Is there a function which exports paths/vectors to a SVG file or string? No, but it would be easy to add, since the functionality exists in the core. If you need this, probably the best thing to do, to start with, is to file an enhancement request, using Bugzilla. Assuming there isn't any problem, it shouldn't take more than a few days to get this done -- the main issue will probably be to make sure to get the right name and API for the functions. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Exporting Vectors to a SVG file
Maybe these ones ? http://developer.gimp.org/api/2.0/app/app-GimpVectors-export.html Those functions are only available from within the GIMP program itself, not from plug-ins. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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 items
From: peter sikking [EMAIL PROTECTED] Well, this topic is not so clear cut. There are many factors: - the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two. - yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes. I agree with this completely. The obvious things that GIMP should be able to support are lines, rectangles, and ellipses. The UI for manipulating rectangles and ellipses already exists in GimpRectangleTool, which was created partly with that thought in mind. The UI for handling lines should be much simpler -- as I said earlier, it should be possible to derive this straightforwardly from GimpRectangleTool. The remainder of the UI would consist of edge/fill options, which would presumably go into the tool options. A full-fledged vector layers capability introduces a lot of UI questions, which, as you say, might not even be desirable to support, but for the most basic things, it should all be reasonably straightforward. I can't tell you how many times I've needed to create a simple arrow pointing to something, and been annoyed to have to hack around to do it. The idea of invoking Inkscape to edit SVG layers makes a lot of sense, and in fact I have suggested this myself in the past -- but, as Sven pointed out, it is very tricky to pull off such an interaction without it feeling awkward and creating a large potential for breakage. This is certainly nothing that could be done in the hoped-for 2.6 time frame. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 Roadmap
One of the things that GIMP badly needs is a vectorial tool for drawing lines and arrows. This also would make sense as a first usable implementation of vector layers. Here is how I think it could be structured: 1) For UI, there should be a GimpLineTool interface, modeled after GimpRectangleTool, but much simpler because it only needs to be able to move the two ends, rather than any of 8 possible corners or edges. This could be created by cloning GimpRectangleTool and then simplifying, or from scratch. It would only be an interface, not a tool in itself. 2) The interface would then be used in a GimpLineShapeTool (GimpArrowTool?), which would create a vector layer containing a single line segment, allowing options to be specified for rendering style and arrows on the ends. This would be an actual tool, accessible from the toolbox. I mention this not because I want to do it myself (I don't particularly), but because I think it makes a good roadmap target, and one that might be interesting to active developers. Martin, I think, would be capable of setting up GimpLineTool, and it would give him something more creative to do in addition to fixing bugs in GimpRectangleTool (which is also important, of course, but not so exciting). For Henk, setting up GimpLineShapeTool (or whatever it is called) might give a target that is both extremely useful and an excellent start toward a full-fledged vector layer capability, without getting into all the complexities of arbitrary shapes. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 Roadmap
As GIMP moves toward vector layers and layer groups, it will more and more need a capability for vector selection -- that is, for the kind of selection capability found in vector graphics programs like Inkscape, whose target is a set of objects rather than a spatial region -- a vector selection as opposed to the raster selection that GIMP currently uses. Actually, GIMP already has such a capability to some degree, in the linking mechanism, but it is too hard to use. I have some suggestions for improvement, which I would like to work on for GIMP 2.6 if it is okay. Here are my thoughts: 1) With two kinds of selection, there is no way to completely avoid confusing users. Probably the best thing to do is to keep calling the vector selection linking. The only real problem with this is that the same thing is always called selection in vector graphics programs, but I think it is better to face this than to use the same word for two quite different things. 2) We need a linking tool: a tool to allow objects/layers to be linked by mouse-clicking or rubber-banding. The UI for this already exists, in the Alignment Tool. In fact, that's actually all that the UI for the Alignment Tool does; the only change needed would be that, instead of the tool maintaining an internal list of the items that are selected, it would link them. 3) If the Alignment Tool is converted to a Linking Tool (with toolbox symbol an arrow pointing to the upper left), then no Alignment Tool is needed -- the functionality can be moved into a dialog, or pair of dialogs, accessible as Edit-Align or Edit-Distribute. The dialogs would operate on the set of objects that are linked. 4) Linked objects should be marked when the canvas is drawn, by putting small filled-rectangles at their corners, as is done in other vector-graphics programs. 5) Possibly the chain symbol in the Layers/Paths dialogs should be replaced by an arrow symbol. 6) The dialog in the Alignment Tool is modeled after the one in Inkscape, but has some differences. It could in principle be made virtually identical, even to the extent of using the same icons. There are a couple of things that Inkscape allows that GIMP wouldn't currently support, including (a) aligning the baselines of text layers, and (b) aligning anchor points of vector objects. I would welcome discussion of the pros and cons with somebody who is familiar with the Inkscape functionality. 7) There is a problem with paths (i.e., Vectors) as currently implemented: the offsets and dimensions obtained using the gimp_item_get_foo() calls are not meaningful. This needs to be fixed to make a linking tool work properly, and really ought to be fixed in any case. This is a sketch: I can spell out all the details in a more appropriate place. Although this may look like a long list of objectives, everything in it is actually simple to do (all the hard work was done in creating the alignment tool); and none of it creates much risk of breaking things that are deep and critical, as far as I can see. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
From: Sven Neumann [EMAIL PROTECTED] I don't see GIMP moving towards vector layers, at least not for 2.6. Layer groups are also not on the near-term roadmap. Perhaps we can target them for 2.8 but that remains to be seen. Oh well, consider my suggestions as early contributions to the 2.8 roadmapping process, then. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporaryparasites
From: Raphaël Quinet [EMAIL PROTECTED] So here is a short list of what I think makes sense to include in XCF files: - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. The problem is that when a parasite gets saved, it becomes in effect a part of the API that must be supported forever. For example, in a GFig layer, the contents of the figure are contained in a layer parasite. If the parasite is permanent, then (1) every future version of GFig must be able to read it without borking, and (2) every future version must write parasites that don't cause past versions to bork. This sort of thing may make sense for stable releases, but during development it is often a great convenience to be able to experiment with formats without every attempt being a commitment that will bind you forever. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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-inenhancements
From: Karl Günter Wünsch [EMAIL PROTECTED] 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. No! EXIF in an edited image is still highly relevant, but it should not merely be copied from the original, as GIMP used to do. The EXIF specification gives precise instructions about how the EXIF data should be altered when an image is edited and saved, and to the best of my knowledge -- I just looked at the code again -- GIMP now follows the specification pretty closely, and has done so for almost three years. The file exif-handling.txt in devel-docs summarizes my understanding of what the specification requires us to do. You can look at the function jpeg_setup_exif_for_save() in plug-ins/jpeg/jpeg-exif.c to see what GIMP currently does to the EXIF. As an example, the specification says that the orientation should *always* be set to top-left when an image is saved after editing, regardless of what it was when loaded. People may argue about whether that is always the best thing to do, but it is what the specification requires, so it is what GIMP does. To the best of my knowledge, it does this regardless of what decision the user makes about rotating when loading. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color change
From: Evan Designs [EMAIL PROTECTED] ... I was wondering if you guys had some advice or any interest in making a GDi+ api for us?? We would pay, of course. Anyway, mull it over, any reply is appreciated, Did NOT mean to offend anyone with the question in any way!!! THANKS Shelly Shelly, The question is not offensive (to me at least), but you're unlikely to have much luck here, because most GIMP programmers are much more familiar with Linux than Windows, and GIMP relies on a completely different graphics API. (GDi+ is an MSWin-specific graphics interface; I had to Google it to find that out.) -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
From: Raphaël Quinet [EMAIL PROTECTED] + remove the prompt for EXIF orientation: it should always be done I agree with this idea now. The problem I had with it before is that it would do bad things to people whose EXIF images had incorrect rotation information, and that would have included everybody who had used GIMP to edit a rotated image and then saved the result as a JPEG. But GIMP has been handling this correctly for a oouple of years now, so the number of cases where people get annoyed should be reasonably small, or at least if they do, it will mostly be blameable on other misbehaving programs. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Cairo for 2.6
To my understanding, switching to Cairo for the canvas (and switching away from XOR drawing) will involve two things: 1) Porting GimpCanvas to Cairo instead of raw GDK. That should be pretty straightforward: I think virtually all of the relevant code lives in app/display/gimpcanvas.c. 2) Changing the implementation of gimp_draw_tool_pause() in app/tools/gimpdrawtool.c, so that instead of erasing the drawing using the XOR trick, it redisplays the projection of the image. I believe that getting this to happen efficiently will require maintaining a pixmap of the projection as it is currently displayed. Given that that needs to happen in any case, this might be a good time to take on the problem of displaying an interpolated view of the projection instead of the current every-nth-pixel view. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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...
My congratulations as well, great to see the release out! From: peter sikking [EMAIL PROTECTED] From my UI-redesign point of view, we need to get GEGL and Cairo in GIMP, else there is little chance of innovation in the UI. Also what the GIMP project needs right now is a short ( 6 months) development cycle. A short-distance run to get its heart beating faster. I agree with you. The experience of many other projects, though, shows that it is very difficult to get short release cycles with a feature- based roadmap -- the only way to do it is to do time-based releases. I would suggest, then (since getting GEGL in is the one really essential thing at this point) that the way to proceed is to make an estimate of the time it will take to do the most basic GEGL intregration, expand it by 50% (because it is good to be realistic), and set that date as a soft feature freeze, with a hard feature freeze following say 2 months later. Things that aren't ready by the designated dates must be removed until the next cycle. (By the way, unless I am very badly mistaken, there is zero chance of doing meaningful GEGL integration on a 6 month time basis. Cairo is much easier.) (I also think that the first GEGL-based release should be called 3.0.) Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is it too late to send a l10n patch for GIMP2.4.0?
My understanding is that it is never too late for translation improvements, even well after a stable release, and that the correct place to send them is to the person responsible for your language. Often translators don't even *begin* to work until the string freeze that comes shortly before a release. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP to New OS, New CPU, New Hardware
no spam [EMAIL PROTECTED] wrote: I plan to hire a famous, professional software development company/team for porting GIMP into a new Operating System, on a new type of CPU and new hardware, with fixed budget and time limit. What is the name of the excellent software development company/team? It would take a commitment of several hundred thousand dollars to get a famous, professional software development company to pay attention to you. If you have that kind of money available, you should talk to Sven and Mitch instead -- they would be able to do a better job for less money. But I think if you were serious, you would not ask the question this way. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
It would be helpful to get more input from yosh. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
From: Luis A. Florit [EMAIL PROTECTED] For Bill: [...] Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. [...] Fedora maintainance sucks. Please don't judge GIMP's bug handling by Fedora. For gg: I suspect it got ignored since one pixel offset errors are pretty much to be expected. ???!!! Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts! As I wrote before, you are quite correct, and gg is wrong here. Rounding errors are to be expected every so often, although they should be fixed when they are found if possible, but a systematic 1-pixel offset in a filter is a serious bug that must be fixed. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Help - gimp-plugin-template development on olderLinux.
From: G Bulmer [EMAIL PROTECTED] I am attempting to write a gimp plugin to 'bridge' between the gimp and a 3rd party piece of technology, under Linux. [...] My users need to stay with their currently deployed versions of software including the gimp (2.0.5) [...] If the code for your plugin will fit into a single C file, it is a lot simpler to build and install it using the gimptool-2.0 --install command. As a framework for such a plug-in, you could start with pretty much anything in plug-ins/common in the GIMP source code -- you have to remove a few lines involving internationalization to get a plug-in to compile using gimptool --install, but it isn't very difficult. Also, you can find quite a number of plug-ins in the registry (registry.gimp.org) that are specifically written for GIMP 2.0, if you want a better starting point. Many are single-file plug-ins that you install using gimptool, but a few are more complex. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
From: Mark Lowry [EMAIL PROTECTED] I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? GIMP Bugzilla is the place to request features, but it is often helpful to discuss them on this list first, as you are doing. As Joao said, the functionality doesn't exist right now. I wonder if the best way to get it would be to use sample points, which you can create by Ctrl-clicking on a ruler and dragging into the image, and can even move around after they have been created, by activating the Color Picker tool and click-dragging a sample point. Sample points are a new feature, and code hasn't yet been written to allow a plug-in to request the list of sample points belonging to an image, but it would be pretty straightforward to do so. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
From: [EMAIL PROTECTED] There is an underlying issue where both origin and offset of a region are stored as gint before any processing is done. This means two rounding and/or trucation errors can easily end up producing a one or two pixel error. Yes, but there are other basic coding errors that can easily cause a filter to shift its result by one pixel, too. I'm rather surprised that anyone following this list should mistake my position since I have been quite critical of just this kind of point, even in the last 7 days. I actually understood what you *meant*, but what you *said* to Luis was misleading and needed to be corrected. Now Luis has given a specific case and replied to my request for the filter settings needed to reproduce it, it seems to be getting the attention he felt it missed last time. Well, it's getting attention, but it probably won't get fixed unless there is a bug report. By the time people get back from LGM, all this discussion will have disappeared in Dev-list limbo, and probably nobody is going to go back and re-read it. (Unless you fix it yourself, gg :-)). -- Bill gg __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] still the same bug
From: Luis A. Florit [EMAIL PROTECTED] I reported this bug in this list some time ago . . . For philosophical questions, it is good to bring them up first on this list. But for actual bugs, in the sense of the program doing something that is clearly incorrect, it is best to file a Bugzilla report. The advantage, and disadvantage, of Bugzilla is that nothing reported there is ever forgotten -- and few reports are completely ignored. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] LGM: top-10 feature requests...
From: peter sikking [EMAIL PROTECTED] Guys and gals, For our presentation at the LGM meeting we would like to show some results from our UI redesign projects. [...] Please help us to make this list by suggesting these top-10 bugs. Here are 11 I have seen requested multiple times, and this is not exhaustive. ). Single-window interface. (This is by far the most often-requested feature.) ). More control over window/dialog organization. ). Color management. ). Better painting tools. ). Better support for metadata. ). Different menu organization. ). Layer effects. ). Save for web. ). Ability to organize/categorize resources such as brushes, gradients, palettes etc. ). Better printing support. ). Better tablet support. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Looking for GIMP developers
From: Nancy Parsons [EMAIL PROTECTED] I'm not sure if I am approaching this in the correct way, but we are a non-profit organization looking for developers fluent with the GIMP programming language to create a customized version of GIMP. [...] So would anyone be able to point me in the right direction to find a list of experienced companies/developers capable of this task? Nancy, There aren't any companies that do GIMP development-for-hire, and the developers capable of it pretty much all read this list. It would be a lot easier to give a meaningful response to your question if you could clarify what the simpler needs of your uers are. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
From: Nancy Parsons [EMAIL PROTECTED] I didn't want to bother everyone with the detailed specs of our project, just hoping for the URL of a few places to search for GIMP developers for hire. This is the right place. If you, or any other developer would like more detailed information on what we are looking for, please let me know where to send it and I'll get it off to you straight away. A pointer to a web page giving the instructions your users are supposed to follow would be great. If that isn't possible, please feel free to email them to me. It's impossible to judge the scope, and therefore realism, of the project you have in mind without that information. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] internal representation of a selection
From: Helmut Jarausch [EMAIL PROTECTED] Date: Sat, 31 Mar 2007 13:10:19 +0200 (CEST) We had some discussions here 5 weeks, ago. I had a look at the current implementation (in the development version). There I found the reference to a paper by T. Georgiev (from Adobe). The current implementation fails in some fundamental aspects. [...] My current plan encompasses a few steps outlined below. Perhaps I'll add a quick mode which would be similar to the clone tool lateron. [...] Helmut, A couple of thoughts. First, there would be a big advantage in starting from the existing healing tool code instead of creating a new one completely from scratch -- the advantage is that a lot of developer time has gone into the user-interaction aspects of the existing code, and people would perhaps not be so patient if they had to repeat with you all of the advising that went on with sookocheff. Second, your approach requires a multi-scale solver. Do you propose to write one from scratch, or to use an existing one? Third, an approach that makes use of the selection and source-center, without requiring any painting, does not need to be a tool at all -- it can, and probably should, be implemented as a plug-in. You would probably find it easier to develop that way, since the libraries used by plug-ins are far better documented than most of the functions used in the core. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Denoising Plugin
Jim Sabatke wrote: I've just compiled a plugin based on a denoising program that attracted slashdot's attention a short while ago. [...] Jim, there is already a GREYCstoration gimp plugin, which you can find out about by googling greycstoration gimp plugin. Is yours better? In any case, the main gimp distribution doesn't currently include anything written in C++. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
What fun! Curiosity piqued, I tried to do some quasi-controlled analysis, using the following method. For various values of foo, I did a Google search for foo developers rude and then for foo developers friendly, and computed the ratio of the number of hits, yielding the RQ or rudeness quotient for foo. Here are the RQ's for a few foo's: baseline (foo = ): 0.064 SOFTWARE: gimp: 0.314 photoshop:0.411 gnome:0.199 linux:0.044 linux kernel: 0.212 kde: 0.160 inkscape: 0.006 krita:0.021 blender 0.181 ORGANIZATIONS: fsf: 0.392 microsoft:0.067 adobe:0.313 oracle: 0.206 ibm: 0.274 COUNTRIES: american: 0.045 german: 0.243 canadian: 0.009 french: 0.116 indian: 0.114 finnish: 0.340 norwegian:0.394 QUALITIES: hacker: 0.571 brilliant:0.791 elite:0.769 incompetent: 0.344 stupid: 0.819 So it seems that the least rude are Inkscape developers and Canadians. The rudest are the stupid developers, followed closely by the brilliant ones. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
Acually the thing that struck me was that the answer from Mitch was not only a little rude (which is unusual for Mitch), it was also a bad answer -- it doesn't make sense to download the source code just to find out what language it is written in. Now if the first thing that occurs to *Mitch* is wrong, then the question is probably not quite as trivial as it seems. In fact, if you take obvious approaches, such as googling for gimp source code, you don't easily learn the language it is written in. Moral: don't be rude unless you *know* that the person you're answering has done something bad. (And even then, rudeness marks you as an amateur.) -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgns_register
From: Luis A. Florit [EMAIL PROTECTED] [ . . . ] My questions: When to use one and when two iterators? Which one should I use for a procedure like the one described in my plugin? Is this indeed faster than the method I implemented based in myblur5.c? You probably shouldn't do this at all. The gimp_pixel_rgns_process method handles the data tile by tile, which means that it is impossible, or at least quite difficult, to handle interactions that extend across multiple tiles. It is mainly useful -- and very efficient -- for plugins that act on individual pixels. Your plugin, because it needs to look at neighborhoods, does not fall into that category. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory manage in python-fu
[...] The thing I did not expect was that it had well over a gig of ram left unused, no swap used, 30 gig of unused drive, and it still thought the hard drive was full. [...] It might help if I explain a little more about how GIMP handles memory. GIMP does not rely on the operating system for swapping. When you start GIMP, it creates a file, of fixed size which you designate in the Preferences, to serve as a swap area. You also tell GIMP, in the Preferences, how much RAM it is allowed to use. If GIMP needs more memory, it moves some of its data from RAM into the swap file. What is happening to you is that the swap file is filling up, because data is accumulating there that ought to be cleared away. You could delay the failure by increasing the size of the swap file (called the tile cache) in Preferences, but really, in the work flow you described, it ought not to be filling up, so there is a bug either in your code or in GIMP -- and as I said earlier, I think there is probably a bug in GIMP. (I am not 100% certain that I got all the details right here. Presumably Sven or Mitch will correct any mis-statement.) -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools
From: Federico Alcantara [EMAIL PROTECTED] I am interested in knowning if Gimp is written in C/C++, and which tools are needed to compile, debug, and test it? You can find a brief overview at http://wiki.gimp.org/gimp/SummerOfCode and a lot more detailed information at http://developer.gimp.org -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] memory manage in python-fu
I think you have hit an actual bug, and that it doesn't have anything to do with python, because I have encountered a similar thing in a modified version of gimpressionist that I worked up, written purely in C. I believe that there is some sort of memory leak that causes gimp in some situations to maintain reference to tiles that are no longer being used in any way, and it is something that shows up when you create and delete layers over and over again, in a certain way. So it would probably be useful for you to file a bug report about this, if you would. The memory that is being exhausted, by the way, is the swap area that gimp allocates on the hard disk each time you run it. The tile manager moves tile data there if space is needed. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving image processing algorithms as SoCproject
Anton Slesarev wrote: I would like to improve performance or quality of image processing algorithms. Try to describe some specific targets. [...] Hi Anton, I think all of these are good ideas, to varying degrees. If you would like to do some of these things for SoC, it would be a good strategy to start doing things now if it is possible. Last year we got 10 times more applications than we could accept, and we found that our greatest difficulty was to tell the difference between people who had good ideas, and people who could actually implement those ideas and work effectively with the GIMP development system. To settle that question before the applications come in would give you a great advantage. Of course there would still not be any quarantee. If you can, please visit the #gimp channel on irc.gimp.org for more discussion. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview window does not work
Concerning the plug-in example, if you want to see the proper way to do it, you can look at the real blur plug-in, in plug-ins/common/blur.c. However, as Sven suggests, that plug-in only does a 3x3 blur, and a proper implementation for NxN, as in the example, would be pretty hard to read -- too hard to make a good example. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gfig
From: Claus Cyrny [EMAIL PROTECTED] Date: Tue, 06 Mar 2007 18:10:10 +0100 Hi all, I would like to know if 'gfig' is supposed to be included in Gimp 2.4? The handling is really so uncomfortable that I would rather like to see the text tool improved, the way it is already realized in Paint Shop Pro, Photo- shop, etc.: to include the text at first as a vector layer, which can be rendered as a bitmap after- wards. The handling of the present text tool is far from satisfactory. Huh? Gfig has nothing to do with text, and the text tool already does create vector text layers. Your request is impossible to understand. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] healing the healing tool
This discussion seems to be going astray a bit. Let me try to supply some suggestions and information. Item: Peter is, no doubt unintentionally, getting into questions of implementation, as opposed to user interface, when he writes about rectangles. The brush only specifies the area to which healing is *applied* -- the region over which the differential equation is solved is invisible to the user. Item: The whole point of this tool is to use a brush. Healing using a selection might be quite valuable, but it would be a different tool. However -- to repeat -- the brush only specifies the region to which healing is applied, not the region used to perform the healing computations. Item: The user needs to receive feedback during brush motion. As Sven points out, the feedback does not have to be perfect, but a user needs to be able to tell at least approximately what is happening. Item: There is no reason why healing has to be cumulative. At least during an individual painting operation (i.e., while the mouse button is held down), it is possible to retain the initial state, and accumulate the set of brush locations, using the totality to define the region for healing. Some of the existing paint tools already work this way. Item: The main healing code is in app/paint/gimpheal.c. You don't actually need a broad knowledge of GIMP internals to understand the code there. The most important thing you need to know about is pixel regions, and the easiest way to learn that is to start by reading How to write a GIMP plug-in, which you can find at: http://developer.gimp.org/writing-a-plug-in/1/index.html The interface to pixel regions for plug-ins is not identical to the one in the core, but it is very similar, and the concepts are the same. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
This discussion goes on too long and distracts too much. I am one who would prefer the plugin to work differently, but it is clear that no solution will be good for everybody, and the approach Sven has taken is certainly reasonable. It would also be reasonable, I think, to separately distribute a fancy-screenshot version, perhaps via the registry, that would allow more options for handling the delay. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Gg, Google Scholar only finds one paper by RG Keys on this topic: Cubic Convolution Interpolation for Digital Image Processing RG KEYS IEEE TRANSACTIONS ON ACOUSTICS, SPEECH, AND SIGNAL PROCESSING, VOL. ASSP-29, NO. 6, DECEMBER 1981 I was able to download a pdf of that paper using my institutional access, and I don't think it would be a violation of anything if I send you a personal copy. Would that solve the problem? -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] replacing gimp-remote
Sven wrote: (3) Should gimp-remote still be built and installed even if the d-bus functionality is built into the gimp exectuable? The patch currently doesn't change this, it just removes the reference to gimp-remote from the gimp.desktop file. My understanding is that d-bus doesn't work on MS Windows yet. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] print plug-in
Re the issues that Akkana mentioned: The margins can be handled within gimp, and probably the paper size too -- I was unable to test this when I was sorking on it so didn't try to handle it. The two Page Setup functions, the bad placement of the layout stuff, and the disappearing dialog when doing print preview are all GtkPrint features, presumably due to the fact that Page Setup, Print Preview, and Print are separate items in the standard Windows menu -- in any case they are not easily changeable at the GIMP level. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] neue Hackordnung
GG wrote: [**] I agree that it would be helpful to have more guidance for new contributors, but my own experience is that most of my trouble has come from trying to understand the high-level structure -- the overall architecture, the core objects and the principles for using them. The low-level thing that has caused me the most difficulty is signals -- knowing when one is going to be emitted and what is going to happen as a result -- because this is often not apparent from the source code. On the question of longer lines, I disagree. For comments it doesn't really matter, but I find consecutive long lines of code extremely difficult to read. Also I often work on code with multiple Emacs windows open side by side, and in that scenario even with a good modern monitor it creates difficulties if the code is wide. There is no question that it is helpful to use good variable names, and lots of the old code could definitely be improved in this respect. People's opinions about specifics may vary, though. I myself think bytes is fine if it is used consistently with always the same meaning, and bpp is fine, but bytes_pp impairs readability. I also think that, strategically speaking, it is best to focus these sorts of improvements on code that needs maintainance for other reasons, because experience shows that even something as seemingly harmless as renaming variables often causes accidental breakage. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Edit-Fade
Mitch has just made a commit to HEAD that imho is important enough to justify a message to this list, on the basis of how commonly the equivalent feature is used in PhotoShop. From the ChangeLog: 2006-10-21 Michael Natterer [EMAIL PROTECTED] Added Edit - Fade which allows to modify the paint mode and opacity of the last drawable operation (fill, plugins etc.). Started from a patch by Bill Skaggs. Fixes bug #170707. See http://bugzilla.gnome.org/show_bug.cgi?id=170707 for more information. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
From: Scott [EMAIL PROTECTED] [...lots of stuff...] I don't know if this is the proper place to post this sort of thing, but I do hope that you developers will consider listening to some of us casual users, as the interface has gotten way too overloaded and user-unfriendly. I seriously am thinking of going back to 2.2, and I shudder to even think of what a mess 2.4 is going to be if this is any indication of progress. How can a tool so simple in concept and so frequently used as crop have been bollixed up so badly? Scott, thanks for the feedback, although you could try to be a bit less emotional about it, since this is after all a development version. Several of the things you complain about have already been changed in the most recent builds, motivated by feedback similar to yours. Others simply reflect that you haven't learned yet how to use the new features. For example, if you always want a 300x200 crop region, you can set the width and height in the options, *and activate the checkboxes next to them*. If you do that, then the width and height will stay fixed no matter what you do with any of the corners. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
It seems that for consistency the Move tool should act like a transform tool --- because after all, it *is* a transform tool. That is, if there is a selection, it should move the contents of the selection, otherwise it should move the layer. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
Bill, to you it *is* a transform tool because you are close to the code and you know the way is it implemented. To the user it *is not* a transform tool. It's just a tool off the palette like any other that is called Move and that carries the hint move layers, selections and other objects. It's not even a transform tool from the code point of view. It has just been sorted into the Transform tools category since that seemed to describe it best. Sven Well, I was quite aware that it is different from a code point of view -- what I was trying to say is that it feels like a transform tool from a *functional* point of view. Moving feels to me like it should group logically with operations like Rotating and Flipping. After all, isn't Rotating just a freer kind of Moving? This may just be my math background coming through, but that's the way it feels intuitively to me that it ought to be grouped. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
From: Rapha�l Quinet [EMAIL PROTECTED] As a side note, it would be nice if the rectangle and ellipse selection tools (not the base rectangle tool) would take Alt into account before the selection is confirmed and behave as if the selection had been confirmed: Alt = move selection mask, Alt+Ctrl = move selected pixels, Alt+Shift = copy selected pixels. It should not be necessary to press Enter before being able to move it. Well, that's a bug, then. The objective for Rectangle Select is that you should be able to do anything with the selection while it remains modifiable that you would be able to do after turning it into a fixed selection. To the extent that you can't, it's a bug. In this case the tool simply is not handling the Alt modifier correctly -- thanks for pointing it out, and I hope I can remember it long enough to get around to fixing it. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
From: Michael Natterer [EMAIL PROTECTED] While doing so I noticed they are all bad and inconsistent. Here is what I think should happen: No brushes available for use with this tool. (brush core) No patterns available for this operation. (clone) doesn't matter, these will almost never be seen Set a source image first. (source core) okay Indexed images are not currently supported.(heal) Healing does not operate on indexed layers Indexed images are not currently supported.(perspective clone) Perspective Clone does not operate on indexed layers Blend: Invalid for indexed images. Blend does not operate on indexed layers Brightness-Contrast does not operate on indexed layers. okay Color balance operates only on RGB color layers. Color Balance operates only on RGB color layers ^ Colorize operates only on RGB color layers. okay Curves for indexed layers cannot be adjusted. Curves does not operate on indexed layers Hue-Saturation operates only on RGB color layers. okay Levels for indexed layers cannot be adjusted. Levels does not operate on indexed layers Posterize does not operate on indexed layers. okay Threshold does not operate on indexed layers. okay -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adobe Illustrator to GIMP palette converter
From: Paul L Daniels [EMAIL PROTECTED] Hello everyone, This is my first ever GIMP related programming project. I've written a stand-alone converter for Adobe Illustrator palette files (.ai) to GIMP palette files. Hi Paul, Thanks for the contribution. Probably the best way to keep this from getting lost would be to file an enhancement request in Bugzilla and attach your code to it. The ideal thing would be to incorporate the code into GIMP itself by working it into app/core/gimppalette-import.c, which is the code that detects and loads palette files in several formats. If you don't feel like doing this, somebody else might be able to, so long as your license is compatible with code being extracted and inserted into a GPL-licensed program -- it does not look to me like that's the case right now, but I may be wrong. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Lanczos algorithm funnyness?
From: [EMAIL PROTECTED] Thanks for your ideas. If you want to play around with Lanczos, you might benefit by looking over the enhancement requests and bug reports relating to it: Bug 162250 Feature Request: Better image scaling algorithms. http://bugzilla.gnome.org/show_bug.cgi?id=162250 Bug 343576 Lanczos resize not the best http://bugzilla.gnome.org/show_bug.cgi?id=343576 Bug 167956 scaling image causes an offset, particularly with Lanczos http://bugzilla.gnome.org/show_bug.cgi?id=167956 Bug 355178 transformation tools with Lanczos interpolation brighten the result http://bugzilla.gnome.org/show_bug.cgi?id=355178 The Lanczos algorithm does not use a 3x3 matrix. The code for Lanczos lives in two places: app/paint-funcs/scale-funcs.c -- for the scale image and scale layer commands app/core/gimpdrawable-transform.c -- for the transform tools As Sven pointed out, this code has been changing pretty rapidly in an effort to make it robust enough for inclusion in the upcoming 2.4 release, so it would be best to look at cvs HEAD if you want to avoid seeing things that are already obsolete. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easier way to convert image into selection
From: Alexander Rabtchevich [EMAIL PROTECTED] Some plug-ins (edge detection for example) provide images as a result. If their result is required as a selection, I new only one way to make it: create layer mask, copy the image into the mask and convert the mask into selection. Is there a shorter way to do it? More common question: maybe it worth improving such plug-ins with an option Create selection? I don't think so, but it might be nice to have a layer to selection filter that would create a selection from the gray values of the active layer. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Customizing GIMP windows and behavior
From: Des [EMAIL PROTECTED] I am new GIMP. We are looking to extend GIMP to fulfill some functionality required by our users, and one of the them is to be able to open an image in three windows, where one window will be the active image which allows the users to add additional paths, and other objects. Adding anything to this image will also add the paths and objects to the second window. On the second window, if the user add any paths or other objects, it just remains in this window. Hmm. It probably wouldn't be incredibly difficult to modify gimp to allow opening an image with multiple views -- but it would be *very* difficult to make those views share some objects but not others. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] http://layers.gimp.org/ is Ugly
From: Shlomi Fish [EMAIL PROTECTED] I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes us look very bad. As people who develop an image editing software we should have at least a bit of rudimentary aesthetic sense. If this were a bug report, the first thing we would do is demand that the bug reporter apologize for using such unnecessarily abusive language, and explain that antagonizing people is not the way to get a problem fixed. Well, it *is* a bug report! -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: rectangle select tool specification
From: Juhana Sadeharju [EMAIL PROTECTED] The handles may confuse users if really the grabbing can be done by clicking in anywhere on the edge. (That is the preferred way to do it since the first interactive graphics system was written.) The handles should be removed. What you are saying makes sense, but there needs to be some visual indication that the rectangle can be modified by moving the edges -- it must not look like a plain ordinary selection. If you can think of a better way of doing this, I believe we would be open to it. Originally we did it by showing the edges of the rectangle in solid black, but I think most people who have tried it feel that it is more pleasant to work with using the four little squares. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: rectangle select tool specification
From: Juhana Sadeharju [EMAIL PROTECTED] Date: Mon, 14 Aug 2006 21:12:05 +0300 If I have multiple views to the same image, is the rectangle tool, the crop tool, etc. visible in each view? For example, I may have one view to the entire 5000x5000 image, and second view of size 500x500 in which I do precision placement of the tools. No, that would be nice, but tool drawing gets applied on a display-specific basis, for any tool. It would be major work to change this. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] on moving toward a 2.4 release
GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004. This was a 9 month release cycle, which is quite reasonable. Howver, it has been over a year and a half since the 2.2 release, and we are still not visibly nearing a 2.4 release. This slow progress is holding up important things, including, especially, GEGL integration. What can be done? The first step is to make a complete list of the remaining critical functionality issues -- the things that must be resolved in order to permit a string freeze. The most reasonable way of making such a list is to use Bugzilla: every critical issue should have a bug report with target milestone set to 2.4, and severity set to Blocker. Things that will not prevent a string freeze should not be marked as blockers at this time. I would like to suggest that we set a hard deadline (say Sept 1) for identifying critical functionality issues -- that is, if an issue does not have a Blocker bug report by then, it will not be considered critical, and will not prevent a string freeze. Once we have a complete list of issues, we can make a concrete plan on how to deal with them, and start moving forward more efficiiently. In any case, something has to be done to blast us out of the current state of near-paralysis. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ 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
Thanks for the comments. I have changed the code so that when a user is modifying an existing rectangle, in Replace mode, the marching ants for the previous selection are no longer shown -- this seemed to confuse almost everybody. Concerning the options gui, it seems clear that improvements are needed, particularly concerning the aspect ratio. However there is a need for more concrete suggestions about what it should look like. The way it was done for the old rect select tool is not viable, in my opinion, but it does not allow for rectangles that can be modified after they have been created. Concerning the aspect ratio, it should be possible to come up with a method that allows easy entry of integer ratios. It isn't clear that we will be able to come up with a menu of standard ratios for 2.4. If we could just use a fixed list, it would be simple, but it seems that it would be necessary to allow people to edit the list of possibilities, and that would require enough machinery that it might not be feasible to add it this late in the 2.4 cycle. For your information, the following bug reports are active concerning the new rectangle-based tools (each of these is marked as a blocker for the 2.4 target): Bug 316156 â selection tool: modifiers pressed before click should only do one thing. Bug 345414 â Should select/crop tool options put controls in an expander? Bug 346683 â New Rect select tool doesn't restore settings Bug 346684 â New Rect select tool setting of the aspect ratio is cumbersome -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] rectangle select tool specification
We are working toward cleaning up for a 2.4 release, and one of the things that needs to be cleaned up is the new tools, including the ones based on GimpRectangleTool, that is, the new rectangle select, ellipse select, and crop tools. In order to fix problems, we need bug reports that describe them. However, Sven feels that there is no point in filing bug reports right now, because there is no specification of how the tools are *supposed* to behave. This document is aimed at providing such a specification. If a tool doesn't work as described here in some way, or if you think that the operations described here are not the way the tool *ought* to work, then you should file a bug report. (Of course, it is also possible that this document will not be entirely perfect itself. Suggestions for improvements or clarifications, or questions, are welcome.) I will focus here on the rectangle select tool. Almost all of its features also apply to the ellipse select and crop tools -- with a couple of exceptions. The (New) Rectangle Select Tool The Rectangle Select tool is used for making rectangular selections, possibly feathered. It is intended to be both simple to use and powerful enough to allow fancy things when they are needed. The basic operation is dragging out a selection, by clicking and dragging. This is done in the same way as with the old rect-select tool. Once you have dragged out a rectangle, the selection exists, and you can switch to a different tool, or act on the selection in any way you please. An important different from the old tool is that the rectangle you get is modifiable, as indicated by handles at the corners. You should be able to click on any corner or edge and drag it -- the cursor should change to indicate when dragging is possible. Clicking *inside* the rectangle, and then dragging, will move all of the rectangle edges simultaneously without changing the shape. Clicking *outside* the rectangle and dragging will start a new rectangle. The results are different if you click and release without dragging. If there is an existing rectangle (with handles visible), then clicking without dragging converts it into a fixed, unmodifiable selection, with no handles. (This is essentially useless, and only happens for consistency.) If there is no existing rectangle, and you click inside an existing selection, then a new, modifiable rectangular selection is created, whose bounds are just large enough to completely enclose the previous selection. If instead you click *outside* the existing selection, then the selection is removed. After you have pressed the mouse button, while you are holding it down and dragging, the marching ants revert temporarily to follow the previous selection. This is useful if you are working in Add, Subtract, or Intersect mode, but may be confusing in Replace mode. The rectangle can also be modified using a set of controls located inside the tool options. (By default, these are hidden inside an expander.) You can use spinbuttons to enter values for the width, height, aspect ratio, or coordinates of the corners. Modifier keys As with other tools, the Rectangle Select tool can be switched between Replace, Add, Subtract, and Intersect modes, either by using buttons in the tool options, or by using the Shift and Control modifiers in the standard combinations. Modifier keys are only effective in changing mode when pressed *before* the mouse click that starts a new rectangle. They can be released after the mouse click without changing the mode of the operation. Modifier keys change the click-and-drag behavior slightly. When modifiers are used to change the mode to something other than Replace, then clicking always starts a new rectangle -- it never modifies the existing rectangle. Note that this applies only when the Mode is changed using modifier keys, not when it is changed using the buttons in the tool options. When you modify an existing rectangle by dragging an edge or corner, you don't need to press any modifier keys. The operation performed for a given rectangle (i.e., replace, add, subtract, or intersect) is never changed simply by moving the edges of the rectangle. Keyboard Control Only a few keys affect this tool. The Esc key cancels the operation, and causes the selection to revert to its state before the tool was activated. The Return key makes the selection unmodifiable, just like clicking inside without moving. The arrow keys move the rectangle without changing its shape -- holding down Shift increases the movement increment. Tool Options Mode: as described above Antialiasing: not available for this tool, shown for consistency Feather edges: does not need describing here Auto shrink selection: If this option is activated, then, after you drag out a rectangle and release the mouse button, the rectangle will automatically be shrunk as much as possible such that the border outside the rectangle is all the same
Re: [Gimp-developer] rectangle select tool
Jimmac, Thanks for your detailed, thoughtful, and very helpful critique. I see the hard work you've put into this. I'm happy to see you learn your way around GIMP codebase. I like the cooperation effort involved. But expect some harsh reactions from existing userbase. Well, my experience has always been that changing *anything* in the UI of an application, no matter how broken, leads to harsh reactions from users who have learned to exploit the breakage -- so it won't come as a surprise. This is not intended to be dismissive of complaints -- the whole effort was largely driven by complaints -- but just to point out that it is never possible to make everybody copletely happy. The bezier selection is now very similar in behavior with the new selection tools. You tweak a shape first and then apply it to form a regular marching ants selection. In bezier selections tool you use the modifiers to add to or substract from existing selection when _applying_ the selection (pressing Alt+Enter or Alt+Click Inside to subtract, Shift +Enter or Shift+Click inside to add...). You don't press the modifiers before you start defining the shape. Using this for these selection tools as well would from my point of view avoid the shortcut clash problem. First: the new tools actually used to work the way you describe, and the behavior was changed in response to complaints from users (including you, iirc!) who wanted to be able to do things like sweep out a rectangle and then hit Ctrl-C to copy the contents without remembering to click inside the rectangle first; etc. It would be easy to change it back, but the current behavior seems to be more appealing to most people. Second: for me personally, I am generally opposed to overloading modifiers. It allows speedups for experienced users, but really messes with the minds of new users. I think there is a better solution to this problem: to allow GIMP to make use of a new modifier key (call it TOOL), and dedicate TOOL-modified keystrokes exclusively to controlling tool behavior. Then you could, for example, toggle the aspect constraint by hitting 'TOOL-s' or something. But this is a topic best discussed in depth elsewhere. On the other hand, rectangular and elliptical selections in cvs HEAD are active even before they are applied. Maybe that's a good thing. Although I found it a little distracting when I had an existing selection and tweaking the new one blinked through the old one. Kinda similarly confusing as the dual-use modifiers ;) But perhaps it's just a bug. It is intentional. I think after you get used to it, it is actually helpful in many cases, but if too many people find it confusing, it can be changed. If you go for shift+drag for adding new selection behavior as it is now in cvs HEAD, allow me to start the drag over an existing selection in progress. Currently that starts editing it as if I didn't hold shift. Good point. I will change this. There's also something I think would make the tool more usable. The cursor changing bounds are image-resolution-bound, not view-resolution-bound. I work with 22x22px canvases. Even when I'm zoomed in, no selection I make shows the apply selection cursor in the center as the selection border takes all the space every time. The feedback I'm given is that I cannot apply the selection in progress by clicking inside. Ah, that's a bug. I'll fix it. It's too early to tell if I can get used to this new behavior. Even though the immidiate reaction was dang give me my tools back! I see the benefit for a lot of casual GIMP users. It probably was a serious-enough problem to require routine users and Photoshop converts to forget and learn something new. I guess the question, in the long run, is how often you find yourself happy to be able to modify an existing selection, versus how often you find yourself thinking that what you are doing would have been easier the old way. Every change is a tradeoff: I hope this one is a good tradeoff overall, but only time will tell. P.S.: I also noticed the selections are broken when modified with a keyboard. The marching ants nor the final selection reflect to the keyboard-set position. I will investigate, and fix any problems I can find. Thanks again for your feedback, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] rectangle select tool
Okay, the old rectangle select tool has finally been removed from cvs and the new, adjustable, one has taken its place. It is hopefully in something very close to its final form now. The rectangle tool project has been a rather long and quite cooperative effort. I started it, using the old crop tool as the take-off point; Edhel took over and rewrote the code completely, turning it into an interface and converting the crop and ellipse tools to use it; Neo provided guidance and feedback all along; Mitch provided advice and lots of bug-fixes; and I came back at the end to wrap up a few loose ends. I won't say anything about how to use the new rectangle select tool here, because it is supposed to be intuitive and discoverable -- to the extent that it behaves contrary to your expectations, that is probably a bug. There are however just a couple of things worth noting: 1) The Shift and Control keys are no longer usable to constrain the rectangle to be square, and to expand from a center-point. Instead there are tool options that do these things. The overloading of Shift and Control was always difficult to deal with in the old tool, and in the new tool with movable edges, it turned out to be completely impossible. 2) You will probably get a GIMP-critical error the first time you run cvs-gimp after this change, because it tries to restore the toolbox to its previous state and finds that one of the tools it is looking for does not exist. This is not a crasher (at least for me), and it should only happen once, so just ignore it. If you find something that is broken or doesn't seem to work right from this point, please file a Bugzilla report. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] SOC: getting a CVS account
SOC students, if you don't already have a Gnome CVS account, you should apply for one. You can find instructions on how to apply at: http://developer.gnome.org/doc/policies/accounts/requesting.html Before you apply, you should familiarize yourself with: http://developer.gnome.org/tools/cvs.html When you apply, ask for an account with full commit access, and include an explanation something like, I am a Google Summer of Code student working on a project involving GIMP, and I am applying with the approval of Sven Neumann, the maintainer of GIMP. Please CC me on the email you send to [EMAIL PROTECTED] asking for access -- I'm not certain that all the SOC students are on this list, so it's the only way I can find out if anybody has been left out. And please let me know if you have any problems -- the system has sometimes been glitchy in the past. Finally, a caution: full CVS access gives you write access to every module in Gnome. Please don't abuse it -- don't commit any changes without having discussed them with the maintainer of a package or some other authority. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] SOC: status update
A few notes now that things have settled down a bit. SOC students and their mentors should have discussed things by now, and be well on their way to working out a plan. My understanding is that Google should soon be sending the initial $500 payments to students. The next established deadline is June 26, when Google will want to get mid-program evaluations of student progress. These need not be very extensive -- a paragraph or two will usually suffice. The main question will be whether the student has done enough to earn the mid-term payment of $2000. For students, hopefully your mentor has given you a good idea of what you should be doing right now. Probably the first goal for almost everybody should be to make sure that you can build GIMP from CVS HEAD -- that's often not a trivial thing, and it is necessary in order to be able to write usable code. Also, you should familiarize yourself with the GIMP coding rules, as described in http://developer.gimp.org/HACKING , and with the GIMP bug reporting system, as described at http://developer.gimp.org/bugs.html . It may be worth your while to look over a few bug reports, to get an idea what they look like and how they are typically handled. At some point, for most of you, your own contributions will give rise to bug reports that you will need to handle. Right now GIMP CVS contains two active branches, the stable branch that produces 2.2, and the development branch that produces 2.3. In the near future the 2.3 branch will be stabilized into GIMP 2.4, so it is not a good place for speculative development at the moment. Sometime around the middle of June a new branch will be created, which can be used for SOC-related code. The plan is to keep it tightly synchronized with the 2.3 branch, until the next development branch, presumably 2.5, is spun off, at which point it will hopefully be merged with the SOC branch. This is a little bit tricky but we think it will work if we are careful. In any case, before committing any code to the main CVS branches, you should discuss your plans with your mentor. As a rule, if you are working on files you have created yourself (for example, a new tool), you have pretty much a free hand, so long as you follow the GIMP coding rules and don't break the build. If you are working on files that affect other things, the code should probably be reviewed before you commit it. In any case, you will need to have permissions to make changes in Gnome CVS by mid-June -- we will try to get this for you in the next few days. For students, even though you have one official mentor, we hope that you will treat every GIMP developer as a secondary mentor, and feel free to come to #gimp with any difficulties you run into. All of us are interested in you and what you are doing, and welcome the chance to interact with you -- so don't feel shy about coming to the channel with questions that you think might be naive. Finally, please let me know about any questions you have or any issues that arise. In particular, if there are any problems in mentor-student interactions (after all, we are only human), I hope you will let me know about them and give me a chance to try to smooth things out. Good luck! -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Overview of SOC projects
We welcome seven students who will be supported this summer by the Google Summer of Code 2006 program. Here is a shapshot of who they are and what they will be working on: Hendrik Boom, Vector layers in GIMP, with Simon Budig as mentor. Hendrik will be starting as an undergraduate in Computer Science at Concordia University in the fall. Philip Lafleur, New/extended brush System, with Sven Neumann as mentor. Philip is a Computer Science undergraduate at North Carolina State University. He has already made important contributions to GIMP, including the code that allows transform tools to show previews inside the image (as opposed to just showing grids). Pedro Alonso Ferrer, Vanishing point cloning, with Manish Singh as mentor. Pedro is a Computer Science/Engineering undergraduate at Pompeu Fabra University in Barcelona. Kevin Sookocheff, Healing brush, with Bill Skaggs as mentor. Kevin is a Computer Science graduate student at the University of Saskatoon. Scott Lembke, Ruby-GIMP scripting, with Kevin Cozens as mentor. Scott is a Computer Science undergraduate at University of Minnesota Morris. Andrey Smorkalov, User interface improvements, with Bill Skaggs as mentor. Andrey is an IT undergraduate at Mari State University in Russia. Divyanshu Vats, Wavelet-based imaging/Jpeg2000 support, with Simon Budig as mentor. Divyanshu is an Electrical Engineering/Mathematics undergraduate at University of Texas Austin. It is worth noting that in supporting these projects, Google is contributing over $30,000 to GIMP development -- a magnificent and truly appreciated gesture. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] alignment tool
I have just committed a set of major changes to the UI of the alignment tool, which make it work mostly like alignment tools found in vector graphics programs, and hopefully make it esier to use. The way to use it now is to select layers by clicking on them or sweeping out a rubber-band rectangle that completely encloses the layer bounds. Hold down Shift to add the newly selected items to the set already selected. (Only Visable itmes are selected.) Then press a button in the Tool Options to bring all the selected items into alignment with each other. Selected layers are indicated by four small squares at the layer corners. Please try it out and let me know if you find bugs -- I'm sure there are a few. It occurred to me, as I was setting this up, that there is a logical similarity between selecting things for this tool, and linklng things using the Layers dialog -- and that there might be advantages in merging the two things, which wuold actually be quite easy. It would be simple to make the tool set items as linked when they are selected, and to have the alignment commands act on the set of items that are currently linked. This would have the advantage that after aligning items, you could easily move or transform them as a group, without having to mess around with the layers dialog. It would take a little infrastructure to make this all work smoothly, but nothing that would be difficult. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp connotations ?
Florent Monnier wrote: What are these funny connotations in the English language ? Could someone explain me ? The results returned from Googling for define: gimp include these: # lameness: disability of walking due to crippling of the legs or feet # limp: walk impeded by some physical limitation or injury; The old woman hobbles down to the store every day wordnet.princeton.edu/perl/webwn * Gimp is a usually derogatory term used to refer to a (normally male) sexual submissive, typically dressed in black leather (or rubber) and wearing a mask of the same material. This apparel emphasises sexuality by drawing attention to the crotch and chest. Sadomasochistic practice often features in the notion of the gimp, with a partnership between gimp and dominatrix (or dominant). en.wikipedia.org/wiki/Gimp_(sadomasochism) The word gimpy is more common, it means noticeable lameness or crippled: disabled in the feet or legs. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp certification
I think most of the people in the GIMP community would find this obnoxious -- but if LPI were willing to offer consulting fees in the $10,000+ range, there might be some curiosity. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: three questions for the LXF article
Michael J Hammel wrote: 1. Developer Wishlist A lng time ago there was a wish list of features for GIMP. Is there any such thing now, specifically as seen from the developers point of view? The real wishlist is the collection of enhancement requests on Bugzilla. You can also look at some of the suggestions that were proposed as projects for the Goggle Summer-of-Code program, at http://wiki.gimp.org/gimp/SummerOfCode These do not, however, include features that will depend on the GEGL framework that is planned to be used for the next major version of GIMP, which include effect layers, layer groups, and 16-bit-depth layers. 2. The 5 most annoying GIMP bugs I'll skip this one. 6 (sic). Important bug fixes provided by non-core developers Anyone with input on fixes supplied by someone who just sort of came out of the blue? The magazine feels this is important to encourage others who aren't currently actively involved in making important contributions. There isn't really a hard distinction between core and non-core devlopers, more of an exponential curve of involvement. Also, most of the people who are more or less heavily involved started out by submitting a patch for something that ame to their attention: me, for example. If you want something more concrete, you can look through the ChangeLog in the source code, searching for the term patch, and you will see brief descriptions of things submitted by a couple of dozen people who don't contribute regularly to GIMP. The most common are probably fixes or improvements for plug-ins, but there are other things too. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
