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] High bit depth processing

[Simon Budig]

Partha Bagchi (parth...@gmail.com) wrote:
> Is there is something one should know about the interaction with gegl
> for loading tiff or everything is contained in file-tiff-load.c?

I have not yet pushed any changes to file-tiff-load.c. But if you want
to look at how to use gegl for loading files then have a look at
file-png.c. This btw. was a port that was reasonably easy, the trickiest
thing being indexed PNGs.

file-gegl.c (EXR/HDR) is interesting as well, since it uses just pure
gegl to load the files, i.e. it constructs a graph that provides the
image data passed to gimp. Unfortunately this also means that I cannot
easily fix the mismatch in the data format for some files in the plugin...

I hope this helps,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
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

[Liam R E Quin]

On Sat, 2012-05-12 at 18:37 +0200, gg wrote:
[to SorinN]
> As the in-house GUI expert , I'm rather surprised you don't see that as 
> the priority too. But if you have "attachment" there's probably no harm 
> in you liking it.

Useability does not operate in a vacuum - branding is part of the user
experience.

Useable is aslo not always the same as "immediately comfortable."

Please, let's not attack people. It's really only a few pixels, and if
that's such a major issue I'd expect a bigger focus on more efficient
use of space in the docks and the file chooser dialogue. Power users can
turn wilber off, and I more often hear requests for a toolbar (which
would use up as much or more space!) than for how to turn off wilber
from newcomers to the gimp. Perhaps this is because Photoshop and
Illustrator also use the same space for branding.

I do think that if gtk had an explicit "drop files here" widget, maybe
like the one Sun and AT&T experimented with some 15 years ago (theirs
also had a "drag out from here" button that changed when the document
was non-empty) then the demands on Wilber might change, both in the
toolbox and in the no-image-window, but such a drag widget would need to
be used elsewhere, e.g in the gnome text editor, file manager, etc. The
useability studies at the time were very promising.

Best,

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

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

Re: [Gimp-developer] High bit depth processing

[Partha Bagchi]

If it's making you swear using words that Alexandre can't understand,
then the code must be elegant indeed. :)

Is there is something one should know about the interaction with gegl
for loading tiff or everything is contained in file-tiff-load.c?

On Sat, May 12, 2012 at 6:21 PM, Simon Budig  wrote:
> Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
>> 16bit PNG can be loaded and saved
>> EXR opens as 32bit float, but is saved with 16bit precision.
>
> Also .hdr files are handled by file-gegl as well.
>
>> Simon already evaluated porting TIFF loader to GEGL, but I couldn't
>> understand a single word through lots of swearing in German, and
>> that's after having studied German since I was a lad :) The general
>> idea, however (if I got it right), is that the file format is messy,
>> so is the original code. In other words, it will take some time to get
>> this done. As usual, patches are welcome.
>
> Yeah, I did a stab in the general direction of the tiff plugin, but the
> TIFF library is quite twisted in its ways. I'll have a look at it again,
> but If someone else wants to take a shot at it please go ahead, I am not
> too eager...  :)
>
> Bye,
>        Simon
> --
>              si...@budig.de              http://simon.budig.de/
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] High bit depth processing

[Simon Budig]

Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote:
> 16bit PNG can be loaded and saved
> EXR opens as 32bit float, but is saved with 16bit precision.

Also .hdr files are handled by file-gegl as well.

> Simon already evaluated porting TIFF loader to GEGL, but I couldn't
> understand a single word through lots of swearing in German, and
> that's after having studied German since I was a lad :) The general
> idea, however (if I got it right), is that the file format is messy,
> so is the original code. In other words, it will take some time to get
> this done. As usual, patches are welcome.

Yeah, I did a stab in the general direction of the tiff plugin, but the
TIFF library is quite twisted in its ways. I'll have a look at it again,
but If someone else wants to take a shot at it please go ahead, I am not
too eager...  :)

Bye,
Simon
-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Translating GIMP from GIMP master (is wrong)

[Kevin Cozens]

On 12-05-12 05:03 PM, Kevin Cozens wrote:

On 12-05-09 05:30 AM, Gabor Kelemen wrote:

Seems like a recent change in intltool causes this, which makes the scheme
string extraction done by xgettext instead of intltools built-in and dropped
parser.


I forgot to add some information.

There was some discussion about modifying the Script-Fu scripts to conform 
to the (Guile) supported method of markup. My initial feeling was that it 
would not be that difficult to change the interpreter to support the method 
but I also suspect that the change in syntax in the scripts will lead to 
problems.


I'm busy with an online course for another three weeks or so which limits 
the time I have to spend working on making the changes and seeing if it 
would break the scripts. My concern is for markup of strings in register blocks.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

[peter sikking]

first, thanks to Guillermo for the insight and the encouraging words.

then, Alexandre wrote:

> "has to be easy to review and apply by the maintainer(s);" -- let's
> just call it Git formatted and made against a rebased clone of the
> master branch, shall we?

actually that sentence about "easy to review and apply by the
maintainer(s)" was said exactly like that in the bof at lgm.
so I thought I included it, there must be an open source point in it.

the whole git business is of course a very detailed implementation
of that.

> On the whole, I agree with this first stab and would like to move this
> description (once finished) to wiki.gimp.org :)


be my guest. you can even add the git bit.

--ps

founder + principal interaction architect
man + machine interface works

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



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

Re: [Gimp-developer] Translating GIMP from GIMP master (is wrong)

[Kevin Cozens]

On 12-05-09 05:30 AM, Gabor Kelemen wrote:

https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme
string extraction done by xgettext instead of intltools built-in and dropped
parser.


The information for revision 722 indicates that intltool-extract.in and 
intltool-update.in had the support for Scheme code in files ending with .scm 
removed. The test case file "test.scm" was also removed.


I would be interested to know more about why this change was made. Back in 
the early days of gimp when these two scripts were part of the GIMP source 
tree we had to apply a patch to make them handle the marked strings in 
GIMP's .scm files.


It's almost as if there is supposed to be one way of marking strings in 
Scheme based scripts (regardless of which interpreter is being used), or 
xgettext never got the additional changes to handle strings marked in .scm 
files the way they are in GIMP's Script-Fu scripts, or both.


If there is a move towards using xgettext to do string extraction we need to 
find out how to use it to extract strings from Script-Fu scripts. If it 
can't do that, we should ask the gettext people to update xgettext to 
include the code that was dropped from the two external scripts.



In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says
that the gettext shorthand for scheme strings is (_"foo"), so I think your
source files should be modified to conform this notation.


Scheme in gettext manual references GNU guile. BTW, the markup it uses has a 
space between the _ and the opening " of the string. The form _"abc" is 
still valid markup for awk but I don't expect that to be of much help to us.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[Kevin Cozens]

On 12-05-12 04:02 AM, Alexandre Prokoudine wrote:

If we do care about it, is there a reason we add a Wilber logo to the
top of the toolbar?


As Tobias mentioned it is a drag and drop target area. There is a tooltip 
that pops up if you point at the area long enough with the mouse. The logo 
in there does nothing to make you think it is anything but decoration. A 
different icon or some text might be more useful (IIRC, there was some text 
in there at one time).


I'd forgotten it was there as I turned it off some time after that area 
appeared as I never use drag and drop with GIMP. I just tried dragging 
images to the image window when no image was open and the only image type I 
could drag was a PNG file. If I try to drag a JPG file I get a GIMP Message 
box popping up saying that the open failed due to "Unknown file type".


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.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] wilber in the toolbar

[Alexandre Prokoudine]

On Sat, May 12, 2012 at 11:14 PM, Guillermo Espertino (Gez) wrote:

> Wilber by itself doesn't communicate the behavior, so users who
> didn't read about it will only know that dragging and dropping works
> by... dragging and dropping.

That was exactly my point. I'm sorry it caused such an uproar, but at
least I didn't suggest renaming GIMP :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
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

[Guillermo Espertino (Gez)]

