Re: [Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

[Partha Bagchi]

On Fri, May 18, 2012 at 8:35 PM, Michael Natterer  wrote:
> On Fri, 2012-05-18 at 19:20 -0400, Partha Bagchi wrote:
>> On Fri, May 18, 2012 at 7:05 PM, Michael Natterer  wrote:
>> > On Fri, 2012-05-18 at 18:24 -0400, Partha Bagchi wrote:
>> >> Hi All,
>> >>
>> >> For the Gaussian blur gegl tool, is it possible to link the X & Y size
>> >> settings so that they scroll together? More often than not, you are
>> >> likely to use the same value in both directions.
>> >
>> > This is planned, by using hints on the gegl properties, so the
>> > gimp UI can be constructed generically, we will not add a special
>> > case for blur.
>> >
>> > --Mitch
>> >
>> >
>>
>> Sounds good to me. Looking forward to it.
>
> I couldn't resist and hacked it up as proof-of-concept, without
> hinting from GEGL:
>
> commit c0351f070673fdb84320f9ac917cba78bf9088f6
> Author: Michael Natterer 
> Date:   Sat May 19 02:30:32 2012 +0200
>
>    app: connect x/y and width/height properties of GEGL ops with chain
> buttons
>
>    Add (too) simple heuristic that connects to subsequent numeric
> property
>    widgets with a chain button if their property names have the
> suffixes
>    "x" and "y", or "width" and "height".
>
>

Wait! You already committed it?? :)
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

[Michael Natterer]

On Fri, 2012-05-18 at 19:20 -0400, Partha Bagchi wrote:
> On Fri, May 18, 2012 at 7:05 PM, Michael Natterer  wrote:
> > On Fri, 2012-05-18 at 18:24 -0400, Partha Bagchi wrote:
> >> Hi All,
> >>
> >> For the Gaussian blur gegl tool, is it possible to link the X & Y size
> >> settings so that they scroll together? More often than not, you are
> >> likely to use the same value in both directions.
> >
> > This is planned, by using hints on the gegl properties, so the
> > gimp UI can be constructed generically, we will not add a special
> > case for blur.
> >
> > --Mitch
> >
> >
> 
> Sounds good to me. Looking forward to it.

I couldn't resist and hacked it up as proof-of-concept, without
hinting from GEGL:

commit c0351f070673fdb84320f9ac917cba78bf9088f6
Author: Michael Natterer 
Date:   Sat May 19 02:30:32 2012 +0200

app: connect x/y and width/height properties of GEGL ops with chain
buttons

Add (too) simple heuristic that connects to subsequent numeric
property
widgets with a chain button if their property names have the
suffixes
"x" and "y", or "width" and "height".


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

[Gimp-developer] contribution processes...

[Saul Goode]

I apologize for the double-post; my mail system barfed and apparently sent a 
draft version of my post. Here is a more refined version.

In my opinion the language of the draft is not very inviting to contribution. 
At minimum, each of the "has to"s should be changed to either "should"s or 
"should strive to"s. Also, it is unclear whether the final "does not have to be 
perfect" trumps any or all of the previous seven bullet points -- if it does 
not then the requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be 
expected to learn or have access to other platforms just so he can submit code; 
he should write his code to work on his development system and those with 
access to and familiarity with alternative deployments should be able to submit 
patches or propose changes to accommodate their systems. This suggests that the 
infrastructure to support contributor participation should be hierarchical in 
nature; i.e., each enhancement/bugfix should be treated as an openly developed 
"subproject" in which all are welcome to participate. 

I would propose a "centralized, distributed" approach akin to the following:

A separate 'gimp-contrib' repository be created in which development of larger 
enhancements and more involved bugfixes takes place. Smaller bugfixes and 
enhancements could still employ the process of submitting patches through 
Bugzilla. 

* A potential contributor submits a Bugzilla report outlining his issue and 
indicating that he/she is willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is 
granted branching and commit privileges to the 'gimp-contrib' repository (if 
not already granted previously). This does NOT offer push privileges to the 
Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, 
through whatever channels he/she wishes. More significant aspects of the 
development should be inclusive of the official GIMP channels (mailing list, 
IRC, and the corresponding Bugzilla report), but smaller issues can be handled 
without much interference with the main project.

* Contributors are responsible for keeping their branch in synch with the GNOME 
'gimp' module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and 
following the feedback provided by the GIMP developers and the input of GIMP UI 
design team. 

* Notably, contributors neither produce or submit patches; they focus on 
producing their code, incorporating suggestions, and persuading people to test 
it.

* When the contributor feels his project is in suitable shape for inclusion in 
GIMP, he/she requests that the GIMP developers merge his branch.


The process outlined above provides a solution that allows for distributed 
development that avails itself of the capabilities of GIT and scales to both 
the smallest and largest of 'subprojects'. 

Contributors' abilities to get their code incorporated would ultimately depend 
upon their ability to attract the support of the GIMP developers but, 
importantly, they are initially welcomed to participate in the project and can 
learn incrementally the process of contributing to a large, community-run 
codebase. 

The demand placed on GIMP developers to support this infrastructure should be 
expected to be less than the current method of contributors creating their own 
local branches and then submitting patches upon every changeset. 

