Does <tabbrowser/> belong in toolkit?
(Posting here instead of newsgroups because to get everyone I want to see this, I’ll need to crosspost to a ton of places, or i could just blog the initial idea)
First off, I’m going to say that tabbrowser is seemingly not used outside of /browser, given that a) I know of more than a few dependencies on browser that haven’t been fixed, and no one’s complained about them except me, and b) no matter how hard I google, I still don’t find any code/reference that actually does anything with tabbrowser except for extensions, but I don’t think most of the implementations I’ve seen of tabbrowser extensions actually extend the binding itself, but instead they just hook onto gBrowser and go from there, which would be the same if the CSS pointed at a different place to find the binding.
Ultimately, tabbrowser is pretty implementation-specific, but we end up doing things like this to extend things for browser, which seems like a giant pain. I don’t think anyone who would build a browser on xulrunner wants all of our implementation tweaks, or automatically shares all of our UI priorities. Moving it to browser allows other browsers (i.e. SeaMonkey) to maintain their own fork, or go in an entirely different direction. There’s room for doing a base implementation for other consumers to extend in a different direction, but that’s not something I find really interesting, or of enough importance to split the binding up.
Thoughts? Is someone out there using tabbrowser for their own purposes that’s not well-known?
I can’t think of any reason why it should be in toolkit. Ultimately if you’re building a tab based browser, you might as well have the whole browser component to start from.
In support of moving it to browser, I can think of at least one unfixed bug that we discussed before which I could then go ahead and fix, since it wouldn’t be creating a dependency.
There are probably others, too.
I can see the rationale for moving it, but I know I have an xulrunner project in mind that will use a tabbrowser.
Is there not some middle ground here, keep a basic (and I mean very basic) tabbrowser implementation in toolkit, then extend it in browser. That way toolkit users can have the basic building blocks and extend them to add their own functionality just like browser would be.
As to what the basic tabbrowser would be, I’m not totally sure I guess just the simple tabs with browser, possibly with tab drag and drop. No context menu’s or anything, they are app specific.
Either moving it completely out of toolkit or go Mossop’s way sounds good. There are other things that might be worth adding to toolkit, here’s one that’s worth removing – at least the way it is at the moment.
Form what I hear, there are thoughts bouncing around of trying to use a tabbed message view pane in mailnews, and others might want to do/use some basic tab-multi-browser widget (like Mossop), so there may be a reason for having a basic tabbrowser widget in toolkit and extend that one in browser/ as well as suite/common/ and other places to the specific needs of different apps.
I know that XBL supports extending such widgets reasonably well (yes, it could be better), but I don’t know the code well enough to tell if that’s worth the effort…
IMO moving tabbrowser to browser/ is the right thing to do, for the exact reasons you say.
I agree that tabbrowser is not a good fit for the XUL language. It also seems to be very tied up with the browser chrome. For that matter, I don’t really understand why there is a XUL element at all (why not just overload ?)
XUL (and toolkit/) will continue to support and other elements that can be combined to produce a tabbrowser. We could even think about moving the tab-drag code into somehow.
We have a tabbox widget in Komodo that supports d&d, and rather than shrinking tabs to fit, it uses a scrollbox. It could certainly use improvements, but wouldn’t mind someone using it as a basis for a toolkit tabbox widget.
In my opinion, yes, there is space for tabbrowser in toolkit but if and only if it’s standalone. I mean using a element in your xul page should not force you to use a given script or whatever else.
That’s precisely what I am trying to with .
My ultimate goal is a that contains all magic to create a new editor or browser tab, convert a browser into an editor and vice-versa, all magic to attach editing behaviours to the document and so on.
Oh, and I think I will be using in Mozilla Composer for a new window allowing to preview all your edited documents at once.
Tabbed browsing is great for the user, but not so great for the developer. This isn’t a democracy, but I would recommend moving tabbrowser out.
Any tabbrowser code that remains in toolkit should be carefully reviewed against the outstanding bugs in Bugzilla, and should also be reviewed for little design flaws.
I wish you had posted to a newsgroup anyway, possibly just a single one, and pointed to that posting here. discussions on blogs are impossible to follow, because there’s no good way to track replies.
I hacked up a dual/triple pane viewer that would be a nice use case for a pluggable tabBrowser.
http://www.surfmind.com/musings/2004/01/06/