Re: [Gimp-developer] [Gimp-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Simone Karin Lehmann]

hhmm, well, just reading this whole thread here on the gimp-devel mailing list 
and on reddit, I really have to admit that Niccolo is right.

The very first posting of Niccolo on reddit, that I can find is an answer to 
another user about a new version for Arch Linux, in which he simply says

"No GTK 3..?“

and getting an answer from that user, that Version 3.0 will bring it. He than 
wrote

"Ah, I see.
Is there a release date? I've heard that it already works well…“

With all respect to anybody on this list and to Alexandre in special, I really 
can’t see any sign of ranting about GIMP or complaining in an inappropriate way.

After Alex joins in with his remark that…

"We don't do "release dates" :) We release when it's ready.“

Niccolo still answers, IMO, very politely and explains why, in his opinion, he 
thinks planned release dates are better than solely saying "we don't do release 
dates“ and explains how a smiley at the end of this sentence sounds to him and 
finally admitting that he might be wrong, though.

This, IMO, must have something triggered in Alex’s mind, because after quoting 
only a few words out of context, he confronted Nicollo with a totally new topic 
Nicollo never mentioned, just to compare this topic to his quote, only to force 
him to justify his opinion and laying the ground for further hitting on Niccolo.

Well, and so it came …

To me it seems, that if a user, who doesn't contribute to GIMP, and uses the 
slightest words of critisism of GIMP will easily run into a situation where he 
gets told between the lines, that he’s a dumb user, who doesn’t know anything 
about coding and therefor has no right to complain and either has to use GIMP 
as it is, submit a patch, simply should „downgrade“ to a well known commercial 
product or shut up.

And sorry to say so, it's not only Alex...

Although I know, that my posting here won’t change the situation, I couldn’t 
stand it not to write it. 

BTW, this attitude was one of the reasons I’ve taken my site gimp.lisanet.de 
 offline.

Simone Karin



> Am 16.11.2018 um 12:40 schrieb C R via gimp-developer-list 
> :
> 
> Happy you've found that support group you were looking for. :)
> 
> Wishing you a speedy trauma recovery,
> -C
> 
> On Fri, 16 Nov 2018, 11:04 Niccolo Brogi  
>> ...in the meantime, I'm getting emails from people that see the whole
>> thing exactly like me, and I assume fear harassment and won't say it out
>> loud.
>> 
>> How sad is this culture you've created.
>> 
>> On Fri, Nov 16, 2018 at 9:50 AM C R  wrote:
>> 
>>> As someone who has worked many years alongside (at the desk next to)
>>> customer service reps, I can verify that no amount of organisation or
>>> pleasantries can quell the entitlement of anyone who thinks you owe them
>>> something. Be that x feature in GIMP, or x release date for the next GIMP.
>>> People are very much the same in that regard, and it's crushing to have to
>>> deal with it all the time.
>>> 
>>> People can be banned from the mailing list if they make too much of a
>>> fuss, but I have to say Alexander's way of handling things is a nearly
>>> flawless mix of not taking any shit (which, after all, why should GIMP
>>> contribs suffer this after donating time to provide free software for the
>>> world?) and being concise and helpful to those who approach with a
>>> constructive attitude (as part of the community).
>>> 
>>> We have not always seen eye to eye on things, but I'm always learning
>>> stuff about handing trollish behaviour from this mailing list, thanks
>>> primarily to Alex, also recognising the behaviour in myself and doing my
>>> best to avoid making the same mistakes as people who can only complain
>>> rather than be helpful (Alex PMs me if I go to far to the ranty side, even
>>> in his defence). So that definitely isn't broken.
>>> 
>>> Alex saves us on a regular basis from having to deal with trolls on all
>>> our media platforms while keeping all ports of communication open for our
>>> users.
>>> 
>>> Every project should have one, but he's ours! ;)
>>> 
>>> Just my thoughts.
>>> -C
>>> On Fri, 16 Nov 2018, 08:17 Alexandre Prokoudine via gimp-developer-list <
>>> gimp-developer-list@gnome.org wrote:
>>> 
 пт, 16 нояб. 2018 г., 6:40 Trevor Rose tarose.tre...@gmail.com:
 
> 
> 3 — the solution to the problem is to tighten up your communications
> channels, and to use some other technology rather than just an email
 group,
> and in which alternative system a person must be logged in, and each
 post,
> thread and comment/reply is not only better organised, but can be
> identified as per user ID, GROUP, and ROLE ... PLUS AND MOST
 IMPORTANTLY
> you can constrain each unit of communication by using mandatory fields
 and
> filters, in order to force clearer communication and remove some
 amount of
> abuse, while also being able to ban anyone who takes their passion
 beyond
> an accepted th

Re: [Gimp-developer] [Gimp-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Simone Karin Lehmann]

> Am 16.11.2018 um 12:46  C R via gimp-developer-list 
> :
> 
> Well clearly he was harassing you with his facts and sarcasm.
> 
> You'll pull through though. I believe in you!
> I've got to go now though. Have fun with whatever this is.
> 

Thank you for your sarcasm. And most of all, thanks for staying away. 

I can’t believe, how you and others on this list, treat people, who don‘t share 
your point of view. 

Simone Karin Lehmann
- former contributor to GIMP and founder and maintainer of the 
GIMP-on-OSX-project. 

> 
>> On Fri, 16 Nov 2018, 11:42 Niccolo Brogi > 
>> Why, Alexandre causes trauma..? I thought he was nice.
>> 
>>> On Fri, Nov 16, 2018 at 12:40 PM C R  wrote:
>>> 
>>> Happy you've found that support group you were looking for. :)
>>> 
>>> Wishing you a speedy trauma recovery,
>>> -C
>>> 
>>>> On Fri, 16 Nov 2018, 11:04 Niccolo Brogi >>> 
>>>> ...in the meantime, I'm getting emails from people that see the whole
>>>> thing exactly like me, and I assume fear harassment and won't say it out
>>>> loud.
>>>> 
>>>> How sad is this culture you've created.
>>>> 
>>>>> On Fri, Nov 16, 2018 at 9:50 AM C R  wrote:
>>>>> 
>>>>> As someone who has worked many years alongside (at the desk next to)
>>>>> customer service reps, I can verify that no amount of organisation or
>>>>> pleasantries can quell the entitlement of anyone who thinks you owe them
>>>>> something. Be that x feature in GIMP, or x release date for the next GIMP.
>>>>> People are very much the same in that regard, and it's crushing to have to
>>>>> deal with it all the time.
>>>>> 
>>>>> People can be banned from the mailing list if they make too much of a
>>>>> fuss, but I have to say Alexander's way of handling things is a nearly
>>>>> flawless mix of not taking any shit (which, after all, why should GIMP
>>>>> contribs suffer this after donating time to provide free software for the
>>>>> world?) and being concise and helpful to those who approach with a
>>>>> constructive attitude (as part of the community).
>>>>> 
>>>>> We have not always seen eye to eye on things, but I'm always learning
>>>>> stuff about handing trollish behaviour from this mailing list, thanks
>>>>> primarily to Alex, also recognising the behaviour in myself and doing my
>>>>> best to avoid making the same mistakes as people who can only complain
>>>>> rather than be helpful (Alex PMs me if I go to far to the ranty side, even
>>>>> in his defence). So that definitely isn't broken.
>>>>> 
>>>>> Alex saves us on a regular basis from having to deal with trolls on all
>>>>> our media platforms while keeping all ports of communication open for our
>>>>> users.
>>>>> 
>>>>> Every project should have one, but he's ours! ;)
>>>>> 
>>>>> Just my thoughts.
>>>>> -C
>>>>> On Fri, 16 Nov 2018, 08:17 Alexandre Prokoudine via gimp-developer-list
>>>>> >>>> 
>>>>>> пт, 16 нояб. 2018 г., 6:40 Trevor Rose tarose.tre...@gmail.com:
>>>>>> 
>>>>>>> 
>>>>>>> 3 — the solution to the problem is to tighten up your communications
>>>>>>> channels, and to use some other technology rather than just an email
>>>>>> group,
>>>>>>> and in which alternative system a person must be logged in, and each
>>>>>> post,
>>>>>>> thread and comment/reply is not only better organised, but can be
>>>>>>> identified as per user ID, GROUP, and ROLE ... PLUS AND MOST
>>>>>> IMPORTANTLY
>>>>>>> you can constrain each unit of communication by using mandatory
>>>>>> fields and
>>>>>>> filters, in order to force clearer communication and remove some
>>>>>> amount of
>>>>>>> abuse, while also being able to ban anyone who takes their passion
>>>>>> beyond
>>>>>>> an accepted threshold/limit.
>>>>>>> 
>>>>>> 
>>>>>> Hi Trevor,
>>>>>> 
>>>>>> I'm afraid I'm not a big believer in