Contributors are permitted to fail without interfering with mainline 
development (the amount of imposition allowed fully determined by the 
individual members of the GIMP team) while maintaining a historical record that 
will hopefully be more complete and easily examined than the current approach. 
The bar to being granted access to this 'gimp-contrib' repository can be rather 
low, and even "speculative" enhancements or bugfix approaches can be afforded 
their chance to flourish. 

Hopefully, there would eventually evolve greater participation in GIMP 
development amongst these contributors that would engender sharing of 
experiences and practices which, even if the end result is never fully 
incorporated, will prove educational and beneficial to the contributors, to the 
GIMP project, and to Free Software in general.







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

Re: [Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

[Partha Bagchi]

On Fri, May 18, 2012 at 7:05 PM, Michael Natterer  wrote:
> On Fri, 2012-05-18 at 18:24 -0400, Partha Bagchi wrote:
>> Hi All,
>>
>> For the Gaussian blur gegl tool, is it possible to link the X & Y size
>> settings so that they scroll together? More often than not, you are
>> likely to use the same value in both directions.
>
> This is planned, by using hints on the gegl properties, so the
> gimp UI can be constructed generically, we will not add a special
> case for blur.
>
> --Mitch
>
>

Sounds good to me. Looking forward to it.

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

[Gimp-developer] contribution processes...

[Crazy Aunt Gail's, LLC]

In my opinion the language of the draft is not inviting to contribution. At 
minimum, each of the "has to"s should be changed to either "should"s or "should 
strive to"s. Also, it is unclear whether the final "does not have to be 
perfect" trumps any or all of the previous seven bullet points -- if it does 
not then the requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be 
expected to learn or have access to other platforms just so he can submit code; 
he should write his code to work on his development system and those with 
access to and familiarity with alternative deployments should be able to submit 
patches or propose changes to accommodate their systems. This suggests that the 
infrastructure to support contributor participation should be hierarchical in 
nature; i.e., each enhancement/bugfix should be treated as an openly developed 
"subproject" in which all are welcome to participate. 

I would propose something akin to the following:

A separate 'gimp-contrib' repository be created in which development of patches 
takes place. 

* A potential contributor submits a Bugzilla report outlining his issue and 
indicating that he/she is willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is 
granted branching and commit privileges to the 'gimp-contrib' repository (if 
not already granted previously). This does NOT offer push privileges to the 
Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, 
through whatever channels he/she wishes. More significant aspects of the 
development should be inclusive of the official GIMP channels (mailing list, 
IRC, and the corresponding Bugzilla report), but smaller issues can be handled 
without interfering with the main project.

* They are responsible for keeping their branch in synch with the GNOME 'gimp' 
module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and following 
the feedback provided by the GIMP developers and the input of GIMP UI design 
team. 

* Notably, contributors neither produce or submit patches; they focus on 
producing their code, incorporating suggestions, and persuading people to test 
it.

* When the contributor feels his project is in suitable shape for inclusion in 
GIMP, he/she requests that the GIMP developers merge his branch.


The process outlined above provides a solution that allows for distributed 
development that avails itself of the capabilities of GIT and scales to both 
the smallest and largest of 'subprojects'. 

Contributors' abilities to get their code incorporated would ultimately depend 
upon their ability to attract the support of the GIMP developers but, 
importantly, they are initially welcomed to participate in the project and can 
learn incrementally the process of contributing to a large, community-run 
codebase. 

The demand placed on GIMP developers to support this infrastructure should be 
less than the current method. Contributors are permitted to fail without 
interfering with mainline developme








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

Re: [Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

[Michael Natterer]

On Fri, 2012-05-18 at 18:24 -0400, Partha Bagchi wrote:
> Hi All,
> 
> For the Gaussian blur gegl tool, is it possible to link the X & Y size
> settings so that they scroll together? More often than not, you are
> likely to use the same value in both directions.

This is planned, by using hints on the gegl properties, so the
gimp UI can be constructed generically, we will not add a special
case for blur.

--Mitch


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

[Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

[Partha Bagchi]

Hi All,

For the Gaussian blur gegl tool, is it possible to link the X & Y size
settings so that they scroll together? More often than not, you are
likely to use the same value in both directions.

Thanks,
Partha
___
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

[Ville Pätsi]

On 2012-05-18 23:45, Cristian Secară wrote:
> The Windows Inkscape version uses Windows native file open and save
> dialog, so some solution appears to exists already.

It does use it, but that doesn't mean it works. Save as and export
bitmap default to empty file names, not the current filename or a
variation of it. Also files that have different extensions aren't
visible in the view, so you always have to start typing in the filename
when you open the export dialog for the first time for a new document as
you can't click on the svg file and just change the extension.

These bugs didn't exist when Inkscape used the GTK+ file dialog, and
have existed since migrating to the native dialog several years ago. My
point is that the way Inkscape uses the Windows native file dialog
should not be used as any kind of direction, guide or proof of concept
for what could or should be done with GIMP.

___
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

[Cristian Secară]

În data de Fri, 18 May 2012 12:25:34 +0400, Alexandre Prokoudine a
scris:

> are mutually exclusive on Windows.
> 
> And with the latter request you are telling us to patch the upstream
> GTK+ dialog.

The Windows Inkscape version uses Windows native file open and save
dialog, so some solution appears to exists already.

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] Gimp 2.8.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]

[gg]

On 05/18/12 19:47, Richard Gitschlag wrote:


When I filed bug #675385 about the export/overwrite distinction the
overall response was "notabug", but Michael Natterer did also comment that:

 > Michael Natterer

[GIMP developer] 2012-05-05 17:05:25 UTC
 > There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu
 > entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need
to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP
job, this means that your Ctrl+E will either work only once per image
session (if assigned to "file-overwrite") or not at all (if assigned to
"file-export").  In order to get both sides you'd need a third shortcut,
say, Ctrl+Alt+E, assigned to the third command.

But why should a third shortcut even be necessary in the first place?
This whole distinction between "overwrite" and "export" was
fundamentally flawed from the start; there is no reason GIMP should need
three functions to perform what are essentially only two commands:

- "Export..." - Analogous to the "Save As" command, but for non-XCF
formats.  Intended for first-time exports and other situations where you
want to export an image to a different filename.  You are prompted for a
filename and format options before it actually writes to file.
- "Overwrite" - Analogous to the "Save" command, but for non-XCF
formats.  Intended for exporting back to the original (non-XCF) file;
whether or not there was a previous export within the current session is
simply irrelevant.  If the file was neither imported nor exported, then
it will trade off to the "Export..." command (also analogous to the Save
/ Save As distinction).

Remember, at any time GIMP only displays two export options in its
menu:  The first may be called "Export to [filename]" or "Overwrite
[filename]" but regardless of whichever one is currently shown, it
performs ultimately the same function:  Exporting back to the same
non-XCF file with no questions asked.  Why does there even need to be
two different internal functions (file-export and file-overwrite) to
handle this ONE behavior?



That about sums it up for me.

/gg

___
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.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]

[Mikael Magnusson]

On 18/05/2012, Richard Gitschlag  wrote:
>
> Going to split this because it really NEEDS some wider discussion.  There's
> no nice way of phrasing it - in the current GIMP this distinction is a total
> snafu.
>
>> To: gimp-developer-list@gnome.org
>> From: grosberg.mich...@gmail.com
>> Date: Fri, 18 May 2012 06:45:22 +
>> Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm
>>
>> Here's the problem - overwrite only works once. Then it becomes export.
>> And you can't assign the same keyboard shortcut to both.

>> Michael Natterer 2012-05-05 17:05:25 UTC
>> There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu
>> entry is hidden. I fixed that in git, it will be in 2.8.1.
>
> Unfortunately this will only exacerbate the problem -- when all you need to
> do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job,
> this means that your Ctrl+E will either work only once per image session (if
> assigned to "file-overwrite") or not at all (if assigned to "file-export").
> In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E,
> assigned to the third command.

I didn't read the huge paragraph I snipped, but I think you completely
misunderstood the reply to the bug. The bug is that ctrl-e doesn't
work in 2.8.0 when you import a file until you do 'export'. This is
fixed in 2.8.1, you can now always press ctrl-e to export a file. If
it is imported, it will prompt for a new name, if you already picked
an export name it will silently export to the same name again.

-- 
Mikael Magnusson
___
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.0 - Saving in .jpg or .png hmmmmm

[Stefan Peter]

On 18.05.2012 15:53, Anke Lange wrote:
> Hello list
> 
> I can't really understand what all this fuss is about.
> All grafical programms I know of work this way. 

+1


Regards

Stefan Peter

-- 
"In summary, I think you are trying to solve a problem that may not
need to be solved, using a tool that is not meant to solve it, without
understanding what is causing your problems and without knowing how
the tool actually works in the first place :)"
Jeffrey J. Kosowsky on the backuppc mailing list
___
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.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]

