SimpleKDE Thoughts and Views

[Wade Olson]

Yes, browser-basd applications have an easier time with
shielding/masking/limiting access to dat basd on roles/privs.

At the level of a desktop and corresponding applications, I could see
it quickly becoming a huge multi-dimensonal matrix mess.  Possible? 
Yes.  Elegant?  No.  Maintainable?  Not by anyone besides the person
who created it.

I'd hazard and initial guess and say that KDE's own slick layout is
its own enemy in this case.

Kparts, library reuse,kioslaves..these all contribute to a massive
impact analysis that would have to be done and maintained.  Such roles
are easier with huge monolithic silos of code that don't talk to each
other.

I don't know much about SimpleKDE, but I wouldn't think about it like
FireFox and Mozilla, where the fork cleans up code and eventually
becomes the dominant code base in the end.

On 9/27/05, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Tuesday 27 September 2005 09:20, jedihobbes at gmail.com wrote:
> > it seems an elegant and simple addition to the software we're planning
> > on rolling out anyway.
>
> unfortunately from a technical POV, it's neither of those things.
>
> > What I'd like to see is
> > SimpleKDE integrated into KDE so that either an administrator or a
> > regular user can enable/disable the "advanced/complicated/confusing"
> > aspects of straight KDE. In other words, how about an interface more
> > in line with VLC's where, when you're working in the configuration
> > system, you have the choice of either globally enabling or disabling
> > "Advanced Options". By default, KDE can ship with it ON, and we can
> > universally turn it OFF in our organisation. How much could this
> > possible add to the final code?
>
> a lot, and there's not many (any?) people around with the time and commitment
> to do it properly. moreover, "user levels" is a tried and failed mechanism.
> *however*...
>
> ... we do have Kiosk, which is very close to providing what you want in that
> you can limit and define what people can and cannot access and configure.
> some distributions (e.g. SUSE) even ship with a "simple KDE" configuration
> that takes out a lot of the complexities in a KDE installation.
>
> i would suggest that putting time and effort into kiosktool and further kiosk
> support in kde apps (there's already been a TON of work done here =) would be
> a good investment of time and energy.
>
> >    Of course, if the aim of SimpleKDE is not JUST to clean the
> > interface, but to clean the code base too, then we are in a bit of a
> > fix, as KDE+SimpleKDE would still leave us with the "dirty" code that
> > SimpleKDE wants to clean out.
>
> whether or not "SimpleKDE" is cleaning out "dirty" code may be a matter of
> personal opinion. i'd say they are removing a lot of code without really
> grasping the remaifications of those acxtions.
>
> > Perhaps SimpleKDE could continue in its
> > existing "clean code/clean interface" fork (is it a fork,
> > technically?)
>
> technically and in all practicality. they've even been requested to change
> their name due to that.
>
> > whilst still contributing changes to KDE concurrently,
> > thereby making KDE "clean-interface-ready", if not "clean-code-ready".
>
> yes, i'd much rather see people work on tidying up interfaces in mainline KDE
> than wasting time butchering the code base in incompatible ways.
>
> --
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
>
>
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>
>
>
>