Re: [Gimp-developer] New adjustment widgets

2011-01-07 Thread Thorsten Wilms
On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote:

 http://mmiworks.net/test/decadepopup.png

Aside of differences in labeling (of course not unimportant),
it's the same concept as
http://www.sidefx.com/docs/houdini9.5/basics/ladder
right?


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] Why artificially constrain toolbox window size?

2010-05-27 Thread Thorsten Wilms
On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote:

 The GtkToolPalette widget that hosts the buttons is able to nicely 
 distribute available space among the buttons, so I would like to remove 
 the resize constraint and make the toolbox dock window freely 
 resizeable. The attached patch does that.

Do the buttons still flow/wrap then, or does this lead to a fixed n rows
and m columns?


 Are there any important use cases or interaction design aspects I'm not 
 thinking about here?

I assume the icons force a minimum button size?

There *might* be some advantage to fix sized buttons regarding a
training effect.

At some point the icons will looks strange, surrounded by too much empty
space, but that's not really an issue as the user can keep it out of the
silly range easily.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] some current 2.7 issues

2009-12-06 Thread Thorsten Wilms
On Sat, 2009-12-05 at 17:34 -0500, Liam R E Quin wrote:

 (3) in most programs, save mirrors open, and export mirrors
 import - if GIMP is erally an XCF editor, open should work
 for .xcf and .xcf.gz files, and File-import should be there for
 the rare 99% case when you want e.g. to touch up a photo, and
 open a non-xcf file. So, please add file-import, with import
 as the label on the dialogue box. (I think?)

AFAIK the rule in other apps is to have all formats you also can save to
in Open, while Import is either for formats you can not save to,
an/or to import something that will become just one part of your
document (linked or embedded).


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] GIMP to be removed from Ubuntu Lucid Lynx?

2009-11-19 Thread Thorsten Wilms
On Thu, 2009-11-19 at 21:38 +0300, Alexandre Prokoudine wrote:

  http://www.omgubuntu.co.uk/2009/11/gimp-to-be-removed-lucid.html

 Did you see any links that prove this? Well, I didn't :) Neither most
 relevant ubuntu mailing lists provide any background.

I have been in that session and can confirm it.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] ceci n'est pas une selection...

2009-11-01 Thread Thorsten Wilms
On Sun, 2009-11-01 at 18:49 +0100, Sven Neumann wrote:

 I wonder why you need both hands on the tablet. The pros that I have
 seen working with GIMP always had one hand on the keyboard and the other
 hand holding the tablet pen. 

That's what I do, too. Wouldn't with a tablet-PC, though ;)


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] We should go for a single-window mode in 2.8

2009-09-21 Thread Thorsten Wilms
On Sun, 2009-09-20 at 23:49 -0400, Tom Rathborne wrote:

 (I also use focus-follows mouse and no-autoraise :) )

Interesting to see the focus-follows-mouse and no-autoraise combination
mentioned several times. In contrast, I use focus-follows-mouse with
autoraise (with 0 delay). It allows me to have a large image window that
partly covers 2 palette windows on the sides. Quick access to tools and
settings and large image view at the same time :)


Now from my understanding, the reason peter doesn't want single-window
with tabs combined with split views is simply that it would make it
unclear, which image the palettes and menu refer to. No matter how you
would try to deal with that, you always get a huge pile of additional
complexity.

Tempting to say: Allow split views via shift/ctrl-selecting tabs, have
all commands either affect both, or for those where that doesn't make
sense, disable them. Or duplicate the menu per split view. Also have the
split appear in the layers, channels and paths palettes. Just thinking
aloud :)


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] no-image-open redux

2008-03-08 Thread Thorsten Wilms
On Fri, 2008-03-07 at 20:48 -0500, Rick Yorgason wrote:

 Has anybody come to a consensus about whether or not the no-image dialog 
 should persist after an image is opened? 

This idea is new to me. The whole point is to represent GIMP if there's
no image, right? So it's not even a dialog, but the main app window.


  Even for expert users, it 
 might be useful to keep the no-image dialog open as a drop-target for 
 opening more images, but I can also see how it would annoy some users. 

I can see how it would annoy pretty much all users. It would very likely
end up hidden below the image window ...

-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] no image open spec...

2008-02-04 Thread Thorsten Wilms
On Mon, 2008-02-04 at 09:01 +0100, Sven Neumann wrote:

 I also very much wonder why the window should have something as useless
 as a slider to control the visual appearance but lack any useful widgets
 to give people quick access to the things they will most likely do next.
 What's wrong about a link to the recently used images and to the New
 image dialog?

Same here.

I think such a slider would be a waste of both developer and user time
(a _million_ users wondering: ooh, what does this slider do? ... to
never touch it again ;)

Reasons against having Recent/New in the window:
- visual noise
- both are in the file menu already and duplication would lessen
consistency in interaction / work against habituation.

But then I would prefer a window as narrow as possible, not much more
than just a title and a menu bar. Any image would get old soon and
putting effort into exchanging it frequently would be wasted.

Reasons for having Recent/New in the window:
- fast access to the only 2 things a user might want to do (well,
there's also accessing preferences)
- avoiding a mostly empty window which will trigger uncountable
complaints through all eternity ;)

The audio application Ardour has a startup dialog with New and Open
Recent tabs. The dialog has its issues, but feels very useful. I never
use a file manager to open a project there. For GIMP, it should be
possible to have New and Recent side by side.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] no image open spec...

2008-02-04 Thread Thorsten Wilms
On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote:

 the slider is a dead serious key in the whole experience. to seamlessly
 track the mood of users over a a working day (or a hobby night) is
 worth gold in user interaction.

You seem to assume that
- users will adjust the slider repeatedly
- this adjustment somehow reflects their mood (not just lighting
conditions from day to night or whatever)

I mean to recall that the product vision stresses serious, professional
level work. I don't see how playing with such a slider is compatible
with a getting-stuff-done mentality. I very strongly doubt that users
would adjust it repeatedly, anyway.

Then, even if they do: what does it tell us about their mood and what
would we do with that information?


 the thing to focus here is that GIMP is not going to behave like
 some  
 kid
 yelling (yep, that is what a dialog is): that was fun, what are we  
 going
 to do now... I mean now... really now!
 
 as long as we understand that, you will be able to understand the
 crucial decisions that I take here.

I fail to see how a full size window that is basically empty regarding
its informational and interaction aspects could be a good thing. It
manages to cover part of the desktop or other windows and distracts from
the then only useful bit, the menu. Seen this way, your wallpaper window
would yell, too, but it'd be: BLAH!

The opposite side of what are we going to do now would be see how you
get along, I will not raise a finger to help you.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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


Re: [Gimp-developer] crop isn't stopped at image borders

2007-06-19 Thread Thorsten Wilms
On Tue, Jun 19, 2007 at 01:38:06PM +0300, Alexander Rabtchevich wrote:
 In GIMP 2.3.18 crop tool isn't stopped at image borders as it was in 
 2.3.14. It is a bug: if ratio is set it is violated by this. And even if 
 no ratio is set crop should not affect pixels outside the image.

Do you mean the ratio is not correctly applied if the cropping rectangle 
leaves the image borders, and only then?

I disagree on the last sentence. While limiting crop to within the image 
borders is convenient in many cases, being able to freely change the 
canvas size for a layer or image is useful, too. I mean to recall it's 
in fact an option in the last stable release.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

2007-05-26 Thread Thorsten Wilms
On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote:

 Turning Gimp into a MDI application will make several users happy, but 
 IMO it won't benefit Gimp at all.
 I think it would be better to improve the way those floating windows work:
 - by creating only one item in the windows list, grouping GIMP's 
 windows, instead of one item for each panel (it's quite confusing)
 - by making toolbox and dockers dependant of the canvas window.
 As it was discussed before, this brings a new problem: where should the 
 menu bar be placed. Of course, the document window is the most ovbious 
 choice, but as we use floating windows, it won't be any document window 
 when we open the program.
 Maybe the best option is to create a new kind of splashscreen, where we 
 get as options:
 -Create a new image (if you choose this, the new image dialog appears, 
 with dimensions, templates, color mode, etc.)
 -Open existing image/s (if you choose this, the filer appears, letting 
 you pick an image or a group of images).
 Once you made your choice, the toolbox and dockers will appear along the 
 document/s window/s.
 (I'm thinking about something like the latest Adobe Premiere Pro initial 
 screen, for instance, but in the GTK/floating windows fashion)

As far as I got it, this is all in line with what Peter has been 
proposing. Where MDI would be an _option_ that could be tackled 
_after_ floating panels have been adressed.

 
 Another thing that was covered in your work is the use of the screen 
 space. I agree that the current menu layout is a waste of pixels.
 But this is already possible to improve in Gimp using the small theme 
 and putting the tool options panel in the docker window. This allows you 
 to shrink the toolbox, gaining much window space.
 You can see a screenshot of my current tool layout in gimp using that 
 idea here:
 http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

Fine if that works for you and nice to see docking put to work for 
a custom layout. But I shudder on the thought of having to move the 
pointer from one side of the screen to the other, for tweakink tool 
options after picking a tool. (Personaly, I learned the shortcuts for 
all frequently used tools, but I still use the tool palette at times)


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

2007-05-25 Thread Thorsten Wilms
On Fri, May 25, 2007 at 02:15:32AM +0200, peter sikking wrote:

 http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- 
 requests_25.html

On 4. better painting tools:

So you propose to have brush models in tools like dodge/burn.
Why would this be preferable to having modes like dodge/burn inside 
brush tools?
Maybe brush model and mode should be handled separately?

A: The region/scope to work on
  - whole image
  - a layer/group/set
  - a selection
  - brush strokes as they happen
B: Options for above
  - mainly brush model with parameters comes to mind
C: The action or drawing mode to apply
  - transformations
  - filters
  - paint


On power modes

Sounds like a rather vague distinction, makes me wonder if 
is such a good idea to split the modes based on it.
Shouldn't layer and paint modes be kept the same?


dipping and smearing

Considering GIMP is not and shall not be painter ... but this would 
be very nice especially for drawing from scratch ;)


On versions and approaches

I have been using layers for versioning, backup, too. It just works.
Of course real, branched versioning would rock. How much I would like 
to see it everywhere. Maybe there's a chance of pushing part of the 
functionality out, so it can become part the environment and have 
a wider developer pool?


Regarding adjustment layers and GEGL

GEGL is graph based, somewhat comparable to the nodes in Blender, 
right? If so, the concept of a layer stack does not match GEGL.
I would propose to go all nodes and have no layers, if the layer 
stack wouldn't match the common case so nicely.


On window management

I have been thinking: What if GIMP was represented by a window with 
just the main menu. Image windows could be dockable palettes. Requires 
docking side-by-side. For SDI style, one would dock one image window 
and the inspectors all to the main window. Several images could docked 
together to have tabs.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

2007-05-25 Thread Thorsten Wilms
On Fri, May 25, 2007 at 05:25:14PM +0200, [EMAIL PROTECTED] wrote:
 
 If everything ends up dockable and there is no longer the freedom to  
 place windows where you _need_ then to be
 I think it should stay as it is. Maybe that was the fundemental reason for  
 this rather unusual set up in the first place.

I talked about dockable, not forcing things to be docked. The only necessary 
restriction of placement of floating palette windows would be palette headers 
right above docking areas (as that should trigger docking). I'm confident 
this could be arranged to be no issue in actual use.
Actually, if you think about it, docking would happen when you move a palette 
close to the bottom or side of another palette, so the then docked pallette 
ends up pretty much where you move it to, but tightly arranged, most space 
efficient. Or if you moved it on top of another palette, you get a tab and 
can easily switch to what would be completely obscured otherwise.


 I know this sort of thing is possible in win32 API but I dont seem to be  
 able to find any linux progs, gtk+ or qt derived, that have freely  
 floating windows or panels.

So what if GIMP became the first?


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...

2007-05-22 Thread Thorsten Wilms
On Tue, May 22, 2007 at 01:24:34AM +0200, peter sikking wrote:
 guys + gals,
 
 part two of three of our lgm presentation is online:
 
 http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- 
 requests.html


10. better printing support

Paper, maybe better called media, could be handled as special kind of 
layer that is restricted to stay below all image layers (unless hiding 
stuff below it makes any sense).
Allowing n media layers would make working on and comparing several 
alternatives easy, I think.
If all media layers are hidden, zoom best-fit could work on the image, 
otherwise on the media.

But paper alone is not a sufficient model, I fear. There's the thing 
you print on and the final product (after cutting, perhaps) ...
PDF has this media/crop/trim/bleed/art box model. Scary stuff ;)
http://bugs.scribus.net/view.php?id=1041
Better written, but german: http://www.dtp-praxis.de/tipps/pdfboxen.htm


7. save for web

Should include indexing for GIF (mandatory) and PNG (optional).
If one needs to create a number of images in indexed colour mode that 
share some colours and where deviations are not acceptable, there 
should be an alternative to indexing them all as one image to then 
cut them apart.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...

2007-05-22 Thread Thorsten Wilms
On Tue, May 22, 2007 at 11:29:55AM +0200, peter sikking wrote:
 Thorsten wrote:
 
 10. better printing support
 
 Paper, maybe better called media, could be handled as special kind of
 layer that is restricted to stay below all image layers (unless hiding
 stuff below it makes any sense).
 
 Think workflow, not about highjacking a image concept (layers):

