Classic Shell: Forum

Classic Start Menu does not take into account results of GetMonitorInfo call properly, rcWork part

http://msdn.microsoft.com/en-us/library/windows/desktop/dd145065(v=vs.85).aspx

Some programs, like Hot Virtual Keyboard http://hot-virtual-keyboard.com/ are able to exclude some parts of the screen from working area.
For an example, if you tie up the virtual keyboard to bottom of the screen - all maximized programs take that into account and do not overlap the virtual keyboard by default.

But that is not applicable to Classic Shell Start menu (see screenshot attached).

It's noncritical issue, it's possible to hide/show virtual keyboard in order to show classic menu properly, but the issue is much wide, because other programs can also exclude parts of the screen from working area, while Classic Shell is not able to handle that properly.

Expected befavior is shown on screenshot which is attached below.
Menu should appear straight above the virtual keyboard: bottom coordinate of menu should be less than rcWork.bottom coordinate, on appropriate screen.

That way works original windows Start menu Windows 7/XP: it does not overlap nonworking part of the screen (does not overlap screen parts which are excluded by something that adjust results of GetMonitorInfo() rcWork).

Can you show a screenshot from Windows 7 or XP?

Also, do sub-menus and tooltips overlap the keyboard? Cause they are not confined to rcWork and can overlap the taskbar.

No, they do not overlap keyboard. Keyborard is top-most window, and that is another issue (Classic Menu, as I presume, should be set as TopMost window and take priority over other windows).
Both menu and tooltips (tooltip over Inkscape in screenshot above) - all are hidden by the Virtual Keyboard, as you can see.

Also please a note, that sending the Virtual keyboard back (below Menu) is not an option - because I still need keyboard to type something in Menu's Search window - having keyboard top-most window is a reasonable choice there, as far as the keyboard declares itself as excluded part of the screen.

So you want the menu to appear above that keyboard or in front of it? (im guessing above)


This would cause some undesirable consequences to some users, and some desirable effects for others, so i would recommend making it optional if you add it IVO.

This is the kind of option that should exist, but at the same time should not clutter the interface , because only a small percentage of users would need it.

(actually this would greatly simplify one of the problems i have previously had : http://www.classicshell.net/forum/viewtopic.php?f=13&t=768, but at the same time it would have caused problems on one of my older settups with rainmeter)

which is why i would recommend adding a .cfg/.txt file to the install directory, with this, and other more specific features. You could even include beta features in the public release this way... (since only true advanced users would likely directly modify a file in the install directory ;P)

No, I'm asking if on Windows 7 or XP the standard start menu (its sub-menus, not the main menu) overlaps the keyboard. I know that it does overlap the taskbar.

His issue isnt the fact that the menu is under the onscreen keyboard. its that the menu isnt on top of the virtual keyboard (the second post i believe is a mockup of what he WANTS it to look like.

As far as the start menu being the topmost' its sort of a fight, both classic shell and the keyboard are trying to be 'topmost' and the keyboard just happens to win..

Here the screenshot of Windows XP. I mislead you a bit, Start Menu overlap Virtual Keyboard there (see Docking Option in Virtual Keyboard settings, that is non-default).

It was a bit unexpected, menu supposed to appead above virtual keyboard, but that's fine because Windows XP does not have Search option in menu,
while Run dialog appears straight above the keyboard, as expected.

...

Sec, I'll prepare Windows 7 screen

Here the Windows 7 one. It looks like I mislead you again - config from scratch shows that Windows 7 still does not allow to type me in Search box using the virtual keyboard.

I solved that somehow, I can't remember how exactly, but Windows 7 showed me Menu straight above the keyboard.
I can't reproduce that right now, I migrated by Tablet to Windows 8 completely, but expected behavior is just like I show in picture #2 - Menu should appear straight above the keyboard.

I'm not talking about just topmost windows. Just try to imagine - how you are supposed to type in Menu's search box, using the virtual keyboard (pen, of fingers) when menu will be just "top topmost" window and will overlap the keyboard?

It's just senseless debate of what has most rights to be topmost there. Proper solution is to divide such windows completely.

After all it could be an option, it you still beleive that Menu should overlap the Keyboard just because Windows XP and Windows 7 did that too.

Apologies if my communication was unclear; I agreed with you that the only way to have both the start menu, and the letters visible, is ensuring there not occupying the same 2 dimensional space...

Also as i said, what is the proper solution in this case, isn't always the proper solution in another, for example with my old desktop, i had the left side of my display reserved for rocket dock, just because i dont want most maximizable programs overlapping my dock, doesn't mean i don't want the start button to do so..., because a flush menu generally looks way better, than one just floating around.


The real issue here, is scope of the problem.. will adding an option to obey desktop work area, cause more confusion(more options means more options every user has to go through, to find the ones there looking for) than its worth.

and how to implement the solution.

From what i can think of, there are 4 possible solutions:


1. (best choice in my opinion) Ivo includes 'offsets' allowing the user to define the position of one of the corners of the start menu. (which i've already requested, even if it cant be monitor specific)
The Pro here is its universal, and less confusing (any user can change the offset, and there menu will move), this would have the widest use, and least confusion in my opinion;
The con however, is this offset would remain, even with whatever program thats changing the desktop work area disabled..

2. Someone modifies the .skin file, to adjust the offset for your specific skin, a somewhat complicated process, that takes about 5 minutes for someone who knows what there doing, and probably around 30 for someone opening a skin for the first time, but with decent computer knowledge
This will solve your personal problem(doing nothing for anyone else, unless they happen to find this thread, have the same resolution, and be using the exact same keyboard program as you)The location must be decided before hand and will be 'hardcoded' into the skin, making it a real hassle to change..

3. (second best choice) Ivo decides to add an option, not to ignore 'desktop work area'
pros; itl work for your case, the menu will even return to its normal position if/when you close the keyboard app

cons; 95% of the people who see the option 'Don't ignore desktop work area' will have no idea what it does, and checking/unchecking it will have no apparent impact for them, they may waste a few minutes each trying to figure out exactly what it changes.. which in most cases will be nothing.. It will also add yet another option that users have to sort through..

Minimizations; if the option were hidden from the 95% it would greatly reduce the confusion and frustration of people not knowing what it does. But the option would still be there, so people with problems could be directed at the sollution (editing a text file in the install directory)

4. (least favorite)Ivo decides to properly implement desktop work area;
pros; in some cases it will be seen as an improvement, 95% of the population goes unaffected
cons; in some cases it will be seen as a problem. A problem that randomly appeared when they updated versions.., which either version-locks them, or leads them to come to the forum for a solution...

If Ivo decides the issue isn't worth addressing, I am willing to help you to make a customized skin that will meet your requirements. (Ill need a little info from you first: your screen resolution, and how many pixels higher you need the bottom corner of the desktop to be), and you should note that you will have to manually switch skins back and forth, when/if you disable the keyboard

The correct behavior is to place the start menu according to the taskbar position and not rcWork. That's because the taskbar can be auto-hide, and then rcWork is the entire screen.
Looks like the keyboard is simply incompatible with start menus. This is more of a problem for the developers of that software. For example the keyboard may be docked to the side, or it can try and automatically move away from the current window.

Starting with Classic Shell 4.2.3, the Start Menu has the ability to move itself, for example, when the Windows 8/8.1 and Windows 10 touch keyboard pops up in the docked state or when the resolution changes (like when you exit a fullscreen game with the Win key).

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.