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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
