[Gimp-developer] Darktable plug-in in GIMP - Darktable for Windows?

[Sven Claussner]

Hi,

sorry if I'm asking the wrong question but I feel I have to.
Since 18.04.2016 there is a raw importer plug-in in GIMP master
that calls darktable to do its job. With the same commit
the GEGL NEF importer was disabled which is a quite clear sign
of the devs' preferences.
On the one hand it is great we have proper import for raw
files in GIMP and darktable is indeed a great application for
raw processing. On the other hand I see that up to 90% of the PC
users are Windows users, for instance see these [statistics].
In the past the darktable devs refused to provide a Windows build
for understandable reasons of maintenance and even didn't want to
hear about Partha's Windows build (see the latest discussion about
this on the darktable dev mailing list in February 2016). The latter
makes it also very difficult to discuss Windows related bugs
which will definitely come.
So, it seems GIMP and Darktable are now trapped - how are
90% of the GIMP users supposed to import raw files with an
application that will probably never support their platform?
What has led to this decision?
Did anybody compare the various ways to import raw files
into GIMP (GEGL, darktable, ufraw, photoflow etc.)?

Greetings

Sven


[statistics]
https://netmarketshare.com/
http://www.statista.com/statistics/268237/global-market-share-held-by-operating-systems-since-2009/

___
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] Release procedure (was: Testers requested for our new Mac OS X DMG release!)

[Sven Claussner]

Hi,

no reply yet.
I asked the devs to discuss it at the LGM, but so far
I don't see anything in the (intermediate state of)
the meeting minutes.
Was it discussed and to which result?

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

Re: [Gimp-developer] Enhancement request policy

[Sven Claussner]

Hi,

no reply yet.
I asked the devs to discuss it at the LGM, but so far
I don't see anything in the (intermediate state of)
the meeting minutes.
Was it discussed and to which result?

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

[Gimp-developer] Bugzilla saved searches

[Sven Claussner]

Hi,

I just created or updated some searches in our Bugzilla:

Searches to prepare release notes:
==
Babl - changes since last release
GEGL - changes since last release
GIMP 2.8 - changes since last release
GIMP master - changes since last release
GIMP Help - changes since last release

