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  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  
>> 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  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  
>>>> #7  0x7fff8cb0a60b in strchr ()
>>>> #8  0x000100167614 in gimp_language_store_parser_init ()
>>>> #9  0x000100012c75 in gui_init ()
>>>> #10 0x00010000d890 in app_run ()
>>>> #11 0x0001fe24 in main ()
>>>> __
>>>>
>>>> Thanks,
>>>> Partha
>>>>
>>>>
>>>> On Sat, Jul 27, 2013 at 3:01 PM, Partha Bagchi  wrote:
>>>>>
>>>>> Jehan,
>>>>>
>>>>> Looks like the segfault is back?
>>>>>
>>>>> Thanks,
>>>>> Partha
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 19, 2013 at 7:12 AM, Partha Bagchi  wrote:
>>>>>>
>>>>>> Jehan,
>>>>>>
>>>>>> Thumbs up! All good now. It didn't crash and I was able to open images
>>>>>> etc.
>>>>>>
>>>>>> Thanks agai

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

[Jehan Pagès]

Hi,

On Sun, Jul 28, 2013 at 5:42 PM, su_v  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  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  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  wrote:
>>
>> On 2013-07-28 08:03 +0100, Jehan Pagès wrote:
>> > Hi,
>> >
>> > On Sun, Jul 28, 2013 at 5:42 PM, su_v 
>> > 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 
>> >>> 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 prefer

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

[Jehan Pagès]

Hi,

On Mon, Jul 29, 2013 at 1:28 AM, Partha Bagchi  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 
> wrote:
>>
>> Hi,
>>
>> On Sun, Jul 28, 2013 at 11:51 PM, Partha Bagchi 
>> 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 
>> > wrote:
>> >>
>> >> On 2013-07-28 08:03 +0100, Jehan Pagès wrote:
>> >> > Hi,
>> >> >
>> >> > On Sun, Jul 28, 2013 at 5:42 PM, su_v 
>> >> > 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).
>

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

[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 
Date: Fri, Sep 6, 2013 at 12:53 AM
Subject: Re: [Gimp-developer] Gimp quick brush editor idea.
To: Abraham Levi Mireles Alvarez 


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

[Jehan Pagès]

Hi,

On Fri, Sep 6, 2013 at 9:34 PM, Partha Bagchi  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 
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  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

Re: [Gimp-developer] refactor palette loading code

[Jehan Pagès]

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  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  wrote:
>
>> Hi again,
>>
>> Here's a 
>> linkto
>>  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

Re: [Gimp-developer] refactor palette loading code

[Jehan Pagès]

Hi,

On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
 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  wrote:
>> Attached is the patch.
>>
>> wt
>>
>>
>> On Sun, Sep 8, 2013 at 12:13 PM, Warren Turkal  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 
>>> here<https://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 
>>> (here<https://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 
>>> wrote:
>>>
>>>> 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 
>>>> 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 
>>>> wrote:
>>>> >
>>>> >> Hi again,
>>>> >>
>>>> >> Here's a link<
>>>> https://github.com/wt/gimp/commit/d1e8c4c8543b18c6f5d95f6ab6b3bbbf8f80778b>to
>>>> a commit containing a refactor of the palette loading code. I have moved
>>>&g

[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] 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
 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
>  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 Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal  wrote:
> On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès 
> wrote:
>>
>> On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning
>>  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  wrote:
> * Thomas W  [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  wrote:
> On Sun, Sep 15, 2013 at 10:38 PM, Jehan Pagès 
> 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  wrote:
> On Sun, Sep 15, 2013 at 11:21 PM, Jehan Pagès 
> 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

[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  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  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 
> wrote:
>>
>> Hi,
>>
>>
>> On Mon, Sep 16, 2013 at 5:58 PM, Srihari Sriraman 
>> 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  wrote:
> On 13-09-16 12:31 PM, Jehan Pagès wrote:
>>
>> On Mon, Sep 16, 2013 at 5:58 PM, Srihari Sriraman 
>> 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  | --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

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

[Jehan Pagès]

Hi Jernej, or any other developer able to answer before,

This is a question about the official Windows build, which I
understand you are the maintainer of.

A user has a problem with fonts on Windows. Fonts with no bold/italic
typeface usually can have a simulated bold/italic version. I tested it
on Linux, it indeed works well, but not on Windows. I think that Pango
is taking care of it since it has such a feature.

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?
Thanks!

Jehan

P.S.: you can see the bug here:
https://bugzilla.gnome.org/show_bug.cgi?id=708110
___
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č  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  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

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

[Jehan Pagès]

Hi,

On Mon, Sep 23, 2013 at 12:49 AM, Sven Claussner  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

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  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  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
 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  
> wrote:
>> Hi,
>>
>> On Mon, Sep 23, 2013 at 12:49 AM, Sven Claussner  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] Environment.

[Jehan Pagès]

Hi,

On Sat, Sep 28, 2013 at 7:46 PM, Román  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] 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  wrote:
> Hi,
>
> On Mon, Sep 23, 2013 at 1:51 AM, Michael Henning
>  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

[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

[Gimp-developer] Next minor release?

[Jehan Pagès]

Hi,

About the broken font support, which was simply in the end
fontconfig's configuration which kept some absolute path from the
Linux where it was cross-compiled from, I think it is a pretty broken
stuff.

It was the reason of why italic/bold could not be simulated anymore in
2.8.6 for Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=708110

That's still an ok bug because I think most fonts have bold/italic
faces anyway. But after testing, I could confirm that the bug where
"Sans" was using a Serif-ed font, which is already much more annoying,
is also the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688593

And probably a few other bugs on fonts (reported already or not).

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?

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

[Jehan Pagès]

Hi,

On Fri, Oct 4, 2013 at 10:34 PM, Michael Natterer  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
 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
 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

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

[Jehan Pagès]

Hi,

On Sat, Oct 5, 2013 at 12:59 AM, Simon Budig  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.

I'm ok for it too. And I would be also OK 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 (some pieces of the UI stayed
light, missing icons, etc.), blabla, but each time I try one, it's
broken somehow. 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] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Sun, Oct 6, 2013 at 3:11 PM, Jehan Pagès  wrote:
> Hi,
>
> On Sat, Oct 5, 2013 at 12:59 AM, Simon Budig  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] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Sun, Oct 6, 2013 at 9:08 PM, Sven Claussner  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] 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
 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
>>  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” to

Re: [Gimp-developer] Translator available

[Jehan Pagès]

Hi,

On Thu, Oct 10, 2013 at 4:35 AM, Abraham Mireles Alvarez
 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] Google Code-In program

[Jehan Pagès]

Hi,

On Sun, Oct 13, 2013 at 3:06 AM, scl  wrote:
> 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.

I had a look. I did not read all, but this looks interesting. Maybe
even more than the normal gsoc on another level, because it may be
more manageable than huge 3-month projects that may end up or not
merged in after years. If I got the concept, these younger students
would make much smaller projects, and could do many of them on various
projects. Like few-day-length projects.
So that's a faster pace for mentors, but in the same time, if code for
instance, that will be very small patches. So we check the few line
changes, and if good, we approve the student work and can push the
code to master without waiting for 3 years.

For code tasks for instance, I would not see GEGL porting, because
that involves quite an involvement for the student to comprehend all
the concepts. But I could see GNOME-LOVE bugs/features or other easy
tasks in GIMP, GEGL, babl or even GTK+ when they have direct visible
impact in GIMP. Test case writing could be nice too.

Extensive testing, bug reporting would be good.

And obviously documentation! I'm sure Patdavid would not be against
students re-writing some of the tutorial with new screenshots. And we
could use updating of gimp-help too.

> Do we want to join this program this year?

Anyway all this to say, why not? I would be glad to mentor too. :-)

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

[Jehan Pagès]

Hi again,

On Sun, Oct 13, 2013 at 4:35 PM, Jehan Pagès  wrote:
> Hi,
>
> On Sun, Oct 13, 2013 at 3:06 AM, scl  wrote:
>> 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
> 

Well I checked possible tasks:

- Coding: we have a bunch of GNOME-LOVE bugs:
https://bugzilla.gnome.org/buglist.cgi?quicksearch=keywords%3Agnome-love+product%3A%22GIMP%22+
By definition, they should not take too long for young but autonomous
developers. Each can be considered 1 task.

- Doc: I checked the gimp-help-2 repo. We don't have any doc written
for several new features. For instance there is apparently no page for
the unified transform tool. No page for the warp tool. Nothing about
the new 16/32 bit precision, etc.

I'm sure each of these could be considered 1 full task for a young
student, if done well (with nice screenshot, comprehensive text, and
following DocBook syntax, etc.).

- Tutorial: won't say further, I guess patdavid should be the one
saying what is suitable.

The price here is t-shirts for anyone who complete 3 tasks, and a trip
with their parents to Google headquarters for 20 big winners. That's
not much, so tasks should stay simple stuff. Actually that's the
disappointing stuff, and the only reason why this program is not so
nice (I would never have participated with such prizes when I was a
kid!), because I don't want to use cheap labor. But for kids who like
Free Software and want to participate anyway, yeah why not.

Jehan

>
>> Do we want to join this program this year?
>
> Anyway all this to say, why not? I would be glad to mentor too. :-)
>
> 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] Google Code-In program

[Jehan Pagès]

Hi,

On Mon, Oct 14, 2013 at 1:50 AM, Tobias Jakobs  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 :
>> 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

[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] HELP with SYMBOLIC icon theme for Gimp.

[Jehan Pagès]

Hi,

On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8)  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

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)  wrote:
> El 29/10/13 01:57, Jehan Pagès escribió:
>
>> Hi,
>>
>> On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8)  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  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 Thu, Oct 31, 2013 at 11:31 AM, Michael Schumacher  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)  wrote:
> El 29/10/13 01:57, Jehan Pagès escribió:
>
>> Hi,
>>
>> On Tue, Oct 29, 2013 at 8:15 AM, jEsuSdA 8)  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: license

[Jehan Pagès]

Hi,

On Wed, Nov 6, 2013 at 4:59 AM, scl  wrote:
>
> Hi,
>
> Jakub Steiner answered me.
> He and Barbara Muraus (the other icon designer who
> created the ArtLibre icon set) are ok with relicensing
> it under the GPLv3. We agreed to mention their names
> in the sources.
>
> Jehan, if you have planned to work on this, please
> let me know to save us from duplication of work ;-)

No, no prob, go on. I'm not planning to do any work that someone else
is willing to do instead. :p

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 29, 2013 at 11:19 PM, Jehan Pagès
 wrote:
> Hi,
>
> On Thu, Sep 26, 2013 at 2:50 PM, Jehan Pagès  
> wrote:
>> Hi,
>>
>> On Mon, Sep 23, 2013 at 1:51 AM, Michael Henning
>>  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

The font bugs on Windows are still present in GIMP 2.8.8!
If we use an older version of fontconfig, Drawoc has a patch all ready
for this: build/windows/jhbuild/patches/fontconfig-fix-config-dir.patch
Other than that, we can just use fontconfig 2.11.0 (current stable),
or over when there will be. Fontconfig has the fix since 2.11.0.

Could we make sure the same process is applied for the Windows
nightbuilds (which use the patches in build/windows/) and the releases
(which apparently do not)? That makes it less useful to have
nightbuilds if we don't even provide the same in a release!

And can something be done for GIMP 2.8.8? Since it has just been out,
and that's not a change in GIMP itself, can we update the Windows
packages? Or once it is out, we say it is too late?
Thanks!

Jehan

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

ok I think I got misleaded. The official Windows package maintainer is
actually Jernej, isn't it?
Anyway see below about the unpatched Windows package.

Jehan

On Wed, Nov 6, 2013 at 11:31 AM, Jehan Pagès  wrote:
> Hi,
>
> On Sun, Sep 29, 2013 at 11:19 PM, Jehan Pagès
>  wrote:
>> Hi,
>>
>> On Thu, Sep 26, 2013 at 2:50 PM, Jehan Pagès  
>> wrote:
>>> Hi,
>>>
>>> On Mon, Sep 23, 2013 at 1:51 AM, Michael Henning
>>>  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
>
> The font bugs on Windows are still present in GIMP 2.8.8!
> If we use an older version of fontconfig, Drawoc has a patch all ready
> for this: build/windows/jhbuild/patches/fontconfig-fix-config-dir.patch
> Other than that, we can just use fontconfig 2.11.0 (current stable),
> or over when there will be. Fontconfig has the fix since 2.11.0.
>
> Could we make sure the same process is applied for the Windows
> nightbuilds (which use the patches in build/windows/) and the releases
> (which apparently do not)? That makes it less useful to have
> nightbuilds if we don't even provide the same in a release!
>
> And can something be done for GIMP 2.8.8? Since it has just been out,
> and that's not a change in GIMP itself, can we update the Windows
> packages? Or once it is out, we say it is too late?
> Thanks!
>
> Jehan
>
>> 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] 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  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::vector data structures included in
> the  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, an

Re: [Gimp-developer] GIMP Icons

[Jehan Pagès]

Hi,

On Mon, Nov 11, 2013 at 5:42 PM, Andrew Pullins  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  about
> this. Direct link to my theme on my
> DeviantArt.

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] GIMP Icons

[Jehan Pagès]

Hi,

On Wed, Nov 13, 2013 at 1:59 AM, Andrew Pullins  wrote:
> I'm sorry I am usually much better at making bug reports.
>
>> Is it the last stable version (2.8.8)?
>
> I started having problems with 2.6 but then 2.8 fixed it. Then I had
> problems again but Ubuntu 13.04 fixed it. Or something.

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.

>> Does it crash on startup, or it first loads fine then crashes later on?
>
> Sorry yes it crashes on startup as soon as the splash loads would start
> running  algorithms.
>
>> Are you sure the themes are the cause of the crash? If you remove the
>> themes, it won't crash anymore?
>
> Yes it is the theme, sometimes you can load the theme and everything seems
> fine but other times It had crashed as soon as I changed the theme. Deleting
> the theme makes GIMP go back to normal. Try the theme again and it starts
> crashing again.
>
>> If you start from a terminal, when it crashes, do you see some error log
>> output?
>
> Never tryed that.
>
>> Some error output might help us.
>
> I don't know how to get this output errors but someone on deviant art posted
> this.

Just for your information: if you open a terminal and just type "gimp"
there, it will start GIMP, with the output "linked" to the terminal.
So if ever you encounter error, they would be printed there.

>
> " White theme works for me (gimp 2.8.6 on arch linux), but the dark one
> fails with:
>
> [phwhitfield@underarch videonodes]$ gimp
> GEGL-geglmodule.c-Message: Module '/usr/lib/gegl-0.2/ff-load.so' load error:
> /usr/lib/gegl-0.2/ff-load.so: undefined symbol: avcodec_open

This one is probably not the reason of the crash (because this is code
to process videos, but I doubt that GIMP is making much use of this,
actually I'm sure, since I can see we are not using this operation),
but I note that there is a packaging error in GEGL on Ubuntu. Maybe a
version issue of libav (or simply one of the many problems that we
have everywhere since the libav/ffmpeg fork war).

> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:69: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-tool-foreground-select-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:70: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-tool-foreground-select-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:71: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-tool-foreground-select-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:82: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-vertical-22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:83: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-vertical-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:84: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-vertical-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:85: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-vertical-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:89: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-horizontal-22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:90: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-horizontal-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:91: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-horizontal-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:92: Unable to locate
> image file in pixmap_path: "images/tools/stock-flip-horizontal-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:96: Unable to locate
> image file in pixmap_path: "images/tools/stock-histogram-22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:97: Unable to locate
> image file in pixmap_path: "images/tools/stock-histogram-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:98: Unable to locate
> image file in pixmap_path: "images/tools/stock-histogram-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:99: Unable to locate
> image file in pixmap_path: "images/tools/stock-histogram-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:103: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-color-pick-from-screen-22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:104: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-color-pick-from-screen-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:105: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-color-pick-from-screen-c22.svg"
> /home/phwhitfield/.gimp-2.8/themes/Flat-Dark/imagerc:106: Unable to locate
> image file in pixmap_path:
> "images/tools/stock-color-p

Re: [Gimp-developer] Quick-edit workflow

[Jehan Pagès]

Hi,

On Sun, Nov 10, 2013 at 2:25 PM, peter sikking  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  wrote:
> Hi,
>
> On Sun, Nov 10, 2013 at 2:25 PM, peter sikking  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

[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  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"
>

Re: [Gimp-developer] Quick-edit workflow

[Jehan Pagès]

Hi,

On Wed, Nov 13, 2013 at 11:49 PM, peter sikking  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:
>
> 
>
> 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  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

[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
 wrote:
> This was replied to just me, so I'm forwarding it to the entire list.

Thanks Michael.

>
> -- Forwarded message --
> From: Andrew Pullins 
> Date: Thu, Nov 14, 2013 at 2:15 AM
> Subject: Re: [Gimp-developer] GIMP Icons
> To: Michael Henning 
>
>
>
>> > 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
 wrote:
> Hi,
>
> On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning
>  wrote:
>> This was replied to just me, so I'm forwarding it to the entire list.
>
> Thanks Michael.
>
>>
>> -- Forwarded message --
>> From: Andrew Pullins 
>> Date: Thu, Nov 14, 2013 at 2:15 AM
>> Subject: Re: [Gimp-developer] GIMP Icons
>> To: Michael Henning 
>>
>>
>>
>>> > 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

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, Nov 18, 2013 at 12:09 PM, DeVonte Applewhite  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 are trying to add a new feature to Gimp. It will be something small,
> but we still want to do something that will be interesting. We were thinking
> of looking into the filters or brush shapes to see what can come of that.

I understand that bug fixes are not sexy and you want something cooler. :-)
Well there are so many wanted features that it is hard to give advice.
About brush, I know there are some plans on supporting more brush
engine (in particular by using libmypaint, if not mistaken). Maybe
that's a path to follow if you want to improve brushes?
You may have an idea of the biggest planned features there:
http://wiki.gimp.org/index.php/Roadmap
Though if you have other ideas, we are always happy to consider
interesting new concepts.

But the best would be to come on GIMP's IRC where most of the devs are
hanging around (respectively in their timezones): #gimp on
irc.gimp.org
There you may ask questions if you have any, if you don't understand
something, or want to propose, etc.

> We understand that this will not increase the speed of Gimp, but it may be
> something else entirely that may be helpful to someone by chance (as we said
> in our initial plan).
>
> Thanks for this dialogue. It has been quite helpful to us moving forward.

You are welcome. Don't hesitate to come hang around on IRC. There is
no reason to just stop the dialogue. :-)
In any case, for the sake of the class, I understand that you have to
work fast and just implement "something to show your teacher". In this
respect you may not care too much about discussing too much about the
best approach and waste time. If that is the case, I fully understand.
Just be aware that some things are doomed from the start though (like
rewriting base class in C++ as you propose) if the goal is also to
merge upstream. Since I find it sad to waste good work and would
definitely prefer to see new contributors with upstream patches, well
I want to make sure you got this part.
In any case, have fun GIMPing! And maybe see you on IRC. :-)