Re: [Gimp-developer] New GIMP configure warning/error

[Simone Karin Lehmann]

> Am 13.05.2017 um 15:50 schrieb Jehan Pagès :
> 
> 
> We have a few issues with our webkit internal browser, one of them is
> that we still use an old webkit version (because of GTK+2; newer
> versions are for GTK+3), which is therefore deprecated. Security wise,
> this is not fine. Though obviously since this browser is made only to
> reach our manual, which are static pages, and cannot be used to reach
> random pages, the risk is lessened. That's even more a reason to make
> sure we have SSL/TLS activated, because if GIMP requests the help
> browser to reach https://gimp.org, we want to drop the connection in
> case of MITM, especially because of the broken webkit.
> 
> This issue will disappear with GIMP 3, where we should be able to
> update the dependency. This will still be some work to do so. Maybe at
> this point, it could be wise to just drop the webkit dependency and
> make the browser do all the work. On the other hand, a minimal help
> browser is still nice. That's not an easy decision IMO.
> 
> We could also drop the help browser even for GTK+2 builds, but then it
> needs some minimal patch to not have GIMP consider this as a lesser
> GIMP. If not mistaken, when the browser is not built-in, right now
> GIMP would complain and display a popup asking you if you want to use
> your web browser instead. We would need to get rid of this warning if
> we start considering the system browser as the defaults display mode
> of the manual. That's probably really easy, but I have more pressing
> things I want to do for 2.10. Patches are welcome for discussion
> though. I believe it still makes sense in a security point of view
> considering the deprecated webkit we use, so I would be in favor of
> the patch (even if just as a temporary fix until we get to GIMP 3 and
> can migrate to newer webkit).
> 

I’ve just made those patches for OS X and included them into my version on 
gimp.lisanet.de. 
It just uses the system defined web browser for accessing online help and I’ve 
even written 
a plugin which replaces the help browser with the system-wide web browser and 
still offers 
context sensitive help. 

Just have a look at my patches at my SorceForge SVN repository 
https://sourceforge.net/p/gimponosx/code/HEAD/tree/GimpPorts/ports/graphics/gimp2/files/
They are just a few lines of Cocoa API calls...

Simone


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

[Simone Karin Lehmann]

> Am 12.05.2016 um 21:56 schrieb Michael Natterer :
> 
> 
>> What is the purpose of this new option? It doesn't do the same thing
>> as 
>> going to Preferences and selecting "Color Management/Mode of 
>> operation/No color management".
> 
> The prefs option is for display color management, and will soon
> only be a default for a per-display switch.
> 
> The option in Image -> New allows to disable color management
> and whatever color management transforms on a per-image base.
> 

Woooh, I can’t believe it! You’re saying that

> This is mainly because almost nobody understands what this
> whole color stuff is about at all.

Is this how you think about all the people who use GIMP? That almost none of 
them understands color management? 

May I remind you of your product vision? -> 
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

"GIMP is a platform for programming cutting-edge image processing algorithms, 
by scientists and artists"

Do you really think, that these targeted audience, your targerted audience, 
doesn’t know what color management is all a bout? Or, sorry to say so, is it 
that _you_ are the one that does not know waht different aspects of color 
management have to be taken care of in an image editor? 

> All (sic!) graphics artists
> I know and have asked switch off color management entirely
> in Photoshop because it's this confusing thing that changes
> colors in an unpredictable way  (which is not surprising
> given the cluelessness).

So, this is how you think about your target users? They are clueless? Your 
target users - professional artists and photographers - switch off color 
management, because it’s confusing them? Or is  it that the users _you_ know 
and the users who claim theirselves as professionals do not know what color 
manangement is and don’t know how to handle it?

So, may it be, that this - „all graphics artist you know … switch off color 
management - is the real cause why GIMP doesn’t have a working color management 
in 2016? You don’t know anybody who uses it and so you don’t see any need to 
implement it? 
Come on, let’s face reality. It’s 2016 and almost all software for image or 
photo editing I know is capable to handle color management. Yet GIMP 2.8.x is 
still broken in some parts….

Trust me, there are a lot, a really lot of professional users, artists, 
scientists and photographers - again I’ll remind you that these are your target 
audience as described in your product vision - who know what color management 
is about and who use it and want to use it in a correct and predictable way. 
Count me one of them.

> 
> Most people dealing with photos do know their colors however
> and have it on, and have the right profiles.
> 
> The sane choice way to let users disable it, rather than
> forcing it upon them

Well, this may be the sane choice for _you_ but, please, don’t tell others - 
your target audience: professional photographers, artists and scientists -  
what their sane choice has to be.

Regards
Simone Karin



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Export instead save directly

[Simone Karin Lehmann]

> Am 01.03.2016 um 15:05 schrieb C R :
> 
> If Save intelligently determines the file format that is most likely to be
> used to save, Export should not be necessary. Just "Save" and "Save As"
> would suffice.
> 
That's nearly exactly what I did with my patched version on 
http://gimp.lisanet.de
I even made this a configurable option in the Preferences dialog. 
So, if one is interested, have a look at my patches. 

> We could use the "multi layer" & "layer outside layer boundaries"

I'm currently testing only for 'multiple layers' but it's quite easy to add 
other tests. 

> convention to suggest that the user save to xcf, as normal to preserve what
> they are seeing in the editor. The workflow would just involve flattening
> the image (which also gets rid of alpha) first before saving to make the
> Save default to the imported file format as a save suggestion. This has the
> advantage of being intuitive and changeable merely by typing the required
> file extension. For my various workflows, 99 times out of 100, it would not
> be necessary to change anything.

That was the reason why I did it. And I got a lot of positive feedback from 
users of my package. 

> 
> I'd be lying if I said the current export convention didn't trip me up
> occasionally. It's been 6 years since I switched completely from Photoshop,
> so in my case, it's not really blamable on convention anylonger. :)
> 
> My 2p.
> 
> -C
> 
> 
> 
>> On 1 Mar 2016 8:43 am, "Tobias Ellinghaus"  wrote:
>> 
>> Am Montag, 29. Februar 2016, 23:57:10 schrieb C R:
 That would be terrible. Users not understanding the concept would
>> suddenly
 be
 facing images where they can just save to JPEG while others can't, but
>> PNG
 is
 still enabled (because they somehow added an alpha channel), and even
 other
 images support XCF only (maybe because the layer is bigger than the
 image).
>> 
>> (I used "just" in the sense of "without any further actions" and not
>> "only".)
>> 
>>> No, that's not what I'm suggesting. If you import a jpeg for example, do
>>> your editing, and end up with an alpha channel somehow, the save could
>>> still default to the .jpg (the jpeg save dialogue could display a warning
>>> that transparency will be lost). That does not prevent the user from
>>> requesting a .png (by specifying that extension). It also does not
>> prevent
>>> the user saving as an xcf either for that matter.
>>> 
>>> When closing the file, if the file is not saved as an xcf, and there is
>>> extra data to be lost, well, the warning about it is there anyway.
>> 
>> But that would mean to just go back to the status quo ante, i.e., revert
>> the
>> save/export dichotomy and bring back saving to arbitrary formats.
>> 
>> [...]
>> 
>>> My 2p.
>>> -C
>> 
>> Tobias
>> 
>> [...]
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> List membership:
>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP project's official statement on SourceForge's actions

[Simone Karin Lehmann]

Hi,

please don’t get me wrong, I don’t like software bundled with adware, toolbars 
or anything like that.

But...


> 
> An acceptable approach would be to provide a method for *any* project to
> cease hosting at any SourceForge site if desired, including the ability to:
> 
> 
> * completely remove the project and URLs permanently, and not allow any
>  other projects to take its place
> 
> * remove any hosted files from the service, and not maintain mirrors
>  serving installers or files differing from those provided by the
>  project or wrap those in any way
> 
> * provide permanent HTTP redirects (301) to any other location as
>  desired by the project


… how do these statements comply to the GPL? 

Doesn’t the GPL give everybody the rights to redistribute GPL’ed software in 
binary form as long as they fulfill the other requirements (providing source 
code)?

IMO, claiming not to set up a mirror with GPL’ed software for redistribution 
and not allowing other projects to redistribute GPL’ed software is AFAIK not 
compliant with the GPL. Even bundling GPL’ed software with proprietary software 
is possible as long as its not linked against GPL’ed libs. 