I think it would be nice if that portion with willber is revealed with 
some sort of highlight when the user drags an importable file over the 
toolbar. That would give a hint without using the space permanently.
Wilber by itself doesn't communicate the behavior, so users who didn't 
read about it will only know that dragging and dropping works by... 
dragging and dropping.
Making it visible when users drag a file over the toolbar will 
communicate that they can also drop it.
Currently it only works as a reminder, but you have to know about it to 
use it.


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

[gg]

On 05/12/12 18:04, SorinN wrote:

..de gustibus
probably an option in preferences will solve this problem forever
one million less me will put out the icon, me not - so we just get
million of happy peoples.

so my opinion is for the option to choose enable / disable Wilber icon
  in preferences



on that basis , the way to have million of happy peoples is to have it 
off by default, since most people will never be aware of the option and 
you (and mitch ;) ) are and can turn it on and cuddle him / she / it, or 
whatever it is you do.


The rest of the world gets some useful space.

As the in-house GUI expert , I'm rather surprised you don't see that as 
the priority too. But if you have "attachment" there's probably no harm 
in you liking it.


/gg


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

Re: [Gimp-developer] Save defaults not working?

[Jernej Simončič]

On Saturday, May 12, 2012, 14:20:02, Guillermo Espertino (Gez) wrote:

> btw, new jpeg defaults are much, much better than 2.6s but imo the 
> progressive option shouldn't be on. It makes the file size a tad larger
> and it isn't always needed. Is there any special reason for using that
> option as default?

In my experience, the majority of images become smaller when you save
them as progressive.

-- 
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

A computer makes as many mistakes in two seconds as 20 men working 20 years.
   -- Horowitz's Rule

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

Re: [Gimp-developer] High bit depth processing

[Alexandre Prokoudine]

On Sat, May 12, 2012 at 10:34 PM, Partha Bagchi wrote:

> Thanks Alexandre. If I understand the chart, one cannot open 16-bit
> tiff yet? Which format can be opened in 16-bit?

16bit PNG can be loaded and saved
EXR opens as 32bit float, but is saved with 16bit precision.

Simon already evaluated porting TIFF loader to GEGL, but I couldn't
understand a single word through lots of swearing in German, and
that's after having studied German since I was a lad :) The general
idea, however (if I got it right), is that the file format is messy,
so is the original code. In other words, it will take some time to get
this done. As usual, patches are welcome.

Alexandre Prokoudine
http://libregraphicsworld.org
___
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

[Liam R E Quin]

On Sat, 2012-05-12 at 19:06 +0200, peter sikking wrote:
[...]
> > A gtk+ drop target might be a better approach.
> 
> is that a standard widget? I have trouble googling it.

No, I am sorry, I was overly laconic. You are standing in
my sunlight.

I was trying to suggest that gtk+ could add a new widget,
a drop target - and perhaps also a drag source. Then there
would be an explicit affordance rather than a hint.

But I have just come from Hamburg, where many things are
explicit that elsewhere are only hinted at :-)

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

___
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

[Liam R E Quin]

On Sat, 2012-05-12 at 19:06 +0200, peter sikking wrote:
[...]
> > A gtk+ drop target might be a better approach.
> 
> is that a standard widget? I have trouble googling it.

No, I am sorry, I was overly laconic. You are standing in
my sunlight.

I was trying to suggest that gtk+ could add a new widget,
a drop target - and perhaps also a drag source. Then there
would be an explicit affordance rather than a hint.

But I have just come from Hamburg, where many things are
explicit that elsewhere are only hinted at :-)

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

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

Re: [Gimp-developer] High bit depth processing

[Partha Bagchi]

Thanks Alexandre. If I understand the chart, one cannot open 16-bit
tiff yet? Which format can be opened in 16-bit?


On Sat, May 12, 2012 at 2:30 PM, Alexandre Prokoudine
 wrote:
> On Sat, May 12, 2012 at 10:17 PM, Partha Bagchi wrote:
>> Downloaded the gitmaster from the usual place:
>> https://gimptest.flamingtext.com:9090/ Built it on Windows. Saw the
>> goat-invasion screen. Opened a 16-bit TIFF - and it opened as an 8-bit
>> file. What am I missing?
>
> http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL#File_loaders.2Fsavers
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] High bit depth processing

[Alexandre Prokoudine]

On Sat, May 12, 2012 at 10:17 PM, Partha Bagchi wrote:
> Downloaded the gitmaster from the usual place:
> https://gimptest.flamingtext.com:9090/ Built it on Windows. Saw the
> goat-invasion screen. Opened a 16-bit TIFF - and it opened as an 8-bit
> file. What am I missing?

http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL#File_loaders.2Fsavers

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

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

[Alexandre Prokoudine]

On Sat, May 12, 2012 at 8:46 PM, peter sikking  wrote:
> guys,
>
> lately I have been thinking about introducing a new process.
>
> this thinking has been accelerated by the GIMP bof at the lgm,
> where GIMP project members expressed concern about lack of
> openness and transparency in the current UI redesign work, and
> I expressed concern about lack of valuation and respect for
> the field of interaction design.
>
> the discussion at lgm was constructive, and I think that
> everybody should just act to address all of the concerns.
>
> I think that the new process that I am thinking about can
> contribute to that.
>
> this process is an ‘interaction design patch/contribution’ for new,
> fresh contributors, that I want to model it one-to-one on the established
> code patch/contribution process (for new, fresh contributors).
>
> so first we need a good description of this code contribution process,
> before adapting it.
>
> I have given it a first stab:
>
> 
>
> I like to discuss it here on this mailing list and get it
> in a shape that is beyond reasonable doubt. after that the
> next steps can be taken.

"has to be easy to review and apply by the maintainer(s);" -- let's
just call it Git formatted and made against a rebased clone of the
master branch, shall we?

On the whole, I agree with this first stab and would like to move this
description (once finished) to wiki.gimp.org :)

Let's see how interaction design part evolves.

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

[Gimp-developer] High bit depth processing

[Partha Bagchi]

Downloaded the gitmaster from the usual place:
https://gimptest.flamingtext.com:9090/ Built it on Windows. Saw the
goat-invasion screen. Opened a 16-bit TIFF - and it opened as an 8-bit
file. What am I missing?

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

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

[Guillermo Espertino (Gez)]

El 12/05/12 13:46, peter sikking escribió:

I have given it a first stab:



I like to discuss it here on this mailing list and get it
in a shape that is beyond reasonable doubt. after that the
next steps can be taken.