Jehan

> Have a great day.
>
>
> On Tue, Nov 12, 2013 at 4:39 AM, Jehan Pagès 
> wrote:
>>
>> Hi,
>>
>> On Tue, Nov 12, 2013 at 5:30 PM, DeVonte Applewhite 
>> 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 kin

Re: [Gimp-developer] Virus in Windows last version of GIMP ?

[Jehan Pagès]

Hi,

On Tue, Nov 19, 2013 at 8:50 PM,   wrote:
>
>
> - Mail original -
> De: "Michael Schumacher" 
> À: gimp-developer-list@gnome.org
> Envoyé: Lundi 18 Novembre 2013 20:14:11
> Objet: Re: [Gimp-developer] Virus in Windows last version of GIMP ?
>
> On 18.11.2013 17:19, david.vantyg...@free.fr wrote:
>
>> Hello,
>>
>> I downloaded http://ftp.gimp.org/pub/gimp/v2.8/windows/gimp-2.8.8-setup.exe 
>> and installed on a Windows 2003 server.
>> Last version of ClamWin Portable detects a virus :
>
>>Attachments are discarded on this list.
>>You could submit the installer file to ClamAV to have them check it for
>>a false positive: http://cgi.clamav.net/sendvirus.cgi
>
> How do you know that it is not a true virus ? Perhaps it is a NSA Trojan ?

Well then if you send it to the ClamAV company, they can check. That's
the whole point of this page.
As they write on it, when you send a false positive, they would review
it to check if it is really a false positive or an actual virus. They
don't trust you on parole.
Regards,

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

[Jehan Pagès]

Hi jEsuSdA,

On Wed, Nov 6, 2013 at 5:08 AM, jEsuSdA 8)  wrote:
> El 05/11/13 16:59, scl escribió:
>
>>
>> Hi,
>>
>> Jakub Steiner answered me.
>> He and Barbara Muraus (the other icon designer who
>> created the ArtLibre icon set) are ok with relicensing
>> it under the GPLv3. We agreed to mention their names
>> in the sources.
>>
>> Jehan, if you have planned to work on this, please
>> let me know to save us from duplication of work ;-)
>>
>> Kind regards,
>>
>> Sven
>
>
>
> Great news, Sven!
>
> If you need any help I can give you, please let me know.

Today I've wanted to actually check the theme and see how it is, other
than as a screenshot. Your archive found in
http://www.jesusda.com/files/symbolic-gimp.7z is the last version?
Also it looks like it comprises only the icons for the light
background theme, doesn't it?
Where are the original light icons for a dark background theme?

Regards,

Jehan

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

Re: [Gimp-developer] Fwd: GIMP Icons

[Jehan Pagès]

Hi,

On Wed, Nov 27, 2013 at 8:23 AM, Andrew Pullins  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 
> wrote:
>>
>> I have GIMP 2.8.8 installed on Ubuntu 13.10
>>
>>
>> On Sun, Nov 17, 2013 at 7:22 PM, Andrew Pullins 
>> 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" 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Mon, Nov 18, 2013 at 10:39 AM, Andrew Pullins 
>>>> 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  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 Tue, Nov 26, 2013 at 2:27 AM, jEsuSdA 8)  wrote:
> El 25/11/13 07:05, Jehan Pagès escribió:
>> Also it looks like it comprises only the icons for the light
>> background theme, doesn't it?
>
>
>
> Here the light one:
>
> http://www.jesusda.com/files/symbolic-gimp_light.7z

Thanks jEsuSdA!

On Wed, Nov 6, 2013 at 11:13 AM, Jehan Pagès  wrote:
> Hi,
>
> On Wed, Nov 6, 2013 at 4:59 AM, scl  wrote:
>>
>> Hi,
>>
>> Jakub Steiner answered me.
>> He and Barbara Muraus (the other icon designer who
>> created the ArtLibre icon set) are ok with relicensing
>> it under the GPLv3. We agreed to mention their names
>> in the sources.
>>
>> Jehan, if you have planned to work on this, please
>> let me know to save us from duplication of work ;-)
>
> No, no prob, go on. I'm not planning to do any work that someone else
> is willing to do instead. :p

Actually Sven, I was thinking if you would mind if I set up a feature
branch for this? I have already started to have a look now, and also
already fixed some bug on the darken images.

I will also set up the wiki page that you wished, so that we can all
work together. Is it good?

I have a friend who wants to help to complete the missing stock icons.
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?

Jehan

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

[Jehan Pagès]

Hi,

On Wed, Nov 27, 2013 at 8:24 PM, jEsuSdA 8)  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

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

[Jehan Pagès]

On Wed, Nov 27, 2013 at 5:16 PM, Alexandre Prokoudine
 wrote:
> 27 нояб. 2013 г. 5:14 пользователь "Jehan Pagès" 
> написал:
>
>>
>> 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?
>
> I think you deserve Medal of Honour, sir :)

Hahaha. Well let's hope that others agree then.
It would be good to have a better release organization.

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

[Jehan Pagès]

Hi,

On Thu, Nov 28, 2013 at 8:01 PM, scl  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] Setting Up a Release Procedure

[Jehan Pagès]

Hi,

It was sent to me only. I imagine that's a small mistake, so I'll
answer back to the whole list. :-)

On Fri, Nov 29, 2013 at 7:41 AM, scl  wrote:
> Hi Jehan,
>
> I am ... impressed ;-)
>
> Yes, the release procedure is something that has potential to improve
> and I'm happy you took the time and elaborated a procedure.
> I fully agree with you that we need more testing before a release.
> As yet I had a glance over your proposal and hope I will find more time
> next for a more comprehensive answer. Currently I'm fully stretched
> with real life tasks, getting a deeper understanding of the color topic,
> the UI theme and Jenkins.

Well actually the 4 main points are:
1/ testing: right now, releases are sudden, out of nowhere, and we
discover release issues afterwards. Not only program bugs, but really
release bugs (like the fontconfig ones on Windows). Seriously if the
Windows package had been first released in beta, I would have tested
these specific fontconfig issues (because I spent quite some time
trying to debug these), and would have reported them immediately (so
they would not have happened in the finale release).
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.
3/ No knowledge passing down: even though everyone knows how to
compile GIMP, it looks only the package maintainers know how to make
OSX/Windows installers (each with its different procedure). First it
means I can't make a package for testing. But even if it were made
very easy to produce installers, we could even propose users to test
fixes and debug versions on Bugzilla when we are trying to debug
issues. Right now we are totally dependent, and if the packagers
disappear, we have to guess the procedure from the start.
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. On the other hand,
all together, I know we can simplify complicated tasks a lot. With
scripts, automatization, and sharing work. That's what usually happens
when a lot of tech people work together. Ideally it should be so easy
to package a new version with a simple command, we go get a coffee and
get back in 2 minutes and... tadaa!!

> Eventually the procedure should find Mitch's agreement.

Of course. I just wanted to give a little push. Because just saying it
would make nobody move, I feel. Maybe starting with a wiki page ready
to be filled by the various packagers could be a small first start to
collaborate (since people like wiki). Of course if nobody cares, well
it will just stay a dead wish and I'll remove the pages in some time.

> BTW: Thanks for the compliments about the benevolent maintainer.
> I wasn't aware that I am seen as a maintainer like Mitch
> (who is our real code guru here ;-), am I? Let's also not forget

Oh right. I just checked again. In the AUTHORS page, there is actually
a Sven Neumann as maintainer alongside Mitch. I actually realize I
made a mistake, because that's another Sven! And since I don't see him
much (I think, but with people's nickname, maybe I do!), I assumed it
was you and did not pay attention to the family name. :p Well good you
took it well. Hopefully nobody took it bad too!

> our eager packagers Jernej, Drawoc, Clayton, Simone and Partha ;-)

