Re: [Gimp-developer] 2.6 roadmap
Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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
On 10/27/07, Valerie VK [EMAIL PROTECTED] wrote: Okay I want to clear this up: GEGL *is* coded (see www.gegl.org), and already in use by a few different applications. Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do. It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. This makes sense. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it. Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases. Yes, that would be a good idea. It's easy to get lost in the GIMP code, so a way to limit what developers need to look at would probably attract more developers. It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way. Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;) Actually I think I didn't explain the difference between adjustment layers and layer effects. Adjustment layer: a layer that modifies the layers below it, without actually contributing pixel data. An adjustment layer as used in Photoshop, has a mask, but no pixel data. http://www.phong.com/tutorials/adjust/ provides some examples, including eg. Curves adjustment. Layer effect: an effect attached to a layer -- for example, Drop shadow is a layer effect provided by Photoshop. Takes the layer pixel data and applies some effect to it. May have a mask, and does not have its own pixel data, so the only difference is the way it's attached to a specific layer. Peter suggested here: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html that layer effects could be thought of (and displayed as) a stack per-layer, sitting underneath the layer. ___ 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
Hi, On Sat, 2007-10-27 at 01:32 -0700, Valerie VK wrote: Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how? Maybe this should be developed before a Gimp roadmap is defined? We have already developed this roadmap for GEGL integration. For the last years this has been the major topic whenever GIMP developers met. Just calm down a little and give Mitch and Pippin some time to present their plans. GEGL integration is going to take a while. But it is a migration process and it will certainly span several release cycles. Sven ___ 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...
- Original Message From: peter sikking [EMAIL PROTECTED] To: Gimp Devel List gimp-developer@lists.XCF.Berkeley.EDU Sent: Friday, October 26, 2007 6:42:17 PM Subject: [Gimp-developer] 2.6 roadmapping, the UI part of it... Roadmapping what over-arching UI topics will be dealt with in this release will be necessary to have UI specifications ready _before_ implementation starts. During 2.4 it has already been shown that having a UI spec encourages new developer participation and that can only be a good thing. I think to get new developers it will be necessary to adopt a more active recruitment policy. The current plan for 2.6 is necessary but not inspiring for new developers unless they know how Gimp will benefit from this in the long run- and showing is better than telling. So: extend the roadmap to versions 2.8 and 3.0. Create convincing mockups, and post them. Then once everything is in place, go public. Send press releases to websites such as linux.com and slashdot, explain and show the planned changes, and ask for help. Paste a big wanted ad on the website. Working on the problems we have easily moving the contents of selections, you pretty soon hit the floating selection mechanism. We already identified in our evaluation that as something that needs to be transformed from a headache that makes you think into something that you never notice but just works. Just as important is the layer boundary problem - this needs to be automated. But in both cases, I think even just committing to fixing it in a future version will benefit the project. Even if nothing is visible in the 2.6 release itself. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Message error in gimp 2.4
Hi, I'm a professional animator and use the Gimp-gap tools as my principal tool. Since I migrate to Linux ubuntu everything was work just perfect. In my point of view, gimp gap is the best toolkit to the traditional animator (like me). Congratulations for this great software The Gimp. But, in the new version of Gimp, the gap tool are sending a Message error: GIMP Error: O Procedimento 'gimp-image-delete' foi chamado com um ID inválido para o argumento 'image'. O mais provável é que um plug-in esteja tentando operar em uma imagem que não existe mais. (in the Portuguese version) it's something like: the 'gimp-image-delete' was call by a invalid ID to the image argument. The most probable is, a plug in are trying to operate a image that doesn't exist anymore. The image convert aren't working. The duplicate continue, the navigation resources (next frame, previous...last...) works, but send the same error message. The playback tool works perfectly Are this problem already fixed? I'm using Ubuntu 7.10 in a Intel Core 2duo I want to help you in the development! You have anything in the roadmap about animation? Tell me. What an animator can do for you? =) Sorry by the caveman's English! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Message error in gimp 2.4
Hi, On Sat, 2007-10-27 at 12:14 -0200, Daniel Pinheiro Lima wrote: I'm a professional animator and use the Gimp-gap tools as my principal tool. Since I migrate to Linux ubuntu everything was work just perfect. In my point of view, gimp gap is the best toolkit to the traditional animator (like me). Congratulations for this great software The Gimp. But, in the new version of Gimp, the gap tool are sending a Message error: GIMP Error: O Procedimento 'gimp-image-delete' foi chamado com um ID inválido para o argumento 'image'. O mais provável é que um plug-in esteja tentando operar em uma imagem que não existe mais. (in the Portuguese version) it's something like: the 'gimp-image-delete' was call by a invalid ID to the image argument. The most probable is, a plug in are trying to operate a image that doesn't exist anymore. What version of gap are you using? We have released an updated version of gap 2.2 before we did the GIMP 2.4 release. You shouldn't get this error with this version. But of course we might have missed a problem. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Message error in gimp 2.4
Quoting Daniel Pinheiro Lima [EMAIL PROTECTED]: ... But, in the new version of Gimp, the gap tool are sending a Message error: The image convert aren't working. The duplicate continue, the navigation resources (next frame, previous...last...) works, but send the same error message. The playback tool works perfectly Are this problem already fixed? Version 2.2.2 of the GAP should fix the problem. You might still get an error message on some apply filter on layer(s) operations, but they should still work. I think such errors are the result of new iter_ALT filters needing to be rebuilt and I hope to be addressing that soon. I want to help you in the development! You have anything in the roadmap about animation? The main GAP developer is reportedly working on updating the FFMPEG encoding as well as making some storyboard changes. I have just started working on OGG support and am interested in updating the audio capabilities. Tell me. What an animator can do for you? Try to get Ubuntu repositories to provide an up-to-date version; last I checked, their version was over two years old. If you have not already learned how to build the GIMP and GAP from the SVN source, it would be helpful if you did so that you could provide feedback and report bugs. There should be some updates coming up in the next few months and testers would be appreciated. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I translate new featues of gimp 2.4.0?
Hi, On Sat, 2007-10-27 at 10:48 +0900, Choi, Ji-Hui wrote: On 10/27/07, Martin Nordholts [EMAIL PROTECTED] wrote: That page is maintained by the GIMP developers and I see no problem with you translating and hosting a version of that page by yourself. Thank you for your kindly reply, Martin. :-) Ah.. i am late to check this mail. Okay Ji-Hui, if you need a assist, give me mail without hesitancy. And, a few hours ago i sent mail to you in Korean. Sincerely, -- After super, can you drive me and the kids to New York in your car? That's what I came for. -- Kay Adams and Tom Hagen, Chapter 32, page 443 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] next generation size entries
Moin, I would like to propose another project. Whether we want this for 2.6 or later pretty much depends on whether we find someone who wants to work on this. But I think we absolutely need this if we want to improve our user interface. What I am talking about is size entries. Widgets that allow the user to specify a size either in pixels, physical units or relative to some other size. Such widgets usually show up in groups and the relationship between them needs to be considered as well. We currently have a widget for this and it is (a) cumbersome and error-prone to use from a developer point of view (b) cumbersome to use from a user point of view (c) ugly and needlessly large It would be great if we could develop something to replace all our size entries. We want something that is flexible enough to cover the complex cases (see for example the Print Size dialog or the SVG import plug-in), but it should still be straight-forward to use for the simple case. We definitely need an architecture here that follows a model-view concept. Code that deals with changes to sizes shouldn't have to care about the widget that the user actually deals with. At some point I have experimented with something into this direction. The result is GimpUnitStore and GimpUnitComboBox as found in the app/widgets directory. Definitely far from what we need, but perhaps looking at this code can give some ideas about how one could tackle the problem. On the user interface side we would want a variety of widgets that can be used with the size models. Scales/sliders should be supported as well as spin-buttons with unit menus and entries that allow the user to input text such as 4.5 cm. I think it is important to first get a very good idea of what the requirements are. It would be good to have a list of use cases and a pretty good specification of the user interface. Then we can think about a model to cover this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] about carol (2nd try)
Moin, we have had this thread before and last time there were a lot of developers who expressed their opinion that Carol is not any longer acceptable as a member of the GIMP team. Last time we have had this thread, it was up to Yosh to respond and he asked for a break because he was busy back then. As far as I can see, Yosh did not respond so far. While Carol has stopped posting to our mailing-lists, which is good, she is still very active in our IRC channel #gimp. Lately things are really getting out of hands. She is insulting people, preferably developers and long-time contributors. This is absolutely inacceptable. Yosh, as far as I know you are in charge of administrating the IRC bots that are repsonsible for giving operator status to known users. I demand that Carol is removed from the list of users that get this priviledge. We can discuss further actions when this has happened. But this absolutely needs to happen now. We can not tolerate this any longer. Sven ___ 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...
I agree what Peter Sikking wrote. It seems -to my user pov- that cairo migration is something that will provide new methods for addressing some maybe menor, but longstanding UI annoyances, and it's great putting that migration in the first place of the roadmap. What I'd like to propose is a change in the UI for 2.6 (part of it is already possible with the current interface) to gain more screen space. The first thing I make every time I have a fresh install of gimp is taking the tool options to the right docker, and made a minor reorganization of tabs. Then I can stretch the toolbox to a two-column layout so I gain a lot of screen space to work. I'd like to propose at least that change as the default panels arrangement. It gains space, and it makes the interface more familiar for people who worked with other image manipulation packages. Plus, it's a totally reversible change, that users that like the current layout can roll back. The other part of my idea is a possible solution of the behaviour of the application when there is no image open. I developed the idea further in my blog, so I invite you to read it and tell me if this change is feasible. http://www.blog.ohweb.com.ar/?p=59 What is not covered there, but certainly would be an interesting idea to develop, is adding to those changes an optional wrapper window for the opened documents. I wouldn't use it, but it's the number one rant about gimp's interface. Imo, it wouldn't have too much impact in the program usage (because it would be working just as the other way, but having a wrapper window for the opened documents) so it wouldn't be a problem for documentation, for instance. Anyway, I'm one of the guys who think it's pretty useless so I won't mind if there is no gray background :-) Of course I don't want to go over Peter and the UI team (this proposal was already sent to the UI brainstorming blog), so I propose this for discussion and I'd really like to know what do you think about it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] THE ALMIGHTY ALT KEY
Hi, On Sat, 2007-10-27 at 11:25 -0700, [EMAIL PROTECTED] wrote: The Alt key used to modify the rectangular and oval selection tools so that it moved the selection frame itself but not it's contents. Now you can just move the selection without pressing the Alt key. What's your point? And please reply to the list. Sven ___ 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...
Hi, On Sat, 2007-10-27 at 15:53 -0300, Guillermo Espertino wrote: What I'd like to propose is a change in the UI for 2.6 (part of it is already possible with the current interface) to gain more screen space. The first thing I make every time I have a fresh install of gimp is taking the tool options to the right docker, and made a minor reorganization of tabs. Then I can stretch the toolbox to a two-column layout so I gain a lot of screen space to work. I'd like to propose at least that change as the default panels arrangement. It gains space, and it makes the interface more familiar for people who worked with other image manipulation packages. Plus, it's a totally reversible change, that users that like the current layout can roll back. The other part of my idea is a possible solution of the behaviour of the application when there is no image open. I developed the idea further in my blog, so I invite you to read it and tell me if this change is feasible. http://www.blog.ohweb.com.ar/?p=59 This looks pretty much like the solution that we have been discussing for quite a while already. The mockup is very nicely done also. In general I like this change. But we absolutely need to discuss how we want to handle multiple images with this approach. Things are getting complicated as soon as you have more than one image window. You can try the transient-docks feature (see gimprc). It makes the toolbox and dock windows transient to the active image window. Unfortunately this approach has shown to not work well with most window managers. But perhaps this is something that can be figured out. Sven ___ 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...
BTW, you can already try the unified menu if you pass the --disable-toolbox-menu option to configure. You will have to do this with a fresh installation though, or things won't work correctly. Currently this is only done when building on OS X for the Quartz GTK+ backend. But we will want to consider making this the default for all platforms. However we then absolutely need a window to stick the menu to. This can probably best be done as outlined in your mockup. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] finishing stuff for 2.6
Hi, while we are talking about the roadmap. There are some tasks left unfinished that we should set on the agenda. At least so that people realize that there's work left to be done. Perhaps we can attract some developers who want to fix them. Heal Tool - The heal tool needs to be finished. Currently it only allows stamping but it should be possible to actually paint with the heal tool. We have already discussed this earlier here. As far as I understand this mainly needs someone to actually finish the work. Some good understanding in the math involved is probably useful. Sample Points - Sample points are in 2.4 but they are not quite done yet, It's hard to discover how to set them and how to manipulate them. The Sample Points dialog only deals with a fixed number of sample points. And I think that Sample Points don't support sampling a region as the Color Picker tool allows you to do. That would be pretty important though to make them useful for color corrections. Needs some thoughts on the UI. Depending on what comes out of this, we might get away with only some relatively simple changes. Foreground Select Tool -- The SIOX crew has developed a refinement brush for the foreground select tool (see siox.org). That would certainly make the tool a lot more useful. There is even some code for this already in our code base, it is just not used yet. This involved getting into contact with Gerald or one of this students. They should be able to explain what needs to be done. We can then review it from a user interface point of view and implement it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] pushing color management further
Moin, another task that should be put on the agenda, perhaps even for 2.6: Currently only the image display is color-managed. The color selectors and the previews in the core and in plug-ins aren't. This should be changed and it should be possible to reuse the existing ColorDisplay filters to do this job. Reusing the display filters for this is probably the way to go. We would hovever have to make an optimization in the lcms module then. Currently each display filter loads the color profiles and creates a transformation object to convert between colorspaces. If we extend this to all previews and color selectors, then we will have to avoid this. So either we reuse the same display filter for all previews or we introduce a transformation cache. Perhaps doing both would be the best solution as multiple displays on the same image would also benefit from a transformation cache. If anyone wants to work on this, please talk to me. I have some more thoughts spent on this already. So far I only wanted to have this brought up so that it isn't forgotten Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] floating selections and other annoyances
Moin, yet another list of tasks that we should IMO commit ourselves to: Floating Selections --- We should try to remove floating selections from the user interface. It should be possible to completely hide this implementation detail. This needs a thorough analysis first. How exactly should all the case be handled where a floating selection is involved? Alpha Channel - Bug 486902 (http://bugzilla.gnome.org/show_bug.cgi?id=486902) makes an interesting suggestion on how to remove the burden of adding/removing alpha channels to layers. This should be looked at and it might turn out to be relatively simple to implement. Layer boundaries It would be nice if layers would enlarge themselves when needed. It is annoying that the user has to care about this. This should be looked at from a user perspective first. When we have figured out the details (like how to align a text layer if it doesn't have a border), we can look how to best implement it. GEGL supports sparse tiles, doesn't it? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating selections and other annoyances
On 10/27/07, Sven Neumann [EMAIL PROTECTED] wrote: Layer boundaries It would be nice if layers would enlarge themselves when needed. It is annoying that the user has to care about this. This should be looked at from a user perspective first. When we have figured out the details (like how to align a text layer if it doesn't have a border), we can look how to best implement it. GEGL supports sparse tiles, doesn't it? At the moment the GeglBuffer system is only catering to the immediate needs of rendering from input buffers (what would be considered drawables in GIMP) that do not change size after they have been initially constructed. Internally in the GeglBuffer itself this limitation is manifested by GEGL only keeping one (huge) buffer for each pixel format, and handing out pieces of this as buffers are constructed. This is something that is open for change, and I very much subscribe to the idea that layer boundaries should be dealt with automatically. Another part of GeglBuffer that is lacking in this regard is that it doesn't automatically replace a fully erased tile with a clone of the blank tile of the buffer, similar optimizations could probably be applied for tiles that have completely uniform color. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] finishing stuff for 2.6
On 10/27/07, Sven Neumann wrote: Sample Points - Sample points are in 2.4 but they are not quite done yet, It's hard to discover how to set them and how to manipulate them. The Sample Points dialog only deals with a fixed number of sample points. And I think that Sample Points don't support sampling a region as the Color Picker tool allows you to do. That would be pretty important though to make them useful for color corrections. Last time I asked in #gimp I was told that sample points are not color managed too. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
On 10/27/07, Sven Neumann wrote: On the user interface side we would want a variety of widgets that can be used with the size models. Scales/sliders should be supported as well as spin-buttons with unit menus and entries that allow the user to input text such as 4.5 cm. In some cases some simple math equations support would be useful. E.g. being able to input 4.5 cm + 2.7, press Enter and see 7.2cm. Is it part of the plan? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a first step towards Cairo drawing
Moin, as a first exercise in Cairo drawing, I would like to start with something very simple and port GimpScrolledPreview to Cairo. There's really only one single thing here that we would want to use Cairo for and that is drawing the outline in the navigation popup. Here's a screenshot of what it currently looks like: http://sven.gimp.org/misc/preview-navigation-popup.png Note that we use the same popup in the bottom right corner of the image window. Currently we are drawing the rectangle using XOR. When we switch to Cairo this should probably change. But I am not entirely sure how to best draw a nice-looking outline that is visible on all images. Perhaps some of the artists out there could draw me some nice mockups? I've picked this example because it is simple but still gets us directly into the problem of replacing the current XOR drawing with something nicer. Looking forward to your comments... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] finishing stuff for 2.6
Hi, On Sun, 2007-10-28 at 00:38 +0400, Alexandre Prokoudine wrote: Last time I asked in #gimp I was told that sample points are not color managed too. Currently nothing except the display is color-managed. As far as I can see, things like the color picker and also sample points only need to be aware of color-management for the display of CMYK values. Currently this conversion is done using the naive RGB-CMYK conversion ignoring the configured CMYK profile. This should indeed be addressed. This is part of the Finish color management task but it is something that I omitted there. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating selections and other annoyances
Hi, On Sat, 2007-10-27 at 21:26 +0100, Øyvind Kolås wrote: Another part of GeglBuffer that is lacking in this regard is that it doesn't automatically replace a fully erased tile with a clone of the blank tile of the buffer, similar optimizations could probably be applied for tiles that have completely uniform color. That would indeed be very interesting for GIMP and I would very much welcome if someone could try to address this in GEGL soonish. Perhaps we also need to make a list of GEGL tasks that we should publish together with the GIMP tasks list? This might attract some more developers to GEGL as well. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] code of conduct moderator?
Hi Everyone I have contributed precisely nothing to the Gimp. I am just some twit learning to program, hoping to be of use. Having said that, I don't know of any specific details about what Carol has said or done but I am sadly familiar with thread #1 on this topic, I found it before I joined a Gimp list, it is easily found within the search results from Google. Here is what I suggest(keeping in mind my vast ignorance): Let's forgive and forget whatever Carol has said. However would it be a good thing to elect a moderator to guide and if need be enforce etiquette? Open source developers have some how found the time, on this brutal planet, to write such great software with little or no compensation. This should really be the 1st wonder of the world. Motivation and moral are likely a big part of this-Patrick Sven Neumann wrote: Moin, we have had this thread before and last time there were a lot of developers who expressed their opinion that Carol is not any longer acceptable as a member of the GIMP team. Last time we have had this thread, it was up to Yosh to respond and he asked for a break because he was busy back then. As far as I can see, Yosh did not respond so far. While Carol has stopped posting to our mailing-lists, which is good, she is still very active in our IRC channel #gimp. Lately things are really getting out of hands. She is insulting people, preferably developers and long-time contributors. This is absolutely inacceptable. Yosh, as far as I know you are in charge of administrating the IRC bots that are repsonsible for giving operator status to known users. I demand that Carol is removed from the list of users that get this priviledge. We can discuss further actions when this has happened. But this absolutely needs to happen now. We can not tolerate this any longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SPAM-LOW: floating selections and other annoyances
Hi, Sven Neumann wrote: Floating Selections --- We should try to remove floating selections from the user interface. It should be possible to completely hide this implementation detail. This needs a thorough analysis first. How exactly should all the case be handled where a floating selection is involved? Unfortunately I have very little time to devote to coding currently, and haven't really been keeping up with the changes here. In 2.4 The user can no longer use a selection tool to tear off and float a selected region, am I right? If you want to select and move a region you now have to manually float with either ctrl-shift-L or do Ctrl-X, Ctrl-V, correct? If floating selections are to be removed, how do you anticipate a user selecting a section of an image and moving it? By creating a proper layer from the selection? Thanks, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pushing color management further
Hi, Sven Neumann wrote: either we reuse the same display filter for all previews or we introduce a transformation cache. Perhaps doing both would be the best solution as multiple displays on the same image would also benefit from a transformation cache. I've implemented a Transform Cache in PhotoPrint - I think I've mentioned before that as a signature for matching the correct transform I use an MD5 hash of both source and destination profiles (excluding headers), as well as the rendering intent. Just throwing that in, in the hope it might be useful. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SPAM-LOW: floating selections and other annoyances
Hi, On Sat, 2007-10-27 at 23:11 +0100, Alastair M. Robinson wrote: In 2.4 The user can no longer use a selection tool to tear off and float a selected region, am I right? If you want to select and move a region you now have to manually float with either ctrl-shift-L or do Ctrl-X, Ctrl-V, correct? Not quite. You can still float and move a selection using Crtl-Alt-Drag. Perhaps we need to make this easier again... If floating selections are to be removed, how do you anticipate a user selecting a section of an image and moving it? By creating a proper layer from the selection? I didn't suggest floating selections to be removed. They will be kept, but they will be kept as what they were supposed to be from the very beginning: an internal implementation detail that the user doesn't need to know about. This change has not yet been laid out in all details, but it looks promising. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
