https://bugs.kde.org/show_bug.cgi?id=395157
--- Comment #17 from emele...@gmail.com --- (In reply to Jan Grulich from comment #16) > Are you sure that Juniper VPN doesn't need to reload if you change the > group? If so, there is also slot connected to group change below, causing > the dialog to reload for the first time and later on it goes to this > QTimer::singleShot() causing it to reload endlessly. I tried commenting out the connection, but the endless loop comes again. That connection doesn't seem to be needed nor harmful in this case. Removing it together with my ugly patch still works. The way it works as I understand it is as follows. We need a first connection to the server to get the groups and populate the ComboBox. The QTimer::singleShot() call makes it reload as soon as the index of the ComboBox changes, which will occur immediately if there is an entry different from the first in the configuration (i.e. in the last successful connection), or when the user selects the group. This triggers a formGroupChanged(), establishing a new connection with the server. I am unsure as to how this is done but the form is deleted in formLoginClicked and afterwards a d->workerWaiting.wakeAll() call probably does the trick. So the only way for Juniper VPN seems to be not to reload the form. I do not have the specs (all of the above is experimental) but since we get all info needed with the first connection to the server, I see no need to reload the form. -- You are receiving this mail because: You are watching all bug changes.
