Re: Performance
On Thu, 03 Feb 2000, Kelly Lynn Martin [EMAIL PROTECTED] wrote: On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said: If you have a shared maschine the best would be to let the administrator choose how much memory each user will get because users'll ALWAYS try to get what they can even if it makes no sense It might be a good idea to have a compile-time configuration option for maximum cache size, I disagree. This would only encourage some users to re-compile their own version of the Gimp in a private directory in order to get around the hardcoded limits. Being a system administrator myself, I believe that an admin should always suggest some limits (and maybe use some social engineering to encourage users to respect these limits) but should avoid hard limits. Because most users do not like hard limits and they start wasting their time and the admins' time trying to work around them. and it might also be a good idea for gimp to check its ulimits and adjust its cache size so as to avoid running over its data segment limit or maximum resident set size. Some admins use these as a way to prevent resource hogging. That would be a good idea, indeed. If the limit on memory is rather low but there is still some room left on the disk, then it would be good to lower the tile-cache-size. This would ensure that the Gimp would not die prematurely because of malloc problems when it could have swapped some tiles to disk. On the other hand, if ulimits are used to limit the maximum file size or CPU usage, there is not much that we could do about it. Same if disk quotas are activated. The Gimp can have some control over its memory usage, but many parts of the code assume that the disk space is unlimited (or is not the main constraint). -Raphael
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On Fri, 4 Feb 2000 (late at night), Marc Lehmann [EMAIL PROTECTED] wrote On Fri, Feb 04, 2000 at 12:48:50AM +0100, [EMAIL PROTECTED] wrote: Since the menus were reorganized I am constantly guessing wether "Repeat Last" will repeat my last action, the one before or not work at all, since you can't tell from the menu anymore. Huh? Sounds strange, could you provide a snapshot in a private EMail? I can't image what this should look like "Repeat Last" will repeat the last plug-in. Since menus do not provide a feedback of wether an entry is a plug-in or "built-in" (I think it would even be wrong to do so), you have to know this, which is not easy for beginners. I agree with you, Mark. Knowing the difference between tools and plug-ins is rather important, but is not easy for the beginner who has several dialogs open and is not familiar with all of them. If the user does not know what belongs to a tool and what belongs to a plug-in, then some actions such as "Undo", "Repeat Last" or "Re-Show Last" become unpredictable. There is also an issue with scripts (e.g. Script-Fu) but hopefully this will be resolved soon. Hmmm... this reminds me that I still have to contribute some code there... I am quite sure it improves usabiloty for me a lot. Well, I could provide you a patch which reverts it when you compile it with CFLAGS="$CFLAGS -DIMPROVE_USABILITY_FOR_MARC" :) Please note that I am not alone with that opinion... Yup! I definitely prefer redundancy if it improves the usability. In this case, making sure that all tools contain "Tool" in their title (e.g. "Pencil Tool") would avoid some confusion. Even if this sounds a bit ridiculous. -Raphael
Re: Performance
On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said: I disagree. This would only encourage some users to re-compile their own version of the Gimp in a private directory in order to get around the hardcoded limits. Frankly, I disagree. Systems where admins are likely to impose such restrictions are going to be ones where users don't have enough space to compile private copies of Gimp. Being a system administrator myself, I believe that an admin should always suggest some limits (and maybe use some social engineering to encourage users to respect these limits) but should avoid hard limits. It depends on the kind of users you have and the hardware you're running. Imposing hard limits is sometimes the only way to deal with certain types of users. On the other hand, if ulimits are used to limit the maximum file size or CPU usage, there is not much that we could do about it. Same if disk quotas are activated. The Gimp can have some control over its memory usage, but many parts of the code assume that the disk space is unlimited (or is not the main constraint). Yup. It might be nice to catch SIGXCPU and try to do an orderly shutdown before the SIGKILL does ya' in, though. :) Kelly
Documenting libgimp
Hi,
ok, I've added the necessary framework, so we can start to work on the
documentation. If you have any problems with configure/Makefiles, please
mail me.
If you check the source out of CVS, you will find a new directory named
devel-docs. There's a README, _read it_ !! You will need gtk-doc and a bunch
of SGML utilities if you want to work on the documentation.
Unless a new function (or a new file) is added to the source, there should
be no need to redo the two first steps ("make scan" and "make templates").
So you can start directly by creating the SGML files (make sgml) and
converting them to HTML (make html).
Changes to the documentation are performed by adding comment blocks to the
source (see libgimp/gimpcolorbutton.c, which I documented as an example) and
editing the sgml templates in the tmpl dir (see tmpl/gimpcolorbutton.sgml).
After changing something you'll have to redo 'make sgml' and 'make html'.
Have fun!
Salut, Sven
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On Fri, 4 Feb 2000, Steinar H. Gunderson wrote: I'm constantly finding myself looking for tools. I know that they are there, but I have to stop and look closer at almost every single tool. There are simply too many tools (some of them could well be combined), and the icons look very much the same (believe it or not). I don't know if colour would solve this (or just add clutter), but we should really get to reduce the number of tools, as a previous poster suggested. Now, where are the users? :) Hi. I am a user, I keep my gimp fairly fresh, and I use the gimp fairly often. I agree that there might be more tools on the toolbox than are used in a toolbox-ly manner. I use a handful of operations, and I use them often. Tear-off menus have been a lifesaver for me. I don't know that I agree on the issue of clutter - I like being able to find most things fairly quickly. Some of the buttons are a little ambiguous, but not so much that I would suggest a major UI overhaul. I wonder if you're talking maybe more about learning curve than usability? The gimp, on my desktop, excels at usability - but I have a desktop set to 1600x1200 with all four sides covered in tear-offs. :) -- Blue Lang Unix Systems Admin QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604 Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
Edit Fille behaviour change?
I just noticed this new CVS entry: Fri Feb 4 18:27:16 CET 2000 Stanislav Brabec [EMAIL PROTECTED] * app/global_edit.c: edit_fill with foreground, not background. Checked the code. Looks like 'Fill' now uses the foreground. So I recompiled the GIMP. Indeed, the changes do what it says. Fill (by default Ctrl-.) has filled using the background colour in the GIMP for as long as I can remember. I don't think it's a bug, and making this change will suddenly render all of the GIMP books completely obsolete! Ok, so GIMP 1.2 will make the books obsolete anyways... but changing such a basic core UI thing seems like a bad idea to me. DrBronner Revert, revert, ok! /DrBronner Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"I seem to be having tremendous difficulty with my life-style."
Re: Edit Fille behaviour change?
Fill (by default Ctrl-.) has filled using the background colour in the GIMP for as long as I can remember. I don't think it's a bug [snip] I agree. I have grown very accustomed to the existing behavior, and I don't think it should be changed. I know it hasn't been customary in the past, but I think such a user-visible change should be discussed a little bit. What does Photoshop do? Federico
Re: Edit Fille behaviour change?
Tom Rathborne wrote: I just noticed this new CVS entry: Fri Feb 4 18:27:16 CET 2000 Stanislav Brabec [EMAIL PROTECTED] * app/global_edit.c: edit_fill with foreground, not background. snipped... I don't think it's a bug, and making this change will suddenly render all of the GIMP books completely obsolete! Ok, so GIMP 1.2 will make the books obsolete anyways... but changing such a basic core UI thing seems like a bad idea to me. DrBronner Revert, revert, ok! /DrBronner Indeed, some of the 1.2 - revised books are well into pre-press and some are out in the market. These books suffer too. From "Gimp - Essential Reference (Covers GIMP 1.2, GTK 1.2 and Script-Fu" by Alex Harford, published by New Riders (Page 32): "Clear and Fill are simple tools for working with selections and entire layers... discussion of Clear omitted ... The Fill ([Ctrl+.]) operation adds paint to the current selection. The selection is always the *background* color even if there are layers or an Alpha channel. emphasis mine Fill is therefore useless when working with a flat image without an Alpha channel because it has the same effect as Clear..." So in a small way, a GIMP reference has been rendered less accurate. The issue of whether or not this change is more sensible is not the point; the point is that the User Interface is special ground; there is a lot of external dependency on long-standing behaviour remaining constant. One should not change it without first posting some kind of proposal here - especially in this feature-freeze period where many people are working hard to get documentation synchronized with the Gimp. My two U.S. cents. Garry Osgood
Re: Edit Fille behaviour change?
Kelly Lynn Martin said... | |What does Photoshop do? | |What does that matter? We've changed the GUI to match PhotoShop more than once. Sometimes it was a good idea, but not always. I don't really care what PhotoShop does; I think this change, even though it seems logical to me, is about 1 year too late in the life cycle fo the GIMP, between the user base and the books. And the way it works now is reasonable. -Miles
