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

List:       kfm-devel
Subject:    Re: konq_frame header
From:       Mark Deneen <deneen () bucknell ! edu>
Date:       2001-05-09 22:12:41
[Download RAW message or body]

On Wednesday 09 May 2001 7:44, David Faure wrote:
> On Wednesday 09 May 2001 22:09, Mark Deneen wrote:
> > I've added a header to all konq frames which are toggleable.  It is a
> > simple class which just has a label and a button.  The label is the title
> > of the header, and the button will toggle the part.  (closing it)
> >
> > I have a screenshot up at http://tick.dhs.org/~deneen/kpart-header.png.
>
> Very cool !
>
> Just wondering.... how does that look with the embedded konsole
> though ? Did you check it ? Your code will be activated AFAICS (since it's
> a toggle view too), and the header will take quite some space since the
> konsole is 'horizontal', no ?

My konsole part must be broken.  :-)  It must never have called setCaption 
while I was in it.  How do I trigger this?

> About the whole "passing the action around"... why not

Why not what?  ;-)

> > It only makes itself visible if the widget in the part calls
> > setCaption().  I had to do a little fudging with a QTimer::singleShot to
> > make it work. (thanks wildfox)
>
> Well, the konqframe could query for the title, to be taken from the
> desktop file of the part, maybe ?

Ok, I read this sentence a few times, and finally understand it.. :-)

So you mean (for example) i would read the value of "Name" from the .desktop 
file and put it there?  That would work as well.  I like this approach 
better.  (That way the strings are already translated)

How would a part specify if it wanted this frame or not?  Or should it be on 
for all toggleable parts?   (You mentioned konsole possibly looking ugly)

Would "X-KDE-BrowserView-ShowHeader=true" in the .desktop file be allowed ?

> This also makes the feature available at no cost to the other views
> to which this feature gets applied.

do you mean that toggleable parts would not need to be modified to take 
advantage of this?

> It would also remove the whole "looking for the caption change event"
> thing AFAICS.
>
> Other than that, this looks great ! The feature _and_ the code :)

Thanks!

Regards,
Mark Deneen

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