So how can a project which develops and publishes GPL’ed software ask somebody 
to give up the rights the GPL grants?

Or am I missing the point?

Regards
Simone Karin


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] sRGB was second worst performer against spectral reference

[Simone Karin Lehmann]

> Am 13.05.2015 um 07:52 schrieb Nicolas Robidoux :
> 
> "We won't provide any conclusions because the results in the given tests
> context are self explanatory."
> 
> This is another way to say: "Trying to put things in context so that the
> results are relevant to real life would expose us to criticism, so we'll
> say it's obvious so that other people get the dunce cap."


No, the conclusion is quiet easy. And it’s what Elle says for, AFAIK, more than 
a year.

Results of operations on RGB data depend on the given RGB primaries and will 
differ with different RGB primaries. So, all operations on user RGB data should 
only use user RGB primaries and not sRGB primaries or any other RGB primaries 
chosen by developers.

Simone Karin
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Simone Karin Lehmann]

> Am 12.10.2014 um 12:46 schrieb Øyvind Kolås :
> 
> On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone
>  wrote:
>> On 10/11/2014 08:52 PM, Jon Nordby wrote:
>> Please correct me if I misunderstood what you are saying. I think you are
>> saying:
>> 
>> GIMP uses GTK+.
>> 
>> GTK+ uses Cairo APIs for rendering to the screen.
>> 
>> Cairo APIs assume 8-bit sRGB.
>> 
>> Therefore in GTK+ applications such as GIMP, images must be converted to
>> sRGB before they can be displayed on the screen.
> 

> Cairo is just one part of our eco-system which is following the
> guidelines of how to integrate with color management even if you do it
> badly; assume sRGB.

so that means, that specifying a monitor profile in GIMP’s preferences other 
than sRGB will result in displaying wrong colors. Or am I wrong?

I didn’t know that.

On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable 
the choice of a monitor profile in GIMP at all, as long as cairo assumes SRGB? 

Simone
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Simone Karin Lehmann]

> Am 07.10.2014 um 12:27 schrieb Øyvind Kolås 

> The set of pixel formats currently in babl are by
> implementation&definition references to unchanging color spaces and
> representations - this is how babl is built with linear sRGB as it's
> connection space; and this is how ICC works with XYZ as it's
> connection space.  

Your comparison is not valid, and you know that. In babl/unbounded sRGB world 
your input space and output space differ in a very important aspect to the PCS 
space unbounded sRGB: unbounded sRGB can have values < 0 or > 1, input and 
output don't. Whereas in ICC / XYZ world input, output and PCS have well 
defined boundaries, namely 0 and 1 and well defined clipping, so everything is 
0 <= x <= 1. The interesting point is, that the math really differs between 
your world "unbounded sRGB, no clipping" and "defined boundaries, clipping". 
You've already encountered one main difference: multiplying negative values 
makes no sense in respect to color. Well, now think of adding pure white to 
pure white in your babl / unbounded sRGB world: what's the result? 
Unbounded-sRGB-double-pure-white? And if you substract pure white from this 
double-white? What do you get? 

> Elle writes well and seemingly with pleasure. Personally I prefer
> writing documentation to writing email, but neither of those are
> pleasurable like writing code. You can however take my word for how
> babl and GEGL works

I'll take your word and I'm quite sure you know how babl and GEGL work. But 
that does not mean, that they work correctly. And, although I take your word, 
I'd like to ask you again to give mathematical proof and equotations to prove 
your statements. Elle does, you don't. And this has nothing to do with how babl 
or GEGL work nor whether writing documentation or coding is more pleasurable. 
It's about giving mathematical proof of statements. And as far as I have read 
about this topic, you are the one that only gives words, not code nor equations.

BTW, I've changed the subject back to the original one.

Kind regards
Simone
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Simone Karin Lehmann]

Hi,

although you and Elle are discussing this topic, I'd like to give my 2 cents

> Am 06.10.2014 um 21:54 schrieb Øyvind Kolås :
> To facilitate
> cooperation between scientists, engineers and others we have developed
> a convention of tagging numbers we use to refer to temperature with a
> unit qualifier, like thus: 37.7°C 100°F 310.9°K. That way, given a set
> of conversions formulas, it is possible to operate in the preferred
> unit.

Of course, you can do operations in your preferred unit, but that does not 
mean, that your computation will give identical results after you convert your 
result of your preferred unit back to the original unit. And that's what you 
implicitly say: operating in a "converted unit" and converting back will give 
identical results, as if operating in any original unit only. Or in GEGL/BABL 
words: operating in unbounded sRGB and converting back to the original space 
will give identical results as operating in the original space only. 

You've given a very good example for that:

If
x C = y F
and
x C = z T, where T is your "TCS" , your "temperature connection space"
is true,

you know that

2*x C != 2*y F 
and
x C + 10 C != y F + 10 C
and
x C + 10 C != y F + 10 F

is true too.

and so although
2*x C = 2*z T
there is
2*z T != 2*y F
and
z T + 10 T != y F + 10 F

So doing an operation in T, either multiply or adding, and converting back, 
won't be the same as computing in the original unit in your example. Same 
applies to color space computations and various operations. 

BTW, I've noticed, that although Elle always gives equations or real world 
examples and images to prove her statements, you don't. So, I'd like to ask you 
for such a mathematical equation or real world example for your statements.

Finally and sorry to say so, AFAICS, Elle is right.

Kind regards
Simone Karin

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] OSX

[Simone Karin Lehmann]

> 
> Simone, I hope this can convince you to not remove that code from GIMP?
> 
well ...
we’re talking about two use cases: 

a) a user wants to use GIMP in some other language than OS X itself. 
b) a user wants to use GIMP in some language, that neither OS X supports, nor 
any other native (not from Linux ported) OS X application

In both cases, the App menu shows mixed languages: the primary one from System 
Preferences and the user selected one

well… I’m still not convinced.
Why? Every supported OS X language is automatically detected, if there’s a 
localization in GIMP. The current implementation mixes languages. And I find it 
confusing to offer an application specific way to set localization because it’s 
one of the main concepts of OS X to have these settings in one central place, 
namely System Preferences, and that this system wide setting should be 
respected by all applications. And finally, the comandline still allows 
switching langugage in both builds, yours and mine: ‚LANG=your_locale open -a 
Gimp'

Anyway, I’m thinking about it …

> P.S. Simone, are there are any other changes like this, ones that greatly 
> alter how your build works compared to a non-modified one?

Well, that depends on what you mean by „greatly alters“. If it’s something 
like: it works, whereas the non-modified doesn’t, there are a few (very 
platform specific ones, indeed) and of course, there’s one 
right-out-of-hell-patch regarding the save/export behavior.

Here they are: working dock menus, standard OS X shortcuts for Hide, Hide 
others, Quit, Fullscreen, Print, Scanner support via Image capture, open 
location, locally installed help, preserving EXIF/IPTC when saving JPEG / TIFF, 
opening EPS,  and some minor tweaks (as completely got rid of Carbon in all 
libraries, using system provided Python, Gatekeeper code signing, QuickLook for 
xcf, and a lot of plugins, a typical Mac user can’t compile itself)

Regards
Simone

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] OSX

[Simone Karin Lehmann]

> Am 14.09.2014 um 23:27 schrieb Partha Bagchi :
> 
> Simone,
> 
> It is indeed possible to change the language within Gimp without
> changing the system language.

yes, I know. 
I meant that my builds don’t support setting the locale within GIMP. And, I 
disabled the code intentionally.

> If you are packaging the iso-codes, you should be able to see and set
> the default Gimp language without changing system language.
> 

I don’t see a need for this. Two UI elements to set the application 
localization are IMO more confusing than useful and don’t confirm to the OS X 
guidelines (ok, ok, I know, GIMP is just a port not an OS X application, and 
there should be as few as possible platform dependent code).
Nevertheless, IMO native Mac applications should respect the user’s settings in 
System Preferences, and if you’re really such an advanced user who want’s to 
run GIMP in a different locale than your system locale, you can still do this, 
as Michael said, in ‚the Linux way‘ via Terminal by typing

LANG=zh_CN.UTF-8 open -a GIMP

And, if I understand Sven correctly, you’ll get a mixture of languages in the 
App menu, if the system preferred language differs from GIMP’s language 
selector. So it’s still a hack.
BTW, this is just the same as if you use the above command line. You’ll get the 
same mixture of languages. 

Ok, you have an UI element for this whereas I use the command line… ;-) (SCNR)

Regards
Simone Karin



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] OSX

[Simone Karin Lehmann]

> On 14 Sep 2014, at 21:54, Michael Schumacher  <mailto:schum...@gmx.de>> wrote:
> 
> On 14.09.2014 20:15, Simone Karin Lehmann wrote:
> 
>> Isn’t it easier at all to only set the primary language in System 
>> Preferences, along with some secondary setting and maybe some more?
>> Why using the language selector in GIMP? As far as I can see, there
>> is no need for the language selector, at least my builds work without
>> it very well.
> 
> It used to be like this on Windows for a looong time, and turned out
> that many people want to use GIMP in a language different from their
> system's - it is quite common for users to stick with the original
> English, because about every tutorial you can find is written in this
> language.
> 
> This doesn't seem to be possible with your builds at the moment, unless
> the users change their system preferences?
> 

Indeed. It isn’t possible within GIMP but in System Preferences. As with all 
other native OS X applications. At least I don’t know about a native 
application having its own language selector.

Regards
Simone Karin

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] OSX

[Simone Karin Lehmann]

Am 14.09.2014 um 15:08 schrieb scl :

> 
> >> BTW, I’ve never used this part of the code at all and only rely on System 
> >> Preferences as any other OS X Application does.
> 
> Well, that's indeed a point why we provide an extra language selector
> while the user can already set the language in the operating system
> resp. desktop environment. This is questionable not only on OS X, but on all 
> systems.
> Especially on OS X we currently have the effect that the language of
> most of the UI is set in our selector, but the language of system
> specific menu items from the App menu can only be set in the OS X'
> system preferences.

I’m not quite sure if I understand you correctly. Do you mean, that without the 
language chooser code, the language of some App menu items and other menu items 
is different? This does _not_ happen with my build.

As I’ve written, my build only relies on System Preferences. I’ve completely 
disabled the language chooser code and of course have added some patches to 
read System Preferences. And, well, all App menu items and all other menu items 
show up in the same language, I’ve chosen in System Preferences. Well, if some 
strings are not translated in e.g. Gaelige, then the second language setting in 
System Preferences is chosen, then the third and so on.

> The convenient way for users to set the language
> consistently is to use 'System language' in GIMP, set the desired
> language as primary language in the system's preferences and restart
> GIMP.

Isn’t it easier at all to only set the primary language in System Preferences, 
along with some secondary setting and maybe some more? Why using the language 
selector in GIMP? As far as I can see, there is no need for the language 
selector, at least my builds work without it very well.


> From a technical point of view the language information is something
> that has to be provided by the application framework to make sure
> all applications based on it behave the same.
> 

And AFAIK, even your build should now that GIMP uses gtk-mac-integration word 
without the language selector. I not, try my patches and rewritten library.

Regards
Simone

— 
stay hungry, stay foolish



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] OSX

[Simone Karin Lehmann]

Hi Sven,

I’ve downloaded your build and I’m experiencing the exact same issue.

The language selector only shows system language and en_US. And it seems to me, 
that your build is picking up languages from OS X System Preferences, and even 
uses all other languages in System Preferences as fallback, if the primary one 
is not complete (as for Gaeilge)

BTW, I’ve never used this part of the code at all and only rely on System 
Preferences as any other OS X Application does.

Regards
Simone

Am 14.09.2014 um 08:13 schrieb scl :

> Am 11.09.14 um 16:33 schrieb scl:
> 
>> Are more people experiencing this effect?
> 
> Hello, no answers?
> Is there anybody else experiencing the effect that
> the build from http://download.gimp.org/pub/gimp/v2.8/osx/staging/
> shows only two languages in the language selector listbox?
> 
> Kind regards
> 
> Sven
> 
> 
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list

— 
stay hungry, stay foolish



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] ANNOUNCE: GIMP 2.8.12 released

[Simone Karin Lehmann]

Hi,

Am 26.08.2014 um 10:19 schrieb scl :

> Hi,
> 
> nice to read that ;-)
> 
> GIMP up to version 2.8.10 could run on OS X 10.6 (Snow Leopard)
> and later. I could provide an OS X 10.9 (Mavericks) build from the
> original sources (i.e. with no extra plug-ins and other patches),
> but I'm not able to provide support for OS X versions before that.

I was under the impression that you have access at least to a virtual machine 
running 10.6 or 10.7

> Does anybody volunteer to build from the original, unmodified sources
> for OS X 10.6 again? If necessary I could support the OS X packager by
> answering arising questions by email.
> If nobody did, could we live with not supporting versions prior to
> OS X 10.9 in this release?
> 

well, since OS X is the only platform for which ready to use binary packages 
are officially provided by gimp.org, IMO there should be packages for every OS 
X version Apple supports. As of today that wold mean 10.7+

At least I will build packages for 10.7+ (but as you might know, with a lot of 
plugins and some small patches ;-) )

Simone Karin

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.8 on OS X fixes

[Simone Karin Lehmann]

Hi Sven,

Am 27.05.2014 um 05:24 schrieb scl :

> Hi Simone,
> 
> an honest thank you for your efforts.
> In my build I'm also patching gtk-mac-integration
> so this might be of your interest.
> The patches are in /build/osx/patches of the build-osx
> branch.
> 
> 0002-Improve-internationalization-of-App-menu-and-other-s.patch:
> The current App menu implementation assumes that the application's name
> is at the end of the 'Hide' and 'Quit' menu item in all languages. This
> is grammatically incorrect for some languages, such as German.
> The patch inserts placeholders for the app name and fixes the
> translations where necessary.
> Fix references to the internationalization table ("GtkOSXApplication")
> to ensure these strings are recognized at runtime.
> Fix broken encoding in the ro, ru, uk languages.
> Add language pt_BR (Brazilian Portuguese).
> 

Thank you. I’ve already included those changes in my forked version.

BTW, if you convert the *strings files from UTF-16 to UTF-8 encoding, git will 
handle these as text and not as binary. And it will be easier to manipulate 
those files in shell scripts with sed, grep, cut, tr and other commands. Cocoa 
itself handles UTF-8 and UTF-16 encoded strings files interchangeable.


> 0003-Keep-separators-between-placeholders.patch:
> Keeps menu separators between menu placeholders.
> It fixes the issue that some separators got lost in the menus,
> for instance the one between File/Send as e-mail and File/Properties
> etc.
> 

yep, already done.

Regards
Simone 


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.8 on OS X fixes

[Simone Karin Lehmann]

Am 26.05.2014 um 21:17 schrieb Simone Karin Lehmann :

