Re: [Gimp-developer] Blog article about Scheme usage in GIMP

[Martin Nordholts]

2011/9/5 Ofnuts :
> On 09/05/2011 07:57 PM, Martin Nordholts wrote:
>> If we look at what programming languages that are popular [1], we can
>> see that the vast majority of languages in use today have a syntax
>> where 1 + 1 is written "1 + 1" and not "(+ 1 1)". If we want to have a
>> main scripting language that as many as possible can use with as
>> little effort as possible, Scheme is simply not an alternative. For
>> most programmers, Scheme is an odd language. In the long term I think
>> it is inevitable that we need to replace Scheme with something that
>> has a syntax that is more mainstream.
>
> I wholeheartedly agree with that.
>
>> However, doing the switch is a huge task and we have other things that
>> are more important to work on, so I don't see this happening any time
>> soon.
>
> Haven't we got a quite nice Python interface already?

Yes we do, which is nice, but Scheme still has higher status. In
particular, the format of gimprc files etc are Scheme-ish, and the
default batch interpreter is Script-Fu.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Blog article about Scheme usage in GIMP

[Martin Nordholts]

2011/9/5 Michael Schumacher :
> I'd like to comment on the blog post, or see comments by someone else, but 
> I'd like to clarify our plans for Scheme in GIMP first.

If we look at what programming languages that are popular [1], we can
see that the vast majority of languages in use today have a syntax
where 1 + 1 is written "1 + 1" and not "(+ 1 1)". If we want to have a
main scripting language that as many as possible can use with as
little effort as possible, Scheme is simply not an alternative. For
most programmers, Scheme is an odd language. In the long term I think
it is inevitable that we need to replace Scheme with something that
has a syntax that is more mainstream.

However, doing the switch is a huge task and we have other things that
are more important to work on, so I don't see this happening any time
soon.

 / Martin

[1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] usability update

[Martin Nordholts]

2011/9/2 Tobias Ehni :
> Dear list,
>
> there have been some updates on the usability wiki as work is progressing.
>
> Method description has moved a bit:
> http://gui.gimp.org/index.php/Mental_Models_for_GIMP
> Please let me know if there is something to clarify or to discuss in
> more detail here.
>
> Next, I've posted some ideas of where to recruit further interview
> partners under "recruitment channels".
> Feel free to add your own ideas there.
> Luckily, there have been recommendations for interview partners on
> this list as well (thanks Ramón).
>
> There's a new section "interview partners"
> (http://gui.gimp.org/index.php/Interview_Partners).
> My idea of how to handle the recruitment process with this section is
> as follows:
> The section is divided into "confirmed" and "pool", so that interested
> people can be put under "pool", most helpfully including a link to a
> website / portfolio of them. If both of the GIMP-Team and they
> themselves confirm an interview, they will get promoted into the
> "confirmed" section. During this process, they can select a time/date
> for their interview via http://doodle.com/ which can also be added to
> their name in the confirmed section.
> As a next step, I will ask the people who have been recommended
> earlier on this list if they would like to participate.
> Does that make sense to you?
>
> Further, I've provided information about the interviews here:
> http://gui.gimp.org/index.php/Information_for_Interview_Partners
> Main audience for this is of course the interview partners.
> Please take a quick look and tell me if I missed something.
>
> Reinforcements are under way / being requested (in the form of a
> volunteer / intern for the project)
> http://www.openusability.org/index.php/sou/projects
>
> I'm also thinking about an IRC meeting on usability in order to:
> - clarify details about the method
> - gather ideas for recruiting
> - add interview partners to the pool
> - talk about next steps
> What do you think?

Hi Tobias,

I think it would be good to keep the discussion on this list rather
than moving to IRC as we don't have central archives of discussions on
IRC.

I'm afraid I don't have much input at this point, but it looks like
you are doing the right things, so please keep going and keep us
informed on the progress. It will be interesting to see the end
result.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tool presets

[Martin Nordholts]

2011/9/5 Alexia Death :
> Of course, but I see no reason to actively discourage resource changes
> at a point when we dont even have a new splash set yet...

Well, the reason we don't have a splash is because nobody had time to
get us one yet. From the point of view of making a 2.8 release happen,
it would be better if you took the lead in finding a 2.8 splash rather
than adding default tool presets.

But then there is the point of view of fun, and if you get a kick out
of giving users default tool presets in 2.8, which is perfectly
sensible, please do that. I get a kick out of trying to make a 2.8
release happen as soon as possible as well as improving the way we
work so that we can shorten our release cycles, so that's what I do.

Best regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tool presets

[Martin Nordholts]

2011/9/5 Alexia Death :
> Since when does adding default resources counts as a feature or
> involves significant amount of coding and risk of breakage? I would
> agree if this was a coding task. It is not. If it was, there would be
> something very wrong with the setup. We sort of promised our users
> better resources with this release but nobody has take it up... The
> very least we could do is to provide some defaults for the new things
> so people know what it does.

What I call "feature" is something that makes GIMP better and that we
don't _have_ to do. Having default tool presets is better than not
having default tool presets, but it is not something we _have_ to do
before releasing 2.8, so adding default tool presets is a feature.

When I say that we should not do this to 2.8, I say that because I
want us to make a 2.8 release as soon as possible. However, people are
of course, as always, free to work on whatever they want to.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tool presets

[Martin Nordholts]

2011/9/5 Alexandre Prokoudine :
> On Mon, Sep 5, 2011 at 9:00 AM, Martin Nordholts wrote:
>
>> This is not something that blocks a 2.8 release and we badly badly
>> need to make a release. This should wait until after 2.8.
>
> How does it prevent you from releasing 2.8?

Any feature we add at this point will delay the 2.8 release because
someone needs to actually write the code, test the feature, fix bugs,
take feedback into account etc. Even if we get a patch from the
outside, a core developer basically needs to do all of the above
except writing the initial code. With limited resources, we have to
prioritize. And releasing 2.8 has higher priority than having default
tool presets. We can always add those later. And with the shorter
development cycles we aim for, it's not a big deal if a feature makes
it into x.y or x.(y + 2).

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tool presets

[Martin Nordholts]

2011/9/5 Alexandre Prokoudine :
> Hi,
>
> We currently have the new Tool Presets dockable dialog that has zero
> factory preset. Maybe we should should opulate it a bit? Some cropping
> presets for popular photo paper formats, DVD and whatnot? Steal some
> presets for painting tools from G-P-S?

This is not something that blocks a 2.8 release and we badly badly
need to make a release. This should wait until after 2.8.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSOC-2011 - Gimp plug-ins to Gegl operations

[Martin Nordholts]

2011/8/26 Robert Sasu :
> Hello,
>
> Here is the list of op's I ported (made):
> 1. Color rotate
> 2. Color to alpha
> 3. Convolution matrix
> 4. Cubism
> 5. Deinterlace
> 6. Emboss
> 7. Fractal-trace
> 8. Lens correct (with Lensfun library)
> 9. Lens-distortion
> 10. Plasma
> 11. Polar-coordinates
> 12. Red-eye-removal
> 13. Ripple
>
> I also made a showcase: http://sasurobert.github.com/GSoC-2011/
>
> It was a really amazing experience, and I will continue to port plug-ins
> and/or make some tools (anything you need) after GSoC.
> Thanks for everything.

Hi Robert

I must say, really great work! This will be very useful as we fully
transition to GEGL. Nice presentation too.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [PATCH] Fix deprecated usage of gimp-free-select

[Martin Nordholts]

2011/8/22 Nelson A. de Oliveira :
> Hi!
>
> Can somebody review and commit it, please?
> http://people.debian.org/~naoliv/misc/0001-Fix-deprecated-usage-of-gimp-free-select.txt
>
> Thank you!

Hi Nelson

There is already a patch that does this that no one have had time yet
(due to priorities) to commit:
https://bugzilla.gnome.org/show_bug.cgi?id=647834

Thanks anyway,

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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

[Martin Nordholts]

2011/8/22 Thales Oliveira - WeAreLinux.com :
> I'm sorry, hasn't it been available for a while? At least I have been using
> 2.7.3 for months. Great news anyway.

There is lot of confusion regarding this, which is why I think we
should start with GEGL-like version numbering, i.e. odd micro numbers
for code in git, even micro numbers for releases.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Tab in Single Window-Mode

[Martin Nordholts]

2011/8/15 Jeremy Morton :
> Speaking of tab in single-window mode, does Ctrl-Tab work for switching
> tab yet?  If not, is this planned?

Ctrl+Tab will continue to cycle between layers, at least in GIMP 2.8.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Tab in Single Window-Mode

[Martin Nordholts]

2011/8/13 Robert Hildebrandt :
> Hello Guys,
>
> I love using Gimp with the new SingleWindow-Mode but I've got a little
> issue:
>
> I like using Tab to maximize and minimize the  working area, which works
> very fine -- except one of those widgets outside gets the focus, so
> using Tab just changes the Widget with Focus.
>
> I haven't found a way to change the shortcut from "Tab" to something
> different (a way to search for the used keys in the shortcut Dialog
> could be also nice).

Hi,

The 'Tab' key is a bit special because GTK+ doesn't allow 'Tab' as a
keyboard shortcut, right now it's hardcoded. It can be changed though
to something normal with the Keyboard Shortcuts dialog.

'Tab' must at least mean "switch focus between widgets", we must not
change that. So for now, I would recommend you to simply change the
shortcut to something else. I doubt it would be worth to spend time
adding code in special places just to get "Tab for dock visibility" to
work. It is quite an odd choice of keyboard shortcut in the first
place, and imho we should look into another default key for this.

 / Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Dockables aren't disposed when closing floating dock window

[Martin Nordholts]

2011/8/13 P S :
> This is my first post in gimp-dev so forgive me if I happen to miss
> out context or interfere with current work in progress.
>
> It turns out dockables aren't disposed after a gimp_dock_dispose()
> call in the current master. gimp_dock_dispose() only removes dockbooks
> which will not be disposed if references are still held by attached
> dockables.
>
> The behavior is particularly notable on singleton dockables when
> closing a floating dock window:
> 1. Add a new tab Tool Options to main dock
> 2. Drag out or detach Tool Options tab to a floating dock window
> 3. Close the floating dock window
> 4. Try to re-insert Tool Options tab in main dock. Doesn't work - as
> floating dock's dockbook hasn't been disposed and Tool Options
> dockable is still attached to it

You don't happen to be running Ubuntu 11.04 are you? Their GTK+
installation seems to be broken. Try building GTK+ yourself,
preferably GTK+ 2.24.5 and see if the problem goes away.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] SingleWindowMode-Issue

[Martin Nordholts]

2011/8/6 Robert Hildebrandt :
> Hello Guys,
>
> I love the new singlewindow mode. But there'se still (today fetched,
> merged and compiled) got one issue in
> the current version:
>
> I like to work with the single Window mode when it's maximized, but
> everytime I open a new Image or close an opened one, the window returns
> to normal mode.

Hi

Thank you for your feedback. It is indeed quite annoying and I will
fix it before we release GIMP 2.8. There is already a bug report for
it:

Bug 650348 - Window unmaximizes when a document is closed
https://bugzilla.gnome.org/show_bug.cgi?id=650348

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)

[Martin Nordholts]

2011/8/2 Michael Muré :
>> #: ../app/gegl/gimpoperationcagecoefcalc.c:82
>> #: ../app/gegl/gimpoperationcagetransform.c:118
>> msgid "A GimpCageConfig object, that define the transformation"
>
> For now, this string won't go to the UI, but it might happen in the future,
> when gegl will be integrated, so I keep it marked for translation.

Hi Michael,

I strongly doubt it would make sense to bother our users with names of
GObject classes, could you elaborate on why we should do this?

Best regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSoC GimpUnitEntry: Review round 2

[Martin Nordholts]

2011/8/1 Enrico Schröder :
> Hey Martin,
>
> just a small status update: starting on documentation and fixing your review 
> comments now. (Have been busy with moving to my new apartment last week).
>
> By going through your review comments I noticed that your diff file 
> incorporates some old code (e.g. all that gimp_prop_coordinates_*2 stuff) 
> which I already removed. Have you used an old revision?
>
> BTW: Of course I will continue working on GimpUnitEntries and maybe other 
> parts of Gimp after GSOC, but since there is roughly a month left of official 
> project time, what do you think needs to be done for my project to be rated 
> "successful"? Anything major except documentation and fixing your review 
> comments? How about porting (which is ~75% done I guess), does that need to 
> be complete until end of august?
>
> Best regards,
> Enrico

Hi

(Keeping gimp-developer on CC)

I had trouble finding time to do the review, so the snapshot I was
reviewing is quite old by now, but hopefully most comments still
apply.

It would be great you could keep contributing also after GSoC.

Regarding being rated "successful", just do your best addressing the
review comments. Your project basically already is successful :)
Porting all GIMP to use the new widget is not as important as having
the GimpUnitEntry widget itself fully completed, tested and
documented, so focus on the latter.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] prerequisites not building on F14

[Martin Nordholts]

2011/8/2 Michael J. Hammel :
> Gdk-2.0.gir: error: Type reference 'GdkPixbuf' not found
>
> I've built and installed the prerequisites, including gdk-pixbuf,
> to /usr/local/gimpgit.  I've tried building gobject-introspection but
> that doesn't build either.  I didn't think that was required for pre-3.0
> anyway (side note: should latest GIMP GIT build with 3.0?).  I was under
> the impression that the "gir" stuff was from the introspection stuff,
> but maybe not.

