Version: 0.10 (using KDE 3.4.0, compiled sources) Compiler: gcc version 3.4.2 [FreeBSD] 20040728 OS: FreeBSD (i386) release 5.3-STABLE This may be an issue of my own ignorance here, but it seems that the format of the kopeterc file won't easily allow for kiosk based settings. The accounts group gets stored something like... [Account_JabberProtocol_username@chat.domain.com] There's no way to kiosk set the username in there. If you're trying to preconfigure users to point to an internal Jabber service there doesn't seem to be any way to get there from here using the kiosk. I'm reporting this as a bug since it would seem that all core KDE applications should be kiosk configurable.
I dedicace this report to Martijn :-)
Martijn: Since you designed the current config writing schema (and know a bit about this), can you think of anyway that we can fix this? Maybe we need to provide support in kiosk for wildcards/regular expressions in config file groups, so then we could match on "Account_.*" or similar
On Thursday 04 August 2005 18:13, Matt Rogers wrote: > Martijn: Since you designed the current config writing schema (and know a > bit about this), can you think of anyway that we can fix this? I'll try to look at it this weekend; bug me again if I seem to have forgotten by next week :)
Hmm, I designed the scheme to be kiosk-compatible (that's why I wanted to get rid of the xml in the first place), but upon closer investigation it looks like I missed a point here :( (The point being that the group name itself should not be dynamic for use with Kiosk.) The best solution is probably the way I did it with KExtProcess, i.e. have the groups simply count upwards and make protocol and uid fields inside the group. For a Jabber account that'd become: [Account_1] AccountProtocol=Jabber AccountId=xxxxxxxxx@jabber.org AllowPlainTextPassword=false (...) It requires slightly more logic in the reading of the config file, but AFAIR the Kopete data structures it can be handled entirely there without having to touch the rest of the code. The upside is that handling the *order* of the accounts will be natural. A nice extra feature for Kiosk would probably be to have a special placeholder "Protocol" line in an account section like "AccountProtocol=None" that terminates the parsing. If you provide a kopeterc in a kiosk environment with a corporate Jabber server preconfigured as [Account_1] and a None-protocol as [Account_2] that would in turn disable all of Kopete's logic to add more accounts. And no, I don't have time to implement this in my spare time :/ Martijn
What is the status of this bug on KDE4?
Marked with NEEDSINFO
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!