Re: Panes vs. Separate Windows

[Ariel Feinerman]

I am glad to know that a lot of people still like multiple windowed UI and
remember Xcode 3 with warm like me. Of course, it is more suitable for
using multiple screens: one window for each screen, or in the case of CAD
-- one screen for model designing window and one for everything else.
However, I should say that we fell into the  other problem: how to separate
windows from several opened projects when we need?


On Wed, Jan 13, 2016 at 7:00 PM, Dave  wrote:

>
> > On 11 Jan 2016, at 23:10, Charles Srstka 
> wrote:
> >
> > My favorite thing in Xcode is the way that Interface Builder stuffs the
> entire object library into that tiny little space in the lower-right corner
> of the screen. Way back in Xcode 3 (or whenever it was that IB was a
> separate app), the floating palette that they had for the object library
> let you browse through the UI elements, see what was there, and discover
> new widgets as they were added to new OS releases. They were even grouped
> into categories, if I’m remembering correctly. Now? Searching for the
> element you want is the only halfway effective way to use it at all. And
> then, of course, if you have it visible at all, it clutters up your code
> editor when you switch to a source file.
>
> Yes, it’s IB that is the most out of place being made to fit in with a UI
> design that just doesn’t suit this style of tool. The situation is even
> worse now we have auto layout. Its obvious to be anyway that IB really does
> need to implemented using specialised windows designed specially towards UI
> layout, not forced into a bloated out window that is designed around
> editing, maintaining and compiling source files and managing project
> settings.
>
> Dave
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/arielfapple%40gmail.com
>
> This email sent to arielfap...@gmail.com
>



-- 
best regards
Ariel
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Dave]

> On 11 Jan 2016, at 16:15, Alex Zavatone  wrote:
> 
> Way back in the mid '90s, there was some double click tool that simply felt 
> like the holy grail to me.
> 
> You double clicked or option clicked on the title of a window and it would 
> turn that window into the "floating windoid" title bar only.  We took this 
> model and made it so that when you collapsed a window in that manner, it 
> moved the tiny title bar up below the last one you collapsed. When restored, 
> it resumed its previous position.  
> 
> This way, you could see all of of your windows and hide and retrieve them in 
> an instant.  And they only took up a small and organized portion of the 
> screen when collapsed.
> 
> I loved it.  I was simple, fast, organized and remembered how you positioned 
> things previously.

Yes, it was really good tool. Also the way in which CodeWarrior handled windows 
in general was developer heaven and sooo much better than XCode. 

XCode seems to suffer from alzheimer’s when it comes to remembering things like 
window positions, the annoying thing is, it *used* to remember them nicely in 
XCode 3, sigh…….

 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Dave]

> On 11 Jan 2016, at 23:10, Charles Srstka  wrote:
> 
> My favorite thing in Xcode is the way that Interface Builder stuffs the 
> entire object library into that tiny little space in the lower-right corner 
> of the screen. Way back in Xcode 3 (or whenever it was that IB was a separate 
> app), the floating palette that they had for the object library let you 
> browse through the UI elements, see what was there, and discover new widgets 
> as they were added to new OS releases. They were even grouped into 
> categories, if I’m remembering correctly. Now? Searching for the element you 
> want is the only halfway effective way to use it at all. And then, of course, 
> if you have it visible at all, it clutters up your code editor when you 
> switch to a source file.

Yes, it’s IB that is the most out of place being made to fit in with a UI 
design that just doesn’t suit this style of tool. The situation is even worse 
now we have auto layout. Its obvious to be anyway that IB really does need to 
implemented using specialised windows designed specially towards UI layout, not 
forced into a bloated out window that is designed around editing, maintaining 
and compiling source files and managing project settings.

Dave

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Dave]

