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

List:       kde-devel
Subject:    Re: KTMainWindow, setCaption, Help menu ...
From:       Espen Sand <espensa () online ! no>
Date:       1999-09-29 14:48:52
[Download RAW message or body]

On Wed, 29 Sep 1999, MadHat wrote:
> Espen Sand wrote:
> > 
> > On Wed, 29 Sep 1999, Waldo Bastian wrote:
> > > On Wed, 29 Sep 1999, Troy Engel wrote:
> > > > Espen Sand wrote:
> > > > >
> > > > > 1. I am going to reimplement setCaption() and add setPlainCaption() in
> > > > > KTMainWindow as I have done in KDialog so that we get proper captions. It will
> > > > > quite sure make some strange captions in the beginning, but I think it is best
> > > > > to do it ASAP.
> > > >
> > > > This may be a dumb question/idea, but would adding a
> > > > setModifiedCaption(bool) make sense?  The idea being that when an app
> > > > has modified it's doc, it could send the KTMainWindow this with true to
> > > > add an asterisk at the end, then when called with a false (say, after
> > > > saving) to remove the asterisk.  A very MFC-centric idea that provides
> > > > great feedback for the user...
> > > >
> > > > It's such a common feature reimplemented in code that there really ought
> > > > to be a "stock" way to do it, rather than reinventing the wheel.  At
> > > > least, I think so. :)
> > > >
> > > > -te
> > >
> > > Yes. That would indeed be a very usefull feature. Although it is probably patented in the US :-)
> > >
> > > Cheers,
> > > Waldo
> > 
> > One possible layout:
> > "[#] <userCaption> - <appName>"
> > 
> > 1. The "[#]" layout is of course changeable (not by the app developer, but
> > perhaps by some central style tool). It can be "[#]" "[!]" "[Not Saved]" etc...
> > 
> > 2. The <userCaption> must be stored in KTMainWindow so that the app.
> > developer (e.g., myself ;) can change the title with setModifiedCaption(bool)
> > without remembering the current <userCaption>.
> > 
> > I like the idea as well. It is often much easier to spot such a "flag" in the
> > window title, especially if every app conform to "the standard". It is easy to
> > implement as well so I will do this later today. The setCaption() is already
> > committed so I will modify the internals in setCaption for now although we
> > should perhaps modify KApplication::makeStdCaption() as well later.
> 
> Just a question, what about apps that wouldn't have a use for such
> feature?  Would this just be an option (like a flag in calling
> KApplication::makeStdCaption()), or added by default? I would hope the
> former.  This may be a stupid qutestion, but I am just thinking of an
> app I am trying to find time to work on that would have no need for such
> a feature.
> 

Lets see. From something derived from KTMainWindow one should be 
able to do:

1.
setCaption( xxx ) => "xxx - <appName>"
setPlainCaption( "xxx" ) => "xxx"

2.
setCaption( xxx ) => "xxx - <appName>"
setModifiedCaption( true )  = > "[something] xxx - <appName>"
setModifiedCaption( false ) => "xxx - <appName>"

3.
setPlainCaption( "xxx" ) => "xxx"
setModifiedCaption( true ) => "[something] xxx"


The setModifiedCaption flag will be off by default. Since the flag can be turned
on and off I need to save the caption ("xxx" in this case). And if you set a
new caption ("yyy") that flag will not be reset I think.

setCaption( xxx ) => "xxx - <appName>"
setModifiedCaption( true )  = > "[something] xxx - <appName>"
setCaption( yyy ) => "[something] yyy - <appName>"

perhaps we should add a new/extend setCaption() as well.
setCaption( QString caption, bool isModified=false) ? Hmm is that possible when
the QWidget::setCaption( QString caption ) is virtual? I have to sit down and
test a little bit.





-- 
Espen Sand

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