I can't move mac window buttons
-
@osbulbul Sorry, there's not really any options for making it more compact.
Though if you're will to experiment, I guess you could hide the address bar entirely; that would certainly make things more compact.
In such a case, you can access the address bar with the "Focus Address Field" command (assigned to
cmd-L
by default). That would look like this: -
@Pathduck The container is still technically on macOS, but the buttons are not actually in it, and is instead completely empty (as seen from the DOM):
-
@AltCode OK that's what I suspected, at least there's a container. So the following should (in theory) change the height of the container and fix the position of the buttons.
.window-buttongroup { height: 30px !important; }
Then again, it does say 0 height which might indicate it's already set as small "as possible" so not sure what they're doing here.
-
@Pathduck Sorry, but that CSS also doesn't do anything.
As I mentioned, the buttons are not actually in the container, therefore they are not in the DOM.
EDIT: In fact, if I force the container to be at its absolutely smallest size possible (0x0), this happens:
-
@AltCode said in I can't move mac window buttons:
As I mentioned, the buttons are not actually in the container, therefore they are not in the DOM.
Yes, but here's code from
common.css
:.mac#browser .window-buttongroup, .linux.alt#browser .window-buttongroup { transform-origin: top left; }
So that's the code that moves the buttons to the top left. And if you can move an element, it should be possible to do other things like hiding it (
display: none;
and possibly changing its position to absolute (position: absolute
) and the setting the top offset liketop: 5px
or something to fix the misalignment.EDIT: In fact, if I force the container to be at its absolutely smallest size possible (0x0), this happens:
Yes, looks like the buttons are just rendered on top of the element, natively.
This is the code for the width and margins:
:not(.fullscreen)#browser.mac .window-buttongroup { position: relative; display: inline-flex; min-width: calc(54px / var(--uiZoomLevel)); margin-top: calc(13px / var(--uiZoomLevel)); margin-left: calc(8px / var(--uiZoomLevel)); } :not(.fullscreen)#browser.mac .window-buttongroup.on-mainbar { margin-top: 0; margin-right: 18px; } .tabs-top:not(.fullscreen)#browser.mac .window-buttongroup { margin-left: calc(13px / var(--uiZoomLevel)); }
Playing with the margin values would likely get the element to move so it can be placed correctly on top of the address bar when it's made lower.
I notice the element has a class of
.window-buttongroup.on-mainbar
- this has a margin-top of 0 so that would override the 13px from the other selector. Possibly one would need to use negative margins here - ugly but might work. -
@Pathduck unfortunately nothing works. .window-buttongroup.on-mainbar is just there for creating empty space. I can move that div with negative (or positive) margins but buttons not moving with it.
So that buttons have no connection with window.html. They are not even following .window-buttongroup divs location. I think Vivaldi just putting buttons there from native with static x,y position.
-
@Pathduck said in I can't move mac window buttons:
Yes, but here's code from
common.css
:I think all of that is just legacy code from pre-6.7 versions though. In fact, in my attempts to override all of that, it doesn't seem to do anything (the container really only seems to be there to add empty space for other addressbar buttons), but perhaps it would be better if a dev like @qjava chimed in, because at this point if mostly feels like we are speculating the function of that CSS code.
What I can tell you though, is that if I remove the
.window-buttongroup
container from the DOM... nothing happens to the buttons either! -
@osbulbul Actually, if completely hiding the address bar is not to your liking, I just remembered that there is one other setting that does change the position of the window buttons: "Show Title Bar", found in
vivaldi://settings/appearance/
. If you enable that and combine it with the following CSS:#browser:not(.fullscreen):not(.address-top-off, .address-bottom-off, .address-bottom) #header { display: none; } #browser:not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar:not(:has(.window-buttongroup.on-mainbar)) { min-height: calc(35px / var(--uiZoomLevel)); } #browser:not(.fullscreen):not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar:not(:has(.window-buttongroup.on-mainbar)) { padding-left: calc(68px / var(--uiZoomLevel)); } #browser:not(.address-top-off, .address-bottom-off, .address-bottom) .mainbar > .toolbar-mainbar { min-height: calc(34px / var(--uiZoomLevel)); }
You should get something closer to what you showed in your original screenshot:
Of course, you still can't do anything else about the exact position of the window buttons, but imo it is the best you can get with their current limitations.
-
@AltCode wow it helps
thank you so much for your time and effort, I am happy with this result.
-
@AltCode said in I can't move mac window buttons:
it doesn't seem to do anything (the container really only seems to be there to add empty space for other addressbar buttons)
This is exactly what it does and why it exists, the reason for this is to add spacing for native buttons that the UI layer has no idea about