maximizing the stack/card

[Alex Tweedly]

Richard Gaskin wrote:

> Alex Tweedly wrote:
>
>> 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:
>
It's not that unusual (ok, it's not common - but it's far from unique). 
Framemaker used to do it (it may still do, I haven't used it for years), 
very successfully. GIMP today uses that style.

Both of those examples use "standard" maximize, such that the window in 
question fills the whole screen. Of course, they also both followed the 
Windows convention that you can Alt-TAB between *all* windows, not just 
a subset, so this didn't cause any problem.

> 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.

Ummm - we're talking about MS Windows,  right ?

The menu/tool bar isn't fixed position; I can move my toolbar anywhere I 
want - both on Win-XP and back when I was on Win2000; and also it's not 
full width, so there wouldn't be any problem reaching the drag bar of a 
max'ed window beneath it. In fact, earlier on this thread, I mentioned 
the fact that windowBoundingRect has its top set to be immediately below 
the toolbar - even if that meant that the windowBoundingRect would be 
off screen. That I'm sure is a bad idea; I can see the merit in trying 
to keep the max'ed windows from obscuring the important IDE ones - but 
they should have done the same with the toolbar as they did with the 
floating tool palette - reduce the "max" size to avoid it *if* it's in 
the "expected" place, otherwise ignore it.

>
> 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).

I agree it would make (more) sense if the toolbar were fixed to the top 
of the screen - but it isn't.

> 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>).


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 11/07/2005