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

List:       kde-core-devel
Subject:    Re: KLineEdit::keyPressEvent() reading from config
From:       Dawit Alemayehu <adawit () starpower ! net>
Date:       2001-11-27 4:12:43
[Download RAW message or body]

On Monday 26 November 2001 11:09, Ellis Whitehead wrote:
> Hi Dawit,
>
> I've committed changes which makes any given string->key conversion happen
> only once per session. 

Great.

> Is there a way to update a given group in the KGlobal::config() object when 
> one wants?

I think David already answered this. 

> 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?

It is not so long as the intention is not wrong :) I have no problem with you
changing the code inorder to reflect changes made by the user in the control
panel.  What I thought would have been un-productive is that changing this
particular code because we thought that it was the cause for the slowness in 
when typing in KLineEdit.  Perhaps I misread your original post :)

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

Oh I see.. but then application/widgets calling this function will be broken right ?

> 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]