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