Borderless

[luckydonald]

I don’t like the window borders.

This is some idea which occurred me.

[luckydonald]

hm it included d2db761, from #26.

[luckydonald]

It just looks so much better on the desktop.

Windows:

The sidebar is where to drag that window.
If you wanna close it, you can still use the menu or hotkeys.

[rgbkrk]

That's much better, especially on Windows. I'm running the app on a Mac so I wasn't paying much attention to it.

Thanks again @luckydonald! I've also made you a member of RobCoIndustries. Welcome!

[rgbkrk]

Since I already merged the other PR, this will just bring the one commit in. You'll want to make sure to start new branches off master next time. No big deal though!

[luckydonald]

I've also made you a member of RobCoIndustries. Welcome!

Thank you

[luckydonald]

Strange, the members page doesn't list me.

[rgbkrk]

You'll have to accept the invitation by visiting https://github.com/RobCoIndustries.

[luckydonald]

Oh, on top it was! I scrolled past it each and every time.
Funfact: I don't even know how to node.js.
I am more a python/django guy.
But 'eh. Here we go, lol.
(I am tempted to throw in the term 'YOLO'.)

[rgbkrk]

Thanks for maximize! This is nice - I'm back home and free to play+code now.

[rgbkrk]

Belated feedback (can become new issues or ignored 😉):

• The fullscreen selection should change how it appears when activated vs. not
• While you and I know to drag the sidebar, I'm not sure if others are going to pick up on that right away. Any ideas about cues we can make about the app being grabbable by the sidebar?

[luckydonald]

About the second point I am actually concerned too.
I would like to imitate the OS's buttons

just more simple, and in the fitting pip boy color.
Then you get a normal bar on top to drag.

[luckydonald]

Photoshop mockups:
Mac.

Mac on Hover.

Windows.

edit:
I would probably make the mac buttons part of the navigation bar, so we don't loose map space.
On windows I can just lay the buttons over some small part in the top left corner of the map, so space is much more efficiently used there too.

[kitten]

@luckydonald and at this point I'm wondering if there's any worth left regarding a custom non-bordered window. Is it worth removing a system compliant feature which brings familiarity and intuitive behavior with it just so we don't have to care about that aspect design wise?

[luckydonald]

The default window borders waist much space, and also Windows adds more border on top and at all sides.
Also, with this there will no menubar be rendered on windows.
moved here from #22

Also the menu bar (Edit, View, Window, Help) isn't hidden in Fullscreen mode... (edit: See #27)

[luckydonald]

Draggable parts has to be set. See electron: -webkit-app-region
So another solution is to mark basically the whole window draggable, and exclude parts with -webkit-app-region: no-drag.
I was concerned that might later conflict with moving the map or something, as there the css has to be included every time.
A question of implicit vs explicit, turn it off vs turn it on.
(I was lazy so I chose to explicitly turn it on on only one element)

[kitten]

@luckydonald Fair enough. I think we might want to use a cursor for indicate that the window is draggable. Otherwise we just have to add -webkit-app-region: no-drag into the reset.css and that's it (?)

[luckydonald]

We have to either

• apply drag to the root and exclude buttons and movable parts later with no-drag

or

• set only specific parts as drag and don't care about the rest (which defaults to no-drag)

The first has the benefit that you can drag everywhere where no input is, but needs more careful selection what to parts to include (e.g. selectable text etc.)

The second makes it easier for us to maintain, but will result in less draggable parts.

cursor is good, probably cursor: move? Cursor reference page
I am not sure what reset.css does, where it applies.