FS#249 - Remove uzbl-tabbed, add its functionality should enter into uzbl-browser.

Attached to Project: Uzbl
Opened by spc (specnaz) - 2011-01-22 11:15:14 AM
Task Type Feature Request
Category uzbl-tabbed
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


My sugestion is that, it's time for ditching uzbl-tabbed with its gtk-tabs.
Yes, ditch gtk-tabs, too.
Uzbl-tabbed is cluttering the design, and a bit bloated.
For me functionality of tabs shoud be directly implemented into uzbl-browser, hence reducing it even more into lean and clean package.

Comment by Ben Boeckel (mathstuf) - 2011-04-14 03:42:21 AM
Full disclosure: I am an uzbl-browser user.

I disagree. The tabbed interface is not part of the core browsing experience (having a tiled window manager is, however, a prerequisite for it to be fully appreciated).

The breakdown:

uzbl-core: Web viewer.
uzbl-browser: Browse the web (and related infrastructure for dealing with what that entails).
uzbl-tabbed: Tabbed browsing using uzbl-browser.

Mixing uzbl-browser and uzbl-tabbed isn't necessary. Plus we'd lose the nice one-browser-one-process thing we have now which would probably be solved in a similar fashion that uzbl-tabbed currently handles C rather than Python.
Comment by Noel Maersk (veox) - 2012-02-09 11:51:26 AM
As a tabbed WM user I, too, disagree. Not having features you don't use is what makes this browser great.

I suggest this issue be closed, so it doesn't clutter the list.
Comment by murchik (murchik) - 2012-11-06 08:47:39 AM
Well, "the nice one-browser-one-process thing" causes troubles such as low performance on opening new tabs, HTTP authentication issues and so on. If there are ways to make life easier without merging tab functionality into uzbl-browser, go on, but now it causes so much pain sometimes.
Comment by Ben Boeckel (mathstuf) - 2014-03-06 07:13:27 AM
This is blocked by the global uzbl object's existence currently. There's a fair amount of work to get this to not be the case, but it is planned (mainly for getting uzbl's logic out of the GUI thread, but this can be revisited).