Re: [Gimp-developer] Re: (LONG) Problems with the GIMP
David Neary writes: Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: 2) Not enough developers use Bugzilla to find out what bugs need fixing 3) Not enough developers hear user complaints I'd like to chime in here and say that gimp seems much more responsive than most projects to bugzilla. Some bugs may get closed or duped, and I may not always agree, but I don't think I've ever felt like bugs were being ignored the way they are in a lot of projects. And that's even without the other channels like IRC and the mailing lists. Of course, David didn't actually complain about responsiveness, but about the number of developers; and indeed, it's only a few developers making comments. Is the problem that bugs don't get triaged to appropriate owners, so that people outside the small overworked core team might see and fix them? Now, let's look at the Owner field - 1 bug is owned by grosgood, one by jimmac, 2 by mitch, 2 by Raphael, 2 by rockwlrs, and 1 each for sven and yosh. That's 10. Leaving 381 bugs owned by that well-known gimp developer [EMAIL PROTECTED] I found that confusing, too -- it's not what I'm used to in other projects, where bugs generally have an owner and components have a default owner, who may also triage new bugs for that component. I guess the gimp team is small enough or works closely enough that they feel they don't need that; or everyone wants to see all the bugs. The lifecycle of a bug *should* be that a bug gets reported against a module, which is owned by the module owner, who [ ... ] I'm not sure anyone's quite sure of the perfect bug lifecycle. I've seen at least five different theories tried, and none seem to work perfectly. It probably just depends on what works best for a particular team. I'm glad you agree there's a problem with the number of people active in gimp development. As I've said a couple of times, the module owners don't need to know how to fix the bugs. This seems to me like a great way to get people involved in the gimp. I know that fixing bugs was how I got involved... I just started browsing bugzilla, picked one that looked fairly easy, and attacked. So maybe there are 5 people who aren't too confident diving into the core, and would like to feel their way around with bug reports? Bugzilla keywords, like helpwanted or blocker, can be helpful here too. (Does gimp already use these? I confess I haven't looked, and should.) For bugs which might be relatively easy fodder, a keyword in bugzilla and a periodic posting on gimp-developer mentioning the keyword or requesting help on particular bugs (as I've seen here a few times in the past) can be a great motivator. ...Akkana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Sven Neumann writes: Assuming your camera adds EXIF info, are you seriously telling me that you do not run 'exiftran -a -i' on each and every image you ever shoot and instead use GIMP to rotate them? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. In fact, I don't think I'd ever met anyone who regularly ran exiftran on every archived original, until this discussion. Exiftran isn't even installed by default on any linux distro I've used. Is it commonly found on mac and windows machines? (in another message) Sven Neumann writes: If the spec says it's ASCII, then we have no choice but keeping it ASCII. That of course means that there isn't much point in allowing anyone to edit this field since conversion to ASCII will fail for almost all strings that a user may enter. It appears that the best we It's a bummer that it's not something like UTF-8 (and quite odd, if the spec came from Japan), but editing ASCII is still useful for quite a large number of people. What do modern cameras sold in Japan save in the EXIF fields? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As remembering last dir (was: we need more documentation)
Sven Neumann writes: Mitch and me also agreed that we would like to do something about http://bugzilla.gnome.org/show_bug.cgi?id=162385 and even get that change into the stable branch. The fact that the file-chooser in GIMP doesn't remember the last used folder in GIMP 2.2 was probably a wrong decision. I don't know if you're soliciting votes, but it would be a huge help if the Save As dialog remembered the last location, as the bug suggests. I hit this nearly every time I save a file. Is someone already working on it, or do you need a volunteer? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Menu reorganization
I haven't seen anything in a while about the menu reorganization which was proposed a while back. One thing I'd like to see is getting script-fu and python-fu items out of separate menus and integrating them into the regular menus, so users don't have to know what language something was written in to find it. With that in mind, I've started from the current Image menu reorg page http://wiki.gimp.org/gimp/ImageMenu and made a few changes: - Reformatted a bit, in plaintext. The stuff on the wiki is html but it's really inconsistent, has paragraph tags inside list items, and closes lists at the wrong place, so it doesn't show the right hierarchy and is impossible to copypaste properly. - Moved script-fu items into the main menu and got rid of the Script-Fu menu. - Combined Animation and Animators: it seemed confusing to have both. - Put the Alchemy scripts under Artistic. They're not really Artistic but they do vaguely similar things. - Distributed the few items in the Python-Fu menu to places that seemed vaguely reasonable. I ended up with 2 more items under Filters than are there now. Admittedly that's still a lot; some of these could be combined, but since it's only two more items and I was trying to change as little as possible, I didn't try. I only looked briefly at Xtns. Really, I think that menu is fine except that again I'd get rid of the language menus, and put the script-fu stuff under Render. That seemed so simple that I didn't bother to write that up as a proposal. So here's my proposal. Does it look reasonable? I tried to compare it both to the existing menus in 2.2.6 (haven't compared with CVS yet) and to the proposal on the wiki, but things got confused with the re-editing I needed to do so I might have missed something. I'm willing to do some work to make this happen, if people agree that it should happen and if it's not too late to get it in for 2.4. I think most of the work involves tweaking script-fu and python-fu registration routines. Is there documentation that would need to be updated? The menu page on the gimp manual doesn't seem to mention script-fu or python-fu menus at all. This seems to be covered under bugs 116145 (image menus) and 145507 (Xtns). The latter has a patch from Carol which might be slightly stale now, but also makes reference to bug 158980, to make a logo browser which would move the logos out of Xtns. That's a great idea, but until it happens, moving the scripts is probably still reasonable. Thoughts? ...Akkana Image Menu File * New * Open * Open as Layer * Open Location * Open Recent o (list) --- * Save * Save as... * Save a Copy... * Save as Template... * Revert... --- * Mail Image... * Print... --- * Close * Quit Edit * Undo * Redo * Undo History --- * Cut * Copy * Copy Visible * Paste * Paste Into * Paste as New * Buffer o Cut Named o Copy Named o Paste Named --- * Clear * Fill with FG Color * Fill with BG Color * Fill with Pattern * Stroke Selection * Stroke Path Select * All * None * Invert * Float * By Color * From Path * Selection Editor --- * Feather... * Sharpen * Shrink... * Grow... * Border... * Rounded Rectangle... --- * Toggle Quick Mask * Save to Channel * To Path View * New View * Dot for Dot * Zoom (XX%) o Zoom Out o Zoom In o Fit Image in Window o Fit Image to Window --- o 16: 1 (1600%) o 8:1 (800%) o 4:1 (400%) o 2:1 (200%) o 1:1 (100%) o 1:2 (50%) o 1:4 (25%) o 1:8 (12.5%) o 1:16 (6.25%) --- o Other... * Shrink Wrap * Fullscreen --- * Info Window * Navigation Window * Display Filters... --- * Show Selection * Show Layer Boundary * Show Guides * Show Grid * Show Sample Points * Snap to Guides * Snap to Grid * Snap to Canvas Edges * Snap to Active Path * Padding Color o From Theme o Light Check Color o Dark Check Color o Select Custom Color o As in Preferences * Show Menubar * Show Rulers * Show Scrollbars * Show Statusbar Image * Duplicate * Mode o RGB o Grayscale o Indexed * Compose * Decompose * Recompose * Transform o Flip Horizontally o Flip Vertically o Rotate 90 degrees CW o Rotate 90 degrees CCW o Rotate 180 degrees o Guillotine * Canvas Size * Fit Canvas to Layers * Print Size * Scale Image * Crop Image *
[Gimp-developer] Re: [Gimp-user] use of the Space key
Sven Neumann writes: I consider to change what GIMP uses the Space key for and would like to get some user feedback on this. Currently, pressing the Space key temporarily switches to the move tool. Spacebar to switch temporarily to move is awfully useful. I didn't know about it until this discussion, but I've often wanted something like that -- I'm forever switching between move and something else, for instance when I'm creating lots of different text layers and need to position each one. If you change spacebar to pan, I hope you'll consider investing some other key with this temporary move tool meaning. Now that I've known about it for a couple days I'm already sorry to have to give it up! Do a lot of gimp users not have a middle mouse button? Maybe tablet users who don't want to put down the stylus and switch to a mouse? (That would be understandable.) Or is this just because ... that other program does it that way, and its users are used to it? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC meeting]
Alan Horkan writes: I was thinking fo doing something similar for the python plugins (and It was my intention to include python-fu as well. I must have missed it because python-fu didn't get built in the tree I was using (it's there now). I need to make an updated patch anyway, to include placeholders, so I'll merge in the python scripts (there don't seem to be very many of them) at the same time. Nobody's commented on any of the other questions I asked in the bug, like whether it would be a good idea to fold the short Glass Effects menu into Light Effects, or moving Enhance up to where it's just under Blur, or whether there's a reasonable place for Show Image Structure since it's now the only item in Utils. I'll go ahead and move Enhance since no one objected; maybe I'll try to come up with some place to stick Show Image Structure. (The bug is http://bugzilla.gnome.org/show_bug.cgi?id=116145 if anyone wants to comment there or read the questions in more detail.) making sure to add ellipses where needed). However some of the python plugins duplicate existing functionality so putting two Clothify plugins beside each other would only confuse users. I see Akkanna tackled this by marking the Script-Fu unsharp as Unsharp 2 but if people have idea on how to tackle this duplication of functionality I would be interested to I'd be interested too. I don't like Unsharp Mask 2 but strings like Unsharp Mask (script-fu) are likely to make the menus too long. Anyone have a better idea? Joao S. O. Bueno Calligaris writes: People suggested that an icon before menu entries would cause to much hassle to the UI - and I agree. Probably. It would be a nice idea but probably isn't worthwhile if it doesn't plug in easily to the current menu code. I do like the idea of being able to find out where a particular menu item comes from. I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable dynamic shortcuts) The problem with that is that many people still use right-click to get the menus (you have to, if you want tear-offs, so I find I get in the habit of using right-click most of the time instead of left clicking in the menubar), and once I'm in a context menu which I brought up by right-click, I expect right-click to continue to work to invoke submenus and menu items. If that changed and suddenly right-click did something else, and probably dismissed the menu at the same time, it would take quite a while to relearn those habits (and would make gimp's context menus inconsistent with most other apps). I could see using a modifier key, e.g. control-click on a menu item, or even mouse over a menu item and hit some key (f12 for help? ctrl-i for info?) Except of course then you couldn't rebind that key any more as a keyboard shortcut, so that's probably not a good idea either. And neither a modifier-click nor a help key over the menu is very discoverable. Tooltips would be discoverable, but they'd get in the way as you explore the menu system. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrated Scripting
Nathan Summers writes: On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote: different levels of artificial intelligence; are there opinions of ways to rearrange the Xtns portion of the menu system? Great topic. Personally I'd love to see the Script-Fu and Python entries go away, for the same reason as in the Filters menu: the user shouldn't have to know. people rearranging the menus now do not seem to see that Xtns makes its own image and do not need to start with an image; even though the logic is very clear to some. The thing is that there are plenty of exceptions to that rule. File|Dialogs being a big source of stuff that doesn't need an image, File-Dialogs doesn't make a new image. I'm with Carol, most of the stuff in Xtns makes a new image, and should be grouped together accordingly. for example. I know that the reason for the difference is that the Dialogs are implemented by the core, but why should I care? You shouldn't. include a menu entry for each of the gimp script powertools: the browsers the consoles the servers I see little reason why these shouldn't be a subcategory of the other dialogs. The name Development was suggested. Right. If it were up to me, I'd split Xtns into two menus: 1. Development (or something similar): all the entries that have to do with mechanics of the languages (including C). It would look like: Module Manager Plug-in Browser Procedure Browser Unit Editor Script-Fu Console... Refresh Script-Fu Start Script-Fu Server... Python-Fu Console... Python-Fu Browser... 2. All the things that actually make new images. I don't know what to call this menu. Xtns or Misc or Generate (because it generates new images) or Create or New Images or ?? This would include all the submenus that are currently under Script-Fu, without any reference to the word Script-Fu. Any Python scripts (or C plugins or anything else) that gets added would merge into these menus too. There was some suggestion on IRC that not all the items in the Xtns-Script-Fu submenus create new images. I haven't gone through them yet to look for counterexamples; if there are some, maybe they should go somewhere else. Likewise, if there are items in Filters which create a new image rather than working on the current one (I don't know of any) then they should move here. I'd lean toward making both these menus top-level menus in the toolbox window (so there would be four menus, not three), but that would cause space issues in verbose languages and large fonts, so alternately, I'd make Development a submenu (probably of File or File-Dialogs, not of Xtns/Generate/whatever, since the Development items do not create an image). It's more important that the New Image Creating stuff be easy to access than that Development is, because anyone developing scripts for gimp knows enough to use tear-offs, or set up key bindings, or somehow make it easier to get to the language tools. Kevi? is certainly not the only one qualifed to change the locations the scripts register under. It's actually a trivial change for anyone. I'd be happy to do the work if we reach consensus on what should be done. Well, no one has experienced all of the gimp experience. That's what good old fashioned kibitzing is for. That's also what discussion on mailing lists, bugzilla and IRC are for. We still won't encompass the whole gimp experience, but at least by doing things in the open we'll have a chance of hearing from a range of people. My suggestion is that Xtns menu items that create images should be called something like File|New Generated Image and that the rest should be merged with the other dialogs, ether as File|Dialogs or as a new toplevel Dialogs menu item. I'd argue for that menu being a toplevel menu, so users are more likely to explore it. There are some cool scripts in there. There's some reorganization that could usefully be done inside that menu as well. Buttons only has two items, Misc only has Sphere, Utils only has two items. How about moving those five items up to be directly visible in the Generate/Create menu? So it would look like this: Logos Make Brush Patterns Web Page Themes --- Custom Gradient... Font Map... Round Button... Simple Bevelled Button... Sphere... Thoughts? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New Colors toplevel menu
I've posted a patch to bug 116145 which would move all the color operations -- currently in Image/Mode, Layers/Colors, and Filters/Colors -- to a new top-level menu called Colors. (See the bug for the request and discussion of that.) If I don't hear any objections I'll commit it in a day or so. One issue is that it makes for an awfully long menu (see screenshot attached to the bug). Probably some of the items in it should be moved to a submenu -- e.g. move everything that was previously in Filters-Colors to Colors-Filters? Please post any suggestions here or in the bug. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Colors toplevel menu
Joao S. O. Bueno Calligaris writes: I am not so sure about Image-Modes , unless tehre is a ubmenu Colors-Image to indicate taht thos ewill operate ont eh whole image instead of a drawable. But then, they could just stay were they are. How about calling it Image Mode rather than just Mode? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
michael chang writes: Some who are prompted for auto-flattening-export think it will perminantly flatten their image, and look for a work around. In CVS GIMP, the export dialog does say, The export conversion won't modify your original image, so at least users shouldn't be worried about that (if they read the dialog). But I'm not sure why the dialog exists in the first place. Is there any reason the user needs to be prompted for this? It doesn't modify the current image, it's just a temporary thing for printing. Clicking Ignore seems to do the same thing (at least on Linux and current CVS) as clicking Export, so the user doesn't have any useful choice to make here, just a confusion between two apparently identical choices (or Cancel). Why not just do the conversion without bothering the user about it? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu
Anyone pulling CVS has probably noticed that most of GIMP's color-related functions have been moved into a new toplevel Colors menu (as discussed in bug 116145). There's some concern that the menu is a bit long, or could be organized better. Sven has been enthused about paper prototyping lately (see discussion in his blog entry) -- that's where you write things down on slips of paper and shuffle them around to come up with the order that seems most intuitive. The problem is, you need to get everybody together in a room for that, which is hard with a worldwide development community. Apparently someone (in gnome?) is working on some sort of card-sorting app to help with distributed paper prototyping. But it occurred to me (based on an offhand comment I read on slashdot, of all places) that GIMP itself could be a pretty good paper prototyping system. After all, you can have lots of text layers and drag them around with the move tool, and there's even a way to save your work when you're done. So I wrote a little quickie paper prototyping script-fu. It's at http://shallowsky.com/software/gimp/paperproto.scm Drop it into your ~/.gimp-?.?/scripts directory and Refresh Scripts. It registers under Xtns-Script-fu-Misc. Fill the textarea with a list of your paper prototyping terms, one per line, and it will make an image where each phrase is a text layer you can drag around. Anyone concerned with the Colors menu, please try this and drag stuff around and see if you find groupings you like better than the current ones. For the current Colors menu, the strings to paste into the paperproto dialog are (copy and paste the whole block): Image Mode Color Balance... Hue-Saturation... Colorize... Brightness-Contrast... Threshold... Levels... Curves... Posterize... Desaturate... Invert Value Invert Auto Histogram Colorcube Analysis... Adjust FG-BG Alien Map 2... Color Exchange... Color Range Mapping... Colormap Rotation... Gradient Map Palette Map Sample Colorize... Compose... Decompose... Recompose... Border Average... Channel Mixer... Color to Alpha... Colorify... Filter Pack... Hot... Max RGB... Retinex... Semi-Flatten Smooth Palette... Draw HSV Graph... Happy prototyping! ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software
Nice proposal. A lot of apps could benefit from a good shared font selector -- it's not just an issue of one app, as you point out. I love the idea of font groupings. I don't mind editing an XML file, but I'm sure it wouldn't take much to whip up an app to help people customize their downloaded fonts, compared with the rest of the work involved in the proposal. Tooltips over menus can be really annoying, because while they're showing more information about one entry they're preventing you from scanning all the other entries. You can move the mouse outside the menu, but it's a shame to have to mouse in to scroll, then quickly mouse out before the tooltip blocks the list you're trying to read. Please consider making that part optional, or skipping it. One more UI issue you don't address: the length of the font list can be a problem, especially if you have a lot of fonts installed. The current GIMP font list (and your proposal looks similar) pops up as a combobox that shows, on my system, 9 fonts at a time. Exploring the whole list through this small window takes a long time and a lot of clicking. Sometimes I really miss having a font selector dialog which I could resize to show a long list, so that I could scan through more quickly without needing to scroll so many times. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
Joao S. O. Bueno Calligaris writes: Unless, of course, the filename is in the ~/.gimp-2.x dir and you try to getthere by start typing . I am serious about this: I _lost_ almost 20 minutes in a 3 hour workshop trying to get people to open files in ~/.gimp-2.x - and It really is fairly tricky with the new file selector to explain to people how to get to files in ~/.gimp (for instance, to save or manage custom brushes, gradients etc.) I know this isn't the place to flame about the gtk file selector and save-as dialogs ... but given that GIMP does use the new dialogs now, and that there are sometimes valid reasons to need to open or save images inside the GIMP profile, has there been any thought on adding a gimp-specific button in GIMP's version of the dialogs which would take the user directly to the user's GIMP profile? That is possible with the current dialogs, isn't it? It would make life so much easier for newbies who aren't entirely clear on the concept of a file system (and believe me, there are a lot of people interested in editing images who have no idea whether they have a home directory or how to manage subfolders, let alone hidden directories), as well as for the people who are trying to teach them how to use gimp. The advantage over a bookmark (besides not needing to figure out how to navigate there the first time) is that most people don't edit images inside their gimp profiles often enough to make it worth adding a bookmark that will then show up in every other gtk app they use. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Comments on gimp's interface
Sven Neumann writes: And how do you reenable a popup that you have asked to suppress? I think that we should try to avoid popups but simply not showing them is not an option. If we can get away without showing the dialog, why do we show it at all then? In the case of the warning popups when saving, why show them at all? Of course it needs to flatten layers when saving to JPEG; why not just do it without asking me every time? It's not like I have an option to save without flattening; all I can do is press OK. In the case of converting to indexed to save as gif, there's some point to it because the user might not realize there's such a severe loss of quality about to happen; but it's still not important enough to warrant a whole extra dialog to which the only options are OK/Cancel. Just put it in the normal GIF save dialog, as a label that says Image will be converted to Indexed mode before saving if the image isn't already indexed. A similar case was the warning I saw sometimes when a layer mask was selected. I never quite figured out the point of that warning since it seemed to save the image correctly anyway. But that dialog seems to be gone now in CVS HEAD. #4 : if you maximize your artwork, the panels are over it, it makes the extreme areas of your work inaccessible without moving your panels, or going fullscreen. Hit Tab and the panels are out of your way. Is there a way to disable this? It gets in my way, because I hit it fairly often by accident (probably when I'm trying to hit 1 to make the image full-size), and it's several steps to undo it: in gimp 2.3 a single tab brings all the windows back (much better than gimp 2.2 where it took several tabs) but in the windowmanagers I use, the focus now moves to one of the restored windows so it's no longer in the image window where it was, and I have to move the mouse out of the window and back in. I've looked for places to disable it, but I don't see anything about the tab key in the Keyboard Shortcuts window or in menurc where other key bindings are controlled. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Comments on gimp's interface
I wrote: In the case of the warning popups when saving, why show them at all? Of course it needs to flatten layers when saving to JPEG; why not just do it without asking me every time? It's not like I have an option to save without flattening; all I can do is press OK. I posted hastily: this dialog does have more than one option. And the other dialog, that I said no longer existed in CVS HEAD, is still there (I don't know why it didn't come up for me earlier). Here's the sequence if a layer mask is selected: First, a dialog that says You are about to save a layer mask as JPEG. This will not save the visible layers. So what WILL it save? There's no way of telling from the text in the dialog. Options are: [Cancel] [Confirm], so Confirming is really the only choice. If you Confirm this, then at least for jpeg, you get the flatten dialog: JPEG can't handle transparency, Flatten? The choices here are: [Ignore] [Cancel] [Export] Export is almost always the right answer, since that saves the image as you're looking at it in the image window -- even if you just dismissed that scary layer mask dialog that said it wouldn't save the visible layers. It turns out that what [Ignore] means here is Save the current layer instead of the whole flattened image. And in that case, if you went through the layer mask dialog earlier, what will be saved is the layer mask, otherwise you'll get the layer (with no layer mask applied). If you wanted to save a layer or layer mask in a format that doesn't call up the Flatten dialog (say, as XCF), you're out of luck. The only option is to paste it as a new image and save that. This would all be so much clearer if Save As just saved the current image (the whole thing, flattening as necessary without pestering the user about it). For people who want to save just one layer (or mask), offer a separate menu item for that, perhaps in the context menu of the layers dialog, as well as in either the File or Layers main menubar. Right now Save As is overloaded to do two fairly different operations -- but only if you're saving to a format that doesn't allow layers. Why not separate those two operations as separate menu items, and have it work the same regardless of format? Bug http://bugzilla.gnome.org/show_bug.cgi?id=75328 seems to be the best discussion of these export dialogs, but it doesn't really address the issues I mentioned (I should probably add a comment). As long as we're talking about Save issues, bug 75459 is another one worth looking at (both referenced from the bug 119545 that GSR mentioned). ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Comments on gimp's interface
Pär Forsling writes: Akkana Peck [EMAIL PROTECTED] wrote: (about problems Tab causes because the focus ends up in the wrong window, and wanting a way to disable Tab). Have you posted a bug report to bugzilla about the wrong focus behaviour? Otherwise I'll do it. I haven't, because the focus behavior is mostly normal window manager behavior. It would be nice if GIMP could set focus back to the image window after Tab brings back other windows, but that seems fairly difficult to do in gtk. I wasn't confident such a bug would be accepted. And since I never actually want the Tab behavior anyway, and Tab is so easy to hit by accident, I'd still like a way to disable it. Grabbing the focus back would help in that correcting an accidental Tab would only take one keystroke instead of a keystroke-plus-mouse- out-plus-mouse-in; but I'd rather not have to correct it at all. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling gimp under debian with gimp-print support
Frédéric writes: I successfully compiled gimp-cvs under my debian testing, but without gimp-print support. What do I need to install to get it ? I can't find any gimp-print-dev or so package... When you're searching, be sure you use a search that would catch both gimp-print and gimpprint, e.g. aptitude search gimp | grep print. But it's likely that they've switched to gutenprint (new name, same project), and although there's a libgutenprint-dev package (at least here in Ubuntu), GIMP's configure script is only set up to look for older gimp-print headers, not the newer gutenprint ones. My understanding is that the gutenprint gimp plug-in is now expected to come from gutenprint, rather than from gimp. (Maybe someone else can clarify that.) In any case, it does work to build gutenprint from source (http://gutenprint.sourceforge.net/ ... and yes, the page still says Gimp-Print, but if you click on Download you'll find the gutenprint releases. It's all very confusing). Make sure that the gimp2 print plugin is enabled (I believe it is by default, at least if you have the gimp dev headers installed). Then the plugin will be built in the gutenprint source tree for use with your CVS gimp. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new default icon theme proposal
Jakub Steiner writes: You can preview the looks of the new GIMP icon set here: Nice icons! I have one comment about the SIOX icon in the light set. In current CVS, I find that the SIOX icon looks very different from the rest. It constantly draws my eye to it and makes me think that it is the selected icon even when it isn't, because it's an icon on a darker square background which makes it look a bit like a pushed in button. I was hoping this this was only temporary and would change in the new icon set, but it looks like the SIOX icon hasn't changed as much as the others. Would it be possible to make its background lighter, or even get rid of the background, to make its style better match the other buttons? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new default icon theme proposal
Jakub Steiner writes: Thanks for the constructive feedback Akkana. It indeed is one of the few icons with solid background. I tried to convey the fg/bg separation message better this time around. Does that work for you? http://jimmac.musichall.cz/wipicons/Tango-GIMP//stock-tool-foreground-select-22.png Much better! It still stands out a little, especially if you put it into a stock toolbox that doesn't have any of the other icons-with-background enabled (so it's the only icon whose outline is a square box instead of an irregular shape). But the important thing is that it no longer looks selected, and it doesn't draw the eye away from the other tools so much now. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] feature request
Tim Jedlicka writes: On 7/2/06, Marco Ciampa [EMAIL PROTECTED] wrote: Why not to bring all the GIMP windows up over all the others windows when I clic on to one of the many GIMP windows? While in the image window - try a Shift-Tab (it may just be my window manager (gnome/gdm)), but this works well for me. Doesn't work here in fvwm. It makes the Toolbox and dialogs disappear; then another shift-tab brings them back, on top of other windows. In neither case does it affect the stacking order of any gimp image windows. I wouldn't want to see a click on any window bring all the others forward. That would be really annoying, since there are many reasons for clicking in a window and most of them don't involve any of the other windows that might be open. But I agree it would be quite useful to have some way of bringing all gimp windows to the front, ideally via a menu item (which could then be bound to a keystroke). There are definitely times when I would use and appreciate that. (As a workaround, what I do is tell my windowmanager to move whatever window is hiding gimp down to the bottom of the stack. I'm not sure all windowmanagers offer a way to do that, though.) If this gimp function was implemented, it would have to loop over the image windows and bring each one forward ... in what order? Order by last access time? Does gimp even keep information about the last time at which each currently open image window was accessed? I suppose it isn't that critical as long as the one most recently accessed image window ends up on top along with the Toolbox and dialogs. -- ...Akkana Check out my book, Beginning GIMP: From Novice to Professional. Now shipping! For more information: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] menu cluttage
Sven Neumann writes: And so far I don't see anyone complaining about my proposal to not install any Python scripts at all with GIMP 2.4. Not installing scripts that are there strictly as example code makes sense. Would they stay in CVS head, so it would be easy for people learning gimp-python to find them? What about the few python scripts that perform functions that aren't otherwise available? Even if they're not perfect, some of them seem useful. For instance, py-slice can be very handy for some people (if they don't have gimp-perl and perlotine). Foggify is a bit different from anything else that's installed by default, isn't it? And it seems to work okay even if the default color makes me wonder where the author lives (orange reflections from low-pressure sodium lighting?) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] panning
Joao S. O. Bueno Calligaris writes: I am a heavy user of the push-move feature, and I know of other people who are. There are 105 keys on the keyboard - and both features are a good thing to have with push functionality. I do not care if the move push is changed to any other key, and space be left to pan. But I care about loosing the current feature. I also use this feature a lot. If there's a conflict with the proposed panner, I'd love to see the key made configurable, because then it would be at least somewhat discoverable (to those who go through the Preferences window carefully). But in truth I don't care very much which key activates the temporary move tool; I just hope some key will, since the feature is so very useful. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] default setup for 2.4 comments
Sven Neumann writes: On Tue, 2006-12-12 at 15:18 -0500, Kevin Cozens wrote: I prefer to have these showing in the toolbox. When I lost them a some time ago after a cvs up, the first thing I did was find out where they went and how to get them back. You could at least have tried to live without them for a while before judging about this change. That's one of the main problems with the GIMP user interface. People are afraid of trying new things and miss what they have learnt to use. So, the fact that you immidiately renabled these widgets only show us that you are reluctant to changes. It doesn't I'm not Kevin, but I had the same reaction he did. In my defense (and maybe Kevin's), when the toolbox selectors disappeared, the new dialogs didn't automatically make themselves visible, so it just looked like a bug that they were suddenly gone, and getting back my color selector was my first priority. A new user wouldn't have that problem. But Sven is right (even though he's talking to Kevin) that some of us didn't give the new layout a fair chance. So I've been doing that for the past couple days, and it actually works fine. I like not needing the popup any more, and for most operations it doesn't require any more clicks than the old layout. There are still two things I miss. Neither of these will stop me from using the new setup, but I wonder if they might cause a problem to non-geeky users: 1. Being able to drag from the foreground or background swatch into the image. Sometimes I use the keybindings (ctrl-, and ctrl-.) but other times it seems more natural to drag the color, and if the swatches aren't exposed (because they're hidden in a tab), it would take two extra clicks to drag them (two clicks assuming that I need the layers dialog visible most of the time, so I need to switch back). 2. The sliders for RGB. I can do HSV adjustments in the big color rectangle, but if I want to adjust RGB values (for instance, to ensure that I'm getting pure red) I have to use the HTML field or click the R, G and B buttons in sequence. I can't just glance at the three sliders like with the old dialog. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet. [ ... ] It should at least do the basic things right. In other words, print a single image, allowing the user to specify the size and location on paper. Should probably default to the original size (determined by the image resolution) if that fits to the printable area. Otherwise it should scale the image down while preserving the aspect ratio. For this plug-in I think we should focus on keeping it simple. Enough to fulfill basic printing needs but still usable without reading a manual. People who need more control can always install the gutenprint plug-in. Has anyone done this evaluation? If not, can someone please volunteer to do it? We need to find out if we can we ship the plug-in as is or if there are issues that need to be addressed before 2.4. I just upgraded to a distro that has gtk 2.10, so I can do the evaluation -- though for my own use I'm fairly happy with gimp-print/gutenprint. I just tried the print plug-in in current CVS. This is the first time I've actually seen it, and I'm happy to see that there's a gnomeprint dialog now that lets me set printer parameters. But I found quite a few problems, and ultimately wasn't able to print anything with it: - Bug: the Layout tab comes up with a unit of Inches, but Width and Height which are the pixel dimensions of the image. I hate to think what it would do if I let it print at 1160 inches wide. - The Layout tab is really difficult to use compared to gimp-print, because it has no live preview. I have to click on the Page Setup button (why isn't that right in the Layout tab?) then try to guess what it means by Portrait, Reverse Landscape, etc. and what it will do for margins (does it always center, or what?) - Minor Bug: the Page Setup dialog came up with the wrong paper size (A4 vs. my system default of Letter). - UI issue: there's a Page Setup tab, plus a Page Setup button in the Layout tab which has a completely different function. Shouldn't one of these be renamed? (Moving the Page Setup button/ dialog options into the Layout tab and eliminating the dialog would solve this.) - There doesn't seem to be any way to position an image on the page, so this dialog doesn't replace gimp-print for functions like printing out my holiday cards, where I have to print to the lower half of a page which will then be folded over. - When I try to change the Width in inches to 4, as soon as I leave the Width field it reverts to the old value of pixel width. So I can't actually try printing anything to check the quality. - When I click Print Preview, the dialog disappears and I get a GIMP Message dialog with a nice clear error message: Procedure 'gimp-image-set-unit' has been called with value 'pixels' for argument 'unit' (#2, type GimpUnit). This value is out of range. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: thanks for looking at the plug-in. It would help a lot if we could split your list into problems of the Print plug-in and problems of the GtkPrint API. The latter would have to be reported against GTK+. I've filed a gimp bug (#387604) on the unit factor problems (I suspect the dialog disappearing on Print Preview is the same problem; at least it's not easily separable from it right now). I'm not sure which of the other problems is GtkPrint vs. GIMP, because I'm not familiar with what GtkPrint does. Two bugs that seem worth filing: - Not reading the system paper size (I'm guessing this is gtkprint) - Two different functions named Page Setup (I'm guessing this is GIMP) Do my guesses sound right? And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp: - No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann writes: I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Robert L Krawitz writes: Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them... The live preview is essential for non-geeky people and visually oriented people (artist types), who aren't going to try to go from text like .8 inches, Reverse Landscape to visualizing what will actually be printed. I might be biased. Gimp-print, and particularly its live preview, was the key that enabled me to switch to Linux full-time back in the day. Before that I'd been fighting with Photoshop LE, which had an absolutely horrible print UI: you had to click a secret unlabelled area in the status bar to pop up a preview window, which consisted of a white rectangle with an X over the part that would be printed. Gimp-print's low-res preview showing the actual image may not have been perfect, but it was a huge improvement in usability over anything I'd found on Windows. Setting unequal margins is an intermediate case. That's really useful for one task a lot of non-geeky users might like to do: printing holiday cards. But maybe that one's less important since there's a workaround, even if it's more hassle (position the image on a white canvas 2.x times as large). -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Alex Pounds writes: On Tue, Jan 30, 2007 at 08:22:11PM +0100, Sven Neumann wrote: Any particular reason why you didn't use the screenshot feature of your desktop for this? Just asking. Not everybody uses a desktop that has a screenshot feature built in. I don't, and whenever I want a screenshot I use the Gimp plugin. I would be very disappointed to see it removed. Same here. I have set up a desktop function that does a screenshot via import (from image magick); but that doesn't allow me controls like delays, and it saves to a file which I then have to open in gimp as a separate step (and remember to delete later). I use it for quickie show someone on bugzilla or IRC what I'm seeing snaps but not for the important ones. For what it's worth, every time I see the question How do I make a screenshot? posed on a beginner/intermediate Linux list, the answer always ends up being GIMP. It's still the best method that's not dependent on users running specific versions of specific desktops. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
Sven Neumann writes: On Tue, 2007-01-30 at 08:22 +0100, Sven Neumann wrote: I don't think that the NEWS file is the right place for this. Someone should set up a detailed description of the changes with instructions on how to fix scripts that stop working after the update. We should then refer to this document from the 2.3 release notes (and of course also from the 2.4 release notes when they are written). Any volunteer for this? Doesn't that require someone with a good knowledge of what all the changes are? If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
peter sikking writes: Peter, I have to ask: how much have you actually used GIMP for screenshots? Have you done a lot windows cut from full-screen screenshots? Or talked to users who do? I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users, Not being an interaction architect, I'm still not understanding. How did you arrive at the 99% number? Is that the percentage of users who would be slowed down by seeing both delay options? Or by the previous behavior of having a delay only after selection? What is the corresponding percentage of users who are slowed down by having only a before-selection delay? Are these numbers based on usability testing, or user interviews, or analysis of bugs or public comments, or what? I'm hoping that, this being an open source project, the methodology involved in this interaction analysis is public and available for everone to see and understand and learn from. [pre- vs. post- selection delay] I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. To get the screenshot dialog out of the way, you mean? Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time? To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case). In 'snap window' mode the shot shall be taken: a) on the first mouse-down after the timer (can be zero) has expired; b) immediately, when a non-zero timer expires AND a mouse-button (left, right [pop-up menu], even middle?) is being held down. That takes care of menus, but there transient effects which don't involve a mouse button down. For gimp, examples include the cursor outline of a brush, or the line you get pressing shift in a drawing tool. That's admittedly an uncommon case, but how about the very common case of hover effects in a browser? I also wonder about discoverability: Sometimes I have to click on the window after the delay, but sometimes I don't. Will people figure out that having a mouse button already pressed is what makes the difference? Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
peter sikking writes: I got the fling that ksnapshot manages to take a snapshot of the window + menu. There is where I got the idea. But reading the documentation again, they do not 100% promise this. I should have tried ksnapshot before! It does get the menus -- even on Edgy where GIMP's snapsnot just gets garbage. If you have the mouse over only a menu, ksnapshot will even give you just the menu without the window containing it. ksnapshot solves the delay problem in a nice clean way: they have only one (pre-selection) delay, but their window selection is Window under cursor -- you don't need to click to select the window. That solves everything without requiring two delays. It's a nice solution! (Now off to poke around X and think about Sven's fabulous super- layered-screenshot idea.) -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Thorsten Wilms writes: I found toggling between original/preview in the same view to be superior if you want to spot JPG artifacts. Me too. The new setup where the preview is a layer in the image dialog (I just updated and saw it) is wonderful. I'd been struggling with focus/raise issues with the old separate-window setup (click on the dialog and it would raise the original image window, hiding the preview window, and even when that didn't happen I was always confusing the two similar looking image windows); using a new layer is a great solution and makes it so much easier to see the effect of the quality settings. I'll add another vote for hiding the Save as dialog when bringing up the JPEG dialog. I often go to the wrong one of the two dialogs after changing desktops or shuffling windows around to see the preview better. Partly that's because they always pop up widely separated on the screen, rather than placing the second dialog on top of the first (they seem to trigger different window manager placement rules). And the buttons on the dialogs are a bit confusing: they both show active Cancel buttons, but Cancel on the Save As dialog is a no-op. I wish there were a way around needing two dialogs (needing to click Save two different times in order to save). Seems like there must be a way around that, but I can't think of one. Putting jpeg options and dialog-like buttons into the image window doesn't seem like a better solution: you still need to click just as many times, and it sounds jarring for the familiar image window to temporarily change its UI and act like a dialog. peter sikking writes: because the task is modal by nature, the UI UI has to reflect that with dialogness. It is simply a UI law of nature. Is that an argument for making the two dialogs window modal? They aren't now -- I can go back to the image window and draw on it, or whatever, while the dialogs are up. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Crop+Scale (was Save As JPG Integrated)
Sven Neumann writes: If you had read the specification (and I expect all of you to have done that), you would know that the current state of the rectangle tool options panel is far from final. I knew it wasn't final. I did wonder what the current buttons were for. The specification you're referring to is the one Peter posted to this list in December? In other words, http://lists.xcf.berkeley.edu/lists/gimp-developer/2006-December/016890.html (The image attachment didn't make it to the archives, but I saved the message and it's not that different from the current aspect ratio, except that it has portrait and landscape buttons to the right of the text field instead of the mysterious Fix.) I'm confused about one thing in the spec: it says | From all three tool option panels, remove all the Fix buttons, | The line with the Aspect fields, and the three buttons below it. Just to be clear, the line with the Aspect fields isn't really removed, just changed to look like Peter's sketch, right? So the text field stays, a Use ratio checkbox is added above it, and the Fix to its right are replaced with the portrait/landscape icons. I'd be happy to update the tool options to be more like the spec, if you're looking for a volunteer and it wouldn't step on any toes. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
Sven Neumann writes: Create an SDI manager widget Do we really want to ask someone to waste his/her time with this? It is in my opinion not implementable in a sane way and we would likely not accept the results then. If this is supposed to be kept on the list then we need to agree first that we really want such a thing. Another possible approach which might be more generally useful is tabbed image windows (suggested in bug 121087), combined with moving the toolbox menus into the image window. Then people could dock the toolbox and do everything in one window if they so chose, while others could keep the current separate-windows model. Additional file format plug-ins Shouldn't this perhaps be titled Improve MNG support? There are a few other file format plug-ins I've seen discussed here recently, such as GeoTIFF and improved PSD support. On-canvas text editing Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing? Rich text support would be a very useful and fun SOC project. It might require architectural agreement on how the rich text would be stored in the XCF (which might not be backward compatible). Is that a problem? Or is there already a model for that? Search-based menu browser Nice and probably even reasonably well specified. The student should perhaps do some usability work on this him/herself (with the help of an expert). Peter says this sounds like flagging usability defeat and I understand why he says that, but I don't agree. Consider it a type of online documentation. Realistically, any program that offers as many different unconnected functions as GIMP does cannot organize them in a way that will be immediately intuitive to everyone, especially someone who doesn't understand conceptually what the functions do. Consider the person who's following an online tutorial. The tutorial says Step 12: run HSV Noise. The user may not understand what HSV noise is or why it's needed at this step; they just need to find something matching the name HSV Noise. Redesign and reimplementation of Save and Export in GIMP. We really need to do this, finally. When I saw the header I was hoping this covered things like remembering settings from the various save plug-ins (like, always show JPEG preview, always save exif, never save thumbnail). Turns out that's not covered -- but it would make a nice SOC project that would be very widely useful. Meta-data plug-in I would love to see the metadata plug-in finished and the framework used from other file plug-ins. This is crucial for 2.6. Probably up to Raphael to decide if making it a SoC project can help to make this happen. I think lots of people would like to see this, but everyone is afraid to touch it because the comments in the bug make it clear that Raphael owns the problem and it's presented as a big complicated project. It would be great to see it separated into smaller pieces so other people could attack it. If a general metadata plug-in is too ambitious, how about a straightforward EXIF and Comment editor? Then if the more general metadata thing ever gets finished, it could replace the simpler one. There's an old exif plug-in on the registry (written by Bill) that might offer a start, though it doesn't currently allow for editing or viewing. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
[EMAIL PROTECTED] writes: Come on, that is simply a rude accusation. Is it rude? It seems perfectly reasonable and polite to me. Interestingly Sven seems to find this highly offensive as well. May be you think taking offense somehow negates the criticism. It seems you both are not too good a taking what you give out to others and quick to take offence where it was not even intended. One key aspect is Joao's comment that outsiders preceive the project as rude -- and he gave several very recent examples of why this perception exists. Even if an original question seems rude or stupid, answering it in a rude or brusque manner creates a perception that GIMP is not a friendly project for outsiders. Maybe that's the intent -- to set up a gauntlet that weeds out any potential participants who might be lazy or thin skinned. If so, no problem. But if you actually want lots of new participants, then how other people perceive the project matters. Being perceived as friendly takes some effort -- and sometimes it means trying to seem friendly even when you don't feel that way, and even when you feel justified in being abrupt because the question was lazy. Simon , who I cant remember as being rude or off-hand to anyone, seems confused yet polite, not offended. Yes, it's ironic to see Simon targeted in this discussion -- he is not one of the main offenders here and is consistently friendly and helpful in general. Joao S. O. Bueno Calligaris writes: Simon, where does that forbid one to add words like thanks, please, would and etc... to even a short answer, like a FAQ URL??? Is there a FAQ URL? There's nothing linked from the top level of gimp.org. There is a FAQ page on the wiki, but it begins with a disclaimer that it's out of date and people should go to the GIMP manual instead (which doesn't answer most of the FAQ questions). I wish the person who added that out-of-date notice had actually mentioned *which* answers were out of date, which would make it a lot easier for volunteers to find and update them. And the FAQ doesn't have anything on the language(s) used to write GIMP. I know it sounds like a stupid question -- that was my reaction too -- but it's not the first time I've seen it asked on the mailing lists, so maybe it belongs in the FAQ after all, along with how to take a quick look at GIMP code (viewcvs) without downloading the whole tarball. Except I'm hesitant to run off and register for the wiki so that I can add it, given that it's not linked from the main GIMP site, no one refers to it and the page itself discourages anyone from using it. If there's no easy-to-find FAQ document, then is it fair to get mad at people for asking FAQs? -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What happened to FFT forward and backward plugins?
Mark Lowry writes: I had 2.2.13 on my PC and it didn't have FiltersGenericFFT Forward or FFT Backward. I have 2.2.14 on my laptop and those filters are there. So I just installed 2.2.15 on my PC and those filters aren't showing up. What gives? Maybe you installed the Fourier plug-in at some point on your laptop? http://registry.gimp.org/plugin?id=2246 (I found that by googling on gimp fft -- it was the first hit.) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David Marrs writes: 4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. I might have misunderstood this step (I definitely don't follow the comment about PS not letting you edit -- maybe that's a PS issue) but it sounds like if you did a Paste as New in gimp, you wouldn't need to create a new canvas or figure out any dimensions. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] JPEG plug in : added a default settings record and debug
guepe writes: The Gimp JPEG plug in does not allow to save defaults settings from session to session. It does exists for the PNG one (see bug #63610). I decided yesterday to write the same thing for jpeg, I submit the source code (mainly inspired from the PNG implementation). That should be a popular patch! It's something that lots of people have asked for. I sent a first mail with the code source attached, but it has been blocked by size.Source code is at : http://p.guepe.free.fr/gimp_jpeg/ The best way to submit patches is usually to attach them to a bugzilla bug. Submitting them in a mailing list makes it really easy for them to get forgotten before anyone has time to review them. In bugzilla, the main bug on this seems to be http://bugzilla.gnome.org/show_bug.cgi?id=63610 though there's a very similar bug that depends on it, http://bugzilla.gnome.org/show_bug.cgi?id=120829 Probably one of those would be the best place to attach your patch. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new rectangle tool specification
Sven Neumann writes: http://gui.gimp.org/index.php/Specifications [ ... ] The other aspect is not yet implemented. The spec suggests that when the mouse is over one of the corner or side handles, and one of the cursor keys is pressed, the rectangle shall be resized by one (shift: 15) image pixel in that direction and (new) the the canvas shall be scrolled in such a way that the position of the bounding rectangle under the sprite shall be constant. I don't think that scrolling the canvas is a good idea. If the canvas isn't scrolled, the spec should probably mention what happens on the next keypress. Suppose I have the mouse cursor over a side handle and I press right-arrow. The side handle moves right by one image pixel. Now the side handle is no longer under the mouse. If I press right-arrow again, I hope it would move another pixel, since arrow keys aren't very useful if you can only move one step. But that requires that the tool go into keyboard navigation mode where the tool remembers that one handle is active and is subject to being moved by arrow keys even if the mouse is no longer over that handle. How will the user see that it's in that mode? I'd suggest keeping the handle outline bold with the 2-pixel border described in the spec, even after it moves out from under the mouse cursor. But if the mouse moves (more than some threshold?) then un-highlight the active handle and go back to normal mouse-activated mode. Of course you could warp the mouse cursor to follow the handle, but I doubt anyone wants to do that, especially in an app used with graphics tablets. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
peter sikking writes: But in between, as long as it is not finished, there is no role for jpeg. Only one decompression at the beginning and a compression of the end result is defendable in high-end graphics. I'm seeing an unspoken assumption in this thread that most photos are edited in multiple sessions: read into gimp, do a few operations, write to disk, read back in (perhaps hours or days later), do a few more operations, write back out, repeat. In my experience, it's much more common to read a jpeg in once and do a lot of operations on it in one session, saving periodically. There's no cumulative loss of quality: the intermediate saves are in case of disaster like a power failure, not a way to quit gimp and continue the editing process later. But I think I remember Sven saying recently that Export would be able to save without prompting each time, after the first time. (I guess that means there will also be an Export As, in case you need to change the filename?) So those of us who often work in JPEG could use it just like we use Save now, and even bind ^S to it. If users get the hint that opening and saving the same jpeg again and again is a pain (also for the quality) and that either adopting a high-end GIMP file workflow or moving to another (mid-fi) app to work in their lossy jpeg way. Another thing I'm unclear on in this thread: when I first heard the idea of forcing Export instead of Save, the plan seemed to be that Save would always save XCF, and anything else would require Export. But now you seem to be telling us that the issue is lossiness, and the point of Export is to make it more hassle to save to lossy formats, to discourage use of those formats. Does that imply that Save will include PNG, TIFF and other non-lossy formats? -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.3 Memory usage and leaks
I just found my (wimpy laptop) machine running slowly after processing a few (4) images with gimp from current svn (with several scales, a crop and several saves) then closing all the image windows. I ran a quick memory check and discovered that gimp was using 51Mb despite not having any images open. I played around with gmemusage to get a feel for what was going on. GIMP 2.3 uses between 33.9 and 35.0 Mb on startup (no images loaded, and I don't know why it isn't always the same). For comparison, 2.2.13 uses about 13.9 Mb at startup, so it's increased by a factor of about 2.5 just for the base app, before images. Each time I load an image then close the image window without doing anything, gimp grows by some variable amount, ranging from half a Mb to 2Mb (perhaps related to the size of the image). If I do operations on the image before closing it, these cause it to grow more: doing a crop and a scale almost always makes it grow 2Mb even with a relatively small image. This seems like a memory leak (there's no usable history once an image is closed, right? so basically it's back in the same state it was before, except using more memory). Or is there useful information that's being saved about each image? I know there's one name and thumbnail added to the Recent Images list, but surely that doesn't account for 2Mb. Nobody on #gimp knew much about it when I asked, and there was some agreement that it sounded like a leak. However, I also see this ~2Mb growth in 2.2, so if it's a memory leak, it's not a new one. So my questions are: - Is the growth that comes from loading an image, doing operations on it then closing the window expected? What is this memory being used for? - Is anyone concerned about gimp's minimal profile having risen from 14M to 35M? If there's agreement that there's a problem I can file a bug and maybe dig in more detail into where the memory's going, but I wanted to ask here first. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.3 Memory usage and leaks
Sven Neumann writes: What does gmemusage display? Does it only look at malloc'ed pages or does it also take code size into account? I'm not sure. I think it's all of the above. On Fri, 2007-07-13 at 15:47 -0700, Akkana Peck wrote: I played around with gmemusage to get a feel for what was going on. GIMP 2.3 uses between 33.9 and 35.0 Mb on startup (no images loaded, and I don't know why it isn't always the same). For comparison, 2.2.13 uses about 13.9 Mb at startup, so it's increased by a factor of about 2.5 just for the base app, before images. That is most likely because your copy of gimp-2.3 has debugging symbols while your copy of gimp-2.2 doesn't. I wouldn't be surprised if gimp-2.3 That's a good point! But surprisingly, stripping the gimp-2.3 binary and all the libraries in lib doesn't make much difference -- the stripped 2.3 still takes 33M at startup. Top showed: VIRT RES SHR %MEM gimp 2.356600 24m 10m 13.1 gimp 2.235984 20M9.8m 11.2 I haven't tested in valgrind yet, or with G_SLICE=always-malloc, but I'll do some more experimenting (probably not for a few days ... I have some projects coming due). ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Guillermo Espertino writes: Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at 100%) . If we use tabs we have only one image open at a time and that's mostly a problem for pros. Clearly it wouldn't be good to have tabs as the only way of using multiple images. But there are lots of cases for which one tabbed image window would be great. For instance, you're editing several images from your camera. They're all the same size, you probably aren't going to be doing much with layers or separate views, and you're only going to be working with one at a time. A tabbed interface would be ideal for that. I'd love to see tabs as an option in image windows. As with Firefox, you'd be able to choose Open in new window versus Open in new tab in the same window. And of course you'd always have the New view option regardless of whether you were using tabs. Then people who only want one window (the people who ask for MDI, or who don't have window managers with multiple desktops and have trouble managing lots of windows) could put all their images in a single tabbed window. Add menu integration and a way of docking the toolbox and layers/paths/etc. dialogs, and you can get down to one window, like the MDI fans want, without having to take away the nice multiple-window multiple-view capability that current GIMP users enjoy. -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Sven Neumann writes: On Fri, 2007-11-02 at 23:55 +0100, Raphaël Quinet wrote: * jpeg plug-in + remove the prompt for EXIF orientation: it should always be done IMO the current solution of asking and allowing the user to skip this question is preferred. It requires a user decision once, but at least it I like being asked. My Canon A540 quite often rotates when it shouldn't (pointing the camera down, as I often do when shooting flowers or lizards, confuses its orientation sensor). The current dialog, with its thumbnail preview and its option of don't ask me again, works very well (though as Sven says, it would be nice to have an easier way of un-doing the don't ask). -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] redeye.c and gimp-2.4
Owen writes: Tried updating Robert Merkel and Benoit Drooghaag's redeye.c into gimp-2.4 but it failed. You know about Filters-Enhance-Red eye removal, standard with GIMP 2.4, I hope? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
William Skaggs writes: I find myself doing Edit-Stroke pretty often, and there are a few easy changes that I think would make it signficantly better. 1) The most important is that the dialog should not go away after the Stroke button is pushed. It often takes several tries to get the settings right, and it is very annoying to have to bring the dialog back each time. The gain in usability would easily be worth the cost of an extra button-click to close the dialog, in my opinion. Certainly a full-size preview would be quite useful. Like you, I find that I usually Stroke several times trying to find the right brush size (I usually stroke with the paintbrush tool, for its antialiasing). It wouldn't have to require an extra click: make the dialog offer a Preview button as well as OK. People who are sure they have the right settings can click OK, everyone else can use Preview first. Your other suggestions sound reasonable, but I seldom change the line style so they're not burning issues to me. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Liam R E Quin writes: Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a more modes submenu is a possibility. Eek, please no! Often the best way to use layer modes is to go down the list one by one, which would become even worse if you had to click through a more submenu each time. Bad enough to have to go to the bottom of the menu then wait for it to scroll. Personally I'd like Bill's side-by-side mode menu, just because it would be faster, and a shorter distance, to get to most entries. But Sven does have a good point that it implies there's a connection between each side-by-side pair of modes. Bill wrote: I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better I don't have a great solution, just a few specifics the gtk widget doesn't do well that I wish the modes menus could handle better. Like the fact that clicking on the button pops up the menu, but not always with the current mode selected -- sometimes it's the mode above the currently selected one, so I can't just arrow down once and assume I'm on the next mode -- I have to look at the current mode before I click, then choose the next one explicitly. And I wish there was a faster way to select them by keyboard than the current click on the button then use up or down arrow ... I wish I could type ad and be on Addition right away. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
I got to thinking some more about this discussion about the mode list UI. What I've really always wanted for the mode list (but didn't want to say because it didn't seem like a good general UI model) is a sort of mode tool: a way to keep the mode list menu posted so I can change modes on the current layer with a single click. In a way, the mode list is like the font list in the text tool: that combobox, like the mode option menu, is way too long and unweildy to navigate, but for font choosing you have another option, the Fonts dialog, which makes the process a lot easier. I've always wished I could have something like that for the mode on the current layer, so I could easily try each layer mode sequentially. And then I realized that it's actually quite easy to have that now, with no gtk changes needed. Just write a little script that changes the current layer's mode to the next one. So here it is: http://shallowsky.com/software/gimp/next-mode.py If you do this layer-changing often, just bind Layer-Next mode to a key, or use tear-offs to keep the Layer menu posted so you just need to click on Next mode repeatedly. And now I no longer wish for some new exotic option menu replacement. :-) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
Bill Skaggs writes: Well, it would be very easy to make the layer mode menu support a tearoff. It can literally be done by adding two lines of C code. (I just tested.) A tear-off Mode menu from the Layers dialog would be lovely, and would solve every problem I've ever had with that menu. One possible problem: would Modes from drawing tool options also be tear-off, and would that be a different Modes tear-off from the one in the Layers dialog? Would there be a way to tell them apart? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Sat, 2008-02-16 at 10:11 -0800, Akkana Peck wrote: dialog, which makes the process a lot easier. I've always wished I could have something like [a dialog] for the mode on the current layer, so I could easily try each layer mode sequentially. Sven Neumann writes: Why don't you just focus the combo-box and use Cursor Up and Cursor Down to go through the layer modes? Or use your mouse-wheel? Honestly, it's because I didn't realize I could use up/down arrows in option menus without first popping up the menu. :) That works well for going through modes sequentially. But there are other common issues a tear-off would solve, like when you want to go back and forth comparing two modes that aren't near each other in the menu. There are very good reasons why tear-off menus are deprecated. They don't solve usability issues but introduce them. They're deprecated? It figures that something so useful would be. Sigh. Fortunately, python makes it pretty easy to work around that. If anyone besides me wishes for a tear-off modes menu, you can get one (Layer-Mode dialog...) at: http://shallowsky.com/software/gimp/mode-dialog.py ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] sharefonts dependancy?
[EMAIL PROTECTED] writes: This seems pretty marginal usage. Can anyone advise if removing sharefonts will break fu or any other parts of gimp? The freefonts and sharefonts packages disappeared from Ubuntu and Debian quite a while ago (years). Kind of a shame -- there were some nice fonts in those packages. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A question on Gap -frame modify
Alchemie fotografiche writes: 1.a # for bourne and ksh users: GAP_DEBUG=y export GAP_DEBUG 1.b # for csh users setenv GAP_DEBUG y Now i don't know if i am a bourne, a ksh, or a csh user, i just know (and not as expert) how to use the terminal of my distro Ubuntu Hardy Heron. If you're a Linux user and you don't know (haven't changed it explicitly), then you're a bash user, which uses the same syntax as Bourne shell. So use 1.a. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF data missing after jpg save
Paka writes: the opensuse team that is maintaining gimp/ufraw does not believe that exif data is important to the project and do not include support for exif. I questioned stbinner at suse dot de several years ago (iirc) and was imformed. Perhaps several questions/comments from different users would convince them otherwise. If they can't be persuaded, Jim might want to look into jhead's -te option, which copies exif from one file to another, so you can put back exif that's been stripped. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
Alexia Death writes: I'm going to echo my support for this. The nags on saves are counterproductive. And often they're not even right -- e.g. The image has transparency, flatten? shows up on anything with an alpha channel even if every pixel is fully opaque. All those dialogs do is train the user to click OK without reading. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
[EMAIL PROTECTED] writes: Additionally, the 'forced .xcf' behaviour can be quite nagging - consider user experience for a quick Levels adjustment to a photo: [ ... ] Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic. For that workflow, what would be even more useful is to be able to have a command that could do both: save the current .xcf (.gz or .bz2) AND, from the same menu item or keystroke, save a copy to a simpler format. Then you wouldn't have to go back and forth between Save and Save a Copy every time you make a change, and you wouldn't have to confirm the copy's filename every time you saved it. It would be great if it were possible to write a plug-in that would do that, even if gimp didn't include it natively. It would need to get the current filename (that's easy already, gimp-image-get-filename) and also what the last save a copy filename was (not so easy -- I don't think there's an API to get that now, is there?) What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layersalpha being lost. This is much more intuitive than textual explanations... That trains users not to save intermediate results in some cases. Consider the case where you need to add text to a jpeg with the result being another jpeg for a website; yet you still might want to try several different fonts, text strings etc. I know, you're thinking Why not save the intermediates as xcf? But if there are only a couple of layers and fifteen minutes of work, it doesn't always seem worth the extra disk space to save an xcf in addition to the final jpg. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Specs for Export/Save User Interface
[EMAIL PROTECTED] writes: 3) Putting Text on a .png (in-place file editing) - Open bla.png - Text layer created - Export to bla.png exporting to currently opened file is admittedly ugly, but consistent. The image stays dirty as the layer data has not been saved. - confirm overwrite protection - check result in web browser - Modify Text size - Export to bla.png again - confirm overwrite protection - check result OK - last finetuning, e.g. brightness - Save dialog pops up, warning of layer data loss - Convert to PNG (dialog button)layers get merged, image gets saved to bla.png and flagged clean. - Close no warning here Two problems/questions on this workflow: 1. Every checkpoint of the file (saving in case of disaster), something which now is just a Ctrl-S, becomes an operation that requires going through at least one scary dialog (the overwrite one) and sometimes two (at least the first time, where the user has to select the same filename that GIMP already knows). 2. Why would a user use Export for every save except the last one, then suddenly switch to using a completely different command to save? How would they learn to do this? Because of GIMP warning them when they try to quit that the file hasn't been properly saved? Won't most users say But I just saved it!, click Quit Anyway, and then go complain to someone about how GIMP often, but not always, says images haven't been saved when they really have? This model seems much more confusing for users since they have to understand a lot more about what makes an image compatible with each format they might save to. (I know it seems patently obvious to anyone on this list why adding a text layer is different from doing a crop, but when you talk to users who mostly edit photos, a lot of them aren't very clear on differences between image formats.) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
vabijou2 writes: Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. How about this? The first time, do Copy Visible then Paste as-New Image. Call this new image the snapshot image. After that, do Copy Visible then go to the snapshot image and Paste (then click New Layer). Now the snapshot image has all the snapshots as layers. To cycle through you need only turn layers on and off. Of course, if you did this all the time you could very easily automate the process: make a little script-fu that does Copy Visible, checks whether the snapshot image exists, then either does Paste as New or Paste + New Layer in the snapshot image, from a single menu item. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp default brush set contest
Rogier Wolff writes: I have a weird obsession. I work with images that are larger than what most other people work with. So I don't need a 3, 5, 7, 9, 11, 13, 15, 17, or 19 pixel fuzzy circle, but I need one that is around 30 pixels wide. Or 50. I'm not sure that's all that unusual. With cheap consumer cameras makng 6 or 8 megapixel images or even more, the standard brushes are quite small. I've been making a lot of use of the brush scaling control to make the brushes big enough to be useful on photographs. Alexia thought 50 was surprisingly large, but remember, brushes aren't just for painting colors and fine clone jobs -- they're also useful for running dodge/burn or blur/sharpen over areas of an image, or painting areasin a layer mask or quickmask. 50 pixels isn't big at all for jobs like that, and even 190 (the largest stock round brush you can get right now, Circle(19) scaled to the maximum of 10x) isn't all that big. Try it against an 8 megapixel photo. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp default brush set contest
I wrote: Alexia thought 50 was surprisingly large, but remember, brushes Oops, that was Valerie, sorry. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we replace the 'Zoom when resizing image window'-button?
Martin Nordholts writes: Hi There is a little button in the upper right corner of each image window with the tooltip Zoom image when window size changes. I have never used this and I can't figure out in what way it is useful. It's useful in that it lets you scale the window exactly as big as you want -- you're not limited to 25%, 33%, 50%, 100% etc. That said ... Does anyone ever use it? I don't (partly because I always forget it's there). I set the Resize on zoom preference, and usually scale with the +/-/1 keys. I suggest we replace it with a shortcut to the Resize window on zoom option which I find much more useful. Does anyone have any objections to this? Should some completely other feature be accessible through that button? It seems odd to devote space to toggling a preference like that ... in theory, the current functionality seems more useful since it lets you do something that isn't otherwise possible. But as I said, I don't actually use it very often in practice. And it's not very discoverable. I didn't know from the tooltip what it would do and only found out by experimentation. It might be clearer if the tooltip added a few words, e.g. Zoom image to fit window when window size changes or Zoom image proportionally when window size changes. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp print dlg
[EMAIL PROTECTED] writes: thanks for the explaination. I've checked and gimp-print is built with gimp option. Should that alter the dlg I get from gimp file print menu? Are you building in gimp-print then doing a make install? Is this the latest gimp-print from http://sourceforge.net/projects/gimp-print/ ? Check that make install is really succeeding. If you already have gimp's built-in gtkprint plug-in, and you also build gimp-print from the Gutenprint project, you'll probably end up with two different File-Print... menu entries. One of them should bring up the Gutenprint dialog, the other, the GTKprint one. As long as you're building gutenprint yourself, I'd recommend modifying their src/gimp/print.c: find the line that registers to N_(Image/File/Print...), (line 166 in the latest version) and change the name, e.g. N_(Image/File/GutenPrint...), Then you'll be able to tell the the two plug-ins apart and verify that your gutenprint plug-in is really getting installed. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Environment suggestion
Rob Antonishen writes: I have an older PIII notebook I'm willing to blow away and use just for this purpose ... can anyone suggest the shortest path from a blank hard drive to a working gimp develpment environment? Sven Neumann writes: It doesn't hurt to put babl and GEGL into /usr/local. Just run configure without any extra arguments and things will just work. There's one more step you'll need in addition to getting gegl and babl that I didn't see mentioned (maybe I just missed it): gimp needs quite a long list of build dependencies that aren't installed by default, especially on Ubuntu which doesn't even install a compiler. If you follow Martin's suggestion (which I agree with) of using Ubuntu 8.10 (Intrepid Ibex), you can get the requirements using one (perhaps very long) line typed in a terminal window. This command might work, but I haven't tried it myself: sudo apt-get build-dep gimp If you try that but still get build errors from missing packages, try the long version listing all the important packages: sudo apt-get install build-essential subversion make gcc libglib2.0-dev libgtk2.0-dev intltool automake1.9 libtool gtk-doc-tools g++-3.3 libart-2.0-dev libtiff4-dev libexif-dev libxmu-dev libjpeg62-dev libmng-dev libpng12-dev librsvg2-dev libgutenprintui2-dev libaa1-dev python2.5-dev python-gtk2-dev libaa1-dev libxpm-dev libwmf-bin libwmf-dev libgtkhtml2-dev By the way, on an older PIII notebook, you may have trouble with the standard Ubuntu Live CD installs. If the Live CD doesn't boot or locks up partway through the installation, don't give up, but try downloading one of the Alternate Installer CD images. Unfortunately you may also have performance issues with GIMP 2.7 on a machine like that. With anything earlier, a PIII notebook should be okay as long as you're patient -- the build will take quite a while, maybe as long as a few hours -- and you don't need to work with huge images. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp license
So finally, I hereby suggest to move to GPL3 asap. Comments from any developers appreciated. Liam R E Quin writes: I think I only have half a dozen lines of code in there, but in case there's any doubt, it's fine here :) Likewise for me -- I don't have many lines of code in GIMP but the GIMP team is certainly welcome to relicense anything of mine as GPLv3. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Rob Antonishen writes: Why limit it to path stroking? It might be more flexible to create a stroke style editor where you could visually adjust those attributes including tapers, brush spacing, jitter, gradient mapping, and ultimately new features like rotation, opacity and scaling (which tapering ultimately is), either as start/end values or randomized values. These stroke styles could be used either when stroking a path, a selection, or just when painting. It would be SO nice to be able to taper lines when drawing. It could be handled just like fade out is now; or it could be handled in Brush Dynamics, adjusting Size with Distance. (The other attributes you mention would be nice too, but tapering is the one I've wished for most often.) Either way the UI would be simple, so it's probably not a good student UI project, but it sure would be useful as a drawing tool attribute. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFE: Changing/Remembering/Setting Dialog Defaults for Image... Canvas Size...
Jay Smith writes: In the dialog box: Image... Canvas Size... - Layers... The dialog _always_ seems to default to None instead of All Layers. I want to set a default of All Layers. I too would love this to be remembered. I usually want All image-sized layers but it gets to be a hassle to change it, so I usually don't and then find I need to resize the layers later. Developers: if someone were to make a patch to do this, would it be accepted? If so, would it be better to have it always remember the last setting, or to introduce a new preference for which setting the user wants as default for each session? - Canvas Size... The 'link' symbol at the top, between the two pixel sizes, reverts every time to linked status. It seems that it has to be unlinked every time if you wish to change only one of the dimensions of the canvas (or change them differently). I want to be able to have this default to unlinked so that I can change them independently without having to click the link/unlink. - Canvas Size... The method of measurement always defaults to pixels. For my work, it would be easier for me to see/manipulate inches or cm. I haven't hit those two myself, but if I were to change the Resize layers option and people thought it was worth doing these two, I could look into doing them at the same time. And while we're talking about options I want to change every time: two more I'd love to have remembered is in the JPEG Save dialog, Preview and Save thumbnail. I always want Preview (why would anyone ever move the quality slider and not want to see a preview?) and I never want EXIF thumbnails, but there's no way to save those settings. I tend to hack them in my own copy of GIMP, but I'd love to do a patch for JPEG save that would remember all the options in the dialog, across sessions. Is there any chance that would be accepted? I know there's a proposal in bugzilla to write a general mechanism for all plug-ins to remember their settings; but that proposal has been there through three major releases and there's no consensus on how to do it, and in the meantime, fixing JPEG save is something that could potentially help a lot of people. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] alignment rotation
Jay Smith writes: My desire would be for: click (on first point) click (on second point to finish the line) do a keystroke command that can be accomplished with ONE hand to execute the task (I would prefer not to have to hit the Enter key) You could perhaps do this with a plug-in: - Use the Paths tool - Click on first point, then on second point (now you have a straight-line path with two endpoints) - Run a plug-in (which you can assign to any key you like) that gets the current path endpoints, rotates the current layer the appropriate amount, then deletes the path. It would be an easy plug-in to write. You would stay in the Paths tool and not have to switch tools at all. Would that do what you want? It would still be a useful feature to add to the Rotate tool, and that discussion should continue; but since any change to a tool won't be available until the next major version, this might be a workaround that you could use right now. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position
Liam R E Quin writes: 5) zoom in on the place where you want to work, a step at a time, gradually moving the floating selection 6) when you get to 50% or 100% so you can work, try to remember why you wanted whatever you pasted. Why you think that's a smoother workflow than 1) paste so floating selection appears on the screen 2) continue working is beyond me. I've found the paste centers behavior quite useful, and have recommended it to lots of other people as a quick way to center a layer (which used to be a FAQ, though less so now that the align tool exists). That said, it's hard to see an argument for anyone wanting to paste to a part of the image that isn't visible. Surely most people paste because they want to do something with the pasted layer, which requires it being visible on screen. Perhaps paste should center within the visible viewport? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] API for bringing up a Save dialog
On Fri, May 29, 2009 at 3:59 PM, Ryan Krauss ryanli...@gmail.com wrote: pdb.gimp_xcf_save(1, img, drawable, xcf_path, xcf_path) pdb.gimp_file_save(img, drawable, xcf_path, xcf_path) That leads into something I've been needing from Python: I'd like a way of bringing up a Save-as or Export-as dialog from a Python script. There's no API for this currently, as far as I can tell. If I call pdb.gimp_file_save like this: pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname, run_mode=0) it goes straight to the jpeg save dialog, or the png save dialog, or whatever, skipping the dialog that would let the user change the filename. I'd like to set the filename, but then give the user a chance to change it and to see or change where it's being saved. Would be be possible to add an API for this, or maybe an optional argument in gimp_file_save and the corresponding _export function? I can try to implement it and submit a patch, but I'd like to know if such an API would be acceptable, and how you'd want it to look. For instance, maybe pdb.gimp_file_save(img, newimg.active_layer, pathname, pathname, run_mode=0, show_save_dialog=True) Or, possibly, should the code be changed so that it always shows the save-as dialog if run_mode is interactive? It would change the behavior of existing scripts ... but only in the interactive case. David Gowers writes: The recently introduced Export framework may end up simplifying your situation.. It considers a file 'clean' only when it has just been saved to XCF (or xcf.gz, etc) format, and introduces a separate 'Export' action for producing a 'rendered result' in eg. PNG format. In the new framework, will gimp_file_save() fail if the filename isn't xcf? Will scripts need to be rewritten to call gimp_file_export instead? If authors have to rewrite their scripts anyway, making a small change to what run_mode=0 does at the same time might not be much of a problem. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
Sven Neumann writes: On Fri, 2009-05-29 at 10:18 -0700, Akkana Peck wrote: I need to show the dialogs because the plug-in needs to save a file (that's the whole point of the plug-in) and it seems like bad UI to pop up the JPEG save dialog without ever showing the user where the file is being saved, or offering them a chance to save it somewhere else. Then please add a sane user interface to your plug-in and pop up a file-chooser. The PDB was designed to allow plug-ins and scripts to call procedures in GIMP, not to pop up specific user interface elements. It is totally not suited for this kind of usage. I'm confused -- you say I should pop up a file chooser, then you say that's not what the PDB is for. Is there a non-PDB way to do this from a plug-in? Popping up a file chooser is exactly what I'm trying to do. But I'd ideally like it to be the gimp file chooser with the image file types, not a generic GTK file chooser (just for consistency, because the GIMP dialog is what the user expects to see elsewhere in gimp). That's why I was asking for an API to do that. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scrollwheel actions by default?
Jernej Simončič writes: I'm all for it - in my experience, the wheel is useless for scrolling the images (partially because it's limited to single direction only), but works very nicely for zooming in and out (and if you combine this I use the mousewheel for scrolling quite often, especially when I'm making a selection with polygonal select or quickmask so I'm zoomed way in to see pixel details. I find the - and +/= keys convenient for zooming in and out (and 1 for going to fullsize), so I've never needed mousewheel zooming. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Martin Nordholts wrote: I would just like to point out that the smallest screen size supported by GIMP is 1280x1024, so we don't need to make 1024x768 work or look good. SHIRAKAWA Akira writes: Yes, I've read that many times and I would agree with it too since anything lower than that resolution is rather old gear. Not at all -- there are thousands of netbooks sold in this year with 1024x600 resolution. I'm sure nobody considers a netbook an ideal graphics platform, but it's nice to be able to do a quick edit when you're traveling. And lots of small non-netbook laptops still have only 768 pixels vertically. But more important, 1024x768 is the max resolution supported by most projectors, so anyone trying to teach a GIMP class or give a talk needs that resolution. That may be some people's first exposure to GIMP, so I hope the UI doesn't change to be unusable on projectors, one of those programs where windows have a minimum height and disappear off the bottom of the screen. Currently GIMP works fine at 1024x768. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Panels disappearing when changing workspace
Alexandre Prokoudine writes: On Thu, Aug 6, 2009 at 1:16 AM, Sven Neumann wrote: I'd rather open a bug-report against your window manager. That would be Metacity, which is declared getting obsolete and has over 400 (IIRC) not closed bugs . It's been reported against at least 4 different window managers so far: metacity, xfce, openbox and windowmaker. It's not just metacity. It makes gimp quite a bit more difficult to use under those window managers -- it's what's been keeping me from using git GIMP for anything more than quick tests. There are also some reports of similar behavior on Windows; I'm not sure whether it really is the same issue, not being familiar with the Windows problem, but Michael Schumacher thought so when he marked bug 566196 a dup of 556896. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] We should go for a single-window mode in 2.8
peter sikking writes: hey guys, I have now blogged about the single-window mode: http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html I was really getting excited about getting tabs in the image window (the image parade idea would achieve a similar function), since it would make it so much easier to group similar images together when I open them all at once. But it looks like if I want that, I have to switch modes to single window mode, and then I give up two important features: 1. The ability to open an unrelated image quickly in another window. For instance, I'm editing 7 photographs from the same trip, and suddenly I need to make a quick change to a 250x50 web icon, placing that window near the browser to see how it will look. It doesn't make sense to open that image in the big window I'm using for the photos. 2. The ability to open a second view on the image I'm editing, zoomed to whatever level I need and placed somewhere that's not on top of the current image. It's fine if second views are view-only Polaroids; but if it's always zoomed out and placed partially on top of the current image, it won't serve the function that Views currently serve now. Is there any chance you might allow those features to coexist with tabs / image parades? It looks like you'll still allow the toolbox and docks to be torn off; please consider allowing separate image windows and views too. Thanks! ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool Presets (was easily switch to last used tool)
On Sat, Jan 9, 2010 at 8:21 PM, peter sikking pe...@mmiworks.net wrote: so per-tool presets would be the solution for your case Alexia Death writes: May it be noted that the tool presets of this nature already exist. they are just terrible to use. those little buttons and menus in tool options suck. So perhaps we could just start with making those tool presets usable? The biggest problem I have with the current tool preset UI is that Save and Restore look almost identical, but Save is destructive. More than once, I've clicked on Save intending to choose (Restore) one of my presets. A menu pops up with a list of the current settings, so I choose the one I want -- and I end up overwriting that setting. And there's no Undo, so now I have to stop what I'm doing, go figure out what those settings were, set them by hand, Save them again, and finally I can get on with editing the image. I finally learned never to click either of those buttons without first hovering over it and waiting for the tooltip, to make sure it's absolutely positively the right button. Without any real redesign, it would help a lot to have a heading on that menu that says Save options in bold -- so it's possible to tell that you're about to overwrite something before you do so. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GIT: window hints and text move
Michael J. Hammel writes: I start 2.7 in one workspace, then switch to another, then back to the GIMP workspace. The toolbox and docks are gone - I can't find them in any workspace. Only the image window remains visible. Tabbing doesn't change anything. [ ... ] I searched but the closest I found was #595708. Not sure if this is related or not. Bug 556896. With GIMP 2.6 Metacity works fine. Seems a bit of a stretch to force people to change window managers with 2.7 just so it doesn't do this. Agreed. It works if you use Utility window as the hint for the toolbox and docks, but then they stay on top of the image window unless you hide them completely with Tab. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] moving windows in the git version
Olivier writes: For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same. https://bugzilla.gnome.org/show_bug.cgi?id=608834 That also has a workaround, if you want to patch your local version so you can use gimp in the meantime. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
Luiz Felipe Moraes Pereira writes: Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. This used to annoy me a lot, because I frequently want to delete, say, the top 5 layers. But once I figured out what it was doing, I developed a habit of clicking on the layers I want to delete in sequence before deleting. For instance, click on the 5th layer from the top, then the 4th, and so on until I get to the top; then click Delete 5 times. It sounds tedious but it doesn't take long at all -- certainly it's a lot faster than scrolling back up each time. Try it -- you may find that it solves the problem. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Text color change
Thales img writes: Is there any way to change the color of part of a text? Like this: This wordis red I'm asking 'cause if there isn't an easy way is something to think about. Probably the easiest way is to use bucket fill and click on each of the letters. Note that that will change the layer into a graphics layer and lose the special text information, like font and size. A more elaborate, but more flexible, way, is to make a new layer on top of your text layer. Make a selection in that layer covering whatever part of the text you want in a different color (e.g. a rectangle covering only that word). Fill the rectangle with your desired color. Then, in the Layers dialog, set the mode of the new layer to Lighten Only. If your text was black, that will turn the word your desired color. If you started with a different color of text, you might need a different layer mode (experiment with all of them). Depending on your background color, this might also change some of the background around the text, but there are some ways to get arond that. Merge down on the layer will merge it only with the text layer below it, or you could use the text layer as a mask to mask off everything but text in the color layer. The best approach depends on exactly what effect you're trying to achieve and what colors are involved. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Trying to Make a Plug-In
Callie writes: Hey guys, I have very limited experience in programming, and none at all with making plugins, but I want to make a plugin that would make my life a whole lot easier. Unfortunately, it seems that all the information regarding this process is written for people who are experienced in programming or writing plugins or such, and is unintelligible to me. I wrote a pair of articles a while back for Linux Planet on writing GIMP plug-ins in Python. Although there wasn't space to teach Python from scratch, I tried to write even for people who don't have much programming background: http://www.linuxplanet.com/linuxplanet/tutorials/6720/ (part I) http://www.linuxplanet.com/linuxplanet/tutorials/6734/ (part II) My first question would be, what language should I be using and how do I set it up so that it will work. Assuming you have GIMP Python support already installed (do you have a Filters-Python-fu menu?), most people find Python easier to read than Script-fu. But Script-fu does have the advantage that there are lots of scripts available to copy, and you can count on it already being installed. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Addressing one of the gimp vision items...easy installation of plug-ins
Martin Nordholts writes: On 05/14/2010 04:13 PM, Rob Antonishen wrote: - GIMP should be easily extensible by the average user: one click-installation of plug-ins [...] I agree installation of plug-ins is a pain, but I'm not aware of anyone planning to work on improving the situation. Writing a file handler like Rob describes sounds easy -- if all you care about is script-fu. The hard part would getting Python and C plug-ins installed for users (especially Windows users) who don't have Python, PyGTK or a C compiler. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] current git version: weird behavior in a detached menu
Olivier writes: Git version compiled today on Ubuntu 10.04. Using a right-click in the Image window, I detach the Image - File - Create menu. In this detached menu, the menu entries work as customary. However, the simple entries, for example Screenshot, have no other effect than to display a comment iin the bottom of the Image window. That's true for 2.6.8 as well. Sometimes they work, mostly they don't. It might be something to do with the GTK (2.20.1) installed on 10.04. I really miss those tear-off menus. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color circles (Thank you.)
Patrick Horgan writes: I'm sitting here whipping out a picture of a RGB Venn diagram with text labels with a recent pull from trunk in single window mode. [ ... ] p.s. http://dbp-consulting.com/RGBVenn.png p.p.s The venn diagram is done with 5 layers. Top to bottom: I agree -- it's great how easy GIMP makes this task. I have a script for that, which I wrote mostly so I didn't have to position the three circles by hand: http://shallowsky.com/software/gimp/colorcircles.scm I use three layers, in Addition mode, but that requires that the background layer be black. For subtractive colors, use Subtract mode and a white background. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] IRC session on how to build GIMP
Are you a GIMP user or Summer of Code student who's been wanting to get involved, but having trouble building, or a bit intimidated by the build process? I'll be running a session on IRC to help anyone build GIMP on Linux, as part of the OpenHatch Build it project. The session will take place on #gimp on irc.gimp.org (also known as GimpNet), on Fri, Apr 15, 0300 UTC -- that's Thursday night in the Americas. To convert to your time zone, run this command on your local machine: $ date -d 'Fri Apr 15 03:00 UTC' Or try this link: http://www.worldtimeserver.com/convert_time_in_UTC.aspx?y=2011mo=4d=15h=3mn=0 This is a time that's usually fairly quiet on #gimp -- European users don't fret, since it's pretty easy to get help there during more Europe-friendly time zones. I'll hang around for at least two hours; that should be plenty of time to build GIMP and all its prerequisites. Note: The #gimp IRC channel was recently under attack by trolls, and it's possible that it may not be usable at the time of the session. I've also posted this on my blog, and in case of trolls I'll update the blog page with the name of an alternate channel to use. http://shallowsky.com/blog/gimp/gimp-buildit.html Preparation: If you want to get your system set up ahead of time, I've put the instructions needed to build on Ubuntu Lucid and other older Linux distros here: Gimp Building Tips (for Linux). I might be able to offer a little help with building on Macs, but no guarantees. Mac and Windows users, or people running a very old Linux distro (more than a year old) might want to consider an alternate approach: install Virtualbox or VMware and install Ubuntu Natty Narwhal (currently still in beta) in a virtual machine. Of course, this isn't the only time you can get help with building GIMP. There are folks around on #gimp most of the time who are happy to help with problems. But if you've been meaning to get started and want a good excuse, or you've been holding off on asking for help ... come hang out with us and try it! ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GLIB version error while compiling GIMP with MacPorts
Tim Chen writes: Note that one has to install gtk2 using command below to avoid some weird dependency problems Most Linux people have to recompile gtk2 (and its dependencies) to build GIMP now too. ImportError: could not import pygtk Did you build python-gtk? It's a separate package, with its own dependency set. Last time I watched someone try to build python-gtk from Macports, it turned out to be a lot easier just to download the tarballs and build and install them by hand. Macports wanted to bring in all kinds of crazy dependencies, including recompiling X and three different versions of Perl, all of them built from source. But maybe they've fixed the dependencies since then. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
