Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
Hans Breuer writes: > This is a regression of previous versions. IIRC it was caused > by the usage of gdk_eindow_new() with parameters 'in range' and > additional adjusted by SafeAdjustWindowRect and the code > later calling gdk_window_move with coordinates directly derived > from the current mouse cursor position. > Using SafeAdjustWindowRectEx in gdk/win32/gdkwindow-win32.c:996 > appears to fix it. I just committed changes to gdk/win32 (HEAD and gtk-2-2) that seem to fix these problems. In fact, I dropped SafeAdjustWindowRectEx() altogether, I don't think it's GTK's business to prevent an application from locating its windows outside of the screen if it wants to :-) And with multiple monitors, coordinates might be negative anyway. The main job of the fix was going through the handling of top-level window position and size in event generation and functions, and make sure that it matches GDK's convention (position is that of decoration, size that of client area). And in the Win32 API, usually both position and size include decorations. > I'm still using my somewhat hackish g_spawn_async version attached to > the bug report and don't have to restart at all under win9x during the > whole plug-in query phase. I'll look at g_spawn() improvements tomorrow, hopefully. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Feedback on 1.3 milestone
Hi all, Ummm - this is going to be a short mail. There wasn't any. Feedback, that is. There were a few comments in bugzilla (which is always welcome), but of the 1.3 milestone bugs, 3 have been resolved in the past 4 days. One of these was a duplicate bug, another was a simple patch application, and a third was a modification of some existing sources. 3 very easy bugs, but quite time consuming. Apart from that, 0. Not only have no bugs been closed, none have been claimed. I was hoping that people would chance their arm, say "I'll do that", and then, well, if it didn't work out they could get help on IRC, or give up. There's nothing wrong with that, and when the bug already includes a patch, that mlakes things all that much easier. But the flood of offers hasn't come. I am very grateful to the people who worked hard getting Bugzilla into a decent state. I was hoping some others who hadn't done that would step up to actually do a bit of coding. I have no more gimp time until camp, I'm afraid - my parents are coming to France to see me this week, and they're staying for a fortnight (you got the calculations right - they'll be here while I'm in Berlin). And Sven and mitch are snowed under, as usual, with outstanding stuff. There are quite a few easy bug fixes to be had in the 1.3 milestone - I posted a summary with bugzilla bug numbers a few days ago. I really hope that some of these features with patches outstanding make it into the gimp before the feature freeze, but unfortunately I won't be the one putting them in. See you all in Berlin, and happy GIMPing, 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: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
At 23:22 27.07.03 +, Tor Lillqvist wrote: [...] > >One irritating thing with GIMP on Windows currently is GTK bug >#112402, I really need to fix that soon. GIMP's toolbox and some other >windows are currently positioned with their title bar exactly off >screen. > This is a regression of previous versions. IIRC it was caused by the usage of gdk_eindow_new() with parameters 'in range' and additional adjusted by SafeAdjustWindowRect and the code later calling gdk_window_move with coordinates directly derived from the current mouse cursor position. Using SafeAdjustWindowRectEx in gdk/win32/gdkwindow-win32.c:996 appears to fix it. >There also seems to be some handle leak when GIMP is starting up and >queries all the plug-ins. Also, something needs to be done to #98737 >soon. (Perhaps related, I had to start GIMP at least four times before >it got past all the plug-ins and wrote out the pluginrc file.) > I'm still using my somewhat hackish g_spawn_async version attached to the bug report and don't have to restart at all under win9x during the whole plug-in query phase. Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > It's easier to handle for arbitrary shaped regions IMHO. Coolest would > be of course to provide a possibility to select a brush for the sample > area; the grey value would determine the importance of the pixel on a > given position. Selecting a black square brush would deliver the same > result as at the moment, a black circle would result in Photoshop > behaviour. Cool, yes; perhaps even sometimes useful but certainly not very intuitive. IMO a circle would be the most useful solution and providing alternatives will probably be more confusing than helpful. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimpwin32-io.h
Henrik Brix Andersen writes: > Removing the fallback definitions broke compilation on at least one > platform, namely GNU/Linux which doesn't define _O_BINARY and/or > _O_TEMPORARY. Most likely other unix-like platforms where affected as > well. Since Unix systems don't distinguish between "binary" and "text" modes for file I/O, there is no O_BINARY (or _O_BINARY) on them. As for O_TEMPORARY that isn't needed either, as the traditional, elegant, Unix method is to unlink the temporary file while still keeping it open. (And even if the functionality of those flags was needed on Unix, the names wouldn't have the leading underscore. It is a bit strange by Microsoft (well, what isn't...) to hide all the Unixish stuff they provide in their C library with a leading underscore, purportedly in order not to pollute the ANSI C namespace. As I see it, if you include non-ANSI headers like (or on Unix) in your code, you accept not to have a clean ANSI C namespace any longer. And, most traditional Windows programs include anyway, which pollutes the namespace like a 300 kg gorilla, with apparently no restriction at all on on what kind of identifiers it introduces.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
On Tue, 29 Jul 2003, Phil Harper wrote: > > > The shape displayed is what's used to sample, that's not a question. > > > Make it configurable doesn't seem like a good idea here. I guess most > > > people will agree that a circle is the natural choice. > > > >I don't. The colorpicker ist quite handy to determine the average color > >in some area and a square is much more natural to handle. Also for a > >circle to be somewhat usable you'd have to take the in/out coverage of > >the pixels under the radius into account or you'll get disturbing > >results for small sizes. > > i would tend to agree, if i want an average for an area i will usually be > after a square anyway, however, it would be good to have a checkbox to > switch between circular and "classic" behaviour, i don't know how much of a > concern this is but surely you should be keeping inline with what the > installed userbase are used to and are happy working with more than > pandering to the Photo$hop audience... I am inclined to believe that the different colour pickers are useful for different tasks and that it is worth while to include the various different colour pickers for the various different use cases. (Although it is entirely possible that you are not talking about exactly what I think you are talking about. Tired, need food.) -- Alan Horkan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Fwd: Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On Tuesday 29 July 2003 5:38 am, you wrote: > Hi, > > "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > > For example, this is the line in current gimp code that does the > > "merge mode" : > > > > sum = src1[b] + src2[b] - 128; > > > > It will be doable by typing: > > ED = E1 + E2 -0.5; > > I don't want to discourage you and it's certainly a nice > expert/geek feature but I doubt that the casual GIMP user wants to > type in any formulas. I know that. Thats why in the future, I want to make them loadable resources just like brushes and patterns. This way, less oftenly used layer modes could go packaged with the GIMP - or be put in a resources page - without cluttering the UI. And even those who will not like typing formulas may fell tempted to tweak a little the numbers - like the .5 to .7 above. Unfortunattely I cannot think, as I've said, of a graphical way to build such formulas. But...when it's time for it, maybe people here ont he list can give e some subjetions, and the raw formula writting canget put behind an "advanced" button. > Sven JS -><- --- -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
From: Daniel Egger <[EMAIL PROTECTED]> To: Sven Neumann <[EMAIL PROTECTED]> CC: Gimp Developer <[EMAIL PROTECTED]> Subject: Re: [Gimp-developer] Wrong terminology in color picker tool Date: 29 Jul 2003 13:39:02 +0200 MIME-Version: 1.0 Am Die, 2003-07-29 um 10.33 schrieb Sven Neumann: > The shape displayed is what's used to sample, that's not a question. > Make it configurable doesn't seem like a good idea here. I guess most > people will agree that a circle is the natural choice. I don't. The colorpicker ist quite handy to determine the average color in some area and a square is much more natural to handle. Also for a circle to be somewhat usable you'd have to take the in/out coverage of the pixels under the radius into account or you'll get disturbing results for small sizes. i would tend to agree, if i want an average for an area i will usually be after a square anyway, however, it would be good to have a checkbox to switch between circular and "classic" behaviour, i don't know how much of a concern this is but surely you should be keeping inline with what the installed userbase are used to and are happy working with more than pandering to the Photo$hop audience... Phil. -- Servus, Daniel << signature.asc >> _ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: St
From: Sven Neumann <[EMAIL PROTECTED]> To: "Joao S. O. Bueno" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Grain modes are just the beginning - was McFarland's Re: Startup Notification support... Date: Tue, 29 Jul 2003 10:38:02 +0200 Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > For example, this is the line in current gimp code that does the > "merge mode" : > > sum = src1[b] + src2[b] - 128; > > It will be doable by typing: > ED = E1 + E2 -0.5; > > as the custom layer mode. (E stands for "every channel". A is already > used for alpha - I myself dislike the "every", and will accept other > suggestions) > > The advantadges? Even the above formula throws information away - it > kees a better average than ADD layer mode. With the custom layer > mode, you willbe able to adjust the cnstante factor for every layer > on every image. > Thus if it is too light, with large white only areas, one will just > have to edit the layer mode expression from the above to: > ED = E1 + E2 -0.7; , for instance. I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas. Sven well, it's certainly something that is of interest to me, and surely it wouldn't be a problem to have the extra layer modes at the bottom of the drop down list as well as a create new mode option which can optionally add it to a user list of modes or just save it in the XCF being processes. just an idea, and sorry if it's already been covered. Phil. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
Am Die, 2003-07-29 um 13.52 schrieb Sven Neumann: > How is a square more natural to handle than a circle? All other apps > I've seen so far use a circle. It's easier to handle for arbitrary shaped regions IMHO. Coolest would be of course to provide a possibility to select a brush for the sample area; the grey value would determine the importance of the pixel on a given position. Selecting a black square brush would deliver the same result as at the moment, a black circle would result in Photoshop behaviour. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Re: Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On Tuesday 29 July 2003 1:25 am, Patrick McFarland wrote: > On 28-Jul-2003, Joao S. O. Bueno wrote: > > It will be doable by typing: > > ED = E1 + E2 -0.5; > > > > as the custom layer mode. (E stands for "every channel". A is > > already used for alpha - I myself dislike the "every", and will > > accept other suggestions) > > > > The advantadges? Even the above formula throws information away - > > it kees a better average than ADD layer mode. With the custom > > layer mode, you willbe able to adjust the cnstante factor for > > every layer on every image. > > Thus if it is too light, with large white only areas, one will > > just have to edit the layer mode expression from the above to: > > I have no issues with E. It might also be nice to have YUV > (independant of the image's mode). I have implemented R G B, H S V, and A besides E. BTW, E doesn't affect the alpha channel - as the majority o f the fixed combination modes do not. - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On 29-Jul-2003, Sven Neumann wrote: > I don't want to discourage you and it's certainly a nice expert/geek > feature but I doubt that the casual GIMP user wants to type in any > formulas. No, but I doubt the casual GIMP user cares about a feature they arnt smart enough to use yet. AFAIK this isnt a replace ment for all modes, just an additional mode. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > I guess I don't really understand your question. Do you want to know > whether it makes sense to display the shape actually used for sampling > or whether to use a circle instead of a square? > I'd say: Make the shape configurable and always display the correct one > in the image. The shape displayed is what's used to sample, that's not a question. Make it configurable doesn't seem like a good idea here. I guess most people will agree that a circle is the natural choice. Actually there was no question, it was a hint to whoever feels this is important enough to be changed. It should be a very simple hack. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
Hi, Daniel Egger <[EMAIL PROTECTED]> writes: > I don't. The colorpicker ist quite handy to determine the average color > in some area and a square is much more natural to handle. How is a square more natural to handle than a circle? All other apps I've seen so far use a circle. > Also for a circle to be somewhat usable you'd have to take the > in/out coverage of the pixels under the radius into account or > you'll get disturbing results for small sizes. Of course I assumed a correct implementation. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong terminology in color picker tool
Am Die, 2003-07-29 um 10.33 schrieb Sven Neumann: > The shape displayed is what's used to sample, that's not a question. > Make it configurable doesn't seem like a good idea here. I guess most > people will agree that a circle is the natural choice. I don't. The colorpicker ist quite handy to determine the average color in some area and a square is much more natural to handle. Also for a circle to be somewhat usable you'd have to take the in/out coverage of the pixels under the radius into account or you'll get disturbing results for small sizes. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > For example, this is the line in current gimp code that does the > "merge mode" : > > sum = src1[b] + src2[b] - 128; > > It will be doable by typing: > ED = E1 + E2 -0.5; > > as the custom layer mode. (E stands for "every channel". A is already > used for alpha - I myself dislike the "every", and will accept other > suggestions) > > The advantadges? Even the above formula throws information away - it > kees a better average than ADD layer mode. With the custom layer > mode, you willbe able to adjust the cnstante factor for every layer > on every image. > Thus if it is too light, with large white only areas, one will just > have to edit the layer mode expression from the above to: > ED = E1 + E2 -0.7; , for instance. I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
Hi, Patrick McFarland <[EMAIL PROTECTED]> writes: > Actually, you probably should really convert. "Convert to Pixels" > would infact destroy the "text" object, and make it a real > image. And of course, while destroying the "text" object, you can no > longer edit the text. The text layer is always a real layer, but rest assured, you won't notice the difference at the user interface level. It's just a fact that we could include the possibility to restore the text later and I wonder if we should do that. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