Searches for bug triaging:
==
Babl, GEGL - NEEDINFO bugs
GIMP - NEEDINFO bugs
GIMP - open bugs without NEEDINFO and ENH (Mitch's List)

Searches for patches waiting for review and integration:

Babl, GEGL - Open patches
GIMP - Open patches

Searches by platform:
=
GIMP - open Linux related bugs
GIMP - open OS X related bugs
GIMP - open Windows related bugs

You should be able to access them in Bugzilla via
Preferences -> Saved Searches.
Feel free to add them to your site footers for quick access
or copy and modify them to your needs.

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

Re: [Gimp-developer] Code for editing in non-sRGB color spaces

[Sven Claussner]

Hi Elle,

On  13.4.2016 at 11:18 PM Elle Stone wrote:

On 04/13/2016 03:16 PM, Sven Claussner wrote:

thank you for your contribution and sorry for not replying earlier.
I didn't have the time yet to read all your lines yet, but how about
pushing your work to separate branches in babl, GEGL and GIMP?


Currently I don't have commit rights. But when I finish the new patches,
it would be nice to be able to upload them to branches where people can
test, review, etc.


We could review and refine them there and make builds on Jenkins
for testing. When they have matured for integration they should go
then into the master branches.



If you need help with development let us know.


Perhaps someone could set up suitable branches of babl/GEGL/GIMP?


It's best to set them up yourself, because even if we did you'd
had to pull them and apply your patches there.
Setting up branches is easy and perhaps you've already done it in your
local workspace:

git checkout -b $mybranch

Instead of $mybranch use wip-not-only-sRGB or what fits best.

To get your branches upstream, follow this:
https://wiki.gnome.org/Git/Developers#Pushing_your_changes_upstream

To get a GNOME Git account just follow this tutorial:
https://wiki.gnome.org/action/show/AccountsTeam/NewAccounts?action=show=NewAccounts

In step 1 'Explanation why you think you should get an account' write
that you need it to contribute to babl, GEGL and GIMP. I cc'ed to Mitch
(or Pippin, too) so he can give his OK on admins request.

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

[Gimp-developer] Enhancement request policy

[Sven Claussner]

Hi,

in the light of current events one problem comes up again:
how do we deal with enhancement requests reported in Bugzilla?

Currently we count 1'193 open GIMP bugs, of which 607 are
enhancement requests. We're drowning in them.

In 2015 Jim DeLaHunt pointed out a discrepancy between the
website and the documentation, see

https://mail.gnome.org/archives/gimp-developer-list/2015-February/msg3.html
Unfortunately the topic wasn't discussed, but still persists and is
in a current case time consuming and going blue.

In the past I already closed bugs as INVALID until they are agreed
upon on the mailing list, but it wasn't considered the best solution.
Actually we put the bug on hold, but Bugzilla has no bug state for this.

How about this:
1. On enhancement requests we check for Bugzilla duplicates and former
mailing list discussions. On duplicates and formerly disagreed requests
we close the bug with a suitable reason as DUPLICATE or WONTFIX.
2. If the request is not a duplicate we answer with an friendly stock
answer and ask to bring the topic to the developer mailing list.
If it's a pure GUI topic, then to the gimp-gui mailing list.
Until the topic is discussed with a clear result, we set the bug into
NEEDINFO state.
3. On agreement we set the bug into state NEW, otherwise close it as
WONTFIX.
If the reporter refuses to post the request to the mailing list, then
either we post it there if we think it's useful, otherwise we close
it as INVALID.

If no further discussion is ongoing we close the bugs after an agreed
period of time, e.g. 3 weeks since reporting.

The goals are getting useful feedback, while keeping the bug base small.

It would be nice if we found a final solution now and made it clear at
the website and in the documentation.

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

Re: [Gimp-developer] Code for editing in non-sRGB color spaces

[Sven Claussner]

Hi Elle,


On  9.4.2016 at 10:32 PM Elle Stone wrote:

I made the assumption that the very talented babl/GEGL/GIMP developers
are capable of writing code that can send colorant information from GIMP
to babl.

On the basis of this assumption, I made a list of all the code files in
babl/GEGL/GIMP that would require patching:
http://ninedegreesbelow.com/files/patch-gimp/user-chosen-rgb/hard-coded-srgb.ods


Then I wrote some "proof of concept" patches for providing GIMP users
with the ability to edit in RGB working spaces other than sRGB:
http://ninedegreesbelow.com/files/patch-gimp/user-chosen-rgb/proof-of-concept-patches.tar.gz


I also wrote an overview of the task of patching babl/GEGL/GIMP to allow
for editing in a user-chosen RGB working space:

Modifying bab/GEGL/GIMP for editing in user-chosen RGB working spaces
http://ninedegreesbelow.com/photography/gimp-edit-in-user-chosen-rgb-working-space.html


thank you for your contribution and sorry for not replying earlier.
I didn't have the time yet to read all your lines yet, but how about
pushing your work to separate branches in babl, GEGL and GIMP?
We could review and refine them there and make builds on Jenkins
for testing. When they have matured for integration they should go
then into the master branches.
If you need help with development let us know.

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

Re: [Gimp-developer] GIMP Open problem on Mac

[Sven Claussner]

Hi,

On  12.4.2016 at 11:46 PM Mkirst wrote:

When I attempt to run GIMP, I receive an error from the “gatekeeper” because 
GIMP is not from the MAC App Store or from a known developer.
I am hoping there is a work-around for this or that this will be resolved in an 
upcoming release.

Right click on GIMP, select 'Open' and confirm the warning that this
software is not from a known developer with an Apple ID.
I can advice this only for downloads from our website www.gimp.org
because this is the only download site we have control over.
We are free people offering free software and decided not to pay Apple
every year for getting less control over our deployment process.


I am deeply involved in photography and in need of a serious “darkroom” 
application for processing the photos I take.

Many of us are involved into photography, too.
For quicker mass photo processing you might also consider using the
raw processor darktable (see www.darktable.org), which is specialized
for this job. And there's the website pixls.us where you can get
more information and discuss free/open source photography.
Anyway, you're welcome to use GIMP.

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

[Gimp-developer] Release procedure (was: Testers requested for our new Mac OS X DMG release!)

[Sven Claussner]

Hi,

lately in IRC the idea of documenting and scripting our deployment
processes at LGM came up. I support this idea and like to bring up the
topic of rethinking our release procedure again:

On  10.1.2016 at 1:11 AM Alexandre Prokoudine wrote:
> On Mon, Jan 4, 2016 at 11:23 AM, Kristian Rietveld wrote
in reply to my post from 31 Dec 2015, at 14:13
>> More coordinated releases would be a good thing to have IMHO.
>> Releasing Windows & Mac binaries and perhaps Debian/Ubuntu and
>> Fedora packages at the same time as a new tarball release would be
>> great.

> Hence I'd like to propose the following change to the release policy,
> using Sven's proposal as a basis:
>
> 1. Negotiate a release date between mitch (GIMP maintainer), pippin
> (GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).

Plus: Roman Joost (GIMP doc maintainer), a responsible counterpart
from the GNOME Translation Project Coordination Team
(perhaps Piotr Drąg as GIMP translation contributor, see also
https://wiki.gnome.org/TranslationProject/CoordinationTeam)
and one from the website maintainers (Michael Schumacher, Alexandre or
Pat).

> 2. Finalize a list of changes that should be covered in the user
> manual and in the docs for developers.
> 3. Announce a strings freeze at least a month before releasing to give
> translators and docs writers do their job.
> 4. Complete all release related docs.
> 5. Bump version number for both GEGL/babl, GIMP, and gimp-help.
> 6. Make and test all builds for all supported systems.
> 7. Update the 'testing' branch of the website (download links,
> announcements), update docs.gimp.org, check everything.
> 8. Merge all changes from the 'testing' branch into the 'master' 
branch of wgo.

> 9. Announce.
> To specifically aid #2, since December, there's a changelog targeted
> at user manual writers:
> http://wiki.gimp.org/wiki/Release:2.10_changelog
> Needless to say, it's WIP, but it's getting there.

It would be good if you could discuss it at LGM. Well, I'm not
attending LGM this year but if you need me I'm ready to take the time
and be there in our chat room or answer by mail.

@Alex, Kris: will you be at LGM?

Greetings

Sven

PS: I already posted this yesterday, but used the answering function
of my email client, so the former post might be buried under others.
Now sending it properly as top level post.


___
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] Release procedure (was: Testers requested for our new Mac OS X DMG release!)

[Sven Claussner]

On  10.1.2016 at 1:11 AM Alexandre Prokoudine wrote:

On Mon, Jan 4, 2016 at 11:23 AM, Kristian Rietveld wrote:


>> On 31 Dec 2015, at 14:13, scl  wrote:

- @GIMP team: I remember that at the time I was more active
new versions came out of a sudden when Mitch had time to
bump a release and the releases were made later. This has the
effect that users who read the announcement have to wait
again and thus are disappointed after a long period of waiting
for a release.
How about reorganizing the process of release builds and
version announcements by
1. negotiating a release date internally,
2. completing the release docs (NEWS, 
http://wiki.gimp.org/index.php?title=Special%3APrefixIndex=Release%3A=0)
3. bumping the version number,
4. making and testing the builds and
5. as last step announcing the release?


More coordinated releases would be a good thing to have IMHO. Releasing Windows 
& Mac binaries and perhaps Debian/Ubuntu and Fedora packages at the same time 
as a new tarball release would be great.

Hence I'd like to propose the following change to the release policy,
using Sven's proposal as a basis:

1. Negotiate a release date between mitch (GIMP maintainer), pippin
(GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).

2. Finalize a list of changes that should be covered in the user
manual and in the docs for developers.

3. Announce a strings freeze at least a month before releasing to give
translators and docs writers do their job.

4. Complete all release related docs.

5. Bump version number for both GEGL/babl, GIMP, and gimp-help.

6. Make and test all builds for all supported systems.

7. Update the 'testing' branch of the website (download links,
announcements), update docs.gimp.org, check everything.

8. Merge all changes from the 'testing' branch into the 'master' branch of wgo.

9. Announce.

To specifically aid #2, since December, there's a changelog targeted
at user manual writers:

http://wiki.gimp.org/wiki/Release:2.10_changelog

Needless to say, it's WIP, but it's getting there.



lately in IRC the idea of documenting and scripting our deployment
processes at LGM came up. I support this idea and like to bring up the
topic of rethinking our release procedure again. It would be nice
if you could discuss it at LGM. Well, I'm not attending LGM but
if you need me I'm ready to take the time and be there in our chat room
or answer by mail.

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

Re: [Gimp-developer] suggestions

[Sven Claussner]

Hi Elle,

On  5.4.2016 at 10:55 PM Elle Stone wrote:

On 04/05/2016 02:10 PM, Sven Claussner wrote:

Hi,

On  4.4.2016 at 3:56 PM Elle Stone wrote:

On 03/27/2016 02:44 PM, C R wrote:
* The ability to edit in RGB working color spaces other than sRGB.


I'm for this, too.
sRGB is from the 1990's and made for the web.
Life goes on. Modern monitors aim to get as much AdobeRGB coverage
as possible and that's not the end yet.
If we aim to provide state-of-the-art technology we should not stick to
sRGB, but be open for flexible solutions.
See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance.
As Alex says, it takes just one developer to work on it. I think we
can start with the above mentioned bug report and go on from that.


Some of the specific code-related information in that particular bug
report is out of date, not surprising as I posted the bug report in
December 2014. The general issues remain. The specific locations of the
hard-coded parameters haven't changed too much (GEGL has fewer such
locations). But the specific functions that call on the hard-coded
parameters have changed a bit.


@Pippin, Mitch: what are your thoughts on this topic?



I started a branch of this current thread to ask some specific questions
regarding a couple of babl functions that might be useful for conveying
RGB color space information from GIMP to babl, and also about the idea
of coding in a selection of well-behaved RGB working spaces:
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.html


I've seen it. It looks like it accidentally landed in the suggestions
thread by just using the 'Answer' function of your mail client.
As it has now evolved too far from the original poster's topic I
suggest to have it as a new top level topic. But please
- do not repeat what was already said in one of those many sRGB postings
before
- stay brief or add a short summary to your postings.
I hope you don't get me wrong. Well-thought postings are welcome,
but the longer the text the less people read it.
Developers love coding ;-)

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

