Re: [Gimp-developer] I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

[Jehan Pagès]

Hi,

On Mon, Dec 9, 2013 at 4:35 PM, DeVonte Applewhite dappl...@nd.edu wrote:
 Hello,

First of all, do not send emails to only me please. You are lucky I
check my emails regularly and in particular answer them. Also I am not
the one who knows the code the best. If you really want answers, you
should send to the whole list. I added it in Cc.

 I am trying to just test out the gimpmath portion of the libgimpmath
 folder. It has the vectors, matrices and other math-related functions in it.
 I want to just take the contents of this folder, put these contents in a
 temporary folder that is inside this folder. I'll name that folder temp.
 then, I want to change the implementation of one of the .c files and test it
 with a driver program to see the individual functions get invoked. However,
 I am having a hard time compiling this setup because at times I am not
 including certain libraries and I do not know the exact location of the
 gdouble and gint variables that these programs use. Here is my makefile so
 far. mygimpvector.c is my implementation of the gimp vector.c program. Right
 now, mygimpvector.c is identical to gimpvector.c except for its name being
 different. Do you have any ideas?
 test: mattest.c mygimpmatrix.c
 gcc `pkg-config --cflags --libs glib-2.0` mattest.c mygimpmatrix.c -Wall

 Thanks in advance and hope to hear from you soon.

I don't really understand what you are speaking about. Are you
modifying core GIMP code (which last time we talked was your project)
or just testing out existing libgimp in say a C plugin?

As for all the g* types (gint, gdouble...), they are glib types, so
you have to find the adequate glib header to include, but I'm not sure
either that is what you are asking me about.

As for your mygimp* files, are they simply reimplementation of the
gimp* files similarly named? If so, why do you even bother making a
separate file? Why don't you modify inline the existing file, so that
you don't have to bother for modifying Makefiles? (you can always keep
a copy of the current files if you need side-by-side comparison, but
the new implementation should go in the gimp* files)

Also are you trying to modify directly Makefile-s (instead of
Makefile.am) and using bare gcc command lines there? This is a very
non-portable and broken way. No wonder you have issues. Look the
Makefile.am files and try to understand how these work (you can also
look for automake tutorials) if really you need to edit the
compilation.
But as I said earlier, if the goal is only to provide a new
implementation of an existing API, you should not have anything to do
to modify the build.

Jehan



 On Sun, Nov 17, 2013 at 7:24 PM, DeVonte Applewhite dappl...@nd.edu wrote:

 Thanks!!! Ah, now I understand. Our initial understanding was that since
 some parts were made in C++ there would be reason for doing more C++ coding
 in place of a few C code files. Thank you for clarifying that this plan has
 large problems and that it would not be merged to the main program
 (upstream). I think that the brushes are definitely a good route to look
 into . Thank you for the reference link. Yes, we do not have a large chunk
 of time, but we definitely will try to spend it as effectively as we can. I
 will try the IRC channel. It sounds like something I could definitely use
 since GIMP is a large project that can be overwhelming to understand at
 once. Glad people are happy and available to discuss questions, suggestions
 and such. I think my group can make a plan based on this information for
 sure. Thanks again.


 On Sun, Nov 17, 2013 at 6:38 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,

 On Mon, Nov 18, 2013 at 12:09 PM, DeVonte Applewhite dappl...@nd.edu
 wrote:
  Thank you for your response. We have used your input to clarify our
  direction on this project. What do you think of this.
  1. We will try to make a c++ implementation of gimpvector where we
  overload
  operators and try to string the executable together so that it
  compiles.

 As Sven also answered on the mailing list, GIMP is written in C, not
 C++. And even though it may happen that some components may be written
 in C++ if really it helped somehow (for instance when using some third
 party library in C++ which is the best at what it does), I'm pretty
 sure our maintainer won't accept any base class in C++, especially for
 no reason.

 Now if that's just for the fun of the experiment and the sake of your
 class project, go ahead. :-) But don't have your expectations too
 high, because such code may never make it upstream.

  2. We will try to make a c++ implementation of gimpmatrix where we
  overload
  operators and try to string the executable together so that it
  compiles. We
  will also see if we can generalize some of the code that implements
  operators.

 Same as above.

  3. We will attempt to fix at least one bug. If we can handle that, we
  will
  try to do more bugs given enough time before the project's due date.

 Cool.

  4. We

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

[Jehan Pagès]

Hi,

On Mon, Dec 9, 2013 at 4:38 PM, scl scl.gp...@gmail.com wrote:
 On 9.12.2013 at 4:23 AM Jon Nordby wrote:

 Apart from that, I think the solution for regular and consistent
 builds that many can contribute to is to get the build scripts
 upstream, and set up continious integration.


 +1

+1 here too!
I think this is exactly the kind of issues that could be fixed by
working all together upstream into 1 single awesome release instead of
having everyone making one's own personal build in one's corner, each
with their ups and downs.

There seems to be definite knowledge that is spread at least 3 people
already in this thread (Simone, Partha, and Jon). Instead it could be
gathered and shared to all in our repository.
That's just a repetition of the previous threads we had about this.
But we would really appreciate to get propositions to improve the
upstream release. Give us your scripts and your patches! :-D
This would be awesome.
Thanks.

Jehan

 I also considered integrating OSX builds into our Jenkins-CI in a later
 step. As yet I thought of using the JHBuild based solution in /build/osx
 (in the gimp-2-8 branch) and I think that's the proper destination if
 Partha or sb. else wants to push upstream.
 As build environment I consider either using an OS X VM on an OS X
 host or crossbuilding from Linux to OS X if that's possible.

 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
___
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

[Jehan Pagès]

Hi,

On Thu, Dec 5, 2013 at 11:55 PM, Partha Bagchi parth...@gmail.com wrote:
 Hi Jehan,

 I don't patch Gimp anymore. In the past I did due to issues with language
 UI, file size issues on Windows, etc. I feel that the source is quite mature
 and does not need patching.

 I started building the Windows version back during Gimp 2.7.1 when there
 were no betas available and also no 64-bit python. I also wanted a pure
 64-bit build. So, I took it upon myself to learn how to build all the
 dependencies and build Gimp. Similarly, I started building the OSX version
 when there was no pure OSX version and I wanted to learn how to build an app
 for Mac, and hence McGimp.

 For your question 3a ( you have 3 twice ;) ) - I have always mentioned the
 plugins I consider useful for photography on my website. I am reproducing
 the list here for completeness - you can always get the latest list from my
 builds:
 1.  G'MIC
 2.  Simple Bilateral Blur (edge preserving smoothing)
 3.  Save and Export
 4.  Resynthesizer
 5.  Refocus-it
 6.  David's Batch Processor
 7.  Exif-Browser
 8.  Wavelet-Denoise
 9.  Wavelet-Sharpen
 10. Wavelet-Decompose
 11. Texture Tiler
 12. Fix Chromatic Aberration
 13. Satequalizer (saturation equalizer)
 14. Advance Unsharp Mask
 15. Liquid Scaling (liquid rescale)
 16. Separate+ (color management in Gimp)
 17. Advanced Tone Mapping (faux HDR)
 18. Recover Shadows and Highlights
 19. ShellOut
 20. BIMP

 For question 3b, nothing prevents me from working with you. I think I do
 bring whatever issues I find to everyone's attention here.

 Finally as far as IRC is concerned, I have absolutely nothing against it and
 would have loved to participate. However, I just don't have the time.

 All the above I am doing as a hobby and I told you why I started it. I have
 not stopped since I have heard from a lot of people that they like my builds
 with all the plugins in one place and the 64-bit builds.

Thanks for the answer. So your build is not a patched GIMP. The only
plus are the embedded plugins (not that it is not a nice addition, but
I mean there is no core change). So you have not much to lose to
participate to the OSX official build.
You definitely have some knowledge to share, as discussed in another
thread. You could help us by setting up a nice OSX build system, with
automatic builds, maybe even some nightly, etc.

But if you really wish to continue also your own build because of the
plugins (because I can imagine that we won't suddenly integrate that
many additional plugins to maintain upstream. We have already quite a
lot of work for too few people!), I see at least 2 ways for you:

1/ you may create a special plugin-only combo containing all these
additional plugins; and for the main program, you redirect your user
base to the upstream GIMP;

2/ you still make your full build of GIMP + plugins, using the same
build scripts that you helped create upstream. They will likely be a
very simplified, robust and automatic version of everyone's current
procedure.

However I see this, working with us can only spare your time, whatever
you decide.

Jehan

 Hope this helps.

 Please let me know if you have any questions.

 Thanks,
 Partha



 On Wed, Dec 4, 2013 at 10:28 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi again!

 On Thu, Dec 5, 2013 at 12:42 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:
  Hi,
 
  On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi parth...@gmail.com
  wrote:
  Hi Sven,
 
  Have been away for the Thanksgiving holidays.:)
 
  On Sun, Nov 24, 2013 at 4:59 AM, scl scl.gp...@gmail.com wrote:
 
  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?
 
  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?
  What makes it so hard to speak to another at the mailing list or IRC
  and unite your forces? Come on, we don't bite ;-)
 
  Thanks for mentioning me. :)
 
  I am happy to collaborate with anyone

Re: [Gimp-developer] Fwd: GIMP Icons

[Jehan Pagès]

Hi,

On Mon, Nov 18, 2013 at 1:06 AM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi again,

 On Mon, Nov 18, 2013 at 12:25 AM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:
 Hi,

 On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning
 dra...@darkrefraction.com wrote:
 This was replied to just me, so I'm forwarding it to the entire list.

 Thanks Michael.


 -- Forwarded message --
 From: Andrew Pullins android2...@gmail.com
 Date: Thu, Nov 14, 2013 at 2:15 AM
 Subject: Re: [Gimp-developer] GIMP Icons
 To: Michael Henning dra...@darkrefraction.com



  You have not answered to the question. What version is it *exactly*?
  The last is 2.8.8. Just 2.8 is not enough, there has been 4 minor
  versions in 2.8. Please check the About of the program.


 here are some comments form my DeviantArt

 Linux

 Works fine on Debian Wheezy / Gimp 2.8.x

 Dark theme crashes on Ubuntu 12.04, but Light works fine.

 I just tested on my Linux Mint. The dark theme crashes too.
 So I tracked the bug. As I thought, the issue is in GTK+. I have fixed
 it on my locale development and will upload the patch tomorrow on
 Bugzilla (I want first to do a few more tests and see if it affects
 GTK+ 3 as well. But for now, I must sleep).

 Well in the end, I did not want to push it to tomorrow. So I just
 tested and made the ticket now.
 See https://bugzilla.gnome.org/show_bug.cgi?id=712536

 With this patch, we will handle better broken themes.

Just for your information, the patch has made it upstream and new
stables releases of GTK+ are planned for this week. Not sure when it
would make it to your distribution but when it will, the particular
crashes you experienced will be fixed (unless there were other issues
I could not discover) with GTK+ 2.24.23.

This being said, even though GTK+ will be now robuster on a faulty
theme, I would still suggest you to fix your theme with the
indications I gave you earlier. Then you don't have to ask your users
to wait for an updated GTK+. :-)
Bye!

Jehan


 In the meantime, you should fix your theme if you want it to work with
 current GTK+.
 In particular, just remove all the gap_file, gap_start_file and
 gap_end_file in your gtkrc which do not correspond to an existing
 image. These were the pieces of the gtkrc which was making GTK+ crash.
 Regards,

 Jehan


 [...]

  There seems to be a lot of missing icons in your set, and more
  problematic, several errors in the gtkrc.
  So that may explain why it does not work well (or at all) for some
  people (maybe it depends on the version of GTK+ installed). The best
  on your side would be to fix at least the gtkrc.


  well I can see how I messed some icons, there are a lot. as for the
 gtkrc I kinda just took a bunch of different themes mashed them
 together and ctrl found colors till switching them out got the look I
 wanted. I honestly have no idea what I'm doing with these themes. I
 did not know there was anything wrong with the gtkrc and have no idea
 where to start. I really wanted this to be a GMIP only theme, there
 seems to be a lot of GIMIP themes out there that can be used for many
 applications and there for have a lot of extra stuff that GIMP dose
 not need.

 I see. Well if you just follow all the warning output in a terminal,
 you can at least track all the non-existent images and get rid of the
 references in the gtkrc.
 That would be already a good start. :-)

  In any case, if really GIMP crashes because of this, that's not
  normal. It should not crash on wrong input. Could you please open a
  bug report: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP



  Then a developer (maybe me) will look into it when we have some time,
  and we'll try to reproduce the crash.


  I will do so.

 Well, now that I have fixed the bug, I may as well take care of the
 bug ticket too, I guess.
 Thanks for the report anyway.

 Jehan
___
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

[Jehan Pagès]

Hi,

On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi parth...@gmail.com wrote:
 Hi Sven,

 Have been away for the Thanksgiving holidays.:)

 On Sun, Nov 24, 2013 at 4:59 AM, scl scl.gp...@gmail.com wrote:

 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?

 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?
 What makes it so hard to speak to another at the mailing list or IRC
 and unite your forces? Come on, we don't bite ;-)

 Thanks for mentioning me. :)

 I am happy to collaborate with anyone on my builds. Note that I build Gimp
 and all dependencies from scratch using OSX gcc version 4.2.1; that is, I
 build gtk+, glib, pango, cairo etc. etc. etc. and then I build Gimp. I also
 include plugins that I believe are useful to photographers, well at least
 useful to me.

This would be very nice.
I have a few questions:
1/ Do you patch GIMP? Is it the reason why you make your own GIMP
build? If so, would you please contribute us all your patches? We
would be happy to check them and see what can be merged in our own
source. We are already working on merging some of Simone Karin
Lehmann's patches to improve our OSX code.
2/ Do you patch some of the third parties? GTK+, glib, etc. If so,
have you tried to contributing upstream to these various projects?
3/ What is exactly the list of plugins you include in your build?
3/ Is there anything else which would prevent you to work with us on
delivering a robust upstream OSX build (faster than currently after a
source release!) instead of duplicating the work? Note that we have
obviously nothing about third party builds. If you really wish to, you
can still make your own builds (maybe slightly different), even though
you would help us making the upstream one. But even so, this could
profit to all of us, for instance by sharing build systems, thus
improving the procedure.
Ideally we could automatize all builds for very easy and early release!

The way I see it, if we find a way to automatize builds, then we could
generate them on a server with no further human input, and available
for testers, which would make releases very easy to test (and
regenerate in case of issue) before any release.

 Finally, it's not really feasible for me to come to IRC and hence I loose
 out on some of those discussion.

Why is that? As I said to Simone too, I am not fond of IRC myself and
probably don't connect as much as the other contributors, but I make
some time to hang around there. If this is the price of collaboration,
it is not too high. Or is that a technical impossibility? (behind some
port-blocking firewall in a company or something?)

Thanks!

Jehan


 Thanks in advance,

 Sven

 Thanks again,
 Partha


 [bugreport]:
 https://bugzilla.gnome.org/show_bug.cgi?id=715094

 [showstopper in the Text tool]:
 https://bugzilla.gnome.org/show_bug.cgi?id=711281
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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
___
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

[Jehan Pagès]

Hi again!

On Thu, Dec 5, 2013 at 12:42 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi parth...@gmail.com wrote:
 Hi Sven,

 Have been away for the Thanksgiving holidays.:)

 On Sun, Nov 24, 2013 at 4:59 AM, scl scl.gp...@gmail.com wrote:

 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?

 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?
 What makes it so hard to speak to another at the mailing list or IRC
 and unite your forces? Come on, we don't bite ;-)

 Thanks for mentioning me. :)

 I am happy to collaborate with anyone on my builds. Note that I build Gimp
 and all dependencies from scratch using OSX gcc version 4.2.1; that is, I
 build gtk+, glib, pango, cairo etc. etc. etc. and then I build Gimp. I also
 include plugins that I believe are useful to photographers, well at least
 useful to me.

 This would be very nice.
 I have a few questions:
 1/ Do you patch GIMP? Is it the reason why you make your own GIMP
 build? If so, would you please contribute us all your patches? We
 would be happy to check them and see what can be merged in our own
 source. We are already working on merging some of Simone Karin
 Lehmann's patches to improve our OSX code.
 2/ Do you patch some of the third parties? GTK+, glib, etc. If so,
 have you tried to contributing upstream to these various projects?
 3/ What is exactly the list of plugins you include in your build?
 3/ Is there anything else which would prevent you to work with us on
 delivering a robust upstream OSX build (faster than currently after a
 source release!) instead of duplicating the work? Note that we have
 obviously nothing about third party builds. If you really wish to, you
 can still make your own builds (maybe slightly different), even though
 you would help us making the upstream one. But even so, this could
 profit to all of us, for instance by sharing build systems, thus
 improving the procedure.
 Ideally we could automatize all builds for very easy and early release!

 The way I see it, if we find a way to automatize builds, then we could
 generate them on a server with no further human input, and available
 for testers, which would make releases very easy to test (and
 regenerate in case of issue) before any release.

By the way! Since you also maintain a Windows build, all above
questions would also pertain to your Windows build!

Jehan

 Finally, it's not really feasible for me to come to IRC and hence I loose
 out on some of those discussion.

 Why is that? As I said to Simone too, I am not fond of IRC myself and
 probably don't connect as much as the other contributors, but I make
 some time to hang around there. If this is the price of collaboration,
 it is not too high. Or is that a technical impossibility? (behind some
 port-blocking firewall in a company or something?)

 Thanks!

 Jehan


 Thanks in advance,

 Sven

 Thanks again,
 Partha


 [bugreport]:
 https://bugzilla.gnome.org/show_bug.cgi?id=715094

 [showstopper in the Text tool]:
 https://bugzilla.gnome.org/show_bug.cgi?id=711281
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Updating gimp-win.sourceforge.net and Sourceforge old page as deprecated.

[Jehan Pagès]

Hi,

1) Today while browsing random pages, I saw references to the
Sourceforge page: https://sourceforge.net/projects/gimp-win/
I clicked and I see no warning message or anything there saying this
is not anymore the place to get newer versions of GIMP for Windows. So
I assume anyone who come to this page would think this is still the
page where GIMP for Windows happen.

Could whoever has admin right on this Sourceforge project add like a
big red message or something saying all these installers are old and
this page deprecated and redirect them to the new installer page?

2) Also the page http://gimp-win.sourceforge.net has been updated with
a link to gimp.org and a message. Nevertheless if you were to browse
and go to the FAQ page, the Download button would be bad again and
link to the old Sourceforge page, which is wrong:
http://gimp-win.sourceforge.net/faq.html

Could the maintainer of this page (Ender, isn't it?) update it?

Thanks a lot all!

Jehan
___
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

[Jehan Pagès]

Hi,

On Sun, Dec 1, 2013 at 12:44 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann sim...@lisanet.de 
 wrote:
 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/

 Thanks. I'll see what Clayton thinks about these.

We had a quick look with Mitch on the patches for GIMP specifically.
Many of them are obsolete now. For instance we already switched to the
Cocoa platform since 2.8.10 (commit
e56344294c90e1ba97de5c134b50c4c522f0808f which includes code from you
already!).

And some like the save/export, we obviously won't integrate, as you can guess.
But the color display change for instance seems promising. :-)
If you have other contributions you would like to see upstream, I
would really suggest discussing them with us and providing us patches.
This would really improve everyone's process!
Thanks anyway.

Jehan
___
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

[Jehan Pagès]

Hi,

On Sat, Nov 30, 2013 at 11:37 PM, Simone Karin Lehmann
sim...@lisanet.de wrote:

 Am 28.11.2013 um 22:25 schrieb Jehan Pagès jehan.marmott...@gmail.com:
 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.


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

 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.


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). 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?
Would you accept to contribute them to us?

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 :-).

 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.

Well this one is indeed useless now. :-)

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

I saw the email and the bug report from the contributor. Have you been
able to reproduce it also?

 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.


No problem. But this is exactly why it would be a lot better if you
could discuss with our team OSX packager (Clayton Walker). I'm sure a
collaboration into a single OSX release could save you time and allow
to do better testing.
May I ask exactly what is different with your release and the ones
that Clayton Walker do?

I see you add some photo editing plugins. Is that, along with the
third party patches, all the difference?

Maybe you could also drop by IRC (#gimp on irc.gimp.org) and discuss
with us some way to improve the situation?

Jehan

 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
___
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

[Jehan Pagès]

Hi,

On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann sim...@lisanet.de wrote:
 Hi,

 Am 30.11.2013 um 12:26 schrieb Jehan Pagès jehan.marmott...@gmail.com:

 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.


Well, this is up to you to decide. I know everyone of us, developers,
think we are right, at least at first. And maybe you even really are
(= maybe your building solution is nicer than Clayton's, I just have
no idea). But in the end, being right does not matter compared to the
benefits of collaboration. GIMP would be nothing compared to what it
is now if it had stuck to be a single-man project.
Stubbornness is usually a good thing... up to one point. :-)
But yes in the end, you are to decide what you want to do.

 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/

Thanks. I'll see what Clayton thinks about these.

 Would you accept to contribute them to us?

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

Well on our side, we have not much to give, or negotiate. We just
want to collaborate with as much packagers as possible, so that they
become actual upstream contributors and save everyone's time, but also
give a much better user experience to all users.

 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.

Well I wish you could also see the other side of the story. Now I
don't know your exact cases of course, but I am a Free Software
contributor too. And I got all sort

[Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hello Peter,

Some time ago, a contributor developed a very interesting feature,
allowing to search actions with natural language keywords
(https://bugzilla.gnome.org/show_bug.cgi?id=708174).

For instance, if you want to search a blur filter to apply to your
image, you could just type in blur and see a list of relevant
actions: for instance you'll find in the list the blur / sharpen
tool, but also the Gaussian Blur, Selective Gaussian Blur,
Tileable Blur, Circular Motion Blur filters, and even Difference
of Gaussians... (because it does a difference of 2 gaussian blurs!).

No need to search in infinite menus and submenus. If you know a common
natural language keyword, you can just search for it, which also makes
it even easier for users of other software who don't know in which
menu to look for which filter, but even for advanced GIMP users when
they know a filter's name but don't remember where to find it.
Such a search would be even localization-aware, since a French would
search for flou and a German for weichzeich instead of blur.

In summary, the user could open the action search dialog (default
shortcut: '/') anytime, type a keyword, select the desired command in
the list and run it.

The original proposition has been largely improved, and is now in the
branch origin/tito on the GNOME git repository of GIMP.
Since I know you have a working development installation now, that
would be easy to check out, and test. Of course, if any question on
how to do so, do not hesitate to ask.

I have also written an exhaustive specification draft of the current
implementation:
http://wiki.gimp.org/index.php/Specs:Action_Search_Dialog

This specification details the search algorithm, and the GUI interaction.

We would appreciate a feedback from you, about this feature and the
user interaction.
Thank you very much!

Jehan
___
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] UI theme for GIMP

[Jehan Pagès]

Hi,

On Thu, Nov 28, 2013 at 8:01 PM, scl scl.gp...@gmail.com wrote:
 Hi,

 the topic to equip GIMP with a better UI theme has come up
 from time to time and especially recently.

 I have set up a wiki page for our work on this:
 http://wiki.gimp.org/index.php/Specs:UI_Theme
 (conditional to find a better place).

Cool, thanks.

 Comments are welcome.

I think we all agree that the existing default themes (the ones named
Default and Small) won't disappear. And that seems to be confirmed
by what you wrote on the wiki page: It's no aim to supersede the
current GIMP themes 'Default' and 'Small'. They shall reside as
'System' themes.

Then I have 2 questions:

1/ Will the symbolic themes be the new default? Which one? Dark one
(with light icons) or light one (with dark icons)?

2/ Can we still have the Default/Small colored icons evolved? I feel
that some people may prefer to keep the older theme. And I guess there
are for every taste. And I can definitely see some evolution. I think
the color icons are not that bad. Yet some icons could definitely be
redrawn.

Thanks.

Jehan


 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
___
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] Fwd: GIMP Icons

[Jehan Pagès]

Hi,

On Wed, Nov 27, 2013 at 8:23 AM, Andrew Pullins android2...@gmail.com wrote:
 I was wondering why are there so many different sized icons? I mean I
 understand that GIMP has different sized icons, but sometimes it does not
 care what size the icon is it will insert it anyway. I noticed that my color
 switcher icon (aka stock-swap-colors-12) was not working,  and I found
 that it was because I made it a 24x24 icon. once I resized it back down to
 12 it was find. but on the other hand, my stock-join-miter-16 is not 16x16
 but in-facet 24x24. So why are there some many different icons? there are
 16x16, 24x24, 32x32, 48x42, and 64x64. GIMP does not care what file format
 it is in, or at least it does not care that my themes are all .SVG. what
 makes it even more confusing is when there are four red Channel icons.