Makes sense to me. With the spanish-speaking libre graphics community 
(graficalibre.org) we tried to figure out how to move the existing FLOSS 
development model to graphic design (specifically brand and identity) 
and we also found that a completely open and decentralized model wasn't 
up to the task, just as a completely closed and controlled wasn't either.
So we refined the procedures until we got to a process which is pretty 
close to the one you're describing.
There has to be an "authority role" that has the final word about what's 
in and what's out, and that person (or a small team coordinated by that 
person) will define the guidelines of what is needed and the quality 
expected from contributions.
Contributors can assign themselves pending "tasks" and provide solutions 
following those guidelines and procedures, and the mantainer will 
evaluate the result, provide feedback and finally accept/reject the 
contribution.
So far it worked fine, and having someone saying what to do worked 
better than total freedom, because it's almost impossible to get 
direction from a large group of contributors without a leading role. 
Also it's easier to contributors to choose what to work on: they can 
just pick a task and focus on it without worrying too much about the big 
picture.
Some people might see this as something less "democratic", but if we 
choose the leading role based on previous track record and merit, we'll 
be chosing democratically our representative, and we can still have 
freedom to discuss decisions with people in charge, so there's no problem.
Personally I think your work (and your team's) has proven the importance 
of having UI experts among our devs and I'll be happy to see you leading 
this new process, and I expect to see great things coming from it.


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

[peter sikking]

gfxuser wrote:

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


your question is general enough that the answer could grow
textbook size. narrowing it down could give am chance to
answer it.

meanwhile, I did find an old blog post that may go into what
you want to know:



(watch out that the top-10 list that it segues into is
heavily outdated and superseded; not useful to start discussions
about that anymore)

--ps

founder + principal interaction architect
man + machine interface works

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



___
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

[peter sikking]

Liam wrote:

>>> "drop images" text message would me more efficient and explicit
>>> or probably an icon representing the drag and drop action...
>> 
>> now that would be really annoying, looking at that 40 hours a week,
>> every week of the year, no?
> 
> A gtk+ drop target might be a better approach.

is that a standard widget? I have trouble googling it.

--ps

founder + principal interaction architect
man + machine interface works

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



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

[Gimp-developer] contribution processes...

[peter sikking]

guys,

lately I have been thinking about introducing a new process.

this thinking has been accelerated by the GIMP bof at the lgm,
where GIMP project members expressed concern about lack of
openness and transparency in the current UI redesign work, and
I expressed concern about lack of valuation and respect for
the field of interaction design.

the discussion at lgm was constructive, and I think that
everybody should just act to address all of the concerns.

I think that the new process that I am thinking about can
contribute to that.

this process is an ‘interaction design patch/contribution’ for new,
fresh contributors, that I want to model it one-to-one on the established
code patch/contribution process (for new, fresh contributors).

so first we need a good description of this code contribution process,
before adapting it.

I have given it a first stab:



I like to discuss it here on this mailing list and get it
in a shape that is beyond reasonable doubt. after that the
next steps can be taken.

--ps

founder + principal interaction architect
man + machine interface works

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



___
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

[SorinN]

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

strange, I was thinking that this topic was related to UI usability
of course speed of use has nothing to do with that icon
and freedom to create also ...

I will keep Wilber there - probably because I think is fancy, probably
because mean something to me
but I am one in a million
probably the other side of the million think in favor of vertical usable space

..de gustibus
probably an option in preferences will solve this problem forever
one million less me will put out the icon, me not - so we just get
million of happy peoples.

so my opinion is for the option to choose enable / disable Wilber icon
 in preferences


2012/5/12 peter sikking :
> SorinN wrote:
>
>> "drop images" text message would me more efficient and explicit
>> or probably an icon representing the drag and drop action...
>
> now that would be really annoying, looking at that 40 hours a week,
> every week of the year, no?
>
>> Wilber itself has nothing to do with the fact of
>> "remembering the drag and drop" ..it's just a branding sign
>> for me is ok - I like it there but :
>> - a new user will not be informed about the functionality we talk about
>> - an old GIMP user ...know that already
>
> we are talking about a shortcut here. first of all the normal,
> highly findable (of not a bit boring) way is to use the File->Open
> menu item. nifty shortcuts like this are documented in the
> manual, and shared on the internet.
>
>> for meis ok as is (I have no points against it) - but talking about 
>> usability ...a clean message or a representative icon for that functionality 
>> would do a better informal job.
>
> 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.
>
>    --ps
>
>        founder + principal interaction architect
>            man + machine interface works
>
>        http://blog.mmiworks.net: on interaction architecture
>
>
>
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list



-- 
Nemes Ioan Sorin
___
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

[Michael Natterer]

OMG not again :)

1. Wilber is cute
2. If you don't like Wilber, add (toolbox-wilber no) to gimprc

Regards,
--mitch

On Sat, 2012-05-12 at 12:02 +0400, Alexandre Prokoudine wrote:
> 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


___
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

[Liam R E Quin]

On Sat, 2012-05-12 at 15:41 +0200, peter sikking wrote:
> SorinN wrote:
> 
> > "drop images" text message would me more efficient and explicit
> > or probably an icon representing the drag and drop action...
> 
> now that would be really annoying, looking at that 40 hours a week,
> every week of the year, no?

A gtk+ drop target might be a better approach.

It might be fun to have a giant wilber as background to the toolbox, but
I don't know how distracting it'd be.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

___
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

[gg]

On 05/12/12 12:36, gfxuser wrote:


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.


