[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Three different tab implementations
From:       Alexander Kellett <lypanov () kde ! org>
Date:       2003-01-31 16:40:06
[Download RAW message or body]

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.

1)
   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.
2)
   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.

Alex

-- 
"[...] 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/)
[prev in list] [next in list] [prev in thread] [next in thread]