Re: [Gimp-developer] Re: Re: Bucket fill, Fill with foreground and gradient
Sven Neumann wrote: Hi, this sounds reasonable to me. On the other hand, this would render the bucket fill tool almost useless since you can do the color and pattern fill much easier using DND. The sole advantage of the Bucket Fill tools is the threshold functionality and the fact that the possibility to fill using DND is not obvious. I feel that that last one is a problem. The GUI needs to be consistent. Why not stick to three basic things: tools, filters, and scripts. The tools should all be in the Gimp main window as buttons (or maybe only partially in beginner mode if we do the config/skin thing, sounds good to me btw, ICQ has it too for example), and the filters should be in Image-Filters, scripts would go into Image-Scripts. These should then be subdivided into logical groups, from the user side, not from the programmer side. The user doesn't care if a script was written in Perl or in Scheme, he cares about what it does to his image. The unobvious things can stay, but please, keep them as hidden functionality for power users, not as the only possible way to do it. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
Dear Gimpers
Thanks for such a prompt reply --- when one is lost like the way I am
There is this wonderful mailing list
[What would I have done without internet :-(]
I had posted a question about -- which is the best way to start
gimp. [this was some time back].
I had received no reply then,
anyway this is how I start my gimp script.
[--enable-stack-trace {never|query|always} option is not available
in with gimp 1.1.04]
_
Xvfb :20
DISPLAY=godavari:20
export DISPLAY
gimp --display $DISPLAY --no-interface --version
$pth/gchart $ipdir $gifdir $pattern
_
and this is what the gchart looks like
**
#!/usr/bin/perl -w
use Gimp;
use Gimp::Fu;
use Fcntl;
#Gimp::set_trace(TRACE_ALL);
$Mainpath = /linuxfs/edp/cdhavse/chts;
require /opt/cmie/perl5mod/miscfunc.pl;
require $Mainpath/start;
require $Mainpath/drfunc;
require $Mainpath/charts_lib;
register
(
Gimp_Charts,
Gimp_Charts,
Pie and Bar Charts,
CDhavse,
Copyright 2000,
2000-06-12,
Toolbox/Xtns/Perl-Fu/Tutorial/chart,
*,
[
[PF_STRING, ptsdir, INPUT DIR,/tmpstore/anagram/out],
[PF_STRING, gifdir, OUTPUT DIR,/scratch/cdhavse/gifdir ],
[PF_STRING, pattern, PATTERN OF FILES TO BE PROCESSED,.*]
],
\start
);
exit main();
**
This is the strace -p -s o/p
#
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt, show
[S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt, show
[S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
#
Please suggest any changes that I should make.
There is this another issue about starting multiple sessions
of this script but let us sort out this problem first.
Thanks again
Chetan
On Tue, 5 Jun 2001, Marc Lehmann wrote:
On Tue, Jun 05, 2001 at 01:01:51PM +0530, Chetan Dhavse [EMAIL PROTECTED] wrote:
It happened again --- and here is the trace (strace) during the time when
hmm, this doesn't look like a bug in gimp (not directly, that is).
(2 sec. generated 15000 such lines) and Perl-Server shows 99% of CPU
used in the 'top'
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-..., 101) = 101
read(0, , 4096) = 0
this looks as if the perl-server outputs an error message and then tries
to read from stdin, which is... probably connected to /dev/null or so. How
do you start gimp the server? could you start in interactively (e.g.
inside a screen?) or re-run the strace with the -s switch, so we can
see the full error message (strace clips strings).
It's especially mysterious why it is trying to _read_ from stdin, my guess
is that this is (yet again) the endless-loop-in-libgimp bug.
You can test the latter by starting gimp with --enable-stack-trace never.
if the perl-server then dies immediately instead of sucking cpu time then
this is the problem you hit.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
Hi, David Monniaux [EMAIL PROTECTED] writes: The installation process is frightening: 1. The user is presented with a dialog box Welcome to GIMP that is half full of legalese (NO GUARANTEE etc...). actually our first version had an Accept button at the bottom ;-) The GPL wants you to put a visible notification about the license into your program. This notice should be seen whenever you start Gimp. We only show it on user installation and one day RMS will come and get us for this lazyness. I think the license part should stay and we should add an additional note about the GPL to the About dialog. Perhaps the first installer screen should simply state that Gimp is a painting, touch up etc... program able to read various image formats etc..., and the legalese should be pushed to a second dialog box ? if you think adding a useless advertisement page to the user installation will help, I wouldn't object adding it even though I don't see the point. 2. The current second dialog box shows a full list of files and directories that most users will never care about at first. Maybe we should add an indication that knowing all about this is not necessary to use Gimp? I think it is very nice that we don't quietly install a bunch of dirs and files in the users home directory without telling him. Perhaps we should indeed change the accompaigning words. Patches are welcome. 3. The installer runs a script that copies files and asks the user to spot an error in the execution of the scriptx and investiguate in case there is an error. [even worse in the Windows version] Come on. Users do not know about scripts, and they do not know what an error looks like [*]. The installation process should see by itself if an error has happened, and display a meaningful error message in that case. It's not that easy. Don't think we didn't try it. Again, patches are welcome. 4. Adjustment of parameters Another frightening dialog box. We should really convey the idea that the default settings are OK, and that those settings can be changed at any time afterwards (otherwise the users may spend time pondering what to say here). It is indeed possible to change this later, but we moved it into the user installation since experience shows that these values will never be adjusted later. Setting the tile cache correctly is viable for a good user experience so I expect the user to spend some time here pondering what values to choose. a) The default tile cache size should be adjusted with respect to the installed RAM size. This should fulfill the need of most users (PCs with one console user). In the case of multi-user systems, the system administrator should be able to set other default values (maybe depending on the machine). Yeah, we had that discussion before quite often and everyone agreed that it should be as you say here, but until today noone found it important enough to change the code. Many people just leave the default of 32M, open a big image and claim that Gimp is s much slower than PhotoShop. If those people knew better, they'd heard their hard drive churning and understand that Gimp is swapping, but this should not be expected from most users - how do you think that computer resellers sold boxes with fast CPUs and only 32M of RAM ? That's exactly why we've put the tile cache size setting into the user installation process. Furthermore, we should add the precision that the value there should not be the total amount of RAM in the machine, but the size of the portion of that full RAM that should be used for Gimp images. Here's what is written: GIMP uses a limited amount of memory to store image data, the so-called Tile Cache. You should adjust its size to fit into memory. Consider the amount of memory used by other running processes. Well, not the best description propably. Please send a patch for a better one. b) The setting of the swap file in .gimp-x.y/tmp is a problem on NFS-mounted accounts (universities, for instance). Why not /tmp by default? Since /tmp is not always a good choice, it might even not exist?! For that reason we say: All image and undo data which doesn't fit into the Tile Cache will be written to a swap file. This file should be located on a local filesystem with enough free space (several hundred MB). On a UNIX system, you may want to use the system-wide temp-dir (/tmp or /var/tmp). Don't you think this is enough to help the user make a good decision? Now for the main UI. We should have a way to remind people to use the RIGHT BUTTON on the image. I bet many people think Gimp is some kind of small MS Paint-like program because they have never been able to reach the filters. Yes, I know this is the second tip, but... Overall I don't like the idea of treating the user like an
[Gimp-developer] Re: bug using gimp with a wacom stylus
Stefan Seefeld wrote: hi there, I'm trying to use the gimp with a wacom intuos tablet. The 'input devices' dialog correctly reports cursor, stylus, and eraser. But when attemping to use the stylus to draw, the program aborts with bash$ gimp GLib-ERROR **: could not allocate -21504 bytes aborting... gimp terminated: Aborted Any ideas what is going wrong ? I compiled and installed new versions of glib, gtk, and gimp this morning, i.e. glib and gtk versions 1.2.9, and gimp 1.2.1. Regards, Stefan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer Has GIMP 1.2.x been officially released for GTK+ 1.2.9 ? XInput (IMHO) has always been a tricky part of the GTK 1.x.x series; you're likely on virgin territory here, because I'm not aware of a lot of testing between GIMP and whatever changes has occured in GTK XInput code. I'd appreciate a bug report (pretty please?) http://bugzilla.gnome.org/enter_bug.cgi and click on 'GIMP' Thanks! Be good, be well Garry ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
Hi, On Wed, Jun 06, 2001 at 12:48:28PM +0200, Sven Neumann wrote: 2. The current second dialog box shows a full list of files and directories that most users will never care about at first. Maybe we should add an indication that knowing all about this is not necessary to use Gimp? I think it is very nice that we don't quietly install a bunch of dirs and files in the users home directory without telling him. Perhaps we should indeed change the accompaigning words. Patches are welcome. What about writing script output to ~/.gimp-x.y/install.log and telling the user that it can be found there? Like: Some files have been copied to ~/.gimp-x.y/. Have a look at ~/.gimp-x.y/install.log if you're curious. Usually, this is not important. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI Stuff
On 5 Jun 2001, at 15:43, Chris Brown wrote: [how to improve the GIMP LookFeel] My second suggestion is more technical, finding a way (and forgive me if there already is) to allow Gimp to have skins or something like that so that if someone wants it to *look* like Photoshop, they can. I defenately feel that some customizability is a key to a good UI. With the default being something that people are familiar with. I would just like to note that there seems to be the idea that improving the looks of a UI automatically improves the UI (you use even stronger language, you call it the key to a good UI). I think this is a fallacy, although I would be hard pressed to find literature to back me up. However, if you think it true, you will soon realize that the functionality of a UI plays a part too. Looks belong to the part of interface design (AFAIK) that have to do with the user experience. Users may think that a certain skin is cooler, but will it actually help them to perform their tasks better? This is a complex area, which is (one reasion) why UIs get user tested before release. I do not think any of us have the resources to test the way users interact with the GIMP, although I would love to do such a study one day. (Hey, maybe we can ask a school or university to do such a study for us! Are there people here who think that that is a good idea?) Only seeing what users do and how users use a tool will help you understand the consequences of your choices in presenting a UI. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI Stuff
On 5 Jun 2001, at 23:08, Sven Neumann wrote: To many people, it won't matter whether it's free, or whether it supports the same features of a commercial product from Adobe that is far more polished. Well, those people should stay with their commercial products then. This is free software. We don't care about market share. We want to have fun developing our software and of course we want it to be as good as possible. I have heard this argument before, and I do not entirely agree with it. Yes, one part of developing free software is scratching that itch. But after that, some of us want recognition too. I know I do. And market share is a pretty good form of recognition. If the GIMP were only used by its developers, we would not see nice e-mails coming from CNN thanking us. Also, if anything, market share can be an indication (one of the many) that we are on the right track. Unfortunately, just having a good product does not guarantee a good market share. If the market were completely free that would be the case, but unfortunately it is not. People who have to decide what tool to use, have a limited time to make that decision. The GIMP first has to grab the attention of possible users. Then, it has to make clear that it is the best tool for the job. I think that, unfortunately, the question users will ask themselves for instance is 'does it look and function like Photoshop?' If the answer is no, they will move on. For me personally, the price (free), is definitely an option. Heck, I even would pay Tor some money if he put more work into releasing stabler Windows versions, and releasing them more often. However, most people copy their software. I do not know one single person who paid for their Photoshop. So the end of the story is that, given the choice between a tool that is widely (if sometimes erroneously) regarded as the best in the field and the GIMP, people will choose the former. The upshot of this all is (I feel): better marketing. The choices we made in the LookFeel (and the rest of the UI) are ours. Can we sell them? Can we tell people Yes, other tools do it that way, but we do it our way and here's why? Is there a document that outlines our philosophy and where we want to go, and does that not just to programmers, but to the average user (who is not interested in a separation of UI and program, just in what it means to her or him) as well? Ah well, this is all IMNSHO, of course. :-' -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: UI Stuff
On 5 Jun 2001, at 23:35, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2001-06-05 at 1543.38 -0500): increase their market share they need to fix the UI, and make it Market share? Heeey, guys, how much money are you earning with Gimp? My hourly rate for making web pages is 45 Euro. I use the GIMP extensively for that work. Having a good graphics editing tool will increase my productivity and, because of that, will mean I can charge less for an end-product (web site or web page) without lowering my rates. I do earn money with the GIMP, yes. If it weren't for the GIMP, I would have to fork out money for PSP. I may still have to do that because, to be honest, that tool has got some options that are very handy for me as a web builder as well (way better vector tools, export wizards for PNG, GIF and JPEG, etc.). -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] smp
Is gimp optimized for use on SMP systems? I would like to build a linux dual box . sincerely, R.Cox
Re: [Gimp-developer] Perl server problem
On Wed, 06 Jun 2001, Chetan Dhavse wrote:
[...]
[--enable-stack-trace {never|query|always} option is not available in
with gimp 1.1.04]
[...]
This is the strace -p -s o/p
#
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt,
show [S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt,
show [S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
#
Please suggest any changes that I should make.
This shows that you are affected by the old bug related to the stack
trace: the process is stuck in an infinite loop trying to ask you if
you want a stack trace or not, but its input is not connected to
anything so it loops forever. This is why the --enable-stack-trace
option was introduced in the more recent versions of the Gimp. The
old version that you are using (1.1.4) did not have that option so it
will be very hard for you to know exactly what is wrong.
You have two options now:
- Upgrade to 1.2.1 (or to the current CVS version in the gimp_1_2
branch). This is the best solution because if you find any bugs in
that version, they can be fixed for everybody.
- If you really cannot upgrade to 1.2.x for some reason, then you
should at least recompile your old version and modify the part of
the code that asks if a stack trace should be produced. But it is
likely that the crash (generating the stack trace) is caused by a
bug that has been fixed since then. So even if you manage to find
where your script crashes, you will probably find that you have to
upgrade to a newer version in order to get rid of the bug that is
causing the crash.
-Raphael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bucket fill, Fill with foreground and gradient
Hi, Branko Collin [EMAIL PROTECTED] writes: The Magic Wand is not the only way to make a selection. I agree it sounds logical that one would want to stroke or fill a wand selection completely, but I can think of uses for a threshold fill with a rectangular or elliptical selection. you can intersect a magic wand selection with an existing selection by pressing Ctrl-Shift. BTW, I checked out how my GIMP (Win32) deals with changing the content of dialogs: when having two image windows open plus the layers dialog (Layers, Channels Paths), and then switch between image windows, the contents of the latter does not change until I click in the new image window. Would it be possible to make it so that the contents of such dialogs change when you only activate the new image window? Or is this just a Windows GTK+ thing? The active image is only switched if you perform an action in the image. Pressing Space counts as an action here. This behaviour is intentional and was discussed here before. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, Robert Cox [EMAIL PROTECTED] writes: Is gimp optimized for use on SMP systems? it could make more use of multiple processors, but yes, you gain a speed improvement if using more than one processor. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, David Monniaux [EMAIL PROTECTED] writes: On 6 Jun 2001, Sven Neumann wrote: it could make more use of multiple processors, but yes, you gain a speed improvement if using more than one processor. Does it actually work? AFAIK, yes. You specify --with-mp=yes when running configure and configure the number of processors in the prefs. Of course multiple processors are also automatically used since plug-ins are separate processes and can though be run on different CPUs. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
On Fri, Jun 08, 2001 at 07:19:46PM -0400, Robert Cox wrote: Is gimp optimized for use on SMP systems? I would like to build a linux dual box . no, but plug ins are run as seperate processes. plug ins themselves can take advantage of that but the app itself does not. sincerely, R.Cox ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, furnace [EMAIL PROTECTED] writes: On Fri, Jun 08, 2001 at 07:19:46PM -0400, Robert Cox wrote: Is gimp optimized for use on SMP systems? I would like to build a linux dual box . no, but plug ins are run as seperate processes. plug ins themselves can take advantage of that but the app itself does not. Not quite correct. If gimp is configured using --with-mp=yes and the number of CPUs is configured correctly in the prefs some core functions run parallel too. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: UI Stuff
[EMAIL PROTECTED] (2001-06-06 at 1424.04 +0200): increase their market share they need to fix the UI, and make it Market share? Heeey, guys, how much money are you earning with Gimp? rates. I do earn money with the GIMP, yes. If it weren't for the I am speaking about the people that make the app, not the people that use the app, they are different. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.2.1 crashes on indexed colour conversion
Hi All, As ever I;m not quite sure where I go to post bug reports, so I;m posting to the list. Colour conversion of the xcf file at http://avi.mediamatic.nl/misc/conversion.html brings downs 1.2.1 everytime I attempt it ;-) I'm trying to go from 24bit to 32 colours. if I resize the image from 2500x3500 to 2000x2800 it does work. ttfn, avi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2.1 crashes on indexed colour conversion
Hi, Avi Bercovich [EMAIL PROTECTED] writes: As ever I;m not quite sure where I go to post bug reports, so I;m posting to the list. http://bugzilla.gnome.org/ is the right place. Your bug-report has been entered into the database and I have forwarded your mail to Adam asking him to have a look. Argh, I knew the heavy usage of g_assert() in the convert code would bite us some day. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2.1 crashes on indexed colour conversion
On Wed, Jun 06, 2001 at 07:37:23PM +0200, Sven Neumann wrote: Argh, I knew the heavy usage of g_assert() in the convert code would bite us some day. But assuming the assertions aren't invalid we have found a bug that would otherwise be very hard to find? IIRC People who don't care why their applications crash can turn off assertions, though presumably only at compile time. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
Hi, Branko Collin [EMAIL PROTECTED] writes: After scrolling. And not on the page where you would expect it, on the download page. Surely, you do not expect a visitor to read the whole web site before downloading the software? please move this discussion about the webpage to the gimp-web mailing list. I did the first, but not the second. However, when you told me to write to [EMAIL PROTECTED], the web mailing list was not up yet, so who was I writing to? Probably to the tarball of ~200 unanswered [EMAIL PROTECTED] mails that was handed over to Carol?! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2.1 crashes on indexed colour conversion
Nick Lamb wrote: On Wed, Jun 06, 2001 at 07:37:23PM +0200, Sven Neumann wrote: Argh, I knew the heavy usage of g_assert() in the convert code would bite us some day. But assuming the assertions aren't invalid we have found a bug that would otherwise be very hard to find? Yes, the assertions caught a real bug (indeed for what other reason would they be there?). However, the bug has been long-dead in my current tree (but possibly replaced with others, of course)! --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 i l1x0r u! 5luRp!Gronda, gronda ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI Stuff
At 10:24 06.06.01 +0200, David Monniaux wrote: On 5 Jun 2001, Sven Neumann wrote: He's speaking of the Win32 version here which of course looks and feels different than the usual win32 application. This feeling will change as Let's add that the UI in the Win32 version is *BUGGY* (my mom runs it and there are some ugly glitches - and I'm not talking of the screwed-up support for tablets). So we should not take as inadequate UI what is actually bugs, pure and simple. We should be very careful with the Win32 version since it may easily convey the wrong impression that Gimp, and free software in general, is buggy. What do you suggest? Stopping the distribution of gtk/win32 apps ?? Yeah, the UI is a little buggy and it would be nice if there would have been the possibility/manpower to do some more polishing to get a better working Gtk+-1.4 version (Gtk/win32 production is based on Gtk-1.3 from March 2000), but IMHO it was dropped to get the world leading Gnome 2.0 desktop, which would render all win32 stuff useless anyway :-) Until that happens I'll continue to try my best to keep Gtk working even on win32. IMHO the (bad) looks and feels reported from win32 users are mostly not related to 'glitches' introduced by the port, but cross platform issues like context menus nested up to a fourth level or a rather visually un-appealing file io dialog, at least if it is not compared to the old Motif dialogs, but decent ones ... And as a reply to your next mail: If I would want my mom use The Gimp, I would have run the installation for her, so all the optimizations for the one time used appears rather wasted to me. Hans Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI Stuff
At 23:08 05.06.01 +0200, Sven Neumann wrote: Chris Brown [EMAIL PROTECTED] writes: [..., removed becuase I totally agree to the points Sven made] My second suggestion is more technical, finding a way (and forgive me if there already is) to allow Gimp to have skins or something like that so that if someone wants it to *look* like Photoshop, they can. I defenately feel that some customizability is a key to a good UI. With the default being something that people are familiar with. GTK+ supported skins (or themes) long before the Windows world had heard about this terms. If I'm informed correctly, GTK+ themes do even work on Win32. AFAIK the win32 Gtk theme support has silently vanished, because there was no one to put in the extra efford to keep it working. Additionaly I seriously doubt that it would be possible to make The Gimp look more potato shop like by simply giving it another 'skin'. And: last time I looked at the PS port to win32 it doesn't behave like a native win32 app, but like one which is used to run on an old single task os ... Hans Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUI comment from an NT user
Can GIMP be started with all the windows grouped the way I want? All the talk about user interfaces made me think about what annoys me most. using the desktop analogy, normal Windows applications look like an organized desktop and Gimp/Apple style applications look like a messy desktop. I do not like spending my time rearranging the desktop when a computer can do that for me. I do not like clicking on the edge of a window, to resize it, and end up clicking through to the application in the window underneath. I normally run with the tool bar down the side of the screen and it some times runs in to two columns (that means more than 40 applications) despite many of the applications, like Opera, running multiple windows within the one NT window. If I replace one instance of PaintShopPro, with perhaps eight images open, with Gimp, I end up with one tool bar item expanding to 12. I run every application full screen and most of the applications open with the screen the way I left it last time. Some applications let me save a layout and set that as the one I will get every time I open the application, no matter how messy it was when I left it. I would like a way to open Gimp so it is equivalent to a Windows full screen application with each tool bar docked. That would mean having one big window containing the image and the other windows as subsets of the main window, placed down the left of a vertical image and across the bottom of a horizontal image. That way, when I am in GIMP, the whole screen is working the Gimp way, and when I am in Word, the whole screen is working the Word way. Last time I used Gimp and tried to resize a window, I ended up in the Word document (which was underneath Gimp) and had to undo a text move, as the mouse movement had translated to moving text. If I could fill the screen with Gimp, I would not care if the application had a slightly different approach to other applications, as I would not be mixing the two on the same screen. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: 1.2.1 crashes on indexed colour conversion
Raphael Quinet wrote: I have just entered your bug report in Bugzilla as bug #55830. You can look at it from here: http://bugzilla.gnome.org/show_bug.cgi?id=55830 Colour conversion of the xcf file at http://avi.mediamatic.nl/misc/conversion.html brings downs 1.2.1 everytime I attempt it ;-) I'm trying to go from 24bit to 32 colours. if I resize the image from 2500x3500 to 2000x2800 it does work. This confirms an earlier bug report. See http://bugzilla.gnome.org/show_bug.cgi?id=52264 Be good, be well Garry ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] adding a tool
Hi, I'm interested in adding a tool for detecting and cutting out contour regions. Is this feasible? Has this already been done? Is there a doc explaining how to contribute to Gimp development? Thanks, Jonas ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
Hi, David Monniaux [EMAIL PROTECTED] writes: I think of coding something for paper sizes. That's what I propose: - a set of predefined paper sizes (ISO and US) - user-definable sizes - the default paper size is set according to the locale (country) where the user is. Any comments? How to do this cleanly? AFAIK there is libpaperg which does just that. Someone should evaluate if it would be useful for The GIMP and integrate it if it is. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
On Wed, 06 Jun 2001, Sven Neumann wrote: David Monniaux [EMAIL PROTECTED] writes: The installation process is frightening: 1. The user is presented with a dialog box Welcome to GIMP that is half full of legalese (NO GUARANTEE etc...). actually our first version had an Accept button at the bottom ;-) The GPL wants you to put a visible notification about the license into your program. This notice should be seen whenever you start Gimp. We only show it on user installation and one day RMS will come and get us for this lazyness. Well, I doubt that RMS would blame us for that. The notice must not be displayed every time the program is started, as long as it can be accessed easily using some command-line option or dialog box that is commonly used to display some information about the program (such as --help, --version or some About dialog for graphical programs such as the Gimp). I think the license part should stay and we should add an additional note about the GPL to the About dialog. Yes, adding a notice about the GPL in the About dialog is a very good idea and would satisfy the requirements of the GPL. However, the part about the license in the first installation window could be softened a bit, as David suggests. There must be at least a pointer to the GPL and the usual wording about use at your own risks, but this could come after a user-friendly text that explains in a few words that the Gimp is free software. I have no precise ideas about how this could look like; suggestions are welcome... [...other good replies snipped...] 4. Adjustment of parameters Another frightening dialog box. We should really convey the idea that the default settings are OK, and that those settings can be changed at any time afterwards (otherwise the users may spend time pondering what to say here). It is indeed possible to change this later, but we moved it into the user installation since experience shows that these values will never be adjusted later. Setting the tile cache correctly is viable for a good user experience so I expect the user to spend some time here pondering what values to choose. I agree. However, the reports in various newsgroups and mailing lists show that many Linux and Windows users did not pay enough attention to these settings, maybe because they did not fully understand the consequences. Or maybe because they wanted to try the program quickly and they pressed OK or Next on all installation windows, assuming that the defaults are fine and that only the experts need to change them. a) The default tile cache size should be adjusted with respect to the installed RAM size. This should fulfill the need of most users (PCs with one console user). In the case of multi-user systems, the system administrator should be able to set other default values (maybe depending on the machine). Yeah, we had that discussion before quite often and everyone agreed that it should be as you say here, but until today noone found it important enough to change the code. Here is a suggestion. I doubt that I will implement it, but maybe David can do it since he wants to improve the installation process. Keep the current dialog as it is (telling the user to adjust the value as needed), but try to change the default value of 32M on the systems in which the available memory is easy to guess. This means that the users of other systems will still have to change the tile cache size from the default of 32M, but at least those who are using one of the common configurations (e.g., Linux 2.2 or 2.4 on a single-user machine) will get a more sensible value by default. The default value could be computed like this: if /proc/meminfo exists, then open it, read the MemTotal value, substract 42M and round to the nearest multiple of 16M to have a nice number. Use the result as the default tile cache size, with a minimum of 32M. If there is no /proc/meminfo, then use 32M as before. A similar thing could probably be done for Windows, although I do not know much about that. [...] b) The setting of the swap file in .gimp-x.y/tmp is a problem on NFS-mounted accounts (universities, for instance). Why not /tmp by default? Since /tmp is not always a good choice, it might even not exist?! For that reason we say: All image and undo data which doesn't fit into the Tile Cache will be written to a swap file. This file should be located on a local filesystem with enough free space (several hundred MB). On a UNIX system, you may want to use the system-wide temp-dir (/tmp or /var/tmp). Don't you think this is enough to help the user make a good decision? Using the same point of view as above, we could try to provide a better default value if possible. The user will still have to pay attention to this value and change it in order to get the best results, but we could provide more sensible defaults. Making a good guess will probably be a bit tricky. I
Re: [Gimp-developer] UI remarks
Hi, Branko Collin [EMAIL PROTECTED] writes: A web master who knows www.gimp.org inside and out may think that 'where is the Windows version?' is neither here nor there, sinds www.gimp.org is not the distribution point for the Windows version. www.gimp.org mentions the win32 version on the front page. Getting back to updating the web site: Sven, I wrote to the [EMAIL PROTECTED], to offer them my services in updating the current site, but I never got a reply. Could you tell me more specifically whom I should talk to? Thanks in advance. subscribe to the gimp-web mailing list as described at https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-web and offer your help there. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: UI remarks
[EMAIL PROTECTED] (2001-06-06 at 1724.41 +0200): The GPL wants you to put a visible notification about the license into your program. This notice should be seen whenever you start Gimp. We only show it on user installation and one day RMS will come and get us for this lazyness. Well, I doubt that RMS would blame us for that. The notice must not be displayed every time the program is started, as long as it can be accessed easily using some command-line option or dialog box that is commonly used to display some information about the program (such as --help, --version or some About dialog for graphical programs such as the Gimp). Have anybody, in last months, tried any commercial app? Seessh, I have to click Accept even to get some damn docs. Or to get new drivers for a card that I own, and I still have to see the damn license again and again. The point is to show, IMHO, that Gimp is not public domain, it has a license like anyone, and it is serious about that. consequences. Or maybe because they wanted to try the program quickly and they pressed OK or Next on all installation windows, assuming that the defaults are fine and that only the experts need to change them. Most people just hit Next like a mad monkey. In some cases, they are right, cos the config tool does nothing. In others, it allows interesting things, like in Gimp case (cache, monitor resolution). BTW, maybe a guided tutorial would be fine, that way people learn to change things once they have the app installed. With the click Next mania, I guess that could be the default way, no entry dialog, only the tuts. Here is a suggestion. I doubt that I will implement it, but maybe David can do it since he wants to improve the installation process. Keep the current dialog as it is (telling the user to adjust the value as needed), but try to change the default value of 32M on the systems in which the available memory is easy to guess. This means that the users of other systems will still have to change the tile cache size from the default of 32M, but at least those who are using one of the common configurations (e.g., Linux 2.2 or 2.4 on a single-user machine) will get a more sensible value by default. There is not sensible size. Start some apps, and Gimp suffer, close those apps, and Gimp is not using all RAM. Users could try to guess how much RAM free they have when they work with Gimp. IIRC in MacOS users have to decide how RAM was shared (old MacOS, not last version). Calc default, OK, but make sure the user knows it could be really wrong. /tmp. I think that the only way to check that automatically is to run df and parse its output. This is not very elegant, but I cannot think of a better solution. In some cases, IIRC, /tmp is RAM. Here is how it could be done: run df $TMPDIR, df /tmp and df $HOME. Ignore the result if df fails or if the second line of the output does not start with /dev/ (which indicates that the directory is mounted from another host). If there is anything left, then use the directory that has the largest value in the available column. If there is nothing left, then use the old default value. The user will still be able to edit it anyway. df? It will vary if the user have installed today, or has been using the machine a lot and is just about to do a clean up. Also, size is not the only important thing, speed too (think two disks, not local and remote). But oooh, well, seeing how default installs work, and how others do partitions, I understand why some people get doggy slow systems (do you placed swap where?), and other snappy ones. Somebody said disk layout was an art, and it is true, at least until computer become really smart. The dialog should point that non obvious details: use a place where you can get more free space if you want, and in a disk that is fast. And where to change them. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
