Re: [Gimp-developer] GIMP 2.6: user directory reorganization
Hi, On Sun, 2007-11-04 at 21:55 +0100, Michael Schumacher wrote: There is a project called CREATE which does have a spec for resource/asset directory organization, I hope to be able to use it for the visible user stuff, at least. I suggest that you also have a look at the basedir specification at freedesktop.org. There are already utility functions in GLib to access these and other directories. If the XDG spec collides with the Create spec, then this collision should be resolved first. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions for 2.6: hopefully not very difficult
Hi, On Sun, 2007-11-04 at 17:39 -0500, Kevin Cozens wrote: It sounds simple enough. Any hints as to how it should look? Would the Tools dialog be added to the bottom of the Toolbox preference tab as a scrollable area or should it be at the top? It could be in a scrolled window or, if that doesn't work, it could be put into an extra dialog. But perhaps we should try to avoid extra dialogs if possible. It would probably also make sense to move the Unit Editor to the Preferences dialog. Perhaps it is even about time for a more complete overhaul of the Preferences dialog. Feel free to open bug-reports for these tasks. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.6: user directory reorganization
Michael Schumacher schumaml at gmx.de writes: My suggestion for GIMP 2.6 - and the only thing I feel able to contribute to - is the reorganization of the user directory. Not sure about the standards on Linux, but in Windows, if we take a hint from the likes of Adobe or Autodesk, user-modifiable program resources (such as: brushes, maps, plugins, gradients, etc) are either in C:\program files\appname\whatever or in C:\Documents and Settings\username\application data\appname\whatever. For photoshop, both are used - resources that come with the app are in the program files folder, and user-saved settings are in the application data folder. Putting resources in the user's my documents folder is bad form - this is a folder for *documents*, not resources. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions for 2.6: hopefully not very difficult
On Nov 5, 2007 1:04 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, I am concerned that we are hiding important functionality here and that most users will never figure out how to get the dialog in case they should need it. But since even the UI team seems to suggest that we do this change, we should probably do it all over the user interface then. There are a few more places that use Shift suppresses dialog. (Sorry Sven, I did not realise I replied only to you before) myStupidTwoCents Cant this be implemented like the playlist buttons in XMMS/Winamp ? I mean the tiny triangle which users intuitively take as There are more options!. /myStupidTwoCents -- Laxminarayan Kamath Ammembal (+91) 9342287956 [EMAIL PROTECTED] www.geocities.com/kamathln ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI redesign: 1 Dimensional Menu for GIMP
Esteban, Hi all, This is the 2º draft for the 1 Dimensional Menu: http://www.zensui.org/IxD/1DM.html in your honour we created the GIMP UI brainstorm: http://gimp-brainstorm.blogspot.com/ please post your idea there. On another note, is a new mailing list dedicated exclusively to interface design needed? What would be the function of the mailing list? What is working really well with the brainstorm is that everyone is able to contribute, these contributions get reviewed by my team and we get new ideas out of them. The other good thing is that the noise factor is cut down by a factor of 1000. --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] Suggestions for 2.6: hopefully not very difficult
Hi, On Mon, 2007-11-05 at 18:45 +0530, Laxminarayan Kamath wrote: myStupidTwoCents Cant this be implemented like the playlist buttons in XMMS/Winamp ? I mean the tiny triangle which users intuitively take as There are more options!. /myStupidTwoCents We are talking about showing a dialog or not showing a dialog. I don't think that you can hide a dialog in an expander. I will assume that you simply missed the context. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
On 11/5/07, Valerie VK wrote: This is why I suspect it to be a transparency problem and not really a process problem. People actually Won't criticize a process if they think it is doing a good job. In the case of the GUI team, we don't know if it's doing a good job. In fact, we don't see a job being done at all. Who are these we? Clearly I am not one of them, because I benefit from new rectangle tools that come out of a spec created by the UI design team, because I can read things like http://gimp-brainstorm.blogspot.com/2007/10/team-review-contribution-2650.html etc. Solve the transparency problem, and the criticism will go away. You say what to do, but you don't say how. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI redesign: 1 Dimensional Menu for GIMP
originally the idea was to make a menubar more comfortable... but I don't understand your idea fully. current menubars, although one of the most used widgets, are too uncomfortable... 2007/11/5, David Gowers [EMAIL PROTECTED]: I may not understand your description. It gave me an idea, though: mouse-gesture-ish submenus.. That is, supposing that you have a top-level menu with items 1 2 3 and 3 is a submenu, then, to select 3, you move down -- then a menu folds out horizontally 1 2 345 you move across, and select 5, which is also a submenu: 8 7 6 345 And move up to the item you wanted, 8. During the time a menu is active, the mouse could be constrained to only move along that axis. Then, the above menu selection could be made by the mouse gesture Down-Right-Up-Click (with appropriate distances). With the cursor keys, it could be made by pressing Up-Left-Down-Down-Enter after bringing the menu up . In this way you can make menu navigation like maze navigation, or like performing special moves in a fighting game, rather than the fairly uncomfortable and unmemorable 'tree' movement used in most applications today. On 11/5/07, Esteban Barahona [EMAIL PROTECTED] wrote: Hi all, This is the 2º draft for the 1 Dimensional Menu: http://www.zensui.org/IxD/1DM.html I will be honored if the new GIMP UI is the first implementation of a 1DM. This, I think are the changes to make it possible: 0) separate the toolbar from the menubar(s) 1) make the toolbar customizable to show only the relevant tools (configurable by each user) to simplify 2) change it to a vertical layout with only one icon per line 3) move it to the left border of the screen by default 4) increase the right padding so that the mouse can be moved vertically more easily and quickly 5) add the name of each tool in this extra space I do understand the points you are making here, though. In addition to 4) I want to suggest that this extra padding only be visible during selection, so usable space is maximized I don't know which parts of this need a new GTK widget, but also think that the concept can be tested with current widgets. If the menubar is separated from the toolbar, the toolbar's window can be manually positioned as a 1xN column in the border. The only part that has to be coded (I think) is changing the padding of each icon. On another note, is a new mailing list dedicated exclusively to interface design needed? IMO, this can make possible a filter between design and engineering posts making this much welcomed redesign progress more smoothly. ___ 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] GIMP 2.6: user directory reorganization
2007/11/5, Michael Grosberg [EMAIL PROTECTED]: Michael Schumacher schumaml at gmx.de writes: My suggestion for GIMP 2.6 - and the only thing I feel able to contribute to - is the reorganization of the user directory. Not sure about the standards on Linux, but in Windows, if we take a hint from the likes of Adobe or Autodesk, user-modifiable program resources (such as: brushes, maps, plugins, gradients, etc) are either in C:\program files\appname\whatever or in C:\Documents and Settings\username\application data\appname\whatever. For photoshop, both are used - resources that come with the app are in the program files folder, and user-saved settings are in the application data folder. Putting resources in the user's my documents folder is bad form - this is a folder for *documents*, not resources. ___ 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] Negative Press
2007/11/5, Alexandre Prokoudine [EMAIL PROTECTED]: Solve the transparency problem, and the criticism will go away. You say what to do, but you don't say how. allowing comments (with moderation... like most blogs) on http://gimp-brainstorm.blogspot.com/ will be a good start. the wiki of the GIMP UI redesign team is closed, so the blog above should be the public face* of this redesign process. *that's what I was suggesting a new mailing list; because both the blog and wiki are virtually closed to outsiders... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
As an example of why a GIMP.UI mailing list (or changes in the blog) is necessary Send your image to us [EMAIL PROTECTED], put the word 'GIMP' in the title of your email (to avoid spam, emails without GIMP in the title or without an image attachment will not be opened). So, if I have a comment on this entry: http://gimp-brainstorm.blogspot.com/2007/11/add-or-remove-tool.html that doesn't include an image manipulation of the images of the post my only option (to avoid being filtered as spam) is reply in this mailing list: This will be a welcome change if implemented, in fact, it is one of the first steps for my idea. But more changes are necessary. The toolbox should be separated from the second menubar (and merge both menubars) and from the options of each tool. In this way (and if each user has a simplified and personalized toolbox), the toolbox can be a 1xN grid that goes to the border (yey!). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Esteban Barahona wrote: allowing comments (with moderation... like most blogs) on http://gimp-brainstorm.blogspot.com/ will be a good start. The idea is that comments are done by images - if you do like something, you can add more suggestions based on it. If you don't like something, you have to create something better. IMO the best way to cut down noise. Have a look at the comments in the linux.com article, many of them are just BS. HTH, Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
On 11/5/07, Esteban Barahona wrote: You say what to do, but you don't say how. allowing comments (with moderation... like most blogs) on http://gimp-brainstorm.blogspot.com/ will be a good start. That won't work. Brainstorm means no discussion. Otherwise it's not a brainstorm. See, I do understand your best intentions to help and I have my own ideas how to improve GIMP as well, but things that could work to a smal project cannot work to huge projects like GIMP. There are dozens, if not hundreds of us. All together we will make a lot of noise and distract UI designers from actual work. Now that we finally have a group of people working at UI this is the last thing I would want to see happening. However I believe that the situation could be improved by writing a friendlier text at brainstorm page and providing a friendly explanation how and why UI team works at the main wiki page. Contributions are welcomed by GIMP team and people have to know that for sure. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] momentary shortcut to the zoom tool?
Sven Neumann ([EMAIL PROTECTED]) wrote: On Sat, 2007-11-03 at 10:25 -0400, Daniel Falk wrote: There doesn't seem to be a way to temporarily switch to the zoom tool while a button is pressed. For example if I hold down ctrl + space, it would switch to the zoom tool, I could click-drag a rectangle to zoom, and let up on the ctrl + space, and it would switch back to the tool that was selected previously. There is code in GIMP to temporarily switch tools. We used to use it for switching to the Move tool when Space is being pressed (this can still be enabled in the Preferences). I guess that code could be used to implement the described behavior. But I can't tell if that is a good idea or not. Or if it is likely to collide with other tools. Or with changes planned for other tools. I am actually unsure if the Zoom tool really should be a tool. It is the only tool that does not affect the image, but the display of the image (the measure-tool at least lets you create guides). At least for me it is an annoyance: I never really use it and if I use it I am annoyed that it does not switch back to the previously used tool. I tend to think that it should be moved to the display of the image to make it easier to fluently change the view/zoom on the image without interrupting the current workflow. -- UI team :) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.6: user directory reorganization
On Monday, November 5, 2007, 11:23:55, Michael Grosberg wrote: Putting resources in the user's my documents folder is bad form - this is a folder for *documents*, not resources. While I agree that putting resources in My Documents is a bad thing, the problem with Application Data is that it's a hidden folder, which normally isn't accessible. -- Jernej Simončič http://deepthought.ena.si/ Never say oops in the operating room. -- Law of Local Anesthesia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] momentary shortcut to the zoom tool?
On Mon, 05 Nov 2007 20:00:00 +0100, Simon Budig [EMAIL PROTECTED] wrote: I tend to think that it should be moved to the display of the image to make it easier to fluently change the view/zoom on the image without interrupting the current workflow. -- UI team Bye, Simon That makes a lot of sense. It should be a one-off event. Like all the View | Zoom entries, you select it , it does it's job and good-bye, back to where you were. This is clearly more a view setting than a tool. It's in the tool menu because it's a tool (in certain aspects of it's code) not because it acts like a tool from a task oriented POV. It is in reality a view option. It seems rather incongruous that this does not appear on the view menu. If and when it does , it should probably go at the top. It seems much more intuitive to grab the bit you want than to guess whether 15 or 18% would be better for what you want to see and how it would center. The number of entries in View|Zoom itself suggests some key functionality is missing. I think that gap is the zoom tool, let's call it Select Zoom. It would be worth considering a separte entry in the view menu rather than burying this one more level down. It's too useful to require complex scrolling of submenus. View | Select Zoom nice and fast, View | Zoom for all the gritty details and specifics like Fit to window. Good thinking Simon. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.6: user directory reorganization
On Mon, Nov 05, 2007 at 08:02:10PM +0100, [EMAIL PROTECTED] wrote: While I agree that putting resources in My Documents is a bad thing, the problem with Application Data is that it's a hidden folder, which normally isn't accessible. What about an option somewhere in the GIMP menus: Open brushes folder which opens the appropriate folder with Explorer / Nautilus / whatever needed? -- Greetings, Richard ___ 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
Sven Neumann wrote: 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'd like to get a couple paint tool related patches in. 323921 GIMPNEW enh add support for color jitter in the paint tools 163050 GIMPNEW enh paint tools should support smudging as they paint. Patches exist, though they haven't been tested against 2.4/2.5, I think they should apply pretty easily however. If theres interest, I can update them. Adrian ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
On Mon, 2007-11-05 at 09:30 +0100, Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. I could find a video for anyone interested, but that really wasn't my point. I suggested the feature not simply to ask for someone to copy photoshop in detail, but to solve the same problem that photoshop has managed to solve. Namely, figuring out an effective, efficient, and time-saving way of cleaning up a photo with a lot of marks or a dusty scan. In general I would like to point out that it is unlikely that any of the active core developers will pick up your feature requests. If you can find a developer who is interested in the algorithms and willing to work on this stuff, then we are very willing to give him/her a hand and guide him/her through the GIMP code and to review patches. But without a volunteer, this is likely to be just another feature requests. We already have several hundreds of them. Sven That's a shame, but I do understand there is a lot of work to be done on the gimp and only so much expertise to go around. Still, can it be logged as a valid feature request somewhere in the event that someone with the interest in improving the gimp might choose to implement this request? After all, I didn't just request it to scratch my own itch. I wanted to add my input into how the GIMP could improve. I wouldn't really know how to find a developer to work on this stuff. I would assume it's more likely that developers would come to you as core developers of the GIMP than to me after all. Thanks for your attention and all the hard work you guys do on the GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
This is why I suspect it to be a transparency problem and not really a process problem. People actually Won't criticize a process if they think it is doing a good job. In the case of the GUI team, we don't know if it's doing a good job. In fact, we don't see a job being done at all. Who are these we? Clearly I am not one of them, because I benefit from new rectangle tools that come out of a spec created by the UI design team, because I can read things like http://gimp-brainstorm.blogspot.com/2007/10/team-review-contribution-2650.html etc. The we are the 80% users who expect UI improvement to be a lot more than just a new design for the rectangular tools, and won't bother reading every single post on the gimp-brainstorm blog, much more so since the only link is in the pile of ways to contribute list which does Not include Check here for future UI improvement plans. Solve the transparency problem, and the criticism will go away. You say what to do, but you don't say how. Yes I did, in perhaps such an extensive manner that you didn't bother reading it from my previous response to this topic. Here it is again since you've missed it: The easiest solution, as far as I can tell, is actually to apply the same principle that the GIMP site's Feature page and that the GIMP UI brainstorm blog apply themselves: using pictures to speak a thousand words. The summary would basically roughly serve the same purpose as a visible 2.6 milestone (which should also have mock-ups) would from a PR point-of-view: show people what's in planning so that people won't think of GIMP as a dead project that isn't moving anywhere. Inkscape has a screenshots section for future features, and that does wonders for showing people the future evolution of the program. Are there any plans for a Future feature page on the GIMP website? If there is, it could be made up of two sections: - Future features (with mock-ups based on the 2.6 milestone) - Future GUI improvements (a whole section dedicated to GUI improvement! This is sure to score points among critics of the GIMP interface) The future GUI improvement section could contain screenshots of a few key UI improvements in planning (they don't need to include everything), with eventually an explanation of dependencies such as GEGL. As long as people know that they Are being planned, they'll be relatively happy and not get the impression that GIMP doesn't care about UI improvements. If the features aren't planned for any time soon but Are on the long-term plans, an explanation is enough to let users know that the GUI team isn't GUI-stupid but simply isn't capable of implementing the changes Yet. Then add a call for help on implementing prior dependencies, and maybe you'll even get more developers. Said section could end with Got more ideas? Submit to the GUI-brainstorm! And that's it. PR problem solved. Lack manpower? Get someone else to do the mock-ups for you. Given the number of submissions to GUI-brainstorm, it should be easy enough to find someone. Add the occasional news update on GUI rework progress, and that's even better! GIMP is finally taking the GUI problem seriously! - would claim people who haven't noticed the work already under way. __ 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] GIMP 2.6: user directory reorganization
Hi, On Mon, 2007-11-05 at 20:38 +, Richard Hirner wrote: What about an option somewhere in the GIMP menus: Open brushes folder which opens the appropriate folder with Explorer / Nautilus / whatever needed? There can be more than one brush folder. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Hi, On Mon, 2007-11-05 at 19:29 -0500, Daniel Falk wrote: Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. I could find a video for anyone interested, but that really wasn't my point. I suggested the feature not simply to ask for someone to copy photoshop in detail, but to solve the same problem that photoshop has managed to solve. Namely, figuring out an effective, efficient, and time-saving way of cleaning up a photo with a lot of marks or a dusty scan. A video wouldn't help. In order to implement this, one would have to know exactly how Photoshop somehow guesses what it should use as source material. Of course if someone has solved the problem you outlined above, then we would be happy to help him/her to implement it as a GIMP tool. That's a shame, but I do understand there is a lot of work to be done on the gimp and only so much expertise to go around. Still, can it be logged as a valid feature request somewhere in the event that someone with the interest in improving the gimp might choose to implement this request? No. It is pointless to keep an enhancement request for something that doesn't have a known solution. It would even be a waste of developers time since this bug would only make our long list of feature requests even longer. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