So this bar is only there to host a dumb logo, it is a total waste of 
space in an environment where space is a premium.


Perhaps GIMP could make better use of the space. We don't need this sort 
of cheesy marketing trick (whether of not it rolls it's eye's on Pres. 
Obama's birthday or whatever).


Users do need more space.

IMHO ;)

/gg

___
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

[SorinN]

Cristi just pointed me to think that probably
users can have this option in preferences.
I mean to keep the Wilber or to hide Wilber for more vertical space in Toolbox

I will not remove Wilber  ;) I promise
but some users in need for vertical space will appreciate this option.

personal note :
for me Wilber represent a victory sign.
(...against the domination of proprietary, outdated but still
gamekeeper standards - wow - sound like a  class struggle declamation
;) )

on the serious side > before CS4, GIMP was superior in many aspects to
Photoshop
I remember when I presented GIMP to my DTP colleagues few years ago.
Today most of them still use GIMP for masking - then Photoshop or
Illustrator to assembly the print or for further manipulations.







2012/5/12 Cristian Secară 
>
> În data de Sat, 12 May 2012 12:02:31 +0400, Alexandre Prokoudine a
> scris:
>
> > 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.
>
> This is one of the first thing I remove after "modern" GIMP install. The
> reason for the lite Wilber logo comes from the past, something like
> version 2.4 or 2.2, when the toolbox had no toolbar, or a different
> toolbar type, or something (I can not remember exactly).
>
> (to remove, at least on Windows, simply just uncomment and chage to
> "no" the existing line
> # (toolbox-wilber yes)
> from the C:\Program Files\GIMP 2\etc\gimp\2.0\gimprc file)
>
> Cristi
>
> --
> Cristian Secară
> http://www.secarica.ro
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list




--
Nemes Ioan Sorin
___
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

[peter sikking]

SorinN wrote:

> "drop images" text message would me more efficient and explicit
> or probably an icon representing the drag and drop action...

now that would be really annoying, looking at that 40 hours a week,
every week of the year, no?

> Wilber itself has nothing to do with the fact of 
> "remembering the drag and drop" ..it's just a branding sign
> for me is ok - I like it there but : 
> - a new user will not be informed about the functionality we talk about
> - an old GIMP user ...know that already

we are talking about a shortcut here. first of all the normal,
highly findable (of not a bit boring) way is to use the File->Open
menu item. nifty shortcuts like this are documented in the
manual, and shared on the internet.

> for meis ok as is (I have no points against it) - but talking about usability 
> ...a clean message or a representative icon for that functionality would do a 
> better informal job.

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.

--ps

founder + principal interaction architect
man + machine interface works

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



___
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

[Cristian Secară]

În data de Sat, 12 May 2012 12:02:31 +0400, Alexandre Prokoudine a
scris:

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

This is one of the first thing I remove after "modern" GIMP install. The
reason for the lite Wilber logo comes from the past, something like
version 2.4 or 2.2, when the toolbox had no toolbar, or a different
toolbar type, or something (I can not remember exactly).

(to remove, at least on Windows, simply just uncomment and chage to
"no" the existing line
# (toolbox-wilber yes)
from the C:\Program Files\GIMP 2\etc\gimp\2.0\gimprc file)

Cristi

-- 
Cristian Secară
http://www.secarica.ro
___
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

[SorinN]

mr. Sikking;
"drop images" text message would me more efficient and explicit
or probably an icon representing the drag and drop action...

Wilber itself has nothing to do with the fact of
"remembering the drag and drop" ..it's just a branding sign
for me is ok - I like it there but :
- a new user will not be informed about the functionality we talk about
- an old GIMP user ...know that already

for meis ok as is (I have no points against it) - but talking about
usability ...a clean message or a representative icon for that
functionality would do a better informal job.

2012/5/12 peter sikking 

