r23340 - Support skinned titlebar for main window

[spr]

That said, I think I have a workable solution. What if I converted the icon and "Forge" part of the title into a button, which, when clicked, would show the menus (besides the current Forge menu) in a single drop down menu as submenus (with the Restart and Exit Forge items being below a separator in that drop down).

If it is compatible with the existing JMenu components then that would be pretty cool.

Cheers,
Steve.

[Diogenes]

That said, I think I have a workable solution. What if I converted the icon and "Forge" part of the title into a button, which, when clicked, would show the menus (besides the current Forge menu) in a single drop down menu as submenus (with the Restart and Exit Forge items being below a separator in that drop down).

I really like this idea. There would have to be a strong visual indication that the logo is in fact a button, but with the navigation tabs it could tie the UI together nicely around the title bar. An over-sized button with an over-sized drop down menu would help tablet users out, and all menus could be easily accessed by mouse without taking up screen-space. As you said, it would also give more personality to Forge's UI.

I really like the idea of "The Forge Button". I'd probably repaint one of my keyboard keys if this happens.

[spr]

If I click the X then the associated action is fired regardless of where my mouse pointer is when I release the button. This means I cannot abort a close. The X should only fire if the mouse down and mouse up events occur with the mouse pointer over X. This is standard behaviour in Windows.

Very minor/cosmetic - the X appears greyish and slightly blurry on my PC. Whereas the minimize and normalize are white.

Cheers,
Steve

[drdev]

Alright, it sounds like the we're going to have a Forge button.

How does everyone feel about making the Alt key open that menu?

spr, I'll go ahead and fix the minimize, maximize, and close buttons to not trigger when the mouse is released outside them. Just a minor oversight in the initial implementation. Also, the reason the X button appears slightly grayish is because I use anti-aliasing to render it, otherwise it looks terrible if its all a single color.

[spr]

How does everyone feel about making the Alt key open that menu?

Check that the ALT key is not being used elsewhere first especially during a match or in combination with the mouse. Also there is a problem with the titlebar on the Mac - viewtopic.php?f=52&t=6333&p=134087#p134077.

Cheers,
Steve

[drdev]

I will check about the Alt key. As for the problem on Mac, I added a comment to the other thread about needing somebody else to investigate since I don't have access to one.

Also, what should I do about the status message support you built into the menu bar? Would it perhaps make sense to add a thin status bar to the bottom of the window, with the status label on the left side and the digital clock on the right side? That might look better than having the clock on the titlebar next to the minimize button anyway, plus you'll then be able to see it even when the titlebar is hidden (though I could support hiding the status bar just like the titlebar, with it then being shown temporarily if you mouse to the bottom of the screen or a status message is set).

I could also put the build info on that bar now that we're splitting off the Forge button. That way, the navigation tabs would start right next to the Forge button. In that case, should the build info be center aligned? Or perhaps center align the status message instead?

[spr]

I will check about the Alt key. As for the problem on Mac, I added a comment to the other thread about needing somebody else to investigate since I don't have access to one.

As far as I am aware there are no Mac developers. When I had similar issues I used a Mac image running in VirtualBox. Suggest you give that a try.

Also, what should I do about the status message support you built into the menu bar? Would it perhaps make sense to add a thin status bar to the bottom of the window, with the status label on the left side and the digital clock on the right side? That might look better than having the clock on the titlebar next to the minimize button anyway, plus you'll then be able to see it even when the titlebar is hidden (though I could support hiding the status bar just like the titlebar, with it then being shown temporarily if you mouse to the bottom of the screen or a status message is set).

Just like a windows application then. I think an auto hide status bar would look wierd. If you are going to display it make it persistent or hidden. If I ever get round to finishing it then it would be useful to display the current download status of card images since it will be designed to run in the background so a status bar-like feature would be handy then. Also as an alternative to displaying tooltips.

I could also put the build info on that bar now that we're splitting off the Forge button. That way, the navigation tabs would start right next to the Forge button. In that case, should the build info be center aligned? Or perhaps center align the status message instead?

I think the Forge Button should contain "Forge" or should be the Forge Icon and oversized a bit like (without the menu) -

I think version info should be shown in the status bar or in an About box accessed via the Forge Button. Or possibly below/in/above the logo on the homepage.

Cheers,
Steve

[drdev]

I'll look into the Virtual Box idea. Otherwise, since you already have it set up, would you mind investigating a bit?