Re: [Gimp-developer] suggestions

[Sven Claussner]

Hi,

On  4.4.2016 at 3:56 PM Elle Stone wrote:

On 03/27/2016 02:44 PM, C R wrote:
* The ability to edit in RGB working color spaces other than sRGB.


I'm for this, too.
sRGB is from the 1990's and made for the web.
Life goes on. Modern monitors aim to get as much AdobeRGB coverage
as possible and that's not the end yet.
If we aim to provide state-of-the-art technology we should not stick to
sRGB, but be open for flexible solutions.
See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance.
As Alex says, it takes just one developer to work on it. I think we
can start with the above mentioned bug report and go on from that.



* The ability to easily record and replay repetitive steps ("macros").


Yes, that's already part of the roadmap and part of our product vision.


* The ability to use adjustment layers.


Yes, that's already part of the roadmap.

I'm wondering why so many people stick with adjustments layers, nodes
and smart objects as if they were the only possible ways for
non-destructive editing. I sometimes think because they know nothing else,
it's so common, looks cool or because 'PS does it so.'
Let's not stick to what Adobe did because it was suitable for PS.
I might be wrong, but to me adjustment layers and smart objects seem an
attempt to get nondestructive editing into a software that wasn't
designed for that while keeping backwards compatibility.
Let's find better ways that suit GIMP and support intense users'
workflows best. Think of filter brushes, intelligent masks or masks
like in Darktable etc. For such a crucial function we won't get out of
doing UI testing with users.
But one thing we really have to keep in mind with adjustment layers
and smart objects is to find an appropriate conversion in the PSD
importer and exporter.

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

Re: [Gimp-developer] Neon Edge Detection Filter

[Sven Claussner]

Hi David,

On  16.2.2016 at 6:58 AM Rosenthal, David wrote:

I am getting some unusual results sometimes when i use the Neon Edge
Detection Filter parameters: 9, 3.0


I couldn't reproduce the filter with these parameters.
Reading your post one year ago I guess you mean (9, 0.3), don't you?


Is there someone I could correspond directly with to send an example
original photo and the processed one.


You're right here on this list. Another way is our IRC channel #gimp.
To refer to your examples please upload them to an image hoster, e.g.
Imgur, and post the link here or in IRC.


[...many lines of cited but unrelated text...]


If you use the Reply feature in your mail client, please make sure to
cut out the text that doesn't belong to your issue.

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

Re: [Gimp-developer] Adding better LCH support to GIMP 2.10

[Sven Claussner]

Hi,

@Elle: you are speaking here of the JCH color model (or space) and mentioned
on your website [1] that JAB and JCH have outdated LAB and LCH
(which are often considered the high end image editing color
spaces/models).
Searching a while for more information about JCH I found only very few
information, even not on other color management and FOSS graphics devel
mailing lists. Only on the PXLab website [2] I see a short description:

JCH:=The CIE Color Appearance Model (1997) with viewing and scene conditions
to be defined separately.