> On 11 Jan 2016, at 21:06, Lee Ann Rucker  wrote:
> 
> 
>> On Jan 11, 2016, at 7:35 AM, Jim Lee  wrote:
>> 
>> We have an application, TopXNotes that allows multiple “documents” (notes) 
>> to be opened in adjacent views (panes). The notes can be edited 
>> individually. One can cut/paste/copy from any text document to/from a 
>> seperate text app, or from pane to pane. Just one example of something 
>> different that I hope fits into the parameters of this discussion. TopXNotes 
>> 2 (now in beta) adds “Open in Seperate Window” as an option that addresses 
>> that “best of both worlds" concept.  
>> 
>> Personally, I have never lilked the way Photoshop implements their extra 
>> panes because I have never been a fan of the inspector, but that is just me. 
>> On the other hand, I like the way Apple has implemented its multiple views 
>> approach in Xcode. Before apple did that there were just way too many 
>> windows jumping around and opening in seeming random oirder at random times. 
>> Now I get some CUI as things appear almost always where expected.  
> 
> I have the opposite impression of Xcode - before, if I had related source 
> files opened in particular windows, those windows kept showing those files no 
> matter what I did. Now, randomly, the windows will show what Xcode thinks is 
> related content, or the debugger, or some other file I happened to 
> double-click... I didn't mind having 50 windows open, the Windows menu 
> managed that nicely. 
> 
> Not to prompt another round of Xcode bashing, just to point out that no 
> system is going to make everyone happy, so go for the most flexible one if 
> you can.

XCode 3 catered for both the separate window approach and one giant clunker via 
a preference……



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Dave]

> On 12 Jan 2016, at 03:56, Greg Weston  wrote:
> 
>> (I also don’t want to restart Xcode wars, but I do actually believe that the 
>> unified window style that arrived in Xcode 4 was an actual decision about 
>> which worked best, made by clever people who actually thought about it. It 
>> wasn’t — I believe — merely clueless. I also want to point out that Xcode 3 
>> was *hugely* criticized for its window bloat.)
> 
> For what it's worth, I felt like the changes to Xcode over the last few 
> versions were most likely motivated by the notion that Xcode should 
> superficially mimic Eclipse.
> 
> I loathe Eclipse.
> 
> I barely write for Apple platforms any more, and in all honesty Xcode is a 
> non-trivial part of that.

I know, XCode is horrid, however with 5 mins worth of setup you can make it 
more bearable and almost usable with separate windows. If you’d like to know 
how I’ve set it up, give me a shout off list and I’ll send you the details.

Cheers
Dave


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Marco S Hyman]

> My reasoning is that if you make it inflexible, you risk getting (say) 50% 
> lovers and 50% haters. If you make it flexible, you risk getting 40% lovers 
> and 40% haters, and 20% people who are annoyed because it’s too flexible or 
> too complicated. That’s a net loss in satisfaction.

I think you can make a UI flexible without annoying too many people.  Example: 
start with one window with panes that can be toggle on-off a la Xcode. Now make 
the panes repositionable. That shouldn’t upset people too much, especially if 
you add a “restore default window layout” option in a menu.   Finally allow a 
pane to be dragged outside of the main window to form a new window.  For the 
finishing touch allow a pane to be dragged to an existing window.

The complexity is hidden for those that don’t want it.  The hard part is how to 
document operation without overwhelming those who are happy with the most basic 
of operations.

Marc
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Quincey Morris]

On Jan 11, 2016, at 13:06 , Lee Ann Rucker  wrote:
> 
> no system is going to make everyone happy, so go for the most flexible one if 
> you can

I’d like to advocate the opposite point of view: no system is going to make 
everyone happy, so go for the the one that works best.

(Yes, I understand what’s wrong with that statement.)

My reasoning is that if you make it inflexible, you risk getting (say) 50% 
lovers and 50% haters. If you make it flexible, you risk getting 40% lovers and 
40% haters, and 20% people who are annoyed because it’s too flexible or too 
complicated. That’s a net loss in satisfaction.

(Yes, I understand what’s wrong with that statement, too.)

My point is philosophical. You’re the developer. You’re supposed to know what 
works best for your app. If you haven’t decided yet, then your job isn’t done.

(I also don’t want to restart Xcode wars, but I do actually believe that the 
unified window style that arrived in Xcode 4 was an actual decision about which 
worked best, made by clever people who actually thought about it. It wasn’t — I 
believe — merely clueless. I also want to point out that Xcode 3 was *hugely* 
criticized for its window bloat.)

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Charles Srstka]

My favorite thing in Xcode is the way that Interface Builder stuffs the entire 
object library into that tiny little space in the lower-right corner of the 
screen. Way back in Xcode 3 (or whenever it was that IB was a separate app), 
the floating palette that they had for the object library let you browse 
through the UI elements, see what was there, and discover new widgets as they 
were added to new OS releases. They were even grouped into categories, if I’m 
remembering correctly. Now? Searching for the element you want is the only 
halfway effective way to use it at all. And then, of course, if you have it 
visible at all, it clutters up your code editor when you switch to a source 
file.

UI design at its best.

Charles

> On Jan 11, 2016, at 2:27 PM, Carl Hoefs  
> wrote:
> 
> FWIW, I find it odd that so many apps these days seem to be following Xcode's 
> "lead", if you want to call it that. I still miss Xcode 3.2.6 because I could 
> configure it for the way *I* was most productive. Now you gotta use that 
> ginormous "plate" window. It shows you what it wants to show you when it 
> wants to show it to you, and enforces a sort of implicit multiple exclusion 
> among the various views.
> 
> If you're an OmniGraffle user (a flowchart/design app), you'll notice that in 
> the lastest release they also changed over from the infinitely more usable 
> multiple floating windows design to one ginormous clunker of a main window. 
> Ugh. Maybe it's a trend toward one-dimensional thinking? 
> 
> For CAD I can't imagine how a single large window would be best. Most often 
> you're using multiple screens, and it's best to break up the windows into 
> logical groups. CAD on a laptop is an exercise in futility.
> 
> -Carl
> 
>> On Jan 11, 2016, at 12:54 PM, Rick Mann  wrote:
>> 
>> I'm pleased to see so many in favor of multiple windows. It seems the 
>> arguments in favor of a single monolithic window hinge smaller screens. But 
>> I find that monolithic windows require larger screens (and can't share 
>> screens). The thing about separate windows is they can overlap and still be 
>> useful, increasing available screen space.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40charlessoft.com
> 
> This email sent to cocoa...@charlessoft.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Matt Reagan]

> If you make it flexible, you risk getting 40% lovers and 40% haters, and 20% 
> people who are annoyed because it’s too flexible or too complicated. That’s a 
> net loss in satisfaction.

How about: 40% lovers, 40% haters, and 20% people who *are initially frustrated 
by the complexity, and then take a few minutes to learn how to leverage its 
power / flexibility.

That is most definitely a net *gain*.

This is the thing that is personally upsetting to me about this simplification 
trend in modern software, it's the idea that all users should be treated like 
children. There is a balance between simplicity/usability and flexibility/power 
to be found, and I think a lot of software these days veers way off the mark.

Of course as an abstract philosophy there's always scenarios in which providing 
a flexible system isn't worth the frustration it will cause with its learning 
curve, but Xcode is a perfect example of when this is _not_ the case (IMO); 
Xcode users should generally be expected to be reasonably intelligent folks who 
are willing to learn a tool's nuances if that means it will improve their 
workflow / development efficiency.

-Matt

> On Jan 11, 2016, at 2:17 PM, Quincey Morris 
>  wrote:
> 
> On Jan 11, 2016, at 13:06 , Lee Ann Rucker  wrote:
>> 
>> no system is going to make everyone happy, so go for the most flexible one 
>> if you can
> 
> I’d like to advocate the opposite point of view: no system is going to make 
> everyone happy, so go for the the one that works best.
> 
> (Yes, I understand what’s wrong with that statement.)
> 
> My reasoning is that if you make it inflexible, you risk getting (say) 50% 
> lovers and 50% haters. If you make it flexible, you risk getting 40% lovers 
> and 40% haters, and 20% people who are annoyed because it’s too flexible or 
> too complicated. That’s a net loss in satisfaction.
> 
> (Yes, I understand what’s wrong with that statement, too.)
> 
> My point is philosophical. You’re the developer. You’re supposed to know what 
> works best for your app. If you haven’t decided yet, then your job isn’t done.
> 
> (I also don’t want to restart Xcode wars, but I do actually believe that the 
> unified window style that arrived in Xcode 4 was an actual decision about 
> which worked best, made by clever people who actually thought about it. It 
> wasn’t — I believe — merely clueless. I also want to point out that Xcode 3 
> was *hugely* criticized for its window bloat.)
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mreagan2652%40gmail.com
> 
> This email sent to mreagan2...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Greg Weston]

> (I also don’t want to restart Xcode wars, but I do actually believe that the 
> unified window style that arrived in Xcode 4 was an actual decision about 
> which worked best, made by clever people who actually thought about it. It 
> wasn’t — I believe — merely clueless. I also want to point out that Xcode 3 
> was *hugely* criticized for its window bloat.)

For what it's worth, I felt like the changes to Xcode over the last few 
versions were most likely motivated by the notion that Xcode should 
superficially mimic Eclipse.

I loathe Eclipse.

I barely write for Apple platforms any more, and in all honesty Xcode is a 
non-trivial part of that.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Lee Ann Rucker]

> On Jan 11, 2016, at 7:35 AM, Jim Lee  wrote:
> 
> We have an application, TopXNotes that allows multiple “documents” (notes) to 
> be opened in adjacent views (panes). The notes can be edited individually. 
> One can cut/paste/copy from any text document to/from a seperate text app, or 
> from pane to pane. Just one example of something different that I hope fits 
> into the parameters of this discussion. TopXNotes 2 (now in beta) adds “Open 
> in Seperate Window” as an option that addresses that “best of both worlds" 
> concept.  
> 
> Personally, I have never lilked the way Photoshop implements their extra 
> panes because I have never been a fan of the inspector, but that is just me. 
> On the other hand, I like the way Apple has implemented its multiple views 
> approach in Xcode. Before apple did that there were just way too many windows 
> jumping around and opening in seeming random oirder at random times. Now I 
> get some CUI as things appear almost always where expected.  

I have the opposite impression of Xcode - before, if I had related source files 
opened in particular windows, those windows kept showing those files no matter 
what I did. Now, randomly, the windows will show what Xcode thinks is related 
content, or the debugger, or some other file I happened to double-click... I 
didn't mind having 50 windows open, the Windows menu managed that nicely. 

Not to prompt another round of Xcode bashing, just to point out that no system 
is going to make everyone happy, so go for the most flexible one if you can.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Gary L. Wade]

I've seen an advantage to having "attached palettes" like Xcode's Utilities 
pane. When set up like this, I can see unique attributes per window and compare 
two separate documents. When there's only one shared all over the place, it 
might be harder at times to get context at a glance. An example I've 
encountered recently that may be just an Xcode bug/oddity is the color palette 
used in choosing "Other" colors, in that it can become a bit disconnected if 
you deselect a color object. In my opinion, the color palette is a great 
candidate for use in a popover.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Jan 11, 2016, at 11:54 AM, Rick Mann  wrote:
> 
> I'm pleased to see so many in favor of multiple windows. It seems the 
> arguments in favor of a single monolithic window hinge smaller screens.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Carl Hoefs]

FWIW, I find it odd that so many apps these days seem to be following Xcode's 
"lead", if you want to call it that. I still miss Xcode 3.2.6 because I could 
configure it for the way *I* was most productive. Now you gotta use that 
ginormous "plate" window. It shows you what it wants to show you when it wants 
to show it to you, and enforces a sort of implicit multiple exclusion among the 
various views.

If you're an OmniGraffle user (a flowchart/design app), you'll notice that in 
the lastest release they also changed over from the infinitely more usable 
multiple floating windows design to one ginormous clunker of a main window. 
Ugh. Maybe it's a trend toward one-dimensional thinking? 

For CAD I can't imagine how a single large window would be best. Most often 
you're using multiple screens, and it's best to break up the windows into 
logical groups. CAD on a laptop is an exercise in futility.

-Carl

> On Jan 11, 2016, at 12:54 PM, Rick Mann  wrote:
> 
> I'm pleased to see so many in favor of multiple windows. It seems the 
> arguments in favor of a single monolithic window hinge smaller screens. But I 
> find that monolithic windows require larger screens (and can't share 
> screens). The thing about separate windows is they can overlap and still be 
> useful, increasing available screen space.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Charles Jenkins]

Interesting that so many others like the multiwindow approach. I’ve always 
thought that a horrible design, because you constantly have to fool with them 
to get them out of the way as you work on a document. I like the approach taken 
by Photoshop, where you can dock them them together in the layout that’s most 
effective for you, then mark some columns as being pinned open while others can 
collapse when not in use.

I have Photoshop 5.5 or 6 and love the interface, but because I didn’t want to 
subscribe to Creative Cloud, I try to do photo stuff in other programs as much 
as possible—to get comfortable with other products so it’s not tempting to use 
PS every time. Initially I tried to do as much as possible in Pixelmator, but 
having tool windows scattered all over the place drove me crazy; now I’m using 
Affinity Photo, and the docked toolwindows are a major reason why.

-- 

Charles

On January 9, 2016 at 17:21:14, Rick Mann (rm...@latencyzero.com) wrote:

In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
windows. The trend in UI at Apple has been to consolidate these into panes in a 
single window. I've always preferred separate windows (e.g. separate toolbar 
window).

One more concrete example is in a CAD program: the objects in the document are 
often related to each other hierarchically. There's usually a view of this 
hierarchy using something like an outline table. I can see this naturally 
fitting as either a pane in a split view, or as a separate window. Best of both 
worlds, I suppose, would be a dockable window (a window that can be separate, 
or live as a pane in a split view), but that might be a lot of additional 
coding (is there a nice library that offers this?).

Complicating matters is whether or not each open document shares a single 
instance of these auxiliary windows or has its own. I think something like a 
tool palette is clearly shared (it's more app-global then per-document), but 
the model object hierarchy window is probably per-document.f

Separate windows have tremendous advantages, but I think panes are considered 
more "simple." Simplicity has advantages, but we're talking about complex apps 
that by their nature demand more of their users than something like iPhoto.

Thoughts?


--  
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/cejwork%40gmail.com

This email sent to cejw...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Alex Zavatone]

Way back in the mid '90s, there was some double click tool that simply felt 
like the holy grail to me.

You double clicked or option clicked on the title of a window and it would turn 
that window into the "floating windoid" title bar only.  We took this model and 
made it so that when you collapsed a window in that manner, it moved the tiny 
title bar up below the last one you collapsed. When restored, it resumed its 
previous position.  

This way, you could see all of of your windows and hide and retrieve them in an 
instant.  And they only took up a small and organized portion of the screen 
when collapsed.

I loved it.  I was simple, fast, organized and remembered how you positioned 
things previously.

On Jan 11, 2016, at 9:57 AM, Dave wrote:

> 
>> On 9 Jan 2016, at 22:19, Rick Mann  wrote:
>> 
>> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
>> windows. The trend in UI at Apple has been to consolidate these into panes 
>> in a single window. I've always preferred separate windows (e.g. separate 
>> toolbar window).
> 
> Yes,  separate windows definitely much better IMO. I think the trend towards 
> one big window has been adopted on the Mac because of the iPad/iOS. This is 
> silly IMO because iPad’s only have one screen but on a Mac you can have lots 
> of screens - I have 4 on my main development machine and having one big 
> window is a real pain. I would have thought that for CAD/CAM and Photoshop 
> type apps, most people would be using multiple monitors these days, so I’d go 
> with the separate windows based on that assumption with maybe the option to 
> dock them……
> 
> Cheers
> Dave
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Jim Lee]

We have an application, TopXNotes that allows multiple “documents” (notes) to 
be opened in adjacent views (panes). The notes can be edited individually. One 
can cut/paste/copy from any text document to/from a seperate text app, or from 
pane to pane. Just one example of something different that I hope fits into the 
parameters of this discussion. TopXNotes 2 (now in beta) adds “Open in Seperate 
Window” as an option that addresses that “best of both worlds" concept.  

Personally, I have never lilked the way Photoshop implements their extra panes 
because I have never been a fan of the inspector, but that is just me. On the 
other hand, I like the way Apple has implemented its multiple views approach in 
Xcode. Before apple did that there were just way too many windows jumping 
around and opening in seeming random oirder at random times. Now I get some CUI 
as things appear almost always where expected.  

Having stated my opinion, we did add one inspector-like Info pane as a separate 
window to TopXNotes.

Anyone who would liek a copy of TopXNotes 1 or the 2.- beta when it is redy 
(soon) please feel free to contact me. I would value feedback that we might be 
able to use for the next version. Along those lines there is a free download of 
the trial version. I am not posting a link because it might not be kosher, but 
I hope this is OK to discuss here.

Cheers, 

Cheers, 
James Lee

> On Jan 11, 2016, at 7:45 AM, Charles Jenkins  wrote:
> 
> Interesting that so many others like the multiwindow approach. I’ve always 
> thought that a horrible design, because you constantly have to fool with them 
> to get them out of the way as you work on a document. I like the approach 
> taken by Photoshop, where you can dock them them together in the layout 
> that’s most effective for you, then mark some columns as being pinned open 
> while others can collapse when not in use.
> 
> I have Photoshop 5.5 or 6 and love the interface, but because I didn’t want 
> to subscribe to Creative Cloud, I try to do photo stuff in other programs as 
> much as possible—to get comfortable with other products so it’s not tempting 
> to use PS every time. Initially I tried to do as much as possible in 
> Pixelmator, but having tool windows scattered all over the place drove me 
> crazy; now I’m using Affinity Photo, and the docked toolwindows are a major 
> reason why.
> 
> -- 
> 
> Charles
> 
> On January 9, 2016 at 17:21:14, Rick Mann (rm...@latencyzero.com) wrote:
> 
> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
> windows. The trend in UI at Apple has been to consolidate these into panes in 
> a single window. I've always preferred separate windows (e.g. separate 
> toolbar window).
> 
> One more concrete example is in a CAD program: the objects in the document 
> are often related to each other hierarchically. There's usually a view of 
> this hierarchy using something like an outline table. I can see this 
> naturally fitting as either a pane in a split view, or as a separate window. 
> Best of both worlds, I suppose, would be a dockable window (a window that can 
> be separate, or live as a pane in a split view), but that might be a lot of 
> additional coding (is there a nice library that offers this?).
> 
> Complicating matters is whether or not each open document shares a single 
> instance of these auxiliary windows or has its own. I think something like a 
> tool palette is clearly shared (it's more app-global then per-document), but 
> the model object hierarchy window is probably per-document.f
> 
> Separate windows have tremendous advantages, but I think panes are considered 
> more "simple." Simplicity has advantages, but we're talking about complex 
> apps that by their nature demand more of their users than something like 
> iPhoto.
> 
> Thoughts?
> 
> 
> --  
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/cejwork%40gmail.com
> 
> This email sent to cejw...@gmail.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jim%40tropic4.com
> 
> This email sent to j...@tropic4.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your 

Re: Panes vs. Separate Windows

[Alex Zavatone]

On Jan 11, 2016, at 2:17 AM, Britt Durbrow wrote:

> My preference would be multiple windows (one primary document window and 
> several utility panel windows) that can be snapped into place against each 
> other. This gives the freedom to use multiple monitors while also having the 
> screen-real-estate efficiency that a single-window approach would. (FWIW, I’m 
> typing this on a 27” 2560x1440 Acer LCD connected to a 13” Retina MBP; both 
> displays are active at the moment).
> 
> I find that as the problem space that the app is trying to solve becomes more 
> complex, the all-in-one approach that is being pushed by the 
> “full-screen-window” model gets too inflexible.

Back when Macromedia tried to do this what I noticed was that there never is a 
perfect fit when trying to force everything into one window.  There always is 
unused space or not enough space.

Xcode seems to do a pretty good job with this, in its layout but I always end 
up with as many windows as I want and just command ~ or command-shift ~ through 
them to get to the ones that I set up the way I want.

But the joy of setting up multiple inspectors or a shared inspector is 
restoring the shared inspector to what the user set it to and where they 
positioned it whenever the user changes the source of the inspector.  

It always ends up being quite annoying when you set up your inspector position, 
then switch to something else, resize the inspector and reposition it and then 
go back to your other source and find that the inspector doesn't remember the 
position you had put it in.

Lovely little details.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Rick Mann]

I'm pleased to see so many in favor of multiple windows. It seems the arguments 
in favor of a single monolithic window hinge smaller screens. But I find that 
monolithic windows require larger screens (and can't share screens). The thing 
about separate windows is they can overlap and still be useful, increasing 
available screen space.

Remember before windowed user interfaces, when each app controlled the entire 
screen?

As to whether or not there should be a single instance or a shared instance 
(that presumably changes its content based on the frontmost document window), I 
think a guiding principle should be whether or not you need to drag from one to 
another.

For example, the object hierarchy of a CAD program, it seems entirely 
reasonable to want to grab a part from one and drag it to another (or to a 
graphical view, or vice-versa).

Windows uses copy-and-paste a lot more than drag and drop because multiple 
windows are so hard to use on that OS. Drag-and-drop was traditionally much 
more fluid on Mac OS, although I frequently run into situations where it'd 
harder to use now because of monolithic windows (for example, I can't as easily 
drag a file from the finder to the Xcode Files & Groups list, because it's part 
of a ginormous window that obscures all the Finder windows).

Anyway, I think I'll just proceed with a multiwindow approach, and later see if 
I can't modify that to make them dockable into the the main document window.

> On Jan 11, 2016, at 08:15 , Alex Zavatone  wrote:
> 
> Way back in the mid '90s, there was some double click tool that simply felt 
> like the holy grail to me.
> 
> You double clicked or option clicked on the title of a window and it would 
> turn that window into the "floating windoid" title bar only.  We took this 
> model and made it so that when you collapsed a window in that manner, it 
> moved the tiny title bar up below the last one you collapsed. When restored, 
> it resumed its previous position.  
> 
> This way, you could see all of of your windows and hide and retrieve them in 
> an instant.  And they only took up a small and organized portion of the 
> screen when collapsed.
> 
> I loved it.  I was simple, fast, organized and remembered how you positioned 
> things previously.
> 
> On Jan 11, 2016, at 9:57 AM, Dave wrote:
> 
>> 
>>> On 9 Jan 2016, at 22:19, Rick Mann  wrote:
>>> 
>>> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
>>> windows. The trend in UI at Apple has been to consolidate these into panes 
>>> in a single window. I've always preferred separate windows (e.g. separate 
>>> toolbar window).
>> 
>> Yes,  separate windows definitely much better IMO. I think the trend towards 
>> one big window has been adopted on the Mac because of the iPad/iOS. This is 
>> silly IMO because iPad’s only have one screen but on a Mac you can have lots 
>> of screens - I have 4 on my main development machine and having one big 
>> window is a real pain. I would have thought that for CAD/CAM and Photoshop 
>> type apps, most people would be using multiple monitors these days, so I’d 
>> go with the separate windows based on that assumption with maybe the option 
>> to dock them……
>> 
>> Cheers
>> Dave
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Britt Durbrow]

My preference would be multiple windows (one primary document window and 
several utility panel windows) that can be snapped into place against each 
other. This gives the freedom to use multiple monitors while also having the 
screen-real-estate efficiency that a single-window approach would. (FWIW, I’m 
typing this on a 27” 2560x1440 Acer LCD connected to a 13” Retina MBP; both 
displays are active at the moment).

I find that as the problem space that the app is trying to solve becomes more 
complex, the all-in-one approach that is being pushed by the 
“full-screen-window” model gets too inflexible.

As for the single-instance vs. multiple-instance auxiliary windows issue; to a 
certain extent it depends on the work-flow of the app. If there are common use 
cases where seeing data from two documents at once is useful, then they should 
be per-document; otherwise I generally prefer a shared inspector palette model.


Background: I’m currently working on two CAD applications, and a GIS system.