I thought I did. Think about workflow.


 But paper alone is not a sufficient model, I fear. There's the thing
 you print on and the final product (after cutting, perhaps) ...
 PDF has this media/crop/trim/bleed/art box model. Scary stuff ;)
 http://bugs.scribus.net/view.php?id=1041
 Better written, but german: http://www.dtp-praxis.de/tipps/ 
 pdfboxen.htm
 
 Wow scribus, a pre-press oriented (that is their product vision) dtp  
 app.
 GIMP's ambitions to not reach that far.

The nature of Scribus is not of interest here, Ther just happens to be 
an english language description of the terms in their bug tracker.

It doesn't matter if you deal with complex page layouts or just images. 
It also doesn't matter much whether you target your desktop printer 
or a larger machine. The issues of media size, printable area, bleed 
and desired final size are just there.


 I would really measure this static-indexed requirement against the
 product vision before throwing in yaUIc (yet another UI complication).

Sure.
 

 And why are we talking teensy little details here when the presentation
 and blog entry was about solutions models: the general direction  
 forward?

It doesn't look to me like there is anything to discuss about your 
solutions model. I would mean this in a bad way if it didn't look like 
you know what you are doing there and if what I read didn't seem all 
agreeable.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] lgm 07, top???10 GIMP user requests...

2007-05-22 Thread Thorsten Wilms
On Tue, May 22, 2007 at 01:17:38PM +0200, peter sikking wrote:

 I thought I did. Think about workflow.
 
 Then how do you end up selecting an intra-image concept (layers)
 to support the task of putting the actual image itself on another
 medium (paper)?
 
 If you concentrate on understanding the task, then thinking about
 layers feels wrong within a second, and you can move on to solve
 the problem in another way.

If you concentrate on the can't-be-painted-on and has-to-be-below- 
image-layers aspects only.

But a place at the bottom of the z-order is natural. The medium 
has size like a layer and relative positioning. Hiding/showing 
is surely useful. This plus the chance of making media/positioning 
alternatives available in a straightforward way is what came to my mind.

The slight modification of putting it into a distinct section below 
the layers or if it has to be, it's own panel (which I would place 
below the layer panel by default) might be all that is needed to 
make the difference clear enough.

But I have been thinking aloud. I'm terribly sorry.


 All those concepts fall within GIMP users' awareness and are actually
 named in the blog entry as interrelated textfields that support the
 placement. But they will be handled in the UI in a way that gets
 artistic results done, and not in technical pdf file format terms.

I didn't say those names have to appear in the UI.
 

 It doesn't look to me like there is anything to discuss about your
 solutions model. I would mean this in a bad way if it didn't look like
 you know what you are doing there and if what I read didn't seem all
 agreeable.
 
 What I mean to say is: can you see that all this detail stuff
 does not really matter at this moment, unless one of these details
 invalidates the overall concept?
 
 This is the way to cut through the jungle of small details, and
 to concentrate on major problems that need to be solved first.

As the overall concept seemed clear to me so far, I though it 
was ok for me to post what your points made me think of. As part 
of going from the general to the more specific. To avoid me forgetting 
about these things, if nothing else.
 

-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save Changes Integrated

2007-05-20 Thread Thorsten Wilms
On Sun, May 20, 2007 at 03:29:37PM +0200, Sven Neumann wrote:
 
 Well, you have overlooked the main problem here. If you add user
 interface elements to the image window, then these will cover parts of
 the canvas and there will be no way to unobscure the covered parts. So
 if you think that it may be important that the user has a chance to
 check the content of the image window, then a popup dialog is the only
 way to go.

No. Either being able to see the canvas is important, in which case 
adding the message and resizing the image window can be better than 
having the user move a window around. Even without resizing, scrollbars 
could come o the rescue.
Or it is not important, so the window doesn't have to be resized and the 
message can obscure part of it (which might be less drastic than the 
dialog window jumping up right in the middle.

With a dialog window, I wonder if it would be better to place it top 
right, though. Close to the Close button.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save Changes Integrated

2007-05-20 Thread Thorsten Wilms
On Sun, May 20, 2007 at 04:29:34PM +0200, Sven Neumann wrote:
 
 There is nothing more annoying that a window that resizes itself. In
 particular because it is very difficult, if not impossible, to get this
 right with all the various window managers being used by our users. The
 window manager may even decide to completely ignore the resize request
 from the application.
 
  With a dialog window, I wonder if it would be better to place it top 
  right, though. Close to the Close button.
 
 Placement of dialog windows is left to the window manager. And only
 because your window manager draws a Close icon in the upper right corner
 doesn't mean that other window managers do that.

I didn't meant to imply the GIMP should or could take care of this.


Taking all the feedback into account, here's another variation, 
now entirely targeted at the WM. Just so you know I'm not ignorant ;)
I will try to raise this with the Metacity project.

http://thorwil.wordpress.com/2007/05/20/save-changes-integrated-3/


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Save Changes Integrated

2007-05-18 Thread Thorsten Wilms
Hi!

Image window and Save Changes dialog turned into one:
http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/

-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save Changes Integrated

2007-05-18 Thread Thorsten Wilms
On Fri, May 18, 2007 at 03:41:39PM +0200, peter sikking wrote:

 http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/
 
 Somehow I do not know what structural problem you are trying to
 solve for one million users.

The current Save Changes dialog tends obscure the image.
If users would be damn sure about closing a window with unsaved 
changes every time, there would be no need for asking back. So 
the user should be able to see _what_ he's about to save or 
discard. The image itself is likely to be much more informative 
than filename and changes from the last x minutes.

BTW, from my own experience, hitting Save when the prior version 
was actually better and something to be kept is much more of a 
danger than not saving something you wanted to keep.

Now that I write about it, another idea comes to my mind:
The Save Changes window could have a toggle to display the last 
saved version.

The dialog is very closely tied to the image window, but still 
presented  as its own window. Transforming the image window into 
a Save Changes window is as clear as you can get about the
relation.

One can get rid of the visual noise of a dialog with titlebar 
and border and avoid obscuring the image in one go. So this 
removes unnecesary elements from screen, something that I think 
is quite helpful if you deal with several image windows.





-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save Changes Integrated

2007-05-18 Thread Thorsten Wilms
On Fri, May 18, 2007 at 05:38:19PM +0200, peter sikking wrote:

 http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/

 It is a modal dialog situation: we need a decision now.

Yes, the scope being the image. Regarding that one image window, 
a decision is needed, outside not.
 

 If users would be damn sure about closing a window with unsaved
 changes every time, there would be no need for asking back. So
 the user should be able to see _what_ he's about to save or
 discard. The image itself is likely to be much more informative
 than filename and changes from the last x minutes.
 
 I find this stress on looking at the image very worrying.
 What drives the decision is the state of mind of users:
 these changes in the last xy minutes were useful/useless.
 
 Either this state of mind is there, because the one just
 worked on the file, or it is not there, because one worked
 yesterday on the file. In that case I am not going to
 invite anybody to investigate that within a dialog.
 Back off (Cancel) and investigate with all of GIMP's
 capabilities, I say.

Ok, you have a point here.


 The dialog is very closely tied to the image window, but still
 presented  as its own window. Transforming the image window into
 a Save Changes window is as clear as you can get about the
 relation.
 
 I do not think so. First you have to realise that this
 decide to save the unsaved is an error scenario, a
 non-task if you will. You are building a full-fledged UI
 for a task that does not exist on users' radar screen.
 
 That is a misfit.

You never witnessed people using the dialog with the intention 
of triggering a save and closing the window? I did. Of course 
I have no numbers :)
Not that this changes anything here, I just thought does 
not exist on users' radar screen is bold, if not wrong.

 
I think I understand your reasoning and maybe my proposal is 
not good.
I'm not at all convinced about the presentation of this modal, 
tied to another window while looking like any other window 
itself dialog, though.
It already shares focus and minimising with the image window.
It being a semi-separate window is only good for moving it.
Moving it is only good for getting to see the whole canvas. 
If it would not cover any part of the canvas, there would be  
no need to move it. If there's never a need to move it, it 
shouldn't be a semi-separate window.

Of course something could be done on a WM level, like not 
drawing it with a titlebar and placing it right below the 
image window menu bar or whatever placement would emphasize 
the connection.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save Changes Integrated

2007-05-18 Thread Thorsten Wilms
On Fri, May 18, 2007 at 08:33:38PM +0200, Thorsten Wilms wrote:
 
  http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/

 I'm not at all convinced about the presentation of this modal, 
 tied to another window while looking like any other window 
 itself dialog, though.
 It already shares focus and minimising with the image window.
 It being a semi-separate window is only good for moving it.
 Moving it is only good for getting to see the whole canvas. 
 If it would not cover any part of the canvas, there would be  
 no need to move it. If there's never a need to move it, it 
 shouldn't be a semi-separate window.
 
 Of course something could be done on a WM level, like not 
 drawing it with a titlebar and placing it right below the 
 image window menu bar or whatever placement would emphasize 
 the connection.


http://thorwil.wordpress.com/2007/05/18/save-changes-integrated-2/


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Canvas Size Margin

2007-05-13 Thread Thorsten Wilms
Hi!

I often use Image: Canvas Size to add a margin.
Recently mainly with mockups, where I want 12 px all around.

Doing the calculations in my head isn't too difficult, but does 
eat time and makes me context switch.

One solution would be allowing calculations in the entrie: 436+24 ...
Typing +24 can be faster than erasing and typing 460.
*2 is faster than switching to percent and 200.
But that should be added on a GTK / per widget level, perhaps?

Another solution would be having fields for the margins or differences.
Would complicate the dialog, but could offer nice possibilities if 
one needs different margins left/right/top/bottom.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier

2007-02-24 Thread Thorsten Wilms
On Fri, Feb 23, 2007 at 05:14:13PM -0800, Mark Lowry wrote:

 It would be useful to add a temporary magnifying
 window that would provide a
 zoomed-in view of the area immediately surrounding the
 cursor.

 This functionality would be very useful when making
 selections with the pen
 tool, lasso tool, etc.

Hmm. I do in fact a lot of zooming when cropping or making 
rectangular selections, where I need both the 'big picture' 
and pixel precision.

But how to make sure the window doesn't obstruct an 
area you need to see?


 Another way to implement this would be to have the
 magnification value in the
 preferences, and instead of opening up a separate
 window for the magnified view
 you enlarge a circular region immediately surrounding
 the cursor 

Could be problematic with rectangular selections.


This leads me to a similar idea:
Opening a second view (implemented since long) 
and enabling an option 'follow cursor', which would 
scroll the view following the cursor, as long as the 
cursor is on another view.


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save As JPG Integrated

2007-02-07 Thread Thorsten Wilms
On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote:
 
 Despite the idiot-user title of this feature (copied for PS it seems)  

...

 If the user is so lame that they are going to click on a feature called  
 save for the web 

If a user wants to save images for use on the web, save_for_the_web 
is high level thinking and not lame or idiotic.

The choice of format is secondary.
1. save for web
2. use most appropiate format


 Someone  
 choosing save for the web needs help, let's provide some rather than  
 maintaining them in thier ignoracen and providing enevitably compromised  
 solutions.

I know the characteristics of JPG, PNG, GIF. I can usually tell 
what will work best. There are border cases, though. Then I have 
to experiment and can't formulate save_as_jpg or save_as_my_png 
as my initial goal at all.


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save As JPG Integrated (mockup)

2007-02-06 Thread Thorsten Wilms
On Tue, Feb 06, 2007 at 05:01:33PM +0200, Aurimas Ju?ka wrote:

 I've worked on a similar plug-in. It would be very interesting to hear
 some comments on it as I am planning to improve it. Here is a short
 introduction: http://img300.imageshack.us/img300/6571/saveforwebid4.jpg
 Peter, could you tell if it fits in save for web scenarios and what
 could be changed to make it better.


If the formats are just JPG, PNG, GIF, radio buttons should
be considered for faster access.

I resize images requently when exporting for web, but 
almost never crop them.

Like I said before, I prefer toggling one view over 2 side by side.
I don't think separate scrolling is useful.
The again, a single set of scrollbars for 2 panes might seem odd.


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Save As JPG Integrated (mockup)

2007-02-03 Thread Thorsten Wilms
Hi!

Whenever I save an image as JPG, I have to move both the 
Save_Image and the Save_as_JPEG dialog out of the way 
to check the preview.

I think the Save_Image dialog should just disappear 
after use, as both Cancel and Help are available on 
the second dialog and what else would it be good for?

Then the Save_as_JPEG controls could appear on the image 
window (inspired by the Firefox find bar) to further cut 
down on window juggling.

There's quite a number of ways it could be organized, my 
mockup shows just one:

http://thorwil.affenbande.org/wp-content/uploads/2007/02/save_as_jpg_integrated_01.jpg

Advanced options hide 'under' the expander. There could 
be a button to bring them up in a dialog instead.

File size can be read in the statusbar.

I moved the buttons down there as it's the standard 
location in dialogs and to take the place of the 
progress Cancel button. Mouse-miles could be less
with the buttons in the new toolbar. They would 
also be less likely to cause an expectation of 
closing the window up there.

Thoughts?


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Save As JPG Integrated

2007-02-03 Thread Thorsten Wilms
On Sat, Feb 03, 2007 at 01:13:56PM +0100, [EMAIL PROTECTED] wrote:
 On Saturday, February 3, 2007, 12:48:54, Thorsten Wilms wrote:
 
  Then the Save_as_JPEG controls could appear on the image 
  window (inspired by the Firefox find bar) to further cut 
  down on window juggling.
 
 Only as an option - some of us have multiple displays, and use the advanced
 options regularly.

Do the save dialogs not appear on the same screen as the image 
windows?

I see how if you have at least 2 displays, having the preview 
on one and the (expanded) controls on another would be nice. 
But if you have to manually move the windows far less so.

I'm rather sure users of multiple screens who are at the 
same time frequent users of the advanced JPG controls are 
a small minority. Nobody likes to be ignored, though, of course ;)


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


Re: [Gimp-developer] Save As JPG Integrated (mockup)

2007-02-03 Thread Thorsten Wilms
On Sat, Feb 03, 2007 at 02:02:58PM +0100, peter sikking wrote:
 Thorsten Wilms wrote:
 
  I think the Save_Image dialog should just disappear
  after use, as both Cancel and Help are available on
  the second dialog and what else would it be good for?
 
 Yeah it can go. It would only make sense if a Cancel on
 the jpeg options would get you back to the Save_Image dialog,
 in case you see that the jpeg compression is not appropriate,
 you change your mind and go back for png or so...

Good, that would make the process quite a bit more 
efficient (for me) already :)

 
  http://thorwil.affenbande.org/wp-content/uploads/2007/02/ 
  save_as_jpg_integrated_01.jpg
 
 I just had a quick look. Later in the expert evaluation we
 will get to the save for web scenarios and I will be in
 a better position to deal with this. But for now:

Hmm, ok.
 

 If we try to do an all in one, then the result has to
 look and feel like a dialog, not like a main window,
 because of the modal nature (finish this first) of the task.

But this would not be like your common dialog that disappears 
after Cancel/OK, but rather a window that changes state.

One could see this as argument for having a separate dialog 
with preview.
This idea is about avoiding a 'jump' in interaction 
and using the image window which is likely in the right  
place and size already, though.


 It is difficult for me to say whether sawing off more main
 window bits (no menu bar, tools, palettes, inspectors or rulers;
 default to magnification tool) and adding more dialog-ness
 (get buttons out of the status bar) to what you have drawn,
 or start from scratch on a BIG-preview dialog would be the
 better way to go.

I thought about removing at least the menubar but decided 
against it, as you can still zoom, toggle guides ...
Might be better to not allow access to editing options, though.


  Advanced options hide 'under' the expander. There could
  be a button to bring them up in a dialog instead.
 
 My gut feeling says that there is a better solution available
 here, but I am only able to work on that after the expert evaluation.

Surely the most problematic aspect.


  File size can be read in the statusbar.
 
 Better keep the quality slider and file size (main cause
 and effect) physically together.

I wanted to, at first. Then moved it to save width 
for small images.


BTW, some apps have web export dialogs with side by side 
panes original/compressed. I found toggling between  
original/preview in the same view to be superior if  
you want to spot JPG artifacts. It's important it can 
happen with a single click. I say this because the thought 
that tabs might make it more clear what is what has occured 
to me ... this is the reason I don't want them.


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


Re: [Gimp-developer] Meaning of delay in screenshot plugin

2007-01-31 Thread Thorsten Wilms
On Wed, Jan 31, 2007 at 11:02:20AM -0800, Akkana Peck wrote:
 
 [pre- vs. post- selection delay]
  I estimate the chance that one is not taking a screenshot of GIMP
  itself as higher than 50%. So you need time to get GIMP out
  of the way.
 
 To get the screenshot dialog out of the way, you mean?
 Is it really that common to screenshoot a single window which is
 so large that there isn't room for both it and the screenshot dialog
 on the screen at the same time?

Yes. I always reserve a workspace for GIMP, though.


 To the list: does anyone here actually uses the delay for that purpose?
 The people who have asked for before-screenshot delay mostly seem to
 want time to switch desktops (a valid reason but surely not a 99% case).

In my case, I use a short delay just to switch workspace most 
of the time. Sometimes I need more delay for some menu or popup.


 Steve Stavropoulos' interface, with the two clearly explained
 delays, seems so much easier to understand than trying to intuit
 a mouse-already-down behavior.

I think so, too.


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


Re: [Gimp-developer] add mouse action for brush scaling

2007-01-24 Thread Thorsten Wilms
On Wed, Jan 24, 2007 at 11:32:03AM +0200, Alexander Rabtchevich wrote:


 Currently scalable brush can be scaled with [ ] by default, what is very 
 fine. Could a mouse scroll wheel + some key modifier be used to act the 
 same as [ ] buttons?

I couldn't find it in the shortcut editor (maybe I overlooked it).
It should be listed there, right?
 


 I'm a right-handed person, so when I retouch a photo most of my actions 
 are connected with mouse movements and some left hand actions: Ctr+H, 
 Ctrl+C, Ctrl+wheel, Shift+wheel, Space. Rather often brush needs to be 
 scaled, so I have to left mouse and press [ or ] several times. The left 
 side of the keyboard is mostly taken with shotcuts.
 
 I suggest adding Alt + wheel to act like [ ] for brush scaling. It could 
 be very convenient to a user not to leave a mouse for keyboard and due 
 the wheel is very well controllable and intuitive for scaling purposes.


Hmm, Alt + wheel is mapped to opacity.
Ctrl + wheel zooms.
Shift + wheel scrolls sideways.

While I prefer + and - for zooming, I guess some people would 
complain if ctrl + wheel got remapped.

Preferences - Input Controlers allows to map mouse wheel events 
to actions, but I don't see actions for changing brush size.


Ctrl + Alt + wheel cycles through gradients.
Shift + Alt + whell cycles through patterns.
Shift + Ctrl + wheel cycles through brushes.

I think the last 3 are quite odd, but 2 keys plus wheel isn't  
exactly comfortable anyway, so I guess you wouldn't want an often 
used feature there.


--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil

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


Re: [Gimp-developer] Drawing zones

2007-01-18 Thread Thorsten Wilms
On Thu, Jan 18, 2007 at 02:57:30AM -0300, Manuel QuiƱones wrote:
 I've had a similar idea than yours, and implemented it right away. But
 instead of changing zones with keystrokes, the zone can be selected
 using the crosspoint of two perpendicular guides. I know this is ugly,
 and maybe your idea about changing to next/previous zone is better.
 Here it is:
(...)
 http://wiki.gimp.org/gimp/DrawingZones

I like the idea of using a layer and a palette to draw the zones.
Even though I talked about hard edges, I (and everyone else drawing)
need anti-aliased ones in almost all cases :}

The selection via 2 guides isn't practical, of course. I understand why 
you do it for now, lets hope there will be a solution.


--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil

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


Re: [Gimp-developer] Drawing zones

2007-01-18 Thread Thorsten Wilms
On Thu, Jan 18, 2007 at 08:04:28PM +1030, David Gowers wrote:

 I like the idea of using a layer and a palette to draw the zones.
 Even though I talked about hard edges, I (and everyone else drawing)
 need anti-aliased ones in almost all cases :}
 
 
 Well, the simple case of that is easily done -- I just inserted two lines in
 my zonemap tool that automatically antialias the zone mask using potrace. I
 think that repeatedly drawing in a non-binary selection is a mistake, though
 -- layer masks or 'preserve layer alpha' do it better.
 
 I rarely ever use antialiased selections for drawing, only exclusively for
 fills (either color fills, alpha-clearing fills, or editing layer masks).
 Drawing into AAed selections makes selecting objects a no-win (ie. cannot
 get a perfect result, because the colors along the edges are uncontrolled)
 situation, and dirties colors.

I usually work with a bunch of alpha-locked layers (paint shape in flat-colour, 
lock alpha, paint shadows, light, texture ...)

I guess the perfect zone implementation would actualy need some overlap 
to have the same effect of alpha-locked layers.

 
 In fact, the best simple solution could be to copy selection masks onto
 layer masks. Like, you have a 'painting' layer, and when you change zones:
1. Any changes are saved onto the underlying layer
2. The entire content of the underlying layer is copied to the paint
 layer
3. The layer mask is copied from the next zone-mask (channel)
 
 This would play well with my 'apply paint' plugin, which applies any paint
 on a layer (specially marked by name, beginning with the character '+') to
 the underlying layer and then clears it to a neutral color.

In short, drawing zones happening on the level of layer masks?


Another model I thought about would require a graph, so I guess 
it's really a bit far out for GIMP: Having a layer/node for 
compositing drawing layers/nodes. It would be like a free-form 
multi-split view on a number of layers. Drawing starting in one 
zone of the view and continuing the stroke outside of it could 
paint on the underlying layer/node, maintaining the advantage 
that using layers has now: you can draw below a layer and later 
change the shape of an upper layer without having to fill a gap.


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Drawing zones

2007-01-17 Thread Thorsten Wilms
On Wed, Jan 17, 2007 at 08:52:48AM +0100, Sven Neumann wrote:
 
 I start to realize what you are asking for now. But, instead of
 suggesting a solution, could you perhaps try to explain where the
 problems are when you try to use the currently available features to
 implement your workflow? You should be able to do this with layers or
 selections. If that doesn't work for you, then perhaps there's something
 that we need to change about how layers and/or selections are handled. I
 don't think that we need to introduce a completely new feature.


# The goal:
Draw on several areas of an image while maintaining sharp edges 
around each of them (in many cases they will touch, so before I 
talked about edges between them).
With the least amount of interruption!

# Motivation
You often have parts of an image that need the same treatment, 
but are clearly divided (like hand and body on my example image).
You draw with the same base colour, draw light and shadow, 
texturing ... all best done in one go.

[Drawing from scratch might not be seen as typical use of GIMP, 
but I know I'm not the only one and the closest commercial 
counterpart, Photoshop is used for this alot, even though 
there's Painter. Check for example
http://forums.cgsociety.org/forumdisplay.php?s=f49edc03bcbdb53f623009e1366edda9f=133]

# Layers
Using layers, you will likely end up with one layer per 
area. You need to switch between them. Just today I took notice 
it can be done with Page Up/Down, layer name appears in status 
bar. If you don't use the shortcuts, you need the layers dialog, 
taking away space from the drawing area. If you use them, it's 
just a keypress, but you have to take care in which layer you end 
up (drawing something on the wrong layer is a mistake i make  
often enough, even usuing the layers dialog).

# Selections
Loading selections to me means having to change between 
layer and channel tabs and a lot of mouse movement away from 
the canvas. This already makes me use layers with locked alpha 
everywhere I can. Only with exactly 2 areas, one could use 
inverse selection.


# Drawing zones
I think drawing zones would have to be organised in sets.  
The zones of a set would always cover a full rectangle like 
layers do.
Inside a set you would add/delete zones and select the zone 
you want to edit. Editing could then happen with the current 
selection tools. Masking would require 1 colour for each  
zone.

I admit this sounds a bit complicated. Now for the nice part: 
once setup, you just draw! If you move the pointer outside 
the zone you started drawing in, nothing happens (just like 
painting outside a selection). You don't have to hit a single 
button, but get to focus on drawing completely.

# Stop lines
My initial idea was to have just lines (non-closed paths), 
which you can't draw past. So they act like a selection 
boundary, but are not closed. You could even draw all around 
them, something that might be helpful on drawing armpits.
I then thought it might be hard to check for this, 
so closed regions/zones might be easier. The management 
of stop lines might be more simple, though.


--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil


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


Re: [Gimp-developer] Drawing zones

2007-01-17 Thread Thorsten Wilms
On Wed, Jan 17, 2007 at 01:18:35AM -0800, Saul Goode wrote:
 
 If I am understanding you correctly, these scripts should be helpful to
 you in your workflow. You would still have to manually invert the
 selection; but I would point out that the Select menu can torn off so
 that Select-Invert is just a mouse-click away. 

Sorry, no. I don't see the benefit over switching between layers.

Lets try another description:
Drawing zones would be like 2 or more non-overlapping selections 
that are active at the same time. Which one is applied to a drawing  
operation is determined by where the mouse/pen-down happens.

Implicit area selection (to not say Selection selection) :)


--
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] More interface rantings

2006-10-21 Thread Thorsten Wilms
On Fri, Oct 20, 2006 at 02:29:31PM -0600, Scott wrote:

 I also completely fail to see
 any reason why areas outside the image should be selectable by a crop
 tool. If I lay a paper photograph on a table and take an xacto knife
 to it, do I reasonably expect to cut out part of the table along with
 what I cut out of the photograph? It is nonsensical.


You're quick with a word like 'nonsensical', when in fact you just 
have a narrow view on this.

You could for example have a photo and now you want to add a border 
around it. The canvas size dialog doesn't the same direct manipulation.

The GIMP is also a nice tool for drawing. Here it can always happen 
that you want to change the composition. Perhaps the foreground asks 
for more space on the left. Easy to do with the crop tool, especialy 
now it has guides (center, golden cut ...).


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


Re: [Gimp-developer] More interface rantings

2006-10-20 Thread Thorsten Wilms
On Fri, Oct 20, 2006 at 10:32:50AM -0600, Scott wrote:
 
 Using the 2.2 version, the interface of the crop tool was very handy
 for me. Typing Shift-c brings up the tool; a quick move of the mouse
 creates a selection area; over to the tool-option menu that
 automatically pops up, type in 300 and 200 for the dimensions; now
 grab the lower-left handle and move the selection as desired, click
 and it's done. 

