SimpleKDE Thoughts and Views

Wade Olson wadejolson at gmail.com
Tue Sep 27 21:47:58 CEST 2005


Good point.  Thanks for the correction.

Any internal project spawned that results in two separate development
teams with applications that need cross-patching, potentially
incompatible skins and modular extensions in one to replicate base
functionality in the other that results in the original project having
a separate release schedule and eventually dying should definitely not
be considered a fork.

Everyone, toss out my last post...it was nonsense! :)

On 9/27/05, obennett <obennett at hartford.edu> wrote:
> On Tuesday 27 September 2005 12:10 pm, Wade Olson wrote:
> > 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.
>
> Firefox wasn't fork, it was an internal mozilla project to create just a
> browser component instead of a whole suite based on gecko. ;-)
>
> >snip
>
>
>


More information about the kde-quality mailing list