Can't think Doogie without thinking of Lil'Doogie
Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
61–70 of 82 posts
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#62Looks great! I'll wait for the OSX version. Also - vim or emacs shortcuts would be appreciated.
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.
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#63I switched to Firefox (dev edition) a month or so ago almost completely becuase the TreeStyleTabs extension is better than anything for chrome. I LOVE having nested tabs. It totally prevents me from getting lost when I'm links deep in technical documentation.
it will change a bit though. A rewrite for firefox' new plugin architecture is on the way
I am using vertical tabs in nightly (which uses the new plugin architecture). I don't use tree style tabs but I would be surprised if they are not supported.
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#64[deleted]
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#65This is a great use of Chromium! Storytime! When we started designing Chrome back in 2006, and despite having spent the past year working on Google's Firefox team, my favorite browser was iRider, which was an IE shell with tree-style-tabs. It was too power-user for what we were going for, but some of the concepts (pinning) live on in Chrome today.
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 increase development costs persistently. For example, consider the staff who added the "audio indicator in tabs" functionality and how the presence of a separate tab system in the tree might cause them extra work, or how their work may inadvertently cause critical bugs in sidetabs that don't have an owner to fix it or care for it.
To keep Chrome nimble we attempt to cut and trim as much as we can, knowing that that annoys some. We don't always get this right, but it's better to aspire to do fewer things well than to be generally OK with crufty bits here and there.
I realize this explanation probably won't decrease the sadness, and you've probably heard something like it many times in the bug tracker, but if not, I hope it explains things a little.
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#66Earlier 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 just find it sad that the world's biggest browser is afraid of extra features, because it might require extra work.
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#67Earlier quoted context omitted.
it will change a bit though. A rewrite for firefox' new plugin architecture is on the way
I am using vertical tabs in nightly (which uses the new plugin architecture). I don't use tree style tabs but I would be surprised if they are not supported.
The author of TST is working on a port :)
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#68Earlier 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.
Before being sad, take a look at already extant add-ons for vertical tabs, which work almost exactly as before, with the exception of tree style nesting. Even that will come soon, as the author of Tree-style tabs is working on a port to WebExt.
Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#69Earlier 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…
> To keep Chrome nimble we attempt to cut and trim as much as we can
$ du -sh /Applications/Google\ Chrome.app/
346M /Applications/Google Chrome.app/
$ du -sh /Applications/Firefox.app
147M /Applications/Firefox.app/Re: Show HN: Doogie – A Chromium-Based Browser with Tree-Style Pages
#70Earlier quoted context omitted.
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…
> To keep Chrome nimble we attempt to cut and trim as much as we can $ du -sh /Applications/Google\ Chrome.app/ 346M /Applications/Google Chrome.app/ $ du -sh /Applications/Firefox.app 147M /Applications/Firefox.app/
To be fair: "trimming as much as we can" doesn't mean you have to be the browser with the smallest file size on the market...