> guys,
>
> the answer is yes, yes, yes.
>
> yes, wilber in the toolbox is suppose to help remember that
> it is a drag + drop area for opening files (as new document).
> does it (and the n-i-w) have a tooltip for it?
>
> yes, it is also a bit of branding. wilber is watching you.
> (btw, if someone wants to implement that on date == friday the 13th
> wilber's eyes follow the mouse pointer all the time, like good old
> xeyes, then be my guest)
>
> yes, it eats space. one row of toolbox icons, all the time.
> I can see how users want that space back for something else.
> a setting in toolbox configuration to switch it off?
> fine with me.
>
>--ps
>
>founder + principal interaction architect
>man + machine interface works
>
>http://blog.mmiworks.net: on interaction architecture
>
>
>
> ___
> gimp-developer-list mailing list
> gimp-developer-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gimp-developer-list
>



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

[Gimp-developer] Save defaults not working?

[Guillermo Espertino (Gez)]

Hi:
I just noticed that the function for saving defaults for the jpeg export 
plugin isn't working in 2.8

Am I missing something or should I file a bug report?

btw, new jpeg defaults are much, much better than 2.6s but imo the 
progressive option shouldn't be on. It makes the file size a tad larger 
and it isn't always needed. Is there any special reason for using that 
option as default?


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

[peter sikking]

guys,

the answer is yes, yes, yes.

yes, wilber in the toolbox is suppose to help remember that
it is a drag + drop area for opening files (as new document).
does it (and the n-i-w) have a tooltip for it?

yes, it is also a bit of branding. wilber is watching you.
(btw, if someone wants to implement that on date == friday the 13th
wilber's eyes follow the mouse pointer all the time, like good old
xeyes, then be my guest)

yes, it eats space. one row of toolbox icons, all the time.
I can see how users want that space back for something else.
a setting in toolbox configuration to switch it off?
fine with me.

--ps

founder + principal interaction architect
man + machine interface works

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



___
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

[Alexandre Prokoudine]

On Sat, May 12, 2012 at 1:21 PM, gfxuser wrote:

> IMO the Wilber logo is currently not obsolete. Its purpose is to drag and
> drop files on it to open them in GIMP.

Oh?

1) I can't see how the logo is a hint that things can be dropped on
it. It looks more like a branding element. Maybe I'm missing some
important cultural experience?

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

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

Alexandre Prokoudine
http://libregraphicsworld.org
___
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

Re: [Gimp-developer] wilber in the toolbar

[Tobias Jakobs]

Hi Alexandre

On Sat, May 12, 2012 at 10:02 AM, Alexandre Prokoudine
 wrote:
>
> ... is there a reason we add a Wilber logo to the
> top of the toolbar?

AFAIK, the Wilber is a hint, that you can drag and drop files in this
window, to open this image. This makes the UI consistent with the "No
Image Window".

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

[Gimp-developer] wilber in the toolbar

[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

Re: [Gimp-developer] Gimp 2.8 blend time

[Michael Natterer]

On Sat, 2012-05-12 at 15:11 +1000, Owen wrote:
> > 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?  Is it a result of the
> > move to GEGL?  Will it be fixed?
> 
> 
> 
> I just tried this on 2.9 (SUSE) and it did it in less than a second.
> 
> However all the "Shaped" gradients took ages, like a minute or more
> compared to a few seconds in 2.6

Known problem with GimpOperatrionShapeburst, will be fixed.

--Mitch


___
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

[Michael Natterer]

On Sat, 2012-05-12 at 00:16 -0300, Guillermo Espertino (Gez) wrote:
> El 11/05/12 20:21, Michael Natterer escribió:
> > Please file it in bugzilla, it's pointless to use threading if it 
> > makes things slower, and we have no code to determine the #cpus on the 
> > mac anyway, so we should default to one.
> 
> My 2.9 install on linux (Debian, 64 bit) also detected the number of 
> cpus incorrectly. I'm using a Quad Core and it defaulted to 8 threads 
> and it also made some things slower.
> 2.8 worked fine though, it's set to 4 threads and I can't notice any 
> slowness because of that.

Ignore any threading in 2.9, it's all going away and transparently
handled by GEGL/OpenCL.

--Mitch


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