> 
> The patch I’ve mentioned is a fork of the gtk-mac-integration library which I 
> heavily modified and patched. I’m currently cleaning up the code so that it 
> would compile without the need to patch the gtk-mac-integrationn library. And 
> I’ll try to write some basic documentation, why I did this, and what I’ve 
> changed, and why I did it.
> 
> In a few words:
> - no undocumented and unofficial function to make the Apple menu. 
> - just use the official Cocoa API and a stub MainMenu.nib,generated with Xcode
> - the library itself now calls [NSApp finishLaunching] as soon as possible, 
> so there’S no need for an extra EventHandler to open files. This fixes the 
> mentioned bug.
> - don’ hide the ApplicationDelate protocol and don’t hide the notification 
> protocol, so the application can fully use these protocols. This made it very 
> easy to implement working dock menus and file open events
> 
> So I’ll try to do my best to upload it in the next few days('til Thursday)….

I’ve just uploaded my patched version of the gtk-mac-integration library and 
committed it into my svn repository. 

https://sourceforge.net/p/gimponosx/code/HEAD/tree/

The README gives some information about why I did this, as I already mentioned 
in my above quoted posting, and gives some basic documentation about how to use 
the library.

I’ve patched GIMP’s 2.8.10 sources to use this forked library. The changes are 
in app/gui/gui.c and app/gui/gui-unique.c. You can find the patches in my svn 
too at

https://sourceforge.net/p/gimponosx/code/HEAD/tree/GimpPorts/ports/graphics/gimp2/files/

Regards
Simone Karin





___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.8 on OS X fixes

[Simone Karin Lehmann]

Hi Jehan,

sorry for answering so late. I’m really very busy in the last few weeks. 

The patch I’ve mentioned is a fork of the gtk-mac-integration library which I 
heavily modified and patched. I’m currently cleaning up the code so that it 
would compile without the need to patch the gtk-mac-integrationn library. And 
I’ll try to write some basic documentation, why I did this, and what I’ve 
changed, and why I did it.

In a few words:
- no undocumented and unofficial function to make the Apple menu. 
- just use the official Cocoa API and a stub MainMenu.nib,generated with Xcode
- the library itself now calls [NSApp finishLaunching] as soon as possible, so 
there’S no need for an extra EventHandler to open files. This fixes the 
mentioned bug.
- don’ hide the ApplicationDelate protocol and don’t hide the notification 
protocol, so the application can fully use these protocols. This made it very 
easy to implement working dock menus and file open events

So I’ll try to do my best to upload it in the next few days('til Thursday)….

Simone

Am 26.05.2014 um 18:40 schrieb Jehan Pagès :

> Hi Sven,
> 
> On Sun, May 25, 2014 at 8:22 PM, scl  wrote:
>> Hi,
>> 
>> I’ve updated the OS X builder. The changes include:
>> - Bugfix 721482: bring back languages other than English and
>>  offer them in the Preferences’ language selection listbox,
>>  show a translated GIMP app menu in various languages,
>> - Bugfix 683177: bring back GIMP’s online user help in a web browser,
>> - Bugfix 721449 and other fixes to make GIMP 2.8 build on OS X again,
>> - add a configuration to build GIMP master,
>> - a UI theme with better integration into the OS X look and feel,
>> - an improved build how-to,
>> - updated dependencies and
>> - various fixes.
>> 
>> Known remaining issues are:
>> - Stock buttons in plug-in dialogs still read English instead
>>  of the users' language,
>> - GIMP opens the user manual still in English when GIMP was
>>  started the usual way by clicking the program icon. It shows
>>  the proper language when started from a terminal window.
>> If somebody has a clue on how to fix this I'd be grateful.
> 
> In other issues, do you have an idea about this:
> https://bugzilla.gnome.org/show_bug.cgi?id=719723
> Simone Karin Lehmann (added in Cc) was saying she already had a fix
> for this crash, but she has not uploaded her patch and we are still
> waiting. Since you apparently take good care of the OSX version, do
> you have an idea of the fix she meant in her explanation?
> 
> Or maybe Simone, if you read this, we would really welcome the patch
> you wrote about.
> 
> Thanks all! :-)
> 
> Jehan
> 
>> You find the update in GIMP’s osx-build branch and if we find
>> no deal breaker it can go into the next GIMP 2.8 release.
>> Thanks to all who helped me getting the job done.
>> 
>> Mac developers, it would be nice if someone of you could build
>> it on a platform other than OS X 10.9. and report back. The
>> updated how to is /build/osx/README and here:
>> https://git.gnome.org/browse/gimp/plain/build/osx/README?h=osx-build
>> 
>> Kind regards,
>> 
>> Sven
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives:   https://mail.gnome.org/archives/gimp-developer-list

— 
stay hungry, stay foolish



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp Registry Future

[Simone Karin Lehmann]

Hi Jehan,

Am 12.04.2014 um 12:57 schrieb Jehan Pagès :
> 
> I don't think it is necessary for the addition of third party servers
> to be made too difficult (and in particular having to recompile is
> over and in practice means that a normal user will never be able to do
> it, but it would be made easy only to scammers). It could just be a UI
> preference. As long as we display proper warnings "at your own risk"
> because unreviewed plug-ins can simply do anything to a user's
> machine.
> 
> Also if we decided to use branding for protection of users, I would
> say that a third party build can be named GIMP if and only if the only
> plug-in server active by default if the official one.

Doesn’t this conflict with the GPL? Let’s assume, I take the GIMP sources and 
add my own plugin server which offers only precompiled OS X binaries, how is 
that different to the current situation where I provide those plugins already 
installed in the application bundle? Am I forced to name my bundle different?


> If you build
> GIMP by adding any third party server, without telling the user about
> it, it can be a scam risk because

of course this _might_ be a risk, IMO it’s the same sort of risk as if you 
install some precompiled binary plugin from one the uncounted Linux 
distributions. 

> the user would not have had the
> original warning (hence would feel safe while one may not be).

OTOH, if one provides his own plugin server repository, such a message in the 
‚official‘ GIMP will discredit the ‚non-official‘ version as a possible 
security risk only  because of some other kind of distribution. 

To make this clearer, I’ll give some example.
Think of the current situation on OS X. The stock GIMP bundle from gimp.org is 
not code signed. AFAIK this is because one has to have a paid Apple developer 
account to get a code signing certificate and currently no one wants to pay the 
annual fee. Now, to bypass the warning a user will get if he installs this 
unsigned application, he’s advised to turn off this security check in OS X’s 
System Preferences. Hhmm, IMO not a good advice in the sense of security.

Now, as you know, I provide a compiled GIMP application bundle with many third 
party plugins. My application bundle _is_ code signed. Should I display a 
warning, that if if a user want’s to install the stock GIMP he’s doing it at 
his own risk, because he get’s advised to turn off a security feature of his 
operating system? How would the core developer team feel about this?

Don’t get me wrong, code signing is a very useful feature. But forcing third 
party developers to use only _one_ specific distribution path or otherwise 
getting discredited as a possible security risk is not a good move. Even Apple 
let’s you sign your code to pass the code signing test on first launch and 
still let you distribute your applications however you want.

Simone Karin
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Single build for various OSX versions (Was: [Gimp-user] Open Gimp)

[Simone Karin Lehmann]

> Am 09.12.2013 um 00:50 schrieb Jon Nordby :
> 
> I'm pretty sure that you don't need a custom XCode install. The 10.6
> SDK comes with XCode for OSX 10.9 (or you can install it from inside
> XCode). You do need to set all the right flags though. I beliieve
> these are all, but I don't have a Mac to verify now.
> 
> -mmacosx-version-min=10.6 -isysroot/Developer/SDKs/MacOSX10.6.sdk
> -DMACOSX_DEPLOYMENT_TARGET=10.6

... great. I'll give it a try.

BTW, Xcode 5 doesn't include the 10.6 SDK and you can't install it from inside 
Xcode, but of course, you could copy it over from some old Xcode version.

Simone Karin
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Single build for various OSX versions (Was: [Gimp-user] Open Gimp)

[Simone Karin Lehmann]

Am 08.12.2013 um 22:37 schrieb Partha Bagchi :

> Hi Sven,
> 
> It's a complicated process. Due to changes in how threads are handled
> between SL and later, if you build on Mountain Lion or Maverick the builds
> will not function on SL or earlier. So, to build Gimp such that it
> functions on SL and later, I installed Xcode under a separate folder and
> then point gcc to that folder and not use Maverick system folders.I also
> pass the CFLAG macosx-version-min=10.6

great, … that’ looks promising. (I have to admit that I never thought of using 
macosx-version-min)

Isn’t it enough to only use macosx-version-min? 

What do you mean exactly by pointing gcc to another Xcode? My /usr/bin/gcc is 
the same as the one
on Xcode/Contents/Develper/usr/bin. I’m using Xcode 5 on Mavericks. 
Do you some other version or a custom installed gcc?

Regards
Simone Karin



___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Single build for various OSX versions (Was: [Gimp-user] Open Gimp)

[Simone Karin Lehmann]

Am 08.12.2013 um 20:18 schrieb scl :

> 
> 
> On 8.12.2013 at 8:14 PM Partha Bagchi wrote in Gimp-user:
>> You can also download my Mac build which will work on Snow Leopard or
>> later. You can download it from www.partha.com
> 
> Hi Partha,
> 
> I hereby confirm that your build is fine on OS X 10.6.
> How did you manage to build GIMP in a manner that it works for
> 10.6 _and later_?

if you compile it on a SnowLeopad machine, it will run up to 10.9

The only reason, why I make separate builds on my site, is that my development 
system runs Mavericks. So I do a second build on an old (and slow) MacBook 
running SnowLeopard.

> As far as I know the OS X versions are often incompatible to
> each other what makes it hard to get a build for various OS X versions.

AFAICS, there are no incompatibilities as long as you compile and install all 
needed libraries inside the application bundle. 

Simone
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Setting Up a Release Procedure

[Simone Karin Lehmann]

Hi,

Am 30.11.2013 um 12:26 schrieb Jehan Pagès :

> Well... that's why I was proposing testing and collaborating *before*
> releasing, and not after. :-/

yes. Sadly, now the „no-outline-issue“ is another showstopper.


>> It’s not about building. I wrote a couple of scripts which automates that 
>> quite well. But in the last years I’ve made a lot of OS X specific patches 
>> (don’t ask, why some of them are not upstream…. long story) and making a new 
>> release requires to adapt these patches and to test if the are still needed 
>> and if they still fix the addressed issue. Two examples:  years ago on X11 
>> it took me for ages to fix the file chooser sorting bug. Well, on Mavericks 
>> it’s back again. Second: using the Cocoa based version of 
>> gtk-mac-integration to get properly working menus and keyboard shortcuts.
>> 
> 
> Well that would still be a lot better for the users *and* for you if
> we could all collaborate. If these patchs on third party are really
> necessary to prevent major bugs, we'll appreciate having them in our
> source tree as well (we have a directory build/osx/ where we save
> build-specific data, like third-party software patches).

yes, I’ll share them. But IMO this needs to get committed about what build 
system we use on OS X. Clayton uses jhbuild. I use a slightly hacked version of 
MacPorts and some bash scripts to ease the process of building on Mavericks 
down to SnowLeopard and even cross compile to 32bit and it helps me manage 
about 100 packages needed to build my bundles. As far as I’m concerned, I’d 
like to stay with that and not to switch to something else I’m not used to and 
from what I don’t know if it fits my needs and gives me all functionality I 
already have.

> This way, we
> can share these patchs will all packagers, and doing so will also save
> you time as we would take on us to check and adapt the patches.
> Could we know more about your patches, and what they fix exactly?

e.g. 
glib, gtk2, cairo
using Coca instead of Carbon, fixes paths to fit into Mac standards, etc.
gtk-mac-integration:
use Cocoa, fix some issues, don’t hide the delegate and notification protocols 
to enable easier app development on the application side.
gimp:
Cocao, working help system with reduced config options, using some system 
provided libraries instead of build them from source, Mac shortcuts, lightly 
different behavior of lcms to recognize more icc profiles, working dock menus 
:-), hide / unhide Gimp, and a 
„right-out-of-hell-and-never-will-be-included-patch“ about the save / export 
issue ;-)

