Three different tab implementations
lypanov at kde.org
Fri Jan 31 16:40:06 GMT 2003
On Fri, Jan 31, 2003 at 04:05:30AM -0800, Neil Stevens wrote:
> On Friday January 31, 2003 03:51, David Faure wrote:
> > FluxBox does it? Good, opensource is always about choice :)
> > However this solution doesn't provide the kind of integration that we
> > want.
> I'd like to see just how the integration can't be accomplished. If KWin
> can be told that a dialog is associated with one window, then KWin can be
> told what document windows go together.
one interesting problem that would
need to be solved by the integration
would be that of bookmarking all tabs.
this could be done via ability to
set/get named atoms or some other
data sharing system for the entire tab.
anyways, i've changed my mind. neil's
right. i agree with possibility c) now.
kwin can't otherwise show the list of tabs
that a window contains. i just found myself
going to the taskbar to find a specific
webpage that was open in one of my konqi's.
its impossible to reattach tabs!
question. why can't applications
have a tab widget that kwin provides
the data for?, this gets around the
ugliness of border tab listings.
- tabs at the edge do actually
cause a pretty major problem
the resulting lack of theming
of the "window decorations"
oh, and fluxbox has a really nice drag
and drop on tabs meaning detachment
is much more natural.
also. neil's implyed notion of having
the performance kcm decide if something
is in-process or not really feels
right to me.
"[...] Konqueror open source project. Weighing in at less than
one tenth the size of another open source renderer"
Apple, Jan 2003 (http://www.apple.com/safari/)
More information about the kde-core-devel