Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Hi, On Sun, 2007-10-28 at 19:20 -0300, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this? gedit would be an example of a GTK+ application that uses tabs to handle multiple documents. 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, Sven Neumann escribió: Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this? Yes, we're talking about two different things :-) I meant detachable tabs and different views like Opera's or Scribus' ones. Not JUST tabs. I (and as far as I could understand the other people that mentioned Opera) was talking about the ability to show the tabbed windows as tileable windows in the workspace (QT and Windows have that kind of options for child windows). That is important when you need to have side by side comparisions of different images (examples of this are grading and gama matching, two views at different zoom ratios, etc.) Is that possible with the current GTK widgets? Gez. ___ 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 Mon, 2007-10-29 at 04:47 -0300, Guillermo Espertino wrote: Yes, we're talking about two different things :-) I meant detachable tabs and different views like Opera's or Scribus' ones. Not JUST tabs. How is that different? We already have detachable tabs in the GIMP user interface. So why are you asking if this is possible? Making it possible to have several images in one image window using tabs would be a nice improvement, IMO. It needs some thoughts on the details but perhaps this can be done off-list to that we can concentrate on getting the roadmap for 2.6 done? 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...
On Mon, 29 Oct 2007 08:30:53 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-10-28 at 19:20 -0300, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. Perhaps we are simply talking about different things. Of course GTK+ provides a notebook widget and what else would we need to implement this? gedit would be an example of a GTK+ application that uses tabs to handle multiple documents. Sven Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence. Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away. /gg ___ 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...
On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote: On 10/29/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 10/29/07, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. http://curlyankles.sourceforge.net/widgets_docking.html Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) Gimp 2.4 already does that. ciao, --mitch ___ 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...
Date: Mon, 29 Oct 2007 09:40:45 +0100 From: [EMAIL PROTECTED] Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence. Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away. There's a Mozilla Firefox extension that does this. Mozilla extensions don't make direct GTK+ calls (as far as I know), but evidently it's possible for Firefox to know that someone has clicked on the current tab. ___ 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...
On 10/29/07, Michael Natterer [EMAIL PROTECTED] wrote: On Mon, 2007-10-29 at 11:34 +1030, David Gowers wrote: On 10/29/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 10/29/07, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. http://curlyankles.sourceforge.net/widgets_docking.html Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) Gimp 2.4 already does that. How? Where? I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active. ciao, --mitch ___ 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...
What Mitch is referring to is that tabs are raised when doing drag-n-drops. I wish to thank Mitch for his brilliant implementation of this at the last minute of the 2.4 release. This functionality is already extremely useful for d-n-d'ing colors, channels, and layers between tabs and would also be necessary if GIMP provided tabbed image interface. - Though this discussion of UI issues is academically interesting (and will eventually prove fruitful), if GEGL is to be integrated into GIMP then that needs to be the primary focus for the next version. Potential developers will not be interested in spending a month of Sundays learning and programming for a system which is soon to be deprecated, requiring that their efforts be duplicated in the future or obviated completely. Attracting users with alternative UIs or the concerns of graphics professionals will not mean more developers. Having a stable structure to the representation and access of GIMP's internal image data is a necessary precursor to attracting developers. If GEGL can be integrated in less time than GEGL + something else then, unless something else can be justified as being more efficiently implemented at the same time, something else needs to be considered ancillary to GEGL integration. == Quoting David Gowers: GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) Quoting Michael Natterer: Gimp 2.4 already does that. Quoting David Gowers: How? Where? I'm currently using 2.4-rc3; it does not happen here. If i hover over a tab, it just shows a tooltip, never makes that tab active. ___ 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...
On 10/28/07, Robert Krawitz [EMAIL PROTECTED] wrote: From: Christopher Curtis [EMAIL PROTECTED] From: Micahel Grosberg [EMAIL PROTECTED] here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png I think the easiest way is with a last-clicked policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows. So then what happens if I'm using focus strictly follows mouse and I put the mouse over another window (giving it focus)? What if I don't click in the window, but do type a key (select a tool, for example)? Don't focus on the word 'click'. This has nothing to do with pointer focus. It's simply that the menu applies to the last image you did something with. And when you read did something with, think clicked on and not moved mouse over. Changing a tool or tool option does not change what image you're working on. The GIMP already does something similar with the layers dialog. Chris ___ 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...
On Mon, 29 Oct 2007 12:28:07 +0100, Robert Krawitz [EMAIL PROTECTED] wrote: Date: Mon, 29 Oct 2007 09:40:45 +0100 From: [EMAIL PROTECTED] Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence. Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away. There's a Mozilla Firefox extension that does this. Mozilla extensions don't make direct GTK+ calls (as far as I know), but evidently it's possible for Firefox to know that someone has clicked on the current tab. Many thanks, I misunderstood your previous comment. this is good news in several ways. 1. I can get ffx to do this as well , it's the sort of feature that you rely on after a while and miss badly. 2. Presumably Gimp can do the same sort of trick using std GTK+ widgets. 3. The code should be available as an example to make implentation simple and quick. regards. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] weekend 2.6 UI roadmap roundup...
hi all, let me see what since friday has been said (UI-wise) concerning the roadmap. Martin wrote: I suspect making use of Cairo won't impose significant changes to the spec? Well it does, because instead of the current 1-bit (invert) graphics for displaying the UI on the canvas, we could lighten/darken with a much higher 'bit depth'. Which means that the current workarounds (e.g. showing no side handles except on mouse over) can be replaced. Then Sven put these (UI related) projects on the map, but not necessarily on the 2.6 roadmap: * next generation size entries * finishing of: * Heal Tool * Sample Points * Foreground Select Tool * Floating Selections * Alpha Channel * Layer boundaries The ideas for these are mostly in sync with the conclutions the UI team reached during the expert evaluation. Here I want to say that what gets put on the 2.6 roadmap will be specified first because it has a higher priority. And then Guillermo opened the the debate about user request number one: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- requests_25.html#thebigone and everybody starts discussing _how_ this could be done... guys, roadmapping is about what you will deal with in the next release (s), absed on how hard it will be to implement. Now I really want to solve this mayor issue, it will be a multi-facetted solution, but the developers keep telling me that it is not going to be easy to implement. Even to do the bare minimum (Removed the extra menu bar, the inspectors have been made real floating windows, a first stage of usability bug fixing before) would, if I understood Mitch + Yosh right, involve patching all mayor window managers out there. I am all for it that we do this as soon as possible, but I can also understand that it is too much for 2.6. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ 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 Sunday 28 October 2007, [EMAIL PROTECTED] wrote: On Sun, 28 Oct 2007 21:12:33 +0100, Robert Krawitz [EMAIL PROTECTED] wrote: I don't think that making tabbed and floating live together is a very hard problem -- Firefox does that just fine (and it sounds like Opera does it even better). Not only do OPera do it better they invented tabbed browsing. No they didn't: * http://en.wikipedia.org/wiki/Tabbed_document_interface * http://weblogs.mozillazine.org/asa/archives/008433.html Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ I'm not an actor - I just play one on T.V. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature desperately missed...
Hello, maybe now is the time to get around to finally getting all the filter settings saved when exiting the gimp? Every single time I edit pictures I am annoyed that filters like unsharp mask, selective gaussian blur, decor border or almost any other one of them is loosing the settings I made during the previous setting. A radius of 5 on unsharp mask for example is whoefully inadaequate. Unfortunately I can't get my head around the program paradigmas of GTK+ to be helpful as a developer otherwise I might have tackled this myself (I program exclusively C++ now)... But speaking as a daily user: this is the single most annoying lack of a feature of the GIMP. regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Sven Neumann escribió: How is that different? We already have detachable tabs in the GIMP user interface. So why are you asking if this is possible? Sven: http://www.ohweb.com.ar/screenshots/Opera-tabs.png I know there are tabs wich are detachable already. I was talking about the way that Opera as well as QT apps can manage different views of the tabbed windows. In Firefox you have tabbed windows or a new window (with the whole chrome and buttons). In QT apps and Opera you can do the same, but also you can display views of the tabbed windos (as cascade or tiles). That results in a sort of window in window interface. That's what I asking if it is possible in GTK. Not just the tabs. That's why Alexandre posted the link to CurlyAnkles too. Making it possible to have several images in one image window using tabs would be a nice improvement, IMO. It needs some thoughts on the details but perhaps this can be done off-list to that we can concentrate on getting the roadmap for 2.6 done? Ok, let's follow it in the IRC channel. ___ 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 Mon, 2007-10-29 at 09:40 +0100, [EMAIL PROTECTED] wrote: Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence. The discussion of how exactly a widget should behave is out of scope here. At this point we are trying to get an idea of the goals we want to set for 2.6. Details will be discussed by the UI designers who take the job of creating and writing down the spec for this particular task. 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 Mon, 2007-10-29 at 08:52 -0400, [EMAIL PROTECTED] wrote: Though this discussion of UI issues is academically interesting (and will eventually prove fruitful), if GEGL is to be integrated into GIMP then that needs to be the primary focus for the next version. Integrating GEGL is a job for not more than one or two developers and it is extremely local, at least in the first step that is planned for 2.6. We should definitely use this time to also work on other areas. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature desperately missed...
Hi, On Mon, 2007-10-29 at 17:16 +0100, Karl Günter Wünsch wrote: maybe now is the time to get around to finally getting all the filter settings saved when exiting the gimp? The revamp of the PDB API as I outlined it already (named parameters and default values) is a prerequisite for this. That's why I proposed to put it on the roadmap for 2.6. A lot of improvements depend on this change. Sven ___ 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] Cairo for 2.6
Hi, On Mon, 2007-10-29 at 12:02 -0700, William Skaggs wrote: 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. It seems you have missed quite a bit of what has happened in GIMP development recently. GIMP displays an interpolated view of the projection. The nearest-neighbour algorithm is not any longer used. GIMP also maintains a pixmap of the projection, or at least something that is very close to what is being displayed. It remains to be seen if we need to add another level of caching there to get reasonably fast tool drawing. It might be necessary to keep a copy of the displayed area with all display filters applied so that tool expose events can be served from this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.4 and how to continue from here
Moin, currently we are still fixing bugs in the 2.4.0 release but it seems that we caught the major problems now and want to prepare a 2.4.1 release soon. When that is done, we will immidiately create a gimp-2-4 branch to continue bug-fixing there. At that point trunk will be open for development. But since we are aiming for a short development cycle, we need to absolutely keep the tree in a good shape. I don't want to see any commits that haven't been discussed and approved beforehand. This doesn't mean line-by-line code review. But I would like you guys to present your plans here beforehand and not learn about them from reading the commit logs. So if are planning any particular features for 2.6, now is the time to present them here so that they can be put on the roadmap. This includes stuff that has been planned for quite a while, like for example finishing the metadata framework/editor (Raphael!), but also the port to GEGL (Mitch!). I suggest that we keep brainstorming for the 2.6 roadmap for another week and then collect the ideas. It would be nice if we could end with a list of well-defined tasks. When that list is collected, I would like to discuss which of these tasks should be put on the roadmap for 2.6. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
On 10/29/07, Sven Neumann wrote: So if are planning any particular features for 2.6, now is the time to present them here so that they can be put on the roadmap. This includes stuff that has been planned for quite a while, like for example finishing the metadata framework/editor (Raphael!), but also the port to GEGL (Mitch!). What are the plans for vector layers from GSoC 2006? Alexandre ___ 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...
On Monday, October 29, 2007, 14:15:28, Michael Natterer wrote: As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND). Hey, if people are selling extensions for popular programs that do exactly that, why wouldn't GIMP do it for free? /sarcasm -- Jernej Simončič http://deepthought.ena.si/ Any object that is accidentally dropped will hide under a larger object. -- Mickelson's Law of Falling Objects ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] weekend 2.6 UI roadmap roundup...
I'd add the quality of downscaling as a high priority need. Currently it's possible to downscale images using 50% steps at a time (it was discussed before) but it would be better if one single scaling step produces the best quality possible (maybe automating the 50% steps, as it was discussed before). IIRC Sven informed that this issue would be easier to address with GEGL, so I don't know if proposing this fix before GEGL is appropriate. Anyway I'd like to point that it's a need for people who work with graphics for the web. Gez. ___ 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...
On 10/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Monday, October 29, 2007, 14:15:28, Michael Natterer wrote: As Saul already responded that happens only if you use DND. Why on earth would a UI control activate just because you hover some seconds over it? That strikes me as utterly useless, what's the problem with pressing the mouse button if it is not otherwise occupied (e.g. by doing DND). It allows more casual inspection of tabs (move move move, not move click move click), and works particularly well with vertically-stacked tabs or tabs whose content is in a folded away NoteBook. I regard it as useful for inspectors, such as the Cursor tab and Histogram tab, that I do tend to check casually, and selectors, such as brushes, patterns, and brush editor, that can be used casually. Of the seven tabs I have docked to the toolbox, three (palette editor, pattern selector, brush selector) would be useful to access in this way. Ideally, each could be a fold-out window (like tooltips), which would be accessed by hovering or clicking on an icon, rather than blocking other dockables that *should* remain visible (eg. Colors, Layers). If tabs could behave in this way, trying to avoid covering the dockbook they are expanded from, and automatically reset to the previously selected tab when done, this would work rather neatly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] weekend 2.6 UI roadmap roundup...
Actually I got the impression that it had changed, and now box-filtering was used, which does account for all input pixels. OTOH, Lanczos currently produces poor results. Geert Jordaans (sp?) was working on improving this. On 10/30/07, Guillermo Espertino [EMAIL PROTECTED] wrote: I'd add the quality of downscaling as a high priority need. Currently it's possible to downscale images using 50% steps at a time (it was discussed before) but it would be better if one single scaling step produces the best quality possible (maybe automating the 50% steps, as it was discussed before). IIRC Sven informed that this issue would be easier to address with GEGL, so I don't know if proposing this fix before GEGL is appropriate. Anyway I'd like to point that it's a need for people who work with graphics for the web. Gez. ___ 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] 2.4 and how to continue from here
First of all I'm a Digital illustrator and 3d artist. GIMP in the actual state is great. My job can be done in 2.4 easily (thanks for the Jitter, scalable brushes and better zoom!). And I know that GEGL will be in the future of GIMP and the interface already have great proposals (and designers). So I decide to not propose these kind of features... Ok, thats my feature request: GIMP have a ease and very flexible way to create animated brushes, with features like Random and Angular (to create brushes that rotates as you move in different angles). The thing is: If we have some of these features in the Tools Options for brushes will be more fast and ease to use the brushes that are not animated. Some examples: - The Random feature could be simple rotating (in its own axis) the original brush in a random way. Just a simple check box for activate it, maybe a intensity control how much is random. - The Angular could also be activated using a Check Box. The angle of the brush changing as you drawn in different directions, dynamically rotating the brush. His frequency controlled by the Space option in the Brush Dialog. - Other features that are avaible only creating animated Brushes could be in to. But these to are just great. Other proposal for brushes are a option to control the Softness and Sharpness of Brushes. Today you need to create another brush just to change his softness (or hardness). Maybe a good alternative is to have in the Tools Options a Slider if two ways to go: If you move the slider to the Left the brush will be Sharpened... to the Right will be Blurred. Here is a very ugly mockup: http://fc03.deviantart.com/fs21/f/2007/302/f/a/very_ugly_mockup_by_Filsd.png Thats it and thanks for the hard work. -- Filipe Soares Dilly dilly.carbonmade.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