Is the .gir file for GdkPixbuf installed? If not, that's probably why
you get the error. If you have problems building the introspection
files, try passing --disable-introspection to configure for all
dependencies.

And no, GIMP git master doesn't build with GTK+ 3.0, but mitch's
gtk3-port branch does.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Small nightly builds-tool update

[Martin Nordholts]

Hi,

This is a small update on some changes I have made on our continuous
integration tool Jenkins that is hosted here:
http://gimptest.flamingtext.com:8080/

With the addition of nightly tarball builds of feature branches, in
particular for some of our GSoC projects, there is a new naming
convention for jobs:
--

Examples:
* The name of the distcheck job for the master branch of babl is
'babl-distcheck-master'
* The name of the distcheck job for the soc-2011-gimpunitentry branch
of GIMP is 'gimp-distcheck-soc-2011-gimpunitentry'

Also, I have stopped using the GNOME Project Builder plug-in for all
our jobs and started using plain shell commands instead. This makes
job configuration more straightforward and adaptable. For reference, I
have included the commands used to build and publish the nightly GIMP
git master tarball at the bottom of the mail.

 / Martin


#
# Constants for this build
#
PREFIX="$HOME/prefix/babl-gegl-gimp"
TARBALL_NAME="gimp-git-master.tar.bz2"

#
# Clean up distdir from previously failed distchecks to prevent make
# check from being confused
#
package="`grep '^PACKAGE = ' Makefile | awk '{print$3}'`"
version="`grep '^VERSION = ' Makefile | awk '{print$3}'`"
distdir="${package}-${version}"
test ! -d "$distdir" || \
  { find "$distdir" -type d ! -perm -200 -exec chmod u+w {} ';' && \
rm -fr "$distdir"; }

#
# Build
#
./autogen.sh --prefix=${PREFIX} --enable-gtk-doc
make
make check
make install
make distcheck

#
# Rename built tarball so it always have the same name
#
ls -1t *.tar.* | head -n 1 | xargs -I fff mv fff ${TARBALL_NAME}

#
# Publish to ftp
#
cp ${TARBALL_NAME} /var/ftp/pub/nightly-tarballs




-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GSoC GimpUnitEntry: Review round 2

[Martin Nordholts]

Hi

Here are my review comments from a rather detailed review round. I've
looked carefully at the GimpUnitAdjustment and GimpUnitEntry APIs, as
I believe we can get the API in a state good enough for inclusion in
the GIMP 2.10 plug-in API (that will also survive into GIMP 3.0).
GimpUnitEntries should still be kept around, but not as part of a
backwards compatible public API, only as a private convenience for us.
Same goes for your new gimp_prop_*()-functions and GimpUnitParser. I
did't look very closely at the GimpUnitEntries implementation or API
this time. I didn't look very close at GimpUnitParser either since
it's a small internal helper which is always nice.

The diff with comments can be found here:
http://files.chromecode.com/gimp/gimp-soc-2011-gimpunitentry-review-2011-07-17.txt

Your focus now should be on fixing the review comments (and coding
style and documentation) rather than continuing to port GIMP app to
use GimpUnitEntry as there is not much time left in the project.

Keep up the good job :)

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSoC GimpUnitEntry: Review round 1

[Martin Nordholts]

2011/7/16 Enrico Schröder :
> Ok, I will define the defines ;-) Should the common ones be declared in 
> gimpunitentries.h or should each class/file define them themselves when 
> needed?

Put them in gimpunitentries.h for now. Later we will move
gimpunitentries away from libgimpwidgets anyway until we have a
GimpUnitEntries interface we believe in.


> The function automatically adds a preview label to the table, showing the 
> value of the entries with id1 and id2 in the given unit. I noticed that the 
> new image dialog (and a couple of others) were using a kind of preview label 
> (provided by GimpPropWidgets), so I thought it was nice to have for other 
> use-cases as well. Since GimpUnitEntries is a convenience class, I wanted to 
> provide an easy way to create such a preview label. Maybe some plugin could 
> use it someday. Since it's already there and working, why remove it? It 
> doesn't harm anybody, and we don't have to use it in the standard gimp 
> dialogs. If we keep it, we'd need a better name though, e.g. 
> _add_preview_label.

Ok let's keep it, but don't add such a label where there wasn't one
(like in the New Layer Dialog).


> Makes sense, I will implement that. GimpEevl even provides the position at 
> which an error occurred, don't know how accurate it is though. I will look 
> into maybe providing a little better error indication than just painting 
> everything read.

Sounds good. I would like to remind again though about that our main
focus right now is to get a basic GimpUnitEntry to work and integrate
it in GIMP, so unless you don't have other things to do, don't work on
error indication.


> I must say separating the entry-management from creating the UI-container 
> sounds a bit cleaner than it is now. But you had your concerns with that, 
> right?

Don't know yet :) Let me get back on that.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSoC GimpUnitEntry: Review round 1

[Martin Nordholts]

2011/7/14 Enrico Schröder :
> Hi
>
> I've adressed most of your comments by now. I have a few comments myself
> though, which I wrote directly in the file. I marked them with '##' so you
> can search for them.
>
> The file with the comments is to be found here:
> http://userpage.fu-berlin.de/enni/soc-2011-gimpunitentry-comments-2011-07-16.txt

Moving discussion out of the text file:

> String literals to identify entries is a bit too runtime-ish (still
> better than a numeric literal though), would be better to allow the
> compiler to tell you when you made a typo. When/if you have time,
> perhaps add a
>
>  gimp_unit_entry_table_add_default_entry (table, GIMP_UNIT_ENTRY_TABLE_WIDTH)
>
> ?
>> The problem with that is that you are limited in how to name your
>> entries.  What if you want to use GimpUnitEntryTable for, say, the
>> radius of a circle.  Sure you can define additional enums/defines,
>> but that yould result in longer code (and we would be back to using
>> int for id's, I bet people would just use 1 and 2 instead of
>> defining their own constants).  If you make a typo, there is a
>> g_warning() in place which tells you that that entry doesn't
>> exist. But maybe we need to discuss further ;)

Let's use the best of both worlds, keep gimp_unit_entries_add_entry()
but provide #defines for the common ones:

  #define GIMP_UNIT_ENTRY_WIDTH "width"
  ...

so that the compiler catches typos. For entry IDs used once, #defines
are not needed.


>  + gimp_unit_entry_table_add_label (options->size_se, GIMP_UNIT_PIXEL, 
> "width", "height");
> I don't understand what this line does, what label? Maybe there is a
> better function name?
>> That function-call automatically adds a label below "height" to the
>> table, which displays the value of "width" and "height" in pixels
>> (see the new layer dialog). Maybe
>> gimp_unit_entry_table_add_preview_label would be a better name? I
>> figured that it might be a good feature to be able to preview the
>> value in pixels while inputting another unit.

I can see the label being useful for debugging, but if a user inputs a
value in inches, he is likely not interested in the value in pixels.
The few that are can temporarily switch to pixels to see. But, since
most are not interested, we should not clutter the UI with that info.
So IMO the function should be removed.

Another thing:
Add a timeout on the red background that is shown on invalid input.
When typing in normal speed, the intermediate state should not flash
"error", becuase no error has been made. For example, if I type "10
in" in normal pace, the entry will flash in red while in the "10 i"
state, which is annoying and distracting.

I'm going to make another full review of your code now that you've
addressed many of the comments, and I will think extra on the fate of
GimpUnitEntries, as we discussed on IRC yesterday.

Nice job so far!

BR,
Martin


--

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GIMP 2.8 schedule update, one month slip

[Martin Nordholts]

Hi everyone,

I just went through our GIMP 2.8 schedule at
http://tasktaste.com/projects/Enselic/gimp-2-8 and made some
adjustments and about a month was added to the release date estimate
because of it. I would like to describe the adjustments I did, check
the status of the various tasks, and discuss if we can do anything to
get 2.8 out faster, or if there maybe is more work left to do on
2.8 than the schedule reflects.

Changes I did:
 * Removed "Bug 647834 - Stop using deprecated API in plug-ins"
   because the problem doesn't exist in stable versions, only in
   development versions

 * Lowered size of "Bug 631934 - Interaction between Old text
   parameters and new region specific text attributes" from 8 to 5
   working days because that seemed to me like a better
   estimate. mitch?

 * Added "Make window mode switching less destructive", because we (I)
   need to prevent dock windows from being placed on top of each other
   when switching from single-window mode to multi-window mode

 * Added "Single-window mode related bugfixing buffer" because I
   expect some single-window mode related bugs to pop up that I need
   to fix

 * Added "Bug 645120 - Disable color tools overlay dialogs"

Status of tasks:
 * I'm going to take care of all single-window mode related tasks +
   "Bug 596410 - gimp-image-get-filename returns NULL for imported
   files".

 * Regarding "Bug 642728 - Use cairo to draw Gfig", I don't think this
   blocks 2.8, we can use the old way of drawing in 2.8. Objections to
   me removing it from the schedule? I know Mikachu has started the
   porting. If he finishes before 2.8 is released that's great, but
   not having GFig ported to cairo in 2.8 isn't a blocker IMO.

 * Regarding "Bug 304798 - Painting brush outline is slow", is this
   still a big problem? I know Alexia and mitch has worked on this.

 * Regarding our biggest tasks, "Bug 612931 - Moving individual layer
   in layer group not possible with Move Tool" and "Bug 51112 -
   clipping groups or masking groups (like in Photoshop files)", maybe
   I have over-estimated these? What do you think mitch?

Any other tasks you'd like to discuss? Any tasks you'd like to add to
the GIMP 2.8 schedule?

Overall the progress on tasks have been good. The reason we have a
small slip is only because new things have been added to the schedule
that was not originally included. Thanks to everyone that has helped
out completing tasks so far! Keep it up.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GSoC GimpUnitEntry: Review round 1

[Martin Nordholts]

Hi Enrico,

I've made a first review-round of some of your new code. It's not a
complete review, but it's a start. I hope the to-the-point comments
are OK, I don't mean to be rude.

Note that I'm CCing gimp-developer to keep our correspondence public.

I've done the review by diffing origin/master with
origin/soc-2011-gimpunitentry (after locally merging master to your
branch) and put the result in a text file, then adding comments
inline. The patch has been indented 8 spaces to make the comments
stand out more. The diff with comments is found here:
http://files.chromecode.com/gimp/soc-2011-gimpunitentry-comments-2011-07-04.txt

If you have comments on my comments, just continue this email thread.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] new color system ready for GIMP

[Martin Nordholts]

2011/7/8 GiveLifeCS :
> Hi Martin Nordholts , I will try to explain your questions:
>
> I have invested approx. 4 years to do this color system
> It was a very manual I mean, that was without using any type of
> mathematical algorithm, but one by one watching and analyzing the colors
> and noting that these colors are expressed in C, M, Y, K had not other
> colors systems in the world today.
>
> The composition or organization of special colors is not governed like
> other color systems have done in different ways, but it has its
> explanation only thing I like is not to comment further.
> Something really important thing I've seen these years is that any color
> system in the world has sought and continues to seek equivalence with
> Pantone, now is that everyone knows.
>
>
>
> GiveLifeCS has never followed any time the color matching with other
> color systems, so I think it has something to offer.
>
> To me, all color systems are good but working with GiveLifeCS and other
> color systems is making an awesome way to enrich the color variations
> making it as simple as this is "a tool for the creative -designer with
> new shades "
> and one software design like GIMP needs a unique color system.
>
> Givelife CS is currently online for only 4 months, I mean it's actually
> doing is new to users.
>
> Actually, I have not invented anything new, in the world there are some
> color systems ,they are good for me.
> and the color palettes for any software design you need to pay it, but
> with GiveLifeCS never , because the color palette of GiveLifeCS will be
> free always.
>
> I am currently working on another palette and will continue with the
> same philosophy as for ubuntu , gimp, linux etc. ..
> I was inspired in the way of distribution of GIMP.
>
> Givelife CS is from the south of Europe (SPAIN)
> For This reason it is the first color system Latino & Hispanic in the
> world ,than i am aware.
>
> the software design should have a system of color or multiple color
> systems that really helps the user design software
>
> By default when a designer does not work with color systems standardized
> way, without wanting to use always or almost always the same colors, but
> it is a contradiction and I say so pure experience.
>
> greetings and good luck
> Gabriel
> GiveLifeCS
>
>
> please very sorry if my english is not so good i use google to translate
> i hope you will understand all ,but if you have any question else please
> contact me.
>
> Thank you in advance
> i wait for your news

Hi

I am afraid going through Google Translate creates too much ambiguity.
To to discuss this we need to be able to communicate efficiently.

I am sharing your reply with gimp-developer anyway for completeness...
please keep the mailing list in this email thread if you make a reply.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] new color system ready for GIMP

[Martin Nordholts]

2011/7/7 GiveLifeCS :
> Hi developers of GIMP
>
> my name is Gabriel Vano
>
> I created a NEW COLOR SYSTEM with 2265 new shades, the color palette is
> free for various design software including GIMP. MY QUESTION FOR THE
> DEVELOPERS IS:
> Someone can help me to get in touch with the developers of GIMP to try
> out this new color system and to study the possibility of including it
> in GIMP by default?
>
>
> I have been in contact with you, precisely because I think than this new
> color system will be right for GIMP and of course for all users of GIMP
> this is a new tool for the Creative-Designer.
>
>
> My thanks in advance.

Hi

Could you elaborate a bit on how you have chosen the colors you have
chosen and how they are defined?

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSOC] GimpUnitEntry - integration into grid editor

[Martin Nordholts]

