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

List:       kde-core-devel
Subject:    Re: KLineEdit::keyPressEvent() reading from config
From:       Ellis Whitehead <kde () ellisw ! net>
Date:       2001-11-26 15:03:41
[Download RAW message or body]

Hi Dawit,

I've committed changes which makes any given string->key conversion happen 
only once per session.  Is there a way to update a given group in the 
KGlobal::config() object when one wants?

In regard to growing the class and adding dependencies: it's a tradeoff 
between updating when the user changes the config and a single extra slot...  
Doesn't seem to me like it's a bad potential tradeoff.  What do you think?

I wrote that key() is being depreciated because I want to use QKeySequence 
(or KKeySequence) instead of an 'int' return type.  We'll see.

Regards,
Ellis

On Sunday 25 November 2001 11:50 pm, Dawit Alemayehu wrote:
> On Sunday 25 November 2001 02:44, Ellis Whitehead wrote:
> > On Saturday 24 November 2001 10:12 pm, Carsten Pfeiffer wrote:
> > > [snip]
> > >
> > > > What I'm thinking is that the keys could be read in once upon widget
> > > > creation and stored in static variables.  Disadvantage: If the
> > > > standard key
> > >
> > > What about doing this in KStdAccel, and not in every place it is used?
> >
> > Ok, I'll implement this and use KIPC as Daniel Molkentin suggested to
> > keep it up to date.
>
> Please reconsider this.  IMHO it is unnecessary optimaztion with a side
> effect of growing the class as well as creating unnecessary dependency.  As
> I have already stated KGlobal::config() is a static object and as such is
> only read once not everytime a key is pressed!  Infact I have no idea at
> this point how the key-bindings that have already been read get updated
> once the user make changes in control panel!
>
> The most concerning issue is that there seems to be some rather expensive
> string operations in KStdAccel::keys as discussed on IRC with Carsten. 
> What is even more confusing to me as I read the KStdAccel header file is
> that someone (is that you?) put a TODO: line saying that something along
> the lines of ::keys being deprecated!  So I did not touch anything in there
> for now.  IMHO what needs to happen is that we need to make sure that no
> expensive string operations take place in any of this functions so that
> they do not introduce much overhead if invoked on every keypress for
> example.
>
> Regards,
> Dawit A.

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