Re: [Gimp-developer] building git on SuSE 12.2 - gtk-doc added, but...

[Gfxuser]

On 23.10.12 at 03:22 pm, Dexter Filmore wrote:

failed to load "./cursor-bad.png": Couldn't recognize the image file format
for file './cursor-bad.png'
make[2]: *** [gimp-tool-cursors.h] Fehler 1
make[2]: Leaving directory `/home/dexter/software/gimp-git/gimp/cursors'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/dexter/software/gimp-git/gimp'
make: *** [all] Fehler 2

Checked on the file:
dexter@shodan:~/software/gimp-git/gimp/cursors$ file cursor-bad.png
cursor-bad.png: PNG image data, 36 x 36, 8-bit/color RGBA, non-interlaced

So it's there. Why does make complain?


I lately had similar pain compiling GIMP and its dependencies.
This brought me many steps further: 
https://staff.banu.com/~muks/tmp/gimp-build-script.txt together with 
http://wiki.gimp.org/index.php/Hacking:Building/Linux.
Some dependencies might be missing on your system (the error you 
reported may come from a missing libpng development package), but 
./configure or ./autogen.sh should tell you them.


Kind regards,

Sven



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

Re: [Gimp-developer] Rethinking mailing list rules

[Gfxuser]

Liam R E Quin (l...@holoweb.net) wrote:

Minor note, "Write Readable" should probably be "Write Readably".


Simon Budig wrote:

Can we add a sentence about mailing list digests? Sometimes people just
reply to the digest mails, yielding unreadable subjects and broken
threads...


Thank you, Liam and Simon, for your hints. I've taken them up and edited 
section 4.


Best regards,

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

Re: [Gimp-developer] Rethinking mailing list rules

[Gfxuser]

Hi,

thank you all for your positive reactions and helpful comments.

I reworked the whole list and made a short version with four easy to 
remember items and separate more detailed explanations out of it.


You find it at
http://wiki.gimp.org/index.php/Mindstorm:_Rework_of_mailing_list_rules. 
I also linked to it from the wiki main page (in the 'Hot topics' section).


Your comments are welcome again.

Best regards,

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

[Gimp-developer] Rethinking mailing list rules

[Gfxuser]

Hi,

because of some neverending discussions on the mailing lists in the last 
time schumaml and I considered rethinking the mailing list etiquette 
rules. Thereto I searched the web for existing mailing list rules and 
found  quite a lot. Because I see us as a community I decided to make a 
catalog of them as a groundwork for a discussion.

You find it at
http://wiki.gimp.org/index.php/Mindstorm:_Rework_of_mailing_list_rules
Please have a look at it and tell your opinion on it here. The reworked 
selection will become the new rules.


Secondly I think it's useful to publish these rules on new mailing list 
subscriptions and regularly.


Best regards,

grafxuser

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

Re: [Gimp-developer] Request to review article

[Gfxuser]

On Sun, Aug 5, 2012 at 5:13 AM, Anatol Chavez  wrote:

Although GIMP has the added value of having the undo option (control-z) go back 
as far as your computer memory allows (which Photoshop does not, by default, 
have)
Photoshop CS5 and CS6 handle up to 1000 protocol items. See 
Preferences/Performance/History and cache. On Windows the Preferences 
dialog is in the Edit menu.
In GIMP you have a lower limit of undo levels and define the maximum 
memory for undo actions. See Edit/Preferences/Environment.


Best regards,

grafxuser

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

Re: [Gimp-developer] windows gimp development

[Gfxuser]

Am 05.08.12 01:11, schrieb steven hallacy:

Hello,

I am interested in getting involved with Gimp Windows development, 
specifically fixing bugs.


Can you explain or point me to a place that explains how the process 
works.


Also, what software tools do I need.  Is it possible to Visual Studio 
Express?


Stephen


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

Hi Stephen,

you find useful information at http://wiki.gimp.org/index.php/Main_Page.

Best regards,

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

Re: [Gimp-developer] Motion blur algorithms

[gfxuser]

Hi Calcemus,


Easy to find papers, hmm? Ok, I am a student and need your advice
on this. Let's say I want to find a paper on an algorithm which I know
what it does, and that is all. Where do I search? I am member at
acm.org  but usually they have very advanced papers.


nearly every scientific paper starts with a survey on existing papers 
and research.
You could also look at Google scholar for survey or introduction papers. 
Another way is to use www.metager.de (a meta search engine) and select 
some scientific search engines there.
This should give you some hints or serve as starting point into a 
particular topic.


Best regards,

grafxuser

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

Re: [Gimp-developer] web based embed for GIMP

[gfxuser]

Hi,
I am looking for something like gimp that can actually be website 
based so users can use gimp right inside my website to edit print 
templates, add text and additional images etc. and then submit it 
directly to us. Anyone have any clues?
I guess this could be possible after GIMPs GTK3 port with GTK+ HTML 
backend (Alexander Larssons Broadway HTML5 backend) in future.


Best regards,

grafxuser

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

[Gimp-developer] Mac versions: where to report issues?

[gfxuser]

Hi,

I tried to install Lisas and Parthas Mac versions of GIMP. Both failed, 
so it's hard for me to find out whether a particular is platform 
specific. Can I report these issues in Bugzilla or is this the wrong place?


Best regards,

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

Re: [Gimp-developer] new interaction project starting...

[gfxuser]

peter sikking wrote:


where can the tool options go? tell us about locations where the
toll options can live (multiples allowed).


Hi again,

I did some studies on the interface and filed a bug for this. You can 
find the result in Bugzilla as bug #677760.
One thing I am also missing in many of GIMPs dialogs are units. Often 
there are only abstract, anonymous numbers and the user has to guess 
what they mean. If possible this should be improved.


Best regards,

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

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[gfxuser]

 Richard Gitschlag wrote:

> Date: Mon, 4 Jun 2012 20:48:40 +0200
> From: gfx.u...@online.de
> To: gimp-developer-list@gnome.org
> Subject: Re: [Gimp-developer] feature: Set exclusive layer 
visibility within groups

>
> Hi,
>
> I posted descriptions of the current behaviour and the proposals in the
> wiki. Now it's on you ;-)
>
> Best regards,
>
> grafxuser

I cannot seem to register a username on the wiki (or edit the page 
without one).  The "Login / create account" message only shows the 
Login panel, not showing the registration panel.



Currently you will possibly have more luck contacting Alexia at IRC. 
LightningIsMyName didn't neither reply my mail nor was he in IRC.


Best regards,

grafxuser

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

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[gfxuser]

Joao S. O. Bueno wrote:

So, we could use a wiki page somewhere for getting this started.
Like here:

http://wiki.gimp.org/index.php/Specs/Visibility


Hi,

I posted descriptions of the current behaviour and the proposals in the 
wiki. No it's on you ;-)


Best regards,

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

Re: [Gimp-developer] new interaction project starting...

[gfxuser]

peter sikking wrote:


where can the tool options go? tell us about locations where the
toll options can live (multiples allowed).



Hi,

here are two other ideas:

1. Place them in the context menu:
New structure of the right click context menu:
Tool options
---
File
Select
...

for instance, if the current tool is the brush: "Brush options" or the 
like the Tool options tab with 'Status and Text' style
Choosing this menu item will show the well-known tool options dialog at 
the mouse cursor.


2. Double-click
Simply double click on the tool icon in the toolbox will show the tool 
options dialog - this already happens. But if the tool options dialog is 
closed, it will be opened somewhere out of the users sight. New 
proposal: on doubleclick open the tool options dialog floating and 
located at the mouse cursor, if it isn't already visible.


Best regards,

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

Re: [Gimp-developer] [Gimp-user] Is it possible to access the capabilities of gimp in Java?

[gfxuser]

Ofnuts wrote:

On 05/31/2012 03:14 AM, stephen wrote:

On 05/31/2012 02:33 AM, stephen wrote:

Hello,

Does Gimp offer an interface (dll) which will allow me to access it 
capabilities through java or c++?

There is  a C interface, and there is a Python interface which is quite
powerful.



Hi,

I see the following possibilities:
1. There is a Java wrapper for GIMP, see http://jgimp.sourceforge.net/, 
but this project hasn't been active for a long time.
2. A still existing way is to use the Java Native Interface (JNI), which 
lets you call C/C++ functions from Java and vice versa.
3. GIMP has a built-in script-fu server which interpretes GIMPs plugin 
language, a Scheme dialect. You could connect to it over a socket from 
an arbitrary language and control GIMP remotely, although it's a bit 
oversized if you could call GIMPs functionality directly from within 
your program.
4. IMHO you should be able to access C from C++ by including the C 
header files, but I haven't tried this for GIMP yet.
5. If you're only interested in accessing GIMPs graphics core, then you 
could use a wrapper around the GEGL library. A Java language binding has 
yet to be developed.


Best regards,

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

Re: [Gimp-developer] Different Languagepacks Linux/Windows?

[gfxuser]

Anke Lange wrote:


I have come across some differences in the translation of Gimp into 
German. For example:


The palettes kontex-menue, on the linux, everything is in German. On 
windows, there is still some english.

Hi Anke,

I just tried with 2.8 on Windows and everything is in German.

On the gradient-dialog, on Windows you can open a new picture, on 
Linux the translation is correkt.

You're right. This is confusing for two reasons:
1. 'open' and 'new' are two different things. 'New' means to create 
something not yet existing, while 'open' expects anything that's already 
there.
2. Hovering over the second icon in the button bar at the dialogs bottom 
I read 'Ein neues Bild erstellen'.  First, it's very unexpected to 
create a new _image_ from a _gradient_ dialog, second it opens the 
gradient editor dialog. So, it should be 'Einen neuen Farbverlauf 
erstellen'. The en_us translation is right: 'Create a new gradient'. 
This simply seems to be an error in German translation.


Could your Windows regionale and language settings be wrong and cause 
this mixture? I read of a similar problem with Portuguese and English 
(see 
http://sourceforge.net/projects/gimponosx/forums/forum/761056/topic/3454274) 
and the reason were wrong system settings.


Trying to reproduce this behaviour I found another confusing item: in 
the gradient context menu there is an item 'Save as CSS...' in the 
German translation. Selecting it opened an English dialog for the 
underlying Python script (I have a 32-bit Windows). I guess both still 
need to be translated. Shall I report a bug for this?


Best regards,

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

Re: [Gimp-developer] [enhancement] Improved layer-visibility icons

[gfxuser]

Hi,

as we already realized the current solution to show hidden layers' icons 
in groups is a bit confusing. IMO less opacity doesn't change this much. 
A slashed icon indeed has more visual weight than a non-slashed one. But 
this suggests exactly the opposite of the actual visibility.
The second drawback is that the user has to keep a third state in mind: 
a visible layer in a hidden group. Actually two states are sufficient - 
a layer is visible or not.
Informations about visible sublayers are relevant only if the group 
itself is visible. So why not simply hide the icons in the sublayers if 
the group itself is hidden? This would show the facts and only the facts 
and thus be less confusing.


Best regards,

grafxuser

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

Re: [Gimp-developer] JPEG lossless operations?

[gfxuser]

Ofnuts wrote:

On 05/27/2012 08:26 PM, gfxuser wrote:

Hi,

reading some of the JPEG related articles here I wondered whether 
GIMP or GEGL can do lossless rotation and cropping on JPEG images. 
Can you tell me more about it?


Thanks,
grafxuser



For rotation, that would only work on images with dimensions that are 
a multiple of 8. For cropping, that only works if you crop on 8-pixel 
boundaries from the origin corner.


Otherwise, this also assumes that JPEG is an "editable format", while 
the recent kerfuffle around the Export function has demonstrated that 
it is not, in the current vision.



Thanks, Ofnuts.
Yes, 'Export vs. Save' was a long discussion and I don't want to boost 
it again. Although it takes a little getting used to I can live with the 
new behaviour. Despite of that I sometimes wondered in the past whether 
GIMP will introduce new compression artifacts if I rotated or cropped an 
existing JPEG image (yes, there are some cameras where saving in JPEG of 
sufficient quality is the best choice. Shall we not use them anymore?).


Best regards,

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

[Gimp-developer] JPEG lossless operations?

[gfxuser]

Hi,

reading some of the JPEG related articles here I wondered whether GIMP 
or GEGL can do lossless rotation and cropping on JPEG images. Can you 
tell me more about it?


Thanks,
grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[gfxuser]

Joao S. O. Bueno wrote:

Ok -
we it can be seen that there are a couple of desired/needed visibility
features when
group layers are in the mix.

Since any native changes to existing behavior could only come in gimp
2.10 (and only them we would have the feedback of lots o people just
as we are having now with 2.8) - this is what could be done now:

We document desired perceived behaviors for toggling visibility, I
write a couple of Python scripts to implement those - we test it
carefully (with input from the UI team), and the optimal settings for
those could be consolidated in gimp 2.10 .

  The major drawback being that these scripts can be called by a
one-key shortcut, but not assigned to be triggered by clicking/shift
clicking on the layers or eye-icons, or other UI parts. Once there are
clear and well defined preferred behaviors, they could be made into
the core bypassing this limitation.


So, we could use a wiki page somewhere for getting this started.
Like here:

http://wiki.gimp.org/index.php/Specs/Visibility


This is a good idea and I hope Richard and Peter agree, too.

Best regards,

grafxuser


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

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[gfxuser]

  Richard Gitschlag wrote:


> I'm also missing two other possibilities in changing layers' visibility:
> 1) Only one layer can be selected at one time. It can be useful to make
> just a few layers visible while hiding the others. Could it be made
> possible to multiselect layers?

That is an unrelated question.  As far as I know GIMP only allows one 
'active' layer at a time because that is the surface that any drawing 
operations are applied to.


As long as drawing operations are the only operations in GIMP, this 
would be a reason. But there are other scenarios where a multiselection 
of layers will be useful: merging a few layers down to one without 
having to affect visibility of the other layers, copying some layers to 
another image, moving some layers into a layer group and so on. Yes it's 
a bit unrelated to your original problem. Maybe a topic for another 
thread if it's of enough interest.


It's a bit hard to understand what you mean exactly in your further 
writing. Can you write down a state chain, please?


BTW: AFAIK layer groups are still work in progress. At least layer masks 
are postponed for a later version. Filters don't work (yet) on layer 
groups, too (see bug #676768). Are there some UI specs for the handling 
of layers and layer groups? Maybe they answer all our questions and 
suggestions here. I haven't found them on gui.gimp.org, but perhaps I 
searched in the wrong place.


Best regards,

grafxuser

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

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

[gfxuser]

Richard Gitschlag wrote:
I have a little gripe about setting "exclusive visibility" 
(shift+click a layer's visibility icon) in an image.  Now that we have 
layer groups in GIMP 2.8, it only functions on the "top level" of the 
layer stack -- it seems impossible to toggle exclusive visibility 
inside a group.


Since a layer group can itself be a complex combination of layers 
(apparently including other layer groups!), we should have some 
ability to toggle exclusive visibility with respect to other members 
in that group only.

You're right.

I'm also missing two other possibilities in changing layers' visibility:
1) Only one layer can be selected at one time. It can be useful to make 
just a few layers visible while hiding the others. Could it be made 
possible to multiselect layers?
2) Shift-clicking on a layers visibility icon toggles between the state 
of 'exclusive visibility' and the state 'all layers are visible', no 
matter whether all layers were visible before.

An example:
Layer L1 visible, L2 hidden, L3 hidden, L4 visible. Make L2 visible 
exclusively, shift-click on L2's eye again -> L1 to L4 will become 
visible, including L3 which was hidden before. It's annoying to set the 
previous visibility settings manually again, especially for users who 
have to handle a lot of layers.
This should be changed to restore the previous visibility settings, for 
instance to the following state chain:
Exclusive visibility -> Restore previous visibility -> Exclusive 
visibility ->.
A second state chain could be added, which resembles the current 
behaviour. Perhaps this could be bound to the Shift + double click on 
the layers eye.


Both chains can be complemented with the aforementioned 'visibility in 
groups' functionality: Exclusive visibility in group-> ... in the 
surrounding groups -> ... in the whole layer stack-> Restore previous 
visibility in the whole layer stack-> ... in the surrounding groups 
->... in the current group -> Exclusive visibility in group->.

and
Show exclusively in the whole layer stack -> Show all layers in the 
whole layer stack -> Show exclusively in the whole layer stack -> ...


Best regards,

grafxuser

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

Re: [Gimp-developer] Poor Display-Performance of Gimp 2.8 on Windows

[gfxuser]

Michael Schumacher wrote:

JPEG issue... is this the file size of 1.3GiB in the Export dialog (and 
everywhere else)?

This is a bug in Glib: https://bugzilla.gnome.org/show_bug.cgi?id=669818
- once this has been fixed in a Glib release, it may not even need a new 
release of GIMP, although an updatede installer would make it easier to roll 
the change out to the users.


Hi Michael,

I wondered today whether this bug will disappear automatically when GIMP 
is ported to GTK+ 3. Do you know more about this and whether there is a 
(rough) time schedule for the GTK3 port?


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Poor Display-Performance of Gimp 2.8 on Windows

[gfxuser]

Claus (Gimp-Devel-List) wrote:



Back to the problem above. Is there already a bugreport for this 
issue? Shall I create one? Or doesn't it make sense, cos there is no 
windows-developer that could look into it?
Yes, this is an already known issue, see 
https://bugzilla.gnome.org/show_bug.cgi?id=645345.
You can speed up GIMP by going to View/Display filters... and removing 
at least the item 'Color management' from the 'Active filters' list on 
the right (select the item, click on the left arrow in the middle). To 
enjoy this wonderful gimmick in all its glory, you can repeat this for 
every image you create or open ;-)


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Quasimode Adjustments -- fastest adjustments [demo included]

[gfxuser]

Srihari Sriraman wrote:

A few more thoughts on the shortcut+slide: [...]

  * Numbers [0-9] (as in the demo) could be very good shortcuts.
0-opacity, 1-size, 2-rate...9-xyz. One could simply look in the
tool options for the shortcut key (shown against each parameter)
corresponding to the parameter he wants to adjust.

  * *[...]*

  * *Gtk[Check/Radio]Buttons* could just toggle with the shortcut
number/key.

So each parameter/option in the tool options has a number-shortcut 
irrespective of the slide-ability.


First of all: Yahvuu, this is great! I would like to see it in GIMP. 
Which editor did you use to create this?
IMHO the numbers could be replaced by the well known concept of 
accelerator keys, for instance &Brightness (B will become underlined in 
the dialog). Unlike numbers they don't eat space, are also visible for 
the user and the user can keep them easier in mind like abstract 
numbers. But I guess, it was your main intention to show the principle 
and it's well done!


Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Targeted audience of GIMP?

[gfxuser]

Alexandre Prokoudine wrote:


1)http://blog.mmiworks.net/2006/11/creating-user-scenarios-with-gimpteam.html

"In the five days before this weekend, Ellen and Kamila had been
gathering vital raw material by performing workplace observation. Half
a dozen professionals in the field of photography and graphic design
were interviewed and observed on the job. These participants had been
selected based on the GIMP product vision."

2)http://gui.gimp.org/index.php/User_Scenarios

3)http://gui.gimp.org/index.php/Interview_Partners

Does it help?

Yes, thanks.

Personally I don't expect every single job out there to be listed. CG
industry seems to create a new kind of job every year, for instance.
I agree with you. I'm not in the CG industry, are you? To me it's 
sufficient and clearer to group them as Peter and his team already did.

Reading the product vision and the document 'GIMP 2.8 understanding UI
changes' I don't see a clear definition of that, but only two groups:
artists and scientists. Where are the non-professional artists and spare
time enthusiasts? I'm also missing a clearer definition of the expected
experience level. Only professionals seem to be addressed.
Are the other people not targeted? Clearing this as a part of the product
vision would be a big help to avoid misunderstandings.

This would be tricky. People can use professional workflows and not be
paid for the work they do.
In German we have the idiom of 'unprofitable art' and unfortunately this 
says a lot about payment for creatives for long ;-(  It's 
understandable, that they'd like to have an affordable tool. I'd like to 
point out, that I don't see the less professional users targeted, like 
spare time enthusiasts They are appearantly a big part of the GIMP 
community, too. Like badly payed creatives not everybody of them can 
afford buying or renting an expensive commercial product. So I 
personally would regret if they are not targeted anymore.


IMHO many usability complaints are based on some ambiguities. Either the 
GIMP team didn't have a clear notion in the past who the users are and 
developed an allrounder, which became a hard to ride horse (I'm 
constructive-minded). Or otherwise the less professional users are not 
targeted and don't know about this - so they will feel targeted and of 
course feel overwhelmed by GIMP's complexity (To be fair: it's similar 
with Photoshop.) That's why I urge for clarifying this in the product 
vision.


Why is painting from scratch not a top level part of the product vision? 
Are we going to miss someone? AFAIK there are already many other 
(semi-)professional affordable photo tools for Linux (RawTherapee, 
Darktable, Digikam, Photivo?, AfterShot, Lightzone etc.) but there seem 
to be much less high-end painting apps (MyPaint, Krita?, Pinta?). 
Wouldn't there be a disbalance? Alexia, where are you  ;-) ?


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Targeted audience of GIMP?

[gfxuser]

peter sikking wrote:

gfxuser wrote:


the last thread reminded me of a question, which I had for some longer and I 
couldn't find the right answer yet:
Who is the targeted audience of GIMP?


since I am used to doing a briefing on this, for GIMP design
projects and also recently the start of a university usability
surveying project, I thought I could write some of that down:

<http://gui.gimp.org/index.php/Vision_briefing>

Very interesting and thanks for your work.
What is 'hyper commercial'? Googling for it led me to a truck rental in 
South Africa ...*hmm*
To me it seems the beginners or 'average users' are not targeted by this 
vision, are they? Or haven't they just been considered _yet_?
To speak for myself, I'm doing graphical art and photo editing, but just 
for fun and in my sparetime. I wouldn't claim to be a professional. And 
I think there are a lot more people in just this situation. What would 
be the benefit for one 'like us' to contribute to GIMP? Will we/they 
benefit automatically from a redesigned UI?


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

[gfxuser]

Alexandre Prokoudine wrote:

And that's another task for an interested developer.

How about making a publicly available list of platform-specific tasks?



From my point of view a good idea.

Something to start from:
for Mac:
https://bugzilla.gnome.org/buglist.cgi?order=Importance&classification=Other&op_sys=Mac%20OS&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&product=GIMP

for Windows:
https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Windows;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP

for Linux:
https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Linux;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP

This can be simply added to the GIMP website or the wiki.

Best regards,

grafxuser (who's not just talking ;-))
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails

[gfxuser]

Am 18.05.12 09:33, schrieb Ryan Johnson:

Hi Ryan,

I checked your complaints with GIMP 2.8 with the following results:

1. Raise the file size limit for autogeneration of thumbnails.
Many of my JPEGs are just slightly over 3 MB or whatever the small 
current limit is. Many of my RAW NEF files are just /under/ 10 MB, at 
a resolution of 10.2 Megapixels. Many dSLR's exceed my camera's 
resolution, so my recommended upper limit is 20 MB, but doing a 
progressive scan (priority queue) would work best. Start out with 
anything under 5 MB, then 10, then 20 MB, so it is a rough priority 
queue, instead of a fine-grain one.
There is a solution for you in the preferences dialog. Goto 
Edit/Preferences/Environment pane. In the middle of the right side you 
will find the option 'Maximum filesizes for thumbnailing'. That's your 
friend.


2. Allow users to multiselect files and explicitly batch-generate 
thumbnails (just clicking on the thumbnail placeholder with multiple 
images selected should initiate the process).
Have you already tried this? I just did: multiselected files in the list 
of the 'open file' dialog, clicked on 'Click to create preview' in the 
right pane - and GIMP just created thumbnails for the selected files. 
Cool, isn't it? ;-)


Alexandre wrote:

3. Use the native "Open file" dialog.

and


Bigger Goal:
Improve the "Open file" dialog to include other viewing modes besides a
detail list. It's a graphics program after all! Appeal to the senses!

are mutually exclusive on Windows.




I wouldn't say that. On Windows 7 the native 'open file' dialog contains 
different views: list, details, symbols in various sizes, tiles. Symbols 
and tiles contain a preview of every file. IIRC it was similar with 
Windows XP. I think, that's what the OP wants.
IMHO using native dialogs has one mantrap: they need to be checked first 
whether they can fulfill all requirements of the application, like a 
thumbnail preview. Not every platform may offer all necessary 
possibilities and keeping track of this could be a hard work. I like the 
way of the Mac version: there's a 'Show in Finder' menu item in the file 
dialog, which will start the platforms file manager.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Targeted audience of GIMP?

[gfxuser]

Hi,

the last thread reminded me of a question, which I had for some longer 
and I couldn't find the right answer yet:

Who is the targeted audience of GIMP?

Reading the product vision and the document 'GIMP 2.8 understanding UI 
changes' I don't see a clear definition of that, but only two groups: 
artists and scientists. Where are the non-professional artists and spare 
time enthusiasts? I'm also missing a clearer definition of the expected 
experience level. Only professionals seem to be addressed.
Are the other people not targeted? Clearing this as a part of the 
product vision would be a big help to avoid misunderstandings.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] hesitant about compiling a list...

[gfxuser]

Hi Peter,

my opinion is 'the clearer the better'.
Such a list could IMHO improve GIMPs product quality.
Even if it will be a long list (and it will be growing, as user 
requirements and wishes always become more) this will show the necessity 
to priorize.
I'm not (or not yet) a GIMP developer, but speaking as a software 
developer I know of the benefits of priorization. Of course, this 
priorization must be done together with the developers. The GIMP team 
could then define mandatorily, what will become realized at all or in 
the next version - which could make it easier to define release plans.
The product vision is the big picture, but it needs refinement and this 
list would fill this hole.
I think, contributors don't have much problems at all seeing their 
proposals/contributions at this list as long as they know it's part of 
the development process and they don't _end up_ on this list. If some 
contributors come with a ready-to-integrate idea (like Tito, a new brush 
engine etc.), such a list could/should be taken to examine, how these 
appreciated contributions can become a useful part of GIMP and keep 
track of that progress.


So, you have my +1.

Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Liquid rescale

[gfxuser]

Hi,

I read the news about Liquid rescale's UI redesign at GIMP's main site 
and Peter's blog. It looks very promising. Especially I like team's no. 
3 results.
Are there plans to take these changes over to the current plugin and/or 
make Liquid rescale an official tool/plugin of GIMP?


One thing that could be changed are the many options 'advanced 
settings', 'rigidity' and 'algorithm parameters'. They look complicated. 
Perhaps more meaningful names could be found or they will be discarded 
in the UI and replaced internally by appropriate defaults. IMHO there 
should be one intuitive way with a few very easy steps, just like the 
current scale tool. They are: optionally make a selection on the image, 
show an outline with clickable handles to change dimensions, optionally 
paint discard and preservation masks, confirm or cancel. I you like I 
can provide a screenshot of the IMHO quite intuitive way of the 
equivalent tool in Photoshop Elements, but I think team's #3 proposal 
matches this best.


Peter, if you are looking for more things to change and use in your 
interaction design courses I suggest to look around in the current GIMPs 
dialogs. There are many unintuitive options, which look too scientific 
for an average user. Or could you explain blindfolded the difference 
between IIR and RLE in the Gaussian blur dialog, even if the results 
most times look the same? How about the dialog 'Path to selection' (see 
https://bugzilla.gnome.org/show_bug.cgi?id=671152)?
These results could then go back into GIMP, with benefits for all. I 
would like to read more from your courses.


To avoid misunderstandings and unnecessary uproars: yes I like GIMP, its 
name, Wilber and I'm sure I'm going to like goats, too ;-))


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Bug with image moving

[gfxuser]

Siarhei Kuchuk wrote:
When Edit image, then paste other image, press M, movement is detected 
but image cannot be moved. 

Hi,

sounds like you either chose the wrong tool or the wrong object to move.
I checked it with 2.6.12 and 2.8. Both work fine.
First: pressing big M (in the English version) will start the Measure 
tool, which is different from the move tool. To use the move tool, press 
m without the shift key.
Second: in the move tool check which of three little imagebuttons behind 
the word 'move' is toggled. To move the latest pasted image (which is in 
a floating selection layer), the button 'layer' has to be toggled and 
the floating selection layer must be the active layer.


Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] new interaction project starting...

[gfxuser]

a specialised widget set for the tool options.
these widgets can be more compact, more versatile for
different layouts, faster and more precise to operate

but, this is of course tied to the direction the tool options should
take in GIMP. and here we can use your input:

where can the tool options go? tell us about locations where the
toll options can live (multiples allowed).

Hi Peter,

one idea: they could be invisible and appear on right mouse click, pen 
click, a keystroke, a gesture or combination of them.
For instance: right mouse click lets the (context) menu appear (as it 
already does),
Shift + right mouse click: open tools palette at the mouse pointers 
position, with three buttons at the center: Undo, Redo, Options. The 
other tools would be arranged circular around it: recently used tools 
are closer to the center, seldomly used tools in the outer regions.
Ctrl+right mouse click: open current tools options at the mouse pointers 
position
Which had two advantages: because it's invisible, it doesn't eat space. 
But it's always there when you need it and where you are (at the 
mouse/pen pointer).


Just a short brainstorm...

Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] contribution processes...

[gfxuser]

On 12.05.12 at 5:45 pm Michael Muré wrote:

I completed the "How to port" section in the wiki.

Great! Now it should be even easier.

Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] contribution processes...

[gfxuser]

Hi Alexandre,

On Sun, May 13, 2012 at 10:40 AM, gfxuser  wrote:


Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is
ported to GEGL, but there are still some open 'easy to do' tasks - the best
start for beginners. The matrix starts with the chapter 'How to port' -
which is empty. How is a beginner supposed to port anything?

Empty? No, it says "Missing info. You can help filling it :)" Which
means that...
This is the point. From a beginners point of view these two sentences 
mean just the same like an empty space. Is nobody there who knows more 
about porting to GEGL? Did all the code suddenly appear from nowhere?





It would also
be helpful if somebody regularly concludes some discussions of general
interest on IRC or the devlist and maintains an up-to-date list in the wiki.

...is entirely possible, but requires someone to be around at all
times. I will, of course, do my best, but cannot guarantee either
24/7/365 presence, or full understanding of all technical discussions.
I appreciate your efforts and wouldn't expect you to be around 
everywhere all the time. I thought of two things anybody can do:
IRC: AFAIK discussions in IRC happen in the evening time (CET). If 
sometimes discussions about certain topics of general interest come up 
(like repeating questions, repeated pain with used libs, maybe some GSoC 
students questions, upcoming release dates) it would be useful if 
someone from the discussion could drop a short, meaningful note about 
the results in the wiki. If all these questions have already been 
answered in the wiki, then it's ok.
Devlist: as we currently see with your 'Wilber in the toolbar' thread, 
discussions can become very long. That's ok. As results grow within the 
discussion, it's later hard to find out a specific information quickly, 
if it's hidden underneath lots of postings. That's why a short summary 
at the end was useful. BTW this clarifies some questions for those who 
later implement something based upon this discussion.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] contribution processes...

[gfxuser]

Hi,

I also read your stab. First of all, I'm a friend of acting ordered and 
high code quality, too.

Some thoughts of mine:
1. Yet I haven't found out whether this draft is for 'interaction design 
patches' (whatever this could mean) or for code patches at all. What 
exactly do you mean?
2. The sentence ' There are quite a few (un)written requirements this 
contribution has to adhere to.' is not necessary. Either the 
requirements count and thus are written or not.
3. I read 'for new contributors', so I feel addressed. But then there is 
a list of few requirements a newbie can hardly fulfill. In fact, they 
are important as they try to achieve high quality software. If I was in 
the shoes of the experienced GIMPs team I would have written the same.
But really, as you noticed yourse lf: 'Each one counts and could form a 
barrier of entry'. IIRC GIMP development has a severe lack of 
developers. Why then build the barriers higher? Softening the 
aforementioned requirements with the line 'It has not to be perfect' is 
IMHO too less. However, after reading the stab my first thought was 
'They expect perfect patches'. I suggest to add a line, that, where and 
when contributors can post and discuss their code for review, before 
it's finally contributed as a patch. There are many possibilities 
(mailing lists, IRC, wiki, mail, Bugzilla ...) - to the GIMP team these 
informations are clear, but not to new people. And of course, 
contributors questions wait for answers. Lately I tried to learn from 
the GSoC students questions and asked for answers in the mailing list 
(see 
https://mail.gnome.org/archives/gimp-developer-list/2012-March/msg00193.html). 
I've got no answer yet for two months. So I went to IRC and tried to 
learn from the discussions there. The guys there are friendly, but yet I 
picked up some little pieces, which have yet to be merged to the big 
picture. This may take a while. I don't know whether everybody has 
enough patience.
Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is 
ported to GEGL, but there are still some open 'easy to do' tasks - the 
best start for beginners. The matrix starts with the chapter 'How to 
port' - which is empty. How is a beginner supposed to port anything? It 
would also be helpful if somebody regularly concludes some discussions 
of general interest on IRC or the devlist and maintains an up-to-date 
list in the wiki.
Don't get me wrong: my lines may sound like beefing, but I'm meaning 
them constructive. What I'm trying to say is: for newbies it's hard to 
get grips. GIMP team, please, add some words in Peters stab where they 
find all necessary information to contribute on a single point (the 
wiki) and keep these sources complete and up-to-date.
4. What will happen to the GIMP UI brainstorm? Will it be replaced by 
this process? If not, how will a contributor there ever know whether 
his/her proposal is accepted or not? AFAIK proposals end in team reviews 
- and then? Getting this information lets him/her start to implement 
this proposal or avoid needless efforts.


Many lines for a Sunday morning... Grab a properly chilled beverage and 
enjoy ;-) and keep on your good work.


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[gfxuser]

On 12.05.12 11:00 pm, Kevin Cozens wrote:


When this was discussed on IRC some time after the change had been 
made and some people were commenting/complaining about the "waste of 
space" the response was to add a line to the gimprc file. The idea of 
making it configurable via Preferences was rejected back then due to 
something along the line of not wanting to add yet another option to 
an already long list of options.


Perhaps it is time to have another think about whether there should be 
a configurable option to turn on/off the DnD target area. I don't 
think we should expect users who want to turn it off to have to find 
and edit their gimprc file.


Full ack. IMO the best place for this configurable option is in 
Preferences/Toolbox/Appearance. It would not be too much to have a 4th 
checkbox there. AFAIK things get too complicated for users if there were 
at least 7 or 8 options. A more consistent way would be to integrate all 
these options into the tools configuration list below. By now users can 
turn options on/off by two different ways on the same panel: the 
well-known checkboxes and the clickable eyes. Having all these options 
in the 'clickable eyes' list would be more consistent.
A cutting line could then clarify the difference between tools and the 
rest (color selector, active brush/pattern/gradient, active image, DnD 
area):


Drag and Drop area
Color selector
Active brush/pattern/gradient
Active Image
-
Rectangle select
and so on...

or let the users decide on their own, on which position of the toolbox 
they want to have the rest.


BTW: Is the single window mode meant to be turned on and off so very 
often, that this option has to be easily accessible in the 'Windows' 
menu? If not, there's enough space in the Preferences/Window Management 
panel...


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[gfxuser]

peter sikking wrote:

well, usability is a lot more than ‘what can do people find out
in the first 5 minutes’ (ease of learning). GIMP is designed
for other goals: speed of use, the freedom to create, etc.


Hi Peter,

can you explain this in more detail, please? I'm honestly interested and 
like to understand the backgrounds of the GIMP UI discussions a bit more.


Thanks,
grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[gfxuser]

Alexandre Prokoudine wrote:

I can't see how the logo is a hint that things can be dropped on
it. It looks more like a branding element.
That's my impression, too. Maybe it's dedicated to those, who forgot 
that they're currently using GIMP Of course they can also be reminded of 
this by a repeatedly popping up message 'You're using GIMP!' with a 
xeyed GIMP logo, for those who like it


2) You absolutely don't need the logo to drop things top open. The
whole toolbox's area works that way.

Nice news! I didn't know this.



Another space saving solution: the 'Images' dialog could be made a drag
and drop target

It was never even avalable by default, and it's not something people
use a lot, as far as I can tell. Im not sure that making it a target
will work.

I use the docked image dialog a lot as a vertical space saving 
alternative to the 'Show image selection' listbox. IMO it would be 
useful to even more people with the suggestions I wrote.


Best regards,
grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[gfxuser]

Am 12.05.12 10:02, schrieb Alexandre Prokoudine:

Hi,

AFAIK, our reasoning for presenting tools' options in a vertically
oriented dockable dialog in the sidebar is that we care about vertical
space.

If we do care about it, is there a reason we add a Wilber logo to the
top of the toolbar? I've been hearing questions how to remove it for a
couple of years already, and that tells me that users also care about
vertical space.

Opinions?

Alexandre Prokoudine
http://libregraphicsworld.org
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi Alexandre,
IMO the Wilber logo is currently not obsolete. Its purpose is to drag 
and drop files on it to open them in GIMP. This can also be done by 
dragging files onto the canvas. But AFAIK this only works with an empty 
canvas.
The technical easiest way to get more vertical space would be an option 
in Preferences/Toolbox/Appearance to show the Wilber logo. This would 
also match the product vision (' GIMP is user-configurable to automate 
repetitive tasks').
Another space saving solution: the 'Images' dialog could be made a drag 
and drop target and have an one click option to always stick in the 
foreground. Dragging an image into the dialogs empty space or an icon in 
its bottom bar would open the image. Dragging an image onto another 
image in the dialog would open it as a new layer. This had the following 
advantages for the users:
- they could then minimize the GIMPs main window(s) and toolbar to get 
more space on the screen
- they would still have a drag and drop target in the foreground 
wherever they want
- they would be able to open an image with just one click into the 
'Images' dialog


I think, GIMP usage should be made as easy as possible, to get rid of 
its long-year bad 'GIMP is too complicated'-image.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Native Mac version

[gfxuser]

Partha Bagchi wrote (was: Re: [Gimp-developer] Gimp 2.8 blend time)

The native Mac build has the menu all on the top just like all other Mac apps.
Thanks. Until now I didn't know of the native Mac build at all. Are 
these the versions from Macports or Fink? Where can I get it from, 
otherwise?
I always used Simone's build (gimp.lisanet.de) and was quite lucky with 
it. But currently there's a bug with the curves tool (bug #675906),
which makes photo editing with GIMP harder and I'd like to check this 
with the native version, too.


Thanks,
grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp 2.8 blend time

[gfxuser]

Hi,

On 2012-05-11.12 Michael Natterer wrote:


I don't currently have 2.8 installed on this Mac, but it can hardly
be slower, unless the threading got broken in GLib, try to set
#processors to 1 in prefs and try again.

thanks Mitch, for your reply.
You're right, on the Mac it depends on the number of processors. Varying 
this number in the preferences dialog between 1 and 16 showed 
significant differences. The operation takes 1 second if  #processors is 
set to 1 and about 8 seconds if it's set to 16 processors.
BTW: my Mac has 1 processor with 2 cores. It's quite pointless to be 
able to set #processors in prefs to 16. The upper bound for the input 
value should be the actual number of processors or cores. Is this a 
known issue or shall I file a new bug in Bugzilla?


Also, what build are you using? Native or X11?
How can I find this out? I used the fresh 2.8 version from 
gimp.lisanet.de. When running GIMP, the X window is open, too. So I'm 
sure it's the X11 build. How could I otherwise find out whether the Mac 
build is native?


Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp 2.8 blend time

[gfxuser]

Hi,

So, I've recently switched from gimp 2.6 to gimp 2.8, and I found that the time 
taken to draw gradients is far longer in 2.8 than in 2.6

To test, I made a blank black canvas at 1024px, then drew a radial gradient 
from center to edge.  2.6 drew it in under a second.  2.8 took 8.7 seconds to 
complete.

Is this something that others have noticed?
Yes, I can reproduce it with the 2.8 builds for Mac and Windows. The 
slowdown does not only affect the blend tool. This seems to be related 
with color management. In the Windows version you can speedup the blend 
tool among some other things by disabling the color management filter in 
View/Display filters This does a speedup for me, but it's only a 
temporary solution, as this only affects the currently open picture and 
only for this session. Also see bug #645345 in Bugzilla for a similar 
problem.
It's the same problem with the Mac version. 2.8 is slower than 2.6, but 
unfortunately the View/Display filters... trick doesn't work there.



Is it a result of the move to GEGL?

I think so.

Will it be fixed?


I hope so. This bug tempers the GIMP 2.8 honeymoon and I'm already 
thinking of staying with 2.6 for production or further using PS.


Or, the other way around: never switch to x.0 versions... ;-)

Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] Translation updates for GIMP 2.8

[gfxuser]

On 2012/05/05 at 11:26pm Cristian Secară wrote

În data de Sat, 05 May 2012 22:58:28 +0200, Michael Schumacher a scris:

Has this been reported as a bug?

I don't know how to fill a bug here,

Hi Cristi,

this is easy. Go to https://bugzilla.gnome.org/, click on the big blue 
button 'Open a New Account', fill in your account data.
After this, click on 'New' in the header, then on 'Other', then on 
'GIMP'. Fill in your bug report data, optionally add an attachment, 
click 'Commit'.
Or go to http://www.gimp.org/bugs/. The first chapter 'Bugs' contains 
useful information. At its end you find one link 'Submit a bug report' - 
just click there.


I hope I could help you.

Best regards,
grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] GIMP FxFoundry using GEGL?

[gfxuser]

Hi,

lately I found this very promising plug-in collection made by two 
well-known persons of this list ;-)
Will or need the plug-ins therein be ported to GEGL or do they use GEGL 
out of the box through the reworked PDP API?


Thanks,
grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Reading and saving of 3D MPO files in GIMP

[gfxuser]

Albrecht Lohöfener wrote

Hi,

I got the answer from Christian (the author of the MPO splitting 
software). He appreciates a MPO plugin for gimp and wrote: "So my 
understanding is that this does not make it incompatible with GPL v3 
at all!  But if it helps, I'm certainly happy to release mposplit 
under GPL additionally ..."

The result is that we can use the code in GIMP now!

How can we implement such an import filter? Is it more practical to 
add the MPO reading filter as an option to the JPEG filter or to 
create a new import filter that uses the JPEG source code from the 
JPEG filter?



Hi,

nice news and thanks, Christian!
My first thoughts are:

Create a new import filter for MPO files. JPEG doesn't depend on MPO and 
nobody knows whether MPO will always depend on JPEG only. In future the 
single image files in MPO could even be DNG files or whatever. These 
facts are reflected best by two separate import plug-ins.


Internally the import plug-in could work as follows:
1. Use MPOsplits code (by calling its functions) to extract the embedded 
JPEG data to new temporary JPEG files.
2. Use the existing import filters to load these JPEG files into two 
separate layers. The PDB API already has the function 
gimp-file-load-layer(s).
3. Give the layers meaningful names, for instance 'left eye view', 
'right eye view' for MPO files with only two embedded JPEG files. If the 
MPO file includes more than two JPEG files (like panoramic images) 
simply number them sequentially: 'image #1' and so on.

4. Internally clean up: delete the temporary files.
The best way to use MPOsplit would be that its author Christian makes 
MPOsplit a library with a quite easy, elaborate and unalterable (or at 
least rarely altering) interface. This had the advantage that his 
software could have broader dissemination by reuse and GIMP could 
participate from MPOsplits evolution without much effort.


An MPO export filter could work like this:
1. For each single view: hide the unnecessary layers: for the edited 
left eye view hide the right eye's view layer and so on. Export the 
visible part of the result to a temporary JPEG file (using PDB APIs 
function file-jpeg-save) for each view.
2. Use MPOsplits code (by calling its functions) to merge the temporary 
JPEG files into a single MPO file.

3. Internally clean up: delete the temporary files.

In a second increment the import filter could be extended to load the 
MPO files thumbnail (APP1's thumbnail in the MPO file format spec) and 
show it in the 'Open image'-dialog.


A next step could be the proper handling of the MPO files' metadata 
(EXIF, IPTC, XMP and so on).


BTW: I don't want to arouse unfulfillable expectations, but this sounds 
like an easy task for a beginner or a GSoC student, if this feature 
request is of enough importance and there's yet time to fill with tasks 
before GSoC ends. Albrecht, could you please file an enhancement request 
in Bugzilla, if you haven't already done? This is the usuaI way after 
discussing it here and I think this helps you and our developers most 
for now.


Best regards,

grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Demo] Porting MyPaint brush engines to the GIMP.

[gfxuser]

Hi,
In Gimp on the other hand you don't have such presets and you start 
every time from scratch to design the brush again and again that you 
used previously. An excellent way to kill time without progress and 
desired result. :-(


It's not about the settings of the brush itself, it's about reusing 
brushes and their corresponding settings. For example: I use a knife 
to add color to a painting, then i use a knife without color to refine 
details and then i use the knife with color again. Switching between 
the two brushes can be done in MyPaint with one click or hotkey. But 
what will you do in Gimp?
have you heard of GIMPs already existing abilities to save and load 
presets? They are in version 2.6.12, but they have already been for 
longer time in GIMP.
You find them at the bottom of each tools' window, like the brush 
dialog. There are disc icons to save, load, delete and reset tool 
presets. The stored settings contain the particular tool settings as 
well as the color. I just tried it out. Also the small triangle icon in 
the upper right corner of the tools dialogs offers these abilities.
There are also many ready-to-use tool presets and brushes for instance 
at 
http://browse.deviantart.com/resources/applications/gimpbrushes/?order=9, which 
can be very useful.
What I was missing in the past were predefined presets out of the box, 
shipping with GIMP, but this will change in 2.8. Version 2.8RC1 has a 
reworked preset system: GIMP will ship with some presets, some reworked 
painting brushes and a preset window like Photoshop's 'Tool presets' 
window. I still haven't found a way to activate a particular preset by 
using a hotkey, but you can bind the new Preset window to a keyboard 
shortcut.


That the brush circle is so sloppy really irritates from drawing, not 
seeing where you really are. 
Version 2.6.11 on my Windows system works fine in this point. For 2.8RC1 
on Windows and 2.6.12 on OS X I have to agree with you.


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Demo] Porting MyPaint brush engines to the GIMP.

[gfxuser]

I'm currently working on porting of the MyPaint brush engine to the
gimp 2.7.5 branch.
It's under heavy development yet, but some functions already work.
You can see some demonstration video at youtube.
[Demo]
http://www.youtube.com/watch?v=hzUwPF1_6H8

Really nice and awesome!
What makes these brushes different to the GIMP brushes with 2.8 dynamic 
options?
Are they some kind of procedural brushes like this: 
http://celarek.at/2012/01/lindenmayer-brush-for-krita/?


Best regards
grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] javick

[gfxuser]

Am 30.04.12 04:40, schrieb Ivano Arrighetta:

sorry, i posted a wrong url.
right one:
https://docs.google.com/document/d/1Lut6Y6Xe-4ScR9G4Fg6EorTuSp0JKuTP6QRRzrk0kSM/edit

Inviato da iPhone
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi,

it was nice if you could explain here a bit more, what you're trying to 
tell.
So I read your doc and as far as I can see you want GIMP to send image 
data to an application which converts them to sounds and vice versa, right?
Have you heard of Metasynth, which generates sounds from images? For the 
other way around (converting sound data to images), there are already 
visualization plug-ins for many media players, like G-Force and so on. 
You could capture their output from screen and paste it into GIMP to do 
further artwork with them. But I doubt it would be sufficient to act as 
a VJ, since GIMP is more an image editor than a video editor.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Reading and saving of 3D MPO files in GIMP

[gfxuser]

With such a clarification, there shouldn't be any reason to use the
code as the basis for a GIMP plugin or patch.

g>  Did I get you right? If the code wouldn't be used in GIMP, why then
g>  any clarification is needed?
g>  Could you please clarify this? ;-)

If the code -- or a derivative thereof -- would not be used in GIMP,
then why did the first reply suggest (needlessly) trying to get the
code relicensed as GPL3?


So, this seems to be a misunderstanding.
I meant: if the existing MPOsplits code - or a derivative thereof - 
would be integrated into GIMP, then there could be a problem due to 
incompatible licenses
(BSD-style vs. GPL 3). So then there were two possibilities: either the 
MPOsplits author decides to publish his program under GPL v3 or another 
GPLv3-compatible license or
- even simpler - Albrecht asks him for clarification which 'BSD-style 
license' he exactly means and depending on this answer a developer 
decides to use the existing code or not.
I agree with you for the case that MPOsplits original or derivative code 
is not integrated into GIMP and both programs would stay standalone 
products.

Then this clarification would be needless.

Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Reading and saving of 3D MPO files in GIMP

[gfxuser]

James Cloos wrote:
>With such a clarification, there shouldn't be any reason to use the 
code as the basis for a GIMP plugin or patch.
Did I get you right? If the code wouldn't be used in GIMP, why then any 
clarification is needed?

Could you please clarify this? ;-)

Best regards,
grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Reading and saving of 3D MPO files in GIMP

[gfxuser]

Hi,

>Is it possible to implement an import filter which reads the MPO file 
and loads the right picture as layer 1 and the left picture as layer 2, 
for example?
>The advantage of this would be that the right and left picture are 
edited simultaneously in the same way when I edit a 3D picture.
This sounds like a nice idea and offers new possibilities in photo 
editing and doing artwork with GIMP. If there are no other convincing 
answers which keep you off, file an enhancement request in Bugzilla. If 
then, there should be an MPO export plug-in, too. Maybe somebody will be 
willing to implement it sooner or later.


> On this site 
(http://cstein.kings.cam.ac.uk/~chris/mposplit/index.html) there is a 
sourcecode which splits the MPO file in two JPEG files.
As far as I can see, it is under a BSD-style license. GIMP is GPL v3, 
isn't it? This might cause license issues, as they can be incompatible, 
see http://www.gnu.org/licenses/gpl-faq#OrigBSD.
But perhaps the author is willing to choose a GPL compatible license or 
somebody else uses the official MPO specification to write an MPO import 
plug-in for GIMP.


Best regards.


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] that typing business...

[gfxuser]

> In GIMP you very seldom get away with one key.

Hi,

do you mean this needs to be improved?

Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp 2.8 splash screen suggestion

[gfxuser]

Am 15.04.12 21:39, schrieb Bernhard Stockmann:

hey everyone!

I made a startup splash screen in GIMP for GIMP 2.8. also filed a bug 
on it here: https://bugzilla.gnome.org/show_bug.cgi?id=674154


If you like it you can use it!

Is there another way to submit splash screens? Or are there any 
official guidelines?



+10
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An appeal for insight into the development of GIMP

[gfxuser]

Hi Martin,

The subject areas I would like to cover in the interview are GIMP's:

* Development flow and release cycles
* Social structures, responsibilities and decision making
* Code structure and architectural considerations
* Special conditions caused by the open source environment
As potential contributor I'm very interested in answers to these 
questions, too.


I realize your time might be scarce, but if you decide to contribute to
this case study your help shall be all the more appreciated. Once
finished I will gladly share my results and any new insights gained on
the topic with you.

I would appreciate this. If you want to tell, which other projects have 
you planned to interview and what is your scheduling to have finished?


Best regards and I wish you success with your thesis,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] ANNOUNCE: GIMP 2.7.5 released

[gfxuser]

Hi,

GIMP 2.7.5 has been released. This is the last development snapshot in
the unstable 2.7 series that leads to 2.8. Only release candidates and
the 2.8 release will follow.

Hello. What is the normal amount of time before a Windows version should be
expected too? Thanks.

Hi,

in my experience this time is short, less than a month.

You might look at
http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28development%20rel.%29/GIMP%202.7.5/
The file date for version 2.7.5. is the same as the announcement date at 
the GIMP news page.


In its parent directory

http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28development%20rel.%29/

you will find other development builds, for instance the 2.8 RC1. 
Remember, they are unstable development snapshots.


I also tried the 2.7.5 build at graphicall.org lately (which appeared 
before the official announcement of version 2.7.5.), but I missed some 
expected features, which the GIMP-WIN projects build has.


grafxuser

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gsoc - Slicing Tool

[gfxuser]

Hi,

I might have overlooked something, but what's the difference to the 
already existing Image-Map filter (see Filters/Web/Image-Map) and Slice 
dialog (Filters/Web/Slice...)?
The first filter already has possibilities to make rectangular, circular 
or polygonal selections plus options for the URL or frame to jump to and 
Javascript event options.

The map itself can be saved, too.
Wouldn't that be a duplication of functionality? If not, maybe these 
already existing possibilities build a foundation for the "new slicing 
tool" and can partially be reused?


Greetings,

grafxuser



___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gsoc - Slicing Tool

[gfxuser]

Am 31.03.12 09:49, schrieb noob7:

Hey there!
Iam interested in this year gsoc. I would like to take slicing tool 
idea which I heard that its one of most requested features. I get the 
main conept of this tool. Ive tested guillotine action and slice 
filter on compiled trunk version. I found that slice filter still have 
some issues. On irc I was told to talk to ,,guiguru" which is mitch? 
about gui for this tool. Do you have any comments about slice tool ? I 
would love to hear some feedback.



Hi,

as far as I know, 'guiguru' is Peter Sikking, isn't he? He is the 
interaction architect in the GIMP project.


Greetings,
grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Screenshot tool: Unify plugin for Windows, Linux and Mac OS X

[gfxuser]

Hi,

> I don't see much purpose in explicitly using external snapshot tools
> from within Gimp.
The purpose is to provide a good screenshot functionality while 
relieving the overloaded GIMP developers.


> If the users have these tools installed they know how to use them,
Think of an average user, a luser or an stressed expert. I know of 
average users who had Windows 7 for a year and never heard of its 
screenshot utility.


> and they may have a hotkey that makes them a lot easier to access
> directly than from Gimp.
Did you know: the standard hotkey for screenshots on Mac OS X is 
Shift+Ctrl+Apple+3. It's not everywhere as easy as in Windows.
In GIMP you need four mouseclicks to capture a screen, on Mac you need 
patience to find the hotkeys and four fingers (and maybe a bandage for a 
broken finger )


> And I don't see how Gimp is going to keep up with an even growing
> list...
I proposed a list with at maximum 3 items to choose from: GIMPs own 
screenshot plugin, the operating systems tool and third party tools. The 
latter two can be combined: GIMP would offer the operating systems tool 
and the option to browse the file system for another tool. Then there 
are only two options.
So GIMP would always be up to date while saving its own development 
resources.


> "File/Create/from clipboard" gives the most bang for the buck if you 
> want to use external snapshot tools.
You're right in this point. This is an easy way to import screenshots 
into GIMP after they were made.


Greetings,
grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Learning from others

[gfxuser]

Hi,

GIMP is accepted to GSoC, which is a chance to share deeper knowledge 
about GIMP development, at least among the mentors and their students.
Will the students questions be discussed here in the mailing list or 
pooled in the wiki? I think, this would be useful to let all (potential) 
contributors learn more.
I already glanced over the archived developer mailing list and the wiki, 
but all I found were GSoC ideas and code reviews. In case I overlooked 
something you can of course point me to the resources.


Greetings,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] ANNOUNCE: GIMP 2.7.5 released

[gfxuser]

Hi,

I just played a bit around with the Windows build of v. 2.7.5. I'm very 
impressed, especially of the layer groups, the new brushes and paint 
dynamics.


Good work!

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Easy access for contributors

[gfxuser]

At 16.03.12 16:42, bootch nc.rr.com wrote:

grafxuser:

Could you please expound on your idea?  (I don't know much about virtual machines.)  What 
would a "middle level" developer do to get the environment and what would they 
have to learn about virtual machines and about GIMP development?  It sounds like magic to 
me.  I assume that you mean something like: a user downloads and installs one package.  
The package does not do any building at installation time, all libraries and programs 
(GEGL, GIMP, etc) are already built in the virtual environment?  After that, they can 
enter a virtual environment where they can hack on GIMP without fear of destroying their 
production environment.  Or do they first need to download the virtual machine package 
that supports virtual machines?  They can destroy and refresh the virtual environment 
whenever they want, but it may take a few hours to download it again?

Do you have a link to another project that offers a virtual development 
environment?
You can think of a virtual machine (VM) as a 'computer in your 
computer'. It's a software which emulates a computer. In a VM (the 
'guest' computer) you can run programs like on a physical computer. It's 
a common technique to test programs safely. Your physical computer (the 
'host'), which runs the VM, is not touched by the processes in the VM. 
So you can safely test or modify developer versions of GIMP in the VM 
without disturbing your productive GIMP version on the host. Even if you 
destroyed the whole system within the VM, it would have no bearing on 
the host computer. It's a sandbox. This works vice versa - installing 
software on your host computer usually doesn't affect the guest 
environment.


Modern VM software uses savepoints (like in computer games): if you came 
to a dead end in your VM, you can recover a stable state in a very short 
time. Depending on the power of your physical computer it's only a 
matter of up to a few minutes. You wouldn't neither have to download the 
virtual environment for hours again nor wouldn't you need to sit a whole 
weekend to recover a broken physical environment in this case.


Also a VM can be used to compare two different GIMP versions, like a 
developer version and a stable version. This can be useful to check 
whether open bugs are already fixed. It also has the benefit of a 
defined environment for contributors. They could help each other easier 
and in shorter time, no matter which physical environment they own.


To be fair it should be mentioned, that final product tests must still 
be done in the target environment. So a VM running Linux cannot be used 
for final tests of GIMPs Windows or Mac versions. Also a VM can do no 
magic if the host operating system doesn't recognize particular 
hardware. If some hardware is not recognized by the host operating 
system at all, the VM wouldn't also be able to use it.


From a technical point of view the VM consists of two parts: the 
emulator software (the 'hypervisor') and a big data file (the 
'appliance'). For a more detailed description see 
http://en.wikipedia.org/wiki/Virtual_machine, especially the chapter 
'Emulation of the underlying raw hardware (native execution)'.


A GIMP specific VM could look like this:
Due to license issues the guest operating system needs to be Linux. This 
also has the advantage to receive distro software updates constantly 
without much effort.
For testers, bug triagers or people who just want to play with a current 
GIMP: a pre-built, fully operative GIMP with documentation.
For developers, authors, translators: a ready-to-use development 
environment with the GIMP sources und developer documentation.
For all: an IRC software and a browser with bookmarks to important GIMP 
sites: GIMP.org, GIMPs G*+-site, Bugzilla etc.
To be independent from specific hypervisor products, the VM should be in 
an open file format, like OVF 
(http://en.wikipedia.org/wiki/Open_Virtualization_Format)

This is a first proposal. Detail questions need to be discussed separately.

A user would
1. download and install the hypervisor software
2. download the GIMP appliance and import it into the hypervisor
3. boot the GIMP-VM and start playing or working

Well-known hypervisor products are Virtualbox, VMWare or Virtual PC. 
There are already some projects offering appliances, for instance the 
VMWare Marketplace, Turnkey Linux, Suse Studio Gallery or the Oracle 
Developer VMs. Using these keywords a search engine will show the right 
addresses among the first results. Maybe there is already something that 
can be used out-of-the-box or with minor modifications.


Greetings,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Translate to pt_BR

[gfxuser]

Looking at http://l10n.gnome.org/languages/pt/gnome-gimp/ui/ and bug 
#667282 I see that the Portugese translation needs help, too.
Maybe Portugese and Brazilian Portugese are similar enough to unite your 
forces with the Portugese translation team to a mutual benefit?

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Easy access for contributors

[gfxuser]

Hi,
Based on the thread title "[Gimp-developer] Easy access for 
contributors" and the initial message I was under the impression that 
we are talking about an idea of offering a /"pre-built developer 
virtual machine, created with say SUSE factory and downloadable from 
the GIMP developers page"/ or similarly fashioned dev 'shortcut' and 
not GSoC. Did I get the context wrong?
No, you just got it right. My initial posting did not address developers 
only, but also other potential contributors, like testers, bug 
reporters, artists etc. IMO it's not their business to first learn 
Linux, to package, to set up an environment, meanwhile see gray hair 
growing on their heads and - weeks or months later - eventually start 
trying out Gimp. Judging from my own painful experiences when making my 
first steps with Linux I see very few chances, that they will be still 
in the biz then.
If not... With that context in mind, it seemed like a worthy idea to 
provide such a thing to the public.
I'm glad that somebody else sees these chances. As Alexandre stated 
here, Gimp developers currently have no capacities for packaging. 
Presently I'm also not able to do it, but if the idea is good, don't get 
it lost! Maybe I can return in a few months and see this idea has 
matured and put more energy into it.


Secondly, in Gimps download area I saw binaries only for the stable 
branch, if current at all. For version 2.7.5. there are only sources 
available. The aforementioned people need something do start and go. So 
I made the proposal (oh no, a proposal... ;-) ) to put a link to 
graphicall.org at the links page (http://graphicall.org/?keywords=gimp). 
They have pre-built Gimp packages (without dev environment I suppose, 
but this would be enough). This seems do be doable and Gimps website 
maintainers are currently working on a site redesign. It could bring 
more supporting people into this project without much effort. Maybe you 
have capabilities to support the team there.


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Easy access for contributors

[gfxuser]

First of all I apologize for my overreaction.

I misunterstood your lines and a lot of bad memories came up to me. IMHO 
e-mail has its weaknesses when trying to express emotions and they 
became to strong here. I didn't think of this.


Best regards,

grafxuser


___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Easy access for contributors

[gfxuser]

First of all I apologize for my overreaction.

I misunterstood your lines and a lot of bad memories came up to me. IMHO 
e-mail has its weaknesses when trying to express emotions and they 
became to strong here. I didn't think of this.


Best regards,

grafxuser
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list