Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On 01/04/2011 08:25 AM, しげっち wrote: Hi, all. I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming. I hope these features to be included or merged into the master branch in some future. So I inform you the patch here. If you're interested in the patch, please discuss about it. The patch is maintained by git, and published at following site. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=summary This patch implement several features like: * horizontal toolbar with many tool options. (http://gimp-brainstorm.blogspot.com/2009/07/blog-post.html or http://gimp-brainstorm.blogspot.com/2009/07/gimpscape.html) * much sophisticated brush panel (http://gimp-brainstorm.blogspot.com/2009/12/brush-panel.html) * dynamics editor with side tabs (http://gimp-brainstorm.blogspot.com/2009/12/brush-dynamics-curves.html) * vertical dock and image tabs for single window mode. (http://gimp-brainstorm.blogspot.com/2010/10/vertical-menu.html) * dock folding features. I think this feature is necessary for single window mode. This patch is based on the current master branch of the git://git.gnome.org/gimp. It modified many source code of the existing codes, but it does not delete any features that is available in the master branch. Thanks, -- sigetch. Hi sigtech That's some very interesting work and we should work on merging what makes sense to merge to GIMP git master. A word of warning though: not everything posted on the gimp-brainstorm blog is suitable to be actually implement in GIMP, so all your patches might not make sense to merge. A couple of early comments on your code: Add toolbar for tool-options to GimpImageWindow. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=13c321f2db36bae52b23d4264dee242827bb801c Rather than adding a widgets at the top of the GimpImageWindow taking up precious horizontal image space, we should work on moving tool options to on-canvas in an elegant way. Adding another tool-options area gives less space for image content and more space is taken by widgets, which is not the best trend. - G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink... http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch? Initial import of color blending function for smudge tool. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=1b83ecae173641b0b08bccd0b207457bb549f9e6 It doesn't look like you change shade_pixels() and shade_region() in a backwards compatible way. Don't you break other things with that change? Otherwise it looks like a change we would want to merge. It would be a good idea to split this commit up so that there is one commit per bullet-point in your commit message. * Some parameters in the toolbar can be edited using popup editor. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=2d5edbfe2fbba08ab4cf456586d5344a3c3a49cc If I understand your code correctly, you are replacing big widgets with smaller widgets that expand when you use them. Worth looking into further. * GimpDock: GIMP dock column folding is implemented. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=01c5590e9566d7f9f7fe2b8112e570a26cb3ac4c Another interesting change, I'll look closer at it when I get back at hacking on single-window mode. [various bug fixes and additions to earlier commits] For review purposes, it would be good if you squashed fixup-commits with commits they fix, so upstream reviewers just need to review one patch. Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On Tue, Jan 4, 2011 at 10:15 AM, Martin Nordholts ense...@gmail.com wrote: On 01/04/2011 08:25 AM, しげっち wrote: - G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink... http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch? I took a quick look. Its an interesting piece of code. Just wondering why it is implemented just for the inkpen, when it could just as well be implemented in the paint core for any paint tool... BTW, I cant find the dynamics editor implementation commits as a patch. Is it in the huge gui merge? Could you lik me to it. I find it interesting, but guiguru might object. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
hi しげっち, I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming. you do realise that the brainstorm is a 'sandbox' for ideas? the deal is that everything is OK within a brainstorm (so ideas keep flowing) but that is only _within_ the brainstorm. when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP. steps 2–5 are what I bring to any project and customer I work with. sometimes these steps are necessarily heavyweight because of the complexities involved, sometimes as lightweight as 15 mins of thinking and an email or irc exchange. it depends... for the patches you sent, only step 1 and 6 were done: 1 by the brainstorm participant and 6 by you. the steps in the middle are missing. this is not criticism of you, most (99.9%) of the software world does not do and know any better than that. but here at GIMP we do better. other folks here will be able to judge the quality of your code, but I can see your enthusiasm to work on UI issues that matter, and we have a backlog of that. I am gathering resources at the moment to get more done for GIMP on the UI design side, we could use your enthusiasm to have more power on the development side. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] GUI enhancement patch from GIMP UI brainstorm blog
Thanks for many comments. 2011/1/4 Martin Nordholts ense...@gmail.com: Add toolbar for tool-options to GimpImageWindow. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=13c321f2db36bae52b23d4264dee242827bb801c Rather than adding a widgets at the top of the GimpImageWindow taking up precious horizontal image space, we should work on moving tool options to on-canvas in an elegant way. Adding another tool-options area gives less space for image content and more space is taken by widgets, which is not the best trend. I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list. And I agree that the toolbar should not replace the existing tool options. But I also know that there are many requests for horizontal toolbar options. As a heavy GIMP user, I've wanted the horizontal toolbars and a popup brush editor for many years. So I'm developing a toolbar which code base is almost shared with tool options and It doesn't replace existing tool options at all. I think optional toolbar is a good idea unless it hurts the existing GUI navigation. - G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink... http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch? 2011年1月4日17:33 Alexia Death alexiade...@gmail.com: I took a quick look. Its an interesting piece of code. Just wondering why it is implemented just for the inkpen, when it could just as well be implemented in the paint core for any paint tool... This patch implements smoothing functions both for brush core and ink tools. Smoothing function works with paint brush, air brush, ink tool, smudge tool, and maybe with other paint tools such as clone tools. BTW, I cant find the dynamics editor implementation commits as a patch. Is it in the huge gui merge? Could you lik me to it. I find it interesting, but guiguru might object. Dynamics editor is only an additional features, and it doesn't replace any existing GUI. It works only with the horizontal toolbar for now. So you can simply ignore the additional dynamics editor implementation. I feel it's much simpler to choose the dynamics and then tweak it in the same panel, like many other graphics editors. Initial import of color blending function for smudge tool. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=1b83ecae173641b0b08bccd0b207457bb549f9e6 It doesn't look like you change shade_pixels() and shade_region() in a backwards compatible way. Don't you break other things with that change? Otherwise it looks like a change we would want to merge. It would be a good idea to split this commit up so that there is one commit per bullet-point in your commit message. AFAIK, no one calls shade_pixels() and shade_regions(), and it seems these functions aren't updated for many years. So I reuse those functions, and update it. If you don't want to change existing code, we can simply create new functions instead. To import blending functions, we should also import the following patches. *Bugfix:app: GimpFgBgEditor: fix bug which caused a crash when palette-n_colors == 0. *Bugfix:app: GimpSmudge: set proper value for GimpBrushCore-scale parameter. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=blobdiff;f=app/paint/gimpsmudge.c;h=a12863618323aaa01f2079cbbea7aae3dfa41917;hp=6941eed8384ce2afd684ae56394cf9daf10da649;hb=2290ffd0d17138eba31ab8e19d904044705ec2fc;hpb=eb95189dc7493b5364ee8dc462aa46b0419ded87 *Bugfix:app:GimpSmudge: properly handles size dynamics to work. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commit;h=66f1b48d582d4bb23a05901d34b14add46b38837 * Some parameters in the toolbar can be edited using popup editor. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=2d5edbfe2fbba08ab4cf456586d5344a3c3a49cc If I understand your code correctly, you are replacing big widgets with smaller widgets that expand when you use them. Worth looking into further. I copied GimpContainerPopup source code and create a new classes named GimpPopup and GimpPopupButton. Its functions is simply to popup one time window, to grab the pointer, and to delete itself when another area is clicked. And then rewrite many tool options code to use those popup functions if it is used as a horizontal toolbar generator. I think GimpPopup is very useful classes to make simple popup GUI parts. 2011年1月4日20:46 peter sikking pe...@mmiworks.net: when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP.
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
しげっち wrote: I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list. I also spent most of a talk at an lgm discussing this topic. in the bigger scheme of things (space, how usable toolbars are) I do not see GIMP having a toolbar. 2011年1月4日20:46 peter sikking pe...@mmiworks.net: when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP. ==snip== steps 2-5 are what I bring to any project and customer I work with. I agree that these features must be reviewed by many people in official and commercial process, but we also want to have a prototype to get positive feed back. It's very good and superior point of the open source software to implement GUI freely by anyone and have review it by many other people. It's just a patch of the my private work for now, so we can review it and simply ignore many of them. Let's try step 2-5 based on the feedback from existing prototype. nice try, but: no. I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see: http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: 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] GUI enhancement patch from GIMP UI brainstorm blog
BTW, I cant find the dynamics editor implementation commits as a patch. Is it in the huge gui merge? Could you lik me to it. I find it interesting, but guiguru might object. Sorry, I misunderstand this paragraph. You can get the patch from this commit. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commit;h=e81acf1904353265cbbbd9c77ab9a465b54a890e Dynamics editor is implemented in app/tools/gimpdynamicsoptions-gui.c. Current implementation is very limited though. -- sigetch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
2011/1/5 peter sikking pe...@mmiworks.net: しげっち wrote: I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list. I also spent most of a talk at an lgm discussing this topic. in the bigger scheme of things (space, how usable toolbars are) I do not see GIMP having a toolbar. 2011年1月4日20:46 peter sikking pe...@mmiworks.net: when making UI, one has to: 1) identify the issue 2) find the cause 3) evaluate everything (including brainstorm ideas) 4) make a solutions model 5) design the UI 6) develop it and although things go a bit jumbled every once in a while, this is what happens here at GIMP. ==snip== steps 2-5 are what I bring to any project and customer I work with. I agree that these features must be reviewed by many people in official and commercial process, but we also want to have a prototype to get positive feed back. It's very good and superior point of the open source software to implement GUI freely by anyone and have review it by many other people. It's just a patch of the my private work for now, so we can review it and simply ignore many of them. Let's try step 2-5 based on the feedback from existing prototype. nice try, but: no. I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see: http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html Well, you don't permit the GIMP to have the toolbars even if it is OPTIONAL and it doesn't replace or overwrite any existing GUI policy ? I think it can be merged as an optional code, and safely ignore that feature in compile time of runtime switch. (currently I don't implement any switches though.) I think open source project can have several policy as a optional implementations, and it can provide alternative way for users who has alternative demands. -- sigetch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
sigetch (sige...@gmail.com) wrote: Well, you don't permit the GIMP to have the toolbars even if it is OPTIONAL and it doesn't replace or overwrite any existing GUI policy ? Each and every optional thing is a burden. Even if disabled it clutters the preferences dialog, it makes inconsistent User-Interfaces across installations (think about telephone support where you first have to figure out how the user interface on the other side actually looks) and it has the potential of confusing users. So before adding a new option we need to make sure that it is really necessary. I think it can be merged as an optional code, and safely ignore that feature in compile time of runtime switch. (currently I don't implement any switches though.) Compile-Time switches are a maintenance nightmare: If larger chunks of code are not compiled by default, the code quality tends to degrade with the time, since it does not automatically follow the rest of the code in the case of API changes etc. So another burden, which - given our very limited development ressources - is not a good idea to have. I think open source project can have several policy as a optional implementations, and it can provide alternative way for users who has alternative demands. I don't get how open source maps to several policys. Except maybe that one easily can fork an open source project, if the predominant policy feels wrong or unsuitable. Which btw. you're free to do (although I'd consider this a bad idea). I hope this helps, Simon -- si...@budig.de 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] GUI enhancement patch from GIMP UI brainstorm blog
I know this has been beat to death before, but just wanted to say please never take away any of my precious real estate at the top and bottom of screens with a horizontal toolbar or anything else! The aspect ratio of screens have gotten so wide these days, I have plenty of extra room at the sides, but not at the top and bottom:) Just my 2 cents. Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Question regarding ToolInfo and Gimp Context
I took a stab at explaining what I'm doing in the IRC channel, but I think I did a poor job, so here goes nothing. In short, I am working with a University lab in making an adaptation of Gimp. While most of our code does not interact with Gimp directly, we do make need to activate tools/actions at particular times. Currently I am running into a problem. We use GimpContext.set_tool(ToolInfo) to set the currently active tool. In our interface this is always called by a button in the toolbox. While this works for most tools and actions, some specific tools have issues. For example, trying to active Hue/Saturation from the toolbox requires that an image be selected before the Hue/Saturation window appears. My understanding is that this is because the tool is set for that window's context, and does not actually execute until the window has focus again (though I could be completely wrong on this). I was hoping someone here with an understanding of the tools architecture could explain to me whether or not I am right, and whether or not the approach I am considering - determining the last active window and giving it focus before activating tools - is in spirit with the existing engine, or if there is a better solution. The stroke selection tool does not seem to have the same limitation as the Hue/Saturation tool, which leads me to believe there may be a better option. Thanks.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
