PATCH: Fix for BR#48679: Proxy options lost after switching proxy use off and on

Dawit A. adawit at kde.org
Sat Nov 9 03:27:56 GMT 2002


On Friday 08 November 2002 05:43, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 08 November 2002 05:44, Dawit A. wrote:
> > > - - an i18n string is changed! Don't apply that!
> >
> > Hmm... I thought this was okay if the same string already exists in the
> > same module/app, no ?  That string is repeated in ::showValue (....).
>
> It must be a string that goes into the same .pot file.
> I admit I haven't checked that. If you know for sure that's the case, then
> there's no problem indeed.

Yes it is.  I checked kcmkio.po and it has the following two sections:

#: kenvvarproxydlg.cpp:177
msgid "Show &values"
msgstr "Show &values"

#: kenvvarproxydlg.cpp:443
msgid "Show &Values"
msgstr "Show &Values"

> > I found another problem however.  A shortcut conflict in KEnvVarProxyDlg.
> >  I fixed it in the patch attached below, but I am sure that breaks i18n
> > for the modified string as well.
>
> Yes, so maybe better leave it (it's very late in the release process now).

OK.

> > > - - textChanged() copies the text into the lineedits below. This is in
> > > fact another way to 'lose' information (if you type 3 different
> > > proxies, then click the "same for all" checkbox by accident, and
> > > uncheck it -> you lose the settings in the two lineedits).
> > >
> > > kmanualproxy.diff:
> > > - - same objection, it seems the patch is mostly about copying values
> > > in the "same for all" case....
> >
> > Fixed.  Please try the attached patch.
>
> Seems to work.
>
> > > - - I see a good memleak fix in updateRunningIOSlaves.
> >
> > Complaint or complement ?  I presume the former.  Could not tell from the
> > tone
> >
> > :)
>
> No, the latter :)  

I actually meant that.  I somehow reversed the two words when I wrote the 
email :)

> However I didn't realize that this was code for the kcontrol module (and
> not for libkio). So using KStaticDeleter.... is a bit overkill IMHO, but
> why not :) One could have simply used a member variable, and made sure that
> this class was only created and destroyed once. But let's leave it as that
> now.

That is fine with me.

Thanks much for taking the time to review my patch.

Regards,
Dawit A.







More information about the kfm-devel mailing list