Re: [Gimp-developer] "Save As" dialog bug?
Hi, "Steven P. Ulrick" <[EMAIL PROTECTED]> writes: > please find two screenshots of the "Save As | Determine File Type:" > menu. If this is a new feature, or if it's a new feature that just > doesn't work yet, please let me know :) I really can't think of any > better way to describe this other than letting you see for yourself what > I'm talking about. This is a known GTK+ bug. There's that new feature that makes the menu scrollable when it doesn't fit on the screen but obviously it sometimes also does this when the menu would fit on screen just perfectly. Actually this problem was supposed to be fixed quite a while ago but it somehow reappears with latest GTK+. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshot plug-in status
Hi, "Michael Schumacher" <[EMAIL PROTECTED]> writes: > > While a Screenshot plugin can be useful (easy enough to discover) it was > > never what I really what I wanted as a windows user. > > > > Rather I would have much preffered to be able to simply use the built in > > Print Scrn (or Alt+Print Scrn to grab just the current window) and paste > > that into the GIMP. Perhaps you should use GNOME then ;) Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] "Save As" dialog bug?
Hello, Everyone :) At the following location: http://www.faith4miracle.org/gimp-ScreenShots.tar.bz2 please find two screenshots of the "Save As | Determine File Type:" menu. If this is a new feature, or if it's a new feature that just doesn't work yet, please let me know :) I really can't think of any better way to describe this other than letting you see for yourself what I'm talking about. The first screenshot is of the above mentioned menu/dialog exactly as it appears when you click on the "Determine File Type:" menu, before I scroll down using the down arrow, to get to the other filetyoes. The second screenshot is what that same menu looks like after I scroll to the bottom. (In the second screenshot it actually looks like it used to in previous versions of Gimp-1.3x, and how I thought it was supposed to look based on how it looked in the 1.2 series of the Gimp. Like I said, if this is a new feature and I just don't understand it, please let me know :) Steven P. Ulrick ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshot plug-in status
On 10 Sep 2003 at 20:18, Alan Horkan wrote: > While a Screenshot plugin can be useful (easy enough to discover) it was > never what I really what I wanted as a windows user. > > Rather I would have much preffered to be able to simply use the built in > Print Scrn (or Alt+Print Scrn to grab just the current window) and paste > that into the GIMP. This works perfectly for me with GIMP 1.2 and 1.3. I assigned shortkeys to the corresponding menu options in the Edit menu. Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshot plug-in status
On 7 Sep 2003, Sven Neumann wrote: > Date: 07 Sep 2003 13:17:47 +0200 > From: Sven Neumann <[EMAIL PROTECTED]> > To: Tor Lillqvist <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> > Subject: Re: [Gimp-developer] Screenshot plug-in status > > Hi, > > Tor Lillqvist <[EMAIL PROTECTED]> writes: (slightly Offtopic and delayed reply) While a Screenshot plugin can be useful (easy enough to discover) it was never what I really what I wanted as a windows user. Rather I would have much preffered to be able to simply use the built in Print Scrn (or Alt+Print Scrn to grab just the current window) and paste that into the GIMP. Unfortunately the GIMP only me to choose File, Aqquire, From Clipboard. Could pasting from the system ClipBoard be setup in such a way as to allow me to directly paste screenshots without needing to take the extra few clicks to Aquire from clipboard or use the Screenshot plugin? Should I file an enhancenment request in bugzilla? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
4.) The old eraser should be replaced with an 'Erase' - mode for the paint tools (Brush, Pen, Airbrush, Ink, Text, Fill), to be able to use e.g. the Airbrush as Eraser, this would make the interface less cluttered and also improves the flexibility. Same goes for the 'Smudge', 'Blur', 'Paint using Patterns' 'Sharpen' tools; Ok, here is how Deluxe Paint would deal with this: painting with right mouse button instead of the left would use the Background color, instead of foreground. In the GIMP, while it is not possible to make such a ssue to the right mouse button, there could, and IMO should, be a fast keystroke (mnemonic?) to swap BG and FG. It is great for a couple of fancy effects to be able to quicly switch between fg/bg without moving the cursor. That's not what I meant, I meant the eraser, not the bg color. But you are right on the keystroke, this would be a great addition. As for the eraser tool, it is currently the only of the paint tools that paints to transparency without the need to paint on the mask. Besides, the behavior of the "ctrl" key in it comes close, if one is paiting on the background, of the color swapping feature. And this is exactly the problem, only the eraser tool paints to transparency. And it should be possible to use ANY paint tool to do this. It could be as simple as reversing the alpha value for this tool... Alpha/ erase != bg color (at least if you use more than one layer). Have you entered this issue as a enhancement bug to Gimp bugzilla? If not would you do it or I could do it, because IMHO it would be a really good thing to have. I think it's pretty orthogonal to having alpha value in color picker and selector, because it could simply paint to full transparency (based on the properties of the brush and kind of a paint tool). In case of images without alpha channel it would simply paint to background color. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Edit Alpha as Mask
Sven Neumann <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: > >> - If necessary, fill the remaining purely transparent parts with a >> color of your choice, since according to the logic of the designers >> of the program they conceptually have no color at all. > >I think you misunderstood some discussions or you wouldn't talk such >a nonsense. You're probably right here. I thought that the generally accepted opinion was that zero alpha implied undefined color info, and the anti-erase etc. was just a hack from that point of view and it could be removed in future. >On a related note: In 1.3 we introduced the possibility to initialize >the mask from the layers alpha channel. This is still unfinished since >it should probably transfer the alpha channel to the mask by making >the layer all opaque. The open question here is if this should be the >default behaviour. It might be confusing since the other ways of >initializing the layer mask don't touch the layer's alpha channel. >Any opinions on this, anyone? I think that many people (including me) would expect to have this feature, and I'm eager to see it implemented. My suggestion to avoid confusion is to offer two options instead of one when creating the mask: - Copy from Alpha channel - Move from Alpha channel or alternative wordings such as Copy/Move Alpha to Mask. I think that the emphasis on the copy/move words while keeping the rest of the sentence unchanged will make it clear for everyone that they behave differently and that Alpha info will be deleted after a "move" operation. -- Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Edit Alpha as Mask
I failed to send this to the list yesterday. I have a proposal to the matter of editting the alpha channel as mask, as follows: Original Message Subject: Re: [Gimp-developer] Edit Alpha as Mask Date: 10 Sep 2003 13:04:27 +0200 From: Sven Neumann <[EMAIL PROTECTED]> To: Joao S. O. Bueno <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: >(...) Yup... Instead of changing the alpha channel when adding a layer mask, create an option besides "apply layer mask". I think "Replace layer alpha with mask" would be descriptive enough and add the needed functionality, You are bringing up a completely new point here and I think you want to repost this to the list. Sven -- J.S. -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Making the color picker tool grab the alpha value
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > So, here is my idea: we postpone this 121331 for 2.2 , and instead of > automatically picking opacity with the color picker, change the GIMP > in a way that thre is a current opacity, choosen as the alpha > component of the current foreground color, and therefore, updated by > the color picker. And in each paint tool, let there be added a > checkbox that will make The GIMP use that tool opacity slider value > or the Current Opacity, selected with the foreground color. > > What do you say Sven? To me this sounds quite complicated and it will certainly introduce a couple of problems like for example http://bugzilla.gnome.org/show_bug.cgi?id=120912 Since you failed to describe a usage scenario so far, I don't see how this change would improve the user experience. So far I can only see how it makes both the code and the user interface more complex. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] WikiWordOfTheDay
Raphaël Quinet wrote: > On Mon, 8 Sep 2003 11:52:10 +0200, David Neary <[EMAIL PROTECTED]> wrote: > > Solution: For a given topic, create a wikipage. Make a start on > > it (sketch paragraphs/sections, basically set up the bare bones > > of what is needed). And then propose that lots of people make > > small contributions to it. > > > > We have a wiki (many people might not know that - it's at > > http://wiki.gimp.org/gimp), which allows just such collaborative > > effort to take place. [...] > > A wiki is nice for drafting some things, but I am not too fond of > using it for the help system: it would be OK for discussing some > ideas, but not for publishing the final result. That was my intention in the proposal. The general idea would be to use the wiki as a means of generating docs, not as a way of replacing either www or the help team :) As I said above, it is for collaborative effort in content generation. > A wiki makes it too easy to add lots of WikiWords that remain empty or > unmaintained for a long time. Unless there is a strong community > interested in keeping the wiki up-to-date and refactoring old entries, > many wikis end up being a collection of very valuable contributions > mixed with content-free pages. Unfortunately, most visitors do not > know which WikiWords are interesting and which ones are not, so it is > not always easy for them to find what they are looking for. Certainly, a bit of discipline is needed. To start with, the front page should have 0 dead end wikiwords. That will happen, but not until the proof of concept (that is, that people will write docs together on this thing) has been proven. I'm willing to put some effort into getting things started, and I have been happy to see a couple of other people embrace the idea (notably Roman Joost, hi Roman), but if it becomes clear in a couple of weeks that I'm wasting my time, then I'll stop, and it will die as an idea :) One part of making it work is the adoption of the docs generated by the various projects which are more stable in terms of content - the website, developer.gimp.org and the help project. I hope that adoption will happen when the content merits it (or that comments will be added explaining why it doesn't merit it). > Now, don't get me wrong: I like wikis in general. But I doubt that a > GIMP wiki will really take off and keep on running for a long time > (picture me skeptical about "if you build it, they will come" - or > more specifically "they will keep on coming"). We already have enough > problems getting contributors for any part of the GIMP (application, > plug-ins, help system, web site) so we should be careful about > introducing a new area in which people could invest some time. The interesting thing about the wiki from my point of view is the total divorcing of technology and content. You don't need to know html, xhtml, docbook sgml, docbook xml or any other markup to generate pages which look OK. That means that there's a low barrier of entry. And it makes it easier to contribute docs. Perhaps it'll take off... > A GIMP > wiki can be very useful for discussing drafts and proposing new > content that will eventually be migrated to the help system or to the > main web site, but the content would have to be migrated over to its > destination instead of staying on the wiki. Otherwise, I am afraid > that it would sooner or later lose focus. I think it could be kept in both. But yes, I never intended (nor did I imply) that the wiki should replace the existing content deployment systems. > That's all IMHO, of course. If I am the only dissenting voice, you > can ignore me. ;-) In fact, I hope that I am wrong and that we can > have a strong community of contributors. Consider yourself ignored ;-) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Making the color picker tool grab the alpha value
Em Sex 05 Set 2003 7:31 AM, Sven Neumann escreveu: > Hi, > > "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > > As I stated on the answer to Willie Sippel, > > I liked the idea of the color picker tool to pick de alpha value > > of a pixel. More specificaaly when c temporarily called using > > "control" while one is using another paint tool. > > The alpha value of the pixel or region picked would them set the > > "opaccity" of the tool one is using in the moment. > > > > I even suggested this as an enhancemnet at bugzilla (bug 121331). > > However, people need to like the idea for it to be done. > > > > So, what do you think? Should the color picker pick the alpha and > > set the opacity of the current paint tool, or not? > > I doubt that this would be useful in general. Actually I can only > imagine workflows where I would not want the color-picker to affect > the tool opacity. When doing retouching you usually set the brush > opacity to some lower value in order to carefully apply some color > where needed. While doing this you frequently pick colors from > other places in the image. In most cases these places are opaque > but you definitely don't want the brush opacity to change to 100%. > You want to pick up the color, not the alpha value. Hmmm...ok...Maybe "there is more than a way to use the GIMP".:-) Of course I would not have suggested that it I worked in the way you describe. So, here is my idea: we postpone this 121331 for 2.2 , and instead of automatically picking opacity with the color picker, change the GIMP in a way that thre is a current opacity, choosen as the alpha component of the current foreground color, and therefore, updated by the color picker. And in each paint tool, let there be added a checkbox that will make The GIMP use that tool opacity slider value or the Current Opacity, selected with the foreground color. What do you say Sven? And others, do you like the idea? This is too much for 2.0 right now, anyway. > > > Sven - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
