Re: [Gimp-developer] Who's coming to GIMPCon?
Hi, On Fri, 2004-06-04 at 13:22, Dave Neary wrote: A number of people have suggested that a list of attendees who have confirmed they're going would be useful - so could anyone who plans to be there reply to the lists saying so, please? Don't forget to register at http://2004.guadec.org/register/ and request free accommodation if you need it - there's floorspace for all, for a groovy atmosphere. I've registered for GUADEC (and for floorspace accommodation as well) - and I hope to be able to go there. ;) Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Blur plug-in
Hi, Sven Neumann wrote: I'd like to get some feedback on the following plan for the Blur plug-in (details are in http://bugzilla.gnome.org/show_bug.cgi?id=142318): The plan is to remove the randomize and repeat functionality. That would allow us to also remove the (quite confusing) dialog. Sounds OK to me. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Conference stand?
Hi all, Do people think that it is worthwhile for the GIMP to have a stand at GUADEC? It would perhaps be a way to sell some t-shirts, have a couple of computers with people doing demos, and have an easy popint-of-contact for people when they were on their down-time. The problem is that it would need to have some work done for it - posters and banners, for example, and I will not be able to do that. Are there people who thionk this is a very good idea, who are prepared to put some time into preparing the stand and putting it up when we get to Norway? Please reply on the list, we can decide before the end of the week whether to do this depending on the response we get. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Blur plug-in
Hi, GSR - FR [EMAIL PROTECTED] writes: The plan is to remove the randomize and repeat functionality. That would allow us to also remove the (quite confusing) dialog. Filters-Blur-Blur would then be a simple blur with a 3x3 convolution kernel. It would be fast and easy to use but of course we it would be less powerful. So the question is, is anyone actually using this functionality? Are there scripts out there that rely on plug-in-blur-randomize to be available? Why not just ditch it completly then? If it just a 3x3 convolution that you have to manually repeat, and there are already other filters and scripts that do the same. The point of repeat is not having to rerun manually to get a bigger radius blur. Someone was doing a version that used another channel to control the repeats, which is a nice improvement. If that is accepted as improvement it should stay, otherwise I see no reason to keep it along the generic matrix one and its presets. Sorry, but what other scripts or plug-ins are you referring to? IMO it would be a good thing to have a simple and fast plug-in that does the job w/o a dialog and I fail to see what other plug-in would provide this functionality. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Blur plug-in
[EMAIL PROTECTED] (2004-06-07 at 1649.35 +0200): Sorry, but what other scripts or plug-ins are you referring to? IMO it would be a good thing to have a simple and fast plug-in that does the job w/o a dialog and I fail to see what other plug-in would provide this functionality. Convolution matrix, and there are scripts floating around that give matrix presets. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2.0.1 compilation problem.
Hi, I'm having problems compiling Gimp 2.0.1 on my Conectiva Linux 9 machine. The error is: if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../app -I/usr/local/gtk+/include/gtk-2.0 -I/usr/local/glib/include/glib-2.0 -I/usr/local/glib/lib/glib-2.0/include -I/usr/local/glib/include/glib-2.0 -I/usr/local/glib/lib/glib-2.0/include -I/usr/local/pango/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/local/gimp/include -DG_LOG_DOMAIN=\Gimp-Text\ -I/usr/local/fontconfig/include -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -O3 -march=athlon-xp -Wall -MT gimpfontlist.o -MD -MP -MF .deps/gimpfontlist.Tpo \ -c -o gimpfontlist.o `test -f 'gimpfontlist.c' || echo './'`gimpfontlist.c; \ then mv -f .deps/gimpfontlist.Tpo .deps/gimpfontlist.Po; \ else rm -f .deps/gimpfontlist.Tpo; exit 1; \ fi gimpfontlist.c: In function `gimp_font_list_font_desc_from_pattern': gimpfontlist.c:290: `FC_WIDTH' undeclared (first use in this function) gimpfontlist.c:290: (Each undeclared identifier is reported only once gimpfontlist.c:290: for each function it appears in.) gimpfontlist.c:294: `FC_WIDTH_NORMAL' undeclared (first use in this function) gimpfontlist.c:297: `FC_WIDTH_ULTRACONDENSED' undeclared (first use in this function) gimpfontlist.c:300: `FC_WIDTH_EXTRACONDENSED' undeclared (first use in this function) gimpfontlist.c:303: `FC_WIDTH_CONDENSED' undeclared (first use in this function) gimpfontlist.c:306: `FC_WIDTH_SEMICONDENSED' undeclared (first use in this function) gimpfontlist.c:309: `FC_WIDTH_SEMIEXPANDED' undeclared (first use in this function) gimpfontlist.c:312: `FC_WIDTH_EXPANDED' undeclared (first use in this function) gimpfontlist.c:315: `FC_WIDTH_EXTRAEXPANDED' undeclared (first use in this function) gimpfontlist.c:318: `FC_WIDTH_ULTRAEXPANDED' undeclared (first use in this function) gimpfontlist.c: In function `gimp_font_list_load_names': gimpfontlist.c:347: `FC_WIDTH' undeclared (first use in this function) make[3]: *** [gimpfontlist.o] Error 1 make[3]: Leaving directory `/usr/src/gimp-2.0.1/app/text' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/gimp-2.0.1/app' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gimp-2.0.1' make: *** [all] Error 2 I have seen other messages on mailing lists regarding this same problem. The proposed solution is, AFAICT, to remove the outdated fontconfig header files. This doesn't seen to be a viable solution for me. Let me explain: gimp 2.0.1 depends on gtk+ 2.4.x and on pango with the xft backend. To compile the gtk+ 2.4.x compliant pango I need libXft.so. This file and the related xft-devel files are inside the fontconfig-devel package on Conectiva distribution. So I neeed fontconfig-devel (the outdated one). I have also compiled fontconfig 2.2.0 as updated gimp and gtk+ both require. I think my distribution should have two separate packages: fontconfig-devel and xft-devel. I have already asked them to consider creating them but until I eventually manage to get these packages I'm looking for another solution. On the other side, I believe gimp should be able to use just the indicated fontconfig installation. I'm setting the following variables on gimp configuration and still can't compile gimp: PKG_CONFIG_PATH=/usr/local/fontconfig-2.2.0/lib/pkgconfig CPPFLAGS=-I/usr/local/fontconfig-2.2.0/include LD_LIBRARY_PATH=/usr/local/fontconfig-2.2.0/lib To resume the situation, I believe that both the Conectiva distribution is wrong (it should have separate packages for fontconfig and xft) and gimp configure/compile process is wrong (it should be enough to set the proper variables and get it compile itself using the indicated library). Could this fix, if really considered proper, be included in gimp ASAP? I'm trying to correct both wrongs and/or learn more on the subject during the process. Thanks a lot for your attention, Rodrigo Severo -- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
Hi Simon, Visually pressing down CTRL or ALT is immediately visible in the tool options: The mode switch will switch accordingly. What else would you suggest to communicate this more clearly? When users are concentrated on drawing a path (and at the same time are exploring different keyboard shortcuts) they will pay few attention to changes in the tool options. Instead, they will give their attention to the image area, here especially to cursor feedback (and hopefully the status line!). The major problem I see here is that when pressing CTRL (Design mode) while the mouse is not located over the path, there is no interaction possible (which is shown by the concerning icon). But there is no hint in the status bar WHY interaction is not possible. I'm not sure about the actual text, but maybe something like 'Move the mouse pointer over the path to edit it'(?) would be helpful and support exploration. Basically it is impossible to really compare the path tool in 1.2 and the path tool in 2.0. I have rewritten the Path tool from scratch, removing arbitrary limitations and implementing some new ideas. Yes, I know it's completely built from the scratch - and I think it's really very good! I tried the 1.2 path tool, and was not happy with it. Nevertheless, on the first look, four modes seem to be more intuitive than three, as they hide les information from the users. Four buttons, combined with simple keyboard shortcuts for a quick navigation, are very easy to learn. But when I read this mail, I just realised that the tool is way more complex than it seemed to be on the first look, and that simple keyboard shortcuts are not realisable. Given the prerequisite, that the whole tool should be usable without having to move the mouse back and forth to a buttonbar (jimmac already wrote about this) and the need for a modifier (SHIFT) we have two modifiers left, which lead to the three modes of the existing tool. In theory we could use CTRL+ALT for a fourth mode, but this would require the user of the tool to be quite a finger acrobat and is probably not really a good idea. That's true. I just didn't realise that there is such a lot of functionality. Further below, you said that the path tool is not for newbies, but for people who will use it on a regular basis and willing to invest some effort to study it. I know it's a bit sobering, but studies on help/manual usage showed that only very very few people actually read manuals. That's why an intuitive and easy to learn interaction design is so important! I admit that my suggestions were short-sighted, I just did not know about the whole complexity! but still I think that especially users who are not image manipulation experts need a bit more support with respect to the path tool. Especially, a hint on how to remove path segments and points is missing. Maybe at least provide a tooltip text for the three modes (Design: 'Create new anchors and shape the path', Edit: 'Add [Ctrl] and remove [Ctrl-shift] elements' - rough wording). So, if you propose to add a fourth mode please also propose a way to get out of the dilemma explained above. I hope you can understand, why I am a bit skeptical about your suggestion. Yes, I understand now - really complicated stuff 8-) But nevertheless, I hope you don't mind if I think of it some more, talk to some colleagues... not to change the conception of the tool, but maybe to find some very small and simple solutions to facilitate the learning. Have a nice day 8-) /ellen -- __ Ellen Reitmayr email: [EMAIL PROTECTED] Usability Engineer mobil: +49.177.3325867 relevantive AG fon: +49.30.23455630 Zehdenicker Str. 21 fax: +49.30.23455639 10119 Berlinweb: www.relevantive.de ___ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Usability test - Results available
Hi, [this is a response to both jimmac and sven] Selection shortcuts: No, I didn't know that there is a difference between the modifiers pressed when you start to create the selection and the modifiers you press while adjusting the selection - it's really very powerful and should not be lost. However, it's hard to learn... As I wrote in response to Simon, studies have shown that only few users actually read the docs - especially if it's about something that seems to be simple, such as selection modes. For such users, it is likely to happen that they will not understand the concept without any hints (just as me and the users I tested 8-)), and we/they should be supported in a way! I think it might help if there were buttons/radio buttons for centered/non-centered selection in the tool options. Additionally, there should be tooltip texts to explain the shortcuts (e.g. Mode Add: 'Add to selection - [SHIFT] while clicking', Centered Selection: 'Centered selection - [CTRL] while dragging' - rough wording). Popup dialogs for transformation: - In deed, the settings get lost when moving to another image - I thought they would persist! But another reason why I think it is better to keep the dialogs for transformation is that it is uncommon to have confirmation/cancel buttons in the tool options dialog. I'm not sure, but as much as I'm concerned there is no tool that makes actual changes to the image in the tool options. Mostly, you can define settings/options there (as indicated by the label), but to change the image you have to interactively click into the image. And providing the transformation parameters in the tool options without offering confirm/reset would surely result in numerous errors. Greetings, /ellen -- __ Ellen Reitmayr email: [EMAIL PROTECTED] Usability Engineer mobil: +49.177.3325867 relevantive AG fon: +49.30.23455630 Zehdenicker Str. 21 fax: +49.30.23455639 10119 Berlinweb: www.relevantive.de ___ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Gimp 2.0.1 compilation problem.
Hi, Rodrigo Severo [EMAIL PROTECTED] writes: I think my distribution should have two separate packages: fontconfig-devel and xft-devel. I have already asked them to consider creating them but until I eventually manage to get these packages I'm looking for another solution. On the other side, I believe gimp should be able to use just the indicated fontconfig installation. I'm setting the following variables on gimp configuration and still can't compile gimp: PKG_CONFIG_PATH=/usr/local/fontconfig-2.2.0/lib/pkgconfig CPPFLAGS=-I/usr/local/fontconfig-2.2.0/include LD_LIBRARY_PATH=/usr/local/fontconfig-2.2.0/lib To resume the situation, I believe that both the Conectiva distribution is wrong (it should have separate packages for fontconfig and xft) and gimp configure/compile process is wrong (it should be enough to set the proper variables and get it compile itself using the indicated library). Could this fix, if really considered proper, be included in gimp ASAP? You didn't suggest a fix for GIMP and actually there is nothing to fix in GIMP since the problem is entirely on your harddisk. All you need to do is to remove the offending header from the include search patch of the compiler. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: Blur plug-in
[EMAIL PROTECTED] (2004-06-07 at 1759.17 +0200): calling the convolution matrix plug in and scripts to preset it a simple replacement ? Well, what would you call a script that just puts a menu entry and calls convolution matrix with a fixed matrix? Please rephrase that to a powerful replacement that can be used by the more then average(new) gimp user. Would this mean having a script-fu menu entry fill convolution matrix for : blur/sharpen/edge detect etc. Those already exists. The ones I got have some extra controls, but nothing disallows making no dialog versions. 2. when using the randomize option the preview makes no real sense since by nature you'll never get twice the same result. Depends how the code is done, using pseudo random and taking into account 2d coord it should provide repeatable results. 4. If a bigger blur is needed use the gausian blur instead of repeating. They are different things, though, box vs guassian. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
Hi, Ellen Reitmayr [EMAIL PROTECTED] writes: But another reason why I think it is better to keep the dialogs for transformation is that it is uncommon to have confirmation/cancel buttons in the tool options dialog. I'm not sure, but as much as I'm concerned there is no tool that makes actual changes to the image in the tool options. Mostly, you can define settings/options there (as indicated by the label), but to change the image you have to interactively click into the image. And providing the transformation parameters in the tool options without offering confirm/reset would surely result in numerous errors. Right, the idea is that you have to click into the image to perform the transformation. You don't need an extra dialog for that. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 06:15:15PM +0200, Ellen Reitmayr wrote: Hi Simon, Visually pressing down CTRL or ALT is immediately visible in the tool options: The mode switch will switch accordingly. What else would you suggest to communicate this more clearly? When users are concentrated on drawing a path (and at the same time are exploring different keyboard shortcuts) they will pay few attention to changes in the tool options. Instead, they will give their attention to the image area, here especially to cursor feedback (and hopefully the status line!). The major problem I see here is that when pressing CTRL (Design mode) while the mouse is not located over the path, there is no interaction possible (which is shown by the concerning icon). But there is no hint in the status bar WHY interaction is not possible. I'm not sure about the actual text, but maybe something like 'Move the mouse pointer over the path to edit it'(?) would be helpful and support exploration. i am a long time gimp user. this new path tool confused me when it first arrived into the app, and i had watched the development and the formation of the logic. i also was never much into using gimp with the keys as the point that i started back up with computers, the gimp had buttons for most things. i learned the key changes back then for the few things that absolutely needed them. it took me about two or three times making actual paths (actually using the app, not testing it). the logic is there and i actually grew to like the function. perhaps i am not in as much need of editing the points i place as others, but the simple tool option change makes sense very quickly with actual use. especially when you understand how the gimp used ctrl and alt. you might be surprised yourself if you were to work with gimp on an actual project rather than with usability tests how quickly this will make sense. there is a point in software development where you might need to give it up and give the new logic a try -- especially when the concerns might cause de-evolution in a well thought out plan like simon accomplished here. the points are not a problem, the crappy libart2 backing is a problem. this is the sort of opinion you get from actual use of the program. also, i might add that if you were a piece of software and the gimp developers were testing you for usability, you might be failing them right now. good thing that humans are not software and do not get treated or tested this way, dont you think? ( /me ctrledits this opinion to prove her point) Basically it is impossible to really compare the path tool in 1.2 and the path tool in 2.0. I have rewritten the Path tool from scratch, removing arbitrary limitations and implementing some new ideas. Yes, I know it's completely built from the scratch - and I think it's really very good! I tried the 1.2 path tool, and was not happy with it. Nevertheless, on the first look, four modes seem to be more intuitive than three, as they hide les information from the users. Four buttons, combined with simple keyboard shortcuts for a quick navigation, are very easy to learn. But when I read this mail, I just realised that the tool is way more complex than it seemed to be on the first look, and that simple keyboard shortcuts are not realisable. it is a difficult balance to have full functionality available to professional image manipulation and yet be simple enough for new users. i would like it if there was a way to have everyone with an opinion give as much thought to the logic of the pathtool design as the author. even one tenth of the time thinking through it as simon did. (it would also be nice if simon thought about his opinions as much as he did the path tool, but the path tool parts that he wrote are excellent and the best place to apply logic if you only have so much to spare) Given the prerequisite, that the whole tool should be usable without having to move the mouse back and forth to a buttonbar (jimmac already wrote about this) and the need for a modifier (SHIFT) we have two modifiers left, which lead to the three modes of the existing tool. In theory we could use CTRL+ALT for a fourth mode, but this would require the user of the tool to be quite a finger acrobat and is probably not really a good idea. That's true. I just didn't realise that there is such a lot of functionality. Further below, you said that the path tool is not for newbies, but for people who will use it on a regular basis and willing to invest some effort to study it. I know it's a bit sobering, but studies on help/manual usage showed that only very very few people actually read manuals. That's why an intuitive and easy to learn interaction design is so important! I admit that my suggestions were short-sighted, I just did not know about the whole complexity! but still I think that especially users who are not image manipulation experts need a bit more
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 06:16:47PM +0200, Ellen Reitmayr wrote: Hi, [this is a response to both jimmac and sven] Selection shortcuts: No, I didn't know that there is a difference between the modifiers pressed when you start to create the selection and the modifiers you press while adjusting the selection - it's really very powerful and should not be lost. However, it's hard to learn... As I wrote in response to Simon, studies have shown that only few users actually read the docs - especially if it's about something that seems to be simple, such as selection modes. For such users, it is likely to happen that they will not understand the concept without any hints (just as me and the users I tested 8-)), and we/they should be supported in a way! my friend got photoshop7. the documentation was difficult to find. i was not able to make it work like TheGIMP. the web site did not help nor did the photoshop tutorials i was able to find. my friend also needed me to do all the things gimp-1.0 could do. if you need an application designed for people who do not need documentation, i dont know if TheGIMP is the best application to use or if functionality should be lost for these people. other people spending actual money for less dont get it. is there an example of a software application that is as simple as you are needing that also has this functionality? my gimp-1.2 only cost me about $55 for two excellent books (that were both available freely online -- almost) and was actually able to out perform photoshop from the get go in fullfilling simple users needs. it seems like a comparison in ease of actual fullfilling of users needs is more informative. also, i am very sorry that suse's need for a pretty desktop interfered with gimps functionality. if you actually use this app, the desktop takes second place in the list of importance. suse had fairly limited people involved with actual gimp experience. and even those people failed some ease of use tests, in my opinion. thanks again for taking all of this time to review TheGIMP. once again i am curious about samples personal projects of yours that you used TheGIMP for. having actual ideas and needs for graphics tends to make the gimp make more sense, in my experience. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.1 compilation problem.
Sven Neumann wrote: Hi, Rodrigo Severo [EMAIL PROTECTED] writes: On the other side, I believe gimp should be able to use just the indicated fontconfig installation. I'm setting the following variables on gimp configuration and still can't compile gimp: PKG_CONFIG_PATH=/usr/local/fontconfig-2.2.0/lib/pkgconfig CPPFLAGS=-I/usr/local/fontconfig-2.2.0/include LD_LIBRARY_PATH=/usr/local/fontconfig-2.2.0/lib To resume the situation, I believe that both the Conectiva distribution is wrong (it should have separate packages for fontconfig and xft) and gimp configure/compile process is wrong (it should be enough to set the proper variables and get it compile itself using the indicated library). Could this fix, if really considered proper, be included in gimp ASAP? You didn't suggest a fix for GIMP Yes, I did. As it seems there is some doubt about, let me try to make it clearer: My suggested fix is to make gimp use the indicated (through the proper variables) fontconfig library no matter which other versions I might have installed. Right now I need two different fontconfig versions installed in my system: 1. the outdated packaged one many packages of my distribution rely on AND 2. the updated 2.2.0 one the new pango, gtk+ and gimp need. and actually there is nothing to fix in GIMP We might both agree that there is or there isn't something to fix in Gimp, or we might not agree. That's entirely other point. I sincerely believe that the flexibility of choosing between several different versions of the same library installed at different points is desirable (generaly speaking) and is a common feature the entire GNU compiling sytem (configure, make and all) try to implement. I believe that there is some problem on gimp because apparently the info provided by pkg-config about my chosen fontconfig installation isn't enough to direct gimp to the proper header files. since the problem is entirely on your harddisk. All you need to do is to remove the offending header from the include search patch of the compiler. I can do it, I have done when I compiled gimp 2.0.0. I decided to try to help implement the above mentioned library-version-chosing flexibility. I believe that's usefull. I believe it's reasonabily easy to implement. I might be wrong. I have been before. Thanks again for your attention, Rodrigo Severo -- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Blur plug-in
GSR - FR wrote: Well, what would you call a script that just puts a menu entry and calls convolution matrix with a fixed matrix? The main reason not to use convmatrix is that internally it always does a 5x5 convolution, regardless of the matrix entries. This means it should take almost three times as long as the 3x3 convolution in blur.c; in fact, a little testing on a 5000 x 1 image shows it taking over four times as long. Otherwise using convmatrix would probably be the right solution. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
Hi, thanks again for taking all of this time to review TheGIMP. once again i am curious about samples personal projects of yours that you used TheGIMP for. having actual ideas and needs for graphics tends to make the gimp make more sense, in my experience. Carol, can you please stop this. There is no point in asking Ellen about personal experience with The GIMP. A usability test as it was performed here is about testing how (new) users get along with the software. It can help to identify problems with the user interface that no gimp developer or long-time gimp user will ever be able to see. It also doesn't really matter if the person leading the tests and summarizing the results has any experience with the software being tested. I hope that more such tests can be done in the future. We will certainly try to use the results to improve The GIMP. Since GIMP is a very powerful tool and is supposed to stay one, we will of course take care that no useful feature is dropped only because it might be confusing for someone who uses GIMP for the first time. There will always be a learning curve, but usability tests can help to make it less steep. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Blur plug-in
Hi, GSR - FR [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (2004-06-07 at 1759.17 +0200): calling the convolution matrix plug in and scripts to preset it a simple replacement ? Well, what would you call a script that just puts a menu entry and calls convolution matrix with a fixed matrix? I'd call it a waste of resources. Actually such a simple task as applying a convolution kernel should probably be done completely in the core. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.1 compilation problem.
Hi, Rodrigo Severo [EMAIL PROTECTED] writes: You didn't suggest a fix for GIMP Yes, I did. As it seems there is some doubt about, let me try to make it clearer: My suggested fix is to make gimp use the indicated (through the proper variables) fontconfig library no matter which other versions I might have installed. The GIMP build process already uses the environment variables you were talking about. There is no way to change how the compiler looks for headers, at least not in the GIMP source tree. So you did not point out a fix. If you can come up with a patch, that'd be a different thing. But I doubt that such a patch can be written at all. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 08:20:32PM +0200, Sven Neumann wrote: Hi, thanks again for taking all of this time to review TheGIMP. once again i am curious about samples personal projects of yours that you used TheGIMP for. having actual ideas and needs for graphics tends to make the gimp make more sense, in my experience. Carol, can you please stop this. There is no point in asking Ellen about personal experience with The GIMP. A usability test as it was performed here is about testing how (new) users get along with the software. It can help to identify problems with the user interface that no gimp developer or long-time gimp user will ever be able to see. It also doesn't really matter if the person leading the tests and summarizing the results has any experience with the software being tested. ah, another thing you forget is how attractive i found the linux developers with their rtfm approach and sound logic and their willingness to express this and provide examples in a very direct fashion. so please, did you not have some good ideas for making the texttool better. i read the first three words of each of those sentences and was quite excited to see you make the app work again and not answer questions from a tester with no real purpose for the gimp. i have this memory of a developer who only wasted time with things that made sense and one of the nice things about the gimp is having to learn how graphics and computers work to make it work. there is nothing wrong with an application that is able to do what you are asking it to do. and someone who through things through enough to say rtfm because everything you need is there and well written and not wasting time typing blather to explain how gimp works is more fun. let dave neary answer this, inventing answers is a good thing for a tester with no real goals. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.1 compilation problem.
Sven Neumann wrote: Hi, The GIMP build process already uses the environment variables you were talking about. There is no way to change how the compiler looks for headers, at least not in the GIMP source tree. Ok, I think I'm persuaded. I will keep trying my luck with Conectiva. Tahnks again, Rodrigo Severo -- Rodrigo Severo Fábrica de Idéias Fone: +55(61)321 1357 Fax: +55(61)223 1712 SBS - Quadra 2 - Ed. Empire Center - Sala 1301 Brasília/DF - Brasil CEP: 70.070-904 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 12:09:49PM -0700, Carol Spears wrote: On Mon, Jun 07, 2004 at 08:20:32PM +0200, Sven Neumann wrote: and someone who through things through enough to say rtfm because and someone who thought things through enough to say rtfm because, even carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
Carol Spears wrote: in the united states, there exists a condition where people are being educated for a test. teachers that do not teach the content for the test are removed. For usability tests? I doubt that this is the case, though it might explain the usability of the software produced by a very large company in the US... i think this sort of thing is being introduced to gimp development. i think it is very good to have the testers show what their purposes were before much of the good developers time is taken. especially when you are dealing with such high quality developers and free software. Hm, I think that I'm at least partly able to understand what you're trying to say - if someone want to do something with GIMP, he should ask for advice before he demands GIMP to be changed. Or at least that he should learn and shut up if he is told the correct way afterwards. Good advice for anyone on a mailing list or on irc, but not in a rather controlled usability test. show what you the human being wanted the gimp to do is a very very good question. Hm? Not sure if I understand correctly, but are you thinking of questions like What is the best way to...?. I always wanted to start a wiki page about this - finding the absolutely fastest way to perform a task in GIMP - but couldn't find a real catching name for this page. Any suggestions? HTH, Michael -- The GIMP http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Sodipodi http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] using gimp
i think we won the usability test when we were able to provide someone as well-rounded and decent as roman to help with the tests. this is a volunteer effort. and then they need more? they needed more from suse, who they must have paid. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 09:26:39PM +0200, Michael Schumacher wrote: Carol Spears wrote: in the united states, there exists a condition where people are being educated for a test. teachers that do not teach the content for the test are removed. For usability tests? I doubt that this is the case, though it might explain the usability of the software produced by a very large company in the US... i think this sort of thing is being introduced to gimp development. i think it is very good to have the testers show what their purposes were before much of the good developers time is taken. especially when you are dealing with such high quality developers and free software. Hm, I think that I'm at least partly able to understand what you're trying to say - if someone want to do something with GIMP, he should ask for advice before he demands GIMP to be changed. Or at least that he should learn and shut up if he is told the correct way afterwards. Good advice for anyone on a mailing list or on irc, but not in a rather controlled usability test. no, i really meant what i said. i am actually very nervous about this because i had in real life a roman who failed a test that was made for testing purposes. this was one of the most intelligent, well read and roundly educated human male beings i had ever encountered. too young to date but just one of those kids you wished you had recognized when you were younger, a world changer and one of the right ones to do it. because he failed a test like this in the money world he lost some good cash that he could have used in college and the money was rewarded to a little creep, whose intelligence i also recognized. but without the good heart. then there is gimp, where our roman has volunteered for somethings i cannot support. i want to keep roman and get rid of the stuff that screwed things up for this other roman. if you were to tell me that this roman is being paid for using that crappy docbook set up and spending time with crappy tests i certainly would feel better about these developers spending their time with the test results. roman did really good work within a very bad set up. this is the sort of thing you should be paid for. i am still under the idea that this is free software and i am dealing with volunteers. this is not a test for volunteer work. show what you the human being wanted the gimp to do is a very very good question. Hm? Not sure if I understand correctly, but are you thinking of questions like What is the best way to...?. I always wanted to start a wiki page about this - finding the absolutely fastest way to perform a task in GIMP - but couldn't find a real catching name for this page. Any suggestions? well like find someone who has just started to use linux and the gimp who has a photo they would like to cut the background from. see how long it takes them to do this. you have to actually want to use the gimp for an actual outcome. it is made for production. then you see how well it goes. how easy is it to use i hope we would fail this. how well does it complete actual tasks. we won this with gimp-0.54 i think. long before i started to use it. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, Jun 07, 2004 at 12:49:50PM -0700, Carol Spears wrote: On Mon, Jun 07, 2004 at 09:26:39PM +0200, Michael Schumacher wrote: no, i really meant what i said. i am actually very nervous about this because i had in real life a roman who failed a test that was made for testing purposes. this was one of the most intelligent, well read and roundly educated human male beings i had ever encountered. too young to date but just one of those kids you wished you had recognized when you were younger, a world changer and one of the right ones to do it. because he failed a test like this in the money world he lost some good cash that he could have used in college and the money was rewarded to a little creep, whose intelligence i also recognized. but without the good heart. then there is gimp, where our roman has volunteered for somethings i cannot support. i want to keep roman and get rid of the stuff that screwed things up for this other roman. in the real life situation, i have this way of not wanting minors to drink alcohol. and i really dont. it did not appear to me that the real life roman needed any help or to change the way you do things. this roman IS using things he shouldnt be. tests and software. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blur plug-in
Sven Neumann wrote: I'd like to get some feedback on the following plan for the Blur plug-in (details are in http://bugzilla.gnome.org/show_bug.cgi?id=142318): The plan is to remove the randomize and repeat functionality. [...] So the question is, is anyone actually using this functionality? Are there scripts out there that rely on plug-in-blur-randomize to be available? Is it possible to remove the dialog without removing the options? Also, I skimmed the bug report, which was initially about a preview. Another random thought (based on my previous 'impossible' one: Does it seem possible to make a 'fixed' preview area somewhere (maybe in the layers dialog?) that all plugins have access to, instead of reimplementing each one? Then maybe have this preview area call into the plugin to update itself when the user interacts with it? I realize this may not be a practical thing, but it may be something that someone else could run with ... Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blur plug-in
Sven Neumann wrote: So the question is, is anyone actually using this functionality? Are there scripts out there that rely on plug-in-blur-randomize to be available? Christopher Curtis wrote: Is it possible to remove the dialog without removing the options? Yes, it is possible, that's why Sven asked the question. The options don't have any obvious utility, though (repeat blurring is nothing more than a very slow way of producing a Gaussian blur), so there does not seem to be any good reason for keeping the options unless deleting them will break something that already exists. Also, I skimmed the bug report, which was initially about a preview. Another random thought (based on my previous 'impossible' one: Does it seem possible to make a 'fixed' preview area somewhere (maybe in the layers dialog?) that all plugins have access to, instead of reimplementing each one? Then maybe have this preview area call into the plugin to update itself when the user interacts with it? This could be done with some cleverness, but I would oppose it on the grounds that the preview should be as near as possible to the controls. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