Of course, I have listed them in the wiki page for instance. :-) I
completely understand that each individual enjoys being a maintainer —
and thus the main actor! — on their own piece of code (the
installers). And that's great, but that's also the reason I fear some
might not like work together and share the title. Maybe? In any case,
I really wish everyone could be happy by still being more efficient
together. That's the goal. And I really hope we can reach it.

Anyway let's wait and see how it goes.

Jehan

>
> Greetings,
>
> 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] 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] Setting Up a Release Procedure

[Jehan Pagès]

Hi,

On Sat, Nov 30, 2013 at 11:37 PM, Simone Karin Lehmann
 wrote:
>
> Am 28.11.2013 um 22:25 schrieb Jehan Pagès :
> Hi,
>
>> Well actually the 4 main points are:
>> 1/ testing: right now, releases are sudden, out of nowhere, and we
>> discover release issues afterwards.
>
> yes, we really need a test cycle before a release goes public. Especially if 
> there’s not only a new GIMP source, but a new OS version as well, like it is 
> on OS X. I just discovered a new bug, which is IMO release critical. On OS X 
> Mavericks, the pencil and brushes outline doesn’t show, so it’s almost 
> impossible to paint, clone and brush.
>

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  wrote:
> Hi,
>
> Am 30.11.2013 um 12:26 schrieb Jehan Pagès :
>
>> Well... that's why I was proposing testing and collaborating *before*
>> releasing, and not after. :-/
>
> yes. Sadly, now the „no-outline-issue“ is another showstopper.
>
>
>>> It’s not about building. I wrote a couple of scripts which automates that 
>>> quite well. But in the last years I’ve made a lot of OS X specific patches 
>>> (don’t ask, why some of them are not upstream…. long story) and making a 
>>> new release requires to adapt these patches and to test if the are still 
>>> needed and if they still fix the addressed issue. Two examples:  years ago 
>>> on X11 it took me for ages to fix the file chooser sorting bug. Well, on 
>>> Mavericks it’s back again. Second: using the Cocoa based version of 
>>> gtk-mac-integration to get properly working menus and keyboard shortcuts.
>>>
>>
>> Well that would still be a lot better for the users *and* for you if
>> we could all collaborate. If these patchs on third party are really
>> necessary to prevent major bugs, we'll appreciate having them in our
>> source tree as well (we have a directory build/osx/ where we save
>> build-specific data, like third-party software patches).
>
> yes, I’ll share them. But IMO this needs to get committed about what build 
> system we use on OS X. Clayton uses jhbuild. I use a slightly hacked version 
> of MacPorts and some bash scripts to ease the process of building on 
> Mavericks down to SnowLeopard and even cross compile to 32bit and it helps me 
> manage about 100 packages needed to build my bundles. As far as I’m 
> concerned, I’d like to stay with that and not to switch to something else I’m 
> not used to and from what I don’t know if it fits my needs and gives me all 
> functionality I already have.
>

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 intere

[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  wrote:
> On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann  
> 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] Fwd: GIMP Icons

[Jehan Pagès]

Hi,

On Mon, Nov 18, 2013 at 1:06 AM, Jehan Pagès  wrote:
> Hi again,
>
> On Mon, Nov 18, 2013 at 12:25 AM, Jehan Pagès
>  wrote:
>> Hi,
>>
>> On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning
>>  wrote:
>>> This was replied to just me, so I'm forwarding it to the entire list.
>>
>> Thanks Michael.
>>
>>>
>>> -- Forwarded message --
>>> From: Andrew Pullins 
>>> Date: Thu, Nov 14, 2013 at 2:15 AM
>>> Subject: Re: [Gimp-developer] GIMP Icons
>>> To: Michael Henning 
>>>
>>>
>>>
>>>> > 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  wrote:
> Hi Sven,
>
> Have been away for the Thanksgiving holidays.:)
>
> On Sun, Nov 24, 2013 at 4:59 AM, scl  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  wrote:
> Hi,
>
> On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi  wrote:
>> Hi Sven,
>>
>> Have been away for the Thanksgiving holidays.:)
>>
>> On Sun, Nov 24, 2013 at 4:59 AM, scl  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

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  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  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 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Nov 18, 2013 at 12:09 PM, DeVonte Applewhite 
>>> 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
>>> hi

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  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  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 
> wrote:
>>
>> Hi again!
>>
>> On Thu, Dec 5, 2013 at 12:42 PM, Jehan Pagès 
>> wrote:
>> > Hi,
>> >
>> > On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi 
>> > wrote:
>> >> Hi Sven,
>> >>
>> >> Have been away for the Thanksgiving holidays.:)
>> >>
>> >> On Sun, Nov 24, 2013 at 4:59 AM, scl  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

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

[Jehan Pagès]

Hi,

On Tue, Dec 10, 2013 at 5:00 AM, Sam Gleske  wrote:
> On Mon, Dec 2, 2013 at 11:09 AM, Sam Gleske  wrote:
>
>> What are the Windows packagers using for the build?  If they're using a
>> proprietary package system I suggest moving to a more open one such as NSIS
>> and customizing that.  Windows builds can easily be automated using NSIS.
>> Another advantage of using NSIS is checking the scriptable installer code
>> into SCM.
>>
>
> Does this mean that nobody on this list knows what the release process is
> on Windows for building installers?

As Michael answered too, of course we have people in charge of the
Windows release procedure. Simply I am hoping we can improve it by
merging efforts, since several people are also known to do their own
quality release outside us. And our procedure is far from perfect. I
wish it were more systematic and without a fault.

But we do have an existing procedure since we do have releases and
code for it in our repo. And we are slowly improving it (for instance
you may have noticed the recent improvement: now all releases go in
the ftp, instead of using a third party provider).

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

[Gimp-developer] Question about fixes on your 2.8.10 release

[Jehan Pagès]

Hi Simone,

We have a user in GIMP who says he encountered a bug which prevented
him to paint along selection/path on OSX with our 2.8.10 build.

But he says that he does not have this bug on your 2.8.10 build.
Since I can't see what this can be about (this seems to be a different
bug as the brush outline thingy), thus whether we fixed it or not, I
was wondering if you know about this bug. Is it something you fixed on
your build and that we would still have in our tree maybe? If so,
would you please provide us with the patch? I don't see a new patch
for such a bug in your subversion repository.

If not, well I don't know. Has anyone experienced such a problem with
our build on OSX?
Thanks a lot.

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

Re: [Gimp-developer] Question about fixes on your 2.8.10 release

[Jehan Pagès]

Hi,

Nevermind. It turned out this was actually fixed with the same commit
as the brush outline bug. That's why.

Jehan


On Thu, Dec 12, 2013 at 7:26 PM, Jehan Pagès  wrote:
> Hi Simone,
>
> We have a user in GIMP who says he encountered a bug which prevented
> him to paint along selection/path on OSX with our 2.8.10 build.
>
> But he says that he does not have this bug on your 2.8.10 build.
> Since I can't see what this can be about (this seems to be a different
> bug as the brush outline thingy), thus whether we fixed it or not, I
> was wondering if you know about this bug. Is it something you fixed on
> your build and that we would still have in our tree maybe? If so,
> would you please provide us with the patch? I don't see a new patch
> for such a bug in your subversion repository.
>
> If not, well I don't know. Has anyone experienced such a problem with
> our build on OSX?
> Thanks a lot.
>
> Jehan
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hi Peter, and all,

Wow this created quite a discussion. I am on the road, so I have just
been skimming through the whole thread, and I will answer to the
first.

On Wed, Jan 15, 2014 at 7:52 AM, peter sikking  wrote:
> Srihari Sriraman wrote:
>
>> Have we had a chance to look into this?
>>
>> On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pagès  
>> wrote:
>> 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).
>>
>> 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.
>
> OK, I have looked at that spec.
>
> then I thought about it for hours, and here is why:
>
> this thing is still giving me a serious stomach ache
>
> (I hope you guys realise that when something that is 100% UI
> gives me a stomach ache, that is quite significant)
>
> even trying to explain to you (and me) why this gives me
> a stomach ache, gives me a stomach ache.
>
> I could talk long or short about all its aspects, but
> I have decided to cut it short and tell you this about it:
> when I read the spec or think about TITo, this comes to my
> mind, second by second:
>
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
> ‘that is OKish, give these guys a break’
> ‘that is awful, completely misguided’
>
> so after hours of thinking I have come to this conclusion:
>
> the problem with TITo is that as it stands now it is a
> conflicted mix of two intentions:
>
> 1) a help system via text search to learn using GIMP
>
> 2) a command-line system for operating GIMP

This is none of them. This is a search tool through available
contextual commands. So that's kind of 1) "help system", but not with
"learning" as intent. Only with "searching" as intent (you may
"discover" some commands or filters of course, but that would be a
happy coincidence, same as when you may discover these same filters by
wandering in menus. There is no learning intent at all in this tool).

And this is definitely not a command line system. At least, when I
hear "command line", I would usually hear "language script". Here
that's just a list of commands, and you can search through them.
This is, in 2 words, a "search tool".

> some note:
>
> - yes, for me 1) maps to ‘give these guys a break’ and 2) to
>  ‘completely misguided’ sort term _and_ long term;
> - if you are serious about “Text-based Intent driven Tool”
>  then you have to build a synonym list for all keywords,
>  in all localisations; else you are just bluffing;

