Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Zach, I know you're trying to make a point, but I'd actually agree with that assessment too, if for slightly different reasons. The user has no way of knowing what shade of gray they are about to place on the image. I don't think this is used anywhere near as commonly as layers/transparency, so isn't perceived as such a big problem. But it should get some attention as well. In this case, changing the toolbar when that image is active is a possibility, if grayscale editing is still a goal. Also, the color selectors would have to change depending on the mode, so you're introducing the same problem in a different spot. I think what it comes down to is that modes increase the load on the user of the tool. If they have to exist, there should always be a clear indicator of the current mode. Where possible, I'd like to see them go away. Seth If that is the case, I have noticed another flaw. When I am working in the grayscale image mode, and I use the paintbrush to try and draw a color on the image, it comes out in gray!! This is clearly wrong behavior. You would not expect a tool to have two different modes of operation depending on the image you are drawing on! Obviously, all images should be color. Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] introduction + localisation questions
Hi there, I am new to this list. I am going to work on an extended and hopefully also improved version of the Dutch translation of the Gimp. At the moment I am a professional HTML coder, who tries to write articles for computer magazines on the side (until last year I was editor of the Dutch version of the famous c't magazine). If you want to know more about me, check out my horribly out-dated home page at http://www.xs4all.nl/~collin/. I have got a couple of questions for this list: 1. Is there a way to search the archive without downloading all? (I am using a slow modem connection to log on.) 2. Do you use language tags as described in RFC 3066 to identify the localisation files? (Hm, why am I suddenly thinking of The Gimp in Klingon?) 3. If the answer to question 2 is 'yes', then: does any of you know what the official country code for the Netherlands is? My guess would be 'NL', but I would like to be sure. 4. Where could I have found the answer to question 2? Many thanks in advance for your help. I look forward to a good cooperation. Kind regards, -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: RFC: eliminating tool destruction and addingbetter caching support
On 23 Feb 2001, Michael Natterer wrote: That lessens but does not solve the problem that the code is more complicated because of the destruction of tools due to state changes. I'm quite a bit biassed about wether we should destroy tools after use or not, but IMHO a tool should simply be able to handle both. Of course it has to handle it's destruction :) and being able to change displays will enable features we may not think of currently. Also, there would be no need to decide now if we want to destroy the tools or not. Good point. It doesn't really matter from the object's point of view when it gets destroyed. But the tools should be able to handle changes of display. And of course, we need to deal with the case where there is no display more cleanly than the hacks that are in now. IMO the GimpToolInfo object Mitch just introduced to resurrect the tool system is the right way to go. GimpToolInfo objects stay around so Gimp knows what tools are available, can display icons, etc., the real GimpTool only exists when needed. I really like what Mitch has done with the tool code. He read my mind when it came to renaming the gimp_tool_emit_* functions to more standard names. The GimpToolInfo objects are elegant. Mitch: if you haven't yet written the code to get rid of the items marked as needing to go away in the GimpTool class structure, let me know so that I can write it and you can spend your time on less trivial code. Yeah, I went through the code when I re-integrated the tool stuff with the context and could not resist to apply some coding style paranoia. Most of the fields are already removed, I suggest to leave the remaining two (pdb string and cursors) there until there are some more tools back. The pdb_string could become a virtual function which returns the string, I'll care about making something real out of the cursor code when there are some more tools. Fair enough. I was thinking about just putting them in GimpToolInfo like the others, but that might be a more elegant solution. I also wonder what happened to standard_control_func. I know it was misnamed, but it contained code that all of the current tools use and was fit for inheritance. In general, it should be ran before the tool's specialized control code. The function is now in the context manager because it's a wrapper around the active tool's "control" method. Just wanted to make sure it didn't disappear. Problem: Some tools, such as iscissors, keep around a lot of cached data generated from the image they are attached to. Changing the image they are working on clears this cache. This can be slow when working on multiple images or layers. discussion snipped Hm, I'd rather vote for making the tool system stable again with all tools in their proper places in the tool hierarchy before we start adding fancy stuff like caches. That was the idea. Get it to work, then get it to work better. (if nothing else, it's hard to debug code that doesn't work ;) And BTW, GLib already provides a cache mechanism which produces the requested data on the fly. I haven't poked around in the glib header files in a while. I guess I should since new useful functions keep on piling in there. It is. I just think of the Gimp part as a namespace. Besides, after typing GimpPaintingTool way too many times (yes, I found the macro command in my editor...) I'm kind of sick of typing that big, long name. ;) (btw, why the "ing" ??). Please make it GimpPaintTool, you just talked about long names above :) [snip] Well, I guess we should rather save some "ing" and add "Tool" all over the place to get a consistent namespace: GtkObject | GimpObject | GimpTool |\ | GimpTextTool | \ | GimpDynamicTextTool? | GimpDrawTool | |\ | | GimpColorPickerTool | | | GimpPaintTool | \ |GimpPaintbrushTool | GimpTransformTool | | GimpRotateTool GimpPerspectiveTool It is nice and consistant. One problem: TransformCore and TransformTool will both turn into GimpTransformTool under this system. (the transform tool is sorta a hack anyway, so maybe this problem will go away...) Also, the policy is to name files exactly as the objects they contain, e.g. gimptool.[ch], gimpcolorpickertool.[ch]. This may look a bit overly picky but a consistent file namespace is important in such a large codebase. True. Yosh: should we rename them ourselves? (cvs remove, cvs add) or do you want to rename the files on the server? I'd like all the tools that don't take a specific point as input to be turned into something else. My definition of a tool is something that you click on the image with. They should also use the image view directly (as should plugins). For example, by color select would count as a
[Gimp-developer] Fwd: Fwd: Same Emails!!
hi, I receive these emails almost every week, and usually throw them out. I finally gave in and clicked on the link. I cannot tell you how excited I now am, this being my 2nd week in the business. If you normally throw these emails away, please think twice and maybe even click on the link. Remember... It can't hurt to look!! http://www.geocities.com/nnew2000dollar sincerely, john telmonte ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gimp-devel] [Gimp-developer] preview icons
[For some reason this mail needed two days to appear on the list and then appeared three times. Is there a Problem with the new ML?] Sven Neumann ([EMAIL PROTECTED]) wrote: today this showed up in CVS: 2001-02-20 Simon Budig [EMAIL PROTECTED] * app/interface.c: Added preliminary support for Preview icons. [...] This is IMHO the most superfluous feature that has ever been thought of and overall a pretty bad idea. You don't want every single brush stroke to propagate a notification about an icon change to the window manager. Well - It was a crazy idea on #gimp and definitely was fun implementing it. At the current state the rendering of the icon is done in the idle loop so it should not have a too deep impact on the performance. Also it seems undesirable to create new gc and preview for this all the time. The necessary task switches and the overhead caused in the X-Server and windowmanager is IMHO not worth the advantage you might get from those icons. I strongly doubt that the icons will be helpful at all since their size is so tiny on almost all window managers. Using slightly different but static icons for different kinds of gimp windows might prove to be helpful. I dont think that these icons are useless. They have the same size as the default LayersChannels previews (we could make them the same size and so using the preview cache more efficient) and are recognizeable. We could of course change the policy like "update the icon when the window gets iconified" or "update the icon every 10 seconds" or something like that. And of course an option to disable them in the preferences should appear. Further opinions? Are the preview icons bound to become an easter egg? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [gimp-devel] [Gimp-developer] preview icons
On , 22 Feb 2001, Sven Neumann wrote: But most (all?) window managers scale them down to a tiny 16x16. Not mine: fvwm 1.24r IMO the whole thing should go away, but if people like it, please make a preferences option to enable it. I think it's a good idea. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
