Live data from Hacker News

Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

cretz.github.io

71–80 of 82 posts

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#71

Earlier quoted context omitted.

it will change a bit though. A rewrite for firefox' new plugin architecture is on the way

Will the rewrite reduce it to the utterly-useless form of a button that drops down a list of open pages? I've seen that sort of thing attempted a few times by browsers that are idiots about their UI and don't let extensions change it and it's really garbage. Firefox going that route just makes me profoundly sad.

looks like he's able to port everything important: https://github.com/piroor/treestyletab/issues/1224#issuecomm...

just hiding the normal tab-bar might require a line of userchrome.css

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#72

This looks very promising, I'll keep an eye out for macos version, and in the mean time might play around in my VMs. In any case, thanks and godspeed to you. Currently juggling between FF Nightly (for speed and memory usage) but lacking critical add-ons (LastPass), and Chrome(/ium). I tried Vivaldi for a bit but was really disappointed with the UX after a while. I miss the golden era of Opera.

Whats wrong with Vivaldi UX????

I really like their power-user approach.

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#73

Earlier quoted context omitted.

Will the rewrite reduce it to the utterly-useless form of a button that drops down a list of open pages? I've seen that sort of thing attempted a few times by browsers that are idiots about their UI and don't let extensions change it and it's really garbage. Firefox going that route just makes me profoundly sad.

looks like he's able to port everything important: https://github.com/piroor/treestyletab/issues/1224#issuecomm... just hiding the normal tab-bar might require a line of userchrome.css

I wrote a couple of styles to hide the tab bar and the sidebar header:

- Tab bar: https://github.com/Timvde/UserChrome-Tweaks/pull/31

- Sidebar header: https://github.com/Timvde/UserChrome-Tweaks/pull/32

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#74

Earlier quoted context omitted.

> It was too power-user for what we were going for Chrome might as well support the Sidebar API to make this possible like Firefox will do with Tree-Tab-Style Add-on iirc. I read a bug report once at the Chromium bug tracker saying roughly "Sidebar API wont be implemented because UI needs to stay simple".

Chrome had side tabs for years. Never overtly, but you could enable them manually. But they took them out because someone 'didn't like how they looked' and despite thousands of people starring the bug and hundreds of comments, they refused to even tolerate their existence as a hidden feature. They're very serious about making sure you use their software only the way they want.

Vivaldi has sidebar tabs, chrome under the hood.

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#75

Earlier quoted context omitted.

Eek, yeah, I didn't have a global Qt install when I was testing. I do bundle the Qt libs along side. Maybe change LD_LIBRARY_PATH to local dir? I have filed an issue: https://github.com/cretz/doogie/issues/45 . That's why it's an alpha release :-)

Doesn't seem to work - not sure why. Perhaps you can fix by calling dlopen on the shared objects explicitly rather than linking them and relying on the linker to find the libraries at runtime. I'm not sure, not totally familiar with C linking.

I have opened a new release at https://github.com/cretz/doogie/releases/tag/v0.6.1. Please test there, and comment on https://github.com/cretz/doogie/issues/45 if it's still not working.

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#76

Earlier quoted context omitted.

looks like he's able to port everything important: https://github.com/piroor/treestyletab/issues/1224#issuecomm... just hiding the normal tab-bar might require a line of userchrome.css

I wrote a couple of styles to hide the tab bar and the sidebar header: - Tab bar: https://github.com/Timvde/UserChrome-Tweaks/pull/31 - Sidebar header: https://github.com/Timvde/UserChrome-Tweaks/pull/32

yay, no side-bar header sounds great :) thank you!

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#77
post #62

Earlier quoted context omitted.

TreeStyleTabs and Vimperator are what keep me in Firefox. Any decent alternative would be amazing.

Yes, this. Although, for a Vimperator replacement because of the breaking FF/Vimperator upgrades, I've found VimFX to be pretty awesome. I had to write some configuration scripts to get d/D to drop tabs like Vimperator, but other than that it works very well.

I'll take a look at VimFX, thanks. Would you mind sharing your configs?

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#78
post #14

I wish someone would create an Emacs buffer style browser where we could easily switch between tabs similar to how Emacs lets you switch buffers. I know you can do this in Emacs, but I just think for all the work people do to get tabs working nicely, maybe the way Emacs has done it actually works pretty well without overwhelming the screen with so much information all the time. That tree on the left would be better i…

> some kind fuzzy search screen that appears on a key-binding

Firefox kind of does that. If you type Gmail and you have a Gmail tab open you will see a "switch to tab" entry. It support fuzzy search so it's handy.

Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages

#79
post #65

Earlier quoted context omitted.

Yeah, too bad some losers at Google killed off vertical side tabs which were working perfectly fine and were even a 'hidden feature' that had to be enabled manually... because they 'didn't like how it looked.' Of course they provided no alternative other than having a ton of nearly useless tiny little tabs which apparently looks 'better' to someone somewhere. Yes, I am bitter, why do you ask?

Yep, that was me. The reasoning wasn't that we didn't like it and wanted to kill hidden features (as above, I loved it), but more that all things, even small or hidden ones, come with small and hidden cost, and cost is the end of large projects. It sounds a bit daft to many, but just having the code in the tree is a burden - tests run, translations need to be updated, and minor dependencies all over the place increas…

I'll keep my comments civil, but I really cannot say how absolutely evil, wrong, and arrogant that decision and attitude are, and how much I hate and despise Chrome on account of this and similar intentional design crippling and abuse.

(I've filed a number of bugs on several of them, based on the experience, I simply won't bother in future. It's absolutely clear that Google's goal is to driver users such as myself far, far away. Why should I fight that?)

I'll point though to the tyranny of the minimum viable user, and a rather massive Achilles' Heel Google have been manifesting of late.

https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...

Post reply on HN