Re: We should go for a single-window mode in 2.8

View: New views
5 Messages — Rating Filter:   Alert me  

Re: We should go for a single-window mode in 2.8

by Cole-14 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>>/ For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking
/>>/ about: URL.
/>
> Eeek, here is the missing URL:
> http://curlyankles.sourceforge.net/widgets_docking.html

> Alexandre

Hello,

I think the term single-window mode is potentially confusing.  
It's how you dock the windows together that gives the user the
*perceived* single-window or multiple-window mode.

If implemented correctly the user that prefers a multiple-window mode gimp wouldn’t
see much difference from the existing gimp version to a gimp version that supported a
single-window mode.  
Maybe after an install the gimp could start with a window layout (docking schema)
that mirrors the existing multiple-window gimp layout; the user could then dock/group
together whatever undocked/floating/torn (terminology???) window he wanted; therby creating
his own single-window mode gimp.

This was one of the goals I was trying to achieve whilst writing the curlyankles library; as I
could see merits in both multiple and single window layout strategies; without having to tie a
user into either.  How could I know how someone else wanted to work?  

Therfore IMHO if implemented correctly single-window and multiple-window gimp modes
could both coexist together.

Regards
Cole

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

Re: We should go for a single-window mode in 2.8

by peter sikking :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Cole wrote:

> I think the term single-window mode is potentially confusing.
> It's how you dock the windows together that gives the user the
> *perceived* single-window or multiple-window mode.

well, if I have to formulate it, then single-window is users' preference
for a flat working surface, where nothing overlaps. Multi-window is
a staggered environment.

one thing is bugging/intriguing me and that is the (single) point
where single-and multi-window 'lines cross'. That is when one image
is open and for single window toolbox and inspector column(s) have
been torn off.

Forgetting the parade for a moment, single-and multi-window look
the same in that situation. It is tempting to think that from there
users can 'just go in four directions,' by opening a tab, a new window,
docking toolbox or inspector column(s). that is just 3 directions,  
because
exactly docking on a multi-window environment is not a viable route
afaics, docking global stuff to image instances.

But I said "forgetting the parade for a moment" because that exactly
points at the kind of UI optimisation that can be done if it is known
whether a flat or staggered environment is the goal. I'll also be
damned to double a number of menu items because the result could
be a new window or a new tab. this now works automatic according to
the single-window mode setting.

     --ps

         founder + principal interaction architect
             man + machine interface works

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





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

smime.p7s (5K) Download Attachment

Re: We should go for a single-window mode in 2.8

by Jakub Friedl-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Mon, Sep 28, 2009 at 5:56 PM, Cole <cole.anstey@...> wrote:


If implemented correctly the user that prefers a multiple-window mode gimp wouldn’t
see much difference from the existing gimp version to a gimp version that supported a
single-window mode.


Only if I can dock non-GIMP windows there.

Jakub Friedl

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

Re: We should go for a single-window mode in 2.8

by Nathan Summers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Sep 28, 2009 at 11:56 AM, Cole <cole.anstey@...> wrote:

>>>/ For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking
> />>/ about: URL.
> />
>> Eeek, here is the missing URL:
>> http://curlyankles.sourceforge.net/widgets_docking.html
>
>> Alexandre
>
> Hello,
>
> I think the term single-window mode is potentially confusing.
> It's how you dock the windows together that gives the user the
> *perceived* single-window or multiple-window mode.

I'm still thinking GIMP could benefit from Eclipse-style
"perspectives", where which dialogs are visible and which are hidden
are user-defined sets that can be switched between.  The user can then
define which dialogs are useful for certain commonly occurring tasks
and quickly switch between them.  It takes a little getting used to at
first, but once you understand the paradigm you never want to go back
to managing individual windows.

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

Re: We should go for a single-window mode in 2.8

by Jon Cruz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Sep 29, 2009, at 9:40 AM, Nathan Summers wrote:

>
> I'm still thinking GIMP could benefit from Eclipse-style
> "perspectives", where which dialogs are visible and which are hidden
> are user-defined sets that can be switched between.  The user can then
> define which dialogs are useful for certain commonly occurring tasks
> and quickly switch between them.  It takes a little getting used to at
> first, but once you understand the paradigm you never want to go back
> to managing individual windows.

In my personal preference, Eclipse's "perspectives" are an interesting  
idea but one that is implemented somewhat poorly. Even after using it  
for years I still find it a very clumsy and inefficient implementation.

A recent example of some of my bad experience was when I was coding  
and debugging some Java while working on both BIRT and Crystal  
reports. That's four different "perspectives" I had to try to work in.  
The UI gave poor switching and tracking of the current "mode", and  
there were even technical problems where they fought over keys and  
killed shortcuts in each other. Quite painful.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer