Building buttons that move


  • Vivaldi Team

    For the first time in Vivaldi history, a button can exist in more than one location. Here’s how we’ve been able to achieve this.

    Click here to see the full blog post



  • as I mentioned earlier there should be a superset of "button" component: a "toolbar element" component, no matter if it's native button, textbox, extension button or bookmark it should be able to be put just anywhere, and to make it easier there should also be no "bookmarks bar" and probably even "tab bar" but just "toolbars" that you can sprinkle with elements as you wish
    someone wants to mix native buttons with extensions? sure! (for example I do)

    about the customization process I still feel like Firefox' "design mode" is slightly more useful, especially if you'd allow us to move around page actions buttons that are not necessarily visible all the time (and I hope you will)


  • Moderator

    Thanks for sharing this devlog. I look forward to whatever customisation feature comes next.


  • Vivaldi Team

    @zakius: The current structure is Toolbar > (various optional grouping mechanisms) > ToolbarButton. The goal of this exercise was to build the foundations you are asking for. We are planning more ways of customization, one of them a separate "mode". 🙂


  • Banned

    This post is deleted!


  • Very interesting read, thank you.

    I have a question concerning triggering the action of a button. With the previous buttons it was possible to simulate a click event with javascript, but with the new buttons I noticed any attempt to simulate the event will fail. I made sure to target the exact element a normal click would, but no dice. I even tried to simulate left mousebutton down, left mousebutton up and click all in a row, but it still doesn't work. Is there any way to simulate the button click with a custom modification these days, and what has changed?

    And as a bonus question: I noticed most of the individual class names for buttons are gone (eg: the home button doesn't have the class .home anymore). This makes it relatively hard to target the buttons with css or js – one of the only ways is to go after the title attribute of the buttons, which is pretty bad, since it will only work for one language. Are you gonna bring back individual class names for buttons to make custom modifications easier again?



  • That was fun to read, thanks for the insight. I really like that you share such stories as I can remind myself about them in times when I sit in front of my monitor and think "why don't they just make like this or that". Most times it probably isn't "just make it like this" but more like a half year worth of work just to make me a happy button pusher ^^



  • Thanks for the writeup, very interesting! I am sure Vivaldi will get even more flexible on this front as time goes! 👍

    Personally I'm a minimalist, and I like as few buttons as possible - I have just back, forward and reload next to the address bar. But I know a lot of people like to have lots of button and all their extensions visible and so on.

    I think old Opera and also Firefox got this right, being able to just remove or add buttons on the toolbars and elsewhere from a list of available ones. And drop them anywhere in the UI, not just pre-defined places.



  • @zakius said in Building buttons that move:

    and to make it easier there should also be no "bookmarks bar" and probably even "tab bar" but just "toolbars"

    I hope not. By making all bars indiscriminant from one another, the customisation of them (from a modders stand point) would cease to exist. Same as with the buttons now not having an identifier, not only can we not move them or use their functions, but we can no longer change the look of the icons with svg's. At that point we really would beholden to the devs to hopefully make any changes we want.

    It's a bit of a catch 22 right now, they have taken away the ability for more options from fewer people to give more people fewer options.


  • Vivaldi Team

    @luetage said in Building buttons that move:

    With the previous buttons it was possible to simulate a click event with javascript, but with the new buttons I noticed any attempt to simulate the event will fail. I made sure to target the exact element a normal click would, but no dice. I even tried to simulate left mousebutton down, left mousebutton up and click all in a row, but it still doesn't work. Is there any way to simulate the button click with a custom modification these days, and what has changed?

    @luetage: Good questions. We listen to pointer events, so you might get it to work by triggering pointerDown and pointerUp. Internally we execute commands, it would probably be better if you were able to use those directly instead of tinkering with the buttons.

    And as a bonus question: I noticed most of the individual class names for buttons are gone (eg: the home button doesn't have the class .home anymore). This makes it relatively hard to target the buttons with css or js – one of the only ways is to go after the title attribute of the buttons, which is pretty bad, since it will only work for one language. Are you gonna bring back individual class names for buttons to make custom modifications easier again?

    Class names like .home are not useful to us, as much of the exercise is to harmonize the button behavior. Of course, on a code level we know which button is which. But that is not written to the DOM. What is it you are trying to achieve by targetting a single button?


  • Vivaldi Team

    @zaibon I try my best to design things the Long, Hard, Stupid Way. 🙂


  • Vivaldi Team

    @sjudenim said in Building buttons that move:

    @zakius said in Building buttons that move:

    and to make it easier there should also be no "bookmarks bar" and probably even "tab bar" but just "toolbars"

    I hope not. By making all bars indiscriminant from one another, the customisation of them (from a modders stand point) would cease to exist.

    At the same time, this might be what is necessary to allow users to move things around. We (as designers and developers) cannot assume specific buttons or even toolbars will exist in a given setup. Like I write in this blog post, we believe in shifting power from designers to users. From what you are writing it seems like you are feeling some of our pain. 🙂

    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?



  • @helmers This took me quite some time ^^ But I really like the ideology / credo behind it, especially as the work that I do for a living has the sad tendency to go completely towards the other direction.
    Originally I wanted to end this post by a short, lame pun about the poor student and the chef that is instructing his sue-chef that the blogpost is somehow fishy as I assumed that a japanese sounding restaurant probably have a lot of seafood on their menu (that was the stupid part^^)
    So I went to their website to do a little fact check, but their site is terrible overloaded and took ages to load (that was the long part^^)
    And in the end my little, low performance, workstation did the only thing possible left - and just restarted .... (that was the hard part ^^)
    So it seems after all I followed the credo at least to get my pun together ; )



  • @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.


  • Vivaldi Team

    @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 like button-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?


  • Vivaldi Team

    @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.


  • Vivaldi Team

    @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 like button-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)


 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.