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