For the Forge button, my plan was just the icon and "Forge".

As for the status bar, I'll try not to have it look like a Windows status bar too much. And you're right that making it show temporarily could be weird, so I'll just make it persistent or hidden based on a toggle switch in the menu and perhaps a keyboard shortcut.

[friarsol]

As for maximize doing full-screen, that's wasn't intentional on my part, but rather a side-effect of using an undecorated JFrame. I thought it was nice if anything, so I called it a feature rather than a bug. If others would prefer the taskbar still be visible when maximized, or at least have that option, I can try out the workaround here. I could then add a full-screen option to the View menu that uses F11 instead of the current behavior of just hiding the titlebar, and that full-screen option could auto-hide the titlebar and we'd have the drop down when mouse at top of screen solution to access it. Though we might want to move the clock in that case.

Did anything ever happen with this? Maximizing still hides my start menu, and if I'm not maximized it's difficult to click the X button. Very frustrating as a very long term dev/user.

[spr]

Did anything ever happen with this? Maximizing still hides my start menu, and if I'm not maximized it's difficult to click the X button. Very frustrating as a very long term dev/user.

Also if the overlay is active (eg. card zoomer, end of game summary, etc) it covers the whole window including the titlebar. This is most noticeable when not maximized.

Also, if debugging and you stop on a breakpoint the main window is completely unresponsive - you cannot move or resize the window at all. This is not the case with the native titlebar and for those of us with a single monitor it is very useful to be able to rearrange stuff on the fly whilst debugging.

Cheers,
Steve

[drdev]

Did anything ever happen with this? Maximizing still hides my start menu, and if I'm not maximized it's difficult to click the X button. Very frustrating as a very long term dev/user.

Also if the overlay is active (eg. card zoomer, end of game summary, etc) it covers the whole window including the titlebar. This is most noticeable when not maximized.

Also, if debugging and you stop on a breakpoint the main window is completely unresponsive - you cannot move or resize the window at all. This is not the case with the native titlebar and for those of us with a single monitor it is very useful to be able to rearrange stuff on the fly whilst debugging.

Cheers,
Steve

I'll look into it. The feedback from full-screen mode has been mostly positive, so I was focusing on the Forge button and allowing the title bar to be revealed when hidden first.

I think what I'm going to do is change F11 to toggle Full-Screen mode (with the menu item being renamed Full-Screen and being moved to the bottom of the Layout menu under Set Window Size) and let the Maximize button just do a normal maximize.

When not in Full-Screen mode (whether maximized or window mode), there will be a button left of the minimize button that also will open Full-Screen mode.

When in Full-Screen mode, the Full-Screen, Minimize, and Restore buttons will be replaced with the clock, a "pin" button that toggles whether the titlebar is locked in position versus hiding unless you mouse to the top of the screen, and an "Exit Full Screen" button.

How does that sound?

[drdev]

Also if the overlay is active (eg. card zoomer, end of game summary, etc) it covers the whole window including the titlebar. This is most noticeable when not maximized.

This is intentional. You shouldn't be able to use the navigation tabs or Forge menu while overlays are active. Since they're all temporary and easily dismissed, that should be a problem. Plus it gives those overlays more space.

[spr]

Also if the overlay is active (eg. card zoomer, end of game summary, etc) it covers the whole window including the titlebar. This is most noticeable when not maximized.

This is intentional. You shouldn't be able to use the navigation tabs or Forge menu while overlays are active. Since they're all temporary and easily dismissed, that should be a problem. Plus it gives those overlays more space.

But you should be able to move the window around using the title bar if not maximized regardless of whether there is an overlay or not. That is what it did previously. The only exeception is if you are displaying a modal dialog. That is just standard windows behaviour.

And what about not being able to move the window around when stepping through code? If you are unable to come up with a solution then please add a (dev) option to temporarily disable the skinned titlebar which you mentioned you were going to look into in an earlier post.

Cheers,
Steve

[drdev]

Ok, fair point. I wasn't thinking about the move behavior during an overlay. I'll see what I can do about preventing the titlebar being covered by overlays.

As for being able to move the window while stepping through code, all you need to do is Shift+Right click on the Forge icon and the taskbar, click Move, and use the arrow keys. I've also just committed a fix so the taskbar isn't hidden when maximized (r23411), so hopefully debugging will be easier on single monitor setups anyway.

[drdev]

spr, friarsol, I've committed several changes to address the issues you've brought up here. Thanks for the input.