Re: [Gimp-developer] weekend 2.6 UI roadmap roundup...
Hi, On Mon, 2007-10-29 at 19:16 -0300, Guillermo Espertino 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). This is an important issue. But it has to be addressed in GEGL as we will soon start to use the GEGL scaling routines. Definitely an important task to put on the tasks list for GEGL. 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
Hi, On Tue, 2007-10-30 at 00:50 -0200, Filipe Soares Dilly wrote: Ok, thats my feature request: I think you misunderstood me. This thread is not about sending your feature requests. It is about telling us what you would like to work on for the next time in GIMP. We already have more than enough feature requests. Please don't post more here but instead let the developers discuss what's important to address and what they would like to work on. 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
Hi, so as I've already written a few weeks ago in my mail about the new features for the text-tool in the PDB, I'd like to contribute especially in that part. As far as I understood the discussion about the roadmap, the PDB will get a little rework for the 2.6 release (named parameters, etc.). So as I'm absolutely new to gimp-development, I'd like to know where is a good starting point to get all informations/things. I'm a bit confused about all information sources: mailing lists, web-pages, wikis, bugzilla, and the source-code itself of course, etc. As Sven told me in a mail-reply, I should bring up the topic about the new text-tool PDB thing... So I have done it now ;) best regards Marcus ___ 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
Marcus Heese wrote: so as I've already written a few weeks ago in my mail about the new features for the text-tool in the PDB, I'd like to contribute especially in that part. As far as I understood the discussion about the roadmap, the PDB will get a little rework for the 2.6 release (named parameters, etc.). It is nice of you to offer to work on improving the text tool portion of GIMP. This is one of those items that has needed work for sometime. It would be worth looking at the text tool related items in Bugzilla. The main (tracking) bug about text tool fixes and enhancement is bug #136740. I saw, but haven't tried, the patch you sent to the mailing list. I see you are allowing extra text options to be set but it isn't easy to see what you are proposing. A new text tool API is one of the outstanding bug reports. It would be helpful to see a summary of the API changes you feel should be made in a form some along the lines of the PDB browser (ie. function name, arguments required, and values returned). I have done a little bit of work on the text operation of GEGL and I know there can be a lot of parameters to set/get. Will you handle only some parameters now and others later? How would the extra parameters be handled later? Setting/getting all text parameters in one call may not be the best option. This may depend on the whether the PDB supported the use of named parameters when a new text tool API is being implemented. Just some things to think about while you plan out a new text tool API. Hopefully, the next version of the text tool and its API will get it right the first time. :-) Looking forward to the improvements you come up with. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ 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...
Guillermo Espertino wrote: I understand. It's clear that everyone's preference may vary on this subject: -Photoshop users will ask for floating windows nested in a container window. They ask for an MDI structure because that's what they know, but I suspect they'll be happy with any solution to their problem that works well. All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the where goes the omni-present menu bar? problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed? Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen. I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example. I'd address the short comings in GIMP's window implementation first and then see if MDI is actually still demanded before thinking about implementing it. Of course, you'll always get some criticism, but I think the majority would be satisfied with a solution that works, even if it isn't like how PS does it. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ 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 Oct 30, 2007, at 2:44 PM, David Marrs wrote: They ask for an MDI structure because that's what they know, but I suspect they'll be happy with any solution to their problem that works well. I believe that the main reason is legacy behavior from Windows 3.x. As I've mentioned before, Microsoft officially deprecated the MDI approach with the introduction of Windows95, but allowed existing apps to be grandfathered in. So I think your assessment is correct. They ask for what they are used to, and aren't aware of alternatives.___ 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 Oct 28, 2007, at 11:49 AM, Sven Neumann wrote: On Sun, 2007-10-28 at 15:06 -0300, Guillermo Espertino wrote: Yes, I knew that (both the utility setting and the image dialog). What I meant was to polish those two features and make them work correctly in every platform (afaik the utility setting seems to have some problems in windows, for instance) so can make them available as the default behavior. The problem is though that I consider it impossible to make this work on all platforms and all window managers. We couldn't even get this to work on a Linux GNOME desktop where we are dealing with a window manager that implements the EWMH spec. But please prove me wrong. I would love to find out that this is possible after all. I know this is one thing we've been fighting with for quite some time with Inkscape. If someone is willing to look into it on the GIMP side of things, I would very much like to coordinate effort. We've had bits and pieces of progress over the last release or so, but working together can help fix things sooner.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a first step towards Cairo drawing
On 10/27/07, Sven Neumann [EMAIL PROTECTED] wrote: [...] 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? How about darkening the outside-of-the-view area and then adding a simple white border? http://cr33dog.fedorapeople.org/misc/gimp/nav.png My only concern is that very dark images may become black in the outside view. On the upside, I'm pretty sure the visible area will be clearly defined on all image types - light images will benefit most from the darkened transparency, and dark images will benefit most from the white box. Both ways, the rectangle is clearly visible. Just a thought... 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...
Date: Tue, 30 Oct 2007 21:44:56 + From: David Marrs [EMAIL PROTECTED] All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the where goes the omni-present menu bar? problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed? Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen. I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example. As long as we're talking about all this, I'd rather see things go the other way -- each image has its own toolbox, set of dialogs (perhaps in a sidebar, or as slide-outs or slide-ins), etc. Let's take layers as an example (because this is one of the more annoying ones to me). Having only one layers dialog has two undesirable consequences: 1) I can only see the layer stack of one image at a time. 2) If I move the mouse from one image to another (even if the mouse is in transit), GIMP switches which image's layers are displayed. One way of looking at this is that this is a problem with focus follows mouse (actually focus strictly follows mouse in my case, but I don't think that that matters here). The other way of looking at it is that this is a problem with dialogs that are related to a document being shared between multiple documents, so there's only one active document at a time. My preferred way of working is to have lots of open windows at a time. Sometimes a window that I'm working in at the moment (emphasis on at the moment -- I don't really have a notion of this is what I'm working on now, I jump around between things) may be partially obscured by another window, but that's how I like it. I do use multiple virtual desktops, but not in a very organized way. I rely on screen real estate (currently 1600x1200 on my laptop, and 1920x1200 on my desktop except when I bring the LCD upstairs and stick it on my laptop to get 1920x1200). I'll be a good candidate for QXGA or even HXGA when it becomes affordable -- it will just give me that much more space to expand my clutter onto. I personally do not like the Macintosh interface one bit -- it gets all the key interfaces wrong for the way I work. At least to me, it emphasizes that there's one thing that it expects you to be working on at a time (click to focus and raise rather does that, especially combined with the single menu bar that's tied to whichever application is active at the time), and that one thing is front and center no matter what. Be all that as it may, I suspect that having separate layers, channels, etc. dialogs for each image might be very attractive in a lot of cases, but it's not going to be to everyone's taste. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
