--===============1290468647==
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

[please reply cc to me but PLEASE keep the content short as i only
 have GPRS access during the week, which is charged at £3.00 per
 megabyte.  thank you!]


hi, i love superkaramba.

can't stop working on it.  superkaramba is "now", plasma is "later", and
i can work well with "existing" code, plus, if i get started on plasma i
will go very far with it, and without svn commit access to kde i am
_not_ doing that (i've had 100,000 lines of code wasted 6 years ago
because of some dickheads' attitudes and i'm not having that happen
again).

anyway.

reasons why i am writing:

1) i heard that ubuntu is planning to put in "scripting".  this is a
_good_ move, other than the bit about it being "ubuntu" - i.e. based on
shit-for-brains gnome.

2) direction for superkaramba (what do _do_??)

3) what is okay for superkaramba, for kde 3.51?
	http://bugs.kde.org/show_bug.cgi?id=120334

so.  firstly.  ubuntu doing scripting is GREAT.  it's a major
opportunity to "merge" desktop functionality.

imagine plasma, superkaramba and ubuntu "themes" all sharing a common
API where the scripts don't give a shit what system they're running
under, it all just... "works".

... how about it ? :)


secondly, i'm just happily hacking on superkaramba, because i love it,
but the concern is to _not_ end up turning superkaramba into another
implementation of pyqt+pykde.  let me put it this way:

* by adding about 700 or so lines of c++ code to superkaramba
over a period of a couple of days, i was able to add KDirLister
support (and then spent a _week_ writing a python theme which
is now running at approx another 700 lines, although the "example"
code is only 100)

* by adding about another 400 lines or so of c++ code to superkaramba
over a period of approx 90 minutes, i was able to add KFileImagePreview
support, which then can be called with a couple of lines of python.

... the question becomes: where do i stop? 

ultimately, i don't want _any_ "standard" kde desktop stuff -
i want _everything_ scripted.  plasma isn't currently there,
pyqt+pykde i'd consider to be too complicated: you don't _want_
"generic" widgets: for a desktop, you want "create me an image
and put it HERE and it's all managed and happy".

stuff like a dialog box which does "settings", i can understand:
i'm happy with that.  but konqueror, with its "fixed" treeview system,
where you have no control over where the icons go?  YUKKK! :)

use the superkaramba.createUrlIcon("settings://..../") function,
and you get an icon which can be clicked on and up pops the
settings.

_one_ line of python for such behind-the-scenes complex functionality.

i can't quite get over this :)


thirdly: p0z3r is a bit concerned about the amount of stuff going in to
superkaramba, for kde 3.51.  he asked last week if anyone minded if new
stuff went in.  the patch that was around for 18 months has gone in
(hurrah!)  however, there's a bit more (which i wrote only last week)
which is the KDirLister stuff.  p0z3r was concerned that it would be an
"overload" of the kde 3.51 maintainers.

if you're a KDE maintainer, no there are new extra "strings" (viz: no
translation work required), and you would find some extra functionality
acceptable (which has no "impact" on the existing superkaramba code:
it's just "additions" in other words) then would you be kind enough to
reassure p0z3r about this (he sent a message last week to
kde-core-devel).

he can then make a decision whether to commit it or not based on his own
schedule and the merits of the patch, _without_ having to worry about
whether it would create additional work (for you).


that's all for now.  please bear in mind, i have very little
available time and my internet access is very limited and
sporadic.

love,

l.


-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--===============1290468647==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============1290468647==--