I'm failing to understand all its implications.
Can you tell us more about JCH and JAB and why you consider it to
be a good choice, please? What about LAB and LCH then?
Does somebody else here know more about it?

Thank you in advance

Sven


[1]
http://ninedegreesbelow.com/photography/high-bit-depth-gimp-tutorial-edit-tonality-color-separately.html

[2]
http://irtel.uni-mannheim.de/pxlab/doc/api/de/pxlab/pxl/ColorSpaceCodes.html#CS_JCh

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

Re: [Gimp-developer] GIMP 2.9 download

[Sven Claussner]

On  31.1.2016 at 1:37 PM Joseph Bupe wrote:

Binaries?




Not from the GIMP project itself yet, but at www.partha.com
you find some Windows and OS X builds of version 2.9.3 which is a
bit newer than 2.9.2. The Windows builds require a 64 bit Windows.
Partha Bagchi might be able to tell more about them.
There's also a 2.9.3 build on Macports for OS X.
For Linux I found no Debian nor Fedora packages, only a OpenSuse/Leap
package: 
https://build.opensuse.org/package/show?project=home%3Acyberbeat=gimp

PC-BSD has no 2.9.x port.

@Alex, Pat, Schumaml: should we add this information to our downloads
page as long as we don't provide own 2.9.x builds?

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

Re: [Gimp-developer] Problems with JPG?!

[Sven Claussner]

On  31.1.2016 at 4:29 PM Stefan Rohde wrote:

I can not display images that I have prepared and saved with GIMP 2.8.14
(under Windows 10) in jpg-format on my TV or via a digital box (WD TV).
On my PC its no problem!
The Thumbnailes can be seen but the images can not be read!
I have also tried several setting for the jpg-saving.

Other images I prepared with former versions are working well!

Do you have an idea or information !?




Hi Stefan,

did you also try various settings of the subsampling
(in the German dialog box: Zwischenschritte, although
'Farbunterabtastung' is the proper translation here)?
If you report a bug, please make sure to use version 2.8.16 which
is the latest.

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

[Gimp-developer] What's the 'Gamma hack' in GIMP master?

