Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-28 Thread Tobias Jakobs 
On Sun, Mar 16, 2008 at 2:31 PM, peter sikking <[EMAIL PROTECTED]> wrote:
> GIMPsters,
>
>  some good news on this front, I have spent a couple of man-days
>  rethinking and re-specifying the 'no image' window situation.
>  It is now roughly complete:
>
I've used Gimp-SVN yesterday to create an black/white image from an
photo to test the NIW. First of all I have to say, that I like it. But
there are some points that feels wrong. I don't know if this are Gimp
or  Windowmanager (Metacity) problems but I hope we can find good
solutions.

Here is my list:
- The close button in the toolbox closes Gimp and not only the
toolbox. The best thing would be to remove the close button compleate.
If that is not possible it would be nice if it would only close the
toolbox. But then we need a way to get the toolbox back.
- If I minimise the last image it would be nice if the toolbox and the
layer window would be hidden too. Or add an way to see the complet
desktop to find images I've placed there.
- Do something with the wilber in the toolbox, I don't know why but I
don't like it there. Perhaps move it in the lower left corner or add
an different background colour.
- It was a little bit annoying to have the layers dialog always on
top. That was something I was a bit astonished about because I always
wanted such a feature. It's that I like to see as much from the image
as possible. To have the toolbox always on top was however very nice.
- And I still don't know if I like it that I have to click twice on
the image close button to quit Gimp. To discover this I need to use
the new UI a little bit more.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-28 Thread David Gowers 
On Fri, Mar 28, 2008 at 5:27 PM, Michael Grosberg
<[EMAIL PROTECTED]> wrote:
>
>
>  > > To give my $0.02, I think Gimp should simply emulate what is out
>  > > there,
>  > > namely the behavior of established applications such as Open Office
>  > > and
>  > > gedit.
>  >
>  > I am really struggling to say something nice here... ah:
>  >
>  > The perfect family car was invented ages ago: the volkwagen beetle.
>  >
>  > That did not stop designer from creating totally different cars for
>  > different needs. And customers from actually buying better cars.
>  >
>  No reason to design a joystick-steered three wheeled car just to be
>  different! Predictability of the UI is a very powerful tool and should
>  not be dismissed. Applications don't work in a vacuum: they are used
>  along with other applications, and asking users to "switch mental gears"
>  when they switch from one app to another for no reason is not a good
>  thing. The developers of those apps have struggled long with exactly the
>  same problems Gimp is trying to solve and have come up with good
>  solutions.
>
>  Case in point: in your specification you state that the application will
>  quit if:
>  "Close in the File menu is invoked and the no image' window is shown"
>  While usually in such cases the close command is grayed out and only the
>  quit command is available. What good reason do you have to change that?
I agree this is difficult. I believe the intent here is to make gimp
more symmetrical, so you can close images, and then you close the
final image (the no-image-window)

>
>  The idea of a window with no document in it is already established. You
>  yourself said "no gimmicks" and yet in the design there's a cute looking
>  wilber in the window's background, which is nice but really, you think
>  without it users won't know what this window is? give users some credit!
>  it's a gimmick and by your own rules should be removed.

I must disagree. It is not a gimmick, because without it, it is
difficult to rapidly identify where to drop. If your window has a
title bar (keep in mind that not all window manager's show a titlebar
attached to the window -- eg the WM I use shows the title of the
window that is currently focused only, at the top of the screen.), the
icon that identifies it as a gimp window is small, and may be obscured
by other windows. Since this window is a DnD target and the user may
want to do multiple drops quickly, it must be identifiable to the user
in  the greatest number of situations. Standard icon+text titlebars do
not provide this.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-27 Thread jbaker 
For the UI team...

I've been watching svn really close the last few days and I know that 
there are a lot of changes coming, (and I really don't know whats 
planned) but I'd thought I would throw out my thoughts so far...

* The "NIW" or main application window...
  o I found myself thinking "Great, now I have another window to
find space for on my desktop... "
+ You can't close it or GIMP closes...
+ It really doesn't make a difference that I can resize
  it small... It still has to be on my desktop...
  o I will personally probably never use the niw drop zone...
mainly because the toolbox is still a drop zone...
  o Working with it the last couple days, I've noticed when I
open nautilus or thunar I really have to move windows in
order to get to the NIW dropzone... in contrast the toolbox
dropzone is usually at the side of a desktop layout - less
movement, it's easier and quicker...
+ Even If I resize the NIW to half the screen and
  nautilus to the other half, I still have to resize the
  image once its open... which is a pain..
  o What would really be nice and make the dropzone a lot more
usable... if there is was a file browser built into it...
split the niw vertically, put a file browser on one side,
and dropzone and whatever else on the other side...
+ With this approach, you could at all times have the
  NIW maximized to the largest size possible...
  o Moving the toolbox menu is a good improvement, and I think
there is talk to reorganize the menu items which would be
good...
  o Another close button when an image is open would be good too...
  o I'm not sure if the plan is to have tabbed images into this
window... If not I bet there will be a million requests for
it...
  o Maybe add a double click feature to the dropzone to
automatically create a new default image (without the prompts)

*The new "Wilber" dropzone area above the toolbox...
  o The entire toolbox widget is a dropzone in itself, why take
up extra space ?
  o When a user grabs an image to drag onto this toolbox area,
they will naturally just head for the center of the
toolbox... Chances are they probably wont specifically
target that tiny area at the top...
  o Some Ideas...