[Richard Gitschlag]

Going to split this because it really NEEDS some wider discussion.  There's no 
nice way of phrasing it - in the current GIMP this distinction is a total snafu.

> To: gimp-developer-list@gnome.org
> From: grosberg.mich...@gmail.com
> Date: Fri, 18 May 2012 06:45:22 +
> Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm
> 
> Here's the problem - overwrite only works once. Then it becomes export.
> And you can't assign the same keyboard shortcut to both.
> You'll have to assign two shortcuts, and remember to use one shortcut the
> first time, and the other shortcut the second, third etc.
> That is indeed a strange behavior - a command that only works once per file.
> 
> Say what you will about save vs. export but this has to be fixed.
> 

When I filed bug #675385 about the export/overwrite distinction the overall 
response was "notabug", but Michael Natterer did also comment that:

> Michael Natterer


  [GIMP developer]







  2012-05-05 17:05:25 UTC
> There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu
> entry is hidden. I fixed that in git, it will be in 2.8.1.

Unfortunately this will only exacerbate the problem -- when all you need to do 
is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this 
means that your Ctrl+E will either work only once per image session (if 
assigned to "file-overwrite") or not at all (if assigned to "file-export").  In 
order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned 
to the third command.

But why should a third shortcut even be necessary in the first place?  This 
whole distinction between "overwrite" and "export" was fundamentally flawed 
from the start; there is no reason GIMP should need three functions to perform 
what are essentially only two commands:

- "Export..." - Analogous to the "Save As" command, but for non-XCF formats.  
Intended for first-time exports and other situations where you want to export 
an image to a different filename.  You are prompted for a filename and format 
options before it actually writes to file.
- "Overwrite" - Analogous to the "Save" command, but for non-XCF formats.  
Intended for exporting back to the original (non-XCF) file; whether or not 
there was a previous export within the current session is simply irrelevant.  
If the file was neither imported nor exported, then it will trade off to the 
"Export..." command (also analogous to the Save / Save As distinction).

Remember, at any time GIMP only displays two export options in its menu:  The 
first may be called "Export to [filename]" or "Overwrite [filename]" but 
regardless of whichever one is currently shown, it performs ultimately the same 
function:  Exporting back to the same non-XCF file with no questions asked.  
Why does there even need to be two different internal functions (file-export 
and file-overwrite) to handle this ONE behavior?


-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.
  ___
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.0 - Saving in .jpg or .png hmmmmm

[yahvuu]

Am 18.05.2012 16:49, schrieb Nicolas Robidoux:
> Yet another completely different (and rather radical) idea: If the
> user saves as JPEG (say), GIMP automatically and silently saves the
> XCF alongside it or in a special folder. 

this idea was considered and rejected two years ago.
However, for a fully geglized GIMP, it seams feasible to write
a journal of all user activities -- for crash recovery and
re-edit capability across sessions.

To give an upper bound of required journal bandwidth, let's say the 
pointing device input comes in as 2*16bit coordinates at 50Hz rate.
That's 200B/s or roughly 7MB for a 10-hour workday of non-stop drawing.

I guess with compression and real-world data, it's much less, by factor 10-1000.


best regards,
yahvuu

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



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] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

Terminology ideas:

.xcf: composition (composition suggests "result of compositing as well
as its process", which is a fitting description, I think) or project

"Everything" (tools, frames, input and output images...): session,
workspace or project.

.jpg or .png or .tif or ...: image
___
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

[Richard Gitschlag]

>From my perspective, what kind of filepicker dialog an application uses goes a 
>long way in making it look like a native app for its target platform.  
>Allowing the Windows version of GIMP to incorporate the native Win32 
>filepicker dialog would be a huge improvement at least in platform-specific 
>aesthetics and user convenience -- if nothing else -- but functionally 
>speaking it would also give GIMP the ability to follow Win32 style shortcuts 
>(.lnk files), because that's part of the filepicker functionality.  And GIMP 
>would still be able to customize the dialog box with a GIMP-specific thumbnail 
>panel (which, as noted, more frequently skips generating a thumbnail than not) 
>-- that is what you see in current versions of Inkscape's Win32 platform, 
>Inkscape being another GTK+ app.

-- Stratadrake
strata_ran...@hotmail.com

Numbers may not lie, but neither do they tell the whole truth.


Date: Fri, 18 May 2012 09:35:32 -0400
From: ccurt...@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog 
thumbnails

On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič  wrote:

Err, why? I find the Windows dialog boxes infinitely more usable than
GTK+'s (especially after the latest "improvement" with the Recent

list).

The GTK+ file chooser does seem to be horrible, and I'm not sure why.  Here's a 
usage scenario that continually drives me crazy in GIMP:
1) Create a new image
2) Select File->Save-> The "Save File" dialog opens3) Navigate to the correct 
directory4) Type the filename to save
Expected result: The highlighted part of "Untitled" in "Name: Untitled.xcf" is 
replaced with what you type.

Actual result: The dialog assumes you want to destroy a file already in the 
directory and starts selecting from them until you type something that can't be 
completed using the files in the directory.  Then, another little window 
appears showing you what you're typing.  When you finish typing the name you 
want to save as and hit Enter, the dialog prompts you to overwrite the file 
that last matched what you were typing.

I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't 
setting some kind of "save mode" flag.
Chris


___
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] Targeted audience of GIMP?

[Srihari Sriraman]

Makes sense; speed is necessary.

On Fri, May 18, 2012 at 8:18 PM, peter sikking  wrote:

> Alexandre wrote:
>
> > On Fri, May 18, 2012 at 6:31 PM, Srihari Sriraman wrote:
> >
> >> Is speed really inferred from the vision?
> >>>
> >>> tools get out of the way of getting things done and allow for
> accelerating
> >>> the workflow
> >>
> >> This talks of a non obstructive interface, which appeals to me, but how
> is
> >> speed a necessity?
> >
> > This is called a turn-round. It's how fast you can finish a job for
> > one client to switch to the next one.
>
>
> yes, production. deliver 300 files, before lunch.
>
>--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
>



-- 
*
*
*Regards,
  *
*Srihari Sriraman
  *
___
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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

Yet another completely different (and rather radical) idea: If the
user saves as JPEG (say), GIMP automatically and silently saves the
XCF alongside it or in a special folder. Then Open/Save does
everything you want, and when the beginner user reopens the JPEG, he
can be asked if he/she wants to actually get back the XCF.
___
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?

[peter sikking]

Alexandre wrote:

> On Fri, May 18, 2012 at 6:31 PM, Srihari Sriraman wrote:
> 
>> Is speed really inferred from the vision?
>>> 
>>> tools get out of the way of getting things done and allow for accelerating
>>> the workflow
>> 
>> This talks of a non obstructive interface, which appeals to me, but how is
>> speed a necessity?
> 
> This is called a turn-round. It's how fast you can finish a job for
> one client to switch to the next one.


yes, production. deliver 300 files, before lunch.

--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] Targeted audience of GIMP?

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 6:31 PM, Srihari Sriraman wrote:

> Is speed really inferred from the vision?
>>
>> tools get out of the way of getting things done and allow for accelerating
>> the workflow
>
> This talks of a non obstructive interface, which appeals to me, but how is
> speed a necessity?

This is called a turn-round. It's how fast you can finish a job for
one client to switch to the next one.

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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

> How does it align to the workflows of professionals?
They still do exactly the same thing. They just use exchanged
buttons/keyboard shortcuts.

I'm suggesting "command remapping" so that open/save does what most
beginners expect, and import/export does what professionals want
(instead of the other way around).
___
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.0 - Saving in .jpg or .png hmmmmm

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 6:25 PM, Nicolas Robidoux wrote:

> Here is a trivial change that would immediately take care of the
> confusion that lead to the top post of this thread:
>
> Exchange the ACTIONS of open <-> import and save <-> export.
>
> That is:
>
> import/export is for XCF.
>
> save/open is for JPEG, PNG, GIF, TIFF, ...

How does it align to the workflows of professionals?

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] Targeted audience of GIMP?

[Srihari Sriraman]

> 


Beautiful. Clear.

Is *speed* really inferred from the vision?

> tools get out of the way of getting things done and allow for accelerating
> the workflow

This talks of a *non obstructive interface*, which appeals to me, but how
is speed a necessity?

On Fri, May 18, 2012 at 7:07 PM, 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:
>
> 
>
>--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
>



-- 
*
*
*Regards,
  *
*Srihari Sriraman
  *
___
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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

On Fri, May 18, 2012 at 4:24 AM, gg  wrote:
...
> In any other context opening a file and then saving it, the user will
> *expect to be saving the file* .  Why try to redefine what the world already
> does.
...

Here is a trivial change that would immediately take care of the
confusion that lead to the top post of this thread:

Exchange the ACTIONS of open <-> import and save <-> export.

That is:

import/export is for XCF.

save/open is for JPEG, PNG, GIF, TIFF, ...

If you think about it for a minute, this is not as ad hoc as it first
seems, and I suspect that it would preemptively kill a lot of
complaints.

Sure, some users will shoot themselves in the foot and open/save and
ask "how can I undo"? My guess is that generally they make this
mistake once.
___
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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

Metaphor: A tree (.xcf) will grow away from the forest
(project/workspace), but a leaf (.jpg or .png) cut away from the tree
won't.

(And yes, I am perfectly aware that in a graph theory sense what I'm
proposing to call a "leaf" is actually a "root". The point here is to
communicate the key information to non-technical users in a form that
they will understand and remember.)
___
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.0 - Saving in .jpg or .png hmmmmm

[Anke Lange]

Hello list

I can't really understand what all this fuss is about.
All grafical programms I know of work this way. You only save in the 
programs own format and export to a diffent like png, jpg or pdf...
It is only a kind of "getting used to it" in GIMP, when you have been 
working with it for some time.


I hate little windows popping up asking me if I'm really, really sure to 
proceed with the decision I made, so they don't really alert me anymore. 
I guess a lot of user feel that way, espacially on windows-systems where 
you get even more alert-windows.
I think it's a really good solution to stick with the normal way to 
handle saving-procedures.


just my 2c

Anke


Am 18.05.2012 15:32, schrieb Alexandre Prokoudine:

On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote:


If an image is saved to a lossy format, it could be decided that the first time
you attempt to do this, an alert will explain to you that repeated saving to JPG
corrupts the image. A checkbox in the dialog will enable you to prevent it
from showing again.

I have a gut feeling that in terms of usability it is considered to be
a mortal sin :)

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



--
Anke Lange
An der Landwehr 25
49076 Osnabrück
Telefon 0541 6004299
gimp-werkst...@gmx.de

www.kreativ-workshops.net
www.gimp-werkstatt.de
www.kompozer-web.de

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

[peter sikking]

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:



--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] Feature request: Improve the Open file dialog thumbnails

[Christopher Curtis]

On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič  wrote:

Err, why? I find the Windows dialog boxes infinitely more usable than
> GTK+'s (especially after the latest "improvement" with the Recent
> list).
>

The GTK+ file chooser does seem to be horrible, and I'm not sure why.
 Here's a usage scenario that continually drives me crazy in GIMP:

1) Create a new image
2) Select File->Save
-> The "Save File" dialog opens
3) Navigate to the correct directory
4) Type the filename to save

Expected result: The highlighted part of "Untitled" in "Name: Untitled.xcf"
is replaced with what you type.

Actual result: The dialog assumes you want to destroy a file already in the
directory and starts selecting from them until you type something that
can't be completed using the files in the directory.  Then, another little
window appears showing you what you're typing.  When you finish typing the
name you want to save as and hit Enter, the dialog prompts you to overwrite
the file that last matched what you were typing.

I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP
isn't setting some kind of "save mode" flag.

Chris
___
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.0 - Saving in .jpg or .png hmmmmm

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote:

> If an image is saved to a lossy format, it could be decided that the first 
> time
> you attempt to do this, an alert will explain to you that repeated saving to 
> JPG
> corrupts the image. A checkbox in the dialog will enable you to prevent it
> from showing again.

I have a gut feeling that in terms of usability it is considered to be
a mortal sin :)

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.0 - Saving in .jpg or .png hmmmmm

[Michael Grosberg]

Alexia Death  gmail.com> writes:

> 
> Hi!
> 
> My 2c on the issue -  This change is GOOD not only for the target
> audience but to the novice too! 

Those are good reasons to do something, but I believe the problem is with the
selected solution and not with the idea of attempting to solve the problem. 
Photoshop Has a similar "protect user from destructive saving" system, 
annoying in its own way, which only lets you save to the original as long 
as no new layers have been added. Once you add layers, choosing "Save" opens 
a dialog letting you asve as PSD and you have to manually select JPG/PNG in
order to save. There is also a warning inside the dialog that data will be lost.

I can see that certain usage patterns will be easier using the new system but
perhaps allowances could be made in some cases. For example, if the image is 
kept
as a single layer, it should allow saving to all full-color, non-lossy formats.
If an image is saved to a lossy format, it could be decided that the first time
you attempt to do this, an alert will explain to you that repeated saving to JPG
corrupts the image. A checkbox in the dialog will enable you to prevent it
from showing again.

___
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

[Jernej Simončič]

On Friday, May 18, 2012, 10:53:46, Michael Schumacher wrote:

>> 3. Use the native "Open file" dialog.
> and no, just no.

Err, why? I find the Windows dialog boxes infinitely more usable than
GTK+'s (especially after the latest "improvement" with the Recent
list).

> Before ever doing that, GIMP should switch to an "if you need better
> file handling, then use your platform's file manager and open images 
> from there" approach and ditch the file open dialog completely.
> I wouldn't be surprised if this was a GNOME user interaction goal, either.

This certainly sounds plausible, given that I found almost every
change to the dialog boxes made them slower and more awkward to use.

> I'm using Windows, and I open most file in any program either through
> their MRU list or via a Windows Explorer window, because all of the file
> open dialogs are awkward.

I don't - I find the file open dialog much better suited for this
(though the bad tab order is slightly annoying in Vista and 7). I
almost never use drag-and-drop.

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

The easier it is to do, the harder it is to change.
   -- Eng's Principles

___
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.0 - Saving in .jpg or .png hmmmmm

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 4:18 PM, Nicolas Robidoux wrote:
> Once GEGL becomes the operative system, XCF can be understood as the
> "tree" that leads to a specific image.
>
> "Save tree"?

"Save the trees
Save the bees
Save the wales
Save those snails"

(c) http://www.youtube.com/watch?v=eScDfYzMEEw

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] Targeted audience of GIMP?

[Ragnar Brynjúlfsson]

There are a couple of user scenarios that are not on the list, that I
hope can be included. These are:

- Creating original art from scratch (basically drawing and
painting...this is mainly what I use GIMP for). Actually, it works
pretty nicely for this as is...but it would be nice to see it included
anyway. :)
- Creating textures for 3D (for games or film). This is in many ways a
lot like creating original art from found images with a few
differences. Such as creating tileable textures, exporting different
passes (color, bump, spec maps etc.), and warping images to match
UV's. Taken to the extreme it would include painting directly on 3D
models, but I think that would be outside the scope of what GIMP is.

Cheers,

  Ragnar


On Fri, May 18, 2012 at 9:43 AM, Alexandre Prokoudine
 wrote:
> On Fri, May 18, 2012 at 8:13 AM, gfxuser  wrote:
>> 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?
>
> 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?
>
> 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.
>
>> 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.
>
> 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] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

Whimsically, save workspace/XCF/image could be save forest/tree/leaf.
___
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.0 - Saving in .jpg or .png hmmmmm

[Ofnuts]

On 05/18/2012 02:18 PM, Nicolas Robidoux wrote:

Once GEGL becomes the operative system, XCF can be understood as the
"tree" that leads to a specific image.

"Save tree"?



"project" would have my vote.
___
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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

Once GEGL becomes the operative system, XCF can be understood as the
"tree" that leads to a specific image.

"Save tree"?
___
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.0 - Saving in .jpg or .png hmmmmm

[Nicolas Robidoux]

This is how things work in NIP2. (I am not holding NIP2 as a paragon
of beginner friendliness by no means. Just brainstorming, and adapting
things a bit to what I understand of GIMP.)

Open/Save have to to with loading/saving from/into the file system
(the "hard disk").

Two kinds of objects can be opened/saved: workspaces (which include
"everything", windows and all) and individual images. (In GIMP, there
may need to be a third type: XCF.)

If the focus is within the "frame" of an individual image, NIP2
understand that "Save" has to do with the image itself, and will ask
whether you want png, jpg, ... with a reasonable default.

"Elsewhere", it would make a lot of sense that "Save" default to
saving the workspace. (I've not checked because I normally use the
menu instead of keyboard shortcuts.)

-

Import/Export have to do with conversion using an ICC profile. By
default, NIP2 does not do this automatically, and makes reasonable but
minimal assumptions. But it does not involve the hard drive (unless
the profile needs to be taken from there).

Colourspace conversion is separate from both Open/Save and Import/Export.

-

Again, this is just to give an example of a system which I find
logical, and which IMHO accommodates fairly naturally both "naive
users" and "power users".

However, it does not address the fact that in GIMP there is a exposed
construct that sits between "resulting JPEG" and "the whole workspace
with windows, image loaded, some tools at the foregroung...": The XCF
file.
___
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.0 - Saving in .jpg or .png hmmmmm

[Thorsten Wilms]

On 05/18/2012 10:24 AM, gg wrote:

Calling it save workspace makes it instantly clear that it will not
writing back to the source image and that any layers etc and work in
progress will be safe.


I would expect "Save Workspace" to save the arrangement of windows and 
panels. Maybe also the selection of opened files, but not any of the 
files themselves.


Thinking about how the term "workspace" is used elsewhere, I'm confident 
a significant percentage of users would have similar expectations.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/
___
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

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 2:19 PM, Kurt Pruenner wrote:

> But for XCF files that's not very useful as GIMP doesn't come with an
> XCF IThumbnailProvider, so all XCF files would only show the Wilber file
> icon at it's highest resolution instead of a preview... :(

And that's another task for an interested developer.

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

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.0 - Saving in .jpg or .png hmmmmm

[peter sikking]

Michael Grosberg wrote:

> Here's the problem - overwrite only works once. Then it becomes export.

that is a bug.

Overwrite stays Overwrite for as long as users work ‘backwards’
to the imported file.

only when users start working forward (via Export... defining a
new export target + type) does it all change to Export to foo.xyz.

(I checked my spec to see if there was confusion about it:
no there is not)

--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] Feature request: Improve the Open file dialog thumbnails

[Kurt Pruenner]

On 18.05.12 10:59, gfxuser wrote:
> 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.

But for XCF files that's not very useful as GIMP doesn't come with an
XCF IThumbnailProvider, so all XCF files would only show the Wilber file
icon at it's highest resolution instead of a preview... :(

-- 
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria

np: Frittenbude - Heimatlos (Delfinarium)
___
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

[Jon Nordby]

On 18 May 2012 11:18, Alexandre Prokoudine
 wrote:
> On Fri, May 18, 2012 at 12:59 PM, gfxuser  wrote:
>
>> I wouldn't say that. On Windows 7 the native 'open file' dialog contains
>> different views: list, details, symbols in various sizes, tiles.
>
> This is exactly what I was referring to.
>
> There's no need to sit down and create a patch for GTK+ which GTK+
> team probably doesn't even want, when you could use native dialogs.
> Personally I've no special opinion on native vs. GTK+ dialogs on
> Windows. As a non-Windows user I'm fine with both :)

Please fix GTK+ instead of using some platforms native dialog in GIMP.
That way it will work for all GTK+ based applications and on all
operating systems supported by GTK+. Remember also that GtkFileChooser
is the native dialog for GNOME (and XFCE).

Some work was done recently, but never ended up in mainline.
https://bugzilla.gnome.org/show_bug.cgi?id=141154

-- 
Jon Nordby - www.jonnor.com
___
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

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 12:59 PM, gfxuser  wrote:

> I wouldn't say that. On Windows 7 the native 'open file' dialog contains
> different views: list, details, symbols in various sizes, tiles.

This is exactly what I was referring to.

There's no need to sit down and create a patch for GTK+ which GTK+
team probably doesn't even want, when you could use native dialogs.
Personally I've no special opinion on native vs. GTK+ dialogs on
Windows. As a non-Windows user I'm fine with both :)

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.0 - Saving in .jpg or .png hmmmmm

[gg]

On 18/05/12 02:23, Nicolas Robidoux wrote:

A long time ago, I suggested "save workspace" (to XCF) VS "save image"
(into a "standard" image format, like png, ideally chosen with some
awareness of past actions or the format of the main ingredients of the
current image).


Hi Nicolas,

Now that is the best idea I've seen on this subject. xcf is not an image 
format since just about nothing else can read it. It is Gimp's internal 
format. Describing it as saving the gimp workspace is a lot closer to 
describing its real function and would instantly make sense.


In any other context opening a file and then saving it, the user will 
*expect to be saving the file* .  Why try to redefine what the world 
already does.


Calling it save workspace makes it instantly clear that it will not 
writing back to the source image and that any layers etc and work in 
progress will be safe.


Thus the user would realise what xcf is about and would not be confused 
by the interface insisting he saves as xcf  when he wants to save his png.


Despite the rest of the save/export argument this seems like damn good 
idea all round.


In fact if this had been thought of years ago, messing with File | Save 
 would probably not have been needed to force people to use xcf.


Chapeau, Nicolas.
___
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

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

[Michael Schumacher]

On 18.05.2012 09:33, Ryan Johnson wrote:

I've been using GIMP to play around with some lighting, color, and GEGL
operations on images.
What I've noticed is that the "Open file" dialog is very poorly
constructed and it has become a problem. I'm using Win7 x64.
Nicely put, it's unintuitive.

These are suggested fixes, and you can choose more than one if it permits.

1. Raise the file size limit for autogeneration of thumbnails.


This is in GIMP's preferences, so a different default would be easy to do,


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


this is already possible,


3. Use the native "Open file" dialog.


and no, just no.

Before ever doing that, GIMP should switch to an "if you need better 
file handling, then use your platform's file manager and open images 
from there" approach and ditch the file open dialog completely.

I wouldn't be surprised if this was a GNOME user interaction goal, either.

I'm using Windows, and I open most file in any program either through 
their MRU list or via a Windows Explorer window, because all of the file 
open dialogs are awkward.



Regards,
Michael
___
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

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 11:33 AM, Ryan Johnson 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.

And with the latter request you are telling us to patch the upstream
GTK+ dialog.

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] Feature request: Improve the Open file dialog thumbnails

[Ryan Johnson]

I've been using GIMP to play around with some lighting, color, and GEGL
operations on images.
What I've noticed is that the "Open file" dialog is very poorly constructed
and it has become a problem. I'm using Win7 x64.
Nicely put, it's unintuitive.

These are suggested fixes, and you can choose more than one if it permits.

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.

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

3. Use the native "Open file" dialog.

Additional comments: I have seen no other modern program, even open source,
that has such an unusable thumbnail generator. If I recall correctly, there
is a free implementation in Evince Document reader for a regular
thumbnailer (thumbnail grid) and Open file dialog.

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!

-- 
I'm an FSF member. The Free Software Foundation fights to keep your
computer in your control, and only your control. Help protect you and your
friends from customer abuse in the technology industry!
http://www.fsf.org/jf?referrer=9448
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Cage-Tool performance

[Anke Lange]

Thanks Alexia
that does help :)
by the way, the examples I made were made on transparent background, I 
only added a white layer to make it easier to see the cage.


Anke

Am 18.05.2012 10:01, schrieb Alexia Death:

On Fri, May 18, 2012 at 9:52 AM, Anke Lange  wrote:

First: when I made a cage and want to adjust the knots, I can't. I have to
create a new cage. But when I create the cage new and close it, it cuts my
picture into bits. The only way to avoid this, yet, is to restart Gimp and
load the motiv new.
Is there another way around this?

Yes you can. Close the cage, then in tool options switch to "Create or
edit mode". Then you can adjust the cage untill you switch back to
transform mode.


Second: I tried out, whether I get a difference in making a cage closer to
the motif or leaving a wider gap between motif and cage. Using the
adjustment of filling the background with color.

Cage transform is only defined for the interior of the cage. It's a
limitation of the algorithm. The fill works based on the pixel under
your first point. It's ideal operating environment is an element on a
separate layer of a larger canvas with transparent bg. Cage is
somewhat special transform. It strives to be shape preserving.



--
Anke Lange
An der Landwehr 25
49076 Osnabrück
Telefon 0541 6004299
gimp-werkst...@gmx.de

www.kreativ-workshops.net
www.gimp-werkstatt.de
www.kompozer-web.de

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

Re: [Gimp-developer] Cage-Tool performance

[Alexia Death]

On Fri, May 18, 2012 at 9:52 AM, Anke Lange  wrote:
>> First: when I made a cage and want to adjust the knots, I can't. I have to
>> create a new cage. But when I create the cage new and close it, it cuts my
>> picture into bits. The only way to avoid this, yet, is to restart Gimp and
>> load the motiv new.
>> Is there another way around this?
Yes you can. Close the cage, then in tool options switch to "Create or
edit mode". Then you can adjust the cage untill you switch back to
transform mode.

>> Second: I tried out, whether I get a difference in making a cage closer to
>> the motif or leaving a wider gap between motif and cage. Using the
>> adjustment of filling the background with color.
Cage transform is only defined for the interior of the cage. It's a
limitation of the algorithm. The fill works based on the pixel under
your first point. It's ideal operating environment is an element on a
separate layer of a larger canvas with transparent bg. Cage is
somewhat special transform. It strives to be shape preserving.

-- 
--Alexia
___
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.0 - Saving in .jpg or .png hmmmmm

[Alexia Death]

Hi!

My 2c on the issue -  This change is GOOD not only for the target
audience but to the novice too! You would not belive how may times
people new to graphics have come to varoius gimp channels asking how i
can change text on this here image I saved from gimp yesterday as jpg
or png and I have to tell them that they cant! and they are not even
aware of the xcf as a format that would allow them to change the
composition at any time. In the worst case, they have managed to
destroy the original by overwriting it too!

The noobs are safe from destructive mistakes and the pro-s are happy
because it now works the way that is the defacto industry standard.
Only people that complain are the intermediate users that have habbits
they have to change now... Very human. And slightly tedious.
___
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?

[Alexandre Prokoudine]

On Fri, May 18, 2012 at 8:13 AM, gfxuser  wrote:
> 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?

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?

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.

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

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