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

[Dawit A.]

On Thursday 07 November 2002 05:03, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> kenvvarproxydlg.diff :
> - - setMinimumSize looks wrong and/or unnecessary

I fixed it another way.  Perhaps this is more acceptable for now without 
redoing the layout at this point ?  Note the problem was that toggling the 
button caused the layout to expand and contract.  In hind sight I could have 
perhaps held it off until post 3.1...

> - - 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 (....).  Removing 
the unnecessary spaces from "Hide &Value" would indeed break i18n.

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.

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

> ksaveioconfig.diff

> - - one minor thing: setObject(0) is unnecessary, KStaticDeleter resets the
> static pointer already.

OK.

> - - Of course we could use KStaticDeleter<KConfig> directly, instead of the
> intermediary class KSaveIOConfigPrivate, but indeed the approach used by
> the patch is open for more extensions in the future.
:)

> - - I see a good memleak fix in updateRunningIOSlaves.
Complaint or complement ?  I presume the former.  Could not tell from the tone 
:)

> - - Why does updateConfiguration delete "d" ? That sounds dangerous, given
> that it's the object in the kstaticdeleter! I would delete (and set to 0)  
d->config instead. I'll make that change and commit that one.

Hmm... I fail to see why since we set it to 0 in case of double deletion.   
Howerver, I am not sure how KStaticDeleter works and consider your approach 
to be better than mine ; so I have no objections.  

On the other hand KProtocolManager does the same thing except that the object 
maintained by the static deleter has a couple of more pointers.  Should that 
be modified as well ?

Regards,
Dawit A.