Re: [Gimp-developer] Gimp interface changes
Nathael Pajani wrote: You are making a comparison to the Linux kernel that is completely inadequate Point of view. The whole point was about stable interfaces, and saying to the users to move back to the previous version if they did not like the changes (what if kernel developers started to say you that ?), but no more arguing about this, it seems everybody missed the point. Hi, I think the point made is clear and always was, but I don't think it holds water. Changing the kernel interface in an incompatible way would typically require large amounts of code to be rewritten, while changing the GIMP user interface in incompatible ways requires no code rewrites at all. Note, again, that the GIMP _programming_ interface is carefully being kept backwards compatible for the same reason the significant parts of the kernel user space API is, but a user interface does not have the same problem of backwards compatibility. As long as it is improving, most people will be happy with the changes. And as far as I can tell from almost obsessively having sought up and read comments on and reviews of GIMP 2.6 on various sites and forums for a long time now, most people think that GIMP 2.6 was an improvement UI wise and that we are heading in the right direction. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Quoting peter sikking pe...@mmiworks.net: so now we need a design problem. the course is short but intense, 3 days with me full-time to work up a solutions model and then they take some days to finish their presentation. so now huge redesign problems, more something like a compact tool. (like the free/poly select tool), or a tricky interactive dialog (like, combined brightness/contrast + levels + curves). please post your suggestions what we could do. A challenging problem that has not yet been addressed by GIMP's interface is how to interactively stroke paths, and not merely just to see the results simple stroking (thickness, color, dashing), but actually provide some presently non-existent capability such as tapering and perhaps even arrowheads. This is a particularly tricky problem because, like the current Text Tool, it requires both a dialog to choose certain settings as well as some on-canvas handles to interact with rendering (I am thinking here of control handles similar to the Paths Tool's, but that they affect the rendering and not the path itself). There is also a problem in that currently stroking a path works upon an existing drawable, and honors several paramaters such as the selection, layer modes, and paint tool options, whereas the Text Tool avoids these issues by creating a new layer. Personally, I think interactive path rendering to a new layer would be worthwhile in and of itself (creation of tapered curves is sorely missed by me), and would offer the advantage of permitting later modification of that rendering, but it would mean a departure from the current stroking behavior (which is a worthwhile capability not to be abandoned). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Hello all who put down good student UI projects. Clearly, Peter can't have his students do them all. Given this, would you consider putting them up at http://wiki.gimp.org/gimp/SummerOfCode2009ideas ? There are five days left to the application process, so some student may bite, and then it would (hopefully) get done. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Why limit it to path stroking? It might be more flexible to create a stroke style editor where you could visually adjust those attributes including tapers, brush spacing, jitter, gradient mapping, and ultimately new features like rotation, opacity and scaling (which tapering ultimately is), either as start/end values or randomized values. These stroke styles could be used either when stroking a path, a selection, or just when painting. -Rob A On 3/29/09, saulgo...@flashingtwelve.brickfilms.com saulgo...@flashingtwelve.brickfilms.com wrote: Quoting peter sikking pe...@mmiworks.net: so now we need a design problem. the course is short but intense, 3 days with me full-time to work up a solutions model and then they take some days to finish their presentation. so now huge redesign problems, more something like a compact tool. (like the free/poly select tool), or a tricky interactive dialog (like, combined brightness/contrast + levels + curves). please post your suggestions what we could do. A challenging problem that has not yet been addressed by GIMP's interface is how to interactively stroke paths, and not merely just to see the results simple stroking (thickness, color, dashing), but actually provide some presently non-existent capability such as tapering and perhaps even arrowheads. This is a particularly tricky problem because, like the current Text Tool, it requires both a dialog to choose certain settings as well as some on-canvas handles to interact with rendering (I am thinking here of control handles similar to the Paths Tool's, but that they affect the rendering and not the path itself). There is also a problem in that currently stroking a path works upon an existing drawable, and honors several paramaters such as the selection, layer modes, and paint tool options, whereas the Text Tool avoids these issues by creating a new layer. Personally, I think interactive path rendering to a new layer would be worthwhile in and of itself (creation of tapered curves is sorely missed by me), and would offer the advantage of permitting later modification of that rendering, but it would mean a departure from the current stroking behavior (which is a worthwhile capability not to be abandoned). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Sent from my mobile device ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New features that should be nice
Hello Gimp coders! I was thinking about 2 new features that would help a lot. 1 - the auto-save job. When you`re working and gimp crashes, your work is lost =x. If not a auto-save, a .bak file that you can save as xcf for recover work should be fine too. 2 - An option to save custom collor palettes. Yes, sometimes you are working on a big draw. Then when you finish a bit of the work and closes gimp, the color pallete you were working is lost. And it is very boring to keep note of any hexa code for colors. Just some ideas. How do you think about it? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
gimp-developer-boun...@lists.xcf.berkeley.edu wrote: Therefore I'd still consider the non-destructive crop feature at least a usability enhancement. At least personally I would assume that the crop tool of a professional tool like Gimp would offer this option as well. (Not sure whether PS has it.) I couldn't swear by it, but I don't think it does. I've had similar issues to you in Gimp regarding this issue. I've learnt to create a new layer above the image, fill it with with black and then apply a mask to it to reveal the image below. I'd quite like to have a way to be able to adjust the layer mask on canvas once it's been created. The nice thing about cropping with layers is that you can toggle their visibility, so you can check your old crop against your new one. This still doesn't solve the problem of making the mask in the first place because neither the mask nor select tools currently conceal the area of the image being masked. The crop tool applies a semi-opaque mask to the cropped area, but this isn't really satisfactory. In this case, your method of using the canvas window still has no replacement. However, adjusting the opacity of the mask has been specified for both the selection and crop tools and I'm trying to learn the gimp code with the hope of implementing the feature...cos I need it. :p I really only use the crop tool to remove unwanted data in order to speed up processing of the image from then on. This has proven to be an essential feature even for my (obsolete) 6.1Mpixel camera. David M. ---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] New features that should be nice
On Sun, Mar 29, 2009 at 2:57 PM, Eduardo Barijan eduwb.horizo...@gmail.com wrote: 2009/3/29, Chris Mohler cr33...@gmail.com: Save early, save often - and if in doubt, save a copy ;) Personally, I would turn off the auto-save feature if it was an option: I don't want to automatically save a huge image every X minutes - just my opinion. Hm... yes, auto-save huge images isnt so nice. But it would help cause the crashes I experience here. I don't use GIMP on windows very much at all, but I do use it often on linux - either way it does not crash very often... I just tested adding colors to a palette and closing GIMP (current SVN) - it saved them for me, and the new colors were available when I restarted GIMP. What version/OS are you using? I am using Windows and gimp version 2.6.3 final version. So how to add and save palletes then? I just tested again with XP and GIMP 2.6.6 - there have been some bug fixes between 2.6.3 and 2.6.6, so you should probably upgrade and see if it fixes your crashing problems and also saves your palettes... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Errors on Mac setup attempt for GIMP development
I am on Mac OS 10.4.11 (Tiger) with XCode 2.5. I am trying to follow the instructions for installing GIMP so that I can build it (then update the code to attempt a bug fix). I am a C/C++ newbie, but do development in PHP and JavaScript, so am not a coding newbie. I've followed the following instructions by doing MacPort installs. I am on the latest version of MacPort. When I try to install the various things the instructions say are required, it gets quite a ways through the procedures before ending with multiple errors. Any idea how I can successfully complete the install? Details follow: Here are my commands with the resulting (edited) results. sudo port install pkg-config --- Activating expat @2.0.1_0 --- Activating pkgconfig @0.23_1 --- Activating gnome-common @2.24.0_1 --- Activating perl5.8 @5.8.9_2 --- Activating perl5 @5.8.9_0 --- Activating p5-xml-parser @2.36_0 --- Activating intltool @0.40.6_0 sudo port install GEGL --- Activating babl @0.0.22_0 --- Activating XviD @1.1.3_1 --- Activating bzip2 @1.0.5_2 --- Activating cppunit @1.12.1_0 --- Activating dirac @1.0.2_0 --- Activating gperf @3.0.4_0 --- Activating libiconv @1.12_2 --- Activating ncursesw @5.7_0 --- Activating ncurses @5.7_0 --- Activating gettext @0.17_4 --- Activating p5-locale-gettext @1.05_0 --- Activating help2man @1.36.4_1 --- Activating m4 @1.4.12_1 --- Activating autoconf @2.63_0 --- Activating automake @1.10.2_0 --- Activating libmp4v2 @1.5.0.1_0 --- Activating libtool @2.2.6a_0 --- Activating faac @1.28_1 --- Activating faad2 @2.6.1_1 --- Activating gmake @3.81_0 --- Activating lame @3.98.2_0 --- Activating libogg @1.1.3_2 --- Activating xorg-bigreqsproto @1.0.2_0 --- Activating xorg-inputproto @1.5.0_0 --- Activating xorg-kbproto @1.0.3_0 --- Activating xorg-xproto @7.0.15_0 --- Activating xorg-libXau @1.0.4_0 --- Activating xorg-libXdmcp @1.0.2_0 --- Activating xorg-xcmiscproto @1.1.2_0 --- Activating xorg-xextproto @7.0.5_0 --- Activating xorg-xf86bigfontproto @1.1.2_0 --- Activating xorg-xtrans @1.2.3_0 --- Activating xorg-libX11 @1.2_0 --- Activating xorg-libXext @1.0.5_1 --- Activating xorg-randrproto @1.3.0_0 --- Activating xorg-renderproto @0.9.3_0 --- Activating xrender @0.9.4_5 --- Activating xorg-libXrandr @1.3.0_0 --- Activating libsdl @1.2.13_6 --- Activating libvorbis @1.2.0_1 --- Activating libtheora @1.0_0 --- Activating glib2 @2.18.3_0 --- Activating liboil @0.3.15_0 --- Activating schroedinger @1.0.5_1 --- Activating yasm @0.7.2_0 --- Activating x264 @20090311_0 --- Activating zlib @1.2.3_2 --- Activating ffmpeg @0.5_1+darwin_i386 --- Activating freetype @2.3.9_0+macosx --- Activating fontconfig @2.6.0_2+macosx --- Activating jpeg @6b_3 --- Activating libpng @1.2.35_0 --- Activating xpm @3.5.7_0 --- Activating gd2 @2.0.35_4 --- Activating Xft2 @2.1.13_1 --- Activating libpixman @0.14.0_0 --- Activating cairo @1.8.6_4+macosx And now the errors start, so I'm including everything: --- Cleaning cairo --- Fetching pango --- Attempting to fetch pango-1.24.0.tar.bz2 from http://distfiles.macports.org/pango --- Verifying checksum(s) for pango --- Extracting pango --- Applying patches to pango --- Configuring pango --- Building pango --- Staging pango into destroot Error: Target org.macports.destroot returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/pango-1.24.0 make install DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/destroot returned error 2 Command output: -- Installing ./html/pango-Glyph-Storage.html -- Installing ./html/pango-Layout-Objects.html -- Installing ./html/pango-Miscellaneous-Utilities.html -- Installing ./html/pango-Modules.html -- Installing ./html/pango-OpenType-Font-Handling.html -- Installing ./html/pango-Scripts-and-Languages.html -- Installing ./html/pango-Tab-Stops.html -- Installing ./html/pango-Text-Attributes.html -- Installing ./html/pango-Text-Processing.html -- Installing ./html/pango-Version-Checking.html -- Installing ./html/pango-Vertical-Text.html -- Installing ./html/pango-Win32-Fonts-and-Rendering.html -- Installing ./html/pango-X-Fonts-and-Rendering.html -- Installing ./html/pango-Xft-Fonts-and-Rendering.html -- Installing ./html/pango-hierarchy.html -- Installing ./html/pango-querymodules.html -- Installing ./html/pango.devhelp -- Installing ./html/pango.devhelp2 -- Installing ./html/pango.html -- Installing ./html/rendering.html -- Installing ./html/right.png -- Installing ./html/rotated-text.png -- Installing ./html/style.css -- Installing ./html/tools.html -- Installing ./html/up.png /bin/sh: line 1: gtkdoc-rebase: command not found make[3]: *** [install-data-local] Error 127 make[2]: *** [install-am] Error 2 make[1]: *** [install] Error 2 make: *** [install-recursive] Error 1 Error: The following dependencies failed
Re: [Gimp-developer] New features that should be nice
On Sun, Mar 29, 2009 at 2:22 PM, Eduardo Barijan eduwb.horizo...@gmail.com wrote: Hello Gimp coders! I was thinking about 2 new features that would help a lot. 1 - the auto-save job. When you`re working and gimp crashes, your work is lost =x. If not a auto-save, a .bak file that you can save as xcf for recover work should be fine too. Save early, save often - and if in doubt, save a copy ;) Personally, I would turn off the auto-save feature if it was an option: I don't want to automatically save a huge image every X minutes - just my opinion. 2 - An option to save custom collor palettes. Yes, sometimes you are working on a big draw. Then when you finish a bit of the work and closes gimp, the color pallete you were working is lost. And it is very boring to keep note of any hexa code for colors. I just tested adding colors to a palette and closing GIMP (current SVN) - it saved them for me, and the new colors were available when I restarted GIMP. What version/OS are you using? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New features that should be nice
Eduardo Barijan wrote: Hello Gimp coders! I was thinking about 2 new features that would help a lot. 1 - the auto-save job. When you`re working and gimp crashes, your work is lost =x. If not a auto-save, a .bak file that you can save as xcf for recover work should be fine too. See http://bugzilla.gnome.org/show_bug.cgi?id=138373 This lists some of the issues related to auto-save; the last few comments in particular. 2 - An option to save custom collor palettes. Yes, sometimes you are working on a big draw. Then when you finish a bit of the work and closes gimp, the color pallete you were working is lost. And it is very boring to keep note of any hexa code for colors. There are a number of enhancement requests about palettes. I guess that http://bugzilla.gnome.org/show_bug.cgi?id=346884 might be an interesting one. But maybe that is not what you want, your complaint is a bit unclear. 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] Gimp interface changes
David Gowers a écrit : Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) Removing customizability is best. I'm not kidding. Customizability is what happens when you can't figure out how to make the program behave sensibly in 99% of situations. Every point of customization is also a point of potential confusion, for both the coder and the user. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg These are dockable. And we can create as many windows as we want, with groups of these tabbed inside. This is customization. The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable as well. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. Difficulty of maintenance as hard-coded options go up is a fact, it's not at all insulting. In order to achieve very reliable code, software must be tested with every combination of options available. This means to achieve moderate reliability, software must be tested with 50% or more of the combinations of options available... To show some perspective on this, you can regard each togglable option in the GIMP preferences as a bit in a binary number. In SVN head, this binary number is 43 bits long [...] means that there are 8,796,093,022,208 combinations of options to test already. [] I cannot agree with you here. Once again, I'll use the kernel as an example here: I won't bother counting the number of options and the possibilities resulting, I'll just state that it's the biggest piece of code I have ever seen, and still the most reliable. Are kernel programmers superhero ? genius ? Tell me, I'm one of them, I'll appreciate :) Another example I'll use as some spoke about it previously: Gnome. I'll not bother counting the options you can find in gconf either. Still, gnome is stable (from my point of view at least, but most will agree) and even if it's not a perfect display manager, I think it's a very good one that manages to perform it's task. And the Gnome example is most accurate, don't try saying the contrary this time: it uses GTK, and it's also a GNU project. So with these two example at hand I cannot agree at all. Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? Alexandre addressed this, but also : 95% of software UIs suck quite badly. This is because most often they are simply written as an afterthought to the backend: 'oh, we need to make this FOO capacity available to the user. What's the easiest way to do that?' rather than designing the frontend first and designing the backend so it fits well with the frontend. This leads to incoherent UI -- and customization of dubious value. Right and wrong. Right, the UI must not come as an afterthought. But the UI is not the main part of an Image manipulation program, it's here to give access to it's capabilities. So designing the UI first is just silly. Both have to be thought in parallel. But this is very hard for a project like Gimp, when programmers are more interested in the backend part and when this part is made up of small parts added one by one with no global initial view. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. The recent changes, OTOH, were based on real UI work with users to discover what things users most often had trouble with. I just hope you did not ask users that would like to have a photoshop clone for free. That's why I pasted the points from GimpCon 2006. Users tend to want what they have with the commercial software. Gimp is not that. And do not tell me (or others) it is not good because other programs have too much customization possibilities. It is not good, precisely because they have too much customization possibilities. We need a meaningful minimum of customization, the absolute least customization for the greatest potential effect; that is the ideal customization situation for any software. I still do not see why more possible customization hurts. When the UI is well thought, then customization goes easy. And we are going to make some much more drastic changes in the future. Please remember that user are working with The Gimp. Changing the user interface drastically because you do not feel like keeping the old one will discourage Feelings have nothing to do with this. Reasoned, rational, open review does. Anyway, changes discourage and encourage people all the time, but changes should be made due to their
Re: [Gimp-developer] Errors on Mac setup attempt for GIMP development
Hi, macports is known to fail frequently. Possible solutions when you meet macports errors include : * Get support from the macports team; each time i went on their IRC channel i got good and fast help * Build components manually - longer and annoying but at least you can control what's happening I might just add that GIMP on mac is a dependency hell, so if you're not used to installing stuff GIMP might be a steep start =) Guud luck -- Auria I am on Mac OS 10.4.11 (Tiger) with XCode 2.5. I am trying to follow the instructions for installing GIMP so that I can build it (then update the code to attempt a bug fix). I am a C/C++ newbie, but do development in PHP and JavaScript, so am not a coding newbie. I've followed the following instructions by doing MacPort installs. I am on the latest version of MacPort. When I try to install the various things the instructions say are required, it gets quite a ways through the procedures before ending with multiple errors. Any idea how I can successfully complete the install? Details follow: Here are my commands with the resulting (edited) results. sudo port install pkg-config --- Activating expat @2.0.1_0 --- Activating pkgconfig @0.23_1 --- Activating gnome-common @2.24.0_1 --- Activating perl5.8 @5.8.9_2 --- Activating perl5 @5.8.9_0 --- Activating p5-xml-parser @2.36_0 --- Activating intltool @0.40.6_0 sudo port install GEGL --- Activating babl @0.0.22_0 --- Activating XviD @1.1.3_1 --- Activating bzip2 @1.0.5_2 --- Activating cppunit @1.12.1_0 --- Activating dirac @1.0.2_0 --- Activating gperf @3.0.4_0 --- Activating libiconv @1.12_2 --- Activating ncursesw @5.7_0 --- Activating ncurses @5.7_0 --- Activating gettext @0.17_4 --- Activating p5-locale-gettext @1.05_0 --- Activating help2man @1.36.4_1 --- Activating m4 @1.4.12_1 --- Activating autoconf @2.63_0 --- Activating automake @1.10.2_0 --- Activating libmp4v2 @1.5.0.1_0 --- Activating libtool @2.2.6a_0 --- Activating faac @1.28_1 --- Activating faad2 @2.6.1_1 --- Activating gmake @3.81_0 --- Activating lame @3.98.2_0 --- Activating libogg @1.1.3_2 --- Activating xorg-bigreqsproto @1.0.2_0 --- Activating xorg-inputproto @1.5.0_0 --- Activating xorg-kbproto @1.0.3_0 --- Activating xorg-xproto @7.0.15_0 --- Activating xorg-libXau @1.0.4_0 --- Activating xorg-libXdmcp @1.0.2_0 --- Activating xorg-xcmiscproto @1.1.2_0 --- Activating xorg-xextproto @7.0.5_0 --- Activating xorg-xf86bigfontproto @1.1.2_0 --- Activating xorg-xtrans @1.2.3_0 --- Activating xorg-libX11 @1.2_0 --- Activating xorg-libXext @1.0.5_1 --- Activating xorg-randrproto @1.3.0_0 --- Activating xorg-renderproto @0.9.3_0 --- Activating xrender @0.9.4_5 --- Activating xorg-libXrandr @1.3.0_0 --- Activating libsdl @1.2.13_6 --- Activating libvorbis @1.2.0_1 --- Activating libtheora @1.0_0 --- Activating glib2 @2.18.3_0 --- Activating liboil @0.3.15_0 --- Activating schroedinger @1.0.5_1 --- Activating yasm @0.7.2_0 --- Activating x264 @20090311_0 --- Activating zlib @1.2.3_2 --- Activating ffmpeg @0.5_1+darwin_i386 --- Activating freetype @2.3.9_0+macosx --- Activating fontconfig @2.6.0_2+macosx --- Activating jpeg @6b_3 --- Activating libpng @1.2.35_0 --- Activating xpm @3.5.7_0 --- Activating gd2 @2.0.35_4 --- Activating Xft2 @2.1.13_1 --- Activating libpixman @0.14.0_0 --- Activating cairo @1.8.6_4+macosx And now the errors start, so I'm including everything: --- Cleaning cairo --- Fetching pango --- Attempting to fetch pango-1.24.0.tar.bz2 from http://distfiles.macports.org/pango --- Verifying checksum(s) for pango --- Extracting pango --- Applying patches to pango --- Configuring pango --- Building pango --- Staging pango into destroot Error: Target org.macports.destroot returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/pango-1.24.0 make install DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/destroot returned error 2 Command output: -- Installing ./html/pango-Glyph-Storage.html -- Installing ./html/pango-Layout-Objects.html -- Installing ./html/pango-Miscellaneous-Utilities.html -- Installing ./html/pango-Modules.html -- Installing ./html/pango-OpenType-Font-Handling.html -- Installing ./html/pango-Scripts-and-Languages.html -- Installing ./html/pango-Tab-Stops.html -- Installing ./html/pango-Text-Attributes.html -- Installing ./html/pango-Text-Processing.html -- Installing ./html/pango-Version-Checking.html -- Installing ./html/pango-Vertical-Text.html -- Installing ./html/pango-Win32-Fonts-and-Rendering.html -- Installing ./html/pango-X-Fonts-and-Rendering.html -- Installing ./html/pango-Xft-Fonts-and-Rendering.html -- Installing ./html/pango-hierarchy.html -- Installing
Re: [Gimp-developer] Gimp interface changes
On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani g...@nathael.net wrote: David Gowers a écrit : Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) Removing customizability is best. I'm not kidding. Customizability is what happens when you can't figure out how to make the program behave sensibly in 99% of situations. Every point of customization is also a point of potential confusion, for both the coder and the user. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg These are dockable. And we can create as many windows as we want, with groups of these tabbed inside. This is customization. The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable as well. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. Difficulty of maintenance as hard-coded options go up is a fact, it's not at all insulting. In order to achieve very reliable code, software must be tested with every combination of options available. This means to achieve moderate reliability, software must be tested with 50% or more of the combinations of options available... To show some perspective on this, you can regard each togglable option in the GIMP preferences as a bit in a binary number. In SVN head, this binary number is 43 bits long [...] means that there are 8,796,093,022,208 combinations of options to test already. [] I cannot agree with you here. Once again, I'll use the kernel as an example here: I won't bother counting the number of options and the possibilities resulting, I'll just state that it's the biggest piece of code I have ever seen, and still the most reliable. Are kernel programmers superhero ? genius ? The kernel is made up of modules, which are almost entirely independent. With this, the total amount of testing needed is much reduced, because any given module has only a few options and can be tested independently. GIMP, which is an application, has a UI, and all options effect the user's perception of that UI. For the core of the program, a simplification such as is applied to the Linux kernel, is impossible; the core behaviour of the program stands as one whole thing to the user, and we test it as one whole thing. This kernel comparison just does not work. Please stop using it. Tell me, I'm one of them, I'll appreciate :) Another example I'll use as some spoke about it previously: Gnome. I'll not bother counting the options you can find in gconf either. Still, gnome is stable (from my point of view at least, but most will agree) and even if it's not a perfect display manager, I think it's a very good one that manages to perform it's task. And the Gnome example is most accurate, don't try saying the contrary this time: it uses GTK, and it's also a GNU project. Gnome also is structured in many individually testable components, like the kernel, and unlike GIMP. I (and, I think, some of the core GIMP developers) would like GIMP to be structured like Linux or Gnome -- this has great advantages -- but it definitely is not where GIMP is at currently. Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? Alexandre addressed this, but also : 95% of software UIs suck quite badly. This is because most often they are simply written as an afterthought to the backend: 'oh, we need to make this FOO capacity available to the user. What's the easiest way to do that?' rather than designing the frontend first and designing the backend so it fits well with the frontend. This leads to incoherent UI -- and customization of dubious value. Right and wrong. Right, the UI must not come as an afterthought. But the UI is not the main part of an Image manipulation program, it's here to give access to it's capabilities. So designing the UI first is just silly. Both have to be thought in parallel. But this is very hard for a project like Gimp, when programmers are more interested in the backend part and when this part is made up of small parts added one by one with no global initial view. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. I don't know what to say to such a viewpoint. Of course you need to adjust your plans as you get feedback from actually implementing them -- this is what led to the current form of the free-select tool -- but the whole idea of an application is to provide capabilities to the user .. the interface should not be dependent in any way on how the
[Gimp-developer] Highlights/Shadow compression
Hi, I am new in GIMP.I am a graduate student and have prior Image processing background.I want to get involved in GSOC 2009 and am interested in the project Highlights/Shadow compression mentored by N./N.Is there any specific qualification task for this project? Thanks, Indrani ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
The more I read this, the more I feel that a solution like the present in Inkscape (wich is not precisely an example of a great interface) would be a one-time solution for everyone. Just to see what I'm talking about, open a new Inkscape session, go the the right edge of the window and drag the bar to the left. There's the space that will be used to dock the dialogs. If GIMP would have something like that to dock the floating windows and toolbox, I guess most of the one-window fans will be satisfied. I can understand it's not a trivial work, but seems to be a reasonable solution that can make everyone happy. I wouldn't need more preferences options, it can behave like the current windows regarding how the windows positions are saved. I guess that would be a tad problematic when there is more than one image open, though. I'd personally stick with the floating windows just like they are now, but maybe that possibility would calm some people out there. :-) Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Rob Antonishen writes: Why limit it to path stroking? It might be more flexible to create a stroke style editor where you could visually adjust those attributes including tapers, brush spacing, jitter, gradient mapping, and ultimately new features like rotation, opacity and scaling (which tapering ultimately is), either as start/end values or randomized values. These stroke styles could be used either when stroking a path, a selection, or just when painting. It would be SO nice to be able to taper lines when drawing. It could be handled just like fade out is now; or it could be handled in Brush Dynamics, adjusting Size with Distance. (The other attributes you mention would be nice too, but tapering is the one I've wished for most often.) Either way the UI would be simple, so it's probably not a good student UI project, but it sure would be useful as a drawing tool attribute. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] A very simple feature that would be very nice...
Hi ! Playing with gimp lately, I've been thinking that it would be nice to be able to save the toolbox state (and maybe other things related to dockable window placement) in profiles. As an example, when I make photo editing, I use different tools that when I draw. Thanks to gimp's system, I can make toolbox changes that reflect those needs. But it's pretty long to play with the toolbox, and as there's no save button available to save my changes, I don't do that that often. I think it's a bit sad. Saving windows state would have the same purpose : being able to quickly switch between different workspaces that are useful for different works, while keeping a clean UI for each work... Thanks ! (PS : Sorry for my bad english) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Errors on Mac setup attempt for GIMP development
Hi, try the suggestions at http://trac.macports.org/ticket/18200 plus links? Best Mark http://www.halloit.com Key ID 046B65CF M Gagnon - auria...@gmail.com wrote: Hi, macports is known to fail frequently. Possible solutions when you meet macports errors include : * Get support from the macports team; each time i went on their IRC channel i got good and fast help * Build components manually - longer and annoying but at least you can control what's happening I might just add that GIMP on mac is a dependency hell, so if you're not used to installing stuff GIMP might be a steep start =) Guud luck -- Auria I am on Mac OS 10.4.11 (Tiger) with XCode 2.5. I am trying to follow the instructions for installing GIMP so that I can build it (then update the code to attempt a bug fix). I am a C/C++ newbie, but do development in PHP and JavaScript, so am not a coding newbie. I've followed the following instructions by doing MacPort installs. I am on the latest version of MacPort. When I try to install the various things the instructions say are required, it gets quite a ways through the procedures before ending with multiple errors. Any idea how I can successfully complete the install? Details follow: Here are my commands with the resulting (edited) results. sudo port install pkg-config --- Activating expat @2.0.1_0 --- Activating pkgconfig @0.23_1 --- Activating gnome-common @2.24.0_1 --- Activating perl5.8 @5.8.9_2 --- Activating perl5 @5.8.9_0 --- Activating p5-xml-parser @2.36_0 --- Activating intltool @0.40.6_0 sudo port install GEGL --- Activating babl @0.0.22_0 --- Activating XviD @1.1.3_1 --- Activating bzip2 @1.0.5_2 --- Activating cppunit @1.12.1_0 --- Activating dirac @1.0.2_0 --- Activating gperf @3.0.4_0 --- Activating libiconv @1.12_2 --- Activating ncursesw @5.7_0 --- Activating ncurses @5.7_0 --- Activating gettext @0.17_4 --- Activating p5-locale-gettext @1.05_0 --- Activating help2man @1.36.4_1 --- Activating m4 @1.4.12_1 --- Activating autoconf @2.63_0 --- Activating automake @1.10.2_0 --- Activating libmp4v2 @1.5.0.1_0 --- Activating libtool @2.2.6a_0 --- Activating faac @1.28_1 --- Activating faad2 @2.6.1_1 --- Activating gmake @3.81_0 --- Activating lame @3.98.2_0 --- Activating libogg @1.1.3_2 --- Activating xorg-bigreqsproto @1.0.2_0 --- Activating xorg-inputproto @1.5.0_0 --- Activating xorg-kbproto @1.0.3_0 --- Activating xorg-xproto @7.0.15_0 --- Activating xorg-libXau @1.0.4_0 --- Activating xorg-libXdmcp @1.0.2_0 --- Activating xorg-xcmiscproto @1.1.2_0 --- Activating xorg-xextproto @7.0.5_0 --- Activating xorg-xf86bigfontproto @1.1.2_0 --- Activating xorg-xtrans @1.2.3_0 --- Activating xorg-libX11 @1.2_0 --- Activating xorg-libXext @1.0.5_1 --- Activating xorg-randrproto @1.3.0_0 --- Activating xorg-renderproto @0.9.3_0 --- Activating xrender @0.9.4_5 --- Activating xorg-libXrandr @1.3.0_0 --- Activating libsdl @1.2.13_6 --- Activating libvorbis @1.2.0_1 --- Activating libtheora @1.0_0 --- Activating glib2 @2.18.3_0 --- Activating liboil @0.3.15_0 --- Activating schroedinger @1.0.5_1 --- Activating yasm @0.7.2_0 --- Activating x264 @20090311_0 --- Activating zlib @1.2.3_2 --- Activating ffmpeg @0.5_1+darwin_i386 --- Activating freetype @2.3.9_0+macosx --- Activating fontconfig @2.6.0_2+macosx --- Activating jpeg @6b_3 --- Activating libpng @1.2.35_0 --- Activating xpm @3.5.7_0 --- Activating gd2 @2.0.35_4 --- Activating Xft2 @2.1.13_1 --- Activating libpixman @0.14.0_0 --- Activating cairo @1.8.6_4+macosx And now the errors start, so I'm including everything: --- Cleaning cairo --- Fetching pango --- Attempting to fetch pango-1.24.0.tar.bz2 from http://distfiles.macports.org/pango --- Verifying checksum(s) for pango --- Extracting pango --- Applying patches to pango --- Configuring pango --- Building pango --- Staging pango into destroot Error: Target org.macports.destroot returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/pango-1.24.0 make install DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_pango/work/destroot returned error 2 Command output: -- Installing ./html/pango-Glyph-Storage.html -- Installing ./html/pango-Layout-Objects.html -- Installing ./html/pango-Miscellaneous-Utilities.html -- Installing ./html/pango-Modules.html -- Installing ./html/pango-OpenType-Font-Handling.html -- Installing ./html/pango-Scripts-and-Languages.html -- Installing ./html/pango-Tab-Stops.html -- Installing ./html/pango-Text-Attributes.html -- Installing ./html/pango-Text-Processing.html -- Installing ./html/pango-Version-Checking.html -- Installing ./html/pango-Vertical-Text.html -- Installing