Here’s the link to the current epository  (not totally complete, I’ll update 
this if I find some time…. and I know, some code looks ugly …)

https://sourceforge.net/p/gimponosx/code/HEAD/tree/

> Would you accept to contribute them to us?

if we could negotiate an what to use …. :-)

> All this said, the preferred politics is indeed to contribute upstream
> if possible. What is the reason why you did not propose your patches
> upstream? You can make the short version of the story if you like :-).

hhhmm, what should I say, I don’t want to revive these zombies, but I’ll try a 
short version. (you’ve been warned :-) )

In the „old days“ of the Mac packaging community most things were fine. But 
then patches or plugins got rejected with a simple „No, we don’t include this, 
because we are the official packagers“. Other patches were silently taken and 
rewritten without asking why I did it in this specific way. No discussion about 
why I did things or how to improve things, all of a sudden, everybody only 
wanted packages. No one was interested in going deeper. Although I asked for 
help to fix a long standing issue (using the help system, install the user 
manual locally, get rid of the „GIO/GFVS“ error. (BTW, all of this is now 
fixed, it took me years…)) … nothing happened. I got the impression that, with 
a few exceptions, nobody wants to contribute to the Mac version. And then came 
this discussion about a „native“ build. Everybody thought that a native version 
will automagically solve all problems they have. But „native“ is IMO much more 
than simply dropping X11 and have a menu bar at the top. It’s about using OS X 
functionality like ColorSync, the print system, system provided libraries, 
using Cocoa not Carbon.
Again, I got the impression that there are only very few people interested in 
contributing to the Mac version. Most people only wanted to build a package and 
to have the menu bar at the top. So I decided to do it on my own. Last zombie: 
for a short time the link to my site was dropped in favour of a „native" build 
with the menu bar on top. And although GIMP now being "officially native“, 
well, there are only few things from other OS X developers and packagers to 
port more code to native OS X functionality.
But now let the zombies rest in peace and give the OS X version a new try.

>> New OS versions introduce new bugs. See the pencil / brush issue I ment

Re: [Gimp-developer] Setting Up a Release Procedure

[Simone Karin Lehmann]

Am 28.11.2013 um 22:25 schrieb Jehan Pagès :
Hi,

> Well actually the 4 main points are:
> 1/ testing: right now, releases are sudden, out of nowhere, and we
> discover release issues afterwards.

yes, we really need a test cycle before a release goes public. Especially if 
there’s not only a new GIMP source, but a new OS version as well, like it is on 
OS X. I just discovered a new bug, which is IMO release critical. On OS X 
Mavericks, the pencil and brushes outline doesn’t show, so it’s almost 
impossible to paint, clone and brush.

> 2/ Work duplication: as you noted, many people on OSX are doing the
> same thing. On Windows, well there are Drawoc and Ender which have 2
> different procedures too.

well, I’ve tried to answer this in another thread. So let’s give it a new try.

> 4/ It looks like it is complicated for each of these individual
> packager. When I see for instance Simone Karin Lehmann saying that she
> just made a release and wouldn't do it again immediately (probably
> because too boring/annoying task), that is too bad. 

It’s not about building. I wrote a couple of scripts which automates that quite 
well. But in the last years I’ve made a lot of OS X specific patches (don’t 
ask, why some of them are not upstream…. long story) and making a new release 
requires to adapt these patches and to test if the are still needed and if they 
still fix the addressed issue. Two examples:  years ago on X11 it took me for 
ages to fix the file chooser sorting bug. Well, on Mavericks it’s back again. 
Second: using the Cocoa based version of gtk-mac-integration to get properly 
working menus and keyboard shortcuts. 

Further in the past I’ve tried to test that new sources fit into the „Mac 
standards“ and wrote patches to do so. E.g. moving the config directory to it’s 
proper location in ~/Library/Application Support.

New OS versions introduce new bugs. See the pencil / brush issue I mentioned 
above.

Pushing releases in such short cycles forces me to „just run my scripts“ to get 
a new package out and satisfy all users who start asking for the new packages. 
I already have a lot of requests for a SnowLeopard version.  This leaves no 
room for testing or fixing already known issues. And that was the only thing I 
wanted to say when I wrote that I don’t want to redo some work. Sorry for not 
writing that clearly enough in the first place. 
 
Simone Karin
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP release: 2.8.10 request, OS X

[Simone Karin Lehmann]

Hi everybody,

Am 24.11.2013 um 10:59 schrieb scl :

> Hi,
> 
> today there was [bugreport] about outdated builds for OSX.
> 
> One reason for not being able to provide an official GIMP 2.8.8.
> on OS X build were serious issues on OS X Mavericks, for instance
> the [showstopper in the Text tool]. These have been solved in
> the meantime (thanks especially to Simone Karin Lehmann, Michael
> Natterer and Daniel Sabo).
> 
> Therefore I think we should bring out GIMP 2.8.10 soon,
> including an official OS X build (preferably also for some older
> OS X versions). As far as I know Claytons build is at the ready.
> All we need is a 2.8.10 bump, don't we?

arrhhhg no, I’ve just released a bundle for 2.8.8.  (… and I don’t wont to redo 
some of the patches right now.)

> 
> This situation shows us another weakness again:
> there are at least four people working on an OS X release:
> Clayton Walker, Simone Karin Lehmann, Partha Bagchi and
> David Evans (Macports), not to mention the (still active?) maintainer
> of the outdated Fink build and the various people building GIMP
> on their own Macs. All of them do it in their rare spare time.
> All of them struggle alone with the special build issues of GIMP
> on OS X, its dependencies and the API incompatibilities between the various 
> OS X versions.
> Can you guys and girls please find a way to work together?

well, long story, at least from my point of view. I’ll try the short version. 
(the first version of this post was way longer .-) )

Years ago, there was no GIMP for the mac besides MacPorts or Fink. Both were 
IMO not suited for casual Mac users. Some day I got a hint from another Mac 
user, Christoph Schröder, how to use MacPorts to ease the build process for 
GIMP (so basically he’s the one who started that all. Thanks, Christoph). So I 
hacked MacPorts a lot and finally got a development environment very well 
suited for GIMP. I could built for all OS versions, cross compile for all 
architectures, patch every source I wanted and include as many plugins as I 
wanted. Everything was fine. 

But differences came. Mainly about on what to focus the efforts. Plugins vs. 
stock GIMP, specialized development environment vs. generic environment 
(MacPorts / jhbuild), specialized patches vs. generic ones. And from what I see 
now in various projects and sources: NSObject classes vs. CoreFoundation.

I' focusing on plugins, specialized environment, specialized patches and 
NSObject classes. 

> What makes it so hard to speak to another at the mailing list or IRC

mainly that I have only very limited time and, that I don’t like IRC and, well, 
my bad english.

> and unite your forces? Come on, we don't bite ;-)

Neither I do.

So I’ll give it a try.

Simone Karin Lehmann

— 
stay hungry, stay foolish
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] RAW files

[Simone Karin Lehmann]

Am 23.12.2012 um 20:54 schrieb scl :

> the UFRAW plugin [1][2] is your friend here.
> Please keep in mind that the current UFRAW plugin doesn't work with GIMP 
> 2.8.2. Please use GIMP 2.6 or GIMP 2.8.0 then or use UFRAW as


... take a look at http://gimp.lisanet.de/Website/Download.html. The UFRaw 
plying works in these 2.8.2 builds.

Simone



smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

Am 23.11.2012 um 13:53 schrieb Tobias Oelgarte:Could we not just change the behaviour of "save as" if the user sets an option (global option) that he wants to use the old style, unsafe solution at his own risk? So everyone can choose what he likes I've made the patch a configurable option. Yu can switch it on or off in GIMP's Preferences -> Environment -> Saving Images. -> "Force to save only in XCF image format".Here's the download link (Mac OS X only). http://switch.dl.sourceforge.net/project/gimponosx/GIMP%20Mountain%20Lion/Gimp-2.8.2-savex3-MountainLion.dmgThe patch is attached Maybe someone can build a patched GIMP on the other platforms.

save-export-patch3.diff
Description: Binary data
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

> 
> ... and here's the new patch which let you "save" JPEG  too.
> 

sorry, I forgot to attach it :-(

Here it is now.

Simone Karin



save-export-patch2.diff
Description: Binary data



smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

Am 23.11.2012 um 13:38 schrieb Simone Karin Lehmann:
> 
> ... but the longer I think about this issue, the more I agree with you. JPEG 
> is in fact the most common used format by photographers (well, besides 
> shooting RAW). So I'll change my patch and build a new version which will 
> allow all non-XCF files with only one layer to be saved via File - Save.

... and here's the new patch which let you "save" JPEG  too.

And the download link for the binary (Mac OS X only): 
http://switch.dl.sourceforge.net/project/gimponosx/GIMP%20Mountain%20Lion/Gimp-2.8.2-savex2-MountainLion.dmg


Regards
Simone Karin




smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

On 23.11.2012, at 09:50, "Michael Schumacher"  wrote:

>> Von: Simone Karin Lehmann 
> 
>> a) Non-XCF non-JPEG images with only 1 layer can be saved via 'File -
>> Save' with the original file format. The dirty flag is cleaned and so 
>> there's no dialog about unsaved changes if you close it after saving. 
>> 
>> After exporting them, the image title and file name is not changed, so
>> that you can repeatedly save it as long as there is only 1 layer.
>> 
>> This is basically the same as 'Overwrite'
> 
> This moves the debate to a later date, when every filter and operation used 
> on an image will have become an op in a graph.
> 
> Will "the image has only one layer" still be a viable criterion at that time?

From a developers point of view certainly not. From a users point of view, IMO, 
yes.

Having the user scenario in mind which I wanted to address with this patch 
'opening - destructive editing in place - saving' is identical to 'opening - 
gegl op editing - saving - loosing the gegl graph'.

Whereas if an image has more than one layer it's far more evident that one 
wants to work non-destructive. So the criterion 'one layer nonXCF' is IMO still 
suitable to allow a destructive workflow.

Anyway, you can't totally prevent users from data loss as long as you support 
non-XCF formats and offer Export / Overwrite.

IMO it's all about finding a trade-off between 'restrictions to prevent data 
loss' and 'allowing common user scenarios'. 

Regards
Simone Karin



smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

On 23.11.2012, at 08:44, Alberto Mardegan  wrote:

> 
> Why are you excluding JPEG files? That is the most commonly used format
> by photographers, among whom are most of the users who dislike the new
> behaviour.

I excluded JPEG mostly because I wanted to calm down developers and I shared 
their concerns about JPEG being a lossy file format

> 
> So, I'm afraid that your proposed change wouldn't help them (certainly
> not me).
> 

... but the longer I think about this issue, the more I agree with you. JPEG is 
in fact the most common used format by photographers (well, besides shooting 
RAW). So I'll change my patch and build a new version which will allow all 
non-XCF files with only one layer to be saved via File - Save.

Regards
Simone Karin

smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Patch and build for the save/export issue

[Simone Karin Lehmann]

Hi everybody,

this all seems to become a more and more controversial discussion. But, IMO, 
argueing more and more heatedly brings us to  nowhere.

I can fully understand all developers who care about preventing data loss. I do 
care too.

I can fully understand all users who get used to the 'traditional way'. I got 
used to it too.

So here's what I did.

I've written a patch which tries to prevent data loss as far as possible but 
still gives you some of the traditional behavior back. A binary package can be 
downloaded (Mac OS X only with all previously included 3rd party plugins)

This is the new behavior

a) Non-XCF non-JPEG images with only 1 layer can be saved via 'File - Save' 
with the original file format. The dirty flag is cleaned and so there's no 
dialog about unsaved changes if you close it after saving. 

After exporting them, the image title and file name is not changed, so that you 
can repeatedly save it as long as there is only 1 layer.

This is basically the same as 'Overwrite' 

b) For all other images - images with 2 or more layers, JPEGs, XCF, newly 
created ones - nothing is changed. Saving them will  create a XCF

c) Save as / Export / Export to / Overwrite are not changed.

This should prevent data loss as far as possible while still allowing the most 
mentioned user scenario: opening - destructive editing in place - saving.

Feel free to try it to see it in action, hoping this will help to settle the 
quarrel.

The patch is attached. Here's the download link: 
http://switch.dl.sourceforge.net/project/gimponosx/GIMP%20Mountain%20Lion/Gimp-2.8.2-savex-MountainLion.dmg

Regards
Simone Karin



save-export-patch.diff
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 2.8.4 release?

[Simone Karin Lehmann]

Am 14.10.2012 um 03:48 schrieb Christopher Curtis :

> Hello,
> 
> GIMP 2.8 was released on 2012-05-03
> GIMP 2.8.2 was released on 2012-08-24
> 
> In the recent past, there was a discussion about doing timed releases, every 
> ~3 months.
> 
> If a ~3-month cycle is desired, the 2nd release in the 2.8.x series could be 
> 2012-11-03 or 2012-11-24. I mention this now because an -RC release 2 weeks 
> prior to the earlier date would be 1 week from now.
> 
> It appears that for version 2.8.2, 21 issues have been resolved FIXED; 14 are 
> NEW, 1 is reopened; and 30 are unconfirmed or need more info.
> 
> Of the new issues, 6 have higher than "normal" severity, and 2 have higher 
> than "normal" priority:
> - 674928 - Major (Urgent): Artifact-prone redraw when panning.
> - 682585 - Critical (Normal): Pressing a key in Edit/Modules crashes GIMP
> - 683019 - Blocker (Normal): Mac requires app signing for installation on OSX 
> 10.8

the 'GIMP on OS X' builds on my site (gimp.lisanet.de) are already signed with 
my developer ID

> - 683373 - Major (Normal): Mac native port has very poor performance
> - 683617 - Major (Normal): MacOS can't take screenshots

... this works too in my builds, so maybe these two issues should not block a 
RC release.

Simone Karin Lehmann




smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build

[Simone Karin Lehmann]

Hi Sven,

Am 02.09.2012 um 15:52 schrieb scl :

> Hi Simone,
> 
> first of all thank you for your build. Unfortunately I don't have 10.8 (yet) 
> to run your native version ;-( BTW: can you report that/whether 10.8 runs 
> stable?

IMO 10.8 runs better than Lion, somehow more smooth. It's worth to update.

> 
>> I've hacked on the sources and found a workaround for the bug which let 
>> plugin dialogs pop up behind the main windows. (well, it's more like a dirty 
>> hack, but it works quite well) I've attached the patch.
> 
> thank you!
> Can somebody integrate this into the native build for OS X older than 10.8 
> and the Windows build, please? I'm willing to test and report back. We could 
> perhaps close the bugs #678359, #676709, #677765 and #360106 then.

aarrgghh, I've sent a temporarily disabled version of the patch. Sorry. (I 
should really take some time to relax after hacking the last few days ...) I've 
attached the working one.

The patch is OS X specific and won't run on Windows, although the basic 
approach should work there too.

#678359 and #676709 are adressed by this patch, although there's still some 
focus issue with scripts. I'll try to fix this too.
(... I don't know GIMP's sources in detail. Could you point me to the files / 
functions where script dialogs get created and run, please? )

Simone



libgimpwidgets-gimpdialog.c.diff
Description: Binary data

-- 
Stay hungry. Stay foolish.





smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build

[Simone Karin Lehmann]

Am 31.08.2012 um 22:46 schrieb Michael Natterer:

> No you are not, this was never anyone's intention.
> 
> I have put the links to your installers back now, removing them
> was neither friendly nor smart, sorry for that.
> 
> About the general issue: Clayton came to IRC and offered to
> work on a native build. Having such a build was a goal for
> a long time, and we will never fix the remaining issued without
> finally going forward by releasing one.
> 
> This was not in any way meant as a hostile move against you,
> we always appreciated your work, and still do.
> 
> The issue is probably that most stuff takes place on IRC,
> so this "just happened". Developer time on GIMP is very
> limited, and the issue of a native build was just not
> pressing enough to publically ask for help on gimp-developer,
> and the help on IRC came without any effort.
> 
> Again, we would really like you to stay with the GIMP
> community, and perhaps even come to IRC so we can work
> on proper OSX packages together.
> 
> It would really suck to lose a valuable hacker over
> such an unintentional incident.
> 
> Regards,
> --Mitch

Now that a few days are over since I first posted here and after I've read your 
answers - Alexandre, Clayton and Mitch - I can now see that it wasn't your 
intention and that it happened just accidentally while everybody was waiting 
for a native version to finally arrive.

So I want to apologize for somehow overreacting in my posting under the, now 
that I can see, wrong impression of being dropped. Sorry.

And thank you, that you've put the link to my site back online.

If you don't mind and to show you that I still want to contribute to the GIMP 
community I've hacked on the sources and found a workaround for the bug which 
let plugin dialogs pop up behind the main windows. (well, it's more like a 
dirty hack, but it works quite well) I've attached the patch.

And I've compiled a native version for Mountain Lion and put it online. All 
plugins I've included in the past are still there and the user manual 
installers work too. G'MIC is included as well. Builds for Lion and SnowLeopard 
with support for 32 bit architectures will follow soon. And I'll try to compile 
it for PPC Macs too.

So, if you don't mind, maybe you could mention on your download page, that the 
builds on GIMP on OS X are now native too.

Finally, if you still want, I'll be back.

Regards
Simone


BTW, I'll update my SVN repo in the next few days, so that you can take a look 
at all patches I've made to GIMP and other sources.




libgimpwidgets-gimpdialog.c.diff
Description: Binary data






smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 1.8.2 for Mac (official?) Build

[Simone Karin Lehmann]

Am 28.08.2012 um 10:08 schrieb Michael Natterer :

> On Mon, 2012-08-27 at 22:02 -0600, Clayton Walker wrote:
>> 
>> 
>> https://dl.dropbox.com/u/942685/gimp-2.8.2-dmg-1.dmg
>> 
>> If someone could just mirror that on the gimp ftp website, or upload it to
>> sourceforge or something, that would be great. Thanks!
> 
> Great! :)
> 
> I have uploaded it to ftp.gimp.org and updated the download page
> on www.gimp.org.
> 
> Thanks Clayton for the effort to make this happen!
> 
> Regards,
> --mitch
> 


aha, so I'm kicked out. 

Why without prior notice, after four years I've maintained the GIMP builds for 
Mac OS X? Why has nobody asked me why I didn't build a, as you call it, 
'native' version? Do you really think I wasn't able to build a version which 
doesn't depend on X11?

It's never been about building, that's quite easy. It's all about having a well 
working version of GIMP.

The now official Mac build still has the usability glitches, which prevented me 
to release such a version of GIMP: plugin dialogs pop up behind the main 
windows. 

Oh, BTW, the color picker doesn't work well, screenshots fail, no support for 
scanners or digital cameras, the help system doesn't work, even accessing the 
online manual fails. OTOH, pressure sensitivity for graphic tablets seems to be 
fixed. (where can I get the source code patches? I can't find them in git.)

But, back to the main topic. What's the advantage of a so called 'native' 
build? The menu bar at the top? Not using X11? From this point of view, even 
most Linux versions aren't native. Or does a 'native' version magically solve 
all kind of problems? Is it about toolkits or software layers? Is GTK+ native 
and XQuartz not? Is the cairo quartz backend a native OS X feature or just 
another kind of software layer between the application and the OS X graphical 
libraries and routines? 

IMO a native version of an application is more than only the use of a specific 
toolkit or software layer. IMO a native application should use standard native 
functionality. And yes, the menu bar at the top is one. But does your 'native' 
version use the native OS X file dialog, the native print functionality and 
dialogs, or does it use native ColorSync. No. Or new security features like 
Gatekeeper. No.

And even further, having your targeted user audience in mind, the official 
build lacks functionality Mac users got used to in the past  years: a set of 
plugins offering advanced photo retousching and workflow, locally installable 
user manuals, support for various OS versions and architectures.

Anyway, now that you're providing an official Mac version of GIMP, I'm quite 
sure that you will give all of these to your Mac users soon, or point them to 
resources where they can easily get it.

Finally, although I'm very disappointed about the current situation, I had a 
great time being part of the open source community and I'd like to say thanks 
to all of you for all your lovely mails and your supportive feedback I've 
received from all over the world in the past few years. Thank you.

Now, dear GIMP team, ...

so long, and thanks for all the fish.


Simone Karin Lehmann
http://gimp.lisanet.de






smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Slow, artifact-prone redraw when panning in 2.8.0-RC1

[Simone Karin Lehmann]

... I'm packaging GIMP  for Mac OS X and can confirm this behaviour too. If 
color management is enabled, redrawing the picture, eg. switching the visibilty 
of a layer, gets horrible slow.

This is somehow related to first doing color correction and then scaling the 
image down. 
If I open a photo with e.g. 4800 x 3200 pixels, set zoom to 15%, add a some 
layer, GIMP redraws the screen very slow. If I set zoom to 100% without 
changing the size of the image window, redrawing is much faster. 

AFACIS at 100% zoom only the visible part of the image is used for color 
correction. At 15% zoom, the whole image is visible, and so all pixels are 
processed although the image is scaled down to fit into the image window.

IMO color management routines should be done on the already zoomed down view. 
There should be no visible difference to the actual behaviour if you do so, but 
it will be much faster.

Simone



Am 11.04.2012 um 08:43 schrieb Kurt Pruenner:

> On 11.04.2012 01:33, Partha Bagchi wrote:
>> Someone reported for my builds that turning off color management
>> helped. However, for photographs I would not want to turn off color
>> management. They did say they were OK with my 2.7.5 build
> 
> I'm afraid turning off color management didn't make the slightest
> difference...
> 
> I've also just confirmed that I get the same artifacts on my notebook at
> work, so that's 3 64-bit Windows 7 machines with horrible panning
> performance... :(
> 
> By the way - is it somehow possible to install the 32-bit version of
> GIMP 2.8.x on a 64-bit system with the new combined Windows installer?
> 
> 
>> On Tue, Apr 10, 2012 at 7:11 PM, Kurt Pruenner  wrote:
>>> Hi,
>>> 
>>> I just downloaded Jernej Simončič's windows build of 2.8.0-RC1 and found
>>> that both on my tablet running Windows 7 with Intel HD3000 graphics as
>>> well as on my desktop, also running Windows 7 but with an ATI Radeon
>>> 5870, panning around an image looks really weird once you pan too fast:
>>> 
>>> http://img441.imageshack.us/img441/6317/gimppanartifacts.jpg
>>> 
>>> A screenshot doesn't really do it justice, though, so I've also made a
>>> ~30 second screen capture video:
>>> 
>>> http://youtu.be/gpARpvEDH0Y?hd=1
>>> 
>>> I'm just holding down the middle mouse button and panning the 100%
>>> zoomed image around.
>>> 
>>> The same thing also happened using one of Partha's recent 2.7.x builds.
>>> 
>>> Does anyone else get similar results? Panning in 2.6.x was smooth as
>>> butter for me... :/
>>> 
>>> --
>>> Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
>>> 
>>> np: Thomas Fehlmann - Next To The Field (Pop Ambient 2007)
>>> ___
>>> gimp-developer-list mailing list
>>> gimp-developer-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gimp-developer-list
> 
> -- 
> Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list



smime.p7s
Description: S/MIME cryptographic signature
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list