I am pretty sure that this was written in the bugzilla thread: the
name "TITo" is only a working name. Actually I am very careful to
never use it when I present the tool (the original email I wrote was
titled "Search Action dialog tool", and I think I did not say tito
anywhere in it, except as a git branch name). This name was originally
given by the original contributor (Srihari), but it does *not* exist
anymore. There is absolutely no "tito" written anywhere in our code. I
even wrote in the spec «The "tito" feature would be named more
generically: "Action Search" »

So please do not focus on this name. This is only a code and it is
non-existing in GIMP. If this name makes you uneasy, just don't use
it, just as I do (I always say the "action search tool").
And we do not plan on creating "synonyms" for any command in all
localizations! uhuh :p

> - with different people working on it, I suspect they have
>  different intentions, or are conflicted internally themselves;
> - since TITo is right now a random mix of 1) and 2), it is
>  really not working for either intentions; things implemented for
>  1) get in the way of 2) (and vice versa);

As said above, this is neither 1) nor 2). Really this is a very common
UI tool. I can see the same feature in blender (they call it the
"space menu"). And my program menu in my desktop has the exact same
tool. When I want to start a program, instead of searching through
submenus (which may have a huge list since a lot of programs are
installed), I can just type the name of the program and it finds it
for me.
So if I want to find GIMP in my application menu, I just type "gimp"
in the search. Even bet

Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hi,

On Mon, Jan 20, 2014 at 9:53 AM, peter sikking  wrote:
> Sven,
>
> I appreciate that you want to mediate to make things go forward.
>
>> Srihari has brought up this topic often and informed about
>> the progress. Many people, including Peter, joined the
>> discussion and the purpose was already discussed.
>> So, many things are not really new.
>
> as things stand right now, the biggest thing that is wrong
> with TITo is that there seems to be no underlying purpose.
> lacking this it is a rather jumbled combination of features,
> which exactly expresses this purposelessness.
>
> if the purpose of TITo is so clear, then tell me what it is,
> including a few words why it is valuable for GIMP users.
>
> (anybody can contribute to this, it is just that
> Srihari and Jehan have to the final say on this definition,
> that is the right they earned by putting in the bulk of the
> code contribution)

Well I did already answer this. The "action search" tool is a...
search tool. This allows to search for and run commands in a natural
way (with natural language text). This is none of the 2 other
hypothesis you thought.

As for use cases, most other people in this thread exposed their own
experience with searching tools, plugins and filters in GIMP. There is
not much to add. I am the same, I always search various tools, which I
know exist but can't find anymore. And I use this exact same feature
daily, as said earlier, to search programs in my desktop OS
(apparently I read there is even the same feature in Windows start
menu too), or in Firefox. And that's damn useful.

Moreover this tool really does not go in the way of anyone. If you
don't want to use it, it won't bother the user. It won't change a
thing and you could go for years without ever running it and have the
exact same experience as now. But for anyone who likes text search
(which is really the way many UIs go since the appearance of web
search engines), this can be a very nice tool. So I really don't see
why you would block the feature to go forward.
Thanks.

Jehan


> I give you an example, so you know what I am asking for:
>
> ‘the Undo system is valuable to GIMP users because it
> allows them to proceed without fear (of doing something wrong).’
>
> you see I defined Undo not by its functionality, but
> by what it means to users.
>
>
> people have already asked me: ‘just say what should be changed
> about TITo.’
>
> I can tell you, once I know what it should be.
>
>
> --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
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hi,

On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer  wrote:
> On Tue, 2014-01-21 at 00:10 +0100, peter sikking wrote:
>
>> 1) you say “action search tool.” is it not menu item search tool?
>> an _action_ search would search the toolbox tools, the layer
>> stack and all dockable dialogs too (the latter being super useful).
>
> "action" is meant as technical term here. A menu item is a view
> on an internal action, and they include:
>
> - all menu items
> - all tools
> - all menu-invokable dialogs
> - some esoteric stuff which we'd probably filter out to avoid confusion

Indeed.

>> 2) you say “natural language text,” the definition of which is
>> very wooly. similar as with ‘Text-based Intent driven Tool’ it
>> promises way too much (e.g. user types in “blown highlights” and
>> TITo responds with “burn tool”). you need to be very precise in
>> defining how sophisticated you want to be here (want to be, not
>> describing the actual bit you do right now).
>
> Please let's forget about the name "TITO", it was a bad choice
> to begin with.

Yes! Please all, stop saying "tito", especially if that confuses you.
TITO does not exist. This is an action search.

> This is about searching whatever text is associated
> with the action:
>
> - its name (as in technical name e.g. "file-open")
> - its label (e.g. "Open...")
> - its tooltip (e.g. "Open a file blah foo")
> - with a little effort all those things both in the
>   english original and the translated local language

Exactly! I don't think we search the technical name in the current
implementation though (usually words in the name as also in the label
and/or tooltip; also the technical name may not be appropriate and
won't be localized), but this can easily be done if someone really
thinks it may be needed. In any case, we search the label and the
tooltip. And localization already works. So if you have a French GIMP,
you won't search for "blur" but for "flou".

There is no "too much" intelligence, and I don't think there will be,
because that may mean too much work. There is still some minimum
processing and that works already quite good.

I only said "natural language" because the user can search with words
of one's chosen language, not technicalities: no shortcut, no menu, no
action name, just words. I did not mean any advanced natural language
processing technics.

So you can't get the burn tool with “blown highlights” because such
words are not in our description of the tool. But if you search
"darken" or "lighten" or even "darken light", the search will answer
with the burn tool.

> This is for initially finding the action, and this is the
> current state of affairs. Currently we are only talking about
> invoking the found action and should probably restrict the
> discussion to that, or it will get out of hand (like, let's
> not go into passing whatever parameters in that search entry)

I agree.

> However, what we IMO could talk about is having a little "help"
> button/icon in each row of the search results, for the case where
> searching "foo" gives you some results, and you'd rather look them
> up in help before applying them to your image.

That's an interesting proposition, indeed.

Jehan

P.S.: for Sven, I am on the road and have random internet access, so I
can't really meet on IRC meetings with certaincy. Email is the way to
go for now. :-)

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

Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hi,

On Thu, Jan 23, 2014 at 5:10 AM, peter sikking  wrote:
> Jehan,
>
> let me first of all say this in general about the process we are
> doing. at this moment I feel we are still working backwards, i.e.
> you are answering to me what the code does.
>
> we have to work forward, else there will be no progress.
>
> this means we write down the goal/purpose/vision that you have
> for TITo (sorry, internal code name still rocks for discussions).
> you make the choices, I just make sure that what we end up with
> 1) makes sense in  GIMP context
> 2) is internally consistent
> 3) is short, sharp and complete
>
> once we got this goal written down, it is possible to
> review the spec to see what is missing and what is getting
> in the way of the goal.
>
>> On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer  wrote:
>>> On Tue, 2014-01-21 at 00:10 +0100, peter sikking wrote:
>>>
 1) you say “action search tool.” is it not menu item search tool?
 an _action_ search would search the toolbox tools, the layer
 stack and all dockable dialogs too (the latter being super useful).
>>> "action" is meant as technical term here. A menu item is a view
>>> on an internal action, and they include:
>>> - all menu items
>>> - all tools
>>> - all menu-invokable dialogs
>>> - some esoteric stuff which we'd probably filter out to avoid confusion
>> Indeed.
>
> if I read that right it still boils down to that you only want to
> search menu items. this needs to be called that way for clarification.

No. As said above, actions are *not* just menu items. There are a wide
list of commands that Mitch listed above.

> now if I am wrong, and you do want to be able to search more
> like am the ‘actions’ in the dockable dialogs
> (example: Brushes dialog->Create a new brush) then you need to
> make that clear explicitly.

Well, yes. We made it clear by saying we search all actions. :-)

>
 2) you say “natural language text,” the definition of which is
 very wooly. similar as with ‘Text-based Intent driven Tool’ it
 promises way too much (e.g. user types in “blown highlights” and
 TITo responds with “burn tool”). you need to be very precise in
 defining how sophisticated you want to be here (want to be, not
 describing the actual bit you do right now).
>>>
>>> Please let's forget about the name "TITO", it was a bad choice
>>> to begin with.
>>
>> Yes! Please all, stop saying "tito", especially if that confuses you.
>> TITO does not exist. This is an action search.
>
> I am not confused.
>
> you said “natural language text,” and I told you that is a huge
> can of worms if you put that in you goal.
>
> I think it is best to say “text search” for now. interim version:
>
>
> “The "action search" tool allows to search for, and run, menu items via text 
> search. It is for searching tools, plugins and filters in GIMP when one knows 
> they exist but can't find anymore.”
>
>
> it is better now to concentrate on _all_ the reasons you
> want this to be useful for GIMP users.
>
> now is the time for you to decide whether ‘when one knows they
> exist but can't find anymore’ is the one and only reason TITo
> is valuable/useful for GIMP users. if there is more, you have
> to clarify that mow.