The old crop tools was ok if you have a fixed target size. 
The dialog always got in the way for the cases where you crop 
the image to find the right aspect.

 
 I recently upgraded to Mandrivel 2007, which includes the 2.3. Did my
 first crop this morning. No tool-option. Okay, clicked on the tools,
 or view, or some danged thing, found the tool option. Hmmm, a whole
 bunch of stuff that doesn't really relate to what I am doing. Finally
 I find some hidden dimensioning menu and enter in the 300 and
 200.

The new place of the dimensions saves me from having to move a dialog 
out of my way every time. I'm less happy about the expander, though.


 Grab the lower left corner - whoops! All the corners resize the
 selection! Handy not.

Resizing and finding the right cutout has become way easier now.


 Instead of automatically confining
 itself to the image as before, I can move the selection outside of the
 image. Now that's *really* handy - like I would ever want to select a
 certain size and then have part of it outside the image.

Sometimes I need to crop extending to outside the current image.
But there should be an option for confining to current size.
On by default, as it's the right choice in most cases, I think.


 How can a tool so simple in concept and so
 frequently used as crop have been bollixed up so badly?

To me it seems it's just that you see only a single use case ;)


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


Re: [Gimp-developer] mock ups for vanishing point

2006-06-01 Thread Thorsten Wilms
On Wed, May 31, 2006 at 10:37:17PM +0200, Pedro Alonso wrote:

 I am Pedro Alonso, a SoC student working in the project Vanishing
 Point clooning.

Great project.
 
 http://www.pedroalonso.es/mockups/plot1f.png
 http://www.pedroalonso.es/mockups/plot2f.png
 http://www.pedroalonso.es/mockups/plot3f.png


I think it would be nice to get around having a modal dialog 
(one with Cancel/OK) for a more straightforward interaction.

How about having a tab next to Layers/Channels/Paths for 
perspective planes? You would create a new one by just using  
the p-plane tool similar to how paths are created.
Each p-plane in the list could be toggled on/off. Every tool, 
as far as possible, should be affected by p-planes.
The p-plane tab would also allow creation of selections from 
the planes (like with paths).

One think I'm unsure about is how to handle plane extension.
With your example image, the same perspective is everywhere, 
so one would need a way to say the p-plane is defined in a 
smaller area, but covers all.
But if there would be a vertical wall in that image, you 
would need a second p-plane. Saying that one of them covers 
all of the image, except where the other p-plane is, wouldn't 
be good enough in some cases.
A solution could be to define for each edge, wether the plane 
extends in that direction.


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


Re: [Gimp-developer] Comments on gimp's interface

2006-04-03 Thread Thorsten Wilms
On Mon, Apr 03, 2006 at 12:17:45AM +0200, Fr?d?ric van der Essen wrote:

 #5 How do i pan with a graphical tablet ? (no RMB/MMB ?)

If you don't waste one of the buttons for double-click, you 
can have them all. Double-clicking with the pen only needs a little 
getting used to it, but after a short while it feels natural and is 
efficient.


 #5 RMB / MMB should be emulable with keyboard shortcuts like alt-lmb = 
 mmb, space-lmb = rmb, or something like that.

Try the rectangular selection with various modifier keys pressed 
and held before or after clicking ...


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


Re: [Gimp-developer] Comments on gimp's interface

2006-04-03 Thread Thorsten Wilms
On Mon, Apr 03, 2006 at 01:14:07PM +0400, Alexandre Prokoudine wrote:

 I might have lost track. One of my tablet's pen buttons (I own
 Graphire3) does exactly panning in GIMP/Inkscape/etc. If one has a
 tablet without buttons on a pen, he can press Space on his keyboard
 and go panning. So, what is exactly wrong with panning via tablet?

With GIMP and Inkscape, panning is on MMB.

There's the option to put double-left-click on one of the buttons. 
If you do that, you can't have both MMB and RMB also available.
If you don't, all is fine with panning.

Space switches to the move tool here.


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


Re: [Gimp-developer] Comments on gimp's interface

2006-04-03 Thread Thorsten Wilms
On Mon, Apr 03, 2006 at 01:48:18PM +0400, Alexandre Prokoudine wrote:
 
  There's the option to put double-left-click on one of the buttons.
  If you do that, you can't have both MMB and RMB also available.
  If you don't, all is fine with panning.
 
 So it this considered GIMP's fault or tablet's fault?

Either the fault of who ever set such defaults (where I don't 
remember the linuxwacom defaults, but i think on windows double-click 
on the lower button was default), or the user who keeps or makes it 
that way.

One could say apps shouldn't rely on MMB. But there are so many  
features and options to have especialy in media applications, 
that working around this is too hard, when everyone can easily have 
3 buttons.

Now one could argue space should be for panning like in Photoshop, 
not move tool. I prefer middle-click drag for panning, anyway.


Cheers,
Thorsten Wilms
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-27 Thread Thorsten Wilms
On Sun, Jun 26, 2005 at 09:21:39PM -0300, Joao S. O. Bueno Calligaris wrote:
 
 On left-clicking on the layer-tree, where the current linked icon 
 for each layer is placed, a drop-down menu would be displayed.
 This menu would contain 4 itens which could each be checked or 
 unchecked:
 
 Transparency Lock
 Color Lock
 Geometry Lock
 Linked  

Linked is not like the locking options, so it should be kept separated.
A dropdown menu is expected to disappear on clicking an entry, so 
changing several options would make for a click orgy.
Color and Geometry lock are no way as important as linking.
The fact your targets only appear after an initial action slows you 
down. Icons/Checkboxes above the list might be faster to handle, 
because you see them right away.

 
 If either of these get checked, an apropriate icon (which could be 
 always the same) would  displayed in that place.

It's usualy difficult enough to convey a single action or state with 
an icon, but trying to combine 4 aspects with all possible combinations?
The only possibility I see are 4 mini icons in the space of one, most 
likely making for a nice pixel salad.

I'm all for icons above the list.


---
Thorsten Wilms
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Thorsten Wilms
On Sat, Jun 25, 2005 at 08:19:16PM -0300, Pedro Kiefer wrote:
 
 I've just made this mockup (attached) of how the locking mechanism
 should appear to the user in the layers tab. But that could be wrong, in
 not really familiar with the GNOME HIG. Clicking in an unlocked lock
 will lock the layer, clicking in a locked lock will unlock it.

I think the lock should be in front of the layer names, right after 
visibility but before chaining, as it will block the later mechanism. 
There should be a third state for chaining, showing the symbol halfway 
faded out or something like that, to indicate it having no effect when 
the layer is locked.

But I'm in doubt if locking is worth the space and additional visual 
complexity. I mean, if you don't want to change the contents of a layer, 
just don't select it. If you manage to draw/edit in the wrong layer, 
there's always undo and you should save frequently anyway.


---
Thorsten Wilms
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] size-pressure relationship has been inverted for airbrush: complaints sought

2005-01-01 Thread Thorsten Wilms
On Fri, Dec 31, 2004 at 08:08:28AM -0800, William Skaggs wrote:
 
 Hi,
 
   I just made a one-line change in cvs head, suggested by Dave Ahlswede,
 that inverts the relationship between pressure and brush size for the 
 airbrush, on the grounds that this more accurately reflects the behavior
 of a real airbrush.  People who use tablets should try it and see if they
 approve, and complain here if they don't.

I can't test that currently, but I imagine it's nice sometimes, 
but will be counterproductive in other cases - I would like to 
have it as an option. And if there should be no option, I would 
prefer the known, not inverted behaviour.

BTW, how about using tilt for a closer airbrush simulation?
That is, not having a fixed shape brush, but a tilt depending 
cone.


---
Thorsten Wilms
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Usability test - Results available

2004-06-12 Thread Thorsten Wilms
I was very thankful for Greg writing somethink like I self 
could have written (allthough with less good and nice wording),
therfor I want to show some support.

On Sat, Jun 12, 2004 at 07:41:49AM -0700, Carol Spears wrote:
 
 i took on a project that no one wanted to do for the gimp.  everyone
 whose opinions i was representing near to the end of this project were
 more important to me than the one or two people who destroyed it.
 
 my project was destroyed (the gimp web site for the users) by a man
 making decisions about what information users need who has, to the best
 of my knowledge, not even on the gimp-user mail list.

I don't see the connection to your recent posts. What gives you the 
right to write such negative, troublemaking, prtly irrational  posts 
(that are extremely hard to parse btw) on a public list?

And you wrote about protecting some people. I wonder who's going to 
protect people from you?
 
 perhaps if you reseached the issues, asked some of the original
 developers what the deal is you would write something both unpleasant
 and factual about me.

Most people wnat to be understood (even by broader audience).
But you require research?

 until then, you are being unpleasant and unfactual.  

Unpleasant and in some way even unfactual was limited to posts
from you Carol, IMHO.


---
Thorsten Wilms
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Usability test - Results available

2004-06-12 Thread Thorsten Wilms
On Sat, Jun 12, 2004 at 09:09:26AM -0700, Carol Spears wrote:

I don't care for your stress and bitterness, especialy 
since you show no understanding for other people in 
your recent posts at all.

I'm not interested in your respect.

I do not have to show contributions, because it's 
you who keeps making noise. Besides devs on many 
lists have an open ear for suggestions and not 
previously answered questions without asking for 
contributions.
Those that do the actual work, AFAIK, are pretty 
relaxed, while you are radiating pure negativity.

RTFM, remember volunteer work, ignorance is all ok 
with me. But even just following the list is not exactly 
fun, because of what you pulled of with Ellen, and 
are continuing in some way here.

And how many people have to ask you to change your ways?
(Even Sven asked you to stop regarding Ellen)

You keep making negative remarks about devs, are 
disrespectful to anyone else.

If you see it as your job to keep people you aparently 
think of as idiots busy, then I know what I have to do 
now. You are the very first person I will filter out 
from mail (you are already the first person receiving 
something personal from me on a list).

Sorry to anyone else, I will shut up now.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Extended tablet functionality

2004-06-03 Thread Thorsten Wilms
Hi!

I recently purchased a Wacom tablet and have been trying to use 
it not only for painting/coloring, but sketching/lineart. 
After some getting used to it control is not that much less 
than working on paper.

But I soon noticed problems with long curves especialy in vertical 
direction. Working analogue I just turn the paper (or alter my own 
position acordingly). Something similar should be possible in the 
digital world ...

Now Painter supports rotating the view without affecting the image, 
and so should the GIMP. There's a bug report here:
http://bugzilla.gnome.org/show_bug.cgi?id=55367

Like stated there I'm willing to provide mockups, but after looking 
at Painter Classic there is not much to mockup.

There should be a tool in toolbox for rotating the view. The icon 
would be an open circle with arrowheads (I offer to provide that 
... are there any guidelines or notes how the existing icons came 
to be?). I think it should be a seperate tool from the existing 
rotate one, because it isn't destructive/undoable.
Rotation would happen by just click-dragging anywhere in the canvas 
area. It could be nice to indicate the rotation center, but it's 
not needed. Resetting to 0 should be possible by clicking on the 
empty canvas area. A doubleclick might also do the trick.

Of course for a fluid workflow there would have to be something 
faster than actualy switching tools. It's just great to have panning 
on middle 'mouse' button (one of the details where GIMP has an 
advantage over PS). Would it be possible to trigger rotation on 
left-drag, when middle button is held down? Else it could work with 
middle button and Ctrl.

View rotation could also be triggered by right-drag on the panning 
tool in the scrollbar corner. Could also have it's own place instead 
of the 'Set canvas padding color' thing. However, in the popup window 
a line would be drawn from the initial pointer location to the actual 
one to indicate center of rotation and pointer location. Ok, something 
to mockup, but not before I hear something positive ...


And now for something else:
Because tablet and monitor aspect ratio don't match, and distortion 
free mapping is needed for serious graphical work, there's always some 
unused tablet area.
Now there are those special fields (new/1, open/2, ...) on larger wacoms 
and special support from the Windows driver. But having to look at the 
tablet is stupid anyway. How about mapping the unused area to a special 
window, that will appear on the screen edge, when the pen is in that 
area? This window could be filled with editable commands and settings.
I bring this up here, because GIMP is the only app with special tablet 
support on Linux (I know of), and the one where I would expect the 
largest benefit from such functionality.


---
Thorsten Wilms
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] scale image/layer UI analysis

2004-05-17 Thread Thorsten Wilms
On Mon, May 17, 2004 at 06:26:16AM +0200, Jakub Steiner wrote:

 * The ratio control has been dropped, since it effectively duplicates the % unit.

I think there should be fields for the aspect ratio (not starting on 1x1 but 
actual values).


 * Print resolution has been removed (discussed at task 6 below)

For me, changing print resolution is an integral part of scaling.
Say you have a scanned image and need to scale it down for a layout.
Print resolution would go up without intervention. Being able to 
restrict it to the highest value that makes sense in one go 
would be a good thing.


The problem I have with the current dialog, or that of PS, is that  
it's hard to understand what will change, when you enter a value 
somewhere.

I think a solution might be to split things up into 3 areas:
- Current values (just output, not editable)
- Target values. Start with empty fields. The user can add target 
values until everything can be determined (left input fields 
will be disabled). Because all possible tasks are realy about 
defining target values, and having feedback about what else 
will change and how (see next one).
- Final values (not editable). The consequences of initilal 
values and target values.

The values are:
- pixel or % width and height
- print width and height
- resolution
- aspect ratio (important for artistic work, giving a work a nice  
shape)


Oh, and finaly Quality/Interpolation should be in the dialog, 
because it's something to decide on per image.


---
Thorsten Wilms
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer