maximizing the stack/card

[Richard Gaskin]

Alex Tweedly wrote:
> Richard Gaskin wrote:
>> What should the desired behavior be?
>>
>> I was unable to find a discussion about handling maximizing properly 
>> in a quick glance at the Win HIG.  Your guidance on where I can find 
>> that would be much appreciated.
>>
> No idea what, if anything, MS's HIG says - but I can tell you what every 
> (*) Windows program I've used in the last 10 years does - it maximizes 
> the window to cover everything except any non-auto-hide taskbar. So if 
> the task bar is set to auto-hide, then the window covers the entire 
> visible screen; if not auto-hide, it covers the complete rectangle which 
> doesn't overlap the task bar.
> 
> (*) every means literally every program I've used except Rev; I'm not 
> aware of

The asterisk is important because it points to the essence of the issue.

Note that I'm not in disagreement on this.  On the contrary, I've gone 
to the mat on this issue with RunRev, so my only point in asking for HIG 
references is to assemble talking points for a stronger argument.

What we have here is a very uncommon UI, and accordingly subsequent 
decisions based on it are equally uncommon:

While the Win HIG describes four radically different window models, it 
offers nothing to suggest having a detached universal toolbar/menubar. 
Of the models MS suggests the closest match is the Project model, but 
even then the menus are attached to the top of each window, not in a 
separate window floating by itself.

Most apps that have a single window for a universal toolbar do so in an 
MDI, but since we don't have MDI parent window classes there's not much 
we can do on that front.  And since MDI is being slowly retired anyway 
I'm not sure we'd want to invest in that at this time.

With Rev, the toolbar is detached and, perhaps more significantly, 
cannot be moved.  So if the windowBoundingRect were not adjusted to 
account for it, it would be too easy to have a document window 
positioned beneath it so that we can't reach the drag bar.

So whether we agree or disagree with the decision, adjusting the top of 
the windowBoundingRect to compensate for the universal toolbar is at 
least understandable (although it does crop the top far more pixels than 
is needed as I had once noted in a Bugzilla report).

But then there's the left-side adjustment, presumably to make room for 
the floating tool palette.  Because such windows are designed to be 
moved in close to where the user is working there should be no need to 
crop the windowBoundingRect for it. There would also be no harm and 
arguably some benefit if the tool window also had a closeBox.

Although these three decisions have mystified me I've been given 
assurances that they are conscious decisions; indeed my Bugzilla 
requests for each of these have long been closed as "Not a bug".

But stepping back to look at the big picture, the only ones risking any 
loss from these decisions are at RunRev, when folks try the product: 
the engine's native settings for the windowBoundingRect work exactly as 
you describe, so your own apps will not be affected by anything the IDE 
does separately from the engine.

As long as the engine gives me the freedom to decide what's right for my 
own apps, I'll leave it to RunRev to make their own decisions for their 
own apps.  Given Rev's unusual role as an IDE that simultaneously 
supports both runtime and development, I'm not sure I'd want to 
completely remove the floating toolbar altogether, and would likely keep 
the top cropping of the windowBoundingRect.

My BZ reports on the other details were more for them than for me, since 
I spend most of my day in the MC IDE which doesn't touch the 
windowBoundingRect (it doesn't touch much really, designed around the 
mantra of "Know the engine, Love the engine, Trust the engine" <g>).

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com