[Sven Claussner]

Hi,

the dialog boxes of GEGL based operations in GIMP master
have a checkbox 'Gamma hack (please ignore)".
What's this?
Why should a user ignore it?

Thank you in advance for your replies

Sven



Sie interessieren sich für wunderschöne Malereien,
Märchenbücher und Heimtextilien?
Dann schauen Sie mal rein: http://www.unikate4you.de !


--

___
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] What's the 'Gamma hack' in GIMP master?

[Sven Claussner]

On  31.1.2016 at 1:21 PM Alexandre Prokoudine wrote:

On Sun, Jan 31, 2016 at 3:18 PM, Sven Claussner wrote:

the dialog boxes of GEGL based operations in GIMP master
have a checkbox 'Gamma hack (please ignore)".
What's this?


https://git.gnome.org/browse/gimp/commit/?id=114a9d46be56932f92758c4bd95ed6539e871249



Brief and precise :-)
I thought the format casts are done automatically?

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

Re: [Gimp-developer] A better way to close a path where an end node is on top of a start node

[Sven Claussner]

On  29.1.2016 at 2:53 PM Ugajin wrote:


I have been searching for how best to close a path where an end node is on top 
of a start node.


Hi,

what exactly are you trying to achieve with this method?
I also think this is rather a question for the gimp-user list than the
developer list.

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

Re: [Gimp-developer] Cannot move a node in a contour in 2.9.3

[Sven Claussner]

Hi,

On  26.1.2016 at 8:05 AM Alexander Rabtchevich wrote:

My bad, it is Paths tool. The nodes really can be moved in the design
mode, but not in the edit mode. It is a bug.


I understand that it looks a bit inconvenient from your point of view,
but it's not a bug.
Please look at the documentation:
http://docs.gimp.org/2.8/en/gimp-tool-path.html

The tool works as described and there is no specification
ruling it otherwise. If you often move nodes around, then
it's more suitable to stay in Design mode and press Ctrl/Cmd
or Alt to edit or move the path.

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

Re: [Gimp-developer] Toolbar For Common Actions

[Sven Claussner]

Hi,

On  25.1.2016 at 6:07 PM Alexandre Prokoudine wrote:

25 янв. 2016 г. 19:47 пользователь "john smith" написал:


There are certain commands that I use rather more frequently than others.
It would be convenient if I could put them in a user defined toolbar.


Is there a reason you don't use custom shortcuts?


Indeed, keyboard shortcuts known by heart are a much quicker way
to achieve things than a mouse or pen, given you have the keyboard
nearby.




Is that a possibility for a future road map?


Most likely not.

I wouldn't say that it will never be done in one or another way.
At least similar proposals were made in the GIMP UI brainstorm:
http://gimp-brainstorm.blogspot.de/search/label/tool%20options

I'm not sure whether this idea would make it to the roadmap.
After some discussion at the more suitable gimp-gui list I could see
the possibility to make it into Bugzilla and then someone needs
to implement it some day.
For the time being I suggest the keyboard shortcut solution as mentioned
above. Here you find keys and mouse quick references to memorize the 
shortcuts: http://docs.gimp.org/



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

Re: [Gimp-developer] Toolbar For Common Actions

[Sven Claussner]

On 25.01.16 at 8:23 PM Sven Claussner wrote


I'm not sure whether this idea would make it to the roadmap.


A discussion in our IRC channel #gimp clarified that this is
very probably not going to happen.
In 2008 we already had such a discussion and our former
user interaction architect voted against it, see
http://article.gmane.org/gmane.comp.video.gimp.devel/13881


For the time being I suggest the keyboard shortcut solution as mentioned
above. Here you find keys and mouse quick references to memorize the
shortcuts: http://docs.gimp.org/


So, this is our solution.

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

[Gimp-developer] Fwd: Annual GNOME Bugzilla statistics for 2015

[Sven Claussner]

Hi

I found the following GNOME desktop mailing list post today.
It's a statistics about the most active contributors to GNOME Bugzilla.
Similar statistics could also be for Git and wiki contributions.
I think that's a nice way to make contributions attractive and could
also have positive effects on our GEGL and GIMP work.
What do you think about it?

Greetings

Sven



On  5.1.2016 at 7:34 PM Andre Klapper wrote:
Hej hej,

a quick look at some basic GNOME Bugzilla activity in 2015.


Overall statistics:
20152014   2013
  Open reports at the end(*):   47205  46056  46130
  Opened in that year:  17481  20695  25137
  Closed in that year:  16417  20609  22120
(*): Excludes reports marked as enhancements


The following people closed more than 500 bugs in 2015:
   988   Milan Crha
   973   Matthias Clasen
   624   Florian Müllner
   588   Sebastian Dröge
   509   Bastien Nocera
   503   Michael Catanzaro

The following people reported more than 150 bugs in 2015:
   303   Bastien Nocera
   215   Michael Catanzaro
   187   Allan Day
   167   Matthias Clasen
   161   Vineeth

The following people contributed more than 250 patches in 2015:
   402   Debarshi Ray
   306   Bastien Nocera
   299   Ray Strode
   284   Philip Withnall
   281   Carlos Garnacho
   264   Florian Müllner

The following people reviewed more than 400 patches in 2015:
  1274   Sebastian Dröge (slomo)
   822   Bastien Nocera
   731   Matthias Clasen
   527   Debarshi Ray
   445   Michael Catanzaro

Enjoy 2016!

andre
--
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-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] git commit problems

[Sven Claussner]

Hi Kolbjørn,

On  14.1.2016 at 8:43 PM Kolbjørn Stuestøl wrote:

Is there a separate branch for the 2.8 version?
"git checkout gimp-2-8" or something?


Exactly. At https://git.gnome.org/browse/gimp/ top left is a list box
where you can see all branches. At the command prompt
  git ls-remote origin
  git remote show origin
are your friends.


Normally I am a curious person but the world of computers are too
complex for me now.


Don't judge from git to the world of computers. Git is known to be a
usability beast even for developers. You'll learn from practice and
eventually it's only few commands you need for regular use.
If you need help, just ask and often you'll get an answer here or in
IRC. In IRC mikachu is our git expert, but many of the others know git 
as well.

You might also find our Problems and Solutions page useful:
http://wiki.gimp.org/wiki/Hacking:Problems_and_solutions

If you feel more comfortable with a GUI client, then gitk, git-gui,
SmartGit or the GitExtensions might be your choice. Gitk and git-gui
are part of git. SmartGit is a comfortable third-party GUI client and
considered quite user friendly. It runs on Mac OS X, Windows and Linux.
I also made positive experiences with GitExtensions on Windows. They
are well integrated into Windows Explorer and Visual Studio.

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

Re: [Gimp-developer] Missing from the roadmap

[Sven Claussner]

Hi,

just for a better understanding:
- Is it for something that goes beyond assigning and converting to
other color spaces? I think of native support of larger gamut color
spaces than sRGB in Babl, GEGL and GIMP, am I right?
- What exactly means 'supporting gamma-encodings other than the sRGB
TRC' for intense GIMP users (artists and scientists)?
- Is it something that happens only in GEGL and Babl or would also
GIMP's code need to be touched?

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

Re: [Gimp-developer] Testers requested for our new Mac OS X DMG release!,

[Sven Claussner]

On  10.1.2016 at 1:21 AM Alexandre Prokoudine wrote:

On Sun, Jan 10, 2016 at 3:11 AM, Alexandre Prokoudine wrote:


1. Negotiate a release date between mitch (GIMP maintainer), pippin
(GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).


Also, I think whoever is in charge of the user manual these days
should have a say here, but the problem is that I have no idea who
that person is (Julien?), and I don't think this person is ever on IRC
where most communication is taking place. It would be _amazing_ to
have stakeholders connected to the release procedure and tuned to
actual gimp development.

Alex



I fully agree to your two posts, Alex.

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

Re: [Gimp-developer] Testers requested for our new Mac OS X DMG release!,

[Sven Claussner]

Hi,


On  4.1.2016 at 9:23 AM Kristian Rietveld wrote:



On 31 Dec 2015, at 14:13, scl  wrote:



And the steps after that are to automate the process


This reminds me of my attempts to integrate an OS X build slave
into the Jenkins continuous build environment. Sam Gleske or
Tobias Vogel might be able to tell you more about the current state.


We’ve been in contact with Tobias indeed.


And to which result?



- @GIMP team: I remember that at the time I was more active
new versions came out of a sudden when Mitch had time to
bump a release and the releases were made later. This has the
effect that users who read the announcement have to wait
again and thus are disappointed after a long period of waiting
for a release.
How about reorganizing the process of release builds and
version announcements by
1. negotiating a release date internally,
2. completing the release docs (NEWS, 
http://wiki.gimp.org/index.php?title=Special%3APrefixIndex=Release%3A=0)
3. bumping the version number,
4. making and testing the builds and
5. as last step announcing the release?


More coordinated releases would be a good thing to have IMHO. Releasing Windows 
& Mac binaries and perhaps Debian/Ubuntu and Fedora packages at the same time 
as a new tarball release would be great.



Lately I heard of AppImages, self-contained application packages like
apps or dmg, but for Linux.
For the Ubuntu part I think all it takes is to contact "Otto 
Kesselgulasch", the maintainer of the GIMP PPA on Ubuntu.

Perhaps staying in touch with the package maintainers of other
distros could be helpful.

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

Re: [Gimp-developer] PSD plugin needs your love

[Sven Claussner]

Hi,

 Am 17.02.2014 um 10:45 schrieb Alexandre Prokoudine 
 alexandre.prokoud...@gmail.com:
 ...
 For testing purposes (that is, to see what happens now) you can use
 builds from  http://nightly.darkrefraction.com/gimp/stable/ on
 Windows, or just build the code from Git master branch on Linux.

You can also get a binary build for Linux (64 Bit) at 
https://build.gimp.org/view/AllDownloads/.

Kind Regards,

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

Re: [Gimp-developer] OS X Build Server (VM)

[Sven Claussner]

Hi Tobias,

first of all thank you very much for your offer and sorry that I
couldn't reply earlier (I was on a holiday trip and came back
today).

I'm the maintainer of our continuous integration system (CI system,
Jenkins). Currently I'm about to do some basic clean up work and
one of the next steps are continuous and/or nightly builds for
the OS X platform. Currently I think we would at least need a VM
of the latest OS X (Mavericks) and perhaps one older version, but
it's not completely decided yet. I'll contact you at the given
time.

Happy GIMPing and a happy new year,

Sven

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

Re: [Gimp-developer] Documentation on color spaces

[Sven Claussner]

Hi Elle,

I hope you agree that I added a link to your documentation in our 
developer wiki: 
http://wiki.gimp.org/index.php/Users:Beginner_Developer%27s_FAQ


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

[Sven Claussner]

Hi all,

I'm also for an additional dark theme. Both (dark and lighter theme)
can ease the artists work and be used to check the images appearance
on-the-fly.

I've already sat for hours on searching for a suitable dark theme,
integrating the Gnome art-libre icon set and after asking Jimmac at IRC
without ulterior motives one day before his G+ posting the things are
now slipped away from my hands. If it still matters - Andrea Cimitans 
Darklooks theme looks suitable. In Debian it's in the package

'gnome-themes-extras'.

I also think there's more to a professional, user-supporting theme
than assembling nice pieces out of a spontaneous idea. Ad hoc topics
like suitability for speedy work, using a theme engine that works on
all important platforms (Linux, Windows, OS X) and suitability for
High-DPI (Retina) displays come to my mind. Therefore I asked Peter for
some input on the topic. Perhaps we know more next week.

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.

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

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

[Sven Claussner]

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.

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

[Sven Claussner]

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.

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

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