Fwd: Old and new [Re: [Gimp-developer] new default icon theme proposal]
.. I meant to send that to the list. Sorry if this is duplicated; gimpdev didn't show up on the list of recipients.-- Forwarded message --From: David Gowers [EMAIL PROTECTED]Date: Jun 21, 2006 10:59 PMSubject: Re: Old and new [Re: [Gimp-developer] new default icon theme proposal]To: Sven Neumann [EMAIL PROTECTED]After actually trying the new icon theme: * The Scissors icon is the only vague tool icon -- i think the semi-transparent areas should be colored darker. http://img.photobucket.com/albums/v449/neota/style/iconedit/blurry-scissors.png * The path and paths icon are somewhat indistinct: http://img.photobucket.com/albums/v449/neota/style/iconedit/indistinct-paths.png So I tuned them a bit, with the following results: http://img.photobucket.com/albums/v449/neota/style/iconedit/stock-path-16.png http://img.photobucket.com/albums/v449/neota/style/iconedit/stock-path-22.png http://img.photobucket.com/albums/v449/neota/style/iconedit/stock-paths-22.png http://img.photobucket.com/albums/v449/neota/style/iconedit/stock-paths-16.png Which perhaps can replace the current ones. Mainly, it hurts clarity to use antialiasing on 45 degree lines; but I also cleaned up all the antialiasing of the path line. * The Ink icon is the best -- clear, iconic, and attractive. * The Undo icon is a massive improvement on it's predecessor. * While the Duplicate icon is a little confusing at first, it's definitely more distinct and clear than it's predecessor. * The Convert To Indexed icon is wonderfully colorful -- reminds me of Rainbow Islands. ___ 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
you all took the blue pill didn't you? this is just another Aqua theme. if we do not count downloads, how come we worry about making it easy to use to the point where it looks like just another aqua-themed application? i appreciate the work that went into this, just i also know that mr. steiner prides himself with making a clean look. i would like you to consider that the word clean and the word icon contradict themselves in almost all of the meanings of those words. these icons are going to clash so much with my desktop. if we do not count downloads, then what is the reason that we seem to think that we have to develop/change it to be easier to use? because anonymous people in forums paste the same thing that some person wrote a few years ago? please at least provide the option to not go aqua carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposal for libgimpmetadata API
In order to improve the support for metadata (XMP and EXIF), I would like to move some of the code that is currently located in the plug-ins/metadata directory into a new library, libgimpmetadata. This library would be linked with all file plug-ins that support metadata. This includes JPEG, PNG, TIFF and maybe GIF, PSD, SVG and other file formats. The metadata is stored internally as an XMP packet inside a gimp image parasite (so it is transparently saved in xcf files). Instead of manipulating this parasite directly, the file plug-ins can use the libgimpmetadata library for getting or setting individual properties in the XMP packet, for merging EXIF data into the XMP packet or for generating an EXIF block from parts of the XMP data. Due to the need to generate JPEG thumbnails, the library adds a dependency on libjpeg. Sven asked for a review of the proposed API for this library, so here it is. Note that the library does not define new gobject classes or anything like that. This is simply a set of functions for accessing the metadata that is attached to the image (in a parasite that should be mostly opaque for the user). /* decode the given XMP packet (read from a file) and merge it into the metadata parasite. */ gboolean gimp_metadata_decode_xmp (gint32image_ID, const gchar *xmp_packet); /* generate an XMP packet from the metadata parasite */ const gchar * gimp_metadata_encode_xmp (gint32image_ID); /* decode the given EXIF block (read from a file) and merge it into the metadata parasite. */ gboolean gimp_metadata_decode_exif (gint32image_ID, guint exif_size, const gchar *exif_block); /* generate an EXIF block from the EXIF-compatible parts of the metadata parasite */ gboolean gimp_metadata_encode_exif (gint32image_ID, guint*exif_size, const gchar **exif_block); /* get the value(s) of a single XMP property */ gboolean gimp_metadata_get (gint32 image_ID, const gchar *schema, const gchar *property, GimpXMPPropertyType *type, gint*num_values, const gchar ***values); /* set the value(s) of a single XMP property */ gboolean gimp_metadata_set (gint32 image_ID, const gchar *schema, const gchar *property, GimpXMPPropertyType type, gint num_values, const gchar**values); /* delete a single XMP property */ gboolean gimp_metadata_delete (gint32 image_ID, const gchar *schema, const gchar *property); /* same as gimp_metadata_get() but simpler, for scalar properties */ const gchar * gimp_metadata_get_scalar (gint32 image_ID, const gchar *schema, const gchar *property); /* same as gimp_metadata_set() but simpler, for scalar properties */ gboolean gimp_metadata_set_scalar (gint32 image_ID, const gchar *schema, const gchar *property, const gchar *value); /* register a non-standard XMP schema prefix for use in get/set procs */ gboolean gimp_metadata_add_schema (gint32 image_ID, const gchar *schema, const gchar *schema_prefix); Example of use: - An image containing both XMP and EXIF information is loaded - Call gimp_metadata_encode_exif (image, exif_size, exif_block) to load the EXIF block into the gimp metadata parasite. - Call gimp_metadata_encode_xmp (image, xmp_packet) to merge the XMP information into the gimp metadata parasite. If some properties are present in both XMP and EXIF (this is very likely), the old EXIF information is overwritten: XMP always takes precedence. - Call gimp_metadata_set_scalar (image, dc, contributor, John Doe); to set the dc:contributor property. - Call gimp_metadata_set_scalar (image, http://ns.adobe.com/exif/1.0/;, UserComment, foo!); to set the exif:UserComment property. Here, the full schema URI is used but it would also be possible to use the exif prefix because this is a known prefix (standardized). - Call xmp_packet = gimp_metadata_encode_xmp (image); to generate a new XMP packet suitable for saving into a file. Most of the functions listed above are currently implemented in the metadata plug-in and exported in the PDB. So you can find a slightly longer description of these functions by looking in the
[Gimp-developer] proposal for better status bar messages (long)
Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools. Some of these different modes are already triggering changes in the cursor. However, this is not sufficient because some people may not see these different cursors and because the status bar messages are better for suggesting what modifiers could also be used. I consider the status bar messages to be a useful complement to these cursors. Note that these messages have to be short enough to fit in the status bar. They may not always fit if the image window is very narrow, but then the user who wants to read the messages can resize the window. The goal is to make the messages reasonably short so that they are entirely visible as often as possible. The suggestion to use some modifiers and the optional description of what these modifiers will do is put at the end of the message so that the essential parts are more likely to be visible. Also, some tools allow their mode to be changed permanently via the tool options and toggled temporarily via a modifier. For example, toggling between horizontal and vertical modes for the flip tool. A change in the tool option reverses the meaning of the modifier. The messages below suggesting (try Shift) or (try Ctrl) should probably be built dynamically depending on whether modifiers are pressed rather than depending on the mode of the tool (tool-op). And finally, most tools only consider the state of the modifiers before the first click for deciding to change their mode. This is the case for most selection tools (Shift/Ctrl for add/subtract/intersect), transform tools, zoom tool, etc. But there are some exceptions, such as siox and iscissors that only consider the modifiers after the area is defined. This has been discussed here a few days ago for the new selection tools. Below, I assume that the old behavior (modifiers considered only when starting) is the correct one because this is the one that brings the best consistency accross all tools. If you want to discuss this, please start a separate thread (new subject). PATH TOOL (app/tools/gimpvectortool.c) -- Most messages would remain unchanged, except that SHIFT would be replaced by Shift. For reference, here are the messages currently used, with the updated capitalization: Click to pick path to edit. Click to create a new path. Click to create a new component of the path. Click to create a new anchor. (try Shift) Click-Drag to move the anchor around. Click-Drag to move the anchors around. Click-Drag to move the handle around. (try Shift) Click-Drag to move the anchors around. Click-Drag to change the shape of the curve. (Shift: symmetrical) Click-Drag to move the component around. (try Shift) Click-Drag to move the path around. Click to insert an anchor on the path. (try Shift) Click to delete this anchor. Click to connect this anchor with the selected endpoint. Click to open up the path. Click to make this node angular. PAINT TOOLS (app/tools/gimppainttool.c) --- - When nothing has been drawn yet: Click to paint, or press Ctrl to pick a color. - After the first brush stroke: Press Shift to draw a straight line. (try Ctrl to pick a color) - While drawing a line (Shift pressed): distance Click to draw the line, try Ctrl for constrained angles. - While drawing a constrained line (Shift+Ctrl pressed): distance Click to draw the line. - While picking a color (Ctrl pressed): Click in any image to pick the foreground color. In these messages, distance is the distance shown as number followed by the current unit. For example, 123.4 pixels or 0.1234 m. Tools such as the eraser, convolve and smudge tools can also use these common messages, with some exceptions explained in their own sections below. It would be better to replace the verb draw by the appropriate action for the tool, if this is possible (I didn't check). For example: Press Shift to erase a straight line. COLOR PICKER (app/tools/colorpickertool.c) -- - While picking the foreground color: Click in any image to pick the foreground color. (try Ctrl, Shift) - While picking the background color: Click in any image to pick the background color. (try Shift) As mentioned above, the try messages would be different if the mode is changed permanently in the tool options (opposite meaning for Ctrl). RECTANGLE SELECTION
Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools. A little late to come up with that now. The status bar messages have been waiting for an update for quite a while now. But better late than never. If you want to see such messages in 2.4, hurry up, the string freeze is coming. RECTANGLE SELECTION (app/tools/gimpselectiontool.c, gimprectangletool.c) Some of the current status bar messages are defined in libgimpbase/gimpbaseenums.c. These messages are OK to describe the undo steps or for PDB help texts, but better messages should be used for the status bar messages. I would suggest that the selection tools are finished before status bar messages are being added. The current state is likely going to change and translators will go crazy if we change the messages over and over again. FOREGROUND EXTRACTION TOOL (app/tools/gimpforegroundselecttool.c) - The current messages are fine, except that I they should suggest to use Shift or Ctrl to add/subtract/intersect selections. Something like (try Shift+Enter, Ctrl+Enter) could be useful and accept the selection would be replaced by the appropriate action. However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter. That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Script-Fu procedure blurb review
Hi, a while ago we went over all plug-ins, reviewed the procedure blurbs and marked them for translation. The blurbs are shown in the image status bar and as menu tooltips. This hasn't happened for Script-Fu yet, even though the script procedure blurbs are shown in the status bar as well. Thus, we need to do the same for all scripts. Any volunteers for this job? This should happen real soon now, because we want to enter string freeze for 2.4 as soon as possible. Your help would be very much appreciated. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for libgimpmetadata API
Hi, On Wed, 2006-06-21 at 21:15 +0200, Raphaël Quinet wrote: Most of the functions listed above are currently implemented in the metadata plug-in and exported in the PDB. So you can find a slightly longer description of these functions by looking in the Procedure Browser and searching for metadata. If you are curious, you can also look in the code: plug-ins/metadata/metadata.c is where these functions are registered and plug-ins/metadata/xmp-model.c is where they are implemented. After moving these functions in the new libgimpmetadata library, they would still be exported to the PDB but probably renamed gimp-metadata-* instead of plug-in-metadata-*. I don't really understand that part yet. If the code is in a library that plug-ins can link to, why are the functions exported to the PDB and how exactly does this happen? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for libgimpmetadata API
On Wed, 21 Jun 2006 22:54:32 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 21:15 +0200, Raphaël Quinet wrote: [...] After moving these functions in the new libgimpmetadata library, they would still be exported to the PDB but probably renamed gimp-metadata-* instead of plug-in-metadata-*. I don't really understand that part yet. If the code is in a library that plug-ins can link to, why are the functions exported to the PDB and how exactly does this happen? The file plug-ins would not use these functions via the PDB because they could use the library directly. However, it is still useful to have these functions exported to the PDB so that they can be used by scripts. For example, if you want to have a script that automatically attaches a Creative Commons license to a file, it would only have to call something like this: gimp-metadata-set-scalar (image, xmpRights, marked, true) gimp-metadata-set-scalar (image, cc, license, http://creativecommons.org/licenses/whatever;) That covers the why. Regarding the how, it depends... My long-term goal is to move the metadata viewer/editor into the core (like other info dialogs and so on) because it would be the only way to ensure that it reflects the current state of the metadata while the image is being edited. This would solve some of the annoying concurrency problems: if you open the metadata editor (currently a plug-in), and save the image while the editor is open, then some changes to the metadata are lost because the parasite is modified by the file plug-in but the editor does not know it. I think that I mentioned this before or during the last GIMPCon. So if/when the metadata viewer/editor is in the core, then it makes sense for the core to export some of these functions to the PDB. But I am not planning on migrating the editor to the core right now. In the meantime, it may be better for the editor (the GUI part) to remain as a plug-in and then it would make sense for it to export these functions to the PDB. But even if these functions are temporarily exported by a plug-in, I think that it would be better to name them gimp-metadata-* in order to reflect the intent to move them into the core later, and to avoid breaking scripts that could start using them in the meantime. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, 21 Jun 2006 22:45:55 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: [...] However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter. That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter. Users may have a different understanding of what is meant by when the selection is actually created. Or different expectations. We know that it is only done at the end. But I would not be surprised that many users would consider the first click to be when the selection is actually created -- they probably do not care about the difference between a solid outline and marching ants, or between a masked foreground/background and marching ants. They probably consider only when they start defining that selection. Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for libgimpmetadata API
Hi, On Wed, 2006-06-21 at 23:53 +0200, Raphaël Quinet wrote: The file plug-ins would not use these functions via the PDB because they could use the library directly. The file plug-ins could as well use the functions via the PDB then. What's the benefit of linking to them? That covers the why. Regarding the how, it depends... My long-term goal is to move the metadata viewer/editor into the core (like other info dialogs and so on) because it would be the only way to ensure that it reflects the current state of the metadata while the image is being edited. I am somewhat reluctant to see such code in the core, or the core linking to it. Simply because experience shows that parsers aren't perfect and can crash. I wouldn't want to see the core crash because some camera manufacturer made a mistake and the camera creates images with corrupt metadata. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for libgimpmetadata API
On Thu, 22 Jun 2006 00:13:13 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 23:53 +0200, Raphaël Quinet wrote: The file plug-ins would not use these functions via the PDB because they could use the library directly. The file plug-ins could as well use the functions via the PDB then. What's the benefit of linking to them? Cleaner code (core/GUI separation, maintainable by different people), lower overhead (especially when changing many properties) and more importantly providing the start of a solution for avoiding the concurrency issues that I mentioned earlier. I am somewhat reluctant to see such code in the core, or the core linking to it. Simply because experience shows that parsers aren't perfect and can crash. I wouldn't want to see the core crash because some camera manufacturer made a mistake and the camera creates images with corrupt metadata. I understand your concerns. However, I do not see another way to view and modify the metadata in real time. Viewing the metadata should be like viewing any other image properties (info dialog) and doing this in a plug-in that does not know when the image or its metadata is modified means that the metadata displayed by the plug-in may not match the current data: wrong image dimensions, color space, etc. And worse, the plug-in may override some changes to the metadata if it updates it after ignoring other changes that happened outside of its control. With the current plug-in, you may get annoying results such as an image saved with the wrong thumbnail or with other incorrect metadata, just because you forgot to close the metadata editor before saving and to re-open it just after saving. This should not happen in the core. Besides, I try to have a parser that is as robust as possible. ;-) -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:08:34AM +0200, Rapha?l Quinet wrote: Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... i really tried to use siox this weekend. it is so confusing, i have no idea what to expect from it or if what happened to me was a bug. the default is foreground extraction. i wanted it to background extract and toggled this tool option. it toggled itself back to foreground and it also could not see an honest line that was in the image. a dark brown/gray area that ended in a very straight line before a very bright (luminescent even) area started (which was the background i wanted to extract. it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such. is the tool broken or are my expectations all wrong? i am honestly way to baffled to go to bugzilla with this even. it would be one heck of a status bar message to explain how to use this tool. also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful. is GIMP showing the help blurb or the about blurb from the scripts? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
Carol Spears wrote: it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such. is the tool broken or are my expectations all wrong? Can you provide and/or point out the image you tried it on? Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages
On Thu, Jun 22, 2006 at 12:49:22AM +0200, Michael Schumacher wrote: Carol Spears wrote: it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such. is the tool broken or are my expectations all wrong? Can you provide and/or point out the image you tried it on? it is the image that makes the tool options toggle? when i select background, it is wrong for me to expect that background continue to be selected or it relies on the image to retain the toggle? that is a really intelligent tool then that will not retain the tool option toggle depending on the image. i think that the problem with the tool should not have anything to do with 1) the image being worked on or 2) who is using the tool. should i expect that when i toggle the tool options that they stay toggled? thank you for responding, btw. it is an interesting environment where every user matters except for one. what kind of environment is this good for? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, Jun 21, 2006 at 03:36:53PM -0700, Carol Spears wrote: also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful. is GIMP showing the help blurb or the about blurb from the scripts? http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png fitting a whole tutorial into that area does not really seem as if it was the most helpful thing let me apologize to everyone whose little freesoftware project i have been involved in for how many years is it now? i really had to send mail out to say that $3000 was not worth it for a nice girl to get involved in something like how this project worked. if i am following the logic that i have received locally, i was one of the first people to have become successful with something like GIMP. $3000 would not have kept me from having real life problems like i did and do. it would have been the very very wrong thing to just let other girls or nice people fall into the same trap. it seems like california has all of the problems michigan did, just with gender removed. it is more wrong to use and discard people than it is to have been nice and unable to live up to those expectations. also, sorry if actually USING the software makes it difficult to report bugs with that language everyone insists on. the fact that i am using it and that i was successful with the project and the people when i had my life and stuff really ought to count for something. mostly i am sorry that this world does not allow a girl to be successful at something without spending the next few years trying to and maybe succeeding in destroying her. do you know what has not been in my life now since may of 2003? love. if there is no love in a life or in a project it is just going to suck for everyone. everywhere around me, love is bought and sold and traded or only used to make families. let me be somewhere where there is some love and maybe even my stuff and then feel free to complain if i am not being nice. no outlet for when there is a problem. no love. no acknowledgement. and the biggest problem is this. it really looks like a bunch of mean minded little males or malelike females who keep a calendar and know when to start being unreasonable. and there. this email is perhaps the best example of what is wrong when you fit a whole tutorial into what should be a small space. you can see from the screenshot that there are some real problems with this new thing. if i am to consider that the developers who work with this project are human beings and have real life issues that need consideration and also that whatever i expect from them is just my own idea and i should not actually expect anything -- when does that start from those same people back to me? in closing, one of the things that i really really remember from when everything started to go so badly and wrong is something that scizzo said. i am paraphrasing now: can we work next time as a team? i never ever wanted to be alone working on this stuff. never ever did i ever think that i could accomplish anything alone. who do i thank? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On 6/22/06, Carol Spears [EMAIL PROTECTED] wrote: http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png Okay. It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected. the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows. Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:09:24PM +0930, David Gowers wrote: On 6/22/06, Carol Spears [EMAIL PROTECTED] wrote: http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png well, i did not use the tool on that image. that image is my desktop and what is wrong with some of the third party scripts with this new tooltip thingie. Okay. It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected. i appreciate that you tried to use the tool and can verify that it is returning to the foreground setting like that. the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows. pathtool works the best for me. i want to write a tutorial for siox though so i have lately been trying to use this tool so that i can write one. it was suggested at the gimp convention that a tutorial should be written. you know how suggestions go, you try to take the good ones and ignore the wrong ones. at least, this is the approach i am trying to take. Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something. heh. i think that you are probably right about this. the situation is wrong wrong wrong wrong wrong for adrenaline running in my life right now. all i can do is sit and count the wrongs about it. this in itself is very frustrating. thanks for the verification, carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