2011/7/1 Enrico Schröder :
> Hi all,
>
> during the integration of the new UnitEntry widget into Gimp I came
> across the grid editor. At the moment it uses two rows, one for entering
> the value in pixels, one for entering it in another unit (cm, inch etc).
> Both display the same value.
> Is there a reason for not using just one row and letting the user select
> if he/she wants to enter pixels or other units? I don't see one and
> would just implement the dialog that way, if you don't say "hold on, we
> need it the way it is"... ;-)

Hi,

No reason is mentioned in the initial commit
(edd5c33923a574a278a74d56ca770f6072e0ffc6), the referenced bug (Bug
65198 - Ability to show a grid) or the manual
(http://docs.gimp.org/en/gimp-image-configure-grid.html). I don't see
a good reason either, it just seems silly. So feel free to have only
one row when you port to GimpUnitEntry.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Isn't this behaviour unintuative?

[Martin Nordholts]

2011/6/30 peter sikking :
> no, nothing changed in the Overwrite workflows.
>
> today's changes can be summarised as:
>
> - in the cases where before Export to was insensitive, it is
>  now sensitive and mapped to invoke Export... (the dialog)
>
> - in the cases where Overwrite blocks Export to out of the File menu,
>  the shortcut of Export to is still active and mapped to invoke Export...
>
> everything else works like before

Thanks for the clarifications, I've made this change now:

commit c73bdc097188a926f01062a009f9f22ff32dad4e
Author: Martin Nordholts 
Date:   Thu Jun 30 23:44:50 2011 +0200

app: Make 'Export to' fall back to 'Export...'

Make 'Export to' always sensitive (as long as there is an image at
all). And make it fall back to 'Export...' if no export target has
been set yet. Note that it is not necessarily visible at all times,
sometimes 'Overwrite' shadows it. It shall still be invokable though.

Reference:
[Gimp-developer] Isn't this behaviour unintuative?
http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html


@Jeremy: Does this work better?

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Isn't this behaviour unintuative?

[Martin Nordholts]

2011/6/30 peter sikking :
> I wrote:
>
>> I will update the spec now to formalise this.
>
>
> done, and it was not a one-liner.
>
> Martin (prime suspect for implementing the change): please do
> a careful diff in the wiki to see the changes.

It looks straightforward and I expect to be able to update the code for 2.8.

One gripe: The spec says "give secondary support to workflows where
the input and output are the same non-xcf file" and you just made this
a bit harder (OK-ing the Export to dialog)

For the record: Would you still want the new approach in the spec if
Ctrl+E would previously have been an unused keyboard shortcut?

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Isn't this behaviour unintuative?

[Martin Nordholts]

2011/6/30 Jeremy Morton :
> My suggestion is an export (to the
> original file name and file type), but with a 'are you sure you want to
> overwrite?' dialog before the export happens, with the focus
> automatically on the cancel so 'enter' will cancel the export.

The popup is good when the user did in fact not want to overwrite the
file, whenever the user *do* want to overwrite the file, that popup
will be very annoying. Imagine a "are you sure you want to
save"-dialog each time you press Ctrl+S.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Isn't this behaviour unintuative?

[Martin Nordholts]

2011/6/26 Jeremy Morton :
> When I open a non-GIMP format file, like a PNG, by drag-dropping it into
> GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and
> nothing happens.  This is because what I actually have to do is select
> "File | Overwrite (filename.png)".
>
> Wouldn't it be more intuative to behave as if you'd just exported
> (filename.png), or whatever file you've just imported into GIMP, so that
> once you've edited it you can just press ctrl+E and easily export it
> back to its native format?

Yes it would be more intuitive, and that was also the initial design.

The reason it works the way it works today is to avoid data-loss. In
GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View ->
Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In
other words, this sequence of events is harmless in GIMP 2.6:

1. File -> Open file-I-dont-want-to-lose.jpg
2. Make some significant changes
3. Press Ctrl+E

while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we
made Ctrl+E invoke Overwrite by default and a user, quite reasonable,
expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing
users to manually assign Ctrl+E to Overwrite, they would confirm that
"ok I know Ctrl+E will potentially destory my originals".

That file-overwrite and file-export can't have the same keyboard
shortcut is a bug, that is meant to work. Quite an oversight that it
doesn't...

Once people have learned that Ctrl+E is export and not Shrink Wrap, we
can make Ctrl+E be the default keyboard shortcut for both Overwrite
and Export. Until then, I just made a commit so that you can use
Alt+F, W instead at least:

commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e
Author: Martin Nordholts 
Date:   Tue Jun 28 08:53:45 2011 +0200

Make 'w' a mnemonic for File -> Overwrite ...

See

  [Gimp-developer] Isn't this behaviour unintuative?
  http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html


Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] GimpSizeEntry widget

[Martin Nordholts]

> 2011/5/30 Enrico Schröder :
>>    Martin Nordholts <mailto:ense...@gmail.com>
>> 30. Mai 2011 11:04
>>
>> Hi again
>>
>> How's it going?
>>
>> Best regards,
>> Martin
>
> Hi Martin,
>
> sorry for the long pause, finished my exams last week (with moderate
> success...) ;)
> Been working on the widget again to get it ready for the initial upload.
> Many things are missing and incomplete, but basic parsing and communication
> between two entries is functional. Right now I'm working on integration of
> the GimpUnit system into the GimpEevl unit resolver callback.
> I also updated the schedule on TaskTaste into smaller steps. Not everything
> is listed there, but I will add tasks as soon as they come to my mind.
> Maybe I will do the initial commit later today. Will my repository be set up
> or can I do that manually?
>
> Best regards,
> Enrico


Hi

I hope the exams went well after all ;)

You got your GNOME git keys, right? If so, you can create a feature
branch yourself in the GIMP git.

# create your local branch
git checkout -b local-branch origin/master
# Do some changes...

# Create/push to the feature branch
git push origin local-branch:soc-2011-gimpsizeentry

# Every now and then
git merge origin/master

I would like task sizes at
http://tasktaste.com/projects/enni/gimpsizeentry to be at most 1 week
so we have a chance to follow up on the progress. Once you have
created your branch, I will set up our nightly builder at
http://gimptest.flamingtext.com:8080/ to create nightly tarballs of
your branch so people can easily try it out.

Looking forward to look at your first pushed commit :)

Note that I CC:ed gimp-developer

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] GimpSizeEntry widget

[Martin Nordholts]

2011/5/14 Enrico Schröder 
>
> Hi Martin!
>
> Parsing is done via GimpEevl which is called from the UnitEntry. I think it 
> makes sense because the entry is responsible for input and output, the 
> UnitAdjustment holds the value. GimpEevl does not require any UI. Or did you 
> mean our get_unit method? Maybe it would make sense to modify GimpEevl to 
> also determine the unit?

Hi!

Yep I meant the get_unit() method on GimpUnitEntry, it should be
possible to get_unit() also in the non-UI layer.

Yes it probably is a good idea to let gimp_eevl_evaluate() return the
unit of the expression. It shouldn't know anything about the unit
itself though, like today, where the knowledge of units is abstracted
away through a GimpEevlUnitResolverProc parameter.


>> * Have you thought about how the image resolution comes into the picture?
>
> Would it be ok to have our UnitAdjustment hold the resolution along with the 
> actual value? It does belong together. However, the problem then would be if 
> we want our entry to be used to input a resolution. We could make that work 
> by using just the resolution field of our adjustment, but that would not be a 
> very elegant solution. So another class "GimpResolutionAdjustment"?

It's fine to keep the current resolution in GimpUnitAdjustment. As far
as I know we haven't had problems with
gimp_size_entry_set_resolution() and a similar interface for
GimpUnitAdjustment will make it easier to port code to use the new
classes.

To use GimpUnitEntry for resolution input, a good solution would be
based on yet another abstraction, perhaps GimpUnitEntryBehavior, with
subclasses GimpSizeBehavior and GimpResolutionBehavior. We don't want
to end up with lots if cases on some mode variable (like GimpSizeEntry
has for GIMP_SIZE_ENTRY_UPDATE_SIZE and
GIMP_SIZE_ENTRY_UPDATE_RESOLUTION).

However, the details of GimpUnitEntryBehavior is hard to predict, so
let's focus on a size-only GimpUnitEntry first. When we're done with
that we can see what of the code we should move out in a
GimpUnitEntryBehavior abstraction to also support resolution input.
Resolution input is in many ways similar to size input, it's just a
different set of units and slightly different constraints.

I think we have thought enough about design matters for now, and it's
time to start writing some code (I suspect you already have started
doing that ;) ). Before doing that though, please update
http://tasktaste.com/projects/enni/gimpsizeentry with as small tasks
as you can. The smaller tasks we have, the better can we track project
progress and discover when we need to do something in order to meet
our deadlines. Don't worry if you can't yet split them up as much as
you'd like to though; we're still early in the project. As we move
along, exactly what we need to do will become more and more clear, and
we can update the schedule accordingly.

Very good job so far!

Best regards,
Martin


--
My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] GimpSizeEntry widget

[Martin Nordholts]

2011/5/9 Enrico Schröder :
> Hi everybody,
>
> I've come up with a updated (and more detailed) version of class and
> sequence diagrams for the new widget.
>
> http://enni.userpage.fu-berlin.de/GimpUnitEntry.pdf
>
> I tried to incorporate some of the comments. Note that all names are
> subject to change ;-)
> Our now called GimpUnitEntry will be derived from GtkSpinScale and use a
> subclass of GtkAdjustment to store its value including the unit
> (GimpUnitAdjustment). All synchronisation and live updating of
> associated UnitEntries will happen directly between their
> GimpUnitAdjustments, thus completely separating everything value-related
> from the gui and input. The GimpUnitEntry itself will be just
> responsible for display and parsing of entered terms. See use cases and
> class diagram for details.

Hi Enrico,

Good job! Very clear. Some comments, questions and design concerns:

* I think the class names are fine.

* The parsing should also be perfomed by a non-UI layer and not in
GimpUnitEntry so the parsing code can be used in e.g. a script
interpreter with no UI dependencies.

* Yes, try to reuse GtkAdjustment::value-changed. Only if that doesn't
work for some reason should you duplicate the signal in
GimpUnitAdjustment.

* GimpUnitEntryTable shouldn't derive from GtkTable, because there is
no is-a relationship. To convince yourself of that: Can you always
replace a GtkTable with a GimpUnitEntryTable? Nope, so you should use
composition instead of inheritance.

* In case mitch didn't already tell you: The easiest way to create a
new class including all C GObject boilerplate is to copy an existing
class and do word-wize and case-preserving (like Emacs)
search-and-replace. For example, to create GimpUnitAdjustment, copy a
GObject inherited GimpDoubleWorded class and first replace 'double'
with 'unit', then 'worded' with 'adjustment'.

* I've recomended a test-case based development approach before, and
now that most of the code will have no UI-dependencies I recomend it
even more, as non-UI classes generally are very easy to unit-test. An
example of a commit that introduces a non-UI class along with
appropriate propotions of documentation and unit tests is this commit:
http://git.gnome.org/browse/gimp/commit/?id=9fefa22efe70e484fc7c92708ed8efe023e4d219
By writing unit tests along with your code, productivity goes up a lot
when you (or anyone in the lifetime of the project) refactor code,
because verifying the class still works takes seconds.

* Regarding the use case of entering "1 cm" and getting the result in
px, we could use an 'in' keyword like Google. Analogous to "100 SEK in
USD", we would have "1 cm in px". That is a future extension though,
don't spend time on that yet.

* Have you thought about how the image resolution comes into the picture?

* Regarding your get_unit() method, an interesting question is what
unit an expression like "10px + 1cm" has.

* Have you thought about how to connect GimpUnitEntry to the existing
GIMP code like the various props helper functions? (See how
GimpSizeEntry currently is used)

* I don't like how constraints currently are applied, in particular
that you require two instance of a constraint when there is only one
equation that shall hold. I don't think it is a good idea to make
GimpUnitAdjustment (or GimpUnitEntry for that matter) be aware of
constraints, because they can potentially be rather complex. It is
probably a better idea to take care of constraints one one
architectural level above GimpUnitAdjustment (they don't know about
constraints, constraints are just being applied to them).

* Regarding the contraint case, for a good design, consider how you
would support constraints between three numbers (e.g. a = b + c).

* Again, I would advice you to focus on the basics. Once the basic
functionality is in place, meaning it is good enough for inclusion in
a stable GIMP version, we can start working on constraints support.

* What program did you make those rather nice sequence diagrams in?

Best regards,
Martin


-- 
My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] nonlinear revision control system for GIMP

[Martin Nordholts]

2011/5/3 Tim Chen :
> Hi Martin,
>
> It sounds like that there are other thoughts about how to implement the macro 
> system? During my GIMP hack last year, my impression was that macro recording 
> should be done in PDB. And I did not do so because not every functions went 
> through PDB, e.g. those stroke functions (please correct me if my memory did 
> not serve me right).

There have been discussions of other approaches than the Command
design pattern. Making use of the PDB somehow probably is a good idea,
although that won't work for things that a use can do but that w don't
have PDB calls for yet.

> In any case, the GIMP community helps me a lot and I do like to contribute 
> something back, i.e. integrate my system into GIMP core.

That sounds great. The best way to take in a large thing like this is
by doing it step by step. Divide your work into small commits that we
can take in upstream piece by piece without introducing any bugs or
regressions. Eventually you'll have the platform you need to land the
final parts that enables your work for users.

 / Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [GSoC] GimpSizeEntry widget

[Martin Nordholts]

