Building buttons that move
-
@helmers Thank you, simulating both pointerdown and pointerup works as expected and triggers the underlying function. I didn't think of that, very helpful!! Of course it would make more sense to call the function directly, but I don't know how to do that.
And about targeting an individual button⦠In the past we used it to order elements in the address bar, but more importantly we use it to change the svg of a button with css. Messing with the icons is obviously fun and a good way to get into modding. You can introduce any icon you please and some members have even made complete sets of buttons for the UI with an underlying theme. I do understand this just got harder anyway, since we'd have to target the svgs depending on were they are in the UI to introduce the right size, but for a simple modification with a button that's being kept in place it's still easy and makes sense. But of course, whatever isn't represented in the DOM is hard to target.
-
@pathduck: I also prefer simple setups. But there are many who like having a lot of buttons. In time we will cater to everyone. And I agree that Opera had very strong customization options. Hopefully we can reach and perhaps surpass that level some day.
-
@helmers:
I think the targeting problem could be solved with a simple string id for each button. Something likebutton-reload
,button-sync
, etc. Would it be in conflict with the existing plans? -
if I remove a button from the toolbar... is there any way to get it back other than resetting the toolbar and destroying all other customisations?
-
@pauloaguia said in Building buttons that move:
if I remove a button from the toolbar... is there any way to get it back other than resetting the toolbar and destroying all other customisations?
Currently that is your only option. Given the limited number of buttons currently available, it is hopefully not too bad. In the future we will add more robust controls.
-
@Nekomajin said in Building buttons that move:
@helmers:
I think the targeting problem could be solved with a simple string id for each button. Something likebutton-reload
,button-sync
, etc. Would it be in conflict with the existing plans?Since a button now can now occur multiple times, we cannot use those as ID (IDs have to be unique). But maybe you meant class names, and that is possible. We could add
.toolbar-button-navigation-reload
. But internally we have no need for this. Adding things to the DOM is bad for performance. -
@helmers said in Building buttons that move:
We could add
.toolbar-button-navigation-reload
. But internally we have no need for this. Adding things to the DOM is bad for performance.I can see how adding a bunch of new classes might impact performance due to a lookup to see if there was any definition for that class (or however CSS works)...
But what about a custom attribute like data-btn-type="navigation-reload", or something like that? It would be ignored by the browser, but could still be used for modding, I think... There would still be some impact from parsing that attribute, when parsing the rest of the DOM, but that's probably negligible, no?
(But I'm no browser developer, I'm just making wild guesses as to how things work on the inside) -
@helmers said in Building buttons that move:
From what you are writing it seems like you are feeling some of our pain.
A little bit, yes. You can please some of the people some of the time, but you can't please all the people all of the time. Such is life.
If you could assign each button a graphic and export a configuration including toolbar/button layout and including graphics, would that be enough power to satisfy modder needs? Or is it the ability to tinker that you find necessary?
Definitely the latter. I only use a couple of buttons and while I have replaced the svg's for them, it's their positioning that I'm having a hard time letting go of.
Having all the bars treated as one would impact my workflow by rendering things like this obsolete,
https://forum.vivaldi.net/topic/21528/animated-overlays-updated-27-march-19
https://forum.vivaldi.net/topic/22766/attack-on-the-status-bar/24
https://forum.vivaldi.net/topic/34672/auto-hide-bookmark-bar/11As well as some other's that I'm sure I've missed that our great community has contributed. If you guys are able to incorporate that type of functionality, then I would have nothing to whine about....for now.
-
@helmers
I did not consider multiple instances of the buttons. That's why I wrote IDs.Does this performance issue occurs only on window creation, or all the time while the browser is running? If the former, a slightly longer loading time may not be even noticeable for the human eye.
-
I love reading Vivaldi's Tech Blogs...
-
Great blog, thanks for sharing
-
@helmers said in Building buttons that move:
@pauloaguia said in Building buttons that move:
if I remove a button from the toolbar... is there any way to get it back other than resetting the toolbar and destroying all other customisations?
Currently that is your only option. Given the limited number of buttons currently available, it is hopefully not too bad. In the future we will add more robust controls.
And just in case this is not yet noticed: when removing all movable buttons from one of the corners you can not move any button back to this now button-empty corner.
-
Tried to move stop/reload to the right. Did not happen.
-
@AnrDaemon said in Building buttons that move:
Tried to move stop/reload to the right. Did not happen.
Unfortunately we are unable to do that just yet. Currently you can only move the buttons within the containers they are nestled in. So buttons on the left of the address bar as well as the left and right of the status bar can be reordered and interchanged in those areas only
-
I love your work, and as always, I am eager to see the next step !
(and personally, what I'm waiting for, is to have custom button, and in particular, custom status fields. To add a clock here, the IP of the site there, etc.)
-
I've cloned the bookmarks and history buttons from the panel sidebar and placed them in the address bar, next to the home button. I'd like to be able to trigger the panel toggle button in the status bar when the bookmarks or history button is clicked to close the respective panel. I've tried doing it via the following function:
function clickBookmarksButton() { var bmarksbutton = document.querySelector("#panels>#switch>button[title='Bookmarks']"); var paneltoggle = document.querySelector("#browser>div.toolbar.toolbar-droptarget.toolbar-statusbar.toolbar-medium>div.panel-clickoutside-ignore.button-toolbar>button"); if (paneltoggle.title.includes("Hide Panel") && bmarksbutton.classList.contains("active")) { paneltoggle.click(); } else { bmarksbutton.click(); } }
I don't know why this doesn't work. I had successfully implemented the modification with virtually identical code in an older version of the browser, before you made the changes to enable movable buttons. I'm fairly new to JS, so I'm undoubtedly making a boneheaded rookie mistake.
UPDATE: Before commenting, I probably should have read luetage's post above and helmers' response. At least I'm not going nuts -- there have been changes that render my previous function obsolete. Still, being a neophyte, I find the suggested approach at least a little over my head.
-
@goedl said in Building buttons that move:
And just in case this is not yet noticed: when removing all movable buttons from one of the corners you can not move any button back to this now button-empty corner.
That is a limitation of the implementation. Only buttons can be dragged, and only other buttons accept dropped buttons. Once the other components also understands drag-and-drop it will feel more natural.
-
@Nekomajin said in Building buttons that move:
@helmers
I did not consider multiple instances of the buttons. That's why I wrote IDs.Does this performance issue occurs only on window creation, or all the time while the browser is running? If the former, a slightly longer loading time may not be even noticeable for the human eye.
Writing about performance is always risky, as many view performance as "that one thing that slows it down". There are sometimes such things. But most of the time performance is about doing as little work as possible. This is one of those things. The cost of an extra class name or attribute is tiny. But multiply that by 200 or more and there might be an impact.
Our underlying React framework achieves its performance by re-using DOM components. When we make them more complex they are harder to reuse. Precisely where how the impact would be distributed in this case is hard to say. Probably it would be unnoticeable. The only thing I know for sure is that adding something has a higher performance cost than adding nothing.
-
@pauloaguia said in Building buttons that move:
@helmers said in Building buttons that move:
We could add
.toolbar-button-navigation-reload
. But internally we have no need for this. Adding things to the DOM is bad for performance.I can see how adding a bunch of new classes might impact performance due to a lookup to see if there was any definition for that class (or however CSS works)...
But what about a custom attribute like data-btn-type="navigation-reload", or something like that? It would be ignored by the browser, but could still be used for modding, I think... There would still be some impact from parsing that attribute, when parsing the rest of the DOM, but that's probably negligible, no?
(But I'm no browser developer, I'm just making wild guesses as to how things work on the inside)I'm sorry to say that cheating is not allowed! The engine is already very clever, so any attribute we add come with some overhead. But I may have overstated the cost of adding a class. They are not that bad. It is just that we have a lot of buttons, so there is quite a bit of volume.
-
@helmers
I know what you mean, and personally I understand if you decide not to add class names. I am not a big modder, so for me, it's not a problem. I just wanted to know whether it would worth to experiment with it, or the overhead would be too much.