Re: [Gimp-developer] The way forward for Color Management
On Fri, 13 Aug 2004, Alastair M. Robinson wrote: From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module. This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument. Wait -- the color selectors need to be filtered on a per-image basis as well. What if you are working in very different colorspaces for two images? It does you no good to select a color in the gamut of one image if you really wanted to select for the other one -- that color might not even be in the gamut of the the other image! Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
* Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.) I can't honestly think of a good reason to disable color management, but couldn't we just have an option for this monitor's colorspace instead of having two choice to choose from? On second thought, I can think of a reason to disable color management, but I still think that it wouldn't be a bad idea to just make this monitor's colorspace one of the options. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is an incompatible change to generated brushes acceptable?
On Mon, 2 Aug 2004, Simon Budig wrote: Hi all. I am currently working on some tweaks to the generated brushes (the brushes you can configure interactively). In Gimp CVS you can generate brushes like these: http://www.home.unix-ag.org/simon/files/generated-brushes.png Note, that currently the new functionality does not affect existing generated brushes. However, when I fiddeled with this stuff I got the impression, that the hardness-parameter should be a bit more extendable to the soft side of the brush - IMHO hardness 0.0 is not yet soft enough. I have a patch sitting here, that makes more soft brushes possible, but since this patch still maps the range from 0 to 1 the hardness for existing generated brushes would effectively be reduced, i.e. existing brushes will look softer when loaded with the next release of the GIMP. Do you think this is acceptable? Note that the current hardness could be reached easily by dragging the slider a bit upwards again. Is it possible to redo your logic so that the the old hardness scale is used, but it's possible to have negative hardness? Alternatively, we could use a fileformat versioning system to keep backwards compatibilty. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extrude-filter and lots of triangles
On Mon, 2 Aug 2004, Markus Triska wrote: I'm for now using a quick and terrible hack to fill the triangles (see attached source if you are curious) and want to ask: Which method do you recommend to fill lots of triangles from within a plug-in? Is there a (fast?) Gimp function for this that I can use, maybe capable of anti-aliasing? Well, the quick-and-dirty way of doing it would be to select a triangle shape and use the GIMP's fill function. :) I'm afraid I don't see why there is a lack of locality here: each triangle to be filled indeed has locality. Of course, if the triangle is sufficiently small, only one tile needs to be involved. Perhaps what you are really saying is that the tile cache needs to be really large to be effective because there is not much between-triangle locality. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-docs] Wording in German: Toolbox
Roman Joost [EMAIL PROTECTED] writes: This mail is for translating the Toolbox into German. I wasn't sure how to translate the Toolbox to German for the manual. But please, hold your breath and let me explain why. So, what do you guys think: Werkzeugfenster or Werkzeugkasten? I don't speak German, but Werkzeugfenster sounds cooler than Werkzeugkasten. In fact, I wouldn't mind a Werkzeugfenster T-shirt. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] removing gimp toys, second opinion please?
On Wed, 21 Jul 2004, Alan Horkan wrote: http://bugzilla.gnome.org/show_bug.cgi?id=148027 Given that some less used file formats have been removed in recently releases on the basis of less code to maintain and less general clutter I suggested that the old Toys be removed from the Gimp for version 2.2. To my surprise Mitch rejected the idea (without much explanation), Adam who wrote the toys didn't seem to think it was a terrible idea so I'm asking onlist to try and get a second opinion. If Excel had a flight simulator, Gimp can have a few toys. :) If toys like Gee-Zoom were built on top of a useful plugin (eg some sort of a kaleidescope plugin for example) I wouldn't even be asking but they toy are not useful at all sso users are just presented with eye-candy and left wondering how they can get that effect on their actual image but they cannot. I guess it wouldn't be impossible to have Gee-Zoom render individual frames as layers, but that ignores the real question, which is why we don't have some cool effect like gee-slime on the splash screen. If you still reject the idea I would ask you to keep the toys in mind when it comes to menu reorganisation. (Wiki is still down otherwise I'd add this to the menu reorganisation document we had there). The Gnome HIG recommends: http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu Do not create submenus with fewer than three items, unless the items are added dynamically (for example the File-New Tab submenu in gnome-terminal). Fortunately, this is only a recommendation. Since the toys are rarely used, I think the uniformity of the Filters menu having just submenus and the usefullness of having the Toys being explicitly labeled as such is better overall. If we broke out all the menus that have only two items, I don't think the menu would fit on the screen. :) Besides, the best solution is to add another toy. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
On 21 Jul 2004, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I think it would be even more useful to set the compose mode to the last used decompose mode, rather than the last used compose mode (if you get my meaning). Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header. Why not put a parasite on the images created by decompose saying what mode the image was decomposed with, and which layers (or images, depending on the options when you decomposed) corrispond to which channels? Then there would be no need for guessing, and you could work with more than one decomposed image (or layer, for that matter) at once. You would still want to allow the user to switch to some other layer for the recompose, of course, but it would be nice to default to the way it was decomposed. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Scheme [was Re: [Gimp-developer] OSCon attendance]
On Thu, 15 Jul 2004, Shlomi Fish wrote: Another implementation of Scheme? Aren't the ones in: http://www.schemers.org/Documents/FAQ/#implementations enough? Or isn't any of them better suited as a starting point? Yeah, really, Little Scheme (http://www.crockford.com/javascript/scheme.html) is all anyone could ever need :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
On Thu, 15 Jul 2004, David Neary wrote: Hi, Shlomi Fish wrote: On Wednesday 14 July 2004 05:49, Nathan Carl Summers wrote: Heh, my vote is for Valgrind. :) Well, valgrind is a very nice and useful tool. (I know becuase I'm also using it extensively) However, I think that perhaps GNU Arch deserves to win because: And what about the GIMP and its 10 years of being a core Free Software application? Hmm, perhaps you missed the Heh at the beginning of my mail. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
On Wed, 7 Jul 2004, Dave Neary wrote: Hi, Quoting Carol Spears [EMAIL PROTECTED]: On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote: Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. awesome. We're a long way from winning - we're up against the Valgrind guy, Pango, VideoLAN, GNU arch and a couple of other really good projects. We have a shot, though. Heh, my vote is for Valgrind. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
On 9 Jul 2004, Sven Neumann wrote: Hi, Tor Lillqvist [EMAIL PROTECTED] writes: I think what the OP really meant to ask whether GIMP requires a *pre-emptively* multitasking OS. I.e. one that can interrupt a running process that has exceeded its timeslice, even if it doesn't do any system calls (or similar) that gives the kernel a chance to let another process have the CPU. (For instance, Windows 3.1 wasn't able to do that.) As far as I can guess, sure, GIMP might work on such a system... I don't think GIMP plug-ins would work w/o proper multitasking and using GIMP w/o plug-ins doesn't make too much sense. Hmm, I'm confident you could get it to work on a cooperative multitasking system. You might need to add a yield() into the glib loop, but no big deal. Of course, it wouldn't work *well*, but then again cooperative multitasking never does. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Sun, 6 Jun 2004, Ellen Reitmayr wrote: I understand there is quite a learning curve involved with the path tool. On the other hand, compare the tool to what sodipodi implements. They have clear buttons for every action yet completing the same task means kilometers of mouse movement and millions of clicks. Of course keyboard shortcuts are very important for quick interaction with the tool! Nevertheless, not every user is a image manipulation expert, possibly does not know the concept of path tools at all. For such user, the learning should be facilitated, by supporting the exploration with simple shortcuts and the like. How about buttons for every mode, with a one-key shortcut to switch between modes? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Blur plug-in
On 7 Jun 2004, Sven Neumann wrote: 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. *chuckles* I agree. [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usability test - Results available
On Mon, 7 Jun 2004, 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. 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. show what you the human being wanted the gimp to do is a very very good question. i'm questioning the testers use of YOUR time, dude. relax. It's easier to improve the user interface of gimp than it is to improve the gimp interface of all current and potential users. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On 22 May 2004, Sven Neumann wrote: So this API would allow you to queue a redraw even after the buffer is only halfway written. Of course you would also have to run the main loop for the redraw to actually happen. Anyway, I consider this rather bad style. IMO, if the preview takes considerable time, then it shouldn't be shown halfway done but instead the progress API should be used to draw a progress indicator in place of the preview. What do others think? There are a lot of image applications that perodically update the preview. In fact, this is essentially what the gimp color balance tools do -- load a large image and adjust the sliders intermittantly and you can watch the previews go by. There are good arguments for incremental update, and good arguments for a progressbar. Superimposing a busy cursor over the preview or replacing it with a progress indicator makes judging between slight differences in the settings harder. But I think the real issue here is that slow previews should be computed in small chunks in an idle handler so as to not impede interactivity. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
On Thu, 20 May 2004, William Skaggs wrote: The motivation for doing this is that it seems to me that the existing edge detection plug-ins distributed with Gimp are rather weak in terms of output quality Yeah, I've never been very happy with them. (their advantage is that, because they are all just 3x3 convolutions with different kernels, they are simple and very fast). Since they are so similar, it might make sense to put them all in one binary. If nothing else, that way we could consolidate some menu items. We would want to continue to export a compatibible PDB API, of course. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] None
On 21 May 2004, Sven Neumann wrote: Also I remember that the plan was to move all edge algorithms into edge.c in order to obsolete the other plug-ins in the distribution. That tasks has probably not been finished before 2.0. Might be a good time to do that now. Come to think of it, it might be benificial to put some generic convolution code in libgimp or an allied library. Just a thought. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
On 17 May 2004, Sven Neumann wrote: Well, we don't have such an entry and I don't see it being added for GIMP 2.2. So for now we should IMO keep the changes to the dialog purely cosmetic. It will help users to be able to recognize the Scale dialog that they have worked with in earlier GIMP versions. Also it makes the code changes easier to do in the limited timeframe that is left before 2.2 is supposed to be done. * The ratio control has been dropped, since it effectively duplicates the % unit. I'd rather drop the % unit since I don't think that it is intuitive enough. From my experience the ratio control is the most used control in this dialog and IMO it should stay. I agree. Percentage changes are definately common enough to warrant their own control set. Percentage isn't even considered a unit outside of the computer graphics world, so most people wouldn't think of using a units selector to select a percentage. Now, if the default on this dialog was always %, that might work, but it might cause other problems as well. Something to test in the lab. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another new image dialog mockup
On 7 May 2004, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: I took a look at the new image dialogs on the list today, and I made a few improvements. I've posted them at http://wilber.gimp.org/~rock/NewDialogSimple.png and http://wilber.gimp.org/~rock/NewDialogExpanded.png Sorry, but I fail to see any improvements in these mockups. Honestly, I would have expected you to reply in a more thoughtful and constructive manner. It's obvious that I spent some time (hours, actually) constructing this mockup, and that I didn't think that my choices were stupid, yet it really feels like you have dismissed them all out of hand. This is exactly the reason GIMP has problems attracting and retaining new contributors. I'm sure if you have asked yourself why I was suggesting the things that I was, what you would have said would have been more reasonable, or at least more reasoned. You know that I am not an idiot. You also know that I spent three months as an intern in a usability lab, so I'm not completely clueless about the topic. If you failed to see any improvements, you also failed to see why others might think that there are, and to identify the principles behind which the changes were made. Not only that, you didn't give me the opportunity to comment more on them (like I said I would) before summarily dismissing them. That is more than bad intellectual practice; it is bad leadership. That said, here is my responce to you comments. The icon next to the memory size as well as the bold label Memory Required don't add any value The icon adds value in two major ways: 1. It provides instantaneous feedback about whether memory usage would be above the threshold set in the user preferences. This is a usability win, since it allows the user to immediately fix the mistake instead of having to re-open the new image dialog after the warning comes up as a separate alert as in http://bugzilla.gnome.org/show_bug.cgi?id=21028 and the user cancels the image creation. Note that it's still a good practice to have the alert box come up as a double-check that the user wants to create an overly large image, even if they have already been warned here in the new dialog. 2. In its normal usage, the icon immediately identifies the corresponding controls as being informational and not directly manipulable. Since the general layout is consistent with other GTK applications, instead of distracting the user, it allows the user to immediately recognize that in order to get the work done, the user needs to manipulate the controls in the other sections of the dialog. It would take a higher level of processing to identify the purpose of the section if the icon were not present, or if it were not placed where it was. wastes screen estate Screen estate is really a non-issue here. Even with the ridiculously bloated theme that comes with Glade for Windows (yeah, yeah, buy me a T1 so I can do this kind of stuff at home on my beloved Debian Sarge box instead of at work) the fully-expanded dialog is by default 344 x 521 pixels, which means that it will fit on any display bigger than 640 x 480. Actually, it will even fit on a 640 x 480 display, since the somewhat ungraceful behavior of the dialog is to clip the bottom part if there isn't enough space allocated. If your display adaptor can't do 640 x 480, you will have bigger problems with GIMP than just the new image dialog going off the screen. Since the new image dialog is unlikely to be open very long, how much it occludes other windows that are in use is unlikely to be an important consideration. Even if real estate was an issue, the mockup in total is 32 pixels longer than the screenshot you posted yesterday. The difference in real-estate usage is not that great, and would probably be mitigated almost completely if the same theme was used in both screenshots. I should note that the screenshot posted yesterday wouldn't fit on a 640 x 480 display, either. Regardless of whether minimizing screen estate is a priority for the new image dialog, given the previously discussed utility of the icon, I would argue that it is a very effective use of real estate. In fact, I experimented with several layouts for the memory required portion of the dialog. Some had icons and some did not. For those that did have icons, I experimented with the size of the icon and with hiding it when the memory requirements did not exceed the threshold. This layout was by far the most effective, and that is why it is the one that you see. It is the most effective because it is a slightly miniaturized version of the standard HIG information window layout, and so, since it is consistent with other applications, it is immediately identified by the user for what it really is. Furthermore, the icon area is designed so that it can accommodate vast changes to the size of the dialog while still being aesthetically
Re: [Gimp-developer] Gimp Menu Reorganization
On Wed, 5 May 2004, Ellen Reitmayr wrote: Hi all, I just wanted to let you know that I'm still there to attend to some usability issues! Roman and I did some usability testing, and we wrote an article for the German Linux User based on the findings. In the meantime, we were both quite occupied with working for our offices, but now we started translating the results into English and to form some suggestions. We'll soon post them on the list! I look forward to reading that. This week, I'll do three or four more tests, and I'll also show them the Wiki page to make them think about a good menu structure. It's really a great idea to provide a Wiki page for that concern!! I'm also planning to do some card sorting to learn more about the user's cognitive representation of the menu items and use the page as a basis for that. Great! That would be very helpful! Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
On 3 May 2004, Sven Neumann wrote: Hi, Dave Neary [EMAIL PROTECTED] writes: There are only a very small number of people who really believe this to be still the case. It may still be called the GIMP Toolkit (but more more I've heard it called the GNOME Toolkit), but that is a historical nod. I disagree. Every time we port GIMP to new features of the GIMP toolkit I get the strong impression that we are the first using the new API. There's certainly a lot of interaction between GIMP and GTK+, way more than between GIMP and the gimp-print project. It should be pointed out that Sven is our main point of contact between GTK and GIMP, so I'm sure he's much more aware of the continuing interaction between the two projects. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)
On 3 May 2004, Sven Neumann wrote: PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost HIG compliant file-new dialog. This is a screenshot from the HEAD branch. Looks fantastic! I really like the hideaway Image Comment section. Here are just a few minor suggestions that I think would improve the dialog: * The extra title bar seems to take up a lot more space than it needs. * Center Create a New Image vertically (perhaps horizontally as well) * Put the size in bytes either flushed right to or directly under the Image Size label. Flushed right will probably look better. * Move the portrait/landscape controls to the right of the template dropdown. Grey them out when no template is selected. * Merge the two Width and Height entries, or make the second one hideaway. If you make the second one hideaway, make the top one have a dropdown units menu, so that you don't have to use the hideaway to specify image size in units other than pixel. * Consider making Resolution hideaway as well. * Resolution should have its own outdent, just like Image Size does. * The units dropdowns should be centered vertically between the two entry boxes to which they apply. (It would be better if they were aligned horizontally as well, but the presence of the link control in the resolution area makes that impractical.) * Consider putting a GtkVSeparator between the Image Type and Fill Type combo box lists. These are pretty easy to do; I would make the changes myself except that the universe seems to be conspiring against me ever having a machine that I can follow gimp-development work with. Poor Rockwalrus. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 4 May 2004, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: What I didn't address yet is the fact that the HIG suggests to left-align labels of UI controls while we currently consistenly right-align labels so that they are close to the control they are describing. I am not sure if I can follow the HIG argumentation for this. I guess we should create some screenshots or mockups of standard GIMP dialogs and discuss this change here before we start to work on this. It seems like the HIG suggests left-alignment for controls whose labels are roughly equal in length, and right-alignment for dissimilarly-sized labels. While this probably does result in the most pleasant appearance, it's an internationalization nightmare. I suggest we stick with the Palm usability guidelines here. I suggest that the next version of the HIG do the same. Since we use a whole lot of those labels that say something like Scale X: and below Y: I think we should generally stick to the right-aligned labels that we use now. What does the HIG say about the colons? Are they needed? Due to kerning the Y tends to crawl under the trailing colon so I'd rather get rid of the column and increase the spacing from the currently used 4 pixels to 6 pixels. Colons are definitely required; the HIG states that they help screen readers identify which component is being labeled. On the other hand, labeling the two components X Scale: and Y Scale: seems to conform better to the independent-labelling guideline while also conveniently working around the kerning problem. (For those unfamiliar with the independent-labeling guideline, the HIG suggests that the entire meaning of a control be contained in the label, because those with screen-readers cannot tell that (in this case) the Scale X: and Y: labels are arrainged analogously, and that both refer to the scaling parameters.) And while we're talking about the HIG, I still wonder what they were smoking when they suggested that Gnome lay out all of its buttons opposite to the way that common sense and every other set of UI guidelines I've ever read suggests. If you are refering to the button order in the action area, I have to say that I am very happy about this decision. Mac OS uses this button order and I always found it to be more logical than the Windows way of arranging the buttons. It seems to me that it makes sense to order the buttons so that when they are scanned in normal reading order, the most likely button press is the one that is read first. If you know you want to Launch Spaceship, why should you have to skip over Help, Surrender Game, and Cancel Launch first? I know that you can train yourself to scan the buttons backwards, but this is inherently less efficient, unless you learn to llew sa sdrawkcab dear. I didn't know that the Apple said something different. I'll have to read their guidelines again. They probably have some good rationale. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
On Sat, 1 May 2004, David Neary wrote: Hi all, Myself and Dan Rogers will be meeting with someone from the GNOME Foundation this week with the intention of having greater co-operation with them on things like money. For the moment, I am working under the supposition that the best option available to us is to join the GNOME Foundation. The alternative is that Dan continue with the work involved in creating an independent GIMP Foundation. The short term effects of doing this would be that we wouldn't have any way to accept tax-deductible donations in the US for this year, and it is unlikely (given Dan's current availability) that the foundation would have cleared up all paperwork issues and elected a board before the end of the year. On the other hand, a partnership with the GNOME Foundation would give us federal tax exempt status in the US now. We could probably work out an arrangement where contributions made to the GIMP get used for GIMP events. Are there any people opposed to closer ties with the GNOME Foundation? I don't see any reason why we can't do both: work closely with the GNOME Foundation now, while the GIMP Foundation is getting off the ground, and then continuing to work with them to some extent once the GIMP Foundation is a reality. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)
[EMAIL PROTECTED] accidentally forgot to cc the mailing list. Forwarded with his permission. Date: Mon, 3 May 2004 16:53:32 -0500 From: Seth Burgess [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Nathan Carl Summers [EMAIL PROTECTED] Subject: Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation) Also, from the HIG: Right-justify the contents of spin boxes, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned. Its just my opinion, but I think showing 3 places of precision past the decimal for resolution is a bit excessive and I would hazard rarely adds any useful information. The alignment of 'Y' seems different than that of 'X' in 'Resolution X.' Maybe just an odd font rendering, but it looks to me like Resolution X has an extra space between X and ':. I disagree on the vertical separator - I think the absense of such noise is welcome in the dialog, and its pretty clear without it due to the bolded headings. Seth On Mon, 3 May 2004 13:40:03 -0700 (PDT), Nathan Carl Summers [EMAIL PROTECTED] wrote: On 3 May 2004, Sven Neumann wrote: PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost HIG compliant file-new dialog. This is a screenshot from the HEAD branch. Looks fantastic! I really like the hideaway Image Comment section. Here are just a few minor suggestions that I think would improve the dialog: * The extra title bar seems to take up a lot more space than it needs. * Center Create a New Image vertically (perhaps horizontally as well) * Put the size in bytes either flushed right to or directly under the Image Size label. Flushed right will probably look better. * Move the portrait/landscape controls to the right of the template dropdown. Grey them out when no template is selected. * Merge the two Width and Height entries, or make the second one hideaway. If you make the second one hideaway, make the top one have a dropdown units menu, so that you don't have to use the hideaway to specify image size in units other than pixel. * Consider making Resolution hideaway as well. * Resolution should have its own outdent, just like Image Size does. * The units dropdowns should be centered vertically between the two entry boxes to which they apply. (It would be better if they were aligned horizontally as well, but the presence of the link control in the resolution area makes that impractical.) * Consider putting a GtkVSeparator between the Image Type and Fill Type combo box lists. These are pretty easy to do; I would make the changes myself except that the universe seems to be conspiring against me ever having a machine that I can follow gimp-development work with. Poor Rockwalrus. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)
On Mon, 3 May 2004, Seth Burgess wrote: Also, from the HIG: Its just my opinion, but I think showing 3 places of precision past the decimal for resolution is a bit excessive and I would hazard rarely adds any useful information. Good point. I disagree on the vertical separator - I think the absense of such noise is welcome in the dialog, and its pretty clear without it due to the bolded headings. Asthetics is such a fickle thing. :) I suggest the separator for two reasons: 1) It's not so clear to my eye that the two lists aren't related in some way. but more for: 2) It distracts from the fact that the two lists are asymetrical. I think that if Resolution is outdented, that will be somewhat less of an issue. Also, a separator was what was clearly suggested in earlier drafts of the HIG for this exact kind of case, although that language seems to have been watered down to something to the effect of add a separator if you need one in the current version. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Menu Reorganization
On Sun, 2 May 2004, David Neary wrote: Sven Neumann wrote: Nathan Carl Summers [EMAIL PROTECTED] writes: http://wiki.gimp.org/gimp/GimpMenuReorganization Very nice. I wonder if there's a way to convert between the menu XML files and the Wiki content. That would make it possible to easily try the suggested menu layout. The forward direction (menu XML to wiki text) should be trivial with xslt - the other way would probably be easier with perl or something. That's funny, I think of wiki - menu as being the forward direction. :) Turning wiki into XML looks like it should be trivial with Perl. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 3 May 2004, Sven Neumann wrote: Hi, here's another summary of what's happening in the HEAD branch, what do watch out for if you want to join development and where help is needed... Mitch has almost finished the port of the menus to GtkUIManager. The new code is in use now and seems to work fine. The only remaining regression is integration with the help system (pressing F1 on a menu item should call the relevant help pages). This is being worked on and will soon be reenabled. Is the ocassionally-suggested right-click-menu for menu items easily implementable with GtkAction? I started to change our dialogs to be more compliant with the GNOME HIG. To ease this effort, I've added a new widget called GimpFrame. This is a variant of GtkFrame that doesn't draw a frame but instead sets a bold title and indents the content of the frame as suggested by the HIG. I've changed some core dialogs already and I think the results look very pleasant. What remains to be done here is changing all plug-in dialogs. I don't plan to do this myself so it would be nice to get some volunteers for this task. It's important that we try to create a consistent dialog layout so this job should be well coordinated or done by a single person. Any volunteers for this? While I don't volunteer to be this coordinator, I have created a Bugzilla entry to help with that process: http://bugzilla.gnome.org/show_bug.cgi?id=141772 This seems like an excellent opportunity to get new volunteer developers' feet wet. We could have a news item blurb about it on wgo that links to a page on dgo with the proper steps: 1. Identify plug-ins with forbidden dialogs. 2. File a bug-report on bugzilla for each bug, making it block #141772. (there should be a mini-tutorial on how to file the bug and make it block #141772) 3. Identify the offending plug-in dialog code, and fix it. (Mini-tutorial here as well) 4. Attach patch to bug report, add keyword PATCH. 5. Bask in glory. What I didn't address yet is the fact that the HIG suggests to left-align labels of UI controls while we currently consistenly right-align labels so that they are close to the control they are describing. I am not sure if I can follow the HIG argumentation for this. I guess we should create some screenshots or mockups of standard GIMP dialogs and discuss this change here before we start to work on this. It seems like the HIG suggests left-alignment for controls whose labels are roughly equal in length, and right-alignment for dissimilarly-sized labels. While this probably does result in the most pleasant appearance, it's an internationalization nightmare. I suggest we stick with the Palm usability guidelines here. I suggest that the next version of the HIG do the same. And while we're talking about the HIG, I still wonder what they were smoking when they suggested that Gnome lay out all of its buttons opposite to the way that common sense and every other set of UI guidelines I've ever read suggests. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
On 3 May 2004, Sven Neumann wrote: Hi, Dave Neary [EMAIL PROTECTED] writes: Well, dgo was started to finally give an alternative to this outdated sourceforge site, so please consider to help with dgo instead. It's in CVS, you have write access, feel free to improve it. Do you have to run any weird scripts after you make changes, like you did with the old wgo? CCed to the list in the intrest of making the answer public knowledge. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OpenGL under GIMP ??
On 30 Apr 2004, Sven Neumann wrote: Hi, Pablo Quinta Vidal [EMAIL PROTECTED] writes: This is my first post to the list and I want to know if its possible to use OpenGL under GIMP. GIMP doesn't use OpenGL but of course a GIMP plug-in can use whatever library it wants to use as long as it's possible to integrate it with the GLib main loop. Try GtkGLExt. It's at http://gtkglext.sourceforge.net Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Environment settings big images
On 23 Apr 2004, Sven Neumann wrote: Hi, David Neary [EMAIL PROTECTED] writes: Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve. How, exactly? AFAIK they don't load the full image into memory. If you open a large image, only the preview is loaded and if you zoom in, then only the necessary parts are pulled into memory. Of course this doesn't work with all file formats. There are already bugzilla entries about this -- most prominantly #107246. I have a feeling to do this right it would have to be a fairly sophisticated GEGL node. Why aren't I on gegl-developer again? :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS statistics
On 23 Apr 2004, Sven Neumann wrote: Hi, for those of you that are into statistiscs, have a look at this: http://libresoft.dat.escet.urjc.es/cvsanal/gnome-cvs/index.php?menu=Modulesmodule=gimp Obviously, the top 21 on that page should get special privileges. ;) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
On Wed, 21 Apr 2004, Carol Spears wrote: while i appreciate someone else being the new person to really abuse the mail lists (try cc and one time multiple mailings). ((check to see if it is sent to the list or not)). (((forgive me when i screw up, sometimes -- all i get is mail list mail))) and send the email carefully. more carefully than me. Ek! I feel like I am reading sentences written in scheme! :-P ;-) :-) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
On Thu, 22 Apr 2004, Carol Spears wrote: i have a bad opinion of someone who so easily gets to change things on an established list. If I recall correctly, it was Dave who was asking for changes to the list, or rather, a return to the civility that once was here. if you want a friendly mail list about gimp, gimp-user list totally fullfills this. There is no reason why gimp-developer can't fulfil it as well. Besides, what if someone wants a friendly list to talk about gimp development related issues? is this person with the smutty mind a developer? I don't think he has a smutty mind, just is painfully mindful of those that do. And there should be no chinese wall between the developers and the users. How else can the developers know what the users think, need, and want? With no feedback, it's hard to know if changes to the gimp make it more useful and usable. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 22 Apr 2004, Sven Neumann wrote: - A plug-in to load and save windows icon files has been added. I figured that the plug-in is not working correctly at the moment. Not sure what exactly is going wrong but there's some debugging needed here. I'm not sure what the problem you are having is, but I can say that last time I looked at the windows .ICO plugin it didn't support multiple-bitdepth icons, at least on saving. ImageMagick produced bogus .ICO files as well. I ended up saving BMPs in GIMP and using a very early alpha of IconShop to create the icons I needed. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp usability tests
On Wed, 21 Apr 2004, Juhana Sadeharju wrote: From: Roman Joost [EMAIL PROTECTED] Tasks for the first test (all-day-usage; all of the are common tasks for all people, except the one where the indicated group is mentioned): Could you also make a proper usability test for the rectangular selection? I seem to be forced to use the re-try approach where I start making the rectangular selection from scratch if it goes wrong (and the initial fine-tuning never goes right at first time!). It also seems to be impossible to make precise selections in large images (e.g., 800x800 to 6000x6000). Both large selections and long narrow selections on large images are trouble. If zoom-in is used, even relatively small images becomes large. This is a good idea for a usablilty test subtask. While the difficulties with the selection tools are well known by the developers, that doesn't change the fact that a usablilty test can show the extent to which it is a problem. (In fact, usablilty tests often start with known or suspected weaknesses.) I for one would be interested in seeing the results, should your suggestion be added to the test. Test the crop tool too -- it fails for large images as well, or when zoom is used for seeing image details. It would be very useful if we can determine which are the biggest impediments to usability here. There are three factors which come to the top of my mind: 1) The extreme brokenness of autoscroll. Autoscrolling tools currently scroll far too quickly to be useful in most cases. 2) Users may not be aware of how to change zoom levels without loosing tool state. Or, in the case of the rectangular select tool, there is no real way to usefully change the zoom, since the entire operation must be performed in a single drag manuver. 3) The interface mechanics (feel) of the tools may need some redesign. For instance, maybe the crop tool should automatically size itself to the bounds of the current selection. Perhaps the rectangular selection tool should work somewhat like how the old bezier select tool did (where you could edit the outline of the selection by clicking at the right points, or cause the selection change to actually occur by clicking in the center.) This would, of course, make selection CSG operations more difficult, so perhaps a third method, where the only selection operations are select the interior of a path, invert, and QuickMask, may actually be more useable, and should be tested as well. I'm puzzled: do you people make perfect initial selections or how you scope with the problem? Generally what I do is make a rough cut in the large and then adjust the selection using the CSG operations. This is pretty unsatisfying sometimes, as you mention, like when you need to move the boarder of a wide selection up a few pixels. Often that requires a lot of adding and subtracting before you get it right. If anyone wants implement the unirectangular selection tool and/or improve the crop tool, please don't hesitate ask my improved designs. (No patent pending.) If you have any suggestions I haven't covered here, I would be interested to hear them. (GIMP does not anymore compile in my Linux -- we should work out the tools together, if at all.) I'm having a difficult time understanding what we should work out the tools together, if at all means, but I assume you meant to say that you wouldn't mind help getting GIMP to compile on your machine, which of course the GIMP developers are more than happy to help with. Unfortunately, due to the fact that there are many things that could potentially be at issue here, and Burrito, the GIMP developers' official psychic, has been a little vague as of late, it would probably help us to know more specifically what problem you are having. The last error messages you got (other than the annoying Make [56872165]: leaving subdir foo/bogus/stuff: Error 1 messages) are most likely to be useful. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] software patent protest?
On Mon, 19 Apr 2004, Henrik Brix Andersen wrote: Hi, On Mon, 2004-04-19 at 14:57, Branko Collin wrote: I noticed that http://www.gimp.org has gone 'black', in order to protest European software patents. A noble cause, for sure, but should this not have been announced at least, perhaps even debated? Or did my trigger-happy, spam-seeking delete-finger erase that message accidentally? This was discussed on the gimp-web mailing list. It should also be noted that last time we did this it was discussed on gimp-developer as well. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] interface nomenclature
On 1 Apr 2004, Sven Neumann wrote: This linked state does not only affect movement, it also applies to transformations. Interesting. I did not know that. You learn something every day. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
On 25 Mar 2004, Sven Neumann wrote: Hi, Branko Collin [EMAIL PROTECTED] writes: As some of you may have noticed, for a short while there was a www.gimp.org that claimed a release of GIMP 2.0.0., and Slashdot confirms it, so it may be true. The corpse of the Slashdot story has grown decidedly cold and rigid, yet http://www.gimp.org still seems to be down (or just very, very slow). The new machine seems to have some problems. It remains to be figured out what kind of problems. But it went alive yesterday after the slashdot attack and when it's there, it's very responsive :) No idea why it's not avaiable at the moment, but rest assured, we know about the problem and it will be taken care of. Also, urls like http://www.gimp.org/~tml don't work, but you probably already knew that. http://wilber.gimp.org/~tml does work still. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
On 25 Mar 2004, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Also, urls like http://www.gimp.org/~tml don't work, but you probably already knew that. http://wilber.gimp.org/~tml does work still. It works again now. Hmm, not for me: Not Found The requested URL /~tml/index.html was not found on this server. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. Apache/1.3.26 Server at mmmaybe.gimp.org Port 80 Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Sun, 21 Mar 2004, Manish Singh wrote: On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write. There hasn't been any real planning, other than planning to do some planning after 2.0 is out. All I was saying is that we haven't forgot about it. 2.0 is out now. :) What requirements would the new PDB have? There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support. Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object. Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :) UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by UI generation before I could comment on it. Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done. GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api. If we do use a translating shim, Libpdb seems like a good fit for this as well. It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method. CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us. If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] PDB Named Parameters
On Fri, 19 Mar 2004 [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. FYI: the version of libpdb in CVS already uses named parameters instead of positional ones. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Foundation
On Mon, 8 Mar 2004, Daniel Rogers wrote: Hello again, It has been awhile since I have done a GIMP Foundation update. There is quite a bit that must be decided on at this point. Also, people need to decide how invovled they would like to be. My goals for The GIMP really boil down to three things. First, I really want to see The GIMP to be a household name for professional image editors. Second, I want to the GIMP as easy as possible for volunteers to contribute to. Third, I want to be able to turn The GIMP into a real, paid, career for a team of people, including myself. I would add usability for all and ease-of-getting started for new and casual users to the list of gimp goals. If you are a board member you must: Attend board meetings. Is this required to be in person, or is conference call/irc/email/etc sufficient? Furthermore, is it possible for board members to be reimbursed for expenses? I can see this being a major obstacle for non-us residents otherwise. WHAT THE ORGANIZATION CAN DO Here are a few of the things, that given the oppurtunity and funds I would like to do with TGF. In my mind one of the major reasons to have a Gimp Foundation is to put all of our IP ducks in a row. As I've said before I don't think that having contributors sign over copyright to TGF would be the best plan. Instead, I would like to see the ability to give TGF power-of-attorney to sue copyright violators in their behalf. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Foundation
On 8 Mar 2004, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: In my mind one of the major reasons to have a Gimp Foundation is to put all of our IP ducks in a row. As I've said before I don't think that having contributors sign over copyright to TGF would be the best plan. Instead, I would like to see the ability to give TGF power-of-attorney to sue copyright violators in their behalf. Does IP mean what I think it means? Let's hope it doesn't because there simply is no such thing as intellectual property. Knowledge must not belong to anyone. I believe that intellectual property is a natural right, but should be limited in scope for the same kind of reasons that you are not allowed to invite someone onto your property and then kill them, even though you own the weapon and the land. More specifically, I think that the number of years copyrights last should be counted on one hand, and that if you have access to software, you should have access to its source. I could go on with more detail about my views about copyrights and patents, but that is really offtopic for this list. I agree with RMS that lumping several somewhat dissimilar aspects of law together under the same title can lead to confusion, but in this case, it causes no confusion, since the gimp foundation should indeed hold all gimp related copyrights, trademarks, and patents. GIMP can't have trade secrets, obviously. And a service mark might be more appropriate than a trademark; i dunno. Having a patent or two for protection might be pragmatic, even though I think that software patents are stupid. If sueing copyright violators is the main goal, I'd rather let the Free Software Foundation do this job. It is probably in a lot better position when it should ever come to a law-suit. Well, the FSF cannot sue unless it has copyright assignment from us, and I don't think we can really do a credible job unless it gets assignment at least from Spencer, Peter, Sven, and Mitch. (All other substantial contributors are also listed here, your eyes just skip over them every time you read the list :) Also, so far the FSF has done a great job at funding our developer conferences. So we should really have good reasons to form our own foundation since I don't expect the FSF to grant any more fundings as soon as The GIMP Foundation has been created. This is not a vote against the TGF; it's just something to keep in mind... Perhaps we should bring the FSF into the discussion. We are, after all, an official GNU project, even though FSF gives us complete autonomy. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Costs estimates
On Mon, 23 Feb 2004, Dave Neary wrote: Hi all, For funding requests for GIMPCon in Norway, it will be very useful to have cost estimates for the event for the GIMP. Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? Ugh! I can't find airfare there any cheaper than about US$1500. Has anyone from the US found a much better deal? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on OS X
On Wed, 11 Feb 2004, Daniel Egger wrote: On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote: Daniel recently posted a list of X extensions supported by the Apple X11 server. The MIT-SHM extension was part of this list but today I found that at least in darwinports gtk2 is compiled with the --disable-shm configure option. Does anyone know if fink does this as well? I can confirm it does. Is there a particular reason to disable the use of the XShm extension on OS X? This would explain at least some of the slowness that people reported here lately. IIRC, didn't early versions of OS X have truly pitiful amounts of shared memory available? Perhaps that is the reason. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GNU Image Manipulation Program
On Wed, 28 Jan 2004, Dave Neary wrote: Hi all, Dave Neary wrote: Because of its continued excellence and longstanding presence as a key free program, I think that the GIMP deserves an OSA. Apologies for jumping the gun, I hope I didn't step on anyone's toes doing this. I personally would never be upset with anyone trying to obtain money for gimp, as long as it is done legally. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source
On 21 Jan 2004, Sven Neumann wrote: What is especially worrying me is that there seems to exist a proposal for EU legislation to require devices and software to include counterfeit deterrence technology: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. Yes, I think it would be best to do it as a joint GIMP/FSF Europe comment. I would include something akin to the following: * GIMP is a popular image-manipulation program that is used in many different applications, such as web design. * Should legislation be enacted requiring currency detection, GIMP would effectively be outlawed from the European Union, since, due to its open source nature, it is trivial to modify it to skip the currency detection step. * The legislation would not have its desired effect anyway, since it is not significantly more difficult for a dedicated individual to modify a closed-source program to skip the currency detection. Once a program is modified once, it is trivial for instructions on how to modify the program to be spread to others. * There are many legitimate and legal uses for images of currency. FSF Europe and the GIMP developers are greatly opposed to any measure that would restrict the freedom of expression of the citizens of European Union member nations. It would then of course be signed by all the GIMPers who are members of the EU. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Status of gegl, gimp 3.0?
On 5 Nov 2003, Sven Neumann wrote: Hi, Piotr Legiecki [EMAIL PROTECTED] writes: Indeed. Websites do rarely say anything useful about the state of development of an open source project. If you had a look at CVS, you'd have noticed that there is indeed development going on. Which brings up an interesting question -- how can an open source project accurately represent what is going on in developmentland on its web site? It's more of a question to ponder -- I don't have the answer myself. On first thought, a todo list with progress bars and lists of current scarry bugs would be good, and a Kernel Cousin-like newslog could be good, too. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
/me returns from the hurricane, finally able to catch up on several days worth of email. On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote: However I *love* the Ctrl-R binding, especially because it lets me quickly compare the done and undone versions of an image using a single hand with very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find that you need either very good coordination between fingers (better than the one I have at least) or to use both hands. I agree. Gimp's undo and redo feature differs from many other programs in that when comparing subtle changes it is useful to switch rapidly between the before and after views, while for a program such as a word processor, that is probably not a useful thing to do. This being the case, this particular need of GIMP users was probably not considered by the HIG. Personally, I compare between the before and after by holding down control and hitting z or r as necessary. For some changes, I switch several times a second, as the human eye is remarkably able to detect small differences when they are animated. Switching between views this fast with accuracy is simply not possible using Shift-Ctrl-Z due the the physiology of the human hand. The optimal hand position is left on the shift and control and right on the z, with the finger on the shift moving every other beat of the other hand and the finger on the control key staying still. Here the body's natural cordination works against switching views quickly, as the nervous system will assume that the finger on the R key and that on the shift key should really be synchronized. This leads to errors. With the old bindings the natural cordination system helps to acomplish the task accurately and faster. So, if it's possible to have two different keybindings for the same command I'd like very much to have both. Unfortunately, it is not. Really, GTK should be made more flexable in this regard, but it is not a trival problem, due to how GTK handles accelerators. Since we only can choose one, it makes sense that we choose the one that ergonomics favors. I'm sure that in this case most usability people would say that actually being able to use the feature is more important than consistancy with some other apps. Especially because this particular funciton isn't particularly consistant between apps. On the other hand, we could go for both ergonomics and consistency by using MS Office's Ctrl-Y. Note that I am not recommending it. I think keeping redo the way it is in 1.2 is the best policy. BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to redo. There we go, between that and tradition, we have all the justification we need. ;) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Difference between 1.2 .gih and 1.3 .gih files?
On 23 Sep 2003, Jeff Trefftzs wrote: On Tue, 2003-09-23 at 04:10, Michael Natterer wrote: Just open the failing brushes with File-Open and save them again. The plug-in is still able to read these files and will save the new format. Thanks to Dave, Simon, and Mitch for the prompt replies. I'm converting the old brushes now. Hmm, this should make it into the release notes. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshot plug-in status
On Thu, 11 Sep 2003, Alan Horkan wrote: I only ask that you take a moment and consider if there might be a way to make things faster for the user which is where speed really counts. Could some of the handling of the system clipboard be done automatically and only when needed to mitigate the speed tradeoff? If is impractical fair enough, I was just asking because the code was being changed anyway. It seems to me that using the system clipboard, but using the internal cut and paste instead of the system functionality whenever it is detected that the sender and reciever are the same process would be the best solution. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for protesting against softwarepatents in Europe
On Tue, 26 Aug 2003, Raphaël Quinet wrote: Well, this may be a bit controversial, I don't think that there is any disagreement about software patents among the major gimp developers. but I thought about supporting the demonstration against software patents in Europe by replacing the GIMP home page by the following page: http://www.gimp.org/nopatents.html I prepared that page a couple of days ago, but now I see that the announcement about the protest has been posted on Slashdot and several other sites. So maybe it is time to put it on the home page, unless most people here are against this kind of online protest. The GIMP web site is in the U.S. so this may not be so relevant. But on the other hand, several of the most active GIMP developers are living and working in Europe. I doubt anyone cares where the server is physically located. I'm an USsian, and I care about software patents in europe (as well as the US). Is anybody against that kind of action on the GIMP web site? No, I'm very much for it. If there is any strong opposition against it, then there is no need to have a long debate: I will simply forget about it. Otherwise, I would like to replace the home page of www.gimp.org later today (let's say in three or four hours). Before doing that, please correct two nits: 1. Change well-documented to well-researched or well-written, depending on what you meant. Well-documented is not idiomatic English. 2. Make the no ePatents graphic point at something. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Documentation of the GIMP-1.3 internals
On Mon, 18 Aug 2003, Sven Neumann wrote: Hi, there is something I hacked up during GimpCon and I thought it might be of interest to some of you although it's not yet finished (and perhaps YEY! (This is a very good thing.) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 21 Aug 2003, Leonard Rosenthol wrote: At 1:47 PM +0200 8/14/03, Sven Neumann wrote: I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. Well, that pretty much settles that discussion... Not really, since that reasoning is based on an untruth. And even if it wasn't, it's a logical fallocy to assume that because no graph-capible proposal was made, that XML was the only possible way of representing a graph in a file format. According the library that reads and writes the new format, GEGL should provide this functionality. Requiring an application to incorporate all of GEGL in order to read/write an XCF file is, in my opinion, a recipe for it not getting used by other applications. (and I say this as one of those other application developers). That is why I suggest both a lightweight library and gegl routines for it. Actually, gegl can use the lightweight library for the loading. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Thu, 14 Aug 2003, Øyvind Kolås wrote: * Adam D. Moss [EMAIL PROTECTED] [030814 09:59]: Stephen J Baker wrote: So, I think what is needed to make a reliable file format is to provide a well written library for reading and writing the files that's freely available and properly maintained on every modern platform FROM DAY ONE. I agree with this -- I think it's really important. [SNIP] but in any case it makes sense to library-ise the XCF load/saver just from a technical abstraction standpoint.) Which is why I in an earlier mail suggested developing a GEGL file format that gimp could extend and use a subset of. By doing it this way, gegl would be the aforementioned file loading, and compositing library,. (e.g. if an application needs to load an XCF2 file, but don't support layers, the library would be capable of compositing it, putting the logic to do compositing of layers, layer groups, adjustment layers, u8, u16, float, double, cmyk, rgb, ycbcr and spotcolors into a file loading library,. makes very little sense It actually makes a lot of sense to have GEGL support loading XCFs. It would probably be a good idea to have a separate library as well, for those apps that already have their own compositors and don't want to have another one as well. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Adam D. Moss wrote: Nathan Carl Summers wrote: On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. That's good to know, it helps me out with some of my own stuff... How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? Yup. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Wed, 20 Aug 2003, Leonard Rosenthol wrote: At 11:42 PM + 8/13/03, Phil Harper wrote: well, it'd be interesting to see if Adobe added XCF to Photo$hop, after all, GIMP is the competition, it wouldn't be in their interests to support a multilayered image format that it controlled by someone else(although they might support PSP, i don't know haven't checked.) They support a number of formats that they don't control - because they are standard formats that their customers are requesting. But today XCF isn't one of them, and probably won't be for a while. AFAICT, there is nothing stopping Gimp developers from creating a potatoshop plugin that can read XCF. it'd be nice if your app could read and render a flat version of the image if you don't support layers i supose, this is an interesting one since all these different target apps will handle things like layermodes differently, and some wouldn't even be supported. EXACTLY my point! Whatever file format we end up with, we need to accept that not all consumers of that file format will be able to support 100% of the features (perhaps not even GIMP itself). no, that simply wouldn't be flexible enough, surely, i mean you could have extra data about how do use the layers in the TIFF but if those aren't recognised by other readers you just get a strange result and a confused decoder. You could get that just as easily with XCF when a given consumer/reader doesn't support 100% of the features of the format... With a PNG style format, this becomes much less of an issue. First, PNG requires all readers to be able to interpret a core subset -- anything that can't interpret it violates the standard. Second, all chunks are tagged optional (meaning that they can be safely ignored if not understood or mandatory (in which case the reader will give up if it doesn't understand the chunk.) This means that a baseline PNG can be read by any compliant program (hello, IE!) without problem, and any extensions will either degrade gracefully or cause an error, but in no case will the decoder become confused and return a strange and wrong result. In this way, for example, someone could create a PNG chunk that indicated that the data was in Lab space, and a decoder that didn't recognize that feature would just give up instead of returning some garbage where the red channel gets luminence, etc. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 14 Aug 2003, Sven Neumann wrote: [Note: quote blocks have been reordered for clarity] Hi, I'd like to mention that none of the proposed formats except the XML approach would be capable of supporting the stuff we want to add to GIMP with GEGL. On the contrary, my proposal would handle graphs as easily as XML would. We are not talking about simple layer lists or trees any longer but we need to be able to store complex processing intructions with each node. XML seems to be the only reasonable choice here. My proposal is tree-based just like XML. And you can do graphs in it exactly the same way it is done in XML -- by labeling elements of the tree and using the labels to denote the links between the nodes on the graph. I don't think any existing format could be sanely extended to support complex render graphs as will be introduced with GEGL. Depends on what you mean by sanely extended. Of course it is unlikely that you could create something that interoperates well with existing applications, but there is nothing inheritly wrong with takiing an existing format, or more than one, and using it for the basis of the new XCF. According the library that reads and writes the new format, GEGL should provide this functionality. The basic file format should be defined by GEGL and GIMP will only add some user interface specific things in its own namespace. I can imagine that parasites, at the minimum, would also go in the GIMP namespace. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. This seems like a good proposal. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. Right. To be mmappable, the format should be aligned. I think with careful design, there won't be too much overhead from this. When I wrote that the example was just a rough sketch, part of what I meant was that I didn't pay too much attention to bit sizes and alignment, because that would have been premature optimization. One issue with alignment is which platform's alignement rules should be used. I think a good common-denominator format can be found. It won't get the wierd ones, of course. I work on a Cray, and nothing follows cray's alignment rules. :) image data chunks should use png-style adaptive predictive compression. They should also use adam-7. I would avoid compression inside the format. Files can be compressed as a whole It does complicate in-place image manipulation, true. OTOH, you can get much better lossless compression using image-specific techniques such as predictive compression than you can using general purpose techniques. and IIRC Adam7 is about interlacing, not compression, dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. Well, working a scaled-down version of large files is an important optimization. It's true that not all image manipulation functions can credibly be approximated with working on a scaled-down version, but that's for the gegl people to worry about. My guess is that it will be easier to use interlaced data than true scaled-down images, and the savings in terms of computational time and pipeline flexablity will be worth it. PNG compression is the one provided by zlib PNG's use zlib compression on the overall file, but the entropy is first significanty reduced by using predictive encoding. It's not the same as just running gzip on raw data. and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. True. Letting other apps do it means those apps could be general, reducing work load. Of course, but we should not sacrifice functionality for convenience. :) Or better, custom, but once the look of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Conformance testing is very important. That is a good idea. Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. This will have to be worked out. CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... Both have their plusses and minuses. This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. Good idea. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7
[Gimp-developer] GimpCon RFC: Portable XCF
Several XCF formats have already been proposed; why should I propose another? It seems to me like the existing proposals have all missed the main point. While they have nice properties for certain extreme cases, they miss the boat when it comes to the main point of a graphics format, which is to efficiently store (and load) graphical information. This has lead to proposals that are neither elegant nor simple; instead they are cumbersome, with redundant, and superficial information stored, along with potential for confict between different sections of the file. But rather than detail these problems, let me suggest my own solution. Let us start with an existing graphics format, for inspiration if nothing else. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Before we continue, though, allow me to ennumerate what charactoristics the Gimp native format should possess, in no particular order: 1 lossless 2 portable between architectures and programs 3 extensible 4 capable of representing trees and graphs 5 recoverable from corruption 6 fast random access of data 7 able to support many color depth and spaces 8 able to represent any state that gimp maintains 9 fast loads and saves 10 compact 11 good compression of graphical data PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. Extensablity: PNG supports some degree of extensiblity, but the namespace available is quite small, being only four letters. While we could use the same chunk type name for all of our additions, say 'GIMP', and then have the first field in the chunk contain which kind of chunk it really is. But this is an inelegant hack. Capablitity of representing trees and graphs: Obviously, png's minimal extension facilities could be used to implement chunks that envelope an entire tree of chunks, but this would be difficult to reconsile with PNG's current order-based approach to metadata association, and would be awkward for GIMP-aware and non-GIMP-aware PNG readers alike. Corruption Recovery: PNG has good corruption detection, but little to facilitate corruption recovery. Representation of GIMP state: see extensibility. While PNG's faults aren't serious, we can do better. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. Such a format would bear strong resemblence to both PNG and XML. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: portable xcf file version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes CHUNK: chunk start, manditory - 2 bytes xcf-layerstack total size - 4 bytes size - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-colorspace total size - 4 bytes size - 4 bytes xcf-sRGB chunk end (flags) - 2 bytes xcf-colorspace 2 (depth) - 1 byte crc32 - 4 bytes SUBCHUNK: chunk start, manditory - 2 bytes xcf-layer total
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Sat, 9 Aug 2003, Leonard Rosenthol wrote: I see fast loads as an absolute requirement. Then we need to also look at the GIMP itself and what can be done there. Of course. Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. Having load on demand via random access is what will really get you the fast loads!! If you don't solve that, then any work on the file format will be a waste towards your goal. Exactly, it's a big priority. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house. Agreed, but what does this really mean in real world terms. Are we willing to sacrifice functionality to get a couple of bytes here and there? The image data is the big hit in this format - the structure will end up as a small fraction of any XCF file. We certainly shouldn't sacrifice high-priority stuff for size, but size should still be a consideration. * incremental update just update a single layer w/o rewriting the whole file! This seems like an excellent goal. It seems like you are suggesting a database-like format. Not necessarily. You should be able to do it with any format with a good catalog system, but some will be easier than others. How would you handle resizes? Either we could do immediate compaction or garbage collection. Both have their disadvantages. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. How about a TIFF-like directory chunk at the beginning (except hierarchical)? That would be one solution - sure. Can you think of a better one? I just think that doing a full reinvent of an image format seems like a waste of time. Let's look at Photoshop... Photoshop is able to do 100% round-tripping of ALL of its functionality in three formats - PSD, TIFF and PDF. PDF is done via throwing their private info into an undocumented blob - so it doesn't really count. So let's look at the other two. Both PSD and TIFF are rich image formats that already address most of your original list and are well defined and supported by many existing tools (including GIMP itself). Both are extensible (TIFF more so) and would allow for additional blocks to meet our needs. Is there a good reason not to use either PSD or TIFF as the native format? The only possible argument for either is that Adobe controls them both. However, I would state that TIFF has pretty much taken on a life of its own outside Adobe (via libtiff). I think the goal of the XCF redesign is to become the de-facto standard for interchange of layered images. Certainly one aspect of this is freedom from Adobe, but in addition to being an open standard, it needs to be a standard that people have confidence in. In other words, any XCF reader should be able to read any XCF writer's output. A layered TIFF by that name wouldn't cut it, because most tiff readers don't support layered images. Of course, we could always use TIFF internally but call it XCF. We might want to change the magic number as well. I have no problem with basing Portable XCF on TIFF. It seems to be well designed without really being too overdesigned. On the other hand, I think there are a few improvements that we could make to make it better for the purposes of GIMP. /me wonders if the CinePaint people have any thoughts... Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Tue, 12 Aug 2003, Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? Yup. The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. Well, since my day job is working with a non-IEEE machine, I can tell you about that pain first hand. It probably took about three days to write conversion functions between the native format and IEEE float and double. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
On Thu, 14 Aug 2003, Sven Neumann wrote: Hi, I never understood the reasoning for this discussion anyway. IMHO the format that Nathan suggested seems like something from the dark ages of file formats (where TIFF and the like originated from). PNG is something from the dark ages? I haven't heard a single good argument for it except that it can do most of the things that the XML/archive approach can do. s/most/all, and many other good things besides. There was however nothing mentioned that it can do better. Or did I miss something? XML is a text markup language. If the designers thought of using it for raster graphics, it was an afterthought at best. XML is simply the wrong tool for the job. The XML/archive idea is the software equivalent of making a motorcycle by strapping a go-cart engine to the back of a bicycle. It will work, of course, but it's an inelegant hack that will never be as nice as something designed for the job. But to answer your question: 1. Putting metadata right next to the data it describes is a Good Thing. The XML solution arbitrarily separates human readable data from binary data. No one has yet considered what is to be done about non-human readable metadata, but I imagine it will be crammed into the archive file some way, or Base64ed or whatever. Either way is total lossage. 2. Imagine a very large image with a sizeable amount of metadata. If this seems unlikely, imagine you have some useful information stored in parasites. The user in our example only needs to manipulate a handfull of layers. A good way of handling this case is to not load everything into memory. Say that it just parses out the layer list at the start, and then once a layer is selected and the metadata is requested, it is read in. With the XML proposal, the parser would have to parse through every byte until it gets to the part it is interested in, which is inefficient. Frankly, this wouldn't be feasable. Only two crappy ways would be possible to get around this: store everything in memory (hope you have plenty of virtual memory!) or write out a temp file with the metadata in it, for later use, and in a random-accessable format. If you're going to do that, why not do it right the first time and save yourself the trouble? 3. None of the current suggestions for archive formats do a good job with in-place editing. AR can't even do random access. Zip can do an ok job with in-place editing, but it's messy and often no better than writing a whole new file from scratch. This means that a program that makes a small change to a file, such as adding a comment, needs to read in and write a ton of crap. 4. Implementing a reader for the XML/archive combo is unnecessarily complex. It involves writing a parser for the semantics and structure of XML, a parser for the semantics and structure of the archive format, and a parser for the semantics and structure of the combination. It is true that libraries might be found that are suitable for some of the work, but developers of small apps will shun the extra bloat, and such libraries might involve licensing fun. The semantics and structure of the combination is not a trivial aspect -- with a corrupt or buggy file, the XML may not reflect the contents of the archive. With an integrated approach, this is not a concern. 5. Either the individual layers will be stored as valid files in some format, or they will be stored as raw data. If they are stored as true files, they will be needlessly redundant and we will be limited to whatever limitations the data format we choose uses. If we just store raw data in the archive, then it's obvious that this is just a kludge around the crappiness of binary data in XML. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
On Mon, 11 Aug 2003, Adam D. Moss wrote: IIRC, the Loki guys. Some ramblings a few years ago on the problems of interoperability of game data between windows/mac/linuxx86/linuxalpha/etc over network and on disk. They made a special point of saying something like 'never, ever serialize floats' and it sounded like the voice of experience. Java doesn't seem to have a problem with it. Even poor fools like me who are working on VM's for machines with non-IEEE floats don't have too much of a problem. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
Good to get some high-quality feedback. On Sat, 9 Aug 2003, Leonard Rosenthol wrote: At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote: Let us start with an existing graphics format, for inspiration if nothing else. OK. The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available. Well, I would argue that TIFF has the crown... However, PNG is an excellent standard, regardless. Good point. It can't hurt to take a look at several graphics formats and take the best parts from each of them. 4 capable of representing trees and graphs Trees, yes - for things like layers. But why a graph?? GEGL supports graphs. If we use GEGL graphs, we'll need a representation ;) 5 recoverable from corruption 6 fast random access of data 9 fast loads and saves 10 compact Good goals, but not a requirements. Perhaps you should separate those two things out... I see fast loads as an absolute requirement. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house. Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. A VIPS-like demand-driven pipeline would increase gimp responsiveness a lot. And I can think of other goals that I'd like to see: * incremental update just update a single layer w/o rewriting the whole file! This seems like an excellent goal. It seems like you are suggesting a database-like format. * rich metadata (this may be your 7, but needs to be spelled out) Well, that was what I meant by extensibility and the ablity to represent anything GIMP can. I agree that this is important. PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail. I would argue that PNG doesn't do 7 - it has no native support for CMYK, for example. (but yes, it does RGB, Gray and indexed). And for comparison, I would offer that TIFF does the same list and REALLY does 7, including CMYK, Lab, ICC and Spot color spaces. It's extensibility is similar to PNG (in fact, PNG's chunks were modelled on TIFF chunks). Indeed. A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8. I'd add 9, just being in XML doesn't mean it can't be fast. I guess if you used raw image data instead of base64 or something similar Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10. But gzipping the entire XML block would then pretty make 6 impossible unless you want to seriously increase in-memory requirements. right. An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11. An archive (zip, tar, ar) with XML metadata plus raster image data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11. 5 10 are related to the archive format of choice since some are better at these than others. But yes, I suspect that it would probably be a bit slower. Requirement 6 is fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is. But the XML is just a catalog of what's in the archive (at least in my proposal). So you read the catalog up front and then use it to quickly find the part of the archive you want and viola - fast random access to data. It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format. That's what TIFF and PNG were designed for. Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions. How about a TIFF-like directory chunk at the beginning (except hierarchical)? At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. This is a common technique in many file formats for corruption detection. It works. One of the major advantages of this hybred technique is that if an implementation does
Re: [Gimp-developer] A fresh pair of eyes.
On Thu, 31 Jul 2003, Sven Neumann wrote: Hi, Jay Cox [EMAIL PROTECTED] writes: You have a point, I dont much like the proposed solution though. Any other solution would probably be too complex to implement at this point in the release cycle. We finally got rid of the palettes being copied to the users dir and now you want to copy all files? You must be kidding. Not necessarily related, plus how was Jay supposed to know about that? Secret gimp omniscence sauce? He's been back for what, a day? and you expect him to know everything that has been done... But I think that having a list of undesired pallete/gradient/brushes/textures/plugins(?)/etc saved in the gimprc file and having the interface not show them would be the best way of doing things, and shouldn't be that hard to implement. You could even have a button to make them visable again. If that doesn't seem feasable, at least we should ln -s the entries instead of copying them. But that will not work on wincrap :( Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A fresh pair of eyes.
On 30 Jul 2003, Jay Cox wrote: This was the first chance I've had to spend quality time with gimp in several years. After this long separation from gimp, I feel that my eyes are pretty fresh. Whho! I think I speak for all of us old fogies when I say, Welcome back! Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
On Sat, 26 Jul 2003, Adam D. Moss wrote: 2) It might be argued that the basic dependance and interconnection of a not-GPL-compatible plug-in with the GPL GIMP core via libgimp and the wire protocol is intimate enough that the two cannot be considered independent and separate works. (Yeah, really.) From my reading of the exogen---oh, I don't know how to spell that word--of the GPL, that is mitigated by the fact that there exist (existed?) programs other than gimp that can use gimp plugins. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On Fri, 18 Jul 2003, Sven Neumann wrote: Hi, I'd like to inform you about our plans for the GIMP 2.0 release. First of all, Mitch and me are not willing to raise the 2.0 versus 1.4 discussion again. Gimp is more than Mitch and me, isn't it? Both sides have expressed their arguments. We took quite some time to think about all of them and to reconsider our decision. We came to the point that it should be called 2.0. It's just a number, so please, before you start the discussion again, think twice if it's worth it. It really is worth it. We will loose *A LOT* of trust with our users if we disappoint them. There are many more than a trivial number of people whe expect CMYK, 16-bit, etc in gimp 2.0. These people are our *MOST ACTIVE USERS* and those who are waiting for gimp to have these features. Any time in the past two years that someone has asked on IRC or mailing lists when gimp will have these features. The second group mentioned I worry about more; the people who need these features, when they hear that 2.0, will check it out and sorely be disappointed. I don't know how well a reference to the story of the Boy Who Cried Wolf communicated cross-culturally, but I can tell you that once lied to once, these people will probably not trust the gimp developers again. They will go elsewhere. This is a big loss to us -- imagine what contributions would come to gimp if people who professionally need features like deep images would be using the software. The lack of deep image support up to this point has already cost us a lot; those who flocked to the program formerly known as FilmGimp would have flocked to us instead. Yes, calling the new release 2.0 is a LIE. I cannot emphasize this strongly enough. It is a lie because we have told many, many people what 2.0 will do. To release a 2.0 without these features is pure misrepresentation. It is much too late to put the worms back into the can. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
On Wed, 16 Jul 2003, Alan Horkan wrote: On Wed, 16 Jul 2003, Sven Neumann wrote: Date: Wed, 16 Jul 2003 13:57:18 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Menubar in fullscreen mode [Re: [Gimp-developer] the user installer] Hi, Alan Horkan [EMAIL PROTECTED] writes: Go to the menu and toggle View Menubar. How did you miss this? (Gimp 1.3.4) I had the menubar turned on I expected to still have the menubar in fullscreen mode. I don't understand your answer but just to clarify my sentence I will describe the behaviour of fullscreen mode for you. By default, if you I expected the menubar to stay on in fullscreen mode. I just wanted to point out that my expectations were different from what happened, which I realise is unneccessary information from your point of view. (I only have a recent build at home so it takes me a while to check these things). This actually could be a serious usablity issue, since a user who has the menubar on (which a distro might set as default) after going to fullscreen mode might not be able to figure out how to get the menubar back, or even how to return to windowed mode. (bah, watching actual real users in usablity tests at work stumble around when using really fairly simple interfaces has caused me to loose all faith in the intelligence of humanity. Then again, our users are actual real users, too.) Seriously, though, it would be a much better behavior to keep the menubar when the window is made fullscreen. A user that prefers a menubar will probably prefer one in fullscreen mode also. Besides, a user with a clue will be able to turn off the menubar anyway. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
On Wed, 16 Jul 2003, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Fullscreen mode was added to be able to view the image in a neutral environment w/o being distracted by any user interface elements. Adding a menubar would completely ruin this effort. I'm sure any UI expert you talk to (or really, anyone who thinks about it for twelve seconds) will tell you that putting up a fullscreen image without any obvious method of exiting is likely to inspire panic in the user, who doesn't know how to get out. The fact that you can edit the image in full-screen mode and that we even decided to allow you to tweak what gets hidden and what not is just an additional nicety and I'm actually tempted to remove it. Don't! Fullscreen mode is useful for more than that. It is nice when working on a large image, or a smaller image with high magnification, to get rid of superfluous stuff like the window decoration, but in that case the user may still want to use of the stuff that would otherwise be hidden. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Fri, 11 Jul 2003, Steinar H. Gunderson wrote: On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote: I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon). How hard would it be to write an autoconf test for that? Rockwlrs ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
On Fri, 11 Jul 2003, Leonard Rosenthol wrote: But the fact is that you're going to end up having to Base64 encode all the image data - which will blow the physical file size WAY out of proportion. And if don't do that (ie. attempt to leave in binary data), then you are violating the spirit of XML's design goals. Honestly I can't think of a way to put image data into a file format at all that wouldn't violate SGML's design goals. XML may differ in some aspects from SGML, but the fact is that SGML was designed to be a markup language for documents written in human languages, and the design decisions that created that also make storing binary in *ML cumbersome. GIMP needs a file format that is extensible, and a native representation for tree structures is essential, but there are plenty of ways to do this other than the XML method. Storing images, which ar almost all binary data, in true XML is a lesson in inefficiency. Oh wait, I take it back. I can think of a image format that retains the spirit of XML: gimpimage commentCreated by the GIMP!/commment layers colorspace=rgb bitdepth=8 layer width=6 height=6 row pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / /row row . . . /row /layer /layers /gimpimage Determining whether this is a good format is left as an exercise to the reader. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
On Fri, 20 Jun 2003, Hans Breuer wrote: I'm about to give it another try with current cvs code base, but before I would like to get some information to avoid (if possible) fast rotting bits. In short the approach (more info in bugzilla) : - Intercept every PDB call if a macro recorder instance is running. The cvs version of Libpdb already provides a flexible mechanism for intercepting pdb calls. I designed it with macro recording in mind. (try to guess the call stack depth to avoid recording functions called by a plug-in) I had a solution to that problem, but I don't remember what it was anymore ;( - deliver PDB calling information to the temp_proc installed by the macro recorder - extend the Gimp Protocol to allow to deliver typed parameter information after an interactive plug-in has fininished it's work. - long-term : replace the gimp_set_data/run-with-last-values mechanics with the typed parameter information I'll illustrate the way I imagine this will work with libpdb in an example: Say that the user calls the Gausian Blur IIR plugin. Gimp calls the pdb function gimp_plugin/gaussian_blur_iir/interactive, which returns an argument list with the user's desired parameters. Gimp then calls gimp_plugin/gaussian_blur_iir with the appropriate values. The macro recorder catches the call and records it. Almost all of the work necessary for this situation has been done and is present in the CVS version. - build a first full blown script recorder in the prefered scripting language (mine is Python) It would be nice eventually to have a language-neutral frontend that feeds ASTs to the language-specific backends. - maybe : allow to let plug-ins register default parameters along with their procedures This would be a good addition. - use default parameters to reduce 'forced dialogs', i.e. make them optional. Best example is png-save where the user - at at least I - almost never changes any values. Sounds nice, but how would the user change the values when needed? Now for my questions : - are there further huge changes planned for the plug-in/pdb code (time involved to maintain my patch) ? Libpdb will be used in the next version of gimp. It probably makes the most sense to concentrate on implementing this functionality there. We have already made a good start on it. - is the outlined approach mature enough to be at least considered for acceptance if I have a first working version ? It would certainly be accepted in libpdb. ;) Nathan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
My vote is for 1.4. Otherwise, the Slashdot headline we will get is GIMP 2.0 Fails to Deliver Promised Features Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] running gimp withou't make install?
On Sun, 1 Jun 2003, Joao S. O. Bueno wrote: But what I do need now is a faster way to go from edit code to running gimp. Make Install asctually eats out a lot of time on my system. Is it possible to run the gimp-1.3 binary generated from make straight, without make-installing it? Of course you can, as long as all the data is installed in the right places (which the first make install took care of for you.) How can it be done? cd app ./gimp-1.3 Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Thu, 3 Apr 2003, Ernst Lippe wrote: On the contrary, there appear to be lots of acceptable names. I am suprised that nobody has suggested YetAnotherGimpPreview :) How about GimpPluginView? GimpSample? GimpTheWidgetFormerlyKnownAsPreview? GimpFancyPreview? GimpMcPreview? GimpExample? GimpView? Actually, GimpThumbnail is more reasonable for the core widget's name than it is for the plugin widget's name. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Tool API [LONG!]
Here is a list of all the symbols currently used by the current tools, courtesy of nm tools/*.o paint/*.o | cut -b 10- | grep ^T | cut -b 3- | sort | uniq stdlib, glib, gdk, pango, and gtk calls have been eliminated from this list. The big things that stand out are accessing the global the_gimp, and calling tile and tile manager functions. the_gimp should not be accessed directly, and tile_manager is probably too ugly for tool developers with weak stomachs. Rockwalrus active_color add_alpha_region apply_mask_to_region blend_region brightness_contrast_lut_setup brush_scale_mask brush_scale_pixmap color_balance color_balance_create_lookup_tables color_balance_init color_balance_range_reset color_pixels color_region combine_mask_and_region convolve_region copy_region curves_calculate_curve curves_channel_reset curves_init curves_lut_func find_mask_boundary floating_sel_anchor floating_sel_relax floating_sel_rigor gdisplays_check_valid gimp_base_config_get_type gimp_bezier_stroke_extend gimp_bezier_stroke_get_type gimp_bezier_stroke_new gimp_brush_get_spacing gimp_brush_get_type gimp_brush_select_brush gimp_brush_want_null_motion gimp_bucket_fill_mode_get_type gimp_channel_add_segment gimp_channel_invalidate_bounds gimp_channel_new_mask gimp_channel_ops_get_type gimp_channel_value gimp_color_area_get_type gimp_color_area_new gimp_color_area_set_color gimp_color_panel_get_type gimp_color_panel_set_context gimp_config_connect gimp_config_copy_properties gimp_config_deserialize gimp_config_disconnect gimp_config_duplicate gimp_config_reset gimp_config_serialize gimp_container_add gimp_container_add_handler gimp_container_get_child_by_name gimp_container_remove_handler gimp_container_thaw gimp_context_copy_properties gimp_context_define_properties gimp_context_get_brush gimp_context_get_display gimp_context_get_gradient gimp_context_get_opacity gimp_context_get_paint_mode gimp_context_get_pattern gimp_context_get_tool gimp_context_get_type gimp_context_new gimp_context_set_background gimp_context_set_display gimp_context_set_foreground gimp_context_set_parent gimp_context_set_tool gimp_context_tool_changed gimp_crop_type_get_type gimp_cursor_new gimp_devices_get_current gimp_dialog_create_action_area gimp_dialog_factory_dialog_raise gimp_dialog_get_type gimp_directory gimp_display_config_get_type gimp_display_coords_in_active_drawable gimp_display_flush gimp_display_flush_now gimp_display_get_type gimp_display_shell_draw_guide gimp_display_shell_get_type gimp_display_shell_scale_by_values gimp_display_shell_selection_visibility gimp_display_shell_set_cursor gimp_display_shell_set_override_cursor gimp_display_shell_transform_xy gimp_display_shell_transform_xy_f gimp_display_shell_unset_override_cursor gimp_display_shell_untransform_xy gimp_dock_get_type gimp_double_adjustment_update gimp_drawable_blend gimp_drawable_bucket_fill gimp_drawable_bytes gimp_drawable_calculate_histogram gimp_drawable_data gimp_drawable_get_color_at gimp_drawable_get_type gimp_drawable_has_alpha gimp_drawable_height gimp_drawable_is_indexed gimp_drawable_is_rgb gimp_drawable_mask_bounds gimp_drawable_offsets gimp_drawable_push_undo gimp_drawable_transform_cut gimp_drawable_transform_matrix_perspective gimp_drawable_transform_matrix_rotate_center gimp_drawable_transform_matrix_scale gimp_drawable_transform_matrix_shear gimp_drawable_transform_paste gimp_drawable_transform_tiles_affine gimp_drawable_transform_tiles_flip gimp_drawable_type gimp_drawable_width gimp_enum_option_menu_new gimp_enum_radio_frame_new gimp_get_current_context gimp_get_mod_name_alt gimp_get_mod_name_control gimp_get_type gimp_get_user_context gimp_gradient_get_color_at gimp_gradient_type_get_type gimp_gui_config_get_type gimp_help_connect gimp_help_set_help_data gimp_histogram_box_get_type gimp_histogram_box_new gimp_histogram_calculate gimp_histogram_channel_get_type gimp_histogram_free gimp_histogram_get_count gimp_histogram_get_mean gimp_histogram_get_median gimp_histogram_get_std_dev gimp_histogram_nchannels gimp_histogram_new gimp_histogram_view_get_channel gimp_histogram_view_get_type gimp_histogram_view_new gimp_histogram_view_set_channel gimp_histogram_view_set_histogram gimp_histogram_view_set_range gimp_hls_to_rgb_int gimp_image_active_drawable gimp_image_add_guide gimp_image_add_hguide gimp_image_add_layer gimp_image_add_vectors gimp_image_add_vguide gimp_image_apply_image gimp_image_contiguous_region_by_seed gimp_image_crop gimp_image_crop_auto_shrink gimp_image_delete_guide gimp_image_find_guide gimp_image_floating_sel gimp_image_flush gimp_image_get_active_layer gimp_image_get_background gimp_image_get_color gimp_image_get_foreground gimp_image_get_type gimp_image_map_abort gimp_image_map_apply gimp_image_map_clear gimp_image_map_commit gimp_image_map_get_color_at gimp_image_map_new gimp_image_mask_boundary gimp_image_mask_bounds gimp_image_mask_clear gimp_image_mask_float gimp_image_mask_is_empty gimp_image_mask_select_by_color
Re: [Gimp-developer] Plug-in preview API proposal
On 31 Mar 2003, Sven Neumann wrote: I'd even prefer to have everything that is related to this widget be under the same namespace. Unfortunately GimpPreview is already taken, so we either need to change the name of the core object or find a new one for the plug-in preview. (off-the-cuff) Perhaps GimpThumbnail? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] blizzards, mononucleosis, and tool plug-in TODOitems
On 30 Mar 2003, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: What needs to be done for the next release is a major cleanup of the tools. I agree. Part of this cleanup should be a proper documentation on how to write a GIMP tool. Providing source for a sample tool was supposed to be on the list I sent. I don't know why I didn't remember to put it on last thing. I believe that it doesn't make sense to even think about pluggable tools before this has happened. While we should have a good specification of the tool api, not thinking about plugging issues would be counterproductive. Many of the existing issues are related to the nonextensiblity of the current api. I'd rather start the tool cleanup by moving GimpToolControl back into the core I think that we should get the advice of the win32 developers because of the braindead behaviour of winbloat's dynamic linker before we move anything. Note that tool plugins will need to make calls to GimpToolModule code and GimpToolControl code and who knows what else. and I'd like to remove the cheesey hacks that were added all over the place. Which cheesey hacks are you refering to? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] blizzards, mononucleosis, and tool plug-in TODOitems
I'm sorry that I haven't been able to do much GIMP participation in the last several months. I don't want to bore everyone here with details of my personal life, so suffice it to say I haven't been able to spend much time hacking or even replying to email. I regret any inconvenience this has caused. The last time I checked, in-process tool plugin loading worked with only a handful of mild issues to be resolved. I have no doubt that it can be in perfect working order in less than two weeks. Out-of-process tool plug-ins are an entirely different matter. Implementing them would still require a fair amount of work. It would also involve some changes to the gimp protocol which, while I would not really term them to be kludgy, add more complexity in places they shouldn't be. Given our time constraints, that in-process tool plug-ins already work, and that out-of-process tool plug-in communication can be handled much more cleanly in libpdb (which I sincerly hope will be used in GIMP 2.0), I would not be opposed to the removal of out-of-process tool plug-ins from the list of goals for 1.4. While I still believe that out-of-process tool plug-ins are the Right Thing to do, they can wait for 2.0. Regardless of whether out-of-process tool plug-ins make it in 1.4, I now feel that the best developmental proceedure is to make in-process tool plug-ins work as well as possible. Without further ado, here is a list of things that must be done to make tool plug-ins useful: * the loop in tools.c that loads tool modules should be uncommented and moved before the loading of the built-in tools, so that they appear last in the toolbox. (perhaps it would be good to allow tools to be reordered by the user.) * cheesey_module_loading_hack needs to stop leaking memory and handle errors sanely. It could also use a better name. * a dialog box should be able to show the tool modules loaded, and tool modules shoulde be loadable and unloadable at runtime. Specifically, any tool not currently being used should be unloadable. That would make tool plug-in development significantly less painful. The current module dialog would be a sensible location for this additional functionality. * tool plug-ins need the ability to supply a custom icon. Themes should be able to supply a replacement if they know about that particular tool plug-in. * likewise, tool plug-ins should be able to supply their own mouse cursors. * the back-end pixel-crunching code usable by both the gui and pdb interfaces should be better separated from the interface-specific code. I have long felt that the paint tool refactoring is a good example of how this can be better accomplished, and feel that similar measures would be useful in the rest of the tools. * tool plug-ins need a mechanism to expose their functionality to the PDB. I will file these items in Bugzilla if consensus is that this is the best course of action. I look forward to your comments. Respectfully, Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpToolGui
On 30 Jan 2003, Sven Neumann wrote: Hi Nathan, when I updated my gimp tree this morning I was surprised to see this commit: 2003-01-30 Nathan Summers [EMAIL PROTECTED] * app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended from GimpObject to be used to separate GUI from logic. Heavily inspired by GimpDrawTool. Not actually used by anything yet. Would you mind to explain what you have in mind here? Not at all. I think I posted this before, but basically, I'd like to have a GimpToolGui class and a GimpToolLogic class, which both inherit from GimpObject. The appropriate GimpToolInfo structure would then have to have the GType for both the gui and logic classes. A GimpTool can then be created that contains a pointer to both a GimpToolGui and GimpToolLogic. Looks a lot like the GimpDrawTool actually and I'd like to hear about your plans for the tools since of course Mitch and me have a plan as well. I must admit that we haven't told you about it neither but we are actively working towards a massive tool redesign for quite some time now. I would love to hear what you have in mind. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Just managed to build HEAD GIMP with autotoolson Win32...
On 31 Dec 2002, Sven Neumann wrote: Hi, Tor Lillqvist [EMAIL PROTECTED] writes: Hmm. You mean libgimptool isn't really used at all currently? It would be helpful to have some short READMEs in the libgimp* directories (especially libgimpwidgets, libgimpproxy and libgimptool) telling what the purpose of the libraries are, and what executables link to them. [snip] I think that Nathan should explain the purpose as well as the current state of libgimpproxy and libgimptool. To explain the purpose of those libraries, here is a diagram: ----- | gimp protocol|| tool-safe-mode |--|gimp| ||| ----- plug-in process core process libgimptool is used by both gimp and tool-safe-mode. It contains the code that is used by both processes, and includes classes like GimpToolControl. All code in libgimptool is tool-related. GimpTools in the core use objects like GimpDrawable and GimpDisplay that are accessable by plug-ins through the plug-in api, but with a very different interface. libgimpproxy is autogenerated from parts of the definitions of the objects in the core (to maintain binary compatiblity), and will contain the code necessary to proxy the objects by making appropriate calls over the pdb. Libgimpproxy is only used by tool-safe-mode. (FWIW, tool-safe-mode is called that because a tool plug-in can't crash the core process.) I put tool plug-in work on the back burner when I graduated, moved, and got a job. Right now I am on vacaion in another state, but when I get back I should have some time to work on it again. I have given up on making UML diagrams of my plans because of the lack of any decent free UML program. Basically, I would create a GimpToolGUI class based loosely on GimpDrawTool. GimpToolCore would contain the essential stuff from GimpTool, leaving the core-specific stuff in the GimpTool class. Everything would be modeled on the system that Mitch designed for the paint tools. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] A more flexible last values system for the pdb
Note: this message is crossposted to gimp-developer because several developers interested in libpdb are not subscribed to libpdb-developer. Please do not send followups to gimp-developer. I've been thinking about a better way to implement the RUN_WITH_LAST_VALUES functionality in libpdb. The current method is annoying and kludgy. Depending on the first value passed to a procedure, the number and meaning of the parameters change, and the scheme is not readily generalizable. It is also not possible for other procedures to manipulate the values used, which would be desirable for macro recorders and plug-in adaptors that run on multiple images. I suggest the following: * we add a subfunction field to PdbProc, which is NULL for the main function. The interactive version would use interactive for the subfunction. * to call a plugin interactively, first call its interactive subfunction. The interactive subfunction will return a list of arguments to be used in the call to the main function. What do you think? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] A Free Software project of interest.
I saw this program and thought it might be interesting to GIMP users and developers. http://www.vips.ecs.soton.ac.uk/ Hopefully Gimp 2.0/GEGL/PUPUS will use some of the ideas there. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] List of changes for the future 1.2.4 release
On 20 Dec 2002, Sven Neumann wrote: Hi, Raphaël Quinet [EMAIL PROTECTED] writes: Note that just checking write() or fwrite() return values may not be enough: some filesystems delay the error indictation until close() is called on the fd. So this bug may well be influenced by the filesystem GIMP is writing to at the time. Yes, this is very important! Checking only the return value of fwrite() and ignoring the return value of close() is a recipe for disaster. You should also bear in mind that some filesystems (even the good old ext2) may behave differently if quotas are enabled. please reopen the bug-report then. No need; we check fclose()'s return value in both branches now. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: libpdb suite 0.2.0
Libpdb suite 0.2.0 has been released. This is mostly a code cleanup release. Changes include: * Renamed WireStandardProtocol WireStdProtocol. Hopefully this will save some typing. Similarly, WireStandardProtocolMessage is WireStdProtocolMsg. * The read and write functions in WireStdProtocol now take a single value instead of an array. The old functionality is still available with new functions that have a _v suffix. * WireStdProtocol now provides signed and unsigned version of the read and write functions. * Parameters can now be marked as required or optional. This currently serves no purpose, but when keyword calling is supported, optional parameters will be supplied with default values if not specified. * GError is used to report errors in libwire. * libwire is now (almost) completely documented. * i18n now works. A Spanish translation is provided. Many exciting new features are planned for 0.3! Check out the TODO list for details. Downloads are available at http://www.gimp.org/~rock/libpdb. A libpdb mailing list is now available at libpdb-developer-at-lists.xcf.berkely.edu. Libpdb can also be obtained from gnome cvs by checking out the libpdb module. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] List of changes for the future 1.2.4 release
On 18 Dec 2002, Sven Neumann wrote: Hi, Raphaël Quinet [EMAIL PROTECTED] writes: I'd also like to see this one being addressed: Saving .xcf on full filesystem hangs GIMP http://bugzilla.gnome.org/show_bug.cgi?id=101340 doesn't seem overly complicated since there's only one call to fwrite() in app/xcf.c which needs to have its return_value to be checked. The larger part of the problem is to propate the error up from xcf_write_int8(). Volunteers for this one? I'll volunteer. I've lost a lot of work to this bug. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New Gimp FAQ: Call for questions
The gimp web team has desired that the current FAQ's be updated to reflect the current 1.2.x reality for some time. Unfortunately, it has not been able to contact the FAQ maintainer, and the licence on the current FAQ's do not allow for modifications. If we are not able to contact Miles soon, we will have to do a clean room reimplementation of the FAQ's from scratch. The results will be placed under the GNU Free Documentation License. We have decided to do this in two parts. First, we will issue a Call for Questions. Please send in all questions you would like to have in the new Gimp User FAQ to [EMAIL PROTECTED], and CC them to the lists for discussion. Once the questions have been selected, I will arrange them and issue a Call for Answers. Please then send me a message stating your intent to write an answer, and CC it to the lists so that no one else takes that question. If I do not recieve an answer within three days, I will open that question up again. Once all the questions are answered, I will send a final draft out for comments. Soon thereafter we will start with the Call for Questions for the Developer FAQ. I must reiterate that copying from the current GIMP FAQ's is simply not acceptable. Such submissions will be rejected. If English is not your first language, don't feel that you can't take part. Any grammar mistakes will be lovingly corrected, so even if your English is not perfect, you can still contribute significantly. FAQ entries should be written with respect to 1.2.x, but should also contain any significant changes in 1.3.x. If you don't use 1.3.x, it is not neccessary to mention differences in 1.3.x -- they will be added by the GIMP web team. Please do not assume that all readers of this document will be Linux users -- we want to treat users of all supported operating systems equally, to the extent that our limited resources are capible of supporting. Here is a list of questions to start with: 1. What is the GIMP? 2. What does GIMP stand for? 3. What features does it have? 3a. Does it support CMYK? 16-bit per channel images? Floating-point channels? 4. What are the minimum system requirements? 4a. What operating systems is it available for? 5. Where can I get it? 5a. There are some binary versions on the GIMP website. Should I download them or build GIMP myself? 5b. Where can I get non-official gimp packages for foo? 6. What version should I get? 7. What documentation is available? 8. Where can I find other GIMP stuff? 9. Is GIMP a true GNU program? 10. What is the history of GIMP? 11. What is the relationship between GNOME and GIMP? 12. Easter eggs are fun. Does GIMP have any? 13. Does GIMP support digital cameras? 14. Does GIMP support scanners? 15. Does GIMP support Wacom tablets? 15a.How about other drawing tablets? 16. Is there a GIMP mailing list? 17. How about an IRC channel? 18. Ok, I'm trying to compile gimp, and this `./configure' program complains about missing or old libraries. What gives? 18a.But I know I have the right version of libfoo! Why can't configure find it? 19. How do layers work? 20. Channels? 21. Paths? 22. Selections? 23. How can I draw basic shapes (straight line, circle, square, etc.)? 24. How can I change the color I draw in? 25. How can I make what I have selected into a separate image? 26. How can I add what I have selected into a new image? 27. How can I make part of my image transparent? 28. How can I change keybindings? 29. How can I do gamma correction? 30. What are plug-ins? 31. Where can I find new plug-ins? 32a.How can I add them to my GIMP? 33. EEEK! I downloaded the latest version of gimp, and my favorite plug-in has dissappeared! 34. Are Photoshop Filters/Plugins supported? 35. What is Script-Fu? 36. Where can I learn more about it? 37. How can I call a plug-in in Script-Fu? How about another script? 38. What in the world is a Procedural Database Error? 39. Is there a macro recorder that automagically creates Script-Fu scripts for me? 40. Can I add my own brushes? 41. Can I add my own patterns? 42. Can I give a copy of this gradient or palette I've created to a friend? 43. My fonts are ugly. 44. What font formats does GIMP support? 45. Where can I get more fonts? 46. The font that the GIMP uses for its menu text is nappy. How can I change it? 47. What is this XCF file format? Why should I use it? 48. What other formats does GIMP support? 49. I can't save my file as a GIF or TIFF. 50. I can't save my file as some other file format. 51. How can I add support for the foo file format to GIMP? 52. What languages does GIMP support? 53. Does GIMP support XInput? 54. Why doesn't text in my native language render correctly with the Text tool? 55. Does GIMP support bidirectional output? 56. How do I use batch mode? 57. Do I have to use an X server to run GIMP even in batch mode? 58. How can I call a Script-Fu script using batch mode? 59. How can I connect my web server to GIMP like
[Gimp-developer] ANNOUNCE: libpdb suite version 0.1.0
I'm proud to announce the first public release of the libpdb suite. The libpdb suite is an exciting new library designed to make it easy for application developers to add scripting and plug-in functionality available. It is based on GIMP's PDB implementation, but much work has been done to improve the programming interface. Here are the release notes: The libpdb suite consists of three libraries based on code from the GIMP. Libpdb is a small library implementing a database that stores information about procedures available for the scripting of applications. Libwire is a lightweight, extensible IPC framework. Libpdbwire depends on both libraries and provides a way for a remote process (such as a script or plug-in) to access procedures stored in the procedural database of another process. These libraries are designed such that at a future time they could be developed and maintained by different groups. This release is still quite rough around the edges. Much basic functionality is missing, and much of the API is subject to change. Still, application developers seeking to use these libraries in future releases would be well advised to start implementing the necessary changes to their programs to be able to access and use the functionality of these libraries. Bug reports and patches are gladly accepted. These libraries are currently housed in CVS on my personal computer, but I will place them on a more public CVS server soon. All libpdb suite releases will be signed with my public gpg key. Accept no substitutes! Always insist on genuine Rockwalrus libpdb releases! A different key is used to distinguish between stable and development releases. Enjoy! Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: libpdb suite version 0.1.0
On 10 Dec 2002, Sven Neumann wrote: Nathan Carl Summers [EMAIL PROTECTED] writes: I hope that you didn't follow the current GIMP implementation too close. It might have proven to work but it certainly has major drawbacks and I wouldn't suggest it to application developers that think about adding plug-in functionality. I've certainly made a lot of changes to make the design cleaner and more generic. I don't think that there are many of the drawbacks of the current gimp design left in libpdb. Of course, I'm open to suggestions and patches. the major drawback of the current design is that it doesn't use named parameters. That is definitely one of the things we should change right in the beginning of the next development cycle. Does your library include this change already? Not yet. But I will put it on the TODO list. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Random number seeding interface
On Thu, 21 Nov 2002, David Neary wrote: The real change would be to do away with the toggle, replace the toggle button with a normal button, and set a random seed in the spin-box when the button is pressed. For this, I've been using the global PRNG (g_random_int) rather than setting up what would be a short-lived GRand * object, but again that would be a trivial change. This would be great! Several times I have lost a really good seed because I did something that causes the plug-in to change the seed, or because I wanted to use it in multiple invocations, and couldn't, because of course it comes up with a new seed each time. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
On Wed, 6 Nov 2002, David Neary wrote: 78064 Entering large dimensions in Scale Image causes fatal error Memory issue - some things use lots of memory and crash the GIMP. Enhancement, marked critical - it's a matter of pre-calculating how big the new image will use, and warning the user if it goes over some threshold (say 1GB?) I think it's safe to say that if the size of the image is bigger than the size of the tile cache, it's big enough to warn about. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
On 7 Nov 2002, Lutz Müller wrote: On Wed, 2002-11-06 at 23:05, David Neary wrote: Looks kind of plaform-specific... how would you go about doing that for Solaris, SGI or Windows? Alternatively, if someone hacks up a plain-C-library called libmem or similar for figuring out free memory and stuff like that on various systems, we can join the efforts in gimp and libgphoto2. It would be a nice thing to put in glib. Regardless, it should only be used to create a suggestion -- the tile cache size should still be determined by the user. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit
On Fri, 1 Nov 2002, Guillermo S. Romero / Familia Romero wrote: I think it should be visual, a window with the image in 8 bit, and controls that decide how to get that 8 bit from the original 16 or 32. Basically black white points and a curve. I say visual, cos it could mean what one does in the lab, but digital (load some copies, adjust each one at will, and mask and mix all the copies to get the final image). Would error-diffusing dithering be an option people would like? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script-fu-scheme: Full implementation of Scheme?
On Wed, 30 Oct 2002, Martin Bernreuther wrote: At http://www.swiss.ai.mit.edu/projects/scheme/documentation/scheme.html there's a reference manual, but I didn't manage to get some functions... to work. How about e.g. the (do) statement or (floor -4.3) (round -4.3) at scheme_5.html#SEC56 ..? It didn't work at the GIMP 1.2.3 script-fu console Is there a reference manual of the script-fu implemented Scheme? Gimp currently uses SIOD, which is a nonstandard implementation of Scheme with some of the standard Scheme functions, some functions imported from C, and some just plain strange stuff (what is the MD5 calculator doing in a lightweight scheme implementation?). A hodgepodge of stuff, really. Then, of course, there is the gimp extensions to it, which are rather strange in of themselves... Anyway, the definative reference for SIOD is now http://people.delphiforums.com/gjc/siod.html (it took some poking around to find that site -- most people refer to an older document at indiana.edu) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script-fu-scheme: Full implementation of Scheme?
On Wed, 30 Oct 2002, Kevin Myers wrote: However, not all of SIOD is implemented in the GIMP. Specifically, all of the stuff that requires a platform specific implementation is missing. These functions were marked with a U in the old Indiana doc. I don't know if that's true on the newer site referenced below. The big U is in the new doc as well. It's not completely reliable, though -- a few of the big U's are in script-fu, and a few of the functions not marked with a U as missing as well. datlength and datref are the only ones I can remember that aren't marked with a U and aren't present. (Which is annoying, since datref can be useful for parasites.) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: About The GIMP
Here is my suggestion for a rewrite. Changes are marked and commentary explaining the change is written at the bottom. GIMP is an acronym for GNU Image Manipulation Program. It is a freely distributed piece of software that is useful [1] for graphics-related tasks [2] such as photo retouching, image composition and image authoring. GIMP is extremely capable. While it can be used as a simple paint program, it is also used [3] as an expert quality photo retouching program, an online batch processing system, a mass production image renderer, an image format converter, and many other functions. GIMP is extremely [4] customizable and extensible. The advanced scripting interface [5] allows everything from the simplest task to the most complex image manipulation procedures to be easily scripted. For new [6] special effects and other advanced custom features, GIMP is designed so that plug-ins and extensions can be written to do just about anything. Plug-ins can also be developed to allow the reading and writing of new file formats. GIMP was originally written and developed under X11 on UNIX platforms, and the UNIX version is usually the most recent and stable. There are also OS/2, [7] MacOS X, and Windows versions available. Features and Capabilities Here is a [8] short list of some of the most important GIMP features. Keep in mind that this is only the tip of the iceberg. *Painting* - Full suite of painting tools including Brush, Pencil, Airbrush, and Clone [9] - Sub-pixel sampling for all paint tools for high quality anti-aliasing - Extremely powerful gradient editor and blend tool - Supports custom brushes and patterns *System* - Tile based memory managent so image size is limited only by available disk space - Virtually unlimited number of images may be open at one time [10] *Advanced manipulation* - Full alpha channel support - Layers and channels - Multiple Undo/Redo (limited only by diskspace) - Transformation tools including rotate, scale, shear and flip - Selection tools including rectangle, ellipse, free, fuzzy, bezier and intelligent scissors [11] - 'Quickmask' allows the selection to be made by painting with paint tools. *Extensible* [12] - Advanced scripting capabilities -- A Procedural Database for calling internal GIMP functions from external programs such as in the included Script-Fu application - Plug-ins -- allow for the easy addition of new file formats -- make it simple to write new effect filters -- Over 100 plug-ins already available *Animation* - Load and save animations in a convenient frame-as-layer format *File handling* - File formats supported include gif, jpg, png, xpm, tiff, tga, mpeg, ps, pdf, pcx, bmp, and many others - Load, display, convert, save to many file formats And much, much more! [13] 1: suitable is wimpy sounding, but something is needed 2: general, then with specific examples. Nice. 3: this phrasing illustrates the contrast in the range of uses more clearly, and also makes it clear that gimp really is used for those purposes. Ideally, each of these noun phrases should be made into hyperlinks to places like filmgimp, flamingtext, etc, and to news articles about how gimp is used in such-and-such. 4: expandedable? huh? 5: switched scripting and plug-ins, to go from simple and less powerful to most complex and powerful. This is how people tend to think, and it saves the most impressive for last as well. 6: explained why you would want to write a plug-in 7: yeah, I have to hold my nose to use Windows too, but really, can't we all just get along? 8: even if the list is thrown together it doesn't need to say so. :) 9: etc and including were redundant and said the same thing two times. 10: 'may be open' 11: intelligent scissors, not intelligent select. Also added Carol's quickmask text 12: reformatted this section to use another level of indentation 13: sounds better with the and Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp security bug, shared memory
On Thu, 13 Jun 2002, Marc Espie wrote: On Thu, Jun 13, 2002 at 05:48:58PM +0200, Raphaël Quinet wrote: Also, I think that some old systems (AIX? HP-UX?) had problems with shared memory segments unless they were created with the mode 777. This is very vague and I cannot find any information about that, so maybe this is just a brain fart on my part. This is quite possible, but it is no excuse to keep a security hole around. In the worst case, write a configure test, and resort to mode 777 only if nothing else works. It should default to no shared memory if the proper permissions don't work. (There could, of course, be a sufficiently omninous-sounding option to configure that would use 777 if the correct permissions don't work; I suggest --enable-shm-security-hole) In any case, if a plugin needs to be setuid, then it had better be written by somewhat security-conscious people (or you've got a whole larger set of problems...), so fixing a shared memory ownership issue on that end is going to be a breeze. Never assume that just because someone makes something setuid they know what they are doing. (also don't assume it's always setuid root). Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
