[Gimp-developer] no-image-open redux
To keep the ball rolling, I thought it might be useful to show a copy of my current experimental version of a no-image-open window. Most features should be obvious from the picture, but a couple of notes: 1) The toolbar shows most of the things a user might want to do with no image open, but not quite all. Aquire, or Open as layers, could be added, or even Create, which would access the menu for creating buttons, logos etc. About could, and probably should, be removed. 2) I felt like I had to shorten the main menu, because it made the window too wide. I did this by shifting the categories I use least into submenus -- View into Image, and Tools, Dialogs, and Xtns into a new Gimp category. 3) The backdrop is handled like the splash screen -- the user can replace it with a different one, and the no-image-open window shapes itself to match the specified image. Yes, it's ugly: sorry, I'm not an artist. 4) The tips can be disabled. 5) The theme used for the screenshot is Clearlooks. The icons, and general appearance of the toolbar, would change if a different theme was used. -- Bill attachment: no-image-open.jpg___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2008 ideas
Hi - here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick. Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-) Also, there is still a little time for adding some more ideas, or try to focus some more. Regards, js -- [http://wiki.gimp.org/gimp/SummerOfCode2008ideas] = GSoC2008 Project Ideas = '' Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.'' Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... == Tagging of GIMP resources == Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things and think of them by names for these collections, like sprinf flower brushes or fancy fonts. However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think Favorites, Most recently used and Most frequently used. It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags. The tasks in this project include: * adding a way for gimp resources to be tagged * decide which types of resources (i.e. which types of gimp objects) should be tagged * find a nice way for users to manage tags (add them, remove them) * present tags in the UI (i.e. how do you show them in the brush list, font list, ...?) * think about how tags can assigned to resources (or resources to tags) == On-canvas text editing == Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it. It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is. And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression. Tasks for this project include: * port the text core to PangoCairo * get on-convas text editing implemented * figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object) * make sure that GTK+ input methods work this this new approach * think about making it possible or not making it impossible to style the text while editing it this way == GIMP Python == mentors: Yosh or João With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries. GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C. However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project: Properly map Gimp Widgets and objects to Python Wrap all libgimpwidgets to be acessible from python, so python plug-ins can have the same presentation as gimp components written in C (that is gradient and palette selectors, scale entries). Additionally map all remaining gimp objects to proper python objects, just as layers and images are already: palettes, gradients, brushes, patterns, fonts, Enhance the interface builder, add plug-in previews Add
[Gimp-developer] no-image-open redux
A couple thoughts: Has anybody come to a consensus about whether or not the no-image dialog should persist after an image is opened? Even for expert users, it might be useful to keep the no-image dialog open as a drop-target for opening more images, but I can also see how it would annoy some users. Perhaps that should be an option which is shown up-front on the dialog instead of buried in config settings. For instance, at the bottom of the dialog there could be a checkbox labeled: Close this window when an image is opened There's a little precedent for this sort of option -- it's similar to the Never show this tip again options in tip systems. Speaking of tips... 4) The tips can be disabled. I suppose that's good, but all that space being used for the tip *could* be used for a more efficient start screen. For instance, the most recent images could be shown in a list instead of hidden in a drop-down. Slightly off-topic: I understand that people want to find a way to show tips in an unobtrusive way, but maybe we can take a hint (no pun intended) from video games here: the loading screen would be a great place for tips, since the user has nothing to do but twiddle their thumbs during that time anyway. Cheers, -Rick- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
Has anybody come to a consensus about whether or not the no-image dialog should persist after an image is opened? Actually, yes, the mere fact that it is called a no-image window means that a consensus has been reached. Your points are reasonable, but when there are several reasonable alternatives, one has to make a decision between them at some point, and the decision we are working with at the moment is to use a no-image window. For what it's worth, even after an image has been opened, it will continue to be possible to open more images by dropping icons on the toolbox, just like you can do now. Also for what it's worth, I've been a bit worried about including a toolbar like the one I showed, precisely because users who find it useful would want to have it available even after an image has been opened. 4) The tips can be disabled. I suppose that's good, but all that space being used for the tip *could* be used for a more efficient start screen. For instance, the most recent images could be shown in a list instead of hidden in a drop-down. There are two problems with this. First, it creates visual clutter. Second, some people won't *want* their most recently edited images to be shown every time they start Gimp, for reasons that will probably occur to you. Slightly off-topic: I understand that people want to find a way to show tips in an unobtrusive way, but maybe we can take a hint (no pun intended) from video games here: the loading screen would be a great place for tips, since the user has nothing to do but twiddle their thumbs during that time anyway. I don't think this is off-topic at all. I thought about this a good deal, and it's a great idea in principle, but it won't work for the current set of tips: many of them are too long and complicated to be presented that way. If the tips were simplified, my enthusiasm for this would be a lot higher. Thanks for your input, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2008 ideas
== Integration of GHNS for GIMP == Though you can add more brushes, patterns, gradients can be added, Most users, not even pros usually add them off the internet. This is so as there is no architecture to quicky share/add from a centralized repository. This seriously limits sharing of resources among the users. GetHotNewStuff (GHNS) could probably help out here. On 3/8/08, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Hi - here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick. Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-) Also, there is still a little time for adding some more ideas, or try to focus some more. Regards, js -- [http://wiki.gimp.org/gimp/SummerOfCode2008ideas] = GSoC2008 Project Ideas = '' Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.'' Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... == Tagging of GIMP resources == Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things and think of them by names for these collections, like sprinf flower brushes or fancy fonts. However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think Favorites, Most recently used and Most frequently used. It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags. The tasks in this project include: * adding a way for gimp resources to be tagged * decide which types of resources (i.e. which types of gimp objects) should be tagged * find a nice way for users to manage tags (add them, remove them) * present tags in the UI (i.e. how do you show them in the brush list, font list, ...?) * think about how tags can assigned to resources (or resources to tags) == On-canvas text editing == Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it. It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is. And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression. Tasks for this project include: * port the text core to PangoCairo * get on-convas text editing implemented * figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object) * make sure that GTK+ input methods work this this new approach * think about making it possible or not making it impossible to style the text while editing it this way == GIMP Python == mentors: Yosh or João With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries. GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C. However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project: Properly map Gimp
[Gimp-developer] Fwd: no-image-open redux
Forwarding accidentally done personal reply. -- Forwarded message -- From: Laxminarayan Kamath [EMAIL PROTECTED] Date: Sat, 8 Mar 2008 09:04:01 +0530 Subject: Re: [Gimp-developer] no-image-open redux To: Bill Skaggs [EMAIL PROTECTED] About changing the menu .. Would the end user like a perpetually changing menu. At least I have got tired of playing this hide and seek with the menu items every time a new version of the GIMP comes in. Supposing now there is no choice, .. if I were to shorten the menu, I would keep the View menu, and move the select menu into Edit. But then that is my preference. And yes, I see no problem in doing away with the toolbar. The four options you have provided are nothing but the four first options in the file menu. In the perspective of a beginner, if the beginner finds no such toolbar, he will explore the menus. And it will probably be only two more seconds than otherwise that he finds those options. In the perspective of a pro, he will know Ctrl+n and Ctlr+o anyways. So it does not help much anyway. On 3/8/08, Bill Skaggs [EMAIL PROTECTED] wrote: To keep the ball rolling, I thought it might be useful to show a copy of my current experimental version of a no-image-open window. Most features should be obvious from the picture, but a couple of notes: 1) The toolbar shows most of the things a user might want to do with no image open, but not quite all. Aquire, or Open as layers, could be added, or even Create, which would access the menu for creating buttons, logos etc. About could, and probably should, be removed. 2) I felt like I had to shorten the main menu, because it made the window too wide. I did this by shifting the categories I use least into submenus -- View into Image, and Tools, Dialogs, and Xtns into a new Gimp category. snip/ -- Laxminarayan Kamath Ammembal (+91) 9945036093 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
On Sat, 08 Mar 2008 04:02:40 +0100, William Skaggs [EMAIL PROTECTED] wrote: Also for what it's worth, I've been a bit worried about including a toolbar like the one I showed, precisely because users who find it useful would want to have it available even after an image has been opened. Hi, that worry could be got around by doing just that , make it available. Right-click : remove toolbar for those who find it superfluous and want to recover the land rights. Opera , for example , has miriad panels and bars available with a resonalbe subset on by default (most of which I bin rapidly to get things the way I like to work). This config is maintained next time I use it and gives me exactly the layout I find efficient for my work load and way of doing things. Right-click on any toolbar or panel gives acces to a global configure toolbars situation. Another useful feature in Opera setup is make everything visible while selecting the elements you need. This is a horrible clutter (since this is not a work mode) and allows you to see all that is available and keep the bits you need and avoids clicking things on and off to find out what they are called. I think Opera's solution is a good example of presenting a very complex set of tools, panels and windows that cater for many different user senarios whilst maintaining almost complete flexibility of screen layout. Since Gimp UI is similarly a constant challenge of screen space vs function accessibility Opera setup may provide some useful ideas. /gg -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote on Sat, Mar 8, 2008 at 6:26 AM : Right-click : remove toolbar for those who find it superfluous a small [x] button on top right of the toolbar might be better. Most people are used to Right click == context menu behaviour. The toolbar disappearing would freak them. Of course, the close toolbar can also be an option in the context menu that could appear when you do a Right Click . -- -- Laxminarayan Kamath Ammembal (+91) 9945036093 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
