TODO :

[x] Draggable
[x] Resizable
[x] Theme-color
[x] Settings entry
[x] Fix Dropdowns-not-showing problem
[x] Fix no-icon-app-bar problem
[x] Make maximizing fill the whole space (no border with shadow)
[x] Handle fullscreen correctly
[ ] Resize to half of the screen when touching a screen edge etc (in progress)
[x] Allow dragging in place without tabs (fixed)
[ ] Change cursor on resizing (idk why it doesn't work anymore) -> does work but only add the shadow's border not at the actual window border (less intuitive)

capture du 2015-09-17 18 35 07 capture du 2015-09-22 22 02 57

pierremtb commented 9 years ago

We can set it as a frameless window, with a custom window decoration (as I previously did on my calculator). However, the code I used to make it dragabble was working, but it wasn't really smooth. I can try to implement it on your browser tonight if I got time.

timsueberkrueb commented 9 years ago

@pierremtb Great! Development on this goes here: https://github.com/tim-sueberkrueb/material-browser/tree/feature-10

pierremtb commented 9 years ago

I got some news, I created a branch for this feature : feature/custom_frame. I borrowed @qcxiaoyezi some codes, thanks a lot !

Only one tab : capture du 2015-09-17 18 15 05

Multiple tabs : capture du 2015-09-17 18 15 29

And without theme-color : capture du 2015-09-17 18 20 41

timsueberkrueb commented 9 years ago

[ ] fixed Mabye needs some work regarding subpages:

pierremtb commented 9 years ago

@tim-sueberkrueb Yes I saw that yesterday. I need to adapt the margin that I had to set for the main page

jmc-figueira commented 9 years ago

Amazing work! Two issues though are that I feel like the maximize and minimize buttons aren't clear from a UX perspective (usually the standard is an "underscore" for minimize and a square or a plus for maximize), although that might be the Material Design approach, and the fact that maximize does leave a small border around the window, not fully maximizing it (at least on OS X). There's also a fair bit of lag between pressing a button and the action actually being performed, as well as some glitchiness when moving a window, and notably toggling the feature in the settings only works after a restart (when going from the custom frame to the OS-default one, it will result in a frameless, control-less window).

Additionally, although this happened previously, the custom color based on the current tab (toggleable in the options) has no effect for me (on OS X), the toolbar + frame always stay gray, no matter what.

pierremtb commented 9 years ago

You're completely right, I just chose that set because they were included in QML-Material, so I had nothing to do. But they are not user friendly at all. BTW what would you think of putting them on the left corner on OS X ? Maybe it would be better for consistency. The custom frame still need to be improved indeed. Regarding the need of restarting, it is apparently OS X related, or at least non-Linux, because it does work instantly on my eOS. Will think about it. Thank you !

Le sam. 3 oct. 2015 02:49, jmc-figueira notifications@github.com a écrit :

Amazing work! Two issues though are that I feel like the maximize and minimize buttons aren't clear from a UX perspective (usually the standard is an "underscore" for minimize and a square or a plus for maximize), although that might be the Material Design approach, and the fact that maximize does leave a small border around the window, not fully maximizing it (at least on OS X). There's also a fair bit of lag between pressing a button and the action actually being performed, as well as some glitchiness when moving a window, and notably toggling the feature in the settings only works after a restart (when going from the custom frame to the OS-default one, it will result in a frameless, control-less window).

— Reply to this email directly or view it on GitHub https://github.com/liri-browser/liri-browser/issues/10#issuecomment-145189757 .

jmc-figueira commented 9 years ago

The maximization issue and restarting have both been fixed in the meantime (between the last few commits I believe). Still, the theming issue remains, and the window is undraggable.

BTW what would you think of putting them on the left corner on OS X ? Maybe it would be better for consistency.

Not necessarily; it would be more user-friendly on OS X, but how would you go about Linux DEs, which have different standards (Ubuntu's Unity puts controls on the left, OS X-style, but KDE puts them on the right, for instance. GNOME Shell doesn't even have minimize and maximize by default)? I believe it's best to stick with a configuration for the material frame, in my opinion, as any user who feels confused by this can opt for the OS-specific controls instead, in the options.

timsueberkrueb commented 9 years ago