Well I don't know the answer to this. :-)
If you want better chances of answers, you better send your questions
to the mailing list, not to me only. I forward it for you.

Jehan


 On Sun, Nov 17, 2013 at 8:47 PM, Andrew Pullins android2...@gmail.com
 wrote:

 I have GIMP 2.8.8 installed on Ubuntu 13.10


 On Sun, Nov 17, 2013 at 7:22 PM, Andrew Pullins android2...@gmail.com
 wrote:

 My GIMP has not crashed in some time. Thats what makes this bug so
 strange, it seems to depend on your OS and GIMP build. I'm not in front of
 my computer but I'll tell you what my GIMP version is.

 On Nov 17, 2013 4:55 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,

 On Mon, Nov 18, 2013 at 10:39 AM, Andrew Pullins android2...@gmail.com
 wrote:
  And here are the errors I get when I load the light theme
 
  ~$ gimp
  /home/andrew/.gimp-2.8/themes/Flat-Light/gtkrc:3: error: unexpected
  character ':', expected character '='
  GIMP-Error: Failed to load data:
 
  Couldn't recognize the image file format for file
  '/home/andrew/.gimp-2.8/patterns/GPS-Pat/Canvas-Covered.xcf'
 
  GIMP-Error: Failed to load data:
 
  Fatal parse error in gradient file
  '/home/andrew/.gimp-2.8/gradients/Untitled.ggr': Read error in line 1.

 Hmmm. I had more than that, even for the light theme.
 In any case, after fixing all the gap files, did the crash stop at
 least?

 Jehan



___
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

[Jehan Pagès]

Hi,

On Sun, Nov 24, 2013 at 10:59 PM, scl scl.gp...@gmail.com wrote:
 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?

 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?
 What makes it so hard to speak to another at the mailing list or IRC
 and unite your forces? Come on, we don't bite ;-)

A little in-topic and off-topic about the Windows build! Could we make
sure that all patches of third party that we know of are used for the
official release this time? In particular, all relevant patches
applied to the nightly build! Because the last GIMP 2.8.8 for Windows
release still had bugs that were already fixed on the nightly builds.

I see in particular 2 bugs related to fontconfig (there may be other
patches I don't know of, better ask Drawoc and check the dir
build/windows/jhbuild/patches/):

- The conf.d path bug: https://bugzilla.gnome.org/show_bug.cgi?id=708110
Fixed either with patch in the repo:
build/windows/jhbuild/patches/fontconfig-fix-config-dir.patch
Or by using fontconfig = 2.11.0

- Better fontconfig cache directory:
https://bugzilla.gnome.org/show_bug.cgi?id=703331
Still in discussion upstream, but if we feel this is the way, we can
already apply the patch available there:
https://bugs.freedesktop.org/show_bug.cgi?id=71691

A small in-topic note, back to OSX build: Clayton Walker proposed to
update the cache directory for the OSX build, but it has been rejected
upstream: https://bugs.freedesktop.org/show_bug.cgi?id=71715

Well maybe all the OSX package maintainers and developers in our team
could discuss this, and if they all agreed a change in fontconfig
cache was in order for the OSX build, well you can configure it
appropriately. Even though a change upstream is nicer, that's still
only a configuration change, so we should do it.

If that helped people, we can also organize a small release meeting?
In any case, I really agree with Sven, that we can really improve the
quality of our releases, whether on OSX (with package dispersion) or
Windows (synchronisation with nightly and stable).

Regards,

Jehan


 Thanks in advance,

 Sven

 [bugreport]:
 https://bugzilla.gnome.org/show_bug.cgi?id=715094

 [showstopper in the Text tool]:
 https://bugzilla.gnome.org/show_bug.cgi?id=711281
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

[Gimp-developer] Setting Up a Release Procedure

[Jehan Pagès]

Hi all,

I'd like to propose to set-up some procedure for releases.

That's not necessarily code and scripts (though in the end, the more
automatized we can be, the better), but at first it could be at least
just writing one wiki page saying what happens in general for a
release, then we write 1 additional wiki page per release for any
specifics.

This way, we can:
- organize ourselves so that work is not duplicated;
- write down not-to-forget information of any manual procedure until
we manage to automatize it;
- write down release-specific details like version of bundled
dependencies (may be important for us, developers, to know what is
used in a release), but also the list of applied patches (let's stop
maintaining different patches in each build! That's a lot of boring
job for you; and makes upstream life difficult if we don't know this),
the build configuration (which options you used in ./configure, etc.).
- not rely entirely on our benevolent maintainers (Sven and Mitch),
but anyone can be a part of helping the release happen, which would
mean a release better tested, but also much faster to happen.

The best example of what can go wrong is the last release: GIMP 2.8.8.
We ended up apparently with major bugs on OSX Mavericks; and several
fontconfig bugs on Windows, which were already fixed in the nightly
builds for ages!
This kind of thing should not happen and should have been detected
before release.

I took the liberty to set the pace by creating a new wiki namespace
Release. I hope that's ok and that it is not considered a bad move.
And I created 2 pages in this namespace:

1/ The general information where we want to set all information about
the process in general: the release procedure, all the patches to
apply for every release.
http://wiki.gimp.org/index.php/Release:General_Information

2/ One page for the specific GIMP 2.8.10 release:
http://wiki.gimp.org/index.php/Release:GIMP_2.8.10

Please if we have any TODO or tasks or something, just write them down
there. If people wants to participate and take on a task, they could
just write down their name next to an existing task and the result.
This is a working page, edits should happen there!

Also I propose that before a build is officially released, they are
first listed on this page for willing people to test it and an email
should also be sent on the dev mailing list. If all goes well, all
tasks done, and all builds are tested and look good, then we can
publicly announce a release and distribute builds that have been
actually tested first.

What do you think?

Jehan
___
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] HELP with SYMBOLIC icon theme for Gimp: license

[Jehan Pagès]

Hi,

On Wed, Nov 27, 2013 at 8:24 PM, jEsuSdA 8) lis...@jesusda.com wrote:
 El 27/11/13 07:04, Jehan Pagès escribió:

 Also am I right to assume that we want to have*all*  icons in this

 style, and get rid of all the generic GTK+ icons too?


 I like it!
 When using a desktop icon theme like Faenza, Gimp looks like great, but if
 you use another more colorful icon theme, it looks like a bit strange. :D

Ok I'll make a small list of all the missing icons. There seems to be
quite a few. And I'll add it in a wiki pageof wiki.gimp.org. Since
there may be several designer who want to give a try to draw the
missing icons, I guess I'll ask to every one who wants to do so to
write his name in front of an icon before starting to create it.

I'll follow up with the link later.

Jehan



 I want to help to do that! ;)

 Salu2 de jEsuSdA 8)

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

[Gimp-developer] Patch to add to build/windows/jhbuild/patches/

[Jehan Pagès]

Hi Drawoc,

We have this bug report about the fact that fontconfig's default cache
directory on Windows may not be very well chosen.
https://bugzilla.gnome.org/show_bug.cgi?id=703331

I've opened a bug report upstream to propose another default, but in
the meantime, whether or not the change is accepted upstream, I guess
we can use this new default in our builds. Using the temp folder may
indeed not be the wisest (same on Linux, we usually never save things
in a temp folder if we expect it to be still available at next
reboot).
So you can just have a look at the upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71691
There is a patch there. I guess we can use it in our builds, no?
Bye!

Jehan
___
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] Fwd: GIMP Icons

[Jehan Pagès]

Hi,

On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning
dra...@darkrefraction.com wrote:
 This was replied to just me, so I'm forwarding it to the entire list.

Thanks Michael.


 -- Forwarded message --
 From: Andrew Pullins android2...@gmail.com
 Date: Thu, Nov 14, 2013 at 2:15 AM
 Subject: Re: [Gimp-developer] GIMP Icons
 To: Michael Henning dra...@darkrefraction.com



  You have not answered to the question. What version is it *exactly*?
  The last is 2.8.8. Just 2.8 is not enough, there has been 4 minor
  versions in 2.8. Please check the About of the program.


 here are some comments form my DeviantArt

 Linux

 Works fine on Debian Wheezy / Gimp 2.8.x

 Dark theme crashes on Ubuntu 12.04, but Light works fine.

I just tested on my Linux Mint. The dark theme crashes too.
So I tracked the bug. As I thought, the issue is in GTK+. I have fixed
it on my locale development and will upload the patch tomorrow on
Bugzilla (I want first to do a few more tests and see if it affects
GTK+ 3 as well. But for now, I must sleep).

 [...]

  There seems to be a lot of missing icons in your set, and more
  problematic, several errors in the gtkrc.
  So that may explain why it does not work well (or at all) for some
  people (maybe it depends on the version of GTK+ installed). The best
  on your side would be to fix at least the gtkrc.


  well I can see how I messed some icons, there are a lot. as for the
 gtkrc I kinda just took a bunch of different themes mashed them
 together and ctrl found colors till switching them out got the look I
 wanted. I honestly have no idea what I'm doing with these themes. I
 did not know there was anything wrong with the gtkrc and have no idea
 where to start. I really wanted this to be a GMIP only theme, there
 seems to be a lot of GIMIP themes out there that can be used for many
 applications and there for have a lot of extra stuff that GIMP dose
 not need.

I see. Well if you just follow all the warning output in a terminal,
you can at least track all the non-existent images and get rid of the
references in the gtkrc.
That would be already a good start. :-)

  In any case, if really GIMP crashes because of this, that's not
  normal. It should not crash on wrong input. Could you please open a
  bug report: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP



  Then a developer (maybe me) will look into it when we have some time,
  and we'll try to reproduce the crash.


  I will do so.

Well, now that I have fixed the bug, I may as well take care of the
bug ticket too, I guess.
Thanks for the report anyway.

Jehan
___
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] Fwd: GIMP Icons

[Jehan Pagès]

Hi again,

On Mon, Nov 18, 2013 at 12:25 AM, Jehan Pagès
jehan.marmott...@gmail.com wrote:
 Hi,

 On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning
 dra...@darkrefraction.com wrote:
 This was replied to just me, so I'm forwarding it to the entire list.

 Thanks Michael.


 -- Forwarded message --
 From: Andrew Pullins android2...@gmail.com
 Date: Thu, Nov 14, 2013 at 2:15 AM
 Subject: Re: [Gimp-developer] GIMP Icons
 To: Michael Henning dra...@darkrefraction.com



  You have not answered to the question. What version is it *exactly*?
  The last is 2.8.8. Just 2.8 is not enough, there has been 4 minor
  versions in 2.8. Please check the About of the program.


 here are some comments form my DeviantArt

 Linux

 Works fine on Debian Wheezy / Gimp 2.8.x

 Dark theme crashes on Ubuntu 12.04, but Light works fine.

 I just tested on my Linux Mint. The dark theme crashes too.
 So I tracked the bug. As I thought, the issue is in GTK+. I have fixed
 it on my locale development and will upload the patch tomorrow on
 Bugzilla (I want first to do a few more tests and see if it affects
 GTK+ 3 as well. But for now, I must sleep).

Well in the end, I did not want to push it to tomorrow. So I just
tested and made the ticket now.
See https://bugzilla.gnome.org/show_bug.cgi?id=712536

With this patch, we will handle better broken themes.

In the meantime, you should fix your theme if you want it to work with
current GTK+.
In particular, just remove all the gap_file, gap_start_file and
gap_end_file in your gtkrc which do not correspond to an existing
image. These were the pieces of the gtkrc which was making GTK+ crash.
Regards,

Jehan


 [...]

  There seems to be a lot of missing icons in your set, and more
  problematic, several errors in the gtkrc.
  So that may explain why it does not work well (or at all) for some
  people (maybe it depends on the version of GTK+ installed). The best
  on your side would be to fix at least the gtkrc.


  well I can see how I messed some icons, there are a lot. as for the
 gtkrc I kinda just took a bunch of different themes mashed them
 together and ctrl found colors till switching them out got the look I
 wanted. I honestly have no idea what I'm doing with these themes. I
 did not know there was anything wrong with the gtkrc and have no idea
 where to start. I really wanted this to be a GMIP only theme, there
 seems to be a lot of GIMIP themes out there that can be used for many
 applications and there for have a lot of extra stuff that GIMP dose
 not need.

 I see. Well if you just follow all the warning output in a terminal,
 you can at least track all the non-existent images and get rid of the
 references in the gtkrc.
 That would be already a good start. :-)

  In any case, if really GIMP crashes because of this, that's not
  normal. It should not crash on wrong input. Could you please open a
  bug report: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP



  Then a developer (maybe me) will look into it when we have some time,
  and we'll try to reproduce the crash.


  I will do so.

 Well, now that I have fixed the bug, I may as well take care of the
 bug ticket too, I guess.
 Thanks for the report anyway.

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

[Gimp-developer] Default file name for file-export action

[Jehan Pagès]

Hi Peter,

Currently if you started a work from an image (jpg, png, whatever) the
first export dialog will propose you the original source image name
as export filename.

In other words:
1/ Open foo.jpg
2/ Modify your image.
3/ ctrl-e (export)
4/ The default proposition for an export filename is foo.jpg (in
other words, by default, it proposes to overwrite your source!).

But I think that's not right, because it goes against the logics of
not destroying your source files as a *default* workflow. You can
still enter the same file name if you really wish it, but then you
have to do it explicitly. The default should be for instance
Untitled.jpg (same as the default for saving will be Untitled.xcf
on the first save).
I've actually already made mistakes sometimes when testing some image
modification quickly and did not really care about the filename, as
long as it is different as the original. I just wanted to export it.
Untitled.jpg would have been fine to me. But it proposed me the
original by default, very risky if I go on a frenzy Enter-Enter usage!

Moreover even for those who have needs of quick edition of the
original file, without saving, there is the file-overwrite action
anyway (for which they can make a shortcut). The file-export would
be more for those who want to *really* export, to a different name,
no? So the default filename proposition should be different, in my
opinion.
What do you think?

Anyway I have already made a patch proposing this change, and Mitch
told me to ask you what you think about it:
https://bugzilla.gnome.org/show_bug.cgi?id=712194
Thanks!

Jehan
___
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] Default file name for file-export action

[Jehan Pagès]

Hi,

On Wed, Nov 13, 2013 at 11:20 PM, Mikel Garai mi...@garai.eu wrote:
 May I suggest leaving it as it is?

Just for information, nothing is decided yet. That's just a proposition from me.

 for the ones of us that take, e.g. 1000 pictures, and want to do some little
 adjustment in most of them, the workflow is already a pain with the new
 save/export thing, don't make it any harder please.

 My typical workflow is:

  * browse the images in geeqie
  * open an image in gimp (i.e. IMG_38210.jpg)
  * make little changes (takes me about 1-5 minutes)
  * save (well, now export) to IMG_38210_0.tif (is just replacing .jpg
with _0.tif)

Actually Mitch, our maintainer proposed something similar (see
https://bugzilla.gnome.org/show_bug.cgi?id=712194).
So we could have a default of IMG_38210-1.jpg for instance.
This one is fine by me too. Probably even better than Untitled.jpg
actually. Only thing I didn't like was that the default name was
*exactly* the same as the source in current code. So IMG_38210-1.jpg
is all good. Close but still different.

  * close image in gimp (and normally export again just in case, that
unsaved changes dialog is scary)
  * continue browsing images in geeqie

 The thing is that if the export dialog does not automatically put the name
 of the file in it I will have to manually enter it looking at the window
 title, so more room for human errors in the process (that in big amount of
 files could be significant, and if I open 3 files it could be just
 infinity).

I see. Well this other proposition (like adding a -1 after the
basename) would suit you well, I think then.

 Saving them to .xcf is not a practical option since I then convert them to
 .jpg and scale them in a batch process with imagemagick (to distribute
 them) and because it does not save me any time even if I have to redo some
 images.

 Yes yes, I know that I'm not the target user and I probably will have to end
 up using something like darktable or similar (even if I prefer geeqie for
 browsing, directories for organizing and gimp for editing) but I want to

I would not say so, even though I know some other developers would use
these words. I have another conception, and for me GIMP is a generic
or general image manipulation software (this was actually even the
original acronym actually, according to Wikipedia, but the meaning of
the G was changed later from General to GNU), so is destined to a
whole range of different users with a broad range of use cases.

Now it is clear that GIMP is a complex software with *a lot* of
features, so it is obvious that using it for basic fixes may not be
the primary use case, because simpler software may be better (= have
nicer workflow) at doing this.
So my opinion is not that you are not the target user, but rather that
there may be other software better suited to what you do. Which is not
the same thing, in my opinion. :-)

 postpone that change as much as possible. So please, leave the Export path
 for the daredevil users that do not want to be protected from ourselves,
 you already have the save path with Save file actions.

Also I'd like to note something that you may have already seen on the
mailing list: there will now be from next release a simplified way to
close the image without saving: in the quit/close image dialog, you
can ctrl-d to close without saving. It means that you can ctrl-w-d
for instance to close an image instantly without saving to XCF (or
ctrl-q-d to close the whole GIMP without saving).
I think that's a very nice change for all the users who use GIMP
without saving, just like you. :-)
So you see! You are the target user! ;-)

 And for Jehan, yes, is kind of weird to use export with the default name
 set to the same of the one opened, but is meant to be export from gimp
 which format is xcf, so saving to any other format is actually exporting
 it (if I understood correctly from previous emails in this list)

It is somehow true. But the goal of this distinction is not for the
sake of the distinction. It has a reason: preventing data
loss/destructive editing. So if the export dialog proposes by default
to overwrite the source file, well that's not really following the
concept, in my opinion.

Jehan

 Best Regards,

 Mikel





 On 13/11/13 09:42, Jehan Pagès wrote:

 Hi Peter,

 Currently if you started a work from an image (jpg, png, whatever) the
 first export dialog will propose you the original source image name
 as export filename.

 In other words:
 1/ Open foo.jpg
 2/ Modify your image.
 3/ ctrl-e (export)
 4/ The default proposition for an export filename is foo.jpg (in
 other words, by default, it proposes to overwrite your source!).

 But I think that's not right, because it goes against the logics of
 not destroying your source files as a *default* workflow. You can
 still enter the same file name if you really wish it, but then you
 have to do it explicitly. The default should be for instance
 Untitled.jpg (same as the default for saving

Re: [Gimp-developer] Quick-edit workflow

[Jehan Pagès]

Hi,

On Wed, Nov 13, 2013 at 11:49 PM, peter sikking pe...@mmiworks.net wrote:
 Jehan wrote:

 Just checking master, currently when overwrite is shown, export-to
 is not grayed out but it is invisible.
 That means that it is active and can be run if you know the shortcut,
 but you can't export from the menu (for people who don't know
 shortcuts, new or casual users, etc.).
 Is it intended? I feel like this is a mistake and that Export To
 should always show up in the menu.
 I could easily fix this.

 yes this is intentional. the spec says:

 ‘The shortcut for the Export menu item shall remain active and map to 
 invoking the Export As… command, sneaky, but true.’

 I have done this so that users who press ctrl-E by habit are not
 stopped by nothing happening. Users who browse the menu see
 Export As... (the new label) and pick that.

 nobody gets hurt. things work as expected. sneaky, but true.

 In any case, I have written a patch here:
 https://bugzilla.gnome.org/show_bug.cgi?id=712192

 I guess you can tell if that's good for you


 Sorry Jehan, no. you change too much and I must say,
 with devastating effect.

 first of all I did my job and updated the spec:

 http://gui.gimp.org/index.php/Save_%2B_export_specification

 checked 98 occurrences of “export” (twice) and updated
 to the new situation.

 in a nutshell, all it is is a string change.

 Export... - Export As...

 (no other changes to this menu item or the code behind it.

 “Export to” - Export (when no export target)

 (this is the menu item where “Export to foo.xyz” and
 “Overwrite foo.xyz” are swapped in as appropriate)

 do not touch the Save menu items, they work fine, as-is,
 since 1984. Save is for the main window content and the
 name of that is in the title bar of that main window.

 and that is it.

Ok. I'll simplify the patch.

Should I change the action's names to follow their label? In
particular Export would correspond to file-export and Export
As... corresponds to file-export-as (otherwise we would end up in
the strange situation where Export = file-export-to and Export
As... = file-export).
Or you care only about UI, not action names, and I should ask Mitch for this?
Thanks.

Jehan


 --ps

 founder + principal interaction architect
 man + machine interface works

 http://blog.mmiworks.net: on interaction architecture



 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Default file name for file-export action

[Jehan Pagès]

Hi,

On Thu, Nov 14, 2013 at 12:54 AM, peter sikking pe...@mmiworks.net wrote:
 Jehan wrote:

 Actually Mitch, our maintainer proposed something similar (see
 https://bugzilla.gnome.org/show_bug.cgi?id=712194).
 So we could have a default of IMG_38210-1.jpg for instance.

 please don’t.

 there is two reasons that I am against tampering with this:

 1) when using Export As... (new label), there are 3 things that
 can be changed:

 the location (say, directory), the name, the file type (extension)

 2 out of 3 times, the name does not need changing.

 2) the same ‘danger’ exists for Save As... but I think
 we all manage quite well with that one.

Well, I feel that the Save As... is quite different, because we
don't touch the source data.
But anyway, ok. I'll close the ticket then.

 Yes yes, I know that I'm not the target user and I probably will have to end
 up using something like darktable or similar (even if I prefer geeqie for
 browsing, directories for organizing and gimp for editing) but I want to

 [snip]

 So you see! You are the target user! ;-)

 no that is not what we are doing with this. it does not mean
 that the non-savers are target users now.

That's not really what I said. :-) I feel there is not just 1 single
type of target users of GIMP, is more what I am saying. Anyway, just
some Free Software philosophy: Free Software is what their
contributors and users make of it. And that's more or less the way I
contribute to FOSS. So it's personal, and that's ok if others don't
agree. :-)

 what we are doing is a renewed effort to take all the
 friction out of the non-saving paths for as much as we
 can (without throwing away the clear separation principle),
 for the benefit of all users.

And I think that's pretty nice. :-)

Jehan

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://blog.mmiworks.net: on interaction architecture



 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] I am hoping to contribute to GIMP. I have some ideas, but I want input if possible.

[Jehan Pagès]

Hi,

On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite dappl...@nd.edu wrote:
 Hello all,

 I am in a Data Structures class which has a final project. This project
 requires students to fix bugs, improve preexisting data structures, or add
 extra features to an open source project that has an active community. My
 group chose GIMP.

Nice choice! :-)

 I have some ideas about changing data structures in hopes
 of generalizing some implementations, improving execution speed and
 reducing the amount of code needed to complete implementation of the .h
 files.

 Here are 3 of our ideas. If you could give input (feasibility, faults in
 our plan of action, predicted improvements upon success of these ideas,
 suggestions) on any or all of our ideas, that would be greatly appreciated.

Well I won't comment all the ideas in detail, and my guess is there
are few chances others will either, because that would take quite a
time! We don't know the whole code by heart, so to understand what you
speak about, we would have to read the code you speak about carefully;
and even so, when I see the kind of changes you propose, I'm not sure
we will just say that's good ideas out of our head by just reading
code. You seem to be proposing mostly API change or code optimization.
But as often in optimization, it starts with gut feeling (except when
dealing with obvious bad designs), and some algorithm cost
computation, but in the end only real testing will really tell.
So if you really feel that's the way to go, you can still implement
it, test it, and if it appears to be a lot better than previously,
then you won. Propose a patch with some benchmark results and someone
will have at look at this.

Now this said, I really wonder if API changes or algorithm
optimizations are the best way to start in OpenSource contribution. A
codebase like GIMP is huge and very complicated and you want to start
with base classes. First of all, classes which are used in a lot of
places may also break many different pieces of code if you change
things (API or algorithm) there. So that implies a lot of regression
testing, which means a lot of time.
Second, even though base classes are indeed used in a lot of places,
and optimizations are always good, well it is not that obvious that
the optimization will get that tremendous speed improvements compared
to all the other things done along the way.
Last, API change just for the sake of API change, I'm not sure that's
the best idea. We will usually do something because we actually want
to use it and see it will make actual code better. I'm not sure if API
change which may make some future code better is a good way to do
it.

I would think an easier way to start contributing is to fix bugs. We
have quite a lot of bugs in our bug tracker waiting to be fixed. Just
pick some of them, and fix them. Then you are sure this will be wanted
code, and there is no maybe or incertitude. Also that's a lot
easier, though very visible.

But if you're sure your propositions are worth it, the best is to do
the changes and propose patches. :-) As I said, I haven't looked at
them in details. Maybe that's great ideas, no idea. I know some
contributors start with base consolidations, not fixes. It happens.
In any case, have fun with GIMP,

Jehan

 1. gimp/libgimpmath/gimpmathtypes.h (file in
 question:gimp/libgimpmath/gimpmatrix.h(c))
 This file declares math structures that gimp uses like vectors and
 matrices. The GimpMatrix structure come in 2X2, 3X3 and even 4X4 versions.
 Each matrix is a 2Dimensional gdouble array with the appropriate amount of
 elements to span the NXN matrix.I believe this data structure is used for
 computation during image editing. There are functions handling
 comparisons, identities, transformations, rotations, translations and
 various other
 matrix operations. Possible changes: I believe the declaration of 3 special
 kinds of gimp
 matrices can be generalized to a struct (or class) that holds and defines
 an NXN matrix. We
 could make it as general as possible to save the amount of code necessary
 to complete the tasks. This also eliminates two extra structs in the .h
 file. We could also change the structure that holds the matrix elements.
 One way could be by making a nested linked list to emulate an NXN matrix.
 This way, we keep everything in memory and not on the stack. If necessary,
 we could even overload the [] operator to make the functionality act like
 an array. We could also use the std::vectorT data structures included in
 the vector library to allow for pushing and popping of matrix data
 structures to make them dynamic and or more fail-safe.

 2. gimp/app/core/gimpcontainer.h
 This class contains a data structure that is used to store different things
 about the
 various objects in gimp. It works hand and hand with the GimpObject class.
 This
 class uses what I believe to be some form of tree or heap structure. The
 class
 refers to add, remove, reorder, and getChild functions that 

Re: [Gimp-developer] GIMP Icons

[Jehan Pagès]

Hi,

On Mon, Nov 11, 2013 at 5:42 PM, Andrew Pullins android2...@gmail.com wrote:
 Hello,

 I am sorry if this is not the right place to ask this. I have been creating
 a theme for GIMP specifically to change out all the icons in GIMP.
 hopefully the development team has taken notice to a recent OMG Ubuntu
 article http://www.omgubuntu.co.uk/2013/09/gimp-icon-flat-themethis  about
 this. Direct link to my theme on my
 DeviantArthttp://android272.deviantart.com/art/GIMP-Icon-Theme-Flat-375010811.

Nice theme. I personally did not hear of this one before (but I am
rarely first on news).
It makes me think of another monochrome theme which was talked about
quite a bit recently:
https://plus.google.com/+AlexandreProkoudine/posts/LP1pWr7YEgA
There is also another version of these icons for light background made
by another contributor. Actually we are discussing about including
this new set of icons in the next official release (GIMP 2.10) and the
3 icon designers have already agreed to license these icons as GPL for
inclusion in our code repository.

 but there seems that people are having a problem with my theme. depending
 on what version of gimp and OS the users run my themes different things
 happen. sometimes the icons do not change, sometimes it crashes GIMP,
 sometime the Dark theme dose not work and the Light one does, sometimes
 nether do. I my self have gone from Ubuntu 12.10 to 13.04, changing nothing
 about the theme it started crashing GIMP.  but then updating to GIMP 2.8

Is it the last stable version (2.8.8)?

 fixed it. But then some users have reported it crashing in Ubuntu. It does
 not work for anyone that uses windows or mac.

 I know that this is not you guys are working on or what this list is for,
 or even the most important thing to tackle right now. But would it be
 possible for someone to look at my theme and see why it is acting so
 strangely? even some incite on how GIMP themes work that might help me fix
 the problems. any help would be appreciated. People really like these
 themes and would love to work in them. I hope you like them as well.

Does it crash on startup, or it first loads fine then crashes later on?
Are you sure the themes are the cause of the crash? If you remove the
themes, it won't crash anymore?
In other words: do you have reproduction steps?

If you start from a terminal, when it crashes, do you see some error
log output? Because just it crashes is not a very detailed report.
Some error output might help us.

Apart from this, nice work on theming GIMP. Keep up the good work. :-)

Jehan

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Quick-edit workflow

[Jehan Pagès]

Hi,

On Sun, Nov 10, 2013 at 2:25 PM, peter sikking pe...@mmiworks.net wrote:
 guys + girls,

 it is a tricky thing, this overwrite vs. export.

 there is a difference, overwrite is for working ‘backward’
 as I called it: doing some work on a non-gimp file and
 feeding this directly back to it. it is labelled brutally and
 frankly, with intent. export is for working ‘forward’, towards
 a new result.

 but as Richard comments, the difference is not that big.
 this is what I exploited in the design for repurposing
 the Export-to item for Overwrite.

 of course one can use Export... to set up to write over
 one of the source files of the composition one is working on.

 thus exporting is the general game, with one special case
 built in: hardwiring the initiating source file as export
 target and giving this a fearsome name (beware: burning bridges)

 Yes, Export-to and Export... mirror images of Save and Save-as...

 I think I can see what Akkana means: when there is no export
 target, the menu items are “Export to” and “Export...”
 that is not ideal. and it’s clear that it irritates people.

 note that the export-to item cannot be grayed out in this case.
 ctrl-E just has to work (leading to an Export..., yes, just
 as the first Save is a Save As...)

Just checking master, currently when overwrite is shown, export-to
is not grayed out but it is invisible.
That means that it is active and can be run if you know the shortcut,
but you can't export from the menu (for people who don't know
shortcuts, new or casual users, etc.).
Is it intended? I feel like this is a mistake and that Export To
should always show up in the menu.
I could easily fix this.

 reviewing the situation, I see that the straightforward solution
 is to relabel

 Export... - Export As... (in all states)

 “Export to” - Export (when no export target)


I like the change. When there is an export target, should it become
Export As somefile.png?

Jehan

 you can see that this achieves perfect mirroring of
 Save and Save As...

 “Export to foo.xyz” and “Overwrite foo.xyz” stay as-is,
 they work well with Export As...

 (just in case you wonder, yes I am giving up on something
 by doing this: in so many other application the label on
 the export menu item is Export... )

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://blog.mmiworks.net: on interaction architecture



 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Quick-edit workflow

[Jehan Pagès]

Hi,

On Wed, Nov 13, 2013 at 1:45 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 On Sun, Nov 10, 2013 at 2:25 PM, peter sikking pe...@mmiworks.net wrote:
 guys + girls,

 it is a tricky thing, this overwrite vs. export.

 there is a difference, overwrite is for working ‘backward’
 as I called it: doing some work on a non-gimp file and
 feeding this directly back to it. it is labelled brutally and
 frankly, with intent. export is for working ‘forward’, towards
 a new result.

 but as Richard comments, the difference is not that big.
 this is what I exploited in the design for repurposing
 the Export-to item for Overwrite.

 of course one can use Export... to set up to write over
 one of the source files of the composition one is working on.

 thus exporting is the general game, with one special case
 built in: hardwiring the initiating source file as export
 target and giving this a fearsome name (beware: burning bridges)

 Yes, Export-to and Export... mirror images of Save and Save-as...

 I think I can see what Akkana means: when there is no export
 target, the menu items are “Export to” and “Export...”
 that is not ideal. and it’s clear that it irritates people.

 note that the export-to item cannot be grayed out in this case.
 ctrl-E just has to work (leading to an Export..., yes, just
 as the first Save is a Save As...)

 Just checking master, currently when overwrite is shown, export-to
 is not grayed out but it is invisible.
 That means that it is active and can be run if you know the shortcut,
 but you can't export from the menu (for people who don't know
 shortcuts, new or casual users, etc.).
 Is it intended? I feel like this is a mistake and that Export To
 should always show up in the menu.
 I could easily fix this.

 reviewing the situation, I see that the straightforward solution
 is to relabel

 Export... - Export As... (in all states)

 “Export to” - Export (when no export target)


 I like the change. When there is an export target, should it become
 Export As somefile.png?


In any case, I have written a patch here:
https://bugzilla.gnome.org/show_bug.cgi?id=712192

I guess you can tell if that's good for you, so that it can be committed. :-)

Jehan

 Jehan

 you can see that this achieves perfect mirroring of
 Save and Save As...

 “Export to foo.xyz” and “Overwrite foo.xyz” stay as-is,
 they work well with Export As...

 (just in case you wonder, yes I am giving up on something
 by doing this: in so many other application the label on
 the export menu item is Export... )

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://blog.mmiworks.net: on interaction architecture



 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Thu, Oct 31, 2013 at 11:31 AM, Michael Schumacher schum...@gmx.de wrote:
 On 28.10.2013 19:59, scl wrote:
 Hi,

 in matter of the unclear license situation I asked the FSF
 for clarification and like to share their answer (see below).
 It's not a legal advice, but I hope it sheds us some light
 on the issue.

 Unfortunately your mail seems to discard the fact that the icons are run
 through gdk-pixbuf-csource. So the FSF probably assumed that the icons
 are included as individual files alongside the binaries.

I wonder though. Do we *have to* compile them as source files?

I mean, users can provide their own themes, thus their own icon set
too, right? And I assume these icons won't be extracted into source
files, since they are loaded at runtime. So that means the default
icons could be just provided alongside the binaries too, just as
third-party's are.

So why do we extract them? Is it like for some efficiency gain reason
(like the default theme would be faster than any third-party theme)?
I mean, there cannot possibly be that a huge gain that it is worth to
do so, compared to licensing issues.
Or is there any other reason?
Thanks.

Jehan


 --
 Regards,
 Michael
 GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hello Jimmac,

my name is Jehan. I am a GIMP developer. We are considering releasing
the next major release of GIMP with an additional icon set, which goes
well with a darker theme. A contributor (jEsuSdA, in Cc) added the
missing icons and also made an alternate version which would go with a
lighter theme.
See here a photo of the dark theme:
https://plus.google.com/+AlexandreProkoudine/posts/LP1pWr7YEgA
And here the light theme: http://www.pasteall.org/pic/show.php?id=60269

It seems you were the original author of the icon set, which maybe you
can confirm us by having a look at the screenshots.

If not mistaken, your work is under a Cc by-sa 3.0 license, which is a
fine license, but would be a problem for one of the default icon set
provided in the official GIMP release, because we actually compile the
icons into source code. And the problem is that Creative Common by-sa
is not compatible with GPLv3.
So my question is simple: would you accept to double-license this
specific set of icons as GPLv3 to allow us to safely include it in our
next major release of GIMP?
Thank you very much.

Jehan

On Thu, Oct 31, 2013 at 5:01 AM, jEsuSdA 8) lis...@jesusda.com wrote:
 El 29/10/13 01:57, Jehan Pagès escribió:

 Hi,

 On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8) lis...@jesusda.com wrote:

 El 28/10/13 18:37, Alexandre Prokoudine escribió:


 Is your theme from October 4 the latest version?


 Here is the latest version:

 http://www.jesusda.com/files/symbolic-gimp.7z


 Reading Sven email about a possible licensing issue, and if I
 understand, you are the author of the icon set. Would you accept to
 double license your work under a GPL license? I guess this would
 simplify the whole discussion and problematic.


 I am not the author of all icons. The main work was made by the Gnome Design
 Team (I think Jimmac has made this nice work). I transformed and created new
 ones, and I converted all the work to a gimp theme.

 I have absolutely no problem to license and relicense this theme. I think
 there are no problem about that and I made this work not only for me, but
 for all gimp users.

 So, if you think a dual license or relicense of the work it will be fine,
 then all is ok for me. ;)

 Of course, you must ask Jimmac too.




 By the way, Sven, which GPL version is the theme?

 Anyway yes, I would love to see a dark theme with a renewed icon set
 available in GIMP 2.10. :-)



 The problem with CC and GPL appears to be when you include the icons in
 binary files. As both CC and GPL forces to mantain the same license in
 derivative works, is not posible to include the icon in a gimp binary and
 mantain the software on GPL or mantain the icons in CC, cause is the same
 file.

 The Gimp icons ARE NOT COMPILED, are ONLY USED, and anybody can EXTRACT and
 MANIPULATE the icons mantaining the CC license restrictions, so, I think it
 is possible include a set of CC icons in Gimp and this not violate CC and
 GPL, cause GPL is for code and CC is for the icon theme.

 Is the same case as help files or plugins. They can use other licenses,
 cause you can clearly separate the help files or plugin from main gimp
 application.

 I undertand this when reading the Sven mail. I'm wrong or wright?


 Thank you!
 jEsuSdA 8)
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Thu, Oct 31, 2013 at 5:01 AM, jEsuSdA 8) lis...@jesusda.com wrote:
 El 29/10/13 01:57, Jehan Pagès escribió:

 Hi,

 On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8) lis...@jesusda.com wrote:

 El 28/10/13 18:37, Alexandre Prokoudine escribió:


 Is your theme from October 4 the latest version?


 Here is the latest version:

 http://www.jesusda.com/files/symbolic-gimp.7z


 Reading Sven email about a possible licensing issue, and if I
 understand, you are the author of the icon set. Would you accept to
 double license your work under a GPL license? I guess this would
 simplify the whole discussion and problematic.


 I am not the author of all icons. The main work was made by the Gnome Design
 Team (I think Jimmac has made this nice work). I transformed and created new
 ones, and I converted all the work to a gimp theme.

 I have absolutely no problem to license and relicense this theme. I think
 there are no problem about that and I made this work not only for me, but
 for all gimp users.

 So, if you think a dual license or relicense of the work it will be fine,
 then all is ok for me. ;)


Cool!

 Of course, you must ask Jimmac too.




 By the way, Sven, which GPL version is the theme?

 Anyway yes, I would love to see a dark theme with a renewed icon set
 available in GIMP 2.10. :-)



 The problem with CC and GPL appears to be when you include the icons in
 binary files. As both CC and GPL forces to mantain the same license in
 derivative works, is not posible to include the icon in a gimp binary and
 mantain the software on GPL or mantain the icons in CC, cause is the same
 file.

 The Gimp icons ARE NOT COMPILED, are ONLY USED, and anybody can EXTRACT and
 MANIPULATE the icons mantaining the CC license restrictions, so, I think it
 is possible include a set of CC icons in Gimp and this not violate CC and
 GPL, cause GPL is for code and CC is for the icon theme.

That's also what I thought and what I said earlier on this thread:
 I know that the FSF says not to use it for code, but it says it is
 good for arts though. And I think since themes are not compiled in
 or linked to the code,
And Michael Schumacher answered to this by:
 They are. Their icons at least, see
 https://git.gnome.org/browse/gimp/tree/themes/Default/images/Makefile.am#n394
 ff.

So well now I'm not sure anymore. Though checking the said file, I
would not say they are compiled in, merely listed as filenames
(which could therefore apply to any other set of icons with the same
names). Only stock-question-64.png seems kind of compiled as pixel
data into gimp-core-pixbufs.h. So I would say that if problem there
were for licensing, it would be only on this icon (and since this icon
displays a Wilber, I guess it was not in the original set, and you are
the author, aren't you?).

 Is the same case as help files or plugins. They can use other licenses,
 cause you can clearly separate the help files or plugin from main gimp
 application.

 I undertand this when reading the Sven mail. I'm wrong or wright?

Then indeed in Sven's email, the FSF person says:

 if the software is merely displaying the icons, could
 just as well display any others, and doesn't rely on specific attributes
 of those particular icons then they shouldn't be considered derivatives
 and could be distributed alongside the GPL'd work in mere aggregation
 (http://www.gnu.org/licenses/gpl-faq.html#MereAggregation)

So here I understand that it can indeed very well apply to icons (even
though they might be compiled somehow in some cases?), because a theme
and icons are replaceable in mere aggregation, and there is nothing
specific about any icon set.

In any case, I would think that there is no problem at all. But same
as the FSF replier said, I am no layer either.
The simpler and safer is to re-license. That's why I asked. If all
authors license to GPL3+, same as the rest of the code, then we just
have no problem altogether, for sure.

Of course, this is only because we may want to distribute this
publicly. For any icon set, theme, plugin or whatever which is not
distributed (a user made it for himself) or distributed separately and
aggregated to GIMP later, then there is no legal issue for the user,
who is perfectly allowed to do so.

Jehan



 Thank you!
 jEsuSdA 8)
___
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] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Thu, Oct 31, 2013 at 11:26 AM, Michael Schumacher schum...@gmx.de wrote:
 On 30.10.2013 23:14, Jehan Pagès wrote:

 So well now I'm not sure anymore. Though checking the said file, I
 would not say they are compiled in, merely listed as filenames
 (which could therefore apply to any other set of icons with the same
 names). Only stock-question-64.png seems kind of compiled as pixel
 data into gimp-core-pixbufs.h.

 Please read that whole Makefile(.am). And run make in that directory and
 check the results.

Yes I did read the whole Makefile.am, but I don't know how I did not
see gimp-stock-pixbufs.h. :-)
Indeed all the default icons are compiled as pixels in a header.

Well the safer and simpler is to ask this Jimmac. If he is from the
GNOME project, as I understand, I guess he would have no problem with
double-licensing his work under GPLv3+.
Is anyone in contact with him and could ask him to make an official
answer (maybe on this mailing list or other public place) about it?

Thanks!

Jehan


 --
 Regards,
 Michael
 GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8) lis...@jesusda.com wrote:
 El 28/10/13 18:37, Alexandre Prokoudine escribió:

 Is your theme from October 4 the latest version?

 Here is the latest version:

 http://www.jesusda.com/files/symbolic-gimp.7z


Reading Sven email about a possible licensing issue, and if I
understand, you are the author of the icon set. Would you accept to
double license your work under a GPL license? I guess this would
simplify the whole discussion and problematic.

By the way, Sven, which GPL version is the theme?

Anyway yes, I would love to see a dark theme with a renewed icon set
available in GIMP 2.10. :-)

Jehan


 The problem with the color picker icon persist. :S




 @Everyone, how about we merge it?


 I think it will be a great idea. Gimp looks like great with this theme.


 Thanks!
 jEsuSdA 8)


 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

[Gimp-developer] crossroad: developer tool for cross-compiling GIMP for Windows under Linux

[Jehan Pagès]

Hi fellow developers,

I thought I'd share the tool I developed for myself, to compile GIMP
for Windows.
This is the continuation of the tutorial I wrote there after my first
successful cross-compilation:
http://wiki.gimp.org/index.php/Hacking:Building/Windows
And as such, it is inspired by Ender's grab-stuff.sh, and Maarten
Bosmans' download-mingw-rpm.py (this last script is still used in
background, but has been highly improved from the original. It can now
also query some information about and list files of a package, will
fix all broken symlinks after installation, handle various failure
cases, can uninstall a package, etc.).

But in particular my wrapper tool is highly simplified because I was
bored of writing down long commands that I could never remember fully
anyway (damn what was the --host value already?), so I always had to
refer to and copy/paste my own tutorial. My tool (named crossroad in
hommage to Robert Johnson's Cross Road Blues) is the nicey way to
cross-compile!

Here is how I compile GIMP master *from scratch* on Linux for Windows 64-bit.
All the dependencies are automatically downloaded and installed in the
right place) from Fedora MinGW project. Only babl and gegl are
compiled dependencies from git master (and cairo because it requires a
version unavailable in Fedora repo).

I Timed the whole procedure in 15 minutes. :-)

$ crossroad w64
$ crossroad install gtk2-devel libjpeg-devel win_iconv-devel
libtiff-devel iso-codes-devel liblzma-devel libbz2-devel
$ cd cairo-1.12.16
$ crossroad configure
$ make  make install
$ cd ../babl
$ crossroad configure
$ make  make install
$ cd ../gegl
$ crossroad configure
$ make  make install
$ cd ../gimp
$ crossroad configure --disable-python
$ make  make install
$ exit
$ crossroad --compress=mygimp.zip w64

And that's it! I've got a zip archive mygimp.zip (yes zip, because
that's for Windows users) to give to someone to test. When I test on
my own VM, I don't need a zip, I would just symlink my prefix into my
shared Virtualbox directory.
$ cd /my/shared/directory
$ crossroad --symlink w64

If you want to understand better, the tool is installed with a nice
man along (`man crossroad` for full tool description).
The whole process took me 15 minutes the other day, using totally clean repos.
That allowed me for instance to provide a build easily to a user to
test for a fix there:
https://bugzilla.gnome.org/show_bug.cgi?id=675554

Well if anyone is interested, you can get the tool with a:

$ pip3 install crossroad

That's python3 = 3.3 only.

Or get the archive there for manual installation:
https://pypi.python.org/pypi/crossroad/

Ask if you have any question. I hope it will be useful to other people
wishing to compile GIMP (or any other software. This is a very generic
tool!).

Jehan
___
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] Google Code-In program

[Jehan Pagès]

Hi,

On Mon, Oct 14, 2013 at 1:50 AM, Tobias Jakobs tobias.jak...@gmail.com wrote:
 Hello,

 and there is the Outreach Program for Women:
 https://wiki.gnome.org/OutreachProgramForWomen

Looks nice. At least they have real payment. It does not feel like cheap labor.

 I thin that could be very interesting for Gimp too.

I'd be glad to mentor someone there too.

Jehan

 Regards,
 Tobias

 2013/10/12 scl scl.gp...@gmail.com:
 Hi,

 beside the 'Summer of Code' program for students Google
 offers 'Code-In', a program for pre-university students,
 ages 13-17 years old. The program can be found at
 http://www.google-melange.com/gci/homepage/google/gci2013

 Tasks for these students include coding, documentation,
 training, community management, outreach/marketing, problem solving,
 quality assurance and user interface tasks.
 I could i.e. imagine tasks in the fields of GEGL porting, testing,
 documenting, translation, website maintenance, bug triaging etc.

 Do we want to join this program this year?

 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
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Translator available

[Jehan Pagès]

Hi,

On Thu, Oct 10, 2013 at 4:35 AM, Abraham Mireles Alvarez
abraham_al...@hotmail.com wrote:
 Hello everyone

 Just eanted to let you know that I am available as a translator in case you 
 need help


I'm not a translator for GIMP, who would know better what procedure
there is. But I guess a first step would be to clone the git
development repository of GIMP, compile it, and see what is missing or
wrong. Maybe there could be an easier procedure for translators, where
you could use existing builds, and just compile the po files, but I
have no idea if such a process is in place.
Because if you work off a released version, you can't be sure if
something has not already been translated by someone else.

Then you could edit the po files. Do you know about gettext syntax?
This might be the next step. :-)

If someone more versed into translation than me would answer you, that
would be great, though. But I would suggest you to come on the IRC
channel. Most of the contributors prefer to discuss through this
channel, rather than email: http://www.gimp.org/irc.html

Have fun!

Jehan

 Spanish- english

 I got a 630 at the TOEFL
 :)
 Enviado desde mi iPhone
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] My plugin doesn't start anymore after upgrading mingw/gcc suite

[Jehan Pagès]

Hi,

On Wed, Oct 9, 2013 at 12:05 AM, Alessandro Francesconi
alessandrofrancesc...@live.it wrote:
 You know what? I give up, for now.

 I spent like an entire day searching for a solution to this problem... and I 
 solved it simply by removing the current mingw32 package and re-installing 
 an version which still includes gcc 4.7.0 (luckily found on another PC).

 I can't really focus on a possibile solution, I've everything on the right 
 place (GIMP-dev and GTK-dev libraries, in primis) and the only thing that 
 changed was the version of gcc, from 4.7 to 4.8 branch.

 With gcc 4.7, compiled for mingw32 on Windows 64bit, I just run the bat 
 command I posted before in order to compile every new version of BIMP.

Same as others, I can't help much without much information. I see one
thing I would do in your place though: have you tried completely
cleaning out all the compiled files first before recompilation? I
don't know which compilation system you use (autotools, cmake...), but
even though they are very good, sometimes they would not detect a good
reason for re-compiling. And I figure that a change of your compiler
version is a very good reason, and that because of it, the whole
project should be recompiled. Maybe there may be issues by mixing
objects compiled by different compilers.

If you use git, you can for instance git clean -d -f -x (be careful,
it would clean *any* file not versionned, even files listed by the
.gitignore. So be careful if you kept non-versionned files you don't
want erased).

 The resulting 32bit binary is put on the usual GIMP's plugin directory, no 
 matter if 32 or 64bit distribution because as far as I know GIMP on a x64 
 machine can run plugins for both the architectures: 
 http://www.dpreview.com/forums/post/41353679. That's the reason why I never 
 had problems in distributing a 32bit-only versions of my plugin. They simply 
 work everywhere.


But do you use the mingw-w64 project or the original mingw project
(which has no 64-bit support, as far as I know, and has different
features, I think)?

 On the other hand, if doing the same thing but using gcc 4.8, the resulting 
 32bit .exe is twice the size of the previous one and crashes when loaded by 
 GIMP.

 @drawoc: your tip is good, but in order to use gdb I must re-compile GIMP 
 with debug symbols. I've never done it before and I haven't got time to solve 
 issues that might arise from this step under Windows.

 So, thank you. Maybe I'll face this problem again in future, but I'd like to 
 deal with other issues for now.
 By the way, a new version of BIMP is out, if you're interested: 
 http://www.alessandrofrancesconi.it/projects/bimp


Finally if none of the answers you get here help you, I would suggest
to ask to the mingw/mingw-w64 mailing list/IRC rather than here. They
might be better suited to help you.

But yeah if an older version of GCC works well, you may also as well
stay there for the time being. I myself use an older version of
mingw-w64 gcc, the one in my distribution repository. And I don't see
the need to install by hand a more recent version.

Jehan


 From: dra...@darkrefraction.com
 Date: Sun, 6 Oct 2013 17:21:02 -0400
 Subject: Re: [Gimp-developer] My plugin doesn't start anymore after 
 upgrading mingw/gcc suite
 To: alessandrofrancesc...@live.it
 CC: gimp-developer-list@gnome.org

 It's hard to help you without any additional information. I would
 suggest that you grab mingw's gdb and try debugging the plugin with
 that. You can try these instructions:
 https://git.gnome.org/browse/gimp/tree/devel-docs/debug-plug-ins.txt
 I forget if they work on windows.

 Anyway, good luck!

 On Sat, Oct 5, 2013 at 5:43 AM, Alessandro Francesconi
 alessandrofrancesc...@live.it wrote:


 Anyone can give me help? I’m still blocked for this problem. As I said to 
 Partha in private, I can’t figure another reason about this, apart from a 
 GCC’s fault.
 The fact is that my code worked few minutes before upgrading to GCC 4.8.1, 
 then, without changes, the new compiler made it “invisible” to GIMP.



 Moreover, the plugin now crashes when queryied by GIMP at startup 
 (http://www.alessandrofrancesconi.it/bimp-fail.jpg).

 My system is Windows 8 64bit, GIMP 2.6.8.



 Can it be related to the 64bit environment? Never had problems before.






 Ale




 Da: Alessandro Francesconi
 Data invio: venerdì 4 ottobre 2013 11.12
 A: gimp-developer-list@gnome.org



 Hello everyone,

 This morning, on my Windows platform, I’ve decided to run a “mingw-get.exe 
 upgrade” command in order to give a fresh update to my compiling tools.

 The process finished fine and the GCC version changed from 4.7.2 to 
 4.8.1... but I shouldn't have done it!


 I went to my plugin source code (it’s BIMP, by the way), then I run the 
 usual batch command in order to compile it with the “new” tools. The 
 compiler ended without errors, but now the plugin is disappeared from GIMP!

 One strange thing after the upgrade: the filesize of my 

Re: [Gimp-developer] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Sun, Oct 6, 2013 at 9:08 PM, Sven Claussner scl.gp...@gmail.com wrote:
 Another thing we should consider is the license. The used symbolic
 icon set is licensed under the Creative Commons Share Alike License 3
 (CCBYSA3). It is probably [incompatible with the GPL] used in GIMP
 and could also be incompatible with Linux distributor approvals.
 IMHO either the icon set and theme are relicenced under the GPL or we
 need something else if we want to integrate them into GIMP.
 The Darklooks theme uses the GPLv2.

Why would CC by-sa v3 *for themes* be incompatible with GPLv3 *for
code*? Do you have any information to backup this?

I know that the FSF says not to use it for code, but it says it is
good for arts though. And I think since themes are not compiled in
or linked to the code, there is absolutely no legal need to have
compatible licenses. I am pretty sure there are a whole bunch of Free
Software projects out there which use CC by-sa for arts (themes,
icons, etc.) and GPL for code. And we were even considering this a few
days ago on the IRC channel (relicensing all our brushes/pattern and
all other GIMP default data in CC by-sa).

I am no lawman though, so if you have more information about this
claim, ok. Otherwise from what I thought to know, there is absolutely
no problem to have CC by-sa for themes in our main tree.

Jehan

 If this is clarified: As the 2.8 branch is for bugfixes I'm for
 integration into the master branch so the theme will be in the 2.10
 release and who likes can use it in 2.8 anyway (both use GTK+ 2).

 JEsuSdA 8) thanks anyway for your work. You did a great job and now
 that we're further there's surely less work to be done. Keep it up! :-)

 Kind regards,

 Sven

 [incompatible with the GPL]:
   http://www.gnu.org/licenses/license-list.html
   http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licenses

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Sun, Oct 6, 2013 at 3:11 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 On Sat, Oct 5, 2013 at 12:59 AM, Simon Budig si...@budig.de wrote:
 jEsuSdA 8) (lis...@jesusda.com) wrote:
 Working on gtkrc I have solved F bug and improve the icons visualization.

 Thanks for your efforts, that indeed looks really great. I'm all for
 including it in the main gimp source.

Damn I should re-read me before posting. Parentheses badly placed and
it lose any meaning! I meant:

I'm ok for it too. And I would be also very nice to have an included
dark theme as soon as possible (not waiting for 3.0). Because
everybody says it's so better for graphics work, blabla, but each time
I try one, it's broken somehow (some pieces of the UI stayed light,
missing icons, etc.). So if we could have an optional one in the main
tree, that we know fully works with GIMP, that would be awesome! :-)

Obviously it could just be the GTK+3 default dark theme that we would
have maybe tweaked to work with GIMP 2.10.

Thanks for the theming work anyway!

Jehan

 The bug D is almost done: eye icon has changed, bug when clicked,
 there are no closed eye showd, so, I need help to solve this.

 I am not sure if I understand the bug: the default theme does not
 contain a closed eye icon.

 Do you see the default eye when the mouse button is pressed down? Then
 apparently the stock icon definition for the ACTIVE widget state is
 wrong for some reason.

 Thanks,
 Simon

 --
   si...@budig.de  http://simon.budig.de/
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Next minor release?

[Jehan Pagès]

Hi,

On Fri, Oct 4, 2013 at 10:34 PM, Michael Natterer mi...@gimp.org wrote:
 On 10/04/2013 10:12 AM, Jehan Pagčs wrote:
 Also we have a bunch of fixes in gimp-2-8 branch anyway, and it is
 soon 4 months since 2.8.6. Maybe it is a good time to make a minor
 release? I feel like there is no much reason to delay bugfix releases.
 Do we have an accurate policy on minor releases?


 ASAP, when I find the time :)

Awesome. :-)

Jehan

 --Mitch

___
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] Next minor release?

[Jehan Pagès]

Hi,

On Sat, Oct 5, 2013 at 12:19 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Fri, Oct 4, 2013 at 12:12 PM, Jehan Pagès wrote:

 It was the reason of why italic/bold could not be simulated anymore in
 2.8.6 for Windows.

 And I suggest we keep it that way. Committing crime against typography
 isn't going to make us popular among professionals.

Well I personally have no opinion there. But I know that some people
liked this. And in this case, I would say that this should not be our
call. If people want simulated italic/bold, why prevent them? The
professionals would use fonts with the right faces, that's all. :-)
That does not break anything in the workflow of people who don't want
to use this.

In any case, massively breaking fontconfig is not the way to achieve this. ;-)

Also if we were to make such a change, it would only pertain to
Windows users, because that's the only release where we embed
Fontconfig. Other users, at least on Linux (and I guess OSX too, no?),
would have a system-wide fontconfig already and we are not going to
override the user's custom configuration.

But if a typography erudite wishes to get rid of this criminal
feature, one just has to delete the following file, and you are done:
/etc/fonts/conf.d/90-synthetic.conf
(that's the Linux most common path. You can just find the equivalent
for another installation/platform)
And that's it! :-)

Jehan


 Alexandre
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Next minor release?

[Jehan Pagès]

Hi,

On Sat, Oct 5, 2013 at 12:42 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Fri, Oct 4, 2013 at 3:37 PM, Jehan Pagès wrote:

 It was the reason of why italic/bold could not be simulated anymore in
 2.8.6 for Windows.

 And I suggest we keep it that way. Committing crime against typography
 isn't going to make us popular among professionals.

 Well I personally have no opinion there. But I know that some people
 liked this. And in this case, I would say that this should not be our
 call. If people want simulated italic/bold, why prevent them?

 Because fake italics and bold faces are an abomination :)

 http://tavmjong.free.fr/blog/?p=822

I understand. I would still not remove the feature altogether. Maybe
there could be a warning when someone requests a bold/italic when
there is no such face and we are simulating them (GIMP does not handle
this, but maybe there is a way for us to get a feedback when this
happens), because I feel that the main issue is not that the feature
exists, but rather that there is no feedback about this from the
software.
If we were to give such a feedback, the typographic erudite would know
to step away from this font, or at least do an informed choice about
the matter.

I would personally not be against a feature request along this line.
Giving the right feedback to users, and making them informed and
active rather than passive in their choices, is totally my view of
things.
If you write such a feature request, please Cc me. :-)

Jehan

Jehan

 Alexandre
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

[Gimp-developer] Idea of a Plug-In manager

[Jehan Pagès]

Hello Ingo, and all GIMP devs,

I found you are the registry.gimp.org maintainer, so I hope it's ok
for me to send you this message. I am a GIMP developer, and a GIMP
user just gave me an idea and I found it very cool, so I am trying to
check the water temperature and see how feasible it would be.

Basically he was interested in a Plug-In Manager, which could be a
master plug-in in GIMP able to browse the plug-ins, their description,
note and comments, and install/uninstall them in a click. In other
words, a plugin manager a-la Firefox. And I thought that was a really
cool idea.

I don't see this as any priority, and likely such a thing would not
happen in the next major release. But maybe for GIMP 3.0 for instance,
that would be an awesome feature, in my opinion. Even more since GIMP
2.10 would likely break compatibility with many plug-ins, with the
full switch to GEGL, that would be a good time to start a structured
plug-in repo.

As I see it, one of the pre-requisites would be to have a more
structured registry. Not just drupal free-form pages (it can still be
drupal, I don't really care, but there should be semantic logic of the
page and its contents, to know the plug-in name, with files in the
right format, which version it is reported to work or not, etc.).
So I was wondering, do you think this kind of change could be possible
in some future of the registry.gimp.org website, or do you just let it
run without any plan of further improvement? The latter is fine, and
that's still nice contribution, just to know if you were up for
bigger. :-)

Of course there would be more pre-requisites for such a project, like
more contributors involved to manage such a registry, I think. But as
I said, I just check the temperature to see if anyone is interested.
And also, I repeat, this is just an idea thrown out there. No code or
anything like this yet.
Right now I just discussed this idea a little on IRC.
Thanks for reading.

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

[Gimp-developer] Licensing documentation and re-licensing GIMP data

[Jehan Pagès]

Hi all,

We were just discussing with Patrick David that there is a bunch of
tutorials with copyright but no licensing information on the gimp-web
repository. So that makes them impossible to touch.

Since that's a lot of very old tutorials anyway and outdated for many,
he is cleaning out a lot of these. I proposed that once we have only
new documentation, we add a COPYING file in the repository root with
an appropriate license (CC by-sa for instance?), because the repo has
no such file right now, so that all future contributions should be
considered free documentation, still with authorship, but at least
really modifiable and distributable.

Another way would be to contact all contributors of current data, but
Patrick David tells me that he plans to remove and replace a lot of
doc anyway, so that's probably unnecessary for the time being. Also
there are apparently past contributors we might not want to contact.

For information, we can get the list of all contributors with `git
shortlog -s` (I count 43 names right now, but if we remove duplicate
(name bugs), and all current contributors, that makes maybe not even
20 names of old contributors, I think.
With this command, we can even get a formatted list, ready for
emailing (then we can do some manual filtering out if needed):
$ git shortlog -s -e | tr \\n , |sed -r 's/\s*[0-9]+\s*/ /g'

We can even get the list of names with actual current contents (number
of lines) by using git-blame:
$ git ls-tree --name-only -z -r HEAD | xargs -0 -n1 git blame
--line-porcelain | grep ^author  | sort | uniq -c

Anyway, that's *if* we need to contact anyone. :-)

Schumaml also proposed that we could relicense GIMP data (brushes,
patterms, etc.) as well and place a more appropriate license for the
data. This could pertain to both the data/ directory of the main gimp
repository (36 names only with `git shortlog -s data/ |wc -l`), and
the whole gimp-data-extras (only 11 names!) all together.
Currently the main GIMP data is GPLv3+ and the data-extras has a GPLv2+ license.

Has there any thoughts about this? Could we go with a CC  by-sa for
all documentation and all data?
For my own, I am obviously ok with such a licensing of the commits I
may do in these parts of the project. :-)

Jehan
___
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] List of dependencies (versions and configuration options) for GIMP on Windows

[Jehan Pagès]

Hi,

On Thu, Sep 26, 2013 at 2:50 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 On Mon, Sep 23, 2013 at 1:51 AM, Michael Henning
 dra...@darkrefraction.com wrote:
 At the time I fixed this, Jernej's builds did not exhibit the problem
 because they used an older version of fontconfig. I did not report
 this upstream because it's a configuration issue, but now that I think
 about it, the defaults should perhaps be changed on windows (or maybe
 when cross compiling).

 Yes I am not sure if upstream or else, but definitely somethings
 should be done *somewhere*, otherwise we might have various new
 developers to the team (or the same ones, forgetting it happened
 already) scratching their head with this problem every 6 months. The
 simple fact that the last Windows build is broken even though you had
 this fixed from before this release is a sign there should be
 something in place for this to not happen again. :-)

Just for information, I have now opened a report upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=69836

Jehan
___
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] Environment.

[Jehan Pagès]

Hi,

On Sat, Sep 28, 2013 at 7:46 PM, Román ro...@mailoo.org wrote:
 Hi everyone,

 I have been trying to build gimp from git but I cannot because old
 pkg-config, babl, gegl, gtk+ and other packages. So I tried to compile
 all these packages from source. So, my question is: what do developers
 do? do you build all gimp dependecies from source? do you use debian
 unstable or something like that to get latest packeges?

You don't need a cutting edge pkg-config, nor gtk+. What you have in
your debian is likely enough (or else, debian is very late on its
versions). You will likely only need the master babl and gegl.
That still makes 3 packages to build from source (babl, GEGL and
GIMP), but they are very easy to compile. That's basically the usual
deal:
$ ./configure
$ make
$ make install

 I would like to learn by making changes in gimp and in the future to help.


We welcome any new help. :-)

Jehan
 Regards.
 Román!
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Enhancement request GIMP Search for all commands

[Jehan Pagès]

Hi,

On Wed, Sep 25, 2013 at 9:22 PM, Srihari Sriraman srih...@visishta.net wrote:
 Hey Mika,

 It's great to see you person share my needs as well.
 I built Tito for GIMP a couple of years ago for the same purpose.

 Here is a demo: http://www.youtube.com/watch?v=G0PuH1LFWhA
 I even blogged about it: http://sriharisriraman.in/blog/2013/09/15/gimp-tito

 Good thing is that Jehan is now helping in getting this into master.
 You can see the progress on that in the feature request here:
 https://bugzilla.gnome.org/show_bug.cgi?id=708174

And I think I am done with it. :-)
Please have a look at your cleaned patch + mine. If you're happy with
it, the best to go on would be to bug Mitch for review on IRC. :p

Jehan

 If you are a developer, please do join in! it would be great to have
 another collaborator on this.


 On Tue, Sep 24, 2013 at 2:04 PM, Mika mika.ras...@gmail.com wrote:

 Hello Gimp Developers,

 I have been using GIMP for some time. I'm using it for logos, cards, photo
 editing etc. I as many others at my workplace I find it a bit hard to find
 the correct tool for a certain job. GIMP's overwhelming collection of tools
 is a bit hard to search through with mouse in the big menu structure.

 I got to thinking that there is a great solution for this in a coding IDE I
 use for work. Its global command and action search. I am talking about
 IntelliJ IDEA and its ctrl-shift-a quick search.

 Here is a picture of what I mean.

 Possibly it could be context sensitive. Also if you could change the
 context with some extra keys or mouse work while the search is on, I
 suspect it would be really helpful. Ofcourse also provide the keyboard
 shortcuts in the menu, so users can use the tool to learn those also.

 What do you think?

 Anyhow hope you find the time to finalise the discussion on this idea and
 it finds its way to GIMP Release soon. I would try to find some time to
 help design the solution and I suspect a few others also from my workplace
 could help with some ideas also.
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership:
 https://mail.gnome.org/mailman/listinfo/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
___
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] List of dependencies (versions and configuration options) for GIMP on Windows

[Jehan Pagès]

Hi,

On Mon, Sep 23, 2013 at 1:51 AM, Michael Henning
dra...@darkrefraction.com wrote:
 As much fun as I'm sure you're all having debugging this, I think I've
 seen this before. I already fixed this with my windows nightlies
 (actually, scl reported it, so I guess he forgot about that).

 There are two potential issues:
   1. fontconfig includes an absolute path to its config directory, so
 when you move the files to a windows system it cannot find them.

   2. The config files themselves are symlinks, which may cause them to
 not exist on windows, depending on how the files are packaged.

 The solutions:
   1. Modify etc/fonts/fonts.conf to remove the absolute path and
 replace it with a relative one (it should just say conf.d, not
 long/path/and/then/conf.d). I compile fontconfig with this patch:
 https://git.gnome.org/browse/gimp/tree/build/windows/jhbuild/patches/fontconfig-fix-config-dir.patch
 You can achieve the same effect by modifying the config files by hand.

   2. Ensure the files in etc/fonts/conf.d/ exist. If not, copy the
 files from share/fontconfig/conf.avail into that folder.

Sorry for the late reply. I wanted to test myself first to be sure it
fixed the issue.
And it does. I just tested on my master build. :-)
So that's indeed the problem and its solution.

 At the time I fixed this, Jernej's builds did not exhibit the problem
 because they used an older version of fontconfig. I did not report
 this upstream because it's a configuration issue, but now that I think
 about it, the defaults should perhaps be changed on windows (or maybe
 when cross compiling).

Yes I am not sure if upstream or else, but definitely somethings
should be done *somewhere*, otherwise we might have various new
developers to the team (or the same ones, forgetting it happened
already) scratching their head with this problem every 6 months. The
simple fact that the last Windows build is broken even though you had
this fixed from before this release is a sign there should be
something in place for this to not happen again. :-)

Thanks!

Jehan


 On Sun, Sep 22, 2013 at 9:09 AM, Jehan Pagès jehan.marmott...@gmail.com 
 wrote:
 Hi,

 On Mon, Sep 23, 2013 at 12:49 AM, Sven Claussner scl.gp...@gmail.com wrote:
 On  22.09.2013 at 12:32 P.M., Jehan Pagès wrote:

 Thanks Sven, but that does not say what versions are used on GIMP
 2.8.4, official build, which was my question. :-)


 Sorry for being a bit terse, I'm in a rush ;-)

 You can find the official 2.8.4 build at

 http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28stable%20release%29/GIMP%202.8.4/

 Running GIMP with the -v or --version parameter shows the versions
 of the used libraries.


 Oh thanks, I did not know this one! Jernej actually already sent me an
 archive with the dependency tree of his build. I was planning to check
 the .pc files. Fortunately I did not start. And your solution will be
 easier *and* more accurate. :-)

 You can also find the 2.8.4 sources at the Web-Git site:
 https://git.gnome.org/browse/gimp

 Yes the source, I already have them, no problem. :-)
 Thanks again.

 Jehan

 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
___
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] List of dependencies (versions and configuration options) for GIMP on Windows

[Jehan Pagès]

Hi,

On Sun, Sep 22, 2013 at 9:23 PM, Jernej Simončič jer...@ena.si wrote:
 On Sunday, September 22, 2013, 10:16:11, Jehan Pagès wrote:

 Anyway the user says this was working fine on GIMP 2.8.4, but not on
 GIMP 2.8.6. So I compiled GIMP master, GIMP 2.8.6, 2.8.4 and even
 older versions. I also tried older versions of pango, freetype, etc.
 Well I never was able to have this work on Windows.
 Would you mind telling me exactly the list of dependencies included in
 your builds, their versions and the configure options?

 Uhh, that's a bit hard - I only build GIMP myself, and use binaries
 from OpenSuSE build service
 (http://download.opensuse.org/repositories/windows:/mingw:/) for all
 dependencies (which I normally update before each build).

 I've given up trying to manage dependencies myself a long time ago. I
 use the following two scripts to get them automatically:
 http://eternallybored.org/misc/gimp/grab-stuff.sh
 https://github.com/mkbosmans/download-mingw-rpm

Ow. That's also what I do. :-/ But since the OpenSuSe repo is
obviously updated regularly, it does not tell us what version was used
back then.
So you have no good way to tell what version of the libraries you used
at the time when you compiled GIMP 2.8.4?

Jehan

  Jernej Simončič  http://eternallybored.org/ 

 Those who live closest arrive last.
-- Mesta's Law of Parties

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] List of dependencies (versions and configuration options) for GIMP on Windows

[Jehan Pagès]

Hello,

On Sun, Sep 22, 2013 at 10:21 PM, Sven Claussner scl.gp...@gmail.com wrote:
 On  22.09.2013 at 10:16 A.M., Jehan Pagès wrote:

 Would you mind telling me exactly the list of dependencies included in
 your builds, their versions and the configure options?


 Hi Jehan,

 the dependencies can be found in configure.ac.

Thanks Sven, but that does not say what versions are used on GIMP
2.8.4, official build, which was my question. :-)

Jehan

 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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Crowdfunding Proposal for Symmetry/Mirror Painting in GIMP

[Jehan Pagès]

Hello,

Lately several people have asked why we won't do crowdfunding for
GIMP. The general position of GIMP developers towards this proposition
is that the core developers usually have day jobs, thus won't raise
money this way.
Well I am one of them and I don't have a day job right now, thus I
have decided to give it a try.

During the Libre Graphics Meeting in Madrid, the painter who was with
me tried the mirror mode during Krita workshop. And I thought it would
be a nice addition to the GIMP. Apparently I am not alone because I
see regularly messages asking for it.

So I started a test implementation to see how it would go. And it
works well. See the demo: http://youtu.be/osSiETyae5c

But now if I want it in GIMP, this is where it will really take time,
to make a nice and clean implementation and a well-thought internal
design.  So I start a crowdfunding initiative.
Have a look there with all the explanation:
http://girinstud.io/news/2013/09/crowdfunding-proposal-for-symmetrymirror-painting-in-gimp/

And if you like it, please fund me and spread the word:
http://funding.openinitiative.com/funding/1578/
Thanks!

Jehan
___
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] Any interested collaborators?

[Jehan Pagès]

Hi,


On Mon, Sep 16, 2013 at 5:58 PM, Srihari Sriraman tec...@visishta.net wrote:
 http://sriharisriraman.in/blog/2013/09/15/gimp-tito/

that looks indeed like a very nice addition. There is a similar
feature in blender too: you hit Enter, and search through actions.
When you know what you want and where to find it (shortcut, menu,
etc.), this kind of menu is not the most efficient; but when you are
not sure, this is a great way to discover a software features through
keywords.
And if it can be made contextual too (depending on the position of the
pointer, or if you have selections, etc.), that would be also cool. In
other words, I like it. I will have a look, hopefully in the next few
days.

That would be nice to have a feature request on the GIMP bugtracker
though (with a copy paste of the main explanation and a link to this
same web page, it should be enough). This way, I can keep an eye on
this and not forget. Would you mind making one?
This is only because if everyone who had a good feature was to use
only one's own tool, it would be impossible to keep track of all of
them. This is better to always come back to the official tracker as
main point. I hope you understand.

Thanks and nice one!

Jehan

 --
 Srihari Sriraman -- ⌀ -- nilenso.com
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Any interested collaborators?

[Jehan Pagès]

Hi,

On Tue, Sep 17, 2013 at 5:09 AM, Srihari Sriraman srih...@visishta.net wrote:
 would be nice to have a feature request on the GIMP bugtracker though


 I've done this here: https://bugzilla.gnome.org/show_bug.cgi?id=708174
 I'm not sure if this is sufficient. Let me know if I need to change
 anything.

That's good. :-)

Jehan



 On Mon, Sep 16, 2013 at 10:01 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,


 On Mon, Sep 16, 2013 at 5:58 PM, Srihari Sriraman tec...@visishta.net
 wrote:
  http://sriharisriraman.in/blog/2013/09/15/gimp-tito/

 that looks indeed like a very nice addition. There is a similar
 feature in blender too: you hit Enter, and search through actions.
 When you know what you want and where to find it (shortcut, menu,
 etc.), this kind of menu is not the most efficient; but when you are
 not sure, this is a great way to discover a software features through
 keywords.
 And if it can be made contextual too (depending on the position of the
 pointer, or if you have selections, etc.), that would be also cool. In
 other words, I like it. I will have a look, hopefully in the next few
 days.

 That would be nice to have a feature request on the GIMP bugtracker
 though (with a copy paste of the main explanation and a link to this
 same web page, it should be enough). This way, I can keep an eye on
 this and not forget. Would you mind making one?
 This is only because if everyone who had a good feature was to use
 only one's own tool, it would be impossible to keep track of all of
 them. This is better to always come back to the official tracker as
 main point. I hope you understand.

 Thanks and nice one!

 Jehan

  --
  Srihari Sriraman -- ⌀ -- nilenso.com
  ___
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership:
  https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Any interested collaborators?

[Jehan Pagès]

Hi Kevin,

On Tue, Sep 17, 2013 at 8:57 AM, Kevin Cozens ke...@ve3syb.ca wrote:
 On 13-09-16 12:31 PM, Jehan Pagès wrote:

 On Mon, Sep 16, 2013 at 5:58 PM, Srihari Sriraman tec...@visishta.net
 wrote:

 http://sriharisriraman.in/blog/2013/09/15/gimp-tito/


 The email would have been better if you stated what you wanted people to
 collaborate on instead of just giving a one line URL. A message like that
 looks a bit like SPAM.

I agree with you on that one. He could have done a better presentation by email.

 That would be nice to have a feature request on the GIMP bugtracker


 The GIMP developers have stated in the past the feature requests should be
 discussed on the mailing list before being added to the bug tracking system.
 Has the project in mind already been discussed on the developer list?

The linked page states that the feature has been discussed on IRC and
Mitch (maintainer of GIMP) already gave his green light (of course it
could be a lie, but I think such a huge one would be spotted sooner or
later). And me, as another (minor) GIMP developer, asked him
consequently to open a feature request. So I think that is enough for
this to happen. :-)

Jehan

 --
 Cheers!

 Kevin.

 http://www.ve3syb.ca/   |Nerds make the shiny things that distract
 Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
 | powerful!
 #include disclaimer/favourite | --Chris Hardwick

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] refactor palette loading code

[Jehan Pagès]

Hi,

On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal w...@penguintechs.org wrote:
 On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
 dra...@darkrefraction.com wrote:
  As a side note for the future, the fastest way to get a patch reviewed
  is normally if you post it to a pastebin and bother people on irc.

 For my own, I would prefer a git format-patch like this, but on a
 feature request/bug report on bugzilla. That's easy to patch a branch
 and to remove after. And also we keep track of any discussion or
 updated patch about a feature/fix. For instance go find this email
 thread in one year in the mailing history.


 Even for small refactorings like this one? I would certainly understand that
 for a feature add or a major refactor, but it seems like a lot of overhead
 for a pretty small refactor like this one. However, I am willing to do
 whatever you folks want since I just wanna help the project. However, please
 keep in mind that I have very little time to commit to this kind of work.

Well there are no strict rules, I guess, likely because the team is
small. I guess the real rule is to do so that others are not annoyed
by the form your patch (so that they will actually check it, and not
delay it to forever). Which means that if the other developers are ok
with a git bundle for instance (I did not even know what it is, I had
to look it up), or by adding your repo as a remote, well that's all
good. :-)

I am myself flexible and adapt to various team logics. But by
experience, I know some others of the core GIMP team want git
format-patch. When I made my first patches (I am myself likely the
most recent of the core developers), I also set up a public git repo
for others to fetch. Well I was told my patches would more likely be
reviewed if I provided patch files instead. And now I got used to it,
so I work also easily with these. That's not more time-consuming.
With a patch formatted with `git format-patch`, you can just git
apply it, and done! So easy to review (and also to commit if the
patch looks good with with git am, nothing to do).

I believe that at the opposite, for small patches, it is much easier
to provide patch files than maintain a public repo. For huge features
which require many commits over weeks, yeah there probably a public
branch is worth it. :-)

Jehan

  P.S. I don't see the patch on that last email. Are you sure you attached
  it?

 I see it but I was also a direct recipient. I guess that the list
 cleans emails out from any attached file.
 Could we have conditional filters? Like any text file with a .patch
 or .diff extension should not be filtered out.


 You should also allow git bundle files, which are a way to pass around git
 commits. I have attached one to this mail that includes the second iteration
 of my change. I guess only direct receivers of the email will receive it.

 wt
___
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-developer-list Digest, Vol 24, Issue 20

[Jehan Pagès]

Hi,

On Mon, Sep 16, 2013 at 11:07 AM, Paka ptilopt...@gmail.com wrote:
 * Thomas W twhitmore...@gmail.com [09-15-13 18:51]:
 Hi Marc, list members,

 Yes, I encounter awkwardness with the Save dialog  autocomplete
 triggering. You will also note that 'autocomplete' triggering blocks Enter
 from actually saving..  it also blocks Alt-S (or whatever Windows shortcut)
 from working.

 I'm not a big fan of autocomplete for Save -- if I wanted a similar name
 to an existing file, I'd expect to select the existing file in the list 
 change the name in the edit field. Since autocomplete here interferes
 strongly with the expected/standard UI, I'd consider the best usability to
 remove it entirely.

For the usability problem about should we autocomplete the save
dialog?, I find your saying interesting. Indeed in a
non-destructive point of view, I don't think autocomplete is such a
great idea for the save dialog, because in most cases, you don't want
to overwrite an existing file, but create a new name (and in the cases
you do want to overwrite, it is better to have the user write it down
or select it by mouse, so that we prevent too fast enter-enter-damn
it was the wrong name! consequences).
Does it make sense to others?

Unfortunately I think we may not have a say in it. I had a fast look
at GTK file chooser dialog API and did not see a function to disable
autocompletion. I may have to check further in GTK code. I don't think
we can add new features in gtk2, but maybe this can be added to gtk3
(then use when we get out GIMP 3, but it means it won't be available
for a bit of course). Anyway if possible, I'd say there should be
intermediate autocompletion types. Like autocomplete folders, but not
file names (so we still help users to choose a folder, but don't
direct them to existing file name for saving).
I'd say this is an interesting feature request. Does anyone agree?

 https://bugzilla.gnome.org/show_bug.cgi?id=698481

 Failing that, autocomplete should be reworked so as not to block the
 dialog's main keybindings. (Perhaps this would be useful for the 'Open'
 dialog.)

 Marc, you'd be welcome to add you comment in Bugzilla  hopefully vote
 usability issues a little higher priority. Other people notice this issue?


 I don't appear to have the problem on linux.  Perhaps it is a problem
 related to windows.

I don't think I have this problem either on Linux. I may test on my
Windows VM some day later.

Jehan
___
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-developer-list Digest, Vol 24, Issue 20

[Jehan Pagès]

Hi,

On Mon, Sep 16, 2013 at 2:57 PM, Christopher Curtis ccurt...@gmail.com wrote:
 On Sun, Sep 15, 2013 at 10:38 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

  I don't appear to have the problem on linux.  Perhaps it is a problem
  related to windows.

 I don't think I have this problem either on Linux. I may test on my
 Windows VM some day later.


 Here's how to reproduce it on Linux:

 Go to File-Open (or File-Export, etc.)
 Navigate to any directory using the folders on the left.
 Double click to select any folder that looks like a good place to open/save.
 Type something.
 Note the filename, while highlighted, never changes
 Note a mysterious box in the lower right collecting your keystrokes

 Version: GIMP 2.8.4 as shipped by Ubuntu.


well I have the mysterious box collecting [my] keystroke (also using
GIMP 2.8.4 as shipped by Mint, hence Ubuntu). It just looks to me like
a feature for being able to select a file without having the text
field active. And it does not block Enter for saving (which was the
original bug reported in the email as I understand it).
So I don't see any bug there.

But I still agree that this is probably not the best behavior for the
save dialog, and maybe even the export one. But for open, it
looks acceptable (though certainly there is a better way, of course.
Just saying I see no obvious usability problem or bug here, as
reported in the email).

Jehan


 Regards,
 Chris

___
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-developer-list Digest, Vol 24, Issue 20

[Jehan Pagès]

Hi,

On Mon, Sep 16, 2013 at 3:53 PM, Christopher Curtis ccurt...@gmail.com wrote:
 On Sun, Sep 15, 2013 at 11:21 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 well I have the mysterious box collecting [my] keystroke (also using
 GIMP 2.8.4 as shipped by Mint, hence Ubuntu). It just looks to me like
 a feature for being able to select a file without having the text
 field active. And it does not block Enter for saving (which was the
 original bug reported in the email as I understand it).
 So I don't see any bug there.


 Well, I haven't been following the thread closely but I don't know what you
 expect it to mean that something would block Enter.


Well... that's part of the message I am answering to, and
consequently, the one you answer to as well.
It says it blocks enter, and I say it does not at least on my machine.

 When in this mode, if you type and hit enter, the box goes away and nothing
 appears to happen. It isn't clear that the box is even there because it's
 not in the visual field. It appears that nothing happens, including enter.
 After hitting enter and trying to type again, the box reappears. Unless you
 pay close attention what is happening this is both very non-obvious and
 frustrating.

 I don't understand the bug's comment because I've never tried to use Alt-S
 or Alt-E in that dialog. I suspect the bug report is simply poorly phrased
 out of frustration, which I can completely relate to.

Yes for these other shortcuts, I am not even sure that these are
supposed to work from the start. Maybe these are common shortcut in
save dialogs in Windows program? I can't say.

 How is this popup search even useful when there's already search built in to
 the file name input? I would agree the popup should be removed/disabled.
 Arrow up/down work in it but Page up/down doesn't. Arrow up/down,
 left/right, and Page up/down all work (mostly) reasonably when used from the
 file name input. Worst of all, if you select a file from the multiple choice
 file name input and then arrow up/down, you're in the file chooser portion
 and typing uses the popup search instead of the file name search you just
 came from.

 Personally, I hit this frequently and think this behavior is an
 extraordinarily frustrating usability disaster.

Yes probably the file selection dialog can be improved. Do you know if
this also happens in GTK+3 programs? If so, a feature request with
relevant counter propositions of how to improve this for GTK+3 may be
worth it (if not already existing, that's possible and should be
searched first).

Because this is not a GIMP thing and there is not so much we can do
about it (of course we could make a custom widget, but well, the whole
point of separating GTK+ from GIMP was to share common widgets).

Jehan

 Chris
___
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] Nightly Build of GIMP

[Jehan Pagès]

Hi,

thanks, I'll try to recompile cairo with these options and see if I
can reproduce the crash.

Note that the crash is fixed by just changing the cairo and libpng dll
(initially I had to change libpng because I tested with older
versions, but now I could try only by changing cairo indeed), so I
don't think that pixman may be the cause. But of course you may try.
There may be some unexpected side-effect; we never know.
Anyway yes let's continue on the tracker from now on!

Jehan


On Thu, Sep 12, 2013 at 11:31 AM, Michael Henning
dra...@darkrefraction.com wrote:
 Jehan:
 These are my nightly builds. I build all of gimp's dependencies every
 night from source. Right now I use cairo 1.12.14, and libpng 1.6.3.
 All of the build options can be found around here:
 https://git.gnome.org/browse/gimp/tree/build/windows/jhbuild/build.jhbuildrc#n133

 This definitely sounds more like a cairo problem than a libpng
 problem. I just realized that there's a minor upgrade of pixman
 available (to 0.30.2), so I'll pull that in tonight because it might
 have a bugfix.

 I'm now cc'd on the bugreport you mentioned. We can continue this
 discussion there.

   -- drawoc

 On Wed, Sep 11, 2013 at 12:55 AM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:
 Hello people!

 Who takes care of the Nightly dev builds of GIMP here:
 http://nightly.darkrefraction.com/gimp/ ?

 I see we link this page on the official download page, so I guess
 that's someone from the team.
 I'd like to know what versions of libpng and cairo are used for these
 builds. Are these binaries taken from another project or self-built?
 Which exact version? With which build options?

 A user reported consistent crashes on Windows 7 32-bit, both for the
 master and gimp-2-8 nightbuilds, on simple resize/move events (Bug
 707653 ). On Windows 7 64-bit running these 32-bit binaries, I could
 reproduce very bad drawing bugs with the same binaries (no crash, but
 the user crash happens on expose events in his traces, so I think
 that's the same problem).

 But I could not reproduce this with my own Windows builds, both for
 master and gimp-2-8. After some tests, I see that the problem comes
 from cairo and/or libpng (basically I can take my own libpng15-15.dll
 and copy over libcairo-2.dll to the nightbuild prefix, and it would
 work).

 But I could not reproduce by recompiling myself libpng-1.6.3 and
 cairo-1.12.14. So I am wondering if the problem does not simply come
 from somehow broken dll in the nightbuilds. Thus I'd like to know how
 these have been build, which version, etc.
 Thanks.

 Jehan
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] refactor palette loading code

[Jehan Pagès]

Hi,

On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
dra...@darkrefraction.com wrote:
 I made a few minor nitpicks on your commit on github. If you would fix
 those points, I'll commit your code to master.

ok cool, someone reviewed the patch before me. :-D

 As a side note for the future, the fastest way to get a patch reviewed
 is normally if you post it to a pastebin and bother people on irc.

For my own, I would prefer a git format-patch like this, but on a
feature request/bug report on bugzilla. That's easy to patch a branch
and to remove after. And also we keep track of any discussion or
updated patch about a feature/fix. For instance go find this email
thread in one year in the mailing history.

   -- drawoc

 P.S. I don't see the patch on that last email. Are you sure you attached it?

I see it but I was also a direct recipient. I guess that the list
cleans emails out from any attached file.
Could we have conditional filters? Like any text file with a .patch
or .diff extension should not be filtered out.

Jehan


 On Mon, Sep 9, 2013 at 3:27 AM, Warren Turkal w...@penguintechs.org wrote:
 Attached is the patch.

 wt


 On Sun, Sep 8, 2013 at 12:13 PM, Warren Turkal w...@penguintechs.org wrote:

 Hey,

 I will get the format-patch as soon as I can. However, if you want to do
 it the git way and get it sooner, you can always add my remote to your git
 with the following command:
 git remote add wt g...@github.com:wt/gimp.git

 Note that wt can be whatever alias you want, but my commands below
 assume you use wt as the remote alias.

 That url for the repo is available on the main page for the repo on that
 website after a single click. To find it from the commit page that I sent
 earlier (this link 
 herehttps://github.com/wt/gimp/commit/d1e8c4c8543b18c6f5d95f6ab6b3bbbf8f80778b),
 look near the top left. You can see it if you look toward the top left.
 You'll see something like PUBLIC wt/gimp. If you click on the gimp
 part, it will take you the repo main page 
 (herehttps://github.com/wt/gimp).
 Look on the right side of the page. You can get https, ssh, and a few other
 types of urls for the repo.

 Once you have my remote, you can fetch my repo objects with this commands:
 git fetch wt

 Then, you can do all the git operations you want. For example, here's how
 to get a log:
 git log wt/refactor_palette_loader

 If you want to merge in my commit, do the following while on your local
 working (maybe master) branch:
 git merge wt/refactor_palette_loader

 And if you find that you don't want my remote in your repo anymore, you
 can remove it. Make sure you don't have any branches tracking mine. One way
 deal with branches tracking mine is to just delete them. Then execute this
 command:
 git remote remove wt

 After doing that, you can also do the following if you to get rid of
 commits that were only in my repo:
 git prune

 wt


 On Sun, Sep 8, 2013 at 5:33 AM, Jehan Pagès 
 jehan.marmott...@gmail.comwrote:

 Hi,

 I searched a little in this web UI, but couldn't find: is there a way
 to generate a proper patch from this? Otherwise, could you generate
 one with git format-patch origin/master, run on your locale branch?
 Thanks.

 Jehan


 On Mon, Sep 9, 2013 at 12:20 AM, Warren Turkal w...@penguintechs.org
 wrote:
  BTW, I tested this with gpl, act, aco, pal, and css palette files. I
  couldn't find RIFF file. If anyone has one, would you mind emailing it
 to
  me so that I can try loading it?
 
  Thanks,
  wt
 
 
  On Sun, Sep 8, 2013 at 5:06 AM, Warren Turkal w...@penguintechs.org
 wrote:
 
  Hi again,
 
  Here's a link
 https://github.com/wt/gimp/commit/d1e8c4c8543b18c6f5d95f6ab6b3bbbf8f80778bto
 a commit containing a refactor of the palette loading code. I have moved
  the file open/close logic to common code. This change actually removes
 more
  code than it adds. Here's a interesting diffstat (without whitespace
 only
  changes):
 
  $ git diff --stat --color -w origin/master
   app/core/gimp.c   |   4 +-
   app/core/gimppalette-import.c |  37 +--
   app/core/gimppalette-load.c   | 148
  -
   app/core/gimppalette-load.h   |  12 +++-
   4 files changed, 85 insertions(+), 116 deletions(-)
 
  Any chance this could be pulled into the master? Do y'all have any
 other
  thoughts on this?
 
  Thanks,
  wt
 
  ___
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership:
 https://mail.gnome.org/mailman/listinfo/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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Nightly Build of GIMP

[Jehan Pagès]

Hello people!

Who takes care of the Nightly dev builds of GIMP here:
http://nightly.darkrefraction.com/gimp/ ?

I see we link this page on the official download page, so I guess
that's someone from the team.
I'd like to know what versions of libpng and cairo are used for these
builds. Are these binaries taken from another project or self-built?
Which exact version? With which build options?

A user reported consistent crashes on Windows 7 32-bit, both for the
master and gimp-2-8 nightbuilds, on simple resize/move events (Bug
707653 ). On Windows 7 64-bit running these 32-bit binaries, I could
reproduce very bad drawing bugs with the same binaries (no crash, but
the user crash happens on expose events in his traces, so I think
that's the same problem).

But I could not reproduce this with my own Windows builds, both for
master and gimp-2-8. After some tests, I see that the problem comes
from cairo and/or libpng (basically I can take my own libpng15-15.dll
and copy over libcairo-2.dll to the nightbuild prefix, and it would
work).

But I could not reproduce by recompiling myself libpng-1.6.3 and
cairo-1.12.14. So I am wondering if the problem does not simply come
from somehow broken dll in the nightbuilds. Thus I'd like to know how
these have been build, which version, etc.
Thanks.

Jehan
___
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] possible bug

[Jehan Pagès]

Hi,

On Fri, Sep 6, 2013 at 9:34 PM, Partha Bagchi parth...@gmail.com wrote:
 Please file a bugreport.

no need. It has been reported on IRC yesterday and already fixed in
the master branch by Mikachu:

commit a9eb0c5120487184a304286741f67181f152c0db
Author: Mikael Magnusson mika...@src.gnome.org
Date:   Thu Sep 5 13:20:03 2013 +0200

app: Fix a typo in an unused function

Found by wt on irc.

Have fun!

Jehan

 Thanks,
 Partha


 On Thu, Sep 5, 2013 at 11:33 PM, Warren Turkal w...@penguintechs.org wrote:

 Hi,

 I have found a possible bug
 in gimp/app/display/gimpdisplayshell-transform.c:285. The line is as
 follows:
 *rotated_coords = *rotated_coords

 Is it possible that it should be the following?
 *rotated_coords = *unrotated_coords

 Also, the documentation for the function containing this line and the next
 function appear to be wrong.

 Thanks,
 wt
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership:
 https://mail.gnome.org/mailman/listinfo/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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Fwd: Gimp quick brush editor idea.

[Jehan Pagès]

Oups forgot to add gimp-developer mailing list in Cc.


-- Forwarded message --
From: Jehan Pagès jehan.marmott...@gmail.com
Date: Fri, Sep 6, 2013 at 12:53 AM
Subject: Re: [Gimp-developer] Gimp quick brush editor idea.
To: Abraham Levi Mireles Alvarez abraham_al...@hotmail.com


Hi,

that looks like an interesting idea. Could you please make a feature
request on our tracker? Upload the image there too. It helps to
understand what you mean.

https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

Jehan


On Mon, Sep 2, 2013 at 12:06 PM, Abraham Levi Mireles Alvarez
abraham_al...@hotmail.com wrote:
 Hello everyone it's me aging from the one with the kickstarted idea. I hope 
 you guys are still considering it :) a protect recently reached.

 I am a painter and a big fan of gimp. However there is a feature I would like 
 to give you for your consideration that would be a complete time-saver for us 
 artists/painters and would make working on gimp easier. Right now it is a bit 
 complicated to quickly change the size and opacity of our brushes. While I am 
 aware of the shortcuts… I think it can be even better.

 There is a feature that many painting programs have and that would be ideal 
 for it as well.

 Basically having the ability to change the brush size (left and right) and 
 opacity (up and down)

 Thank you for your consideration

 Here it is a photo bucket pic if the attachment doesn't 
 workhttp://s276.photobucket.com/user/heroicmasterchief/media/GimpBrushEditorpng_zps37aef908.png.html

 by moving the mouse/stylus up and down while you are pressing a button 
 combination at the same time.



 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v suv...@users.sourceforge.net wrote:
 On 2013-07-28 07:32 +0100, Jehan Pagès wrote:
 yes I saw your message in the report too. Actually I was feeling this
 would work your crash around when I wrote this patch. But that is
 still not a fix. When you open the preferences and check the Interface
 tab, then the language list, this list is empty now, right?

 No, it lists all languages.

Hmmm... ok. So it lists them all of them, nicely displayed language
name [code] as usual?


 On 2013-07-28 07:31 +0100, Partha Bagchi wrote:
 Are you using Macport? I don't use Macport and build all my
 dependencies from scratch.

 Yes, I use MacPorts for the dependencies.

What is MacPorts? Is it like a package manager for Mac?

Also I see you run the command gimp-git.sh quartz. Is there
something particular you do in this script?
Also why the quartz? Can you like switch backend at startup or
something (not even at compilation?)? Like between X11 and quartz? How
does this work under OSX, I heard there is X11 too, so are there
layers running on each other? Concurrent systems and you can use one
or the other?


Jehan


 [ fullquote below trimmed to avoid moderation ]


 On Sun, Jul 28, 2013 at 5:19 PM, su_v suv...@users.sourceforge.net wrote:
 On my system (10.7.5), GIMP launches ok, but crashes when opening
 the preferences. See stack trace in
 https://bugzilla.gnome.org/show_bug.cgi?id=704592#c6

 With your patch applied (and no other local changes), GIMP still
 launches ok, and now no longer crashes when opening the preferences
 dialog (see attached log).


 On 2013-07-28 05:47 +0100, Jehan Pagès wrote:
 Hey Partha, su_v,

 could you test the following patch:
 - copy it in your GIMP directory;
 - apply it with this command from the GIMP directory:
 patch -p0  osx_crash.diff
 - compile and try again.

 I believe it would not fix your crash, because I did not change the
 calls where your traces say it happens. Problem is that it apparently
 crashes at strchr() but there are 5 of them in this function. Looking
 at what seems to be the code in MacOSX of strchr(), looks like it may
 be when the string is NULL, but in my code, I don't see anywhere where
 this is supposed to be possible.
 So unless you can run a debugger to know which exact strchr() line it
 happens at, I added some debug output in the code. Just copy paste
 anything which may be outputted before crash.
 You will most likely have a whole bunch of lines on screen because I
 want to cover as much ground as possible, so you can run like this:
 $ ./gimp-2.9 --verbose output.txt

 Then send me the output.txt after the crash occurs.
 Thanks.

 Jehan




___
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 git on Mac Segfault

[Jehan Pagès]

Hi,

On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi parth...@gmail.com wrote:
 As of night, the crash still occurred. Jehan, is there a new patch?

Sorry Partha, I went out. I am kind of a particular timezone (New Zealand).
I just realized I completely misused a macro. That may have been the
issue, even though it did not show on my platform.
Could you please try the attached patch please?
Of course remove the previous one first (git checkout -- . to clean
out your git repository, so that with a git status, it should list
no modified files).
Thanks.

Jehan

 Thanks,
 Partha


 On Sun, Jul 28, 2013 at 2:57 AM, su_v suv...@users.sourceforge.net wrote:

 On 2013-07-28 08:03 +0100, Jehan Pagès wrote:
  Hi,
 
  On Sun, Jul 28, 2013 at 5:42 PM, su_v suv...@users.sourceforge.net
  wrote:
  On 2013-07-28 07:32 +0100, Jehan Pagès wrote:
  yes I saw your message in the report too. Actually I was feeling this
  would work your crash around when I wrote this patch. But that is
  still not a fix. When you open the preferences and check the Interface
  tab, then the language list, this list is empty now, right?
 
  No, it lists all languages.
 
  Hmmm... ok. So it lists them all of them, nicely displayed language
  name [code] as usual?

 Screenshot here

 https://www.dropbox.com/s/6haa2tq0vow3u29/gimp-013c9d3-patched-prefs-languages-1.png

 
  On 2013-07-28 07:31 +0100, Partha Bagchi wrote:
  Are you using Macport? I don't use Macport and build all my
  dependencies from scratch.
 
  Yes, I use MacPorts for the dependencies.
 
  What is MacPorts? Is it like a package manager for Mac?

 Yes: http://www.macports.org/

  Also I see you run the command gimp-git.sh quartz. Is there
  something particular you do in this script?

 Since I install into a custom prefix, it mainly sets $PATH accordingly.
 The script was originally based on the launch script described here:
 http://lightningismyname.blogspot.ch/p/compiling-gimp.html

 There is no difference whether I launch the gimp-2.9 binary directly, or
 with the script: same result (crash unpatched, no crash with patch).

  Also why the quartz? Can you like switch backend at startup or
  something (not even at compilation?)? Like between X11 and quartz? How
  does this work under OSX, I heard there is X11 too, so are there
  layers running on each other? Concurrent systems and you can use one
  or the other?

 I have two MacPorts trees installed into custom prefixes, one with GTK+
 compiled using the Quartz backend (native backend for OS X), one with
 the X11 backend (legacy backend on OS X: all GTK+ apps require to run
 under X11/XQuartz).
 For GIMP I use two local git clones - one for building with Quartz-based
 dependencies, one for building with X11-based dependencies. They both
 are configured to install into different prefixes.
 The launch script just sets $PATH for gimp-2.9 accordingly, depending on
 the command line argument given (quartz, x11).

 AFAICT the backend is not relevant for this issue: the crash is the same
 with unpatched builds, independent of the GTK+ backend used. I only
 built GIMP with the X11 backend (and integrated it as command line
 option in the script) because I wanted to compare the redraw performance
 between the two backends [1].

 Note: Above build setup has a lot of rendundant packages installed,
 because with GTK2 one cannot have multiple backends compiled in. I
 maintain it for building  testing Inkscape, and thus can easily reuse
 it to test local builds of GIMP 2.8  GIMP 2.9 (git master).


 [1] see footnote in
 https://bugzilla.gnome.org/show_bug.cgi?id=703845#c13


  On Sun, Jul 28, 2013 at 5:19 PM, su_v suv...@users.sourceforge.net
  wrote:
  On my system (10.7.5), GIMP launches ok, but crashes when opening
  the preferences. See stack trace in
  https://bugzilla.gnome.org/show_bug.cgi?id=704592#c6
 
  With your patch applied (and no other local changes), GIMP still
  launches ok, and now no longer crashes when opening the preferences
  dialog (see attached log).
 
 
  On 2013-07-28 05:47 +0100, Jehan Pagès wrote:
  Hey Partha, su_v,
 
  could you test the following patch:
  - copy it in your GIMP directory;
  - apply it with this command from the GIMP directory:
  patch -p0  osx_crash.diff
  - compile and try again.
 
  I believe it would not fix your crash, because I did not change the
  calls where your traces say it happens. Problem is that it
  apparently
  crashes at strchr() but there are 5 of them in this function.
  Looking
  at what seems to be the code in MacOSX of strchr(), looks like it
  may
  be when the string is NULL, but in my code, I don't see anywhere
  where
  this is supposed to be possible.
  So unless you can run a debugger to know which exact strchr() line
  it
  happens at, I added some debug output in the code. Just copy paste
  anything which may be outputted before crash.
  You will most likely have a whole bunch of lines on screen because I
  want to cover as much ground as possible, so you can run

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hi,

On Mon, Jul 29, 2013 at 1:28 AM, Partha Bagchi parth...@gmail.com wrote:
 Sorry Jehan, didn't mean to bug you. :) Didn't realize you are in NZ.

No prob. I prefer these kind of annoying crashes gone as soon as
possible myself! ;-)

 Yes, all is good now. The crash is history!!

Cool! I'll push this then. :-)

Jehan


 Thanks so much!
 Partha



 On Sun, Jul 28, 2013 at 8:07 AM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,

 On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi parth...@gmail.com
 wrote:
  As of night, the crash still occurred. Jehan, is there a new patch?

 Sorry Partha, I went out. I am kind of a particular timezone (New
 Zealand).
 I just realized I completely misused a macro. That may have been the
 issue, even though it did not show on my platform.
 Could you please try the attached patch please?
 Of course remove the previous one first (git checkout -- . to clean
 out your git repository, so that with a git status, it should list
 no modified files).
 Thanks.

 Jehan

  Thanks,
  Partha
 
 
  On Sun, Jul 28, 2013 at 2:57 AM, su_v suv...@users.sourceforge.net
  wrote:
 
  On 2013-07-28 08:03 +0100, Jehan Pagès wrote:
   Hi,
  
   On Sun, Jul 28, 2013 at 5:42 PM, su_v suv...@users.sourceforge.net
   wrote:
   On 2013-07-28 07:32 +0100, Jehan Pagès wrote:
   yes I saw your message in the report too. Actually I was feeling
   this
   would work your crash around when I wrote this patch. But that is
   still not a fix. When you open the preferences and check the
   Interface
   tab, then the language list, this list is empty now, right?
  
   No, it lists all languages.
  
   Hmmm... ok. So it lists them all of them, nicely displayed language
   name [code] as usual?
 
  Screenshot here
 
 
  https://www.dropbox.com/s/6haa2tq0vow3u29/gimp-013c9d3-patched-prefs-languages-1.png
 
  
   On 2013-07-28 07:31 +0100, Partha Bagchi wrote:
   Are you using Macport? I don't use Macport and build all my
   dependencies from scratch.
  
   Yes, I use MacPorts for the dependencies.
  
   What is MacPorts? Is it like a package manager for Mac?
 
  Yes: http://www.macports.org/
 
   Also I see you run the command gimp-git.sh quartz. Is there
   something particular you do in this script?
 
  Since I install into a custom prefix, it mainly sets $PATH accordingly.
  The script was originally based on the launch script described here:
  http://lightningismyname.blogspot.ch/p/compiling-gimp.html
 
  There is no difference whether I launch the gimp-2.9 binary directly,
  or
  with the script: same result (crash unpatched, no crash with patch).
 
   Also why the quartz? Can you like switch backend at startup or
   something (not even at compilation?)? Like between X11 and quartz?
   How
   does this work under OSX, I heard there is X11 too, so are there
   layers running on each other? Concurrent systems and you can use one
   or the other?
 
  I have two MacPorts trees installed into custom prefixes, one with GTK+
  compiled using the Quartz backend (native backend for OS X), one with
  the X11 backend (legacy backend on OS X: all GTK+ apps require to run
  under X11/XQuartz).
  For GIMP I use two local git clones - one for building with
  Quartz-based
  dependencies, one for building with X11-based dependencies. They both
  are configured to install into different prefixes.
  The launch script just sets $PATH for gimp-2.9 accordingly, depending
  on
  the command line argument given (quartz, x11).
 
  AFAICT the backend is not relevant for this issue: the crash is the
  same
  with unpatched builds, independent of the GTK+ backend used. I only
  built GIMP with the X11 backend (and integrated it as command line
  option in the script) because I wanted to compare the redraw
  performance
  between the two backends [1].
 
  Note: Above build setup has a lot of rendundant packages installed,
  because with GTK2 one cannot have multiple backends compiled in. I
  maintain it for building  testing Inkscape, and thus can easily reuse
  it to test local builds of GIMP 2.8  GIMP 2.9 (git master).
 
 
  [1] see footnote in
  https://bugzilla.gnome.org/show_bug.cgi?id=703845#c13
 
 
   On Sun, Jul 28, 2013 at 5:19 PM, su_v
   suv...@users.sourceforge.net
   wrote:
   On my system (10.7.5), GIMP launches ok, but crashes when opening
   the preferences. See stack trace in
   https://bugzilla.gnome.org/show_bug.cgi?id=704592#c6
  
   With your patch applied (and no other local changes), GIMP still
   launches ok, and now no longer crashes when opening the
   preferences
   dialog (see attached log).
  
  
   On 2013-07-28 05:47 +0100, Jehan Pagès wrote:
   Hey Partha, su_v,
  
   could you test the following patch:
   - copy it in your GIMP directory;
   - apply it with this command from the GIMP directory:
   patch -p0  osx_crash.diff
   - compile and try again.
  
   I believe it would not fix your crash, because I did not change
   the
   calls where your traces say it happens. Problem is that it
   apparently

Re: [Gimp-developer] Fwd: need to contact the developers of GIMP.

[Jehan Pagès]

Hi,

On Mon, Jul 29, 2013 at 8:08 AM, Elle Stone l.elle.st...@gmail.com wrote:
 I just looked at the questionaires. The questions imply/offer a narrow
 business-oriented view on open source projects, it seems to me.

I agree. There are very few questions, and in the few, I don't
understand some (one in particular has, I think, broken English; or
maybe I am broken. :p), and the others are vague (or rather too
accurate, like how many projects did I participated to? How do I
remember this? Do single patches sent over a mailing list/bug tracker
and forgotten count or does she mean lasting active participation
only? etc.) or hard to answer in just a few words (if we consider the
size of the entry answer, the author apparently don't want long
answers). In any case, I really wonder what kind of thesis can really
emerge from answers to this questionnaries.
By the way I also received this directly on my email. And I also
recommended to post this to the mailing list (it has been sent to the
ml afterwards, if not mistaken).

 I recall one person saying in a recent post, possibly on the Gimp
 users list, that he contributed code because he liked to code, he
 wanted to make something in particular about Gimp work better, and he
 did it for his own personal satisfaction. That was exactly my own
 reasons for working on the lcms.c plugin.

 Do the questionaires connect with real motivations? Or some of the
 real, core motivations just plain missing from the forms? Why do you
 all really do it (other than possibly sainthood or insanity of
 course)?

For me, insanity! So I guess it means you don't want to hear from my
core motivations anymore. hmpf!
;-)

Jehan


 Elle
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hey Partha, su_v,

could you test the following patch:
- copy it in your GIMP directory;
- apply it with this command from the GIMP directory:
patch -p0  osx_crash.diff
- compile and try again.

I believe it would not fix your crash, because I did not change the
calls where your traces say it happens. Problem is that it apparently
crashes at strchr() but there are 5 of them in this function. Looking
at what seems to be the code in MacOSX of strchr(), looks like it may
be when the string is NULL, but in my code, I don't see anywhere where
this is supposed to be possible.
So unless you can run a debugger to know which exact strchr() line it
happens at, I added some debug output in the code. Just copy paste
anything which may be outputted before crash.
You will most likely have a whole bunch of lines on screen because I
want to cover as much ground as possible, so you can run like this:
$ ./gimp-2.9 --verbose output.txt

Then send me the output.txt after the crash occurs.
Thanks.

Jehan


On Sun, Jul 28, 2013 at 1:47 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Argh! I should nearly have a Mac just to test code there! uhuh
 Let me have a look. :-)

 Jehan

 On Sun, Jul 28, 2013 at 10:39 AM, Partha Bagchi parth...@gmail.com wrote:
 Should have mentioned the segfault is related to
 gimp_language_store_parser_init ()
 __
 ./gimp-2.9 --verbose
 Cannot spawn a message bus without a machine-id: Unable to load
 /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file
 '/var/lib/dbus/machine-id': No such file or directory
 This is a development version of GIMP.  Debug messages may appear here.

 INIT: gimp_load_config
 Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc'
 Parsing
 '/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc'
 Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc'
 ./gimp-2.9: fatal error: Segmentation fault: 11
 ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or [P]roceed: S
 #0  0x7fff8b970698 in __wait4 ()
 #1  0x000101868353 in g_on_error_stack_trace ()
 #2  0x0001018687f2 in g_on_error_query ()
 #3  0x0001dee4 in gimp_eek ()
 #4  0x0001df58 in gimp_fatal_error ()
 #5  0x0001e7b6 in gimp_sigfatal_handler ()
 #6  signal handler called
 #7  0x7fff8cb0a60b in strchr ()
 #8  0x000100167614 in gimp_language_store_parser_init ()
 #9  0x000100012c75 in gui_init ()
 #10 0x0001d890 in app_run ()
 #11 0x0001fe24 in main ()
 __

 Thanks,
 Partha


 On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi parth...@gmail.com wrote:

 Jehan,

 Looks like the segfault is back?

 Thanks,
 Partha



 On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:

 Jehan,

 Thumbs up! All good now. It didn't crash and I was able to open images
 etc.

 Thanks again,
 Partha



 On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:

 Hey Partha,

 you can pull and test now. I made a simple commit where I only take
 care of the unset env variable issue. Hopefully this will fix the OSX
 crash. I'll handle the other issue I discovered about not being
 thread-safe later.
 Tell me how it goes. :-)

 Jehan

 On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:
  Partha,
 
  nothing pushed yet. I'll do this and send a message. :-)
 
  Jehan
 
  On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi parth...@gmail.com
  wrote:
  Jehan,
 
  Do you want me to go ahead test the current code or wait for you to
  add
  additional logic?
 
  Thanks!
  Partha
 
 
 
  On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès
  jehan.marmott...@gmail.com
  wrote:
 
  Hi,
 
  I searched a little more though, and it seems on BSDs, hence on OSX,
  indeed setenv with a NULL value could crash the program. The setenv
  in
  GNU libc on the other hand perfectly handles the case explicitly.
  So obviously when I see this kind of code (note I am not 100% sure
  this is the code for Darwin on Mountain Lion but I can't find a
  reference linking the libc numbers there and the Darwin version
  10.8,
  but I assume that should be a similar code):
 
 
  http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c
 
  Before any test on the value pointer, it dereferences it (which is
  undefined!), and read the content of the non-existing first
  character
  of the NULL string (which I assume would crash!):
 
  if (*value == '=') /* no `=' in value */
  ++value;
 
  I don't know what is the policy on BSD but I thought they were very
  keen on security, but this code does not look very sane to me.
  So yeah anyway that's a problem too in the end. I'll deal with it.
 
  Jehan
 
 
  On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi parth...@gmail.com
  wrote:
   Jehan,
  
   I will test it tomorrow. I

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Just to try into another direction: if you comment out the line:
parse_iso_codes (base_lang_list, NULL);
(line 173 in app/widgets/gimplanguagestore-parser.c)

Do you still have the crash? And if yes, the same trace?

Jehan

On Sun, Jul 28, 2013 at 4:22 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hmmm... NULL nowhere, no strange values, nothing. Did the trace still
 say it happened at strchr() inside gimp_language_store_parser_init ()?

 Jehan

 On Sun, Jul 28, 2013 at 4:16 PM, Partha Bagchi parth...@gmail.com wrote:
 Hi Jehan,

 Here is the output from the crash.

 Hope it's helpful. I don't see anything myself. :(

 Thanks!
 Partha




 On Sat, Jul 27, 2013 at 11:47 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hey Partha, su_v,

 could you test the following patch:
 - copy it in your GIMP directory;
 - apply it with this command from the GIMP directory:
 patch -p0  osx_crash.diff
 - compile and try again.

 I believe it would not fix your crash, because I did not change the
 calls where your traces say it happens. Problem is that it apparently
 crashes at strchr() but there are 5 of them in this function. Looking
 at what seems to be the code in MacOSX of strchr(), looks like it may
 be when the string is NULL, but in my code, I don't see anywhere where
 this is supposed to be possible.
 So unless you can run a debugger to know which exact strchr() line it
 happens at, I added some debug output in the code. Just copy paste
 anything which may be outputted before crash.
 You will most likely have a whole bunch of lines on screen because I
 want to cover as much ground as possible, so you can run like this:
 $ ./gimp-2.9 --verbose output.txt

 Then send me the output.txt after the crash occurs.
 Thanks.

 Jehan


 On Sun, Jul 28, 2013 at 1:47 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:
  Argh! I should nearly have a Mac just to test code there! uhuh
  Let me have a look. :-)
 
  Jehan
 
  On Sun, Jul 28, 2013 at 10:39 AM, Partha Bagchi parth...@gmail.com
  wrote:
  Should have mentioned the segfault is related to
  gimp_language_store_parser_init ()
 
  __
  ./gimp-2.9 --verbose
  Cannot spawn a message bus without a machine-id: Unable to load
  /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file
  '/var/lib/dbus/machine-id': No such file or directory
  This is a development version of GIMP.  Debug messages may appear here.
 
  INIT: gimp_load_config
  Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc'
  Parsing
 
  '/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc'
  Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc'
  ./gimp-2.9: fatal error: Segmentation fault: 11
  ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or
  [P]roceed: S
  #0  0x7fff8b970698 in __wait4 ()
  #1  0x000101868353 in g_on_error_stack_trace ()
  #2  0x0001018687f2 in g_on_error_query ()
  #3  0x0001dee4 in gimp_eek ()
  #4  0x0001df58 in gimp_fatal_error ()
  #5  0x0001e7b6 in gimp_sigfatal_handler ()
  #6  signal handler called
  #7  0x7fff8cb0a60b in strchr ()
  #8  0x000100167614 in gimp_language_store_parser_init ()
  #9  0x000100012c75 in gui_init ()
  #10 0x0001d890 in app_run ()
  #11 0x0001fe24 in main ()
 
  __
 
  Thanks,
  Partha
 
 
  On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi parth...@gmail.com
  wrote:
 
  Jehan,
 
  Looks like the segfault is back?
 
  Thanks,
  Partha
 
 
 
  On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com
  wrote:
 
  Jehan,
 
  Thumbs up! All good now. It didn't crash and I was able to open
  images
  etc.
 
  Thanks again,
  Partha
 
 
 
  On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès
  jehan.marmott...@gmail.com wrote:
 
  Hey Partha,
 
  you can pull and test now. I made a simple commit where I only take
  care of the unset env variable issue. Hopefully this will fix the
  OSX
  crash. I'll handle the other issue I discovered about not being
  thread-safe later.
  Tell me how it goes. :-)
 
  Jehan
 
  On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès
  jehan.marmott...@gmail.com wrote:
   Partha,
  
   nothing pushed yet. I'll do this and send a message. :-)
  
   Jehan
  
   On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi
   parth...@gmail.com
   wrote:
   Jehan,
  
   Do you want me to go ahead test the current code or wait for you
   to
   add
   additional logic?
  
   Thanks!
   Partha
  
  
  
   On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès
   jehan.marmott...@gmail.com
   wrote:
  
   Hi,
  
   I searched a little more though, and it seems on BSDs, hence on
   OSX,
   indeed setenv with a NULL value could crash the program. The
   setenv
   in
   GNU libc on the other hand perfectly handles the case
   explicitly.
   So obviously when I see this kind

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hi su_v,

yes I saw your message in the report too. Actually I was feeling this
would work your crash around when I wrote this patch. But that is
still not a fix. When you open the preferences and check the Interface
tab, then the language list, this list is empty now, right?

Jehan


On Sun, Jul 28, 2013 at 5:19 PM, su_v suv...@users.sourceforge.net wrote:
 On my system (10.7.5), GIMP launches ok, but crashes when opening
 the preferences. See stack trace in
 https://bugzilla.gnome.org/show_bug.cgi?id=704592#c6

 With your patch applied (and no other local changes), GIMP still
 launches ok, and now no longer crashes when opening the preferences
 dialog (see attached log).


 On 2013-07-28 05:47 +0100, Jehan Pagès wrote:
 Hey Partha, su_v,

 could you test the following patch:
 - copy it in your GIMP directory;
 - apply it with this command from the GIMP directory:
 patch -p0  osx_crash.diff
 - compile and try again.

 I believe it would not fix your crash, because I did not change the
 calls where your traces say it happens. Problem is that it apparently
 crashes at strchr() but there are 5 of them in this function. Looking
 at what seems to be the code in MacOSX of strchr(), looks like it may
 be when the string is NULL, but in my code, I don't see anywhere where
 this is supposed to be possible.
 So unless you can run a debugger to know which exact strchr() line it
 happens at, I added some debug output in the code. Just copy paste
 anything which may be outputted before crash.
 You will most likely have a whole bunch of lines on screen because I
 want to cover as much ground as possible, so you can run like this:
 $ ./gimp-2.9 --verbose output.txt

 Then send me the output.txt after the crash occurs.
 Thanks.

 Jehan


 On Sun, Jul 28, 2013 at 1:47 PM, Jehan Pagès jehan.marmott...@gmail.com 
 wrote:
 Argh! I should nearly have a Mac just to test code there! uhuh
 Let me have a look. :-)

 Jehan

 On Sun, Jul 28, 2013 at 10:39 AM, Partha Bagchi parth...@gmail.com wrote:
 Should have mentioned the segfault is related to
 gimp_language_store_parser_init ()
 __
 ./gimp-2.9 --verbose
 Cannot spawn a message bus without a machine-id: Unable to load
 /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file
 '/var/lib/dbus/machine-id': No such file or directory
 This is a development version of GIMP.  Debug messages may appear here.

 INIT: gimp_load_config
 Parsing '/Users/partha/Library/Application Support/GIMP/2.9/unitrc'
 Parsing
 '/Users/partha/projects/src/gimp/Gimp-2.9.app/Contents/Resources/etc/gimp/2.0/gimprc'
 Parsing '/Users/partha/Library/Application Support/GIMP/2.9/gimprc'
 ./gimp-2.9: fatal error: Segmentation fault: 11
 ./gimp-2.9 (pid:63964): [E]xit, [H]alt, show [S]tack trace or [P]roceed: S
 #0  0x7fff8b970698 in __wait4 ()
 #1  0x000101868353 in g_on_error_stack_trace ()
 #2  0x0001018687f2 in g_on_error_query ()
 #3  0x0001dee4 in gimp_eek ()
 #4  0x0001df58 in gimp_fatal_error ()
 #5  0x0001e7b6 in gimp_sigfatal_handler ()
 #6  signal handler called
 #7  0x7fff8cb0a60b in strchr ()
 #8  0x000100167614 in gimp_language_store_parser_init ()
 #9  0x000100012c75 in gui_init ()
 #10 0x0001d890 in app_run ()
 #11 0x0001fe24 in main ()
 __

 Thanks,
 Partha


 On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi parth...@gmail.com wrote:

 Jehan,

 Looks like the segfault is back?

 Thanks,
 Partha



 On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:

 Jehan,

 Thumbs up! All good now. It didn't crash and I was able to open images
 etc.

 Thanks again,
 Partha



 On Thu, Jul 18, 2013 at 10:56 PM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:

 Hey Partha,

 you can pull and test now. I made a simple commit where I only take
 care of the unset env variable issue. Hopefully this will fix the OSX
 crash. I'll handle the other issue I discovered about not being
 thread-safe later.
 Tell me how it goes. :-)

 Jehan

 On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès
 jehan.marmott...@gmail.com wrote:
 Partha,

 nothing pushed yet. I'll do this and send a message. :-)

 Jehan

 On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi parth...@gmail.com
 wrote:
 Jehan,

 Do you want me to go ahead test the current code or wait for you to
 add
 additional logic?

 Thanks!
 Partha



 On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès
 jehan.marmott...@gmail.com
 wrote:

 Hi,

 I searched a little more though, and it seems on BSDs, hence on OSX,
 indeed setenv with a NULL value could crash the program. The setenv
 in
 GNU libc on the other hand perfectly handles the case explicitly.
 So obviously when I see this kind of code (note I am not 100% sure
 this is the code for Darwin on Mountain Lion but I can't find a
 reference linking the libc numbers there and the Darwin version
 10.8

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hey all,

it seems I am the culprit for this bug. I don't have this crash on Linux though.

It looks like the implementation of setenv/getenv is different on OSX.
According to glib doc, the problem may be that on some
implementations, successive calls may use the same buffer. I guess
that's the case on OSX. And also these calls are not thread-safe. Also
the fact that there is no LANGUAGE env variable should normally not be
a real problem. I don't have this variable set on my system either
and, as I said, no crash here. I guess this brought the real issue of
the OSX getenv/setenv implementation into light though.

In any case, I think that the real solution is to have the list of all
localized languages generated at startup, before any thread or
anything happens (I just saw that's also what glib doc says: we should
only use these calls on startup before any thread happens). Then we
just use this pre-generated list each time it is needed. I was already
thinking that the current design was bad anyway, because we are
basically parsing a huge file of language codes and names each time we
open the preference dialog! Such a waste of resources and time.
I did not modify it at the time because I did not feel like using more
time towards this, but I guess that should be the occasion to do it.

In any case, please fill a bug report and I'll have a look! :-)

Jehan


On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi parth...@gmail.com wrote:
 Hey V,

 Thanks for checking on this. I am glad (in a way) that my system is not the
 only one having this issue! :)

 I will try to revert the above changes and see if the problem disappears.

 Partha



 On Wed, Jul 17, 2013 at 7:51 AM, su_v suv...@users.sourceforge.net wrote:

 On 2013-07-17 01:19 +0100, Partha Bagchi wrote:
  My recent (last built a few moment ago) git builds (2.9) have been
  instantly segfaulting on MBR running Mountain Lion.
 
  gdb backtrace (or commandline execution) shows:
  ./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack trace or [P]roceed:
 S
  #0  0x7fff8b257698 in __wait4 ()
  #1  0x0001018de353 in g_on_error_stack_trace ()
  #2  0x0001018de7f2 in g_on_error_query ()
  #3  0x0001fa54 in gimp_eek ()
  #4  0x0001fac8 in gimp_fatal_error ()
  #5  0x000100010326 in gimp_sigfatal_handler ()
  #6  signal handler called
  #7  0x7fff8c40887e in setenv ()
  #8  0x0001018f76cf in g_setenv ()
  #9  0x000100168c11 in gimp_language_store_self_l10n ()
  #10 0x000101915c99 in emit_start_element ()
  #11 0x0001019170b0 in g_markup_parse_context_parse ()
  #12 0x00010035a7ba in gimp_xml_parser_parse_io_channel ()
  #13 0x00010035a9ab in gimp_xml_parser_parse_file ()
  #14 0x000100168f71 in gimp_language_store_parse_iso_codes ()
  #15 0x00010188619b in g_object_new_internal ()
  #16 0x000101886cdd in g_object_newv ()
  #17 0x000101886edc in g_object_new ()
  #18 0x000100168025 in gimp_language_entry_new ()
  #19 0x00010017cc00 in gimp_prop_language_entry_new ()
  #20 0x0001000a3df2 in gimp_text_options_gui ()
  #21 0x00010005e9e6 in gimp_tools_restore ()
  #22 0x00010001428b in gui_restore_callback ()
  #23 0x00010187dd0d in g_closure_invoke ()
  #24 0x00010189483b in signal_emit_unlocked_R ()
  #25 0x000101897111 in g_signal_emit_valist ()
  #26 0x000101897964 in g_signal_emit ()
  #27 0x0001f2fe in app_run ()
  #28 0x000100011994 in main ()
 
  and gimp-2.9 --verbose
  ...
  Parsing '/Users/partha/Library/Application
  Support/GIMP/2.9/tool-options/gimp-text-tool'
  ./gimp-2.9: fatal error: Segmentation fault: 11
  ./gimp-2.9 (pid:42330): [E]xit, [H]alt, show [S]tack trace or [P]roceed:
 
  Is anyone else on the Mac having this issue? Should I file a bug-report?

 Reproduced (same stack trace) on MBR (13-inch, Late 2011) running OS X
 10.7.5; dependencies for GIMP installed via MacPorts (custom portfiles
 for babl, gegl and GIMP git master).

 Workaround (at least for this segfault at launch time) is to run GIMP
 like this:

 $ echo $LANG
 en_US.UTF-8
 $ LANGUAGE=$LANG gimp --verbose


 Possibly related to the changes in
 
 https://git.gnome.org/browse/gimp/commit/?id=f6dcde1ee66fda4dfdc063022c4d2e901adb9a71
 
 
 https://git.gnome.org/browse/gimp/commit/?id=4eecd9b4ac71615f10819378938dcdce7e531167
 


 hth, V
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership:
 https://mail.gnome.org/mailman/listinfo/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
___
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 git on Mac Segfault

[Jehan Pagès]

Hi again,

I have some working code in my working branch now where I applied the
concepts I wrote about (basically initializing the language store only
once and at the very start of the program, before any threading would
occur hopefully).
Don't know if that will be the finale code, but should be at least
good enough to test on OSX (I don't have access to a OSX machine to
reproduce the bug myself and see if this indeed fixes the issue). As
soon as the report is up, I'll upload the patch there so that someone
with OSX can test it and tell me if that fixes it. :-)
Thanks.

Jehan


On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hey all,

 it seems I am the culprit for this bug. I don't have this crash on Linux 
 though.

 It looks like the implementation of setenv/getenv is different on OSX.
 According to glib doc, the problem may be that on some
 implementations, successive calls may use the same buffer. I guess
 that's the case on OSX. And also these calls are not thread-safe. Also
 the fact that there is no LANGUAGE env variable should normally not be
 a real problem. I don't have this variable set on my system either
 and, as I said, no crash here. I guess this brought the real issue of
 the OSX getenv/setenv implementation into light though.

 In any case, I think that the real solution is to have the list of all
 localized languages generated at startup, before any thread or
 anything happens (I just saw that's also what glib doc says: we should
 only use these calls on startup before any thread happens). Then we
 just use this pre-generated list each time it is needed. I was already
 thinking that the current design was bad anyway, because we are
 basically parsing a huge file of language codes and names each time we
 open the preference dialog! Such a waste of resources and time.
 I did not modify it at the time because I did not feel like using more
 time towards this, but I guess that should be the occasion to do it.

 In any case, please fill a bug report and I'll have a look! :-)

 Jehan


 On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi parth...@gmail.com wrote:
 Hey V,

 Thanks for checking on this. I am glad (in a way) that my system is not the
 only one having this issue! :)

 I will try to revert the above changes and see if the problem disappears.

 Partha



 On Wed, Jul 17, 2013 at 7:51 AM, su_v suv...@users.sourceforge.net wrote:

 On 2013-07-17 01:19 +0100, Partha Bagchi wrote:
  My recent (last built a few moment ago) git builds (2.9) have been
  instantly segfaulting on MBR running Mountain Lion.
 
  gdb backtrace (or commandline execution) shows:
  ./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack trace or [P]roceed:
 S
  #0  0x7fff8b257698 in __wait4 ()
  #1  0x0001018de353 in g_on_error_stack_trace ()
  #2  0x0001018de7f2 in g_on_error_query ()
  #3  0x0001fa54 in gimp_eek ()
  #4  0x0001fac8 in gimp_fatal_error ()
  #5  0x000100010326 in gimp_sigfatal_handler ()
  #6  signal handler called
  #7  0x7fff8c40887e in setenv ()
  #8  0x0001018f76cf in g_setenv ()
  #9  0x000100168c11 in gimp_language_store_self_l10n ()
  #10 0x000101915c99 in emit_start_element ()
  #11 0x0001019170b0 in g_markup_parse_context_parse ()
  #12 0x00010035a7ba in gimp_xml_parser_parse_io_channel ()
  #13 0x00010035a9ab in gimp_xml_parser_parse_file ()
  #14 0x000100168f71 in gimp_language_store_parse_iso_codes ()
  #15 0x00010188619b in g_object_new_internal ()
  #16 0x000101886cdd in g_object_newv ()
  #17 0x000101886edc in g_object_new ()
  #18 0x000100168025 in gimp_language_entry_new ()
  #19 0x00010017cc00 in gimp_prop_language_entry_new ()
  #20 0x0001000a3df2 in gimp_text_options_gui ()
  #21 0x00010005e9e6 in gimp_tools_restore ()
  #22 0x00010001428b in gui_restore_callback ()
  #23 0x00010187dd0d in g_closure_invoke ()
  #24 0x00010189483b in signal_emit_unlocked_R ()
  #25 0x000101897111 in g_signal_emit_valist ()
  #26 0x000101897964 in g_signal_emit ()
  #27 0x0001f2fe in app_run ()
  #28 0x000100011994 in main ()
 
  and gimp-2.9 --verbose
  ...
  Parsing '/Users/partha/Library/Application
  Support/GIMP/2.9/tool-options/gimp-text-tool'
  ./gimp-2.9: fatal error: Segmentation fault: 11
  ./gimp-2.9 (pid:42330): [E]xit, [H]alt, show [S]tack trace or [P]roceed:
 
  Is anyone else on the Mac having this issue? Should I file a bug-report?

 Reproduced (same stack trace) on MBR (13-inch, Late 2011) running OS X
 10.7.5; dependencies for GIMP installed via MacPorts (custom portfiles
 for babl, gegl and GIMP git master).

 Workaround (at least for this segfault at launch time) is to run GIMP
 like this:

 $ echo $LANG
 en_US.UTF-8
 $ LANGUAGE=$LANG gimp --verbose


 Possibly related to the changes in
 
 https://git.gnome.org/browse/gimp/commit/?id=f6dcde1ee66fda4dfdc063022c4d2e901adb9a71
 
 
 https://git.gnome.org/browse/gimp/commit/?id

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hi,

I searched a little more though, and it seems on BSDs, hence on OSX,
indeed setenv with a NULL value could crash the program. The setenv in
GNU libc on the other hand perfectly handles the case explicitly.
So obviously when I see this kind of code (note I am not 100% sure
this is the code for Darwin on Mountain Lion but I can't find a
reference linking the libc numbers there and the Darwin version 10.8,
but I assume that should be a similar code):
http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c

Before any test on the value pointer, it dereferences it (which is
undefined!), and read the content of the non-existing first character
of the NULL string (which I assume would crash!):

if (*value == '=') /* no `=' in value */
++value;

I don't know what is the policy on BSD but I thought they were very
keen on security, but this code does not look very sane to me.
So yeah anyway that's a problem too in the end. I'll deal with it.

Jehan


On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi parth...@gmail.com wrote:
 Jehan,

 I will test it tomorrow. I will get back to you with the results.

 Thanks for your prompt response!

 Partha



 On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi again,

 I have some working code in my working branch now where I applied the
 concepts I wrote about (basically initializing the language store only
 once and at the very start of the program, before any threading would
 occur hopefully).
 Don't know if that will be the finale code, but should be at least
 good enough to test on OSX (I don't have access to a OSX machine to
 reproduce the bug myself and see if this indeed fixes the issue). As
 soon as the report is up, I'll upload the patch there so that someone
 with OSX can test it and tell me if that fixes it. :-)
 Thanks.

 Jehan


 On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:
  Hey all,
 
  it seems I am the culprit for this bug. I don't have this crash on Linux
  though.
 
  It looks like the implementation of setenv/getenv is different on OSX.
  According to glib doc, the problem may be that on some
  implementations, successive calls may use the same buffer. I guess
  that's the case on OSX. And also these calls are not thread-safe. Also
  the fact that there is no LANGUAGE env variable should normally not be
  a real problem. I don't have this variable set on my system either
  and, as I said, no crash here. I guess this brought the real issue of
  the OSX getenv/setenv implementation into light though.
 
  In any case, I think that the real solution is to have the list of all
  localized languages generated at startup, before any thread or
  anything happens (I just saw that's also what glib doc says: we should
  only use these calls on startup before any thread happens). Then we
  just use this pre-generated list each time it is needed. I was already
  thinking that the current design was bad anyway, because we are
  basically parsing a huge file of language codes and names each time we
  open the preference dialog! Such a waste of resources and time.
  I did not modify it at the time because I did not feel like using more
  time towards this, but I guess that should be the occasion to do it.
 
  In any case, please fill a bug report and I'll have a look! :-)
 
  Jehan
 
 
  On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi parth...@gmail.com
  wrote:
  Hey V,
 
  Thanks for checking on this. I am glad (in a way) that my system is not
  the
  only one having this issue! :)
 
  I will try to revert the above changes and see if the problem
  disappears.
 
  Partha
 
 
 
  On Wed, Jul 17, 2013 at 7:51 AM, su_v suv...@users.sourceforge.net
  wrote:
 
  On 2013-07-17 01:19 +0100, Partha Bagchi wrote:
   My recent (last built a few moment ago) git builds (2.9) have been
   instantly segfaulting on MBR running Mountain Lion.
  
   gdb backtrace (or commandline execution) shows:
   ./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack trace or
   [P]roceed:
  S
   #0  0x7fff8b257698 in __wait4 ()
   #1  0x0001018de353 in g_on_error_stack_trace ()
   #2  0x0001018de7f2 in g_on_error_query ()
   #3  0x0001fa54 in gimp_eek ()
   #4  0x0001fac8 in gimp_fatal_error ()
   #5  0x000100010326 in gimp_sigfatal_handler ()
   #6  signal handler called
   #7  0x7fff8c40887e in setenv ()
   #8  0x0001018f76cf in g_setenv ()
   #9  0x000100168c11 in gimp_language_store_self_l10n ()
   #10 0x000101915c99 in emit_start_element ()
   #11 0x0001019170b0 in g_markup_parse_context_parse ()
   #12 0x00010035a7ba in gimp_xml_parser_parse_io_channel ()
   #13 0x00010035a9ab in gimp_xml_parser_parse_file ()
   #14 0x000100168f71 in gimp_language_store_parse_iso_codes ()
   #15 0x00010188619b in g_object_new_internal ()
   #16 0x000101886cdd in g_object_newv ()
   #17 0x000101886edc in g_object_new ()
   #18 0x000100168025

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Partha,

nothing pushed yet. I'll do this and send a message. :-)

Jehan

On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi parth...@gmail.com wrote:
 Jehan,

 Do you want me to go ahead test the current code or wait for you to add
 additional logic?

 Thanks!
 Partha



 On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,

 I searched a little more though, and it seems on BSDs, hence on OSX,
 indeed setenv with a NULL value could crash the program. The setenv in
 GNU libc on the other hand perfectly handles the case explicitly.
 So obviously when I see this kind of code (note I am not 100% sure
 this is the code for Darwin on Mountain Lion but I can't find a
 reference linking the libc numbers there and the Darwin version 10.8,
 but I assume that should be a similar code):

 http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c

 Before any test on the value pointer, it dereferences it (which is
 undefined!), and read the content of the non-existing first character
 of the NULL string (which I assume would crash!):

 if (*value == '=') /* no `=' in value */
 ++value;

 I don't know what is the policy on BSD but I thought they were very
 keen on security, but this code does not look very sane to me.
 So yeah anyway that's a problem too in the end. I'll deal with it.

 Jehan


 On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi parth...@gmail.com wrote:
  Jehan,
 
  I will test it tomorrow. I will get back to you with the results.
 
  Thanks for your prompt response!
 
  Partha
 
 
 
  On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès
  jehan.marmott...@gmail.com
  wrote:
 
  Hi again,
 
  I have some working code in my working branch now where I applied the
  concepts I wrote about (basically initializing the language store only
  once and at the very start of the program, before any threading would
  occur hopefully).
  Don't know if that will be the finale code, but should be at least
  good enough to test on OSX (I don't have access to a OSX machine to
  reproduce the bug myself and see if this indeed fixes the issue). As
  soon as the report is up, I'll upload the patch there so that someone
  with OSX can test it and tell me if that fixes it. :-)
  Thanks.
 
  Jehan
 
 
  On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès
  jehan.marmott...@gmail.com
  wrote:
   Hey all,
  
   it seems I am the culprit for this bug. I don't have this crash on
   Linux
   though.
  
   It looks like the implementation of setenv/getenv is different on
   OSX.
   According to glib doc, the problem may be that on some
   implementations, successive calls may use the same buffer. I guess
   that's the case on OSX. And also these calls are not thread-safe.
   Also
   the fact that there is no LANGUAGE env variable should normally not
   be
   a real problem. I don't have this variable set on my system either
   and, as I said, no crash here. I guess this brought the real issue of
   the OSX getenv/setenv implementation into light though.
  
   In any case, I think that the real solution is to have the list of
   all
   localized languages generated at startup, before any thread or
   anything happens (I just saw that's also what glib doc says: we
   should
   only use these calls on startup before any thread happens). Then we
   just use this pre-generated list each time it is needed. I was
   already
   thinking that the current design was bad anyway, because we are
   basically parsing a huge file of language codes and names each time
   we
   open the preference dialog! Such a waste of resources and time.
   I did not modify it at the time because I did not feel like using
   more
   time towards this, but I guess that should be the occasion to do it.
  
   In any case, please fill a bug report and I'll have a look! :-)
  
   Jehan
  
  
   On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi parth...@gmail.com
   wrote:
   Hey V,
  
   Thanks for checking on this. I am glad (in a way) that my system is
   not
   the
   only one having this issue! :)
  
   I will try to revert the above changes and see if the problem
   disappears.
  
   Partha
  
  
  
   On Wed, Jul 17, 2013 at 7:51 AM, su_v suv...@users.sourceforge.net
   wrote:
  
   On 2013-07-17 01:19 +0100, Partha Bagchi wrote:
My recent (last built a few moment ago) git builds (2.9) have
been
instantly segfaulting on MBR running Mountain Lion.
   
gdb backtrace (or commandline execution) shows:
./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack trace or
[P]roceed:
   S
#0  0x7fff8b257698 in __wait4 ()
#1  0x0001018de353 in g_on_error_stack_trace ()
#2  0x0001018de7f2 in g_on_error_query ()
#3  0x0001fa54 in gimp_eek ()
#4  0x0001fac8 in gimp_fatal_error ()
#5  0x000100010326 in gimp_sigfatal_handler ()
#6  signal handler called
#7  0x7fff8c40887e in setenv ()
#8  0x0001018f76cf in g_setenv ()
#9  0x000100168c11

Re: [Gimp-developer] Gimp git on Mac Segfault

[Jehan Pagès]

Hey Partha,

you can pull and test now. I made a simple commit where I only take
care of the unset env variable issue. Hopefully this will fix the OSX
crash. I'll handle the other issue I discovered about not being
thread-safe later.
Tell me how it goes. :-)

Jehan

On Fri, Jul 19, 2013 at 11:26 AM, Jehan Pagès
jehan.marmott...@gmail.com wrote:
 Partha,

 nothing pushed yet. I'll do this and send a message. :-)

 Jehan

 On Fri, Jul 19, 2013 at 11:21 AM, Partha Bagchi parth...@gmail.com wrote:
 Jehan,

 Do you want me to go ahead test the current code or wait for you to add
 additional logic?

 Thanks!
 Partha



 On Thu, Jul 18, 2013 at 10:04 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:

 Hi,

 I searched a little more though, and it seems on BSDs, hence on OSX,
 indeed setenv with a NULL value could crash the program. The setenv in
 GNU libc on the other hand perfectly handles the case explicitly.
 So obviously when I see this kind of code (note I am not 100% sure
 this is the code for Darwin on Mountain Lion but I can't find a
 reference linking the libc numbers there and the Darwin version 10.8,
 but I assume that should be a similar code):

 http://www.opensource.apple.com/source/Libc/Libc-825.26/stdlib/FreeBSD/setenv.c

 Before any test on the value pointer, it dereferences it (which is
 undefined!), and read the content of the non-existing first character
 of the NULL string (which I assume would crash!):

 if (*value == '=') /* no `=' in value */
 ++value;

 I don't know what is the policy on BSD but I thought they were very
 keen on security, but this code does not look very sane to me.
 So yeah anyway that's a problem too in the end. I'll deal with it.

 Jehan


 On Fri, Jul 19, 2013 at 7:14 AM, Partha Bagchi parth...@gmail.com wrote:
  Jehan,
 
  I will test it tomorrow. I will get back to you with the results.
 
  Thanks for your prompt response!
 
  Partha
 
 
 
  On Thu, Jul 18, 2013 at 11:42 AM, Jehan Pagès
  jehan.marmott...@gmail.com
  wrote:
 
  Hi again,
 
  I have some working code in my working branch now where I applied the
  concepts I wrote about (basically initializing the language store only
  once and at the very start of the program, before any threading would
  occur hopefully).
  Don't know if that will be the finale code, but should be at least
  good enough to test on OSX (I don't have access to a OSX machine to
  reproduce the bug myself and see if this indeed fixes the issue). As
  soon as the report is up, I'll upload the patch there so that someone
  with OSX can test it and tell me if that fixes it. :-)
  Thanks.
 
  Jehan
 
 
  On Thu, Jul 18, 2013 at 9:47 PM, Jehan Pagès
  jehan.marmott...@gmail.com
  wrote:
   Hey all,
  
   it seems I am the culprit for this bug. I don't have this crash on
   Linux
   though.
  
   It looks like the implementation of setenv/getenv is different on
   OSX.
   According to glib doc, the problem may be that on some
   implementations, successive calls may use the same buffer. I guess
   that's the case on OSX. And also these calls are not thread-safe.
   Also
   the fact that there is no LANGUAGE env variable should normally not
   be
   a real problem. I don't have this variable set on my system either
   and, as I said, no crash here. I guess this brought the real issue of
   the OSX getenv/setenv implementation into light though.
  
   In any case, I think that the real solution is to have the list of
   all
   localized languages generated at startup, before any thread or
   anything happens (I just saw that's also what glib doc says: we
   should
   only use these calls on startup before any thread happens). Then we
   just use this pre-generated list each time it is needed. I was
   already
   thinking that the current design was bad anyway, because we are
   basically parsing a huge file of language codes and names each time
   we
   open the preference dialog! Such a waste of resources and time.
   I did not modify it at the time because I did not feel like using
   more
   time towards this, but I guess that should be the occasion to do it.
  
   In any case, please fill a bug report and I'll have a look! :-)
  
   Jehan
  
  
   On Thu, Jul 18, 2013 at 6:31 AM, Partha Bagchi parth...@gmail.com
   wrote:
   Hey V,
  
   Thanks for checking on this. I am glad (in a way) that my system is
   not
   the
   only one having this issue! :)
  
   I will try to revert the above changes and see if the problem
   disappears.
  
   Partha
  
  
  
   On Wed, Jul 17, 2013 at 7:51 AM, su_v suv...@users.sourceforge.net
   wrote:
  
   On 2013-07-17 01:19 +0100, Partha Bagchi wrote:
My recent (last built a few moment ago) git builds (2.9) have
been
instantly segfaulting on MBR running Mountain Lion.
   
gdb backtrace (or commandline execution) shows:
./gimp-2.9 (pid:42315): [E]xit, [H]alt, show [S]tack trace or
[P]roceed:
   S
#0  0x7fff8b257698 in __wait4 ()
#1  0x0001018de353

Re: [Gimp-developer] Gimp build for Windows

[Jehan Pagès]

Hi,


On Thu, Jan 10, 2013 at 8:46 PM, pavel pa...@pamsoft.cz wrote:

 Hi Skand,

 here is a detailed guide of how to compile the dependencies. First of
 all, I used MinGW64 cross compiler (Ruben's personal build) to build
 both 32 and 64bit versions of Gimp. 32bit version works on Windows XP
 and newer, 64bit version works on Win7, does not work on XP 64bit, I
 suppose it would work on Vista and newer. I cannot see any issue like
 instability or malfunctions.

 zlib - I wasn't able to run configure for cross-compilation here,
 fortunately this is an easy piece of code, so make can be called
 directly with Makefile.gcc
 libffi - no problems from here onwards until I mention some
 libiconv
 libxml2
 gettext
 glib - this is a bit tricky. I don't want to go into details, but there
 are several issues with it and requires lots of manual intervention. I
 can perhaps describe all the issues in a separate thread, if someone
 request that
 gtk-doc - no problems
 atk - does not want to build shared library for 64bit version. Generated
 libtool must be manually edited to go through.
 libpng - no problems again
 jpeg-8d
 jasper
 tiff
 gdk-pixbuf
 freetype
 fontconfig
 lcms (taken from ghostscript source)
 lcms2
 jbig2dec (taken from ghostscript source)

 ghostscript - this is really hard one. In the end I created my own
 script to build libgs.dll

 libspectre - no problems again
 poppler
 pixman - must be configured with --disable-sse2 !!! Otherwise Gimp gets
 very unstable, at least on virtual XP SP3
 cairo - no problems from now till the end
 harfbuzz
 pango
 libcroco
 librsvg
 libexif
 libmng
 iso-codes
 gtk+
 babl
 gegl
 GIMP !!!


Impressive list. I would have abandoned before...
In any case, for it to be more useful, details are better because that make
a lot of difference:
- which version you installed for each dependency (that can change much)
- which compile option

Still I would say that you made too much effort (as impressive as they
are). As Mitch said, you should not have to compile this all (the wiki page
that Alexandre linked contains all the details to make a simple
cross-compile environment).

Some final thoughts. The configure and libtool are very often so clever
 that they refuse to build shared libraries even if all the required
 dependencies exist. libtool must be manually edited and then it builds
 them OK. The extra mentioned atk package is an exception to this role -
 they are even more clever here for the 64bit cross-compilation that much
 bigger portion of libtool must be commented out.


Could you be more specific? What do you mean by editing libtool? Are you
sure you simply have not set your environment variables to point to the
right prefixes for your cross-compiled environment *instead of* your normal
environment (/usr/ and /usr/local usually)?
Once again the wiki page has some information on which such environment
variables to set (note that there may be other env variables good to set.
In any case it is rarely a good idea to do too specific configuration for a
generic compilation environment).


 For this reason it is almost impossible to create an automated script
 which would do all the job. Or at least I am not skilled enough for
 that.


Well as I said, the wiki gives all this information. And it is perfectly
automatable. Actually I know it, because I wrote such a script, using my
wiki notes.  :-)
I have a command line which allows me to create and enter cross-compilation
environments in both 32 and 64 bits in 1 line (obviously it does not
compile all the chain like you do! I use pre-compiled packages as in the
wiki).



 I don't know whether the sequence I gave here is an optimal one, but it
 works. I hope it will be helpful anyway.


And I hope my comments were useful too. I don't want to look like I am
negative. I just try to simplify your process. Plus, that should ease your
work and give you more time for actual bug fixing!
Have fun!

Jehan




 Pavel


 On Thu, 2013-01-10 at 15:11 +0530, Skand Hurkat wrote:
  Could you provide a list of steps that went into compiling the
  dependencies? I have been trying to compile a similar list of
  dependencies for Win64 (using MinGW64), and have found very little,
  and/or scattered documentation for the same.
  A consolidated list of steps, or even better, a shell script that does
  the job will be highly appreciated.
 
  Regards,
  Skand.
 
  On 09-01-2013 15:05, pavel wrote:
   Hi Gimp team,
  
   are you still looking for a Windows developer? Recently I've spent
   couple of days, or maybe weeks, to compile Gimp for Windows, 32bit. In
   the end I have a working Gimp, version 2.8.2. I have built the whole
 GNU
   chain, starting with zlib through gtk+-2.0 and ending with Gimp, using
   the most recent stable versions of all the necessary packages. Today I
   quickly went through the list of Windows related bugs and it looks like
   lots of them have gone.
  
   My initial intention was only to have a working build so that I could
   

Re: [Gimp-developer] [usability wishlist] Fixing the off-screen immovable text tool

[Jehan Pagès]

Hi Lauri,

I agree with you, I had the same experience lately and that's very
annoying. That's indeed a usability bug, which usually means it is a
feature request (because usability bug means it still works but could be
better).

I would suggest you open a ticket about this on the bugzilla, mark it as an
enhancement, and come back here to give us the link. Eventually someone
would step up to make it so. Maybe even me if some day I am really too
annoyed by it. :-)

Also in the meantime, note that there is one solution to your issue: you
can increase the size of the window, then you'll see the whole text tool.
Annoying, but not a blocker.
Enjoy!

Jehan


On Mon, Dec 17, 2012 at 1:52 AM, Lauri Kasanen c...@gmx.com wrote:

 Hi list

 Screenshot of the issue: http://i46.tinypic.com/1zmfn0g.png

 If you try to add text to the right edge, part of the inline text tool is
 off-screen and so inaccessible.

 To me, the bad initial positioning wouldn't be so bad if the tool were
 movable, but it's not.


 To fix this, I would propose two things:
 - adding smart placement, so it would always start fully visible
 - making it movable, so the user can still move it to a better place

 On the IRC I was told this wasn't a bug, so posting here for comments.
 Personally I consider it a usability bug ;)

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

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

Re: [Gimp-developer] Status of the Unified Transform Tool?

[Jehan Pagès]

On Fri, Nov 30, 2012 at 6:07 PM, Michael Natterer mi...@gimp.org wrote:

 On Fri, 2012-11-30 at 13:33 +0900, Jehan Pagès wrote:
  Hi,
 
  what is the state of the Unified Transform Tool and when can we hope to
 see
  it in master branch?
  [ snip ]

 It is already in master for a few months ;)


Oups! But nice. :-p

Jehan


 --mitch



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

[Gimp-developer] Status of the Unified Transform Tool?

[Jehan Pagès]

Hi,

what is the state of the Unified Transform Tool and when can we hope to see
it in master branch?

The artist working with me often complains about the completely disparate
transform tools in GIMP for which she has to set up many different
shortcut. And I saw there was this gsoc about exactly this feature.

So I was wondering what was the status. When will it make it to master? Is
it in active development (git log shows me no commit since August 21st,
which is not very re-assuring), or dying since gsoc ended?
Thanks all!

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

Re: [Gimp-developer] Translation Error

[Jehan Pagès]

Hi,

looks like this typo has already been changed in our development
repository. I can find a whole bunch of ferramenta in our translation
files, but no feeramenta (with case-insensitive search in all our files).

You should see the right tool name the next time a version will be
released, I guess. :-)
Thanks for the report.

Jehan


On Wed, Nov 21, 2012 at 10:54 AM, Ivair ivairoso...@gmail.com wrote:

 Hi,


 My name is Ivair. I'm from Brazil.

 Today I discovered a translation error on Portuguese-Br Gimp version, that
 I'll attaching a screenshot in this message.

 In portuguese, the meaning of Tool word is ferramenta, the translator
 wrote Feeramenta.


 Thanks



 --
 Ivair
 ivairoso...@gmail.com

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


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

Re: [Gimp-developer] Feedback and personal comments about Gimp 2.8

[Jehan Pagès]

Hi,


On Tue, Nov 20, 2012 at 3:05 AM, Vincent Cadet v_ca...@yahoo.fr wrote:

 --- En date de : Lun 19.11.12, Vincent Cadet v_ca...@yahoo.fr a écrit :

I'll wipe out my current profile and check again to make sure.

 I can confirm: Gimp 2.8 defaults to assigning the airbrush to the stylus
 *and* eraser until I change it. Either tip of the pen remain with the
 assigned brush until I close Gimp. I have checked with the default Gimp 2.8
 profile, as I suspected I had done it initially.

 Here's what I did:

 1. run: find ~/.gimp-2.8 -delete (it's been backed up beforehand ;-)
 2. run: Gimp 2.8
 3. enable Bamboo Fun (pad, pen, eraser) and Cintiq (pad, pen, eraser)
 devices, mode screen
 4. use the pen: notice airbrush selected
 5. flip the stylus to use the eraser: notice airbrush selected
 6. select the eraser tool


From what I recall, I also had this behavior (did not try to reproduce just
now, but I remember at the time it took a while to actually realize I could
select a different tool for the eraser tip).
That would indeed be much more friendlier to have the eraser selected by
default.


 7. flip back to the pen: notice airbrush selected
 8. flip again to the eraser: notice eraser selected.

 Repeat 4. - 8. for the other tablet.

 Takes longer to write than do but that's it :D .


Well I'd propose you copy that down in a bug report on our bugzilla and
post the ticket ID on this thread after. :-)

Jehan



 Cheers,
 Vince C.
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

Re: [Gimp-developer] Helping with the GEGL transition

[Jehan Pagès]

Hi,


On Fri, Nov 16, 2012 at 4:42 PM, Alexandre Prokoudine 
alexandre.prokoud...@gmail.com wrote:

 On Fri, Nov 16, 2012 at 9:05 AM, Jehan Pagès wrote:
  Hi,
 
  I just wanted to know if there was some help needed for the GEGL
 transition.

 We absolutely need help there :)

  From what I understood, the fact we are in the middle of it is the main
  reason why the whole GIMP drawing from master is so extraordinary slow.
  So if I could help to speed this all up, I'd be happy. :-)
 
  But right now I am too new to GIMP dev to know by myself where to start
 on
  this specific topic. Is there any task/bug ticket you might direct me to
  whether you'd need more hands?

 Please talk to mitch on IRC (irc://irc.gimp.org/#gimp) about that :)

 We use IRC as primary communication channel for all development
 discussions.


I took your advice and am discussing with him right now.
Thanks.

Jehan


 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

[Gimp-developer] Cross-compile for and packaging/testing on Windows

[Jehan Pagès]

Hi,

I have tried native compilation (the GIT repo) in a Windows 7 VM; then I
tried to cross-compile.
I finally managed to complete the GIMP cross-compilation!
This email from the archive has been a great help by the way:
https://mail.gnome.org/archives/gimp-developer-list/2012-May/msg00067.html

This kind of information should definitely be in a WINDOWS-DEV-README (or
whatever you wish to call it) file in our repo! That would prevent
potential developers to search for days on the web (and for myself in the
future maybe, because I probably, and hopefully, won't cross-compile
anything for quite some time).

Would it be ok to include such a file in devel-docs/ for instance?
I can provide an updated version for this procedure.

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

Re: [Gimp-developer] Cross-compile for and packaging/testing on Windows

[Jehan Pagès]

Hi,

On Mon, Nov 12, 2012 at 12:46 PM, drawoc dra...@darkrefraction.com wrote:

 Personally, I think the wiki would probably be a better place for
 stuff like that than the repo (but it's not really my call what goes
 in the repo or not).

 There's already a stub for compiling for/on windows:
 http://wiki.gimp.org/index.php/Hacking:Building/Windows


I didn't know this page, though it is not much filled anyway. :-)
I personally does not care much *where* it is as long as I know this
*where*. Indeed I think it could be a little more centralized. Between
developer.gimp.org, the wiki, what is in the repo, etc. I am a little lost
and end up spending more time on search engines than in the doc. :-/


 If you'd like a wiki account, I'm told you should hop on IRC and
 bother either LightningIsMyName or Alexia_Death.


Ok I'll pass some time today or another day and ask for an account.


 If you need any more help with cross compiling, feel free to ask. A
 few people, including myself, have up to date cross compiling
 environments working, and wouldn't mind helping you (or anyone) out if
 you run into any more problems.


Thanks for the offer! I had so many problems one after the other that I
felt asking too much would be bothering everyone.
Anyway now I compiled it, well enough to be able to test my patch (that is
now in the main repo), so hopefully I won't need to bother with Windows for
quite some time.
But if I need more, I will ask on the list. :-)

Jehan

  -- drawoc

 On Sun, Nov 11, 2012 at 9:22 PM, Jehan Pagès jehan.marmott...@gmail.com
 wrote:
  Hi,
 
  I have tried native compilation (the GIT repo) in a Windows 7 VM; then I
  tried to cross-compile.
  I finally managed to complete the GIMP cross-compilation!
  This email from the archive has been a great help by the way:
 
 https://mail.gnome.org/archives/gimp-developer-list/2012-May/msg00067.html
 
  This kind of information should definitely be in a WINDOWS-DEV-README (or
  whatever you wish to call it) file in our repo! That would prevent
 potential
  developers to search for days on the web (and for myself in the future
  maybe, because I probably, and hopefully, won't cross-compile anything
 for
  quite some time).
 
  Would it be ok to include such a file in devel-docs/ for instance?
  I can provide an updated version for this procedure.
 
  Jehan
 
  ___
  gimp-developer-list mailing list
  gimp-developer-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gimp-developer-list
 

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

Re: [Gimp-developer] XDG support and better Windows configuration path

[Jehan Pagès]

Hi,

On Thu, Oct 11, 2012 at 3:50 PM, Michael Natterer mi...@gimp.org wrote:
 On Thu, 2012-10-11 at 13:21 +0900, Jehan Pagès wrote:
 That leads me to wonder: what do we want to do if the variable is set:
 1) We save directly under this path. Hence we never know if a version
 bump (or downgrade) occurred (hence there can be problems at every
 change of version for this user's configuration if ever something a
 little more than copy-paste needed to happen).
 2) We now make a subdirectory with the version. Hence $GIMP2_DIRECTORY/x.x/.

 I would think that we could go with 2). That's a little more work to
 detect the situation but that's nicer to the users. What do you think?
 Of course, if you don't want, that's just less work for me, so I am
 ok. :p

 We can't do that, gimp_directory() returns the folder where
 stuff is stored, and i should stay that way.


I must have badly explained, because that's not what I wanted to tell.
:-) gimp_directory() will still and always return where stuff is
stored. No problem here. Only discussing how to determine this folder
when the env variable is set. Basically there are 2 cases:

(1) No environment var set: gimp_directory() will return {conf-dir}/GIMP/2.10/
where {conf-dir} depends on the platform (XDG_CONFIG_HOME on Linux,
APPDATA on Win and NSApplicationSupportDirectory on OSX basically).
All good.

(2) the env var is set: until now gimp_directory() would return
$GIMP2_DIRECTORY itself.
I propose to return $GIMP2_DIRECTORY/2.10/ instead.
Note that the user is still choosing the root of where GIMP should
store the configuration, and all the rest. Simply we add one level in
the configuration tree. This way, first we make it consistent with the
case (1). Second we can support their configuration migration.

The problem indeed when people set this variable is that when a 2.8
users will use 2.10 for the first time, if he had this variable both
before and now, GIMP will not consider the user's configuration to be
a 2.8. Hence no migration will happen. In most cases, that should be
ok (as the migration is mostly about copy-pasting files and folders).
But if something changed and we want to actually do something other
than copy-pasting, these users will be the only one where the
migration will fail.

I hope this is clear enough this time. But I definitely don't propose
to break the return valye of gimp_directory().

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

Re: [Gimp-developer] XDG support and better Windows configuration path

[Jehan Pagès]

Hi,

On Thu, Oct 11, 2012 at 7:12 AM, Michael Natterer mi...@gimp.org wrote:
 Hi all,

 Since we are about to change things here, let's do
 it right and consistent across platforms this time.

 I suggest:

 OSX: NSApplicationSupportDirectory/GIMP/GIMP_APP_VERSION
 WIN: APPDATA/GIMP/GIMP_APP_VERSION
 XDG: XDG_CONFIG_DIR/GIMP/GIMP_APP_VERSION

 which means for master:

 OSX: ~/Library/Application Support/GIMP/2.9
 WIN: (whatever windows folder i have no clue about)\GIMP\2.9
 XDG: ~/.config/GIMP/2.9

 I know the part before GIMP/2.9 should be handled
 by g_get_user_config_dir(), but until it does, let's
 do the right thing anyway.

 Comments?

Good for me. I'll change my patch according to this.

Jehan

 --mitch


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

Re: [Gimp-developer] Procedure for new patches

[Jehan Pagès]

Hi,

On Sun, Oct 7, 2012 at 2:13 PM, drawoc dra...@darkrefraction.com wrote:
 Alexandre: I think you need to check out the branch girin in specific.
 If you cd into an existing gimp checkout you can do something like
 this:
 git remote add gimpgirin git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git
 git fetch --all
 git checkout girin

Indeed. Sorry the main reason is that I use my locale master branch
to track the upstream Gimp master, and my locale girin to track
mine. As I like to have the same locale and remote name for
simplicity, I ended up pushing only a girin branch on my fork.
Anyway all good now. :-)

 Jehan: I think we normally rebase branches around here instead of
 merging, just so you know.
 Btw, since you're using the gimp for animation, you might want to take
 a look at Gimp-GAP.

I saw many references on the web about GAP, so I had a look a few
weeks ago, read and looked a few tutorial and videos, and installed
it. First the last code I could find (on the GIMP plugin registry) was
for Gimp 2.6 3 years ago, along with a Windows binary (we use Linux
distributions). I could compile it nonetheless but the fact it is
obviously unmaintained is not reassuring. And not surprisingly, when
running it, GIMP regularly complains through pop-ups that the plugin
uses some deprecated function, etc.

Second it looked overcomplicated for cases when you want to do boring
stuff on a huge scale with a few images (= do a hundred time the same
thing which is boring and a waste of your time so you automatize).
Like you have a text, you want it to circle around 1000 times, and
change color while doing so; or have a ball jumping around for 10
minutes, etc. That's not what we do.
And in particular, I don't like the way it does it. Like it creates
hundreds of nearly similar xcf files, duplicates layers, and such.
That would be very hard to maintain and work with in a huge project.
Probably nice for making one-time GIF files, then forget about them.
Not that good if each scene of a few seconds implies dozens of xcf
files with several dozens of nearly identical (but sligthly different)
layers.

I may have missed something. But all the tutorial and small tests I
ran was ending the same way.
In other words, I was really not impressed by GAP.

Another issue is that it tries to be an all-in-one solution, whereas
it doesn't do each thing that good. It tries to deal with drawing of
course, but also importing from videos, the sound, sequence editing,
video outputting, etc.

In our current workflow, for extracting images from video data, we use
directly ffmpeg. For the sound, we will be most likely using Audacity
and Ardour on a RT kernel. And for video editing, our current tests
led us to the Blender video editor (kdenlive has limitations which
made it impossible to work with it with more than 2 video channels,
and I have not tested much Cinerella yet).

Once again, if I am wrong and GAP is the ultimate animation tool,
please tell me. :-)

In the meantime, I am actually improving the default animation plugins
available in GIMP upstream repo. I am making so these simple tools
will be all what is necessary to work nicely with GIMP xcf, only for
the drawing part inside a more complete workflow with other tools.
I have done some very nice stuff (partially already in my branch), but
I am not fully done. I plan to make a new bug ticket to propose my
improvements when in a good release test. I will probably make a small
demo along to explain these and post on the list.

 Anyway, it's always good to have more contributers.

:-)

See you soon.

Jehan

   -- drawoc

 On Sat, Oct 6, 2012 at 8:25 PM, Alexandre Prokoudine
 alexandre.prokoud...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 5:37 PM, Jehan Pagès jehan.marmott...@gmail.com 
 wrote:

 As a consequence, I have been working on GIMP code lately, hoping to
 fix issues that my animator or I would encounter, and to add new
 features. For this, I have set up a public repository at
 git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named
 girin).

 warning: remote HEAD refers to nonexistent ref, unable to checkout.

 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] About GimpImageType, image and layers

[Jehan Pagès]

Hi,

On Sun, Oct 7, 2012 at 7:47 AM, Ofnuts ofn...@laposte.net wrote:
 On 10/06/2012 08:30 AM, Jehan Pagès wrote:

 Hi,

 I have a question about the GimpImageType of layers.
 checking several plugins, I see that the GimpImageType

 (http://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpbaseenums.html#GimpImageType)
 is queried for each layer. But as a simple user, this is set
 Image-wide in Gimp, not for each layer. Are there actual cases where
 the GimpImageType can be different on different layers of the same
 image?
 Thanks.



 You can mix layers with and without alpha.


Got it. Basically the type is the same for all layers, except that
they may or not have alpha channel (so if image is RGB, each layer
will be either RGB or RGBA for instance). Makes sense.
Thanks.

Jehan

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

Re: [Gimp-developer] Procedure for new patches

[Jehan Pagès]

Hi,

On Mon, Oct 8, 2012 at 1:39 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Sun, Oct 7, 2012 at 4:15 PM, Jehan Pagès wrote:

 it. First the last code I could find (on the GIMP plugin registry) was
 for Gimp 2.6 3 years ago, along with a Windows binary (we use Linux
 distributions). I could compile it nonetheless but the fact it is
 obviously unmaintained is not reassuring.

 It's not a fact, it's an assumption and an incorrect one at that :)

 http://git.gnome.org/browse/gimp-gap


Thanks. I could not find a repo before. I'll have a look there.

 In our current workflow, for extracting images from video data, we use
 directly ffmpeg. For the sound, we will be most likely using Audacity
 and Ardour on a RT kernel.

 I would recommend Ardour 3 and xjadeo for syncing audio and video.

Thanks for the advice. I'll have a look at this. Any other advice on
any part of a full movie creation workflow is good to take, so don't
hesitate (true for everyone on the list)! :-)
I am just starting to compare, research and test all these awesome programs.

 Unless, of course, by the time you get to that stage Paul merges video
 tracks patch to Ardour.

Ok I miss the references so I guess I need an explanation because I am
either too new to the GIMP list to know a Paul, or that's someone from
Ardour's dev team, or from somewhere else. And what is the video
tracks patch you are talking about? Is Ardour becoming a Video Editor
as well?

Thanks.

Jehan

 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] About GimpImageType, image and layers

[Jehan Pagès]

Hi,

I have a question about the GimpImageType of layers.
checking several plugins, I see that the GimpImageType
(http://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpbaseenums.html#GimpImageType)
is queried for each layer. But as a simple user, this is set
Image-wide in Gimp, not for each layer. Are there actual cases where
the GimpImageType can be different on different layers of the same
image?
Thanks.

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

[Gimp-developer] Procedure for new patches

[Jehan Pagès]

Hello all,

First I guess a small presentation is in order as a new member to this
list: my name is Jehan. I am working with an animator, in the optic of
creating an animation. And we are using Gimp for this (see
http://girinstud.io/ for our newly set-up website).

As a consequence, I have been working on GIMP code lately, hoping to
fix issues that my animator or I would encounter, and to add new
features. For this, I have set up a public repository at
git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named
girin).
I have also just created my 2 first GIMP tickets, one is a bug fix
(Bug 685557), the other a small feature (Bug 685559).

As the HACKING file in the repo says The best way to submit patches
is to publish your git repository and ask developers to git-fetch from
you., I just wanted to be sure the procedure is the right one. Should
I rather make a new branch per fix/feature? Should I just give you the
commit hashes (as I did in these tickets) and you can pick just these
commits into the main repo? Do you actually prefer me to generate a
patch and attach it on the list or in a ticket?
Something else?
Thanks for all!

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

Re: [Gimp-developer] Procedure for new patches

[Jehan Pagès]

Hi,

On Sat, Oct 6, 2012 at 12:24 AM, Michael Natterer mi...@gimp.org wrote:
 On Fri, 2012-10-05 at 22:37 +0900, Jehan Pagès wrote:
 Hello all,

 First I guess a small presentation is in order as a new member to this
 list: my name is Jehan. I am working with an animator, in the optic of
 creating an animation. And we are using Gimp for this (see
 http://girinstud.io/ for our newly set-up website).

 As a consequence, I have been working on GIMP code lately, hoping to
 fix issues that my animator or I would encounter, and to add new
 features. For this, I have set up a public repository at
 git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named
 girin).
 I have also just created my 2 first GIMP tickets, one is a bug fix
 (Bug 685557), the other a small feature (Bug 685559).

 Thanks and welcome to the party :)

 As the HACKING file in the repo says The best way to submit patches
 is to publish your git repository and ask developers to git-fetch from
 you.,

 Heh, does it really say that? I can imagine which of our git crazy
 hackers added this section. If you plan to keep a lot of patches
 around there, this is probably a good idea, for one or two it's
 total overkill :) we will see.

Eh! Anyway it is done now. And I will definitely have other patches. I
am already working on some interesting features (which I hope you will
find interesting to).

  I just wanted to be sure the procedure is the right one. Should
 I rather make a new branch per fix/feature? Should I just give you the
 commit hashes (as I did in these tickets) and you can pick just these
 commits into the main repo? Do you actually prefer me to generate a
 patch and attach it on the list or in a ticket?
 Something else?

 All is fine so far, we will look at your patches. Thanks for
 contributing!

Cool. Thanks.

Jehan

 --mitch


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