Re: Tab bar

[Juri Linkov]

>> We already have a suitable infrastructure of graphical primitives to
>> implement a tab bar on top of it.  It is required to have graphical
>> areas attached to window edges that can contain a row of bitmaps
>> bound to some commands.  This functionality is already supported by the
>> header line and window fringes.  It seems what we need is to improve
>> them to attach arbitrary number of header lines and fringes to a window,
>> and to render text (tab names) using specified fonts on these
>> graphical elements.
>
> however, toolkits like gtk+ do have tab widgets, like they have tool
> bars and scroll bars - shouldn't they be usable, akin to "toolkit scroll
> bars" and "toolkit tool bars" and "toolkit menu bars" in emacs?

Then should we have two versions of tab widgets: Gtk and non-Gtk?

>> I think tab bars are popular because they contain only elements of the
>> current program without stuff from other programs in their lists.
>
> Trying to understand that, at least re tabbed wm vs.
> intraprogram-implemented tabbing  - are you suggesting the
> window-attached tab bars in a tabbed wm *would* have stuff from other
> programs in their lists? Now, granted they _could_, but typically,other
> applications' windows would have to be manually dragged into the tabbed
> window, whereas new windows from existing applications could e.g.
> default to the tabbed window their last window went into.

The main disadvantage of tabbed WMs is that they can't provide
program-specific functionality like e.g. a command to undo tab closing,
etc.

-- 
Juri Linkov
http://www.jurta.org/emacs/