Vivaldi://sppeddial as Startpage
-
Usin vivaldi://speeddial as the startpage is not working. When you do so, the speeddialpage is not loaded and Vivaldi says that the page chrome://speeddial could not be found.
-
Give this a go = http://vivaldi:speeddial or vivaldi:speeddial
Hope it helps
-
if you close tabs at the moment of close vivaldi, when you reopen vivaldi it will start with speeddial tab
-
vivaldi://startpage works
-
vivaldi://startpage works
As a link, yes - but as an assigned value for home page, no (at least not here on Windows, yet). So, rather than using the home page button, I use a link to startpage on the bookmarks bar. It's better than nothing.
-
vivaldi://startpage works
As a link, yes - but as an assigned value for home page, no (at least not here on Windows, yet). So, rather than using the home page button, I use a link to startpage on the bookmarks bar. It's better than nothing.
On 32-bit Win7 with 32-bit Vivaldi v1.0.138.4 I have it entered as my Homepage in the settings, and it works when opening a New window (Ctrl+N). So I thought it was all good to go.
But you're right, it isn't working if I click on the Homepage button in the toolbar. :pinch:
(and if I substitute chrome://startpage, that URL doesn't work for either)Well, some of these Vivaldi URLS (and other Vivaldi features) are still just waaay too buggy.
-
If you assign it (vivaldi://startpage) to the home button, click on it and get the error page, you can then press "enter" in the url box and the startpage (speed dial) will appear. Yeah. Weird, right?
-
If you assign it (vivaldi://startpage) to the home button, click on it and get the error page, you can then press "enter" in the url box and the startpage (speed dial) will appear. Yeah. Weird, right?
Confirming that also works here.
β¦And yeah, weird.
Probably there are some things about this kind of development project that I (as a non-programmer) don't understand, but I'm surprised so many functions that seem to be such simple standard behavior in most/all software have had all these quirky/buggy behaviors in Vivaldi (e.g., non-responsive Enter key in Address Bar, loss of text-box focus upon Enter key, Ctrl+Left/RightArrow and Ctrl+Z in text-boxes, Backspace bug, have to Right-Click twice for context menu, etc.).
-
This is probably secondary to a couple of factors. The first would be the fact that the browser is so immature. The second would be the fact that the entire user interface is divorced from the rendering engine, the javascript engine and the operating system interface. It's essentially written like a web page. This is necessary in order to have the level of configurability that we former Opera users demand. In the end, the interface of the old opera was the same - it was rendered by the browser engine and the JS engine, like a web page, so the developers could make it look like and act like anything they wanted, and provide dozens (no, hundreds) of options to change the user-facing experience. If that level of configurability is to be present in Vivaldi as well, then it, too, must be written like a web page- not relying on the constraints or the elements of the engine or the environment.
The drawback of this is that code must be written newly for EVERY SINGLE function of the UI. Where this code does not exist yet, no function exists yet. Where the code is incomplete or needs debugging, the user experience is buggy. This is no trivial challenge Vivaldi has taken on.
-
This is probably secondary to a couple of factors. The first would be the fact that the browser is so immature.
On the surface I would say, "Oh, well, of course!" even before reading your post. But after digesting your post, it sounds like the second factor probably has much more to do with what I was getting at.
The second would be the fact that the entire user interface is divorced from the rendering engine, the javascript engine and the operating system interface. It's essentially written like a web page. This is necessary in order to have the level of configurability that we former Opera users demand. β¦ The drawback of this is that code must be written newly for EVERY SINGLE function of the UI. Where this code does not exist yet, no function exists yet.
Ahhh⦠Now I get it. I was imaging that many of the type of functions I mentioned were already existent and developmentally mature in some sort of underlying building blocks used in Vivaldi. So they seemed like odd "immaturities" to me. But now I see, for example, that some kind of code may yet have to be written/debugged to differentiate Ctrl+BackArrow in a text-box from Ctrl+BackArrow to go back in the tab history.
In the end, the interface of the old opera was the same - it was rendered by the browser engine and the JS engine, like a web page, so the developers could make it look like and act like anything they wanted, β¦
Ahhh⦠See, now, in spite of 8 years of intensive use and exploration of Olde Opera (starting with v9.20 in 2007 IIRC) I had no awareness that was an underlying reason for the customizability.
and provide dozens (no, hundreds) of options to change the user-facing experience.
No, thousands or even tens of thousands! To this day, it never ceases to amaze me how much unique customizability exists in Olde Opera. Even after 8 years of intensive Olde Opera use and exploration I'm still learning, and I figure I probably only have some working knowledge of maybe 25% (?) of the possible customizations (and have probably forgotten half of those).
If that level of configurability is to be present in Vivaldi as well, then it, too, must be written like a web page- not relying on the constraints or the elements of the engine or the environment. β¦ This is no trivial challenge Vivaldi has taken on.
I will love it if/when we get to even 25% of that configurability!
β¦So given all the above I would come back your first factor and say "So in that case, at this point in time Vivaldi is developmentally even much younger than I realized."
-
-
Please support my idea to do it automagically here
Done (with some additional thoughts).
-