From kde-kiosk Wed Jun 22 15:46:27 2005 From: Oswald Buddenhagen Date: Wed, 22 Jun 2005 15:46:27 +0000 To: kde-kiosk Subject: [Kde-kiosk] kcm_kdm again Message-Id: <20050622154627.GD8199 () ugly ! local> X-MARC-Message: https://marc.info/?l=kde-kiosk&m=111945519912500 On Wed, Jun 22, 2005 at 04:34:00PM +0200, Martijn Klingens wrote: > Oswald Buddenhagen said: > > btw, my call for help wrt some amazing idea how to significantly > > grow kcm_kdm without making it unusable still holds. > > Contact Thomas Zander, Aaron J. Seigo or the Relevantive people for > that, they are actually capable for the job, > one might think so ... but i've been pestering kde-usability like two or three times already ... anyway, moving the thread won't hurt. :) some points for consideration: - we can't grow the tab bar, that's obvious. so splitting it into multiple pages navigated from the icon/tree view on the side seems mandatory. unfortunately, kcontrol has a 1:1 mapping between pages and modules. but this imposes problems: - they'd all work on the same kdmrc -> screwup if multiple simultaneous modules in kcmshells. solution: distribute the kdm config over oodles of files. to a certain extent this even makes sense, but there's also a host of options where i'm not sure where to make a cut. also, it ain't clear yet, whether the most sensible grouping of the config in the files would be sufficiently fine-grained for "kcm purposes". - needing to re-auth for every page is sort of inacceptable. and caching the password is not the answer. solution: create a user for kdm, and su an entire kcontrol instance into that user. i also thought about dropping kcontrol at all and writing a separate config app for kdm. but both variants seem non-kde-ish. - kdm has this utterly complex per-display config system which merges ideas from x resources into kconfig. i wasn't able to explain it to thomasZ in two attempts, so i suppose it's pretty pointless to even try to make the gui handle this in it's full scope ... i thought about abandoning the concept alltogether, but that would just replace a generic nightmare with lots of specialized little nightmares and take away the abandoned flexibility from the about 10 users worldwide that actually need it. so the current solution of handling just a subset of the possibilities in the gui seems most appropriate. > unlike you, me and the others on this list ;-) > that's for sure. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. _______________________________________________ kde-kiosk mailing list kde-kiosk@kde.org https://mail.kde.org/mailman/listinfo/kde-kiosk