> On Jan 9, 2016, at 2:19 PM, Rick Mann  wrote:
> 
> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
> windows. The trend in UI at Apple has been to consolidate these into panes in 
> a single window. I've always preferred separate windows (e.g. separate 
> toolbar window).
> 
> One more concrete example is in a CAD program: the objects in the document 
> are often related to each other hierarchically. There's usually a view of 
> this hierarchy using something like an outline table. I can see this 
> naturally fitting as either a pane in a split view, or as a separate window. 
> Best of both worlds, I suppose, would be a dockable window (a window that can 
> be separate, or live as a pane in a split view), but that might be a lot of 
> additional coding (is there a nice library that offers this?).
> 
> Complicating matters is whether or not each open document shares a single 
> instance of these auxiliary windows or has its own. I think something like a 
> tool palette is clearly shared (it's more app-global then per-document), but 
> the model object hierarchy window is probably per-document.f
> 
> Separate windows have tremendous advantages, but I think panes are considered 
> more "simple." Simplicity has advantages, but we're talking about complex 
> apps that by their nature demand more of their users than something like 
> iPhoto.
> 
> Thoughts?
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Alex Zavatone]

On Jan 9, 2016, at 5:19 PM, Rick Mann wrote:

> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
> windows. The trend in UI at Apple has been to consolidate these into panes in 
> a single window. I've always preferred separate windows (e.g. separate 
> toolbar window).

Same here. I strongly prefer separate windows that I have control over.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Bill Cheeseman]

> On Jan 10, 2016, at 8:41 AM, Alex Zavatone  wrote:
> 
> On Jan 9, 2016, at 5:19 PM, Rick Mann wrote:
> 
>> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
>> windows. The trend in UI at Apple has been to consolidate these into panes 
>> in a single window. I've always preferred separate windows (e.g. separate 
>> toolbar window).
> 
> Same here. I strongly prefer separate windows that I have control over.

Me, too. However, I see the handwriting on the wall and I am in the process of 
revising my primary product to follow the new paradigm as much as possible -- 
and to convert my beloved drawers to panes in the process.

However, I have a number of separate, single-purpose windows that are used only 
rarely, and I can't figure out a good way to incorporate them into the main 
window without turning my product into an ugly, too-complex, single-window 
monstrosity like Xcode.

The only alternative to separate utility windows that I see on the current 
landscape is popovers, but it seems like popovers shouldn't be allowed to get 
too large or too numerous. Popovers do have one big advantage, from my point of 
view -- you can compromise with Apple's new paradigm by allowing them to be 
detached into separate windows when you want to have several of them open at 
once for interaction.

I there any alternative better than popovers for this?

-- 

Bill Cheeseman - wjcheese...@comcast.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Panes vs. Separate Windows

[Rick Mann]

In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
windows. The trend in UI at Apple has been to consolidate these into panes in a 
single window. I've always preferred separate windows (e.g. separate toolbar 
window).

One more concrete example is in a CAD program: the objects in the document are 
often related to each other hierarchically. There's usually a view of this 
hierarchy using something like an outline table. I can see this naturally 
fitting as either a pane in a split view, or as a separate window. Best of both 
worlds, I suppose, would be a dockable window (a window that can be separate, 
or live as a pane in a split view), but that might be a lot of additional 
coding (is there a nice library that offers this?).

Complicating matters is whether or not each open document shares a single 
instance of these auxiliary windows or has its own. I think something like a 
tool palette is clearly shared (it's more app-global then per-document), but 
the model object hierarchy window is probably per-document.f

Separate windows have tremendous advantages, but I think panes are considered 
more "simple." Simplicity has advantages, but we're talking about complex apps 
that by their nature demand more of their users than something like iPhoto.

Thoughts?


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Panes vs. Separate Windows

[Jerry Krinock]

> On 2016 Jan 09, at 14:19, Rick Mann  wrote:
> 
> Thoughts?

You could argue this both ways until the cows come home, but here is one 
thought:

I think the recent move toward one big window, like the move toward full-screen 
apps, has been advanced by the increased prevalance of laptops, with their 
smaller screens.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com