+ Allow the user to remove it if they want
+ Allow the user to specify some other item in that space
  # Maybe a small color selector
  # RGB color input
  # Hex color input
  # Double click to create a new default image

* The main opinion I would like to throw out is to "give the end
  user as much control as possible"... Your right when you say that
  designers keep designing new cars, but the thing is people always
  want to customize the cars they buy...
* For every component and widget in the interface ask yourself "How
  would a user like to customize this"
* Some examples:

+ Come up with docking window framework that allows
  # Any docking window to be docked to another in
any arrangement
  # Multiple levels of nested docks
  # Ability to assign shortcuts to each window
+ Menus
  # Allow the user to create their own menus
  # Allow the user to dock a menu anywhere they
would like...
+ Toolbar
  # Allow the user to create their own toolbars
  # Allow them to dock toolbars anywhere

* Once a good customizable framework has been set up then do some
  studies, graphs, reports, wikis, and meetings to figure out the
  best standard default layout. And if the user wants to change it,
  he/she would have the capability...
* People like to customize, and everybody has their own workflow
  style...

//Cinema 4D by Maxon - www.maxon.net - has an incredible interface 
framework... If you've never messed with it, download the demo and just 
mess with customizing the interface for a while... They have really 
taken the time to give the users ultimate control of their layout and 
workflow, yet at the same time provide a solid standard setup...

Finally, and most important - Thanks for all of your volunteer time... 
There have been some excellent improvements over the last few months 
with GIMP itself and the attitude in the community...

Your work really is appreciated by many people...

jbaker
___

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-27 Thread Vladimir Savic 
peter sikking wrote:
> Michael Grosberg wrote:
> 
>> On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:
>>> check it out when you have the chance.
>> Where can one see the new spec?
> 
> same old place:
> 
> 
> 
> but I actually meant check out the software...
> 
>> To give my $0.02, I think Gimp should simply emulate what is out  
>> there,
>> namely the behavior of established applications such as Open Office  
>> and
>> gedit.
> 
> I am really struggling to say something nice here... ah:
> 
> The perfect family car was invented ages ago: the volkwagen beetle.
> 
> That did not stop designer from creating totally different cars for
> different needs. And customers from actually buying better cars.

Sorry for interruption...

Speaking of the cars... Designers made different types of cars, but 
they've never broken basic principles we all got used to.

Following your analogy: We have serious parking place issues. Currently 
GIMP takes four parking places by default.

I like this kind of interface GIMP uses. I agree that one window per 
image is great thing when you get used to it. My only objection is that 
registering four of them clutters taskbars. Just for the record, I know 
about TAB key and Keep on top settings. :)

Vlada

>  --ps
> 
>  founder + principal interaction architect
>  man + machine interface works
> 
>  http://mmiworks.net/blog : on interaction architecture
> 

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

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-27 Thread peter sikking 
Michael Grosberg wrote:

> On Wed, 2008-03-26 at 20:58 +0100, peter sikking wrote:
>> check it out when you have the chance.
>
> Where can one see the new spec?

same old place:



but I actually meant check out the software...

> To give my $0.02, I think Gimp should simply emulate what is out  
> there,
> namely the behavior of established applications such as Open Office  
> and
> gedit.

I am really struggling to say something nice here... ah:

The perfect family car was invented ages ago: the volkwagen beetle.

That did not stop designer from creating totally different cars for
different needs. And customers from actually buying better cars.

 --ps

 founder + principal interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-26 Thread peter sikking 
hey GIMPsters,

let me give you an update here.

in the last 10 days the concept and spec has matured quite a bit.

the feedback and plain old bug reports, both here and on the IRC
went into what is being built right now.

check it out when you have the chance.

thanks,

 --ps

 founder + principal interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] ‘no image’ window: progre ss...

2008-03-20 Thread Martin Nordholts 
Rick Yorgason wrote:
> Peter Sikking said:
>   
>> Close via the window manager (e.g. close box on the window frame,
>> close on the taskbar) is invoked on an image window
>> 
>
> Here, the spec states that the "close window" button may not actually 
> close the window, if it was the last open window.  There was a little 
> bit of concern over this earlier in the list, both in terms of usability 
> and technical challenges, and I don't think it got sorted out.
>
> It would probably be easiest if the "close window" button always closed 
> the window, regardless of whether that meant closing the image, or 
> quitting the app.
>   
> Since the spirit of the idea is that the last open window is simply 
> reused, would you consider not resizing it?
>
> Those are the only things that jumped out at me.  I don't really agree 
> with all of the usability decisions, but it's not a bad starting point, 
> and I definitely can't wait to see it implemented if it fixes the 
> problem of utility windows not acting like utility windows.

Hello

That a window is not actually closed after the user has clicked the
"close window" button does not pose any techical problems at all. All
sane window systems allow applications to make the final decision of
wether or not to actually close the window. If this would not be the
case it would be impossible to click Cancel on the customary question
"You have unsaved changes in this document/image, do you want to save?".

>From a usability point of view it is quite a brave approach however, but
I think it will work well. Only time will tell.

Note that GIMP trunk already now has a considerable amount of the spec
implemented, so if you manage to compile GIMP from there you can already
now try this out and get a pretty good feel for what the end result will
be like.

BR,
Martin Nordholts

What we call the "no image" window doesn't really matter since that
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer