| Summary: | Can't apply kiosk settings to kopete due to config file structure | ||
|---|---|---|---|
| Product: | [Plasma] kiosk | Reporter: | metrol |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | finex, klingens, kopete-bugs-null |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
metrol
2005-03-29 00:18:38 UTC
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! |