No it is not the "only" reason. This was more an example, thus an
error on my side to cite here. The real goal is «searching and
running» actions. And this by itself contains all the reasons I think
it is useful for. Now "searching" can imply a lot of sub-reasons. The
«I know this action exists (because I used it before, for instance)
and I want to find it again» would indeed be a typical one. Another
would be «I don't know GIMP by heart, but I know graphics editing, and
there are usually blur effects. So instead of going through endless
menus, I open the search and type "blur" and search through the 3/4
results I get».
It would contain any other reason why one would want to *search*
through available actions.

Thus, this is an "action search" tool. The goal is to *search and run*
through all available actions.

Jehan

>
> thanks,
>
> --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
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès]

Hi,

On Tue, Jan 28, 2014 at 10:23 AM, peter sikking  wrote:
> (first of all I think all blur examples have to be banned. there
> is nothing to search about blur, it is under Filters->blur, end
> of story. if it is not clear that it is to be found in the Filters
> menu, or as a toolbox tool, then this user needs an introductory
> course in GIMP, which can (today) only be delivered by a web browser
> or a book.)

I completely disagree. You may know where it is but still prefer to
get it through the search. This is like 10 times faster and easier.
Seriously this search dialog would be already in GIMP master, I would
use it for most of the features actually. This makes things so much
easier and the use of GIMP so fluider.

Same as my program application list. I know where most of the apps I
installed are, but I nearly never use the menus anymore. I use the
search atop the menu. Why would I bother searching through menus and
submenus when by typing 2, 3 or 4 keys (in natural language of what I
search, not shortcuts, nothing to memorize) at most I get the app I
need?

Apparently also same as GNOME shell (never used, but dixit Mitch in
another email). Same as what Windows does now too (also never used
this, but someone said in another email too), same as Blender.
That's just too useful. *Even for experts*. Even when you know exactly
where each item is.

> anyway, GIMP is a designed to be a tool for masters, or for
> users on their path to become a master (beginners, intermediates).
> any other use is not considered when designing the UI.
>
> so if someone comes to GIMP (s)he is either a master in another
> graphics app, or not. in the latter case (s)he can be considered
> and helped, as a beginner or intermediate GIMP user.
>
> from this there are 2 conclusions:
>
> - we really need to talk about how you envision TITo being useful for
>  GIMP masters, beginners and intermediates; most of this will
>  involve learning to use GIMP;
> - that leaves only masters of other programs coming to GIMP to
>  consider in this discussion.
>
> since they are masters in another programme the will hate not
> being all-powerful in GIMP. so they will want to master GIMP
> as fast as they can (think of it as grokking).
>
> - for all the terms that GIMP has in common with other graphics
>  programs (blur, dodge, fill, paint) the value of searching
>  for them will be nearly zero, they are placed where they belong.

As explained above, I *completely* disagree.

> - the terms that GIMP does not have in common with all other
>  graphics programs need a synonym list, a mapping between the
>  non-GIMP terms in other programs to the GIMP term;

I agree, this would be a very nice thing. And that's what Srihari said
was one of his original plans.

Now this is a huge work. Someone would work full-time on it, yeah it
could take only a few days to have a demo version, but then weeks to
have a *real* stable bug-less version for quality testing and release.

Such a feature implies gathering the data (list of words to get
synonyms for, then list of synonyms in every languages). And
development-wise, to do this feature really well (and not half-baked),
we would have to do at the very minimum tokenization and lexemization,
which implies at least some basic lexical analyzis, which is
language-dependant.

The only word processing I do right now (already implemented) is basic
word-tokenization, which implies that "gaussian blur" as well as "blur
gaussian" would both return gaussian blur, but also that spaces are
irrelevant to a search. But even this current implementation is basic
and would work well mostly for languages where space characters are
token separators (tokenization for non-spaced languages like Japanese
or Chinese are a lot more complicated, and involve machine training;
and not to mention languages which are only partially agglutinative,
like German, which make them also quite particular to tokenize).

But well we don't have full-time developers, and there is also the
priority problem (that's nice, but it may be better to have other
things worked on, no?). Is it really worth to work for weeks on this
when we already have something still quite good?

Moreover I would recommend third-party language analysis dependencies
(libraries) for some parts of the text analysis, rather than
developing all ourselves, and a bunch of text data to embed in our
software. I'm not sure that's ideal.

And honestly, I would love to work on this all, advanced language
processing and all. These kind of things have been my university major
(Artificial Intelligence, Intelligent Multimedia, etc.), also I love
linguistics, I have done any of these things at least once in my life,
and I have worked on these topics in a startup which was working on
translation. I would really enjoy to do it again. But I am also
realistic and I don't think this is prioritary for GIMP and that we
should waste weeks on being as performant as Google (which reached
this quality with thous

Re: [Gimp-developer] N-Point Image Deformation queries

[Jehan Pagès]

Hi Marek,

On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak  wrote:
> Hello,
>
> I see that there (on IRC) has been some queries on n-point deformation
> recently. I'll try to bring some transparency to it.

Thanks for all your great work. I was just wondering how it was
getting along. :-)

This feature is really neat and each time I try the branch, I love it
more and more.
Also a small stupid question: when I try the current version, the grid
is "printed" onto the canvas after a deformation, which is likely not
intended. Is there a reason for this? Testing maybe? I wanted to try
and use the feature a little for experimentation but could not find
how to disable this grid printing.

Anyway hope we'll get more news soon. :-)

Jehan

> I'm currently quite a lot busy, but in my free time I try to work on the
> deformation tool at least a bit. For example I've recently integrated a
> lattice cutting algorithm that I devised during GSOC. In a lot of
> situations it allows user to set a larger square size of lattice and
> still be able to manipulate with articulated parts of an image. The
> algorithm can be made even smarter, that's one of my plans for the
> future.
>
> GEGL part of n-point-deformation
> 
> I was creating the library in a way so that it was the most independent
> (especially on "display" library). I wanted to use it (and I use it)
> with Allegro library as well as with GEGL. If is that possible, I would
> like it to stay as independent as possible so that I can maintain and
> refine just one source code.
>
> The library is separated into computational part (deformation.[ch]),
> graphics part (graphics.[ch]), GEGL part (npd_gegl.[ch]) and other
> rutines.
>
> Graphics part contains graphics rutines that are not dependent on any
> graphics library. When somebody wants to use the library with some
> graphics library he is expected to implement some graphics functions
> (get_pixel, set_pixel, draw_line) and some structures (_NPDImage,
> _NPDDisplay). NPD operation does it this way.
>
> GEGL part should contain these implementations of majority of needed
> graphics functions and structures due to the fact that these
> implementations can be useful when somebody would like to use them from
> more then one place (for example in two partialy different GEGL
> operations).
>
> About NPD operation. It currently operates in 'RGBA u8' format which is
> suitable for a preview of the deformation. Generation of the preview
> should be as fast as possible - it currently uses graphics techniques
> implemented in graphics part of the library. I have partialy implemented
> a version of NPD operation that produces absolute coordinate buffer in
> floats. When we connect it to map-absolute operation we can get a better
> interpolated result and in 'RGBA float' format.
>
> GIMP part of n-point deformation
> 
> During GSOC I wanted to use mentioned GEGL operation for a preview of
> the deformation process in GIMP NPD tool and I also wanted to use some
> functions (e.g. to manipulate with points) and share some structures. I
> decided to make shared library and bundle it with GEGL because it showed
> up that it was an easy way - because GIMP uses GEGL (and 'seamless
> clone' does it similarly).
>
> At the beginning of implementation of NPD tool, the tool directly
> modified image's GEGL buffer and forced the image to redraw itself. That
> was just for testing reasons and, of course, it was slow. It showed up
> that it was needed to draw on canvas using Cairo - similarly as
> Transform Tools do it. I use GimpCanvasBufferPreview class for it.
>
> Things to do (among others)
> ---
> - Solve deformation of large images - The deformation is currently slow
> on large images. It's due to the fact that it's needed to render the
> deformation of such an image serveral times per second. That is
> impossible. The solution is to render only what is contained in
> viewport.
> - Implement depth of control points so that user can adjust which part
> of overlapping mesh/image is visible.
>
> I hope that my thoughts about n-point deformation during GSOC are now
> clearer and that it's not a total nonsense.
>
> Regards,
> Marek
>
>
> ___
> 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
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] N-Point Image Deformation queries

[Jehan Pagès]

Hi again,

On Mon, Feb 3, 2014 at 2:39 PM, Jehan Pagès  wrote:
> Hi Marek,
>
> On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak  wrote:
>> Hello,
>>
>> I see that there (on IRC) has been some queries on n-point deformation
>> recently. I'll try to bring some transparency to it.
>
> Thanks for all your great work. I was just wondering how it was
> getting along. :-)
>
> This feature is really neat and each time I try the branch, I love it
> more and more.
> Also a small stupid question: when I try the current version, the grid
> is "printed" onto the canvas after a deformation, which is likely not
> intended. Is there a reason for this? Testing maybe? I wanted to try
> and use the feature a little for experimentation but could not find
> how to disable this grid printing.

Drawoc told me to use the npd-squashed GEGL branch (and not outdated
soc-2013-n-point-deformation), and it does not have the grid printing
anymore. So forget the question. Apparently the tool is close to a
mergeable state, at least on GEGL side, he also told, which is
awesome. :-)

Hope to see the full feature on master soon!

Jehan

>
> Anyway hope we'll get more news soon. :-)
>
> Jehan
>
>> I'm currently quite a lot busy, but in my free time I try to work on the
>> deformation tool at least a bit. For example I've recently integrated a
>> lattice cutting algorithm that I devised during GSOC. In a lot of
>> situations it allows user to set a larger square size of lattice and
>> still be able to manipulate with articulated parts of an image. The
>> algorithm can be made even smarter, that's one of my plans for the
>> future.
>>
>> GEGL part of n-point-deformation
>> 
>> I was creating the library in a way so that it was the most independent
>> (especially on "display" library). I wanted to use it (and I use it)
>> with Allegro library as well as with GEGL. If is that possible, I would
>> like it to stay as independent as possible so that I can maintain and
>> refine just one source code.
>>
>> The library is separated into computational part (deformation.[ch]),
>> graphics part (graphics.[ch]), GEGL part (npd_gegl.[ch]) and other
>> rutines.
>>
>> Graphics part contains graphics rutines that are not dependent on any
>> graphics library. When somebody wants to use the library with some
>> graphics library he is expected to implement some graphics functions
>> (get_pixel, set_pixel, draw_line) and some structures (_NPDImage,
>> _NPDDisplay). NPD operation does it this way.
>>
>> GEGL part should contain these implementations of majority of needed
>> graphics functions and structures due to the fact that these
>> implementations can be useful when somebody would like to use them from
>> more then one place (for example in two partialy different GEGL
>> operations).
>>
>> About NPD operation. It currently operates in 'RGBA u8' format which is
>> suitable for a preview of the deformation. Generation of the preview
>> should be as fast as possible - it currently uses graphics techniques
>> implemented in graphics part of the library. I have partialy implemented
>> a version of NPD operation that produces absolute coordinate buffer in
>> floats. When we connect it to map-absolute operation we can get a better
>> interpolated result and in 'RGBA float' format.
>>
>> GIMP part of n-point deformation
>> 
>> During GSOC I wanted to use mentioned GEGL operation for a preview of
>> the deformation process in GIMP NPD tool and I also wanted to use some
>> functions (e.g. to manipulate with points) and share some structures. I
>> decided to make shared library and bundle it with GEGL because it showed
>> up that it was an easy way - because GIMP uses GEGL (and 'seamless
>> clone' does it similarly).
>>
>> At the beginning of implementation of NPD tool, the tool directly
>> modified image's GEGL buffer and forced the image to redraw itself. That
>> was just for testing reasons and, of course, it was slow. It showed up
>> that it was needed to draw on canvas using Cairo - similarly as
>> Transform Tools do it. I use GimpCanvasBufferPreview class for it.
>>
>> Things to do (among others)
>> ---
>> - Solve deformation of large images - The deformation is currently slow
>> on large images. It's due to the fact that it's needed to render the
>> deformation of such an image serveral times per second. That is
>> impossible. The solution

Re: [Gimp-developer] GSoC, call for mentors

[Jehan Pagès]

Hi,

On Tue, Feb 4, 2014 at 11:05 AM, Alexandre Prokoudine
 wrote:
> Hi,
>
> It appears that I've got myself into administrating GSoC this year,
> with schumaml being backup admin :)
>
> I know that Jehan was interested in being a mentor, and I guess that
> mitch will be joining the fun, but I'm not sure that the idea of
> meta-mentors will be seen by Google all that appealing. So I'd like to
> get a better understanding where we stand:
>
> 1) who is willing and will realistically be able to do the job of a mentor;
> 2) who is willing and will realistically be able to stick around and
> be a backup mentor.
>
> Here's the GSoC timeline for you to check against your personal one:
> http://google-melange.appspot.com/gsoc/events/google/gsoc2014
>

I definitely want to do it seriously, but I realize that it starts way
sooner than I thought.
Basically I will be more settled from end of May. Before that, my
schedule and my internet time will be limited, just like now. It still
means that I will read all my emails and will answer them. But it may
mean that my response time can be a few days (like it is currently).
>From end of May though, I can be a full time geek again with its own
Internet connection, through all summer.

How would such a thing work with gsoc? Is it acceptable?

> Just in case, we will be accepting project ideas for both GIMP and GEGL.

On my side, I would concentrate on GIMP side.
There are many things that can be improved in GIMP, with or without a
GEGL piece too, and I definitely can propose and mentor various
projects.

Jehan

> An official announcement that we are submitting an application to
> participate at GSoC again will be sent later.
>
> Alexandre
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp Manual Roadmap proposal

[Jehan Pagès]

Hi,

On Wed, Feb 5, 2014 at 9:51 PM, Roman Joost  wrote:
> Hi,
>
> I've put together a Roadmap proposal under:
>
> http://wiki.gimp.org/index.php/Documentation:Main
>
> Any feedback is welcome. Some of the points are not to be read as: go
> ahead and implement, but rather look into it for it's feasibility.
>
> If there are no objections or comments I'd basically call the roadmap
> silently as accepted. For each point I think it'll be good to create
> bugs so we can track progress.

I've not read it in details and mostly skimmed through.

I got intrigued by a specific point though: moving the manual to
github. Really? I know several (all?) of GNOME's repos have already
been *mirrored* to github. Personally I find it acceptable if repos
are just mirrored (that's after all one of the point of git as a
"distributed" revision control), but not if it is to be considered the
new main repository of the project. github is just another of these
platforms led by a company, just like was Sourceforge (and now look,
with time, all projects are fleeing it, just as we did), and like will
be some other "fashionable" platform in the future. So I say, we keep
control of the main repo. And if a github mirror had to be created,
that would only be to profit of its network effect (why not), but it
must be soon clear to new contributors that they must sync with the
GNOME repo in the end, not the github one.

Was that what you were proposing? If so, ok.

If you really propose to "move" the main repo to github (as it is
worded on the wiki), then I personally vote against.

Jehan

>
> Kind Regards,
> --
> Roman Joost
> www: http://www.romanofski.de
> email: romanof...@gimp.org
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Wiki down?

[Jehan Pagès]

Hi,

The wiki seems down. I get a fatal error when trying to get there.
Is that "normal" (= maintainance in progress or something of the sort)?
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
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Adopt a development model similar to Jenkins?

[Jehan Pagès]

Hi,

On Sun, Mar 23, 2014 at 12:04 PM, Sam Gleske  wrote:
> Reference - https://github.com/jenkinsci
>
> So recently I've been introduced to the way Jenkins CI does development and
> progression of the platform.  I decided to write a plugin for Jenkins and
> so I hopped over to their IRC channel to discuss with them about it.  First
> thing they did was make me a member of the org.
>
> Basically they have two organizational teams: Owners (consists of core
> devs) and Everyone.
>
> By making me a member of the Everyone group I got commit access to all
> 1000+ repositories associated with Jenkins plugins.  I can freely
> contribute to any one of them.  However, I don't have commit access to the
> core Jenkins repository which is the main application of the whole
> platform.  I think this model is really cool.  Because basically when you
> first commit a pull request the jenkinsadmin bot will tell you how the pull
> requests work.
>
> Here is a pull request as an example [1].  The Jenkins admin posted a
> comment stating that the pull requester should read the link on pull
> requests [2].  I think this is cool.  It's basically a policy that if any
> plugin goes unnoticed pipe up and become a contributor with commit access
> to the organizations.
>
> Right now, GIMP has a place for users to dwonload plugins... but there is
> no place where the source code of all of the plugins live and be maintained.

We have the core plugins (the ones released together with GIMP)
versionned already and their source lives in the main source tree,
with GIMP itself.
Now maybe you are speaking about the user-contributed plugins, that
anyone can upload on registry.gimp.org. The current status on this is
that apart from providing a subdomain for conveniency, we have
basically no control and no verification whatsoever over whatever
users upload.

Note that providing a whole infrastructure to check plugins, source
versioning to third-party plugin devs, and such things would be great.
I actually wish to kickstart such a project some day, hopefully (see
for instance the project I was proposing if we had been accepted as
mentoring org in this year gsoc:
http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas#Create_a_plugin_management_framework
).

But the real current status is that these third-party plugins are just
completely outside of our control. And we certainly don't have the
man-force right now to do otherwise anyway. So the wish of us keeping
their source code somewhere is irrelevant here.

> I went looking for the GIMP repository on github (it's nice that there is
> one!) however it seems sadly buried in the GNOME project repositories.

Yes this is only a mirror of our main repository hosted on the GNOME servers.

> I propose GIMP developer team take the initiative to create an
> organizational account at github and form teams similar to Jenkins.  1.
> Owners whom are the only ones with commit access to the GIMP core but can
> still accept pull requests from outsiders.  And 2. an Everyone group in
> which anybody who asks gets commit access to all of the plugins in the
> organization area.

I personally completely downvote this proposition. I have already
given my opinion about github a few times, and I'll give it again:
this is just a service provided by a company like there had been
dozens by the past and like there will be dozens more in the future.
They just come and go (look at sourceforge, it used to be the big
deal, now everyone flees the sinking stinky boat). Relying on this
kind of service is not sustainable, unless we just can't afford
hosting ourselves (like individuals, I may understand them using
services for conveniency). But we can afford it (through GNOME), so
why care?

Also basically that's not good for independence. These commercial
services always have complicated and terrible contracts that nobody
ever reads and that they just change whenever they feel like
tightening the grip a little more. We can't forget they are companies
whose goal is hence money. So I really prefer never having to rely on
them. Using them as mirror (a big strength of git) for profiting of
network effect? Fine. Using it as backup? Fine. But that's it.

Finally I used to use github when employed in a startup for a few
years. Well I really couldn't see the big idea. It is nice but it has
nothing else that we don't do otherwise as simply. Except that it does
it all in a browser, which makes it very annoying in my opinion.
Worse, projects there would likely limit themselves to whatever github
proposes. Being on our own allows us to go much further and make our
own adapted tools.

> I think this would spice up and breath development life into the GIMP
> project.  GIMP is much more than just gnome and I think the barrier to
> entry to developing on GIMP should be so low you can trip over it.  Jenkins
> does that well and I feel like by immediately being made a committer to all
> of the plugins repositories it makes me want to jum

Re: [Gimp-developer] Fwd: Gimp Registry Future

[Jehan Pagès]

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl  wrote:
> Hi,
>
> it's interesting to see what interest such a post can trigger ;-)
> To be honest, it wasn't me who started the discussion, I just forwarded
> Ingo's call to the mailing list.
>
> 'GIMP is easily user-extendable, by ‘one-click’ installation of
> plug-ins.' is a part of our product-vision and as far as I remember
> there have already been many ideas on this topic, dating back to 2003.
>
> For both the registry and GIMP the situation changes:
> Registry: from some or many users who know and use the registry to
> potentially every user who can access it conveniently from GIMP. These
> are millions.
> GIMP: From a standalone application that uses mostly local data to
> an application with tighter access to an online service.
>
> I think before we start losing ourselves prematurely in implementation
> details like programming language and data formats we should clarify
> the overall picture first:
> - What are the concrete requirements: functional and nonfunctional
> requirements,
> - user interaction,
> - overall technical architecture and integration into GIMP,
> - reuse of existing solutions like package managers,
> - who will also care in future for the registry and the plug-in manager?
> - Integration into the Jenkins builds and manpower to handle this.
>
> Examples for functional requirements:
> * installing only plug-ins or also other assets,
> * curation/quality assurance of provided assets,
> * metadata of the assets,
> * search and filter functionality.
>
> Examples for nonfunctional requirements:
> * performance: be fluent, also with a slow internet connection,
> * security, protection against abuse,
> * scalability (how many users will access the registry at one time or
> at maximum),
> * target platform,
> * maintainability (even with our given low resources).
>
> Perhaps it would - depending on our resources - first be better to cut
> down the registry to the necessary part we can handle, e.g. to remove
> the functionality that causes spam and start with a little
> thing in GIMP, like a clickable link to open the registry in a
> browser and easy to find assets folders in the Preferences.

All this topic is one I am myself very interested too, and I actually
have been thinking about it for 6 months.
If we had been a Gsoc mentor organization this year, I was even hoping
we could find a student willing to kickstart such a plugin management
infrastructure (this was in my personal list of gsoc ideas meant to be
merged with the rest:
http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas ).

Now if someone wants to take care of this, I am all for not
overworking myself. :-) Otherwise, I would likely tackle the issue
properly in a several months. I am currently farming alpacas :P thus
in the impossibility to focus on such an important problem, but in end
of May I will be much more dedicated to GIMP again (though I have
several GIMP-related priorities at this time, before even thinking
about a plugin management system).

Now before I become silent again, I will still raise what I believe
are much important problems than any technical issues: security and
responsibilities of the GIMP project. If that had been a gsoc project,
I would have given most of the technicalities to the student and would
have taken care of security personally.
Basically having a website where anyone can upload anything and anyone
else is fully responsible for checking oneself and installing manually
is one thing. But providing a plugin management system, released
together and integrated with GIMP, which would download and install on
the user's behalf, and even auto-update plugins is a completely
different matter. If not mistaken, there is no proper sandbox for GIMP
plugins, so they are technically executables that GIMP runs and which
can do many kinds of nasty stuff. We suddenly have a much more bigger
responsibility:

- We must not accept anything without at the very least a minimum of
check. Ideally we would need security analysis programs to
automatically review each and every code uploaded (calls to third
party URIs, attempt to access networks, system calls which are likely
not normal in a GIMP plugins, etc.), then technical-minded
contributors to review codes of any suspicious plugin (being the case
when the previous automatic review did pick up some strange patterns)
for any funny story (scam, attacks, using your computer as a ghost
machine, etc.). We could of course start with a self-managed community
(abuse button, vote system, etc.) until some admin steps in to install
code review scripts, and enough users step in into code review duty.
Many Free Software started their plugin management this way.
Though obviously even with such a community system, I would feel fine
only with at least a minimum of check.

- We should definitely not accept uploaded binaries. For me, this is
an absolute *no*. Binaries are black boxes. What it means is not that
C plugins shou

Re: [Gimp-developer] Fwd: Gimp Registry Future

[Jehan Pagès]

Hi,

On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle  wrote:
> Oh, and just to clarify, I also mean that effort for *authors* should be
> taken into account.

Ok well I understood everything until your "clarification". What
effort for which authors?

> On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle  wrote:
>>
>> Jehan,
>>
>> I wholeheartedly support your concerns, but I would advise trying to think
>> of ways of approaching this in a simpler way. If the registry can support
>> you in that, let me know.

Well some things can be simplified for the first release, like code
reviews as I said. But some things can't, in my opinion. In
particular, we absolutely need to secure the plugin provenance (secure
channel, signing or any other method) and we absolutely can't
automatically install any binary, with executable rights, generated by
any random person on the internet.

For me, there could be absolutely no discussion about it. That's about
respecting our community, but also about responsibility. The risks to
have malwares are too big, especially for a program as well known,
hence spread, as GIMP. We all know this. As you said yourself, the
registry is receiving more and more abuse. That's an open door for
spam, scam, and much worse. We even have more and more fake GIMP going
on nowaydays on the web, and even on some app stores (very recently
there was such a case, and Michael had to ask for the fake app to be
taken down). We seem to be told on the mailing list of a scam
involving GIMP every few weeks, and that's without counting all the
ones we never hear about. So allowing to install any random,
unreviewed and uncontrolled executable, which can be run under the
user's rights from our official build? That's like creating a
backdoor, a big security breach into a user's data and system.
So no, I don't think there can be much simpler way to this problem.

Note that of course, as a developer, I would first develop a basic
system without much security for quick feature test. But the finale
released system must have all the security in place, when dealing with
such a dangerous feature.

>> Other than that, the whole searching and browsing UI is likely far from
>> trivial as you suggest.

Yes you are right. I did not mean to imply all the rest was just easy
stuff (though I mistakenly said so). UI and search algorithm are also
important and difficult (as always). But I still meant to say that for
this specific feature, the security should be taken very seriously. It
just seems to me that your original call (which I saw, has been
relayed by some websites as gimpusers.com) seems to completely
overlook this side, which I think is primordial.

Jehan

>> cheers
>>
>>
>>
>> On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Apr 10, 2014 at 4:06 PM, scl  wrote:
>>> > Hi,
>>> >
>>> > it's interesting to see what interest such a post can trigger ;-)
>>> > To be honest, it wasn't me who started the discussion, I just forwarded
>>> > Ingo's call to the mailing list.
>>> >
>>> > 'GIMP is easily user-extendable, by ‘one-click’ installation of
>>> > plug-ins.' is a part of our product-vision and as far as I remember
>>> > there have already been many ideas on this topic, dating back to 2003.
>>> >
>>> > For both the registry and GIMP the situation changes:
>>> > Registry: from some or many users who know and use the registry to
>>> > potentially every user who can access it conveniently from GIMP. These
>>> > are millions.
>>> > GIMP: From a standalone application that uses mostly local data to
>>> > an application with tighter access to an online service.
>>> >
>>> > I think before we start losing ourselves prematurely in implementation
>>> > details like programming language and data formats we should clarify
>>> > the overall picture first:
>>> > - What are the concrete requirements: functional and nonfunctional
>>> > requirements,
>>> > - user interaction,
>>> > - overall technical architecture and integration into GIMP,
>>> > - reuse of existing solutions like package managers,
>>> > - who will also care in future for the registry and the plug-in
>>> > manager?
>>> > - Integration into the Jenkins builds and manpower to handle this.
>>> >
>>> > Examples for functional requirements:
>>> > * installing only plug-ins or also other assets,
>>> > * curation/quality assurance of provided assets,
>>> &g