This is a discussion on superkaramba "KDirLister" and "KFileImagePreview" functionality - KDE ; --===============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 ...
Content-Type: text/plain; charset=unknown-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
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
2) direction for superkaramba (what do _do_??)
3) what is okay for superkaramba, for kde 3.51?
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 **** 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
_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
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
Content-Type: text/plain; charset="us-ascii"
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<