2011/5/2 Enrico Schröder :
> Hi all,
>
> i've come up with the first concept for the rewrite, including a class
> diagram and sequence diagrams for a few use cases:
> http://enni.userpage.fu-berlin.de/GimpSizeEntry.pdf
> Note that it mainly shows how the different components work together,
> not how each component does its work internally. If I forgot something
> (and I probably have ;-) ) please tell me.
> Martin: I planned on integration the keep-aspect-ratio functionality
> right away, because I don't think it's to much additional work.

Hi Enrico

That's a good start! A couple of comments

 * As this project is not about refactoring GimpSizeEntry but instead
write a new widget from scratch so we can get it right this time, we
need a new name. I could think of GimpDimensionEntry and
GimpUnitEntry, feel free to come up with something better.

 * The sequence diagrams should be on the class interface i.e. method
level. For example, in the "simply entering two values" sequence
diagram, what classes and method calls will be involved in order to
let GimpSizeEntry b know about GimpSizeEntry a? (I don't understand
why in that use case they need to know about each others value at all
though, they are independent, aren't they?)

 * You should put some thought into what exactly happens during
"enters value a", "enter value in a new unit" etc. You'll get a
GtkEditable::insert-text signal, but then what? Some kind of parsing
needs to take place. Take a look at GimpEevl which is a unit parser we
already have, resuing that would be ideal.

 * In the "Changing aspect ratio" sequence diagram, a good design
would have an abstraction for the aspect ratio constraint, so that it
would be equally easy to have a constraint between two entries that
said "entry_a = entry_b + 100" as it is to have "entry_a = entry_b *
1.33". Think a base class GimpUnitConstraint with GimpOffsetContrainst
and GimpAspectRatioConstraint sub classes. In order to verify a design
for the aspect ratio preservation use case, what GimpUnitEntry classes
and method calls are involved in the following situation (which is the
main use case for aspect ratio preservation):

The current image has a pixel size of 200x100. The user does Image ->
Scale Image that brings up a dialog with two GimpUnitEntries, one for
width and one for height. The user can toggle between preserving and
not preserving aspect ratio. With aspect ratio preserved, the user
focuses Width (= 200) and erases one of the zeroes. At the same time,
the Height (= 100) entry changes to "10". What method calls were
involved to make that happen? When you have a sequence diagram that
answers that, you have a design.

But, don't put too much time into aspect ratio preservation. In fact,
I would prefer if you put as little effort as possible into this right
now (except making sure not to make it impossible to extend the design
with it later). Let me explain why: There are a lot of things that
could be done on GimpUnitEntry. Let's list a few things:

 A The basic use case 'Enter a string in the form " "
and have an interface that allows the pixel value with a given
resolution to be returned.
 B The GimpSizeEntryTable you talked about
 C Aspect ratio preservation between two GimpUnitEntries

At the end of the project, it is much better if you are 100% done with
A, and 0% on B and C, than if you hare 60% done with A and 20% done
with B and C. Code that is not delivered during the end of a GSoC
project has a tendency to either take a long time to hit upstream or
never does it at all. So we should work incrementally, first focus on
the basic use case A, then we can spend time on B and C.

To summarize, there are some things to sort out before we can say we
have a design. Once we have a design, we can start looking at writing
code. Now, of course, we probably won't get the design 100% right the
first time, it's an iterative process, but we should at least have an
initial design before we start coding.


> Additionally I set up a task schedule on
> http://tasktaste.com/projects/enni/gimpsizeentry and applied for a gnome
> git account, but it probably takes some time for it to be activated.

Good, being able to track progress is essential if we want this to be
a successful GSoC project. I do think however that you should increase
the resolution of the tasks. It will be hard to follow up progress on
an 8 week big task. Let's settle on an initial design before creating
more detailed tasks though.


> Also, since I'm using a Mac and tried to not having to use a virtual
> machine, I built git-gimp natively on osx (without X11) and with a patch
> that moves the menubar from the main window to the top of the screen
> (like other mac apps). It really was a horrible experience (took me a
> whole day), so I thought it would be nice to have a precompiled
> app-bundle. As far as I know, there are no official mac binaries, right?
> The only ones I found where using X11, which isn't very good. I could
> try to provide osx

Re: [Gimp-developer] Example: Vala as code generator

[Martin Nordholts]

2011/5/3 Simon Budig :
> Martin Nordholts (ense...@gmail.com) wrote:
>> I'm trying hard to find time hacking on GIMP, and not having to waste
>> time on GObject C boiler plate means a lot to me. At first I was
>> thinking "what the hell, I'll just come up with the the damn
>> boilerplate code manually then". But right after I began doing that I
>> started to feel like I was wasting my time, and I can't stand that
>> feeling.
>
> Hm. This paragraphs leaves me a bit perplexed, because it gives the
> impression that the most important thing about including vala is to make
> you more comfortable with our codebase. You blame mitch for a blunt
> dismissal, but this reads a lot like bluntly forcing down something
> through mitchs throat. Not sure if that is any better.

You are right, that isn't any better. I should just give up on these
patches, I clearly don't have the support for them I hoped for.

Obviously, in my opinion we increase the quality of our codebase by
using Vala for this helper class mostly because the number of readable
and documented version controlled lines of code is less than if we
would also version control the GObject C boiler plate. That is not the
only measurement of code quality however and we are simply weighting
the pros and cons differently.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Example: Vala as code generator

[Martin Nordholts]

2011/5/2 Michael Natterer :
> On Sun, 2011-05-01 at 17:15 +0200, ense...@gmail.com wrote:
>> Hi all,
>>
>> We have discussed the possibility to use Vala as a code
>> generator. What follows is a set of patches so we all can see what
>> that would look like. Any objections to me pushing these commits?
>
> Yes, and I'm currently on vacation and can't respond in detail,
> but IIRC I have made myself very clear about vala.

Hi Michael,

I'm trying hard to find time hacking on GIMP, and not having to waste
time on GObject C boiler plate means a lot to me. At first I was
thinking "what the hell, I'll just come up with the the damn
boilerplate code manually then". But right after I began doing that I
started to feel like I was wasting my time, and I can't stand that
feeling. I find your blunt dismissal of these two patches really
discouraging. Can't we at least push them to master and have them in
for a while and see if we can discover some real problems? If it
really doesn't work out, we can just reformat the generated .h and .c
files and discard the .vala file.

If you are on vacation and don't have time to properly review or test
these patches, please take your time to do so. I'm not going to push
these patches without your OK, and if you're busy for a few weeks,
then I'll have to wait. I can work on other items on the GIMP 2.8
schedule in the meantime...

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] nonlinear revision control system for GIMP

[Martin Nordholts]

2011/5/2 Tim Chen :
> Hi all,
>
> Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision 
> control system for images. You can find the abstract and videos at
>
> https://sites.google.com/site/httimchen/2011_imagesvn

Hi Tim

That's great stuff.

> 1) is there anyone implementing the macro/script system

Nope there isn't, so you are more than welcomed to start doing that.
FYI, macro recording is on our roadmap found at
http://wiki.gimp.org/index.php/Roadmap.

> 2) can anyone give me a head start on how should I modify my hack so that it 
> is more readable to others? Spreading the log function into tens of files 
> certainly breaks most guideline one should follow when writing 
> object-oriented program :D

I'm convinced (others are not) we should use the proven
http://en.wikipedia.org/wiki/Command_pattern and
http://en.wikipedia.org/wiki/Composite_pattern for macro recording and
wrote some patches a while ago that introduced a GimpCommand and a
GimpGroupCommand class. I didn't have time to even turn it into a
working prototype however.

It will be necessary to make some extensions to the above patterns.
For example, you may have noticed that GIMP is quite quick to Undo and
Redo, in particular for time consuming pixel processing operations.
That's because the undo stack contains the tiles with the resulting
pixels, not only parameters used to get that result. When Redoing, the
tiles with the result can quickly be applied.

I'm imagining that we'd have code that would look something like this:

  gimp_expensive_command_execute (...)
  {
if (gimp_expensive_command_result_cached (...))
  gimp_expensive_command_apply_cached_result (...);
else
  // Do time-consuming stuff
  }

We don't want to start each GimpCommand with that if case though, so
an abstraction will be needed.

This is not a trivial refactoring, but we need to do it eventually.

Best regards,
Martin


-- 
My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSOC

[Martin Nordholts]

2011/4/27 Enrico Schröder :
> Hi Martin,
>
> thanks for choosing me for the Summer of Code. I will start working on the
> specification details of the widget at the end of the week. At the end of
> may I have exams, so I hope I can manage to start a little before the
> official coding period. My first step would be to write a little test app
> for developing the widget. Integration into Gimp will then be the last step
> after finishing the widget. Do I get a Git repository for my work or what
> are the next steps?
>
> Regards,
> Enrico
>

Hi Enrico!

It's great to have you as a GSoC student!

A small test app that can quickly be rebuilt sounds sane. You'll get
your own feature branch in GIMP's git. Have you applied for a GNOME
git account yet? If not, you should do that.

The next step is to come up with a class diagram with the main
components involved, for example GimpUnit. You should also draw
sequence diagrams for the main uses cases so we can verify that the
design we're going to have will work.

We should also create a schedule of this project before we start to
write code so we can act early if things don't go as expected and we
risk becoming late. I suggest you add a schedule to
http://tasktaste.com/. A schedule is a simple list of tasks to do and
the size of each task. The site then sums this up and shows project
progress as we complete tasks.

I'm adding the gimp-developer mailing list to CC and would prefer if
all our communication went through gimp-developer unless there content
is very private.

Again, great to have you on board! Let's get started :)

Best regards,
Martin


-- 
My GIMP Blog:
http://www.chromecode.com/
"GIMP 2.8 schedule on tasktaste.com"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Continuous update of the NEWS file

[Martin Nordholts]

Hi,

Now that 2.7.2 has been released and NEWS is up to date (thanks mitch!), 
let's make sure to keep it up to date from now on. That means that 
whenever you make a commit that is worth being mentioned in NEWS, add it 
to NEWS along with the other changes in the commit.

That way making a new release will require less effort since whoever 
makes a release don't have to go through months of commits history first.

Making frequent releases is something we want to be as easy as possible.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.8 schedule update

[Martin Nordholts]

On 04/15/2011 09:57 AM, Alexia Death wrote:
> On Fri, Apr 15, 2011 at 9:08 AM, Martin Nordholts  wrote:
>> Hi
>>
>> Two new items on the 2.8 schedule has been added:
>> * Bug 647835 - Handle deprecated GTK+ API
>> * Bug 647834 - Stop using deprecated API in plug-ins
>>
>> And one item has been fixed:
>> * Include UI tests in nightly Jenkins builds
>
> Bug 304798 - Painting brush outline is slow
> Work on this bug has progressed considerably. It now performs very
> well in most cases. There have been plans to have an alternate
> simplified brush indicator, but that is not the subject of this bug.
> As far as I'm concerned this bug can be closed.

You and mitch are the paint and brush masters, so if it's good enough 
for you, it's good enough for 2.8. Can you or mitch close the bug report 
then or at least move it off the 2.8 milestone please?

It's just that when I do

  1. new image
  2. move around the default brush outline on the canvas

then one of my CPUs work 100% in 2.7.2 and about 50% in 2.6.11. That it 
not necessarily a problem, just wanted to point it out.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.8 schedule update

[Martin Nordholts]

2011/4/15 Kevin Cozens :
> Martin Nordholts wrote:
>> The last fixed item means that we run all our tests each night now,
>> including UI tests.
>
> Um... ok... How does a buildbot run UI tests?

If the backend is X, you use http://en.wikipedia.org/wiki/Xvfb.
Although it is often more convenient to use a common wrapper script
called xvfb-run, which is also what our bulidbot uses. xvfb-run is
actually used by default always (detected during configure-time), so
if you have xvfb-run installed and runs make check, you won't see any
GIMP UI while the UI tests are run, they will run in Xvfb.

 / Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GIMP 2.8 schedule update

[Martin Nordholts]

Hi

Two new items on the 2.8 schedule has been added:
* Bug 647835 - Handle deprecated GTK+ API
* Bug 647834 - Stop using deprecated API in plug-ins

And one item has been fixed:
* Include UI tests in nightly Jenkins builds

The last fixed item means that we run all our tests each night now,
including UI tests.

The estimated release date is now 2011-11-21. To track development
progress and get an up to date release date estimate, simply visit
http://tasktaste.com/projects/Enselic/gimp-2-8 .

/ Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations

[Martin Nordholts]

2011/4/7 Robert Sasu :
> After writing the code reviews I ported the emboss plug-in to gegl. Should I
> upload to GIMP bugzilla ?

Yes please, and don't forget to reference the patch in your GSoC 2011
application.

BR,
Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Sample implementation of a new GEGL op

[Martin Nordholts]

On 04/06/2011 06:14 PM, sourav de wrote:
> I tried to implement the blur operation in GEGL. The algorithm is same
> as of the blur plug-in in GIMP. The patch file for GEGL operation and
> the blur.c file for the plug-in are attached below. Kindly let me know
> if there is any mistake in my implementation.

Please attach the patch to GIMP bugzilla and reference the patch in your 
application.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New schedule for GIMP 2.8

[Martin Nordholts]

Den 3 apr 2011 23:46 skrev "Łukasz Czerwiński" :
>
> I'd like to suggest time profiling as another task to be done before the 
> release. Once I started to optimize Gimp's startup time (especially scheme 
> interpreter) and I'd like to return to that task in the near future (when I 
> find at last some time for it :) ). What do you think about it?
>
> Łukasz

Improved startup-time is a nice-to-have, but hardly a must-have,
especially since our startup-time is not awfully bad. Most of the
things on our roadmap [1] is more important than improved startup
time. From a GIMP project point if view, it would be better if you
worked on items on the roadmap instead. But you are of course free to
work on whatever you want. We're not going to ignore a high-quality
patch that improves startup time.

Regards,
Martin

[1] http://wiki.gimp.org/index.php/GIMP_Roadmap


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New schedule for GIMP 2.8

[Martin Nordholts]

On 04/03/2011 10:31 PM, Eric Grivel wrote:
> I added a proposed patch to fix Bug 596410 to the bug report a while
> ago. Do I need to look at that again?

Nope, I just haven't had time to look at the patch yet

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] New schedule for GIMP 2.8

[Martin Nordholts]

Hi all,

I have created a schedule for GIMP 2.8 and put it here:
http://tasktaste.com/projects/Enselic/gimp-2-8

Please review the list of tasks and let me know if there are other 
things than those listed there that you know we need to do before we can 
release 2.8. In that case I will add those tasks to the schedule.

Ideally, all commits pushed to git master should be related to one of 
the tasks listed there. Being able to make a reasonable estimate for 
when we can make a GIMP 2.8 release is good for many reasons; one of 
them is that we need to know when we should enter a string freeze.

If no tasks are added and if my estimates are correct, we will release 
GIMP 2.8 on 2011-10-20.

As we all know however, making estimates is hard and 2011-10-20 will not 
be our release date, but it is the best estimate we have right now. The 
nice thing with having our schedule on tasktaste.com is that anyone 
interested in when GIMP 2.8 will be released just needs to visit that 
web page linked to above to get an overview of how GIMP 2.8 development 
is progressing and get an updated estimate for when we can make a GIMP 
2.8 release.

As a side note, I have developed tasktaste.com from scratch during the 
last few months and the source code is available under the Apache 
Licence 2.0: https://github.com/Enselic/task-taste

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] http://wiki.gimp.org/

[Martin Nordholts]

On 03/31/2011 02:40 PM, Michael Natterer wrote:
> Hi all,
>
> I'm pleased to announce that the new GIMP developer wiki
> has found its way home and is reachable as wiki.gimp.org now.

That's great! I have removed 'GIMP' from the roadmap title now since the 
domain itself has enough GIMP-weight, the roadmap can now be found at:

http://wiki.gimp.org/index.php/Roadmap


> Thanks a lot to LightningIsMyName and Alexia for starting,
> hosting, and taking care of the wiki.

Indeed, thank you Alexia and LightningIsMyName.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

[Martin Nordholts]

2011/3/29 LightningIsMyName :
> ** Re-Discussing GIMP's programming language **
> For core (non-UI), continue using GObject, use code generators (such
> as turbine) and do copy/paste/replace for existing GObject classes
> (for the rare case where the generator won't be enough).

Hi,

Unfortunately I couldn't attend the meeting and affect the outcome of
the discussion, but I still want to comment on it:

GObject C boilerplate is a general productivity problem not bound to
any specific kind of code, it doesn't make sense to treat core and UI
code differently.

Regarding code generators: that's basically how we will use Vala, I
don't see why e.g. turbine would be better to use for this.

Regards,
Martin


--

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

[Martin Nordholts]

2011/3/27 Michael Natterer :
> On 03/27/2011 04:45 PM, Martin Nordholts wrote:
>>
>> On 03/27/2011 02:12 PM, Michael Natterer wrote:
>>>
>>> As to the actual iussue of introducing whatever *additional*
>>> language in GIMP, I strongly doubt that it would help us in
>>> any way. It would increase the complexity of both building and
>>> programming because there would be two languages to learn,
>>> it would complicate the build system (new contributors
>>> would also have to learn to deal with autofoo makefiles dealing
>>> with both C and vala code). It would increase the barrier of
>>> getting new contributors into the project, not lower it.
>>
>> It's funny, because I see it the other way around. With infrastructure
>> for and knowledge about how to use Vala in GIMP, the barriers of
>> getting new contributors is lowered, because they don't need to learn
>> GObject C boilerplate before writing code. Assuming of course that
>> most of our code is in Vala already...
>
> And this is *exactly* the problem. We would end up with programmers
> that quickly learnt vala, having no clue about GObject. That's
> absolutely horrible. Just like the people who only know how
> to write java or #C code. They know how to use all the fancy
> classes, but they have never implemented a list or anything
> lowlevel themselves. I don't want people who know vala, but
> don't "had to learn" GObject. Absolutely not. Knowing the
> foundations is an absolute prerequisite for any serious
> programming.

How is it a problem that our code becomes so easy that even "dumb"
programmers can understand and improve it when we are not forced to
include patches from such "dumb" programmers? Why would an open source
project have as a goal to keep its code complex in order to limit the
set of people that are able to help out, especially a project that
wants more people to contribute? Besides, it is not only "dumb"
programmers that uses higher-level languages such as C# and Java.

 / Martin


--

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

[Martin Nordholts]

On 03/27/2011 02:12 PM, Michael Natterer wrote:
>
> So when you write code, how much time do you spend writing the
> boilerplate? 10%? I would say it's much much less, because writing
> the code is a small fraction of the time actually spent on the code,
> the rest is debugging, refactoring, reading and reading it over
> and over again. The percentage of writing the actual boilerplate
> rapidly drops to a few percent.

I don't have any exact figures, but it takes enough time to make it
annoying. Also don't forget to look at this from the point of view
from someone who doesn't know anything about GObject boilerplate code.
It is quite an obstacle to climb over, not only to be able to write
GObject boiler plate fluently, but also to read it fluently. This
becomes especially problematic in the context of "temporary"
contributions such as GSoC, where a substantial amount of the initial
time in a project is spent on getting students up to speed on how
GObject works.


> And what are "things that benefit our users" we could do instead?
> Thats a complete non-statement. Programming a complex thing
> like GIMP is hard, no matter how supposedly "easy" you make
> the programming language.

I meant that instead writing boilerplate, we and others can write code
that adds actual functionality.


> The "problem" is not the programming language, or GObject, it's
> simply the complexity of GIMP's object system, and that complexity
> is unfortunately unavoidable, and is not going to decrease by
> adding another layer to it.

Vala is not another layer, it's just another way to write GObject code
where the boiler plate is taken care of by the valac compiler. And I
don't see the GIMP object system as very complex, it is what you'd
expect for a program like GIMP. I actually often find myself reluctant
to add new classes because of all the extra work the boiler plate
requires. This isn't a healthy situation; adding new classes should be
effortless.


> I often hear how well the GIMP source is structured, and people
> point others to GIMP as an example of properly done code. That's
> a reputation which is not going to improve by adding another
> fringe language.

The GIMP code *is* well structured, but I don't see how that is an
argument either way. I don't want to add Vala to bring structure into
the code, I want to add Vala to get rid of all the boiler plate code.


> As to the actual iussue of introducing whatever *additional*
> language in GIMP, I strongly doubt that it would help us in
> any way. It would increase the complexity of both building and
> programming because there would be two languages to learn,
> it would complicate the build system (new contributors
> would also have to learn to deal with autofoo makefiles dealing
> with both C and vala code). It would increase the barrier of
> getting new contributors into the project, not lower it.

It's funny, because I see it the other way around. With infrastructure
for and knowledge about how to use Vala in GIMP, the barriers of
getting new contributors is lowered, because they don't need to learn
GObject C boilerplate before writing code. Assuming of course that
most of our code is in Vala already...

 / Martin


--

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

[Martin Nordholts]

2011/3/27 Kevin Cozens :
> LightningIsMyName wrote:
>> *** Optional topic: Re-Discussing GIMP's programming language ***
>> Some developers that weren't present in the last meeting, highly
>> disagree on the attempt to introduce vala into gimp, claiming that it
>> will scare off developers (more than the "simple" C GObject code).
>
> Before talking about which new programming language is needed(?) in GIMP we
> should make sure the problem is clearly defined as to *why* we need
> something new. What problem is the new language going to solve?
>
> IIRC, it had something to do with creation of GUI stuff (such as dialog
> boxes?). If that is the case, the language should be irrelavant. There are
> other tools that can be used to more easily make a GUI. One that comes to
> mind is a tool like Glade that can generate a file that can be used with
> with a library (GtkBuilder?) to show the contents of the file.
>
> I may be completely off base here because I haven't heard a clear definition
> of the problem.

The problem with using C for everything is that we have to spend time
on managing boilerplate GObject C code, like manually initialize
vtables for example. We could spend this time doing things that
benefits our users instead.

When I get time, I will port GimpTag to Vala so we can see how the
introduction of Vala affects our codebase, autotools etc. If we bump
into a lot of problems, we can drop the idea of using Vala in GIMP,
but if it turns out we can become more productive by using Vala, we
should start using Vala more.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

[Martin Nordholts]

On 03/25/2011 02:31 PM, LightningIsMyName wrote:
> *** Other topics ***
> Any other suggestions should be suggested by replying to this email,
> or adding it directly to the wiki (if you have permissions to edit the
> wiki).

Hi,

What's the status of making wiki.gimp.org resolve to gimp-wiki.who.ee so 
e.g. the roadmap URL becomes

   http://wiki.gimp.org/index.php/GIMP_Roadmap

rather than the current

   http://gimp-wiki.who.ee/index.php/GIMP_Roadmap

?

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMYK file export plug-in

[Martin Nordholts]

2011/3/22 Jacek Poplawski :
> CMYK is also best colorspace for skin color retouch by numbers,

No it isn't, because unless you go through a lot of extra work to
avoid it, colors in the image that the used CMYK color space is unable
to represent will get lost.

 / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMYK file export plug-in

[Martin Nordholts]

On 03/22/2011 08:20 AM, Martin Nordholts wrote:
> LAB values
> makes colorimetric sense by themselves, without any additional information.

Correction: For CIELAB values to make colorimetric sense, it is 
necessary to also know the reference white point.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMYK file export plug-in

[Martin Nordholts]

On 03/22/2011 08:25 AM, Jacek Poplawski wrote:
> On Tue, Mar 22, 2011 at 8:19 AM, SorinN  wrote:
>> Jacek - you don't need CMYK for photos ["I need CMYK support for photo
>> retouch, to create better colors"].
>
> I am familiar with this opinion. I don't want to continue offtopic
> discussion in this thread, so I just give one example: curves. You can
> get more interesting retouch when using curves in CMYK and in LAB and
> in RGB than using only RGB curves. You can get more data from shadows
> by using K curve in CMYK for instance. You can increase contrast
> without touching the colors by using L curve. etc

We are talking about techniques to retouch photos on a mailing list for 
the development of an image editing application, so this is not offtopic.

Why would you transform to CMYK to lose color information just so you 
can increase the K value, rather than making a lossless transformation 
into LAB and decrease the L value?

Note that with GEGL, we will easily be able to have adjustment layers 
that work on the L component in CIELAB.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMYK file export plug-in

[Martin Nordholts]

On 03/22/2011 01:37 AM, Jacek Poplawski wrote:
> On Mon, Mar 21, 2011 at 11:30 PM, gespert...@gmail.com
>   wrote:
>> Most of the people ask for CMYK because:
>
> I need CMYK support for photo retouch, to create better colors.
> CMYK is no different than LAB, HSV or RGB. It is colorspace like
> others, but uses 4 channels instead 3.

CMYK is fundamentally different than LAB, HSV and RGB.

In order for RGB values to make colorimetric sense, meaning that the 
CIEXYZ tristimulus values are known, all you need to know are the 
primaries and the white point used.

The tristimulus values for a set of CMYK values depends on the 
characteristics of the pigmets, the pattern in which the colorants are 
arranged on paper, the order in which they are applied, the illuminant 
used, the characteristics of the paper they are applied on, and even the 
age of the print.

Another difference of the CMYK color space compared to e.g. RGB is of 
course it's subtractive nature, meaning that as you increase CMYK 
values, the resulting color will be darker, whereas with RGB, larger 
values means a brighter color.

HSV is just a different representation of RGB values, and LAB values 
makes colorimetric sense by themselves, without any additional information.

That CMYK is fundamentally different than light based additive color 
spaces is the reason why GIMP developers considers CMYK somewhat of a 
special case we can take care of later, we first need to make a program 
that is powerful in the additive color space world.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] How to best use Bugzilla

[Martin Nordholts]

Hi,

I think we should discuss how we make best use of Bugzilla. Except for 
tracking bugs, I'd like us to use bugzilla for

  a) Keeping track of what is important to fix for a given release
  b) Keeping track of what bugs among all our bugs we consider important
 to fix, but not more important than working on things on our roadmap

I'd like to use milestones [1] for a) , and priorities [2] for b). Does 
this sound reasonable to everyone? Would be good to agree on this before 
we start updating lots of bugs.

  / Martin

[1] 
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8

[2] 
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&priority=High&priority=Urgent


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color"

[Martin Nordholts]

2011/3/16 Charlie De :
> Martin, with all due respect, your focus in releasing 2.8 ASAP should be on
> integrating fixes that are completed, not battling to bring in new 
> functionality
> such as layer groups. What's the point of layer groups if the layer transfer
> modes don't work correctly? More important than that is that a promise is 
> being
> broken - a promise made to an excellent new talent who came out of nowhere and
> worked and behaved to the highest standard. The least you could do to 
> encourage
> his further participation is to fulfill your part of the bargain and let his
> work see the light of day in the 2.8 release. In preference to layer groups,
> which could wait till 2.10.
>
>
> My criticism is for the whole team involved in these decisions, I don't wish 
> to
> single out Martin or ask anyone to quit.

Layer groups are already in 2.8, but we can't release 2.8 without
fixing some things that users will expect to work and that must work,
for example layer masks on a layer group. In other words, this is not
about bringing in some new features not including others, it is about
bringing our git master branch to a state where there are no
incomplete features on it. Avoiding incomplete features on the master
branch is crucial if we want to get in control of our currently very
long development cycles.

And regarding the patch itself: It is not quite as easy as just
commiting what we have now and be done with it. Before we can commit a
patch like this, it needs thorough review of experienced developers.
And by my standards, the patch also needs to come with a test case
that verifies that it works, and that it keeps working. So, there is a
substantial amount of work left before that bug report can be closed
as fixed.

It was more than 3 years ago we made a stable release. Just as you
point out, we must stop bringing in new features, finish work in
progress, and make a release.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color"

[Martin Nordholts]

2011/3/16 Carol Spears :
> martin, if in, oh, lets say 3 days, March 18, 2011 the majority of your list
> items are not commited, perhaps you should consider stepping aside.  
> "releases"
> don't attract developers.  look at the history!  gimp-1.0 - gimp-1.2, 1997 
> thru
> 2000.  lots of contributors, lots of development, lots of ideas, lots of bug
> fixing.  it was a lot of fun.
>
> sometimes, you gotta quit -- and see if that helps things.  i sure didn't like
> what was going on, i needed to be forced to quit.  so, okay fine, i quit for
> more than two years, maybe more than three and you know what?  the problem
> wasn't me because all of the things that i did not like persisted and there
> was no improvement in involvement -- in fact, involvement (especially by
> people who can fix bugs and have some knowlege of gimps innards) dropped off.
>
> i cannot force you to quit the way i was forced to quit.  i can only ask you 
> to
> consider this and also that before you quit, that you removed the buildbot
> stuff from gimp's source and put it into eh, lets say buildbots source on the
> same server.  that way, other projects can become rejuvinated with buildbot
> product the way that gimp has been.  i was told that it was a gnome project
> afterall...

Hi Carol,

Thank you for sharing your concerns. I will quit when the majority of
contributing members of the GIMP community wants me to quit.

Regards,
Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color"

[Martin Nordholts]

On 03/15/2011 08:47 PM, Charlie De wrote:
> Why?? Rupert Weber finished this last September and you promised it would be 
> in
> 2.8. Is this how you show respect for the most stellar effort by a new talent?
> Shame, truly, shame on you. It's now been 5 years since the issue was first
> reported, you're going to add another year even though the work is done. That
> is, if you don't break your promise again. Where's your integrity?

If we never make releases, we won't get new contributors either. We 
really need to make a release ASAP, and we simply don't have time to fix 
this before the 2.8 release. In modern software development, 
uncomfortable decisions like this sometimes needs to be made. I am sorry 
that it upsets you.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

On 03/15/2011 06:38 PM, Alexandre Prokoudine wrote:
> On Tue, Mar 15, 2011 at 8:25 PM, Martin Nordholts wrote:
>
>>> Speaking of which, I'd love to know what on Earth the reasoning behind
>>> putting https://bugzilla.gnome.org/show_bug.cgi?id=556884 off the
>>> milestones is supposed to mean. The prerequisite is in place, making
>>> the messages translatable is very little work. So why are we going to
>>> ship 2.8 with the horrible mix of English/localized UI once again?
>>
>> There are thousands of other small things we could spend time on rather
>> than working on the highest prioritized features dictated by our
>> roadmap. But if we do, it might very well go another 9 years without
>> any support for high bit depths in GIMP.
>
> It looks like you didn't even bother looking at the bug report in question.
>
> Right now all it takes is green lights for someone (e.g. me) to enable
> the messages for translation and then let translators do their work.
>
> With all respect due, what 9 years are you talking about?

I did look at it, and I saw that mitch said there was a problem, then 
you said there wasn't a problem, and now developer needs to verify that 
there maybe isn't a problem. It is harder to ignore small things like 
this, but they add up, and as I said: we need to stop working on what is 
not important and not be trapped in working on things like this.

I was referring to the age of "Bug 74224 - Add support for 16 bits per 
channel"...

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

On 03/15/2011 02:12 PM, Alexandre Prokoudine wrote:
> On Mon, Mar 14, 2011 at 1:59 PM, Joao S. O. Bueno wrote:
>> Hi,
>>
>> This decision, as I see it, change the release date from within
>> "months" to within some weeks -
>> I hope you have in mind that Translators have to  know about so they
>> can update translations as possible, as well. At some reasonable point
>> before the release, a "string freeze" status for GIMPshould be set
>> (even if a few string chanegs are to happen after that).
>
> Speaking of which, I'd love to know what on Earth the reasoning behind
> putting https://bugzilla.gnome.org/show_bug.cgi?id=556884 off the
> milestones is supposed to mean. The prerequisite is in place, making
> the messages translatable is very little work. So why are we going to
> ship 2.8 with the horrible mix of English/localized UI once again?

There are thousands of other small things we could spend time on rather 
than working on the highest prioritized features dictated by our 
roadmap. But if we do, it might very well go another 9 years without 
any support for high bit depths in GIMP.

Let's please focus on what's important, and compared to high bit depths, 
that is not important.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

On 03/15/2011 12:35 PM, Joao S. O. Bueno wrote:
> Scripts which previously interated through layers are currently not
> working. That is a regression.

It sure sounds like one, please file a bug report and put it on the 2.8 
milestone with a scripts that allows the regression to be easily reproduced.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

On 03/15/2011 10:44 AM, Jon Nordby wrote:
> On 15 March 2011 07:43, Martin Nordholts  wrote:
>> Not including API to work with layer groups in Python is not a
>> regression, it's just missing functionality in one of the scripting
>> languages. It is unfortunate if GIMP 2.8 will be released without layer
>> groups support in Python, but the alternative is worse: not releasing
>> GIMP 2.8 at all. And we should arrange for the Python bindings to be
>> automatically generated from the PDB rather than wasting man-weeks on
>> manually keeping it up to date. Not an easy task perhaps, but the only
>> sensible one.
>>
> Long term, bindings should of course be generated (or rather be
> dynamic using pygobject, when/if possible).
> However I need layer groups exposed for the Python API in order to
> support layer groups in OpenRaster, so I will probably do these
> bindings for 2.8. Just need to find the time. Do we have a bug open
> about this issue?

Take a look at

Bug 624303 - Introduce an item class in PyGIMP
https://bugzilla.gnome.org/show_bug.cgi?id=624303

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

On 03/14/2011 11:59 AM, Joao S. O. Bueno wrote:
> Hi,
>
> This decision, as I see it, change the release date from within
> "months" to within some weeks -

May I ask for the calculations that led you to the conclusion that we 
are weeks away from a release? I haven't done the math yet, but I still 
expect us to be months away from a release.


> I hope you have in mind that Translators have to  know about so they
> can update translations as possible, as well. At some reasonable point
> before the release, a "string freeze" status for GIMPshould be set
> (even if a few string chanegs are to happen after that).

Thanks for the reminder. We should probably enter a soft string freeze 
soon...


> Other than translation, we have to work the Python bindings so there
> are no functionality regressions, (whch includes the ability to work
> with layer groups) -
> so to the above list of bugs, we shuld at least have one more about this task.
> (this also depends on being able to transform layer groups).

Not including API to work with layer groups in Python is not a 
regression, it's just missing functionality in one of the scripting 
languages. It is unfortunate if GIMP 2.8 will be released without layer 
groups support in Python, but the alternative is worse: not releasing 
GIMP 2.8 at all. And we should arrange for the Python bindings to be 
automatically generated from the PDB rather than wasting man-weeks on 
manually keeping it up to date. Not an easy task perhaps, but the only 
sensible one.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

[Martin Nordholts]

Hi everyone,

As you all know, getting 2.8 out is highest priority right now. There 
are however some things that we want to fix before we make a 3.0 
release. Thus, we must plan for a 2.10 release.

I have updated our milestones in bugzilla with this. After the update, 
there are only 7 bugs on the 2.8 milestone:

   642728  - "Function `gdk_gc_new' implicitly converted to pointer"
 causes build failure
   631766  - Bad performance when moving brush outline on canvas
   612931  - Moving individual layer in layer group not possible with
 Move Tool
   603848  - Single-window mode is not properly session managed yet
   600554  - Implement layer group transforms
   596410  - gimp-image-get-filename returns NULL for imported files
   51112   - clipping groups or masking groups (like in Photoshop files)

Let's focus our efforts and smash these last bugs so we can make a 2.8 
release as soon as possible.

To see what we should fix for the 2.10 release, refer to the 2.10 
milestone and our roadmap:

2.10 milestone:
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.10

Roadmap:
http://gimp-wiki.who.ee/index.php/GIMP_Roadmap

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP vs Photoshop

[Martin Nordholts]

On 03/08/2011 07:50 PM, Bogdan Szczurek wrote:
>> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek
>> wrote:
>>> I also have high hopes for GEGL, but I'd rather have it use some
>>> more abstract color model for that. I know it's not so simple—maybe
>>> even undoable–that way, but I do like the idea of color model that
>>> has complete coverage of visible spectrum.
>>
>> Using a color model with full coverage of the visual spectrum would be
>> an extension along the lines of RGB and the responses of the human
>> visual system/physics, entirely additive.
>
> Not entirely along the lines I'm afraid. First of all it strongly
> depends which RGB we're talking about. Even if we take scRGB into
> account there's still some considerable parts of visible spectrum that
> can not be described by scRGB's triad. I know scRGB is tempting for
> it's quite broad and seems easy to implement in RGB dominated world,
> but I've got a premonition that using device agnostic color space would
> pay off more. But again–I don't know that :).


If all you want is a color space that can encode all visible colors, 
i.e. the entire CIEXYZ color space, RGB is fine. Transforming from 
CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where 
the matrix depends on the primaries and white point chosen. It's just 
that sometimes the RGB components will be negative and sometimes greater 
than 1.0, but each color that can be perceived by a human can be encoded 
in such a boundless RGB color space.

If you want a color model that doesn't lose the information about the 
spectral power distribution of the stimulus, then RGB won't do, but from 
your reply above it doesn't sound like that is what you meant.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Porting GIMP plugins to GEGL operations

[Martin Nordholts]

On 03/03/2011 03:46 PM, Andreas Plath wrote:
> I started to compile a list of which were implemented, but I think I'd
> better ask: are all the plugins in the default GIMP bundle already
> implemented as GEGL operations? If not, is there an easy way to find
> which are already done?

There is no such list yet, it would be great if you could create one 
which we can put up on our wiki.

The only way to find out if a plug-in has a GEGL operation version is to 
look for that GEGL operation in the GIMP and GEGL source trees.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Adding a layer mode

[Martin Nordholts]

On 03/03/2011 06:03 PM, "Jörn P. Meier" wrote:
> very cool. Is this a patch against the git version?

Yes, and help with reviewing and testing it for inclusion in GIMP 2.8 
would be appreciated.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Porting GIMP plugins to GEGL operations

[Martin Nordholts]

On 03/03/2011 07:21 AM, Bill Skaggs wrote:
> Let me start by noting that although I was once pretty familiar with the
> Gimp code, I haven't
> looked at it in a couple of years.  That being said, this discussion is
> not making sense to
> me.  Plug-ins do not access Gimp core functionality directly, they use
> an interface library
> known as "libgimp".

Hi Bill

You got it all wrong: porting GIMP plug-ins to GEGL operations is about 
exactly that: replacing GIMP plug-ins with GEGL operations. It is not 
about making libgimp GEGL-aware.

Instead of
http://git.gnome.org/browse/gimp/tree/plug-ins/common/pixelize.c
we want
http://git.gnome.org/browse/gegl/tree/operations/common/pixelise.c

Best regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Adding a layer mode

[Martin Nordholts]

On 03/03/2011 02:00 AM, "Jörn P. Meier" wrote:
> Hi,
>
> I would like to implement the following layer mode in the GIMP:
>
> 1) Transform destination and source pixels to HSL space.
> 2) Note original destination pixel saturation.
> 3) Set luminance component of destination pixel to luminance component
>  of source pixel.
> 4) Transform destination to HSV color space.
> 5) Set saturation of destination pixel to original saturation of
>  destination pixel.
>
> I'm assuming destination is also the result of the operation. Not sure
> how GIMP handles this, though.
>
> The purpose of the mode is to colorize a greyscale image while keeping
> both the saturation and hue data of the color layer and the luminance
> data of the greyscale image. Existing modes (as far as I see)
> unfortunately either mess up the color information or the luminance
> information.
>
> So, the question is, what changes would I need to make to add this
> layer mode?
>
> I would be very grateful for any hints. :)

There is already a patch for that (using the CIELCH space instead), see 
the most recent patch in
https://bugzilla.gnome.org/show_bug.cgi?id=325564

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Roadmap - wiki page

[Martin Nordholts]

On 03/02/2011 04:33 AM, GSR - FR wrote:
> Hi,
> ense...@gmail.com (2011-03-01 at 2214.48 +0100):
>> Thanks, I've added your items as well as mapped features into GIMP
>> releases up to GIMP 3.8. (I implicitly include both 'color adjustment
>> layers' and 'filter layers' under "Adjustment layers".):
>> http://gimp-wiki.who.ee/index.php/GIMP_Roadmap
>
> Please pick a different name that trully combines both things then,
> assuming they are combinable. Adjustment layers is already a standard
> term (de facto from another app, yeah, impossible to change that now)
> for a layer that only has a mask and applies per pixels changes like
> hue or level changes. Not only confusing, but hard to see the relation
> between "adjusment" and "render grid", for example, which is probably
> what you mean with filter. Thanks.

I've changed "Adjustment layers" to 'Layer filters' for now, and added 
"Layer effects". Ideas for better names are welcomed.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Roadmap - wiki page

[Martin Nordholts]

On 03/01/2011 03:23 PM, Michael Grosberg wrote:
> Congrats! this is a much-needed step.
>
> Can I ask what "non-destructive editing" is? According to Adobe, this 
> includes:
> * Color adjustment layers (such as levels, hue/saturation, threshold, etc)
> * filter layers (such as blur, sharpen, emboss, etc)
> * smart objects (i.e., ability to scale / rotate a layer as a single object,
>without changing its pixel data)
>
> Maybe this could be expanded upon and prioritized.
>
> I also have a couple of suggestions for things to put on the roadmap:
>
> * change the floating selection behavior so that float and un-float can
>be automatic and not need user's explicit input.
> * Automate layer boundary management so that the user can draw on any point
>at any time and not worry about increasing the boundary
> * unified transform tool (I remember seeing plans for that last item on
>Peter sikking's Blog)
>
> So, what do people here think? I believe all three are essential in making
> GIMP a faster and more hassle free tool. I can expand on these subjects if
> needed.

Thanks, I've added your items as well as mapped features into GIMP 
releases up to GIMP 3.8. (I implicitly include both 'color adjustment 
layers' and 'filter layers' under "Adjustment layers".):
http://gimp-wiki.who.ee/index.php/GIMP_Roadmap

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GIMP Roadmap - wiki page

[Martin Nordholts]

On the developer meeting I got an action to create a draft of a roadmap. 
It can be found here:

http://gimp-wiki.who.ee/index.php/GIMP_Roadmap

It has has a list of features we prioritize, as well as a list of at 
what GIMP release we expect features to be available.

It is quite influenced by my personal opinions of what we should 
prioritize, please take a look and add things you miss. If you disagree 
on priorities, please bring it up here so we can discuss it and reach 
consensus.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP developer meeting

[Martin Nordholts]

On 02/28/2011 07:02 PM, Sven Neumann wrote:
> On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote:
>> Wiki needs an admin that cares, a database and php installed on the
>> server. AFAIK there is no gimp host that meets all those requirements,
>> specially the admin part.
>
> Well, the machine that hosts www.gimp.org meets all those requirements.
> It has database and PHP installed and if anyone volunteers to become
> "the admin that cares", it's no problem to add accounts on the machine.

Why don't we migrate gimp-wiki.who.ee to gui.gimp.org and call it 
wiki.gimp.org instead? Seems unnecessary to administer two wikis.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP developer meeting

[Martin Nordholts]

On 02/28/2011 12:07 AM, LightningIsMyName wrote:
> Hello,
>
> Today (February 28, 2011), at 10pm CET (for time zone conversions, see
> http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=28&year=2011&hour=22&min=0&sec=0&p1=48
> ) a meeting of GIMP developers is scheduled on the GIMP developer IRC.
> On the list of topics:
>
> - GSoC 2011 - ORG Application deadline is in 11 days!
> - Bug fixing priorities
> - Future development?

Good initiative. I'd like to add to the agenda:

  - Create a roadmap at http://gimp-wiki.who.ee/
  - Make http://gimp-wiki.who.ee/ the official wiki, e.g. make
wiki.gimp.org point to it

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Development environment

[Martin Nordholts]

Tool:
Emacs + https://github.com/Enselic/enselic-home/tree/master/elisp

Direct compilation:
Yes, with M-x compile and M-x flymake-mode

Code completion:
Kind of, Emacs supports tab-completion for symbols in all buffers, so if 
I have the relevant headers open, I have tab-completion for e.g. all 
gtk_ functions. Not the best code completion, but you come pretty far 
with it.

Documentation browser:
I use exuberant-ctags for symbol definition lookup, so to get to the 
documentation of a function, I usually go to the declaration/definition 
of it using the exuberant-ctags indexes. I also occasionally use 
devhelp, but that's an external program.

Debugging:
Yes, M-x gdb

Refactoring:
No, unfortunately not.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Martin Nordholts]

On 02/13/2011 12:04 AM, LightningIsMyName wrote:
> I'm starting this thread to list ideas for Google Summer of Code 2011,
> for the GIMP project. Since in the last year collecting ideas was done
> partially by the mailing list, let's try it again this year and keep
> most ideas here.

Thanks for a good start on this Barak


I would like to add:

Port UI code to a non-low level language

Hacking UI code in C is a resource eater for us, we should use C for 
quick and efficient pixel processing but not for creating buttons. It 
would be interesting to make changes to the GIMP codebase that would 
allow us for example write the Pointer Information Dialog in JavaScript.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Nightly builds moved to Jenkins (Hudson)

[Martin Nordholts]

Hi everyone

I got tired of managing our BuildBot(s), so I decided to switch our 
continuous integration tool to Jenkins (formerly known as Hudson). You 
find our Jenkins at

   http://gimptest.flamingtext.com:8080/


The main benefits are:
  * An order of magnitude easier to configure and maintain. All
configuration happens through the web interface.
  * Has its own account and login system, no need for accounts
on the host machine.
  * One Jenkins for all our projects vs one buildbot per project
  * Mails with last build log lines and list of changes since last
build works out of the box. That is quite a bit of work to get
working with buildbot, so much that I gave up on it. In a few days
I will make failures be posted to gimp-developer, I think that is
good to do if the mails contains logs and list of changes.


The nightly tarballs can now be reached both through HTTP and FTP with 
permanent URLs:

   babl:
 
ftp://gimptest.flamingtext.com/pub/nightly-tarballs/babl-git-master.tar.bz2
 
http://gimptest.flamingtext.com:8080/job/babl-distcheck/lastSuccessfulBuild/artifact/babl-git-master.tar.bz2

   GEGL:
 
ftp://gimptest.flamingtext.com/pub/nightly-tarballs/gegl-git-master.tar.bz2
 
http://gimptest.flamingtext.com:8080/job/gegl-distcheck/lastSuccessfulBuild/artifact/gegl-git-master.tar.bz2

   GIMP:
 
ftp://gimptest.flamingtext.com/pub/nightly-tarballs/gimp-git-master.tar.bz2
 
http://gimptest.flamingtext.com:8080/job/gimp-distcheck/lastSuccessfulBuild/artifact/gimp-git-master.tar.bz2

To simplify configuration, I wrote a simple 'GNOME Project Builder' 
Jenkins plug-in that can be found here:
https://github.com/Enselic/gnome-project-builder

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Gegl-developer] Where can I help?

[Martin Nordholts]

On 02/07/2011 01:33 PM, Patrick Horgan wrote:
> On 02/06/2011 10:52 PM, Martin Nordholts wrote:
>> On 02/07/2011 04:48 AM, Patrick Horgan wrote:
>>> I'm trying to come up to speed on gegl and built the hello-world.c
>>> example from the examples directory.  The text from that example doesn't
>>> show up on the output, although the mandelbrot zoom works wonderfully.
>>> Is there anything I can do to figure it out?  Can someone point me
>>> toward something to read to understand where things are going on?
>> One thing you can do is to run with the env var GEGL_DEBUG set to
>> "process". That will give some output on how things are processed in the
>> graph. Does the output for the text node look weird?
>>
>> / Martin
>>
>>
> btw, forgot to say this is on Ubuntu using gegl and babl from git trunk
> and gcc 4.6
> Could it be where it says:
> Using cache for pad 'output' on "gegl:text 0x9017e90"

Yes maybe, caches don't always work like they should. If you disable 
that code, does it become better? You can also set a breakpoint in 
process() for text and see that the thread of execution looks reasonable 
when you single-step through the code.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Gegl-developer] Where can I help?

[Martin Nordholts]

On 02/07/2011 04:48 AM, Patrick Horgan wrote:
> I'm trying to come up to speed on gegl and built the hello-world.c
> example from the examples directory.  The text from that example doesn't
> show up on the output, although the mandelbrot zoom works wonderfully.
> Is there anything I can do to figure it out?  Can someone point me
> toward something to read to understand where things are going on?

One thing you can do is to run with the env var GEGL_DEBUG set to 
"process". That will give some output on how things are processed in the 
graph. Does the output for the text node look weird?

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] application

[Martin Nordholts]

On 02/06/2011 05:51 PM, Michael Grosberg wrote:
> Martin Nordholts  gmail.com>  writes:
>
>> So I suggest you look for something you'd like GIMP to do better, then
>> start working on that. If you bump into problems, feel free to ask for
>> advice on this list.
>
> Isn't there some prioritized task list for Gimp? I believe GEGL integration is
> currently the highest priority task, isn't it?

Almost; it's second. Getting 2.8 out is number one.

But to recommend our friend Nicolas specific tasks to work on, I need to 
get to know him as a coder first.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] application

[Martin Nordholts]

On 02/04/2011 07:59 PM, Nicolas Brack wrote:
> Hello,
>
> I'm responding about the advertisement "Plans for 2.8 and beyond" to help
> the team to freely code gimp. Here is a little resume :

Hi Nicolas!

Thank you for your mail.

However, you're not applying to a job, and a resume won't help us much. 
What matters is that you write good code ;)

So I suggest you look for something you'd like GIMP to do better, then 
start working on that. If you bump into problems, feel free to ask for 
advice on this list.

BR,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Wrong tools contour

[Martin Nordholts]

On 02/03/2011 05:59 PM, Alexia Death wrote:
> On Thursday, February 03, 2011 18:10:21 Nelson A. de Oliveira wrote:
>> On Thu, Feb 3, 2011 at 2:32 PM, Alexia Death  wrote:
>>> On Thu, Feb 3, 2011 at 2:50 PM, Nelson A. de Oliveira
> wrote:
 I don't know if it's a know issue,
>>>
>>> Im sorry, but I find this question a bit annoying. It's a big issue
>>> smack in the middle where you cant miss it. Of course its known.
>>
>> So users will have to always stay in doubt if one issue is known or
>> not, because it annoys to ask?
> Users arent supposed to use GIT versions. Git versions are for developers and
> often conain incomplete features.

This is how it _has_ been, but to make GIMP more fun for both developers 
and users, this needs to change.

The change we need to make is to develop things on feature branches and 
merge them to git master when they are ready. That way we can make 
releases much more frequently than every 2 or 3 years.

Making frequent releases is one important part in attracting 
contributors. How fun is it to contribute a feature to a project when 
the feature won't be widely used until after 3 years?

So to be a bit harsh: the error here was that git master broke, not that 
a user wanted to help by pointing it out.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Developer Boot Camp?

[Martin Nordholts]

On 01/28/2011 05:01 AM, Michael J. Hammel wrote:
>> * Shouldn't we standardize on a common development IDE (like Eclipse)?
>> If I am missing something in that area . . . let me know.
>
> IDE's are crutches.  Based on the source tree I don't think the
> developers use them but I could be wrong.  I don't even use IDEs for
> Java programming.  Unless you include cscope as an IDE.
>
> Don't bog down in the tools.  Open the file and read it.  That's how you
> learn code.

Hi

Hmm I don't understand your reasoning. So you rather waste time manually 
refactoring Java code than using Eclipse' excellent integrated 
reafactoring features?

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Developer Boot Camp?

[Martin Nordholts]

On 01/28/2011 12:56 AM, Stephen Greenwalt wrote:
> It is huge.  Incredible, actually.  Who wrote all of this?  Wow.

To see who wrote all this, visit https://www.ohloh.net/p/gimp/contributors


>
> A few comments:
>
> * It seems to work best to put the entire project (all source, and all
> build product) under a project folder in the Home directory.
> * If possible, that should include a /copy /of any external dependencies
> . . . with environment variables (etc) adjusted accordingly
> * The project ought to be able to exist in a "*bubble*" . . . so as to
> avoid confusion . . . regarding copies of dependencies that might exist
> in the OS.

I've tried quite a few different setups, and I find this to be the best:
http://www.chromecode.com/2009/12/best-way-to-keep-up-with-gimp-from-git_26.html


> * Multiple different project versions ought to be able to exist on the
> same machine without stepping over each other.

As have already been pointed out, you can already do that, just use 
different --prefix:es


> * If we do it right, compiling for Linux vs. Windows vs. OSx ought
> require no more than the flip of a switch.  The Blender folks, and
> others, are moving in that direction.

I agree, we should make nightly .rpm, .deb, .exe and .dmg builds. Quite 
a bit of work left to get there though.


> * Shouldn't we standardize on a common development IDE (like Eclipse)?
>   If I am missing something in that area . . . let me know.

If you want a good IDE I recommend Qt Creator. If I were to start fresh 
today, I would probably use Qt Creator instead of Emacs.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Developer Boot Camp?

[Martin Nordholts]

On 01/27/2011 10:43 PM, Eric Grivel wrote:
> I am getting the impression that the Gimp project is trapped in a
> chicken-and-egg problem with regard to attracting new contributors,
> where the few core developers are too busy maintaining the product to
> spend a lot of time helping new developers come on board.

To be honest, I don't recall a single instance of when a question about 
the code has not been answered (when developers have been around). If 
you are unable to get in touch with core developers on IRC, feel free to 
use our mailing list instead.

It's just that it has to be new contributors driving the core 
developers, not the other way around.


> Gimp is an extremely large and complex system. I am a fairly experienced
> coder myself, and have recently submitted patches for two open bugs. But
> those were easy ones, not really related to any Gimp structures but
> basic "C" bug fixing. I have looked at some of the other outstanding
> bugs and for most don't have a clue where to start, or how to make sure
> that my fix fits in the vision, or that it doesn't break something else.

This is exactly why I have been setting up a nightly builder and trying 
to get everyone to write more regression tests: to make GIMP a less 
scary project to work on. If people can be confident that if they break 
something, our nightly builder will discover that, then people wouldn't 
be so afraid.

I believe our biggest development-technical mistake right now is that 
people don't write regression tests for new functionality they add. It 
is kind of boring and sometimes hard, but the long term effects of 
consistently doing this is priceless.

Our nightly builder is found at 
http://gimptest.flamingtext.com:8012/waterfall which curiously enough 
failed this night to my changes yesterday, but I fixed that already...


> At this point, knowing how busy the core Gimp developers are, and
> recognizing that it will take more time for them to walk me through a
> problem and a solution than it would take them to just fix the issue
> themselves, I am hesitant to ask for a lot of help. On the other hand,
> the idea of just delving in and figuring it out myself is quite daunting.

Please please please don't hesitate asking for help, the worst thing 
that can happen is that you are ignored ;)

But don't underestimate the value of being able to understand code all 
by yourself. It takes some practice, but that skill is generic and will 
make you a better programmer in general.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Team Organization?

[Martin Nordholts]

On 01/26/2011 08:15 AM, Stephen Greenwalt wrote:
> I have been reviewing Gimp / GEGL source code . . . to get familiar with
> everything . . . so that I have some context to understand where I might
> help the project.
>
> But I am operating in a "void" because I don't understand:
>
> * How the development effort is organized.
>
>   o
> Is there a team leader?

Strategic decisions are taken in concert, although due to human nature, 
the opinions of some individuals have more weight depending on their 
reputation. We have two official maintainers, cat MAINTAINERS.

>   o What tools, etc. are being used to manage things such as:
> +
>   Feature requests, bug reports, etc.

We prefer feature requests on this mailing list, so that they can be 
discussed and evaluated, in particular in the context of our product 
vision [1]

Bug reports are managed in GNOME Bugzilla [2]


> + Component development.

In general, all development happens on the git master branch directly, 
although personally I think we should review our development methodology 
for GIMP 3.0 because we have problems in our 2.8 development cycles due 
to this.


> + Testing.

I have a long term goal of improving the GIMP development environment, 
and have lately put efforts into writing regression tests for both old 
and new functionality, and I have been setting up a nightly builder that 
runs all our tests [3]. Curiously enough, you'll notice make distcheck 
failed tonight due to changes yesterday, but I already fixed that...


> * What the development priorities are, and where programmer
>   resources are needed.

Right now, the priority is getting GIMP 2.8 out. The two major work 
areas left is finishing the implementations of layer groups and 
single-window mode, see [4] for the main missing bits.

After that, we will start working on GIMP 3.0, which will be GIMP 2.8 
running on GTK+ 3.0 and using GEGL-buffers for all data. That is, we 
will throw out our 8-bit only image/tile data structures. For GIMP 3.2 
we will start looking into serious support for non-destructive editing.


>
> The main Gimp website says that the new priority is expansion of the
> GEGL engine.
>
> But, does that mean that major feature development for main Gimp app is
> being stopped until the GEGL engine is ready?

See above

>
> I, for one, love Gimp but would really like to see one or new features
> such as:
>
> * Support for sub-layers (i.e. nesting of layers in tree-style control).

Fundamental support for that is already in place in git master

> * Ability to delete multiple layers at the same time, rather than
>   one-by-one.

Yes that would be nice, but support for higher bit depths and 
non-destructiveness has higher priority


> * Layer-by-layer history . . . so that you can undo changes within
>   the current layer only.

Sounds like a work-around for GIMP not having non-destructive editing yet


> Should I offer help in those areas?

Any help is greatly appreciated.

Best regards,
Martin


[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision
[2] http://bugzilla.gnome.org/browse.cgi?product=GIMP
[3] http://gimptest.flamingtext.com:8012/waterfall
[4] 
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Where can I help?

[Martin Nordholts]

On 01/26/2011 06:55 AM, Stephen Greenwalt wrote:
> Here's one suggestion that you could probably work on immediately,
> and would prepare
> you to work on other things if you are interested.  Gimp has a
> plug-in called Lighting Effects
> Thanks for the info.  I have used that filter many times, and I will
> take a look at what you describe.

Thank you for the offering. I would like to point out though that it 
would be even more helpful in the long term if the plug-in was ported to 
a GEGL operation so that we can use it when GIMP does its processing in 
linear light 32-bit RGBA.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSoC 2011 announced

[Martin Nordholts]

On 01/25/2011 05:52 AM, Alexandre Prokoudine wrote:
> Google has just announced GSoC2011.

Schumaml: Will you be our GSoC master this year too? If so, that would 
be great.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Where can I help?

[Martin Nordholts]

On 01/25/2011 09:35 AM, Stephen Greenwalt wrote:
> Where can I help?

It would be great to get help with bugs put on the 2.8 milestone:
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Submitted patches for bug 596410

[Martin Nordholts]

On 01/23/2011 09:11 PM, Eric Grivel wrote:
> Hi, I submitted a series of patches to bug 596410. This is my first time
> working on Gimp and I'm new to "git" at well. I am very open to
> suggestions on how to do things differently (better).

Hi and thanks, I'll review them soonish.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP icon " stolen" by commercial Symbian software on sale at Nokia app store

[Martin Nordholts]

On 01/21/2011 06:37 AM, Ilgaz Ocal wrote:
>   I got my lesson second time for attempting to help an open source
>   project in a positive manner.

Hi Ilgaz

Don't take one unfriendly reply from an arbitrary person as a 
representative reply from everyone. There are many of us that appreciate 
that you want to help us out. Thank you for that.

Regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Why GIMP is Inadequate

[Martin Nordholts]

On 01/13/2011 01:39 AM, Malix wrote:
> Hi all,
>
> on this blog there is a post about Gimp that generate a lot of user comments.
>
> http://troy-sobotka.blogspot.com/2011/01/why-gimp-is-inadequate.html
>
> I think that someone of you that can replay to false things must post a 
> replay.
>
> Bye
> Massimo

To me, most of his criticism is legitimate. I don't agree with all of 
it, but it's not all "false". I don't see the point in treating him as 
hostile; it just help him prove his point that we can't take criticism.

If we keep improving GIMP and stick to our plan, I am confident we will 
eventually address all of the shortcomings he points out.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] donations for GIMP 2.8

[Martin Nordholts]

On 01/06/2011 11:01 PM, Sven Neumann wrote:
> I just wanted to let you know that we have seen a dramatic increase in
> donations since then. More than 120 people donated over the last 8 days
> and sent us about 2,500 dollars. Perhaps it would be a good idea to
> discuss how we can actually use this money to make the GIMP 2.8 release
> happen soon...

Here are some examples of what I think blocks a GIMP 2.8 release:

  * Finish single-window mode
  * Make layer masks work with layer groups
  * Bug 596410 - gimp-image-get-filename returns NULL for imported files
  * Bug 597117 - impossible to drop a group as a sibling inside a group
  * Bug 612931 - Moving individual layer in layer group not possible
 with Move Tool
  * Bug 600554 - Implement layer group transforms
  * Bug 624303 - Introduce an item class in PyGIMP
  * Bug 630748 - display filters do not work
  * Bug 631766 - Bad performance when moving brush outline on canvas

One natural use of money donated specifically to speed up a GIMP 2.8 
release would be in the form of bounties for fixing bugs that blocks 
GIMP 2.8 from being released. I know we have a history of disliking 
bounties, but as far as I know we never really tried, and now we have 
money more or less ear-marked for this purpose.

We must not put bounties on things with vague scope like "Finish 
single-window mode", that won't work. We can only put bounties on things 
where the work to be done is well-defined, like for

  * Bug 596410 - gimp-image-get-filename returns NULL for imported files

If the work to be done in order to get the bounty is unclear, we *will* 
get into problems.

I also think bounties shall only be claimable by people who would not do 
the work if there wasn't a bounty. For example, I won't and can't claim 
the bounty if I fix bug 596410, since I would have fixed it long ago if 
my spare time was infinite.

One tricky question is what the size of the bounty should be for each 
bug... Let's discuss that if we can agree on that we want to try 
bounties at all.


I think it is also worth to contemplate why we are in this situation 
where we want to make release, but can't because there's too much work 
left to do. The reason we are in this situation is because we develop 
features on the branch we make releases from. If things don't go as 
expected, like the case has been for single-window mode for example, we 
don't have any place to make releases from. The solution to this is of 
course to develop big features on feature branches. Basically, it should 
not be allowed to commit code to git master that is known to put the 
branch in an unreleasable state. We'll have good reasons to revisit this 
topic when we start working on GIMP 3.0...

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog

[Martin Nordholts]

On 01/06/2011 08:32 AM, Olivier wrote:
> 2011/1/5 Martin Nordholts mailto:ense...@gmail.com>>
>
> That is not necessary, the reason I haven't hacked on GIMP the last two
> months is that I am working on a website which will allow people to
> easily track progress of GIMP development (or any project for that
> matter).
>
> I expect to be back working on single-window mode in 1-3 months.
>
> What could be the implications on the date of the future release of
> version 2.8?

We want GIMP 2.8 out as soon as possible. Achieving that goal with be 
easier with a tool which will allow us to track progress of development, 
since problems can be spotted early, making them easier to resolve or 
mitigate. The effect on GIMP 2.8 development as well as future GIMP 
versions will be positive.

It will also be easier for external parties, for example book authors 
that tries to align book publishing with releases of new GIMP versions, 
to see if development is progressing as expected.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog

[Martin Nordholts]

On 01/05/2011 07:19 PM, Simon Budig wrote:
> What currently is needed is some more work on the single-window mode.
> AFAIK there are some bugs in there and Martin (Enselic) can no longer
> dedicate as much of his time to it as he used to. It would be awesome if
> this work could be picked up and continued,

That is not necessary, the reason I haven't hacked on GIMP the last two 
months is that I am working on a website which will allow people to 
easily track progress of GIMP development (or any project for that matter).

I expect to be back working on single-window mode in 1-3 months.

  / Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog

[Martin Nordholts]

On 01/04/2011 08:25 AM, しげっち wrote:
> Hi, all.
> I'm recently implementing a GUI features that is inspired by the ideas
> of the GIMP UI brainstorming.
> I hope these features to be included or merged into the master branch
> in some future.
> So I inform you the patch here.
> If you're interested in the patch, please discuss about it.
>
> The patch is maintained by git, and published at following site.
> http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=summary
>
> This patch implement several features like:
> * horizontal toolbar with many tool options.
>(http://gimp-brainstorm.blogspot.com/2009/07/blog-post.html or
> http://gimp-brainstorm.blogspot.com/2009/07/gimpscape.html)
> * much sophisticated brush panel
> (http://gimp-brainstorm.blogspot.com/2009/12/brush-panel.html)
> * dynamics editor with side tabs
> (http://gimp-brainstorm.blogspot.com/2009/12/brush-dynamics-curves.html)
> * vertical dock and image tabs for single window mode.
> (http://gimp-brainstorm.blogspot.com/2010/10/vertical-menu.html)
> * dock folding features. I think this feature is necessary for single
> window mode.
>
> This patch is based on the current master branch of the
> git://git.gnome.org/gimp.
> It modified many source code of the existing codes, but it does not
> delete any features that is available in the master branch.
>
> Thanks,
> --
> sigetch.

Hi sigtech

That's some very interesting work and we should work on merging what 
makes sense to merge to GIMP git master. A word of warning though: not 
everything posted on the gimp-brainstorm blog is suitable to be actually 
implement in GIMP, so all your patches might not make sense to merge.

A couple of early comments on your code:


Add toolbar for tool-options to GimpImageWindow.
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=13c321f2db36bae52b23d4264dee242827bb801c

Rather than adding a widgets at the top of the GimpImageWindow taking up 
precious horizontal image space, we should work on moving tool options 
to on-canvas in an elegant way. Adding another tool-options area gives 
less space for image content and more space is taken by widgets, which 
is not the best trend.


- G-Pen algorithm is ported into GIMP trunk. Now smoothing function 
works for Ink...
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed

Looks like something we might want, some paint tool hacker should look 
closer at it. Alexia? Mitch?


Initial import of color blending function for smudge tool.
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=1b83ecae173641b0b08bccd0b207457bb549f9e6

It doesn't look like you change shade_pixels() and shade_region() in a 
backwards compatible way. Don't you break other things with that change? 
Otherwise it looks like a change we would want to merge. It would be a 
good idea to split this commit up so that there is one commit per 
bullet-point in your commit message.


* Some parameters in the toolbar can be edited using popup editor.
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=2d5edbfe2fbba08ab4cf456586d5344a3c3a49cc

If I understand your code correctly, you are replacing big widgets with 
smaller widgets that "expand" when you use them. Worth looking into further.


* GimpDock:  GIMP dock column folding is implemented.
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=01c5590e9566d7f9f7fe2b8112e570a26cb3ac4c

Another interesting change, I'll look closer at it when I get back at 
hacking on single-window mode.


[various bug fixes and additions to earlier commits]
For review purposes, it would be good if you squashed fixup-commits with 
commits they fix, so upstream reviewers just need to review one patch.

Best regards,
Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer