[Panel-devel] Fwd: [Slicker-devel] irc dump about our Atuin code ...

[danalien]

On Fridayen den 17 June 2005 18.12, Aaron J. Seigo wrote:
> well, this is why i asked. because when i read it over and i didn't see 
> anything in it that isn't in today's kicker design. yes, kicker doesnt' have 
> the concept of "cards and cardstacks" (and i don't see that as a negative, 
> btw), but the actual class designs are pretty reminiscent of those in kicker 
> right now and many of approaches are pratically 1:1. so i'm not sure what i'm 
> supposed to be looking at and going "ah, i see".

oohh, didn't know that. good for kicker  :)

then yes, not so much to 'glean' no.        *gets the picture*
 
> this has been an ongoing problem for slicker: it's aimed to reinvent 
> everything instead of working with projects and code that already exist. 
> perhaps the defining moment was when the slicker devs decided that providing 
> containers for kicker applets wasn't worth it and it would be a better route 
> to just reimplement every applet for slicker that already existed in kicker. 
> not only did this approach starve it of developer resources and interest, but 
> it's taken all this time to come to a design that reflects what already 
> exists elsehwere. we're moving on from there, not trying to get there.

mind you, we did *this over a year or so ago ... 

well, 'the defining moment' was when we saw that our 'legacy' code just ran 
hell of a slowish (an no matter how much you patched it, it wouldn't matter), as it was
of an architectural-falure ... as it basically was a thing ppl more then less hacked & patched together
with duct-tape .... As no-one had taken the time to 'step back' and 'charter a sound course',
back when the slicker-concept was just "fop's mockups" ... and opted just to start hacking at it &
patching it when a hole was found...
 So we (who didin't like that 'hacked & patched"-architecture) began on the rehaul,
lets-do-it-from-the-foundation-and-all-the-way-up..  When we saw that a fresh clean-start would be 
easier then mess around with 'the legacy', and since 'legacy' was seen more as a 'proof of concept'
which made the decision even easier to take.

So we lost some dev's in the rehaul process, and then there was this school-factor for our
main dev (rawler) that kept him allready far to busy....

Anyhow, things happened, we've learned one and another thing along the way - and the
journey at the end was 'worth it' from our (those that are still around) POV :)



BTW,
An other thing I've noticed is that for some reason (well, mainly in big-projects) is the 'bad vide'
they get from the phrase "lets redo it, from the ground up".  And it's become this "taboo" thing
to even mention it around *these_big-projects.

Though, the thing *they don't ask, though should (IMHO), is:
  
     Have ${We} passed our No-Return-Boundary, or not?

Sure, if one has, it makes no sense to start from scratch... but the thing is, we (slicker) realized
we hadn't [after an analysis...]. So we gambled and went for it ... 

Try we did & failed we did - though certain failure would we do even if we hadn't tried at all.  </yoda> :-)
Since 'legacy' wouldn't do it anymore.

> i really don't want the slicker cultureal approach to things reflected within 
> plasma as i believe that would be detrimental to the future of the project.
>
> if there are things we can actually learn from slicker, great; but i'm not 
> seeing them (which is why i asked). if those involved with the slicker 
> project would like to work on moving plasma forward, great. in fact, i think 
> that's best thing they could do to achieve their vision of a 
> non-crappy-set-of-desktop-widgets-that-actually-ship.


-- 

//   with regards
//   UID ::  panel-devel  ::  <${gofigurewhatmyemailis}@datormaffian.com>

- - -
  /\/\
(^.^)
 (")")
 *This is the cute kitty virus, please copy this into your sig so it can spread