Need help with kdesktop patch

Kevin Krammer kevin.krammer at gmx.at
Wed Nov 16 19:32:11 GMT 2005


Hi Aaron,

On Wednesday 16 November 2005 19:37, Aaron J. Seigo wrote:

> not that it matters overly much here because these aren't in a hot path,
> but for loops like:
>
> for (unsigned i=0; i < m_Renderer[sdesk]->numRenderers(); ++i)
>
> it's usually a good idea to cache the value instead of calling it every
> time through the loop.

True.
I just copied it from the respective set method to stay close to the main 
coding style of the file.

> something that stood out was these two changes:
>
> -    KDesktopSettings::setLimitCache( (bool) bLimit );
> -    KDesktopSettings::setCacheSize( size );
>      KDesktopSettings::writeConfig();
>
> and
>
> -    KDesktopSettings::setCommonDesktop( m_bCommon );
>      KDesktopSettings::writeConfig();
>
> where is the change being made to KDesktopSettings (and if nowhere, why
> write the config file out)? i couldn't find a place where the settings
> object was getting updated; should it be?

Argh!
Thanks for spotting that. It was left from a previous trial.

> > The last two are not so important:
> > http://bugs.kde.org/attachment.cgi?id=13483&action=view
>
> why have backgroundConfigureDone when it just calls internalConfig? just
> connect the signal to internalConfig and be done, no?

Done.
Was mostly for testing purpose so that I could log when the signal was 
received.

> i'll test after we're doing chewing over the above items =)

Thanks a lot.

> also, since this has been there since 3.4.0 and isn't an overly serious
> issue, this probably doesn't need to be in 3.5.0 (certainly 3.5.1 though)
> so we're in no massive hurry.

The bug came up initially on kde-forum.org (IIRC) quite some time ago.
As this is the first report about the issue it seems nobody else has 
discovered it yet or wasn't concerned about it.

> certainly a lot of work to get kiosk right there =)

:)
That's why I had to obsolete my first attemps, it turned out there where more 
places to check for this.

A question regarding the KConfigXT generated class: is this the correct way to 
check for an entry's immutability?
It requires the caller to know the internal entry name, but the generated 
class seemed to not contain methods for that and

bool canSetCommon()
{
    // remember value
    bool common = KDesktopSettings::commonDesktop();

    KDesktopSettings::setCommonDesktop( !common );
    if  ( common == KDesktopSetting::commonDesktop() )
    {
        return false;
    }
    else
    {
        // restore value
        KDesktopSettings::setCommonDesktop( common );
        return true;
    }
}

didn't feel right.

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bgmanager.diff
Type: text/x-diff
Size: 6399 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051116/f3deab00/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: desktop.diff
Type: text/x-diff
Size: 4274 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051116/f3deab00/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051116/f3deab00/attachment.sig>


More information about the kde-core-devel mailing list