i spent a bit of time updating the plasma tasks page yesterday. it's quite the list =) hopefully other plasma devs will also add to it as needed.
we're at the stage now where scripting is pretty well possible. richard moore has worked up some prelim QtScript bindings and the plasmagik packaging has been fully integrated with the Applet class so when it is given an applet that is actually script based it automatically goes into package mode. this should fully blur the lines at all levels between c++ and non-c++ applets. i'm quite happy with how this is turning out, in fact =)
krunner now also does case insensitive matching on services so typing "Mouse", "mouse" or "mOuSe" (just to be wierd) all bring up the mouse control panel (for example). i had to patch the ktrader query language stuff a bit to make it work (thank-you to allen winter for helping to get flex/bison stuff spitting out the right content!).
it was way too hot in the house to do anything requiring higher brain functions today, so inspired by the trader language work and the techbase milestone, i did up a pair of tutorials on services and using kservicetypetrader. i'll eventually write a third one on creating, registering and loading plugins to complete that particular cycle.
otherwise it's been a bunch of bug fixing and clearing out a few remaining todo's from aKademy and the e.V.
About Me
Labels
- akademy (3)
- amarok (1)
- appeal (1)
- build system (1)
- community (7)
- crash (2)
- d-bus (1)
- dataengine (1)
- dolphin (2)
- events (1)
- family (1)
- free software (1)
- gnome (2)
- graphics (1)
- guademy (1)
- kde (52)
- kde e.v. (3)
- kde; kdegraphics (1)
- konqueror (1)
- krunner (4)
- libs (5)
- lug radio (1)
- media center (1)
- misc (1)
- openid (1)
- oxygen (2)
- performance (1)
- photos (1)
- plasma (26)
- podcast (1)
- pr (1)
- prose (1)
- release (1)
- social (1)
- solaris (1)
- techbase (6)
- travel (6)
- trolltech (3)
- web2.0 (1)
22 comments:
What's the timeline for returning Plasma back to Kross bindings? A lot of Python, Ruby people were standing on the sidelines waiting for the sensible desktop-wide scripting with KDE-native-widget Forms support. Now, it seems it's a kick in the gut to that effort.
> What's the timeline for returning Plasma
> back to Kross bindings
the js bindings will happen first and then we can work backwards from the resulting API to see exactly what we will do for other languages.
@daniel
Just use SuperKaramba :)
@Sebastian
:) You are blowing my cover, man! I am redoing A-Foto for SK 0.5 with SVG frames already.
I was just giving Aaron some hard time.
ups, sorry, Daniel. I'll try to behave better next time ;)
i'm not particularly sure why not having python would be a deal breaker. but hey... whatever floats your boat.
heh... well, besides SK being deprecated in 4.0, i think people will be a lot more satisfied with what plasma offers in general.
as for a-foto, there's already a photo viewer plasmoid. it supports wikipedia photo of the day, though i don't think it has multi-photo support yet, though that would be trivial to add. annma started it (took her all of a day to make it go) but she's open to others improving it as well.
so .. you may want to consider working on the photo frame plasmoid
> well, besides SK being deprecated in 4.0
What is your point of view and I would have a problem with it, if it wouldn't sound such arrogant and is imho wrong.
But I guess it's really better if I behave now as promised before since such kind of "discussions" are contra-productive.
Oh! now Aaron is giving us some hard time!? :)
@Sebastian, it appears the move to QtScript is 2/3 corporate promotional decision, 1/3 people's indifference. As such, it has very little "lets empower the users" and a lot of "practicality" argument in it. There is no point arguing about it on a wrong level.
@Aaron, aaron, of all people you know better that "why don't you HTML coders learn the MFC and help us with our C# project" never works. Less Python scripters != more C++ and Qt coders. Just consider this "an opportunity lost."
@Daniel
I don't really care about QtScript cause I don't use JavaScript at all ;) The main point here is those "SK is deprecated" statement since it feels like someone is pissing on the work others do. That's just not the way KDE works.
Also I don't have a problem with such comments if I read them at the dot written by someone I don't know anyway. But in that case it comes from someone who should know it better and who I respect at least enough to care about what he says and that's why I started this semi-flame in the hope to don't read such statements again.
(and since it's difficult to stop writting once started :)
@aaron
btw, I also don't understand this from the pov of Plasma as well. Not that long ago nice work landed to be able to run SuperKaramba within Plasma. Isn't this an advantage even for Plasma itself and doesn't that show, that SuperKaramba is still pretty active?
Also it's interesting that you did blog about techbase and it's tutorials and failed to note the new SK Tutorial or the SK API counterpart and judging from them SuperKaramba improved a lot. The chapter about SuperKaramba on KDE4 even is more explicit.
While I guess coperation would provide better results, I guess good competition can't harm too, right?
i'm feeling a bit grumpy this evening, so bewar. ;)
now, i'm not sure if neither of you have been around for the last year of discussions or if you're just practicing practical amnesia, but this was discussed at great length.
the person who worked on turning SK into a library and then worked on getting SK loading into a graphics view and then worked on getting SK loading into plasma was wirr.
i thought, and continue to think, that that work is both valuable and very cool.
but wirr was of the opinion that it was a bridge to ease people from SK to a new way of doing things, e.g. plasmoids. we've spent a lot of time to make sure that plasma can do what SK did and then a few things.
so for you to come here and say i'm pissing on someone else's work when all i'm doing is relaying what the person who did the damn work in the first place said to me ... jesus.
now let's think of it from a technical POV.
if you reflect on it for a moment and ponder whether or not it makes sense to have two completely different rendering and data delivery systems, both for the developers as well as for the poor desktop systems it'll be running on, it may occur to you that this is sub-optimal.
now, if plasma can offer everything SK does and then some, .......
and please keep in mind that i was the one who encouraged the addition of SK to kdeutils in the first place. it's not like i don't care about it.
now let's take daniel's "points" which are pretty misguided.
first off, if you want to point the "corporate whore!" finger, go find someone else to do it at.
here's the reality check: nobody stepped up to help at all with kross scripting. but two people stepped up to help out with qtscript stuff. the person who is responsible for the code we're looking to use is actually a community member.
they came to me and asked if their approach was worthwhile. so yeah, obviously it was me being a corporate drone and trolltech pulling the strings, right?
no, it just so happens that qtscript is pretty damn good at what it does. it's fast (more so than kjs) and easy to work runtime bindings out for.
you may have noticed that kjs is getting the boot from kdelibs? this was requested by the person who was still working on it ... with the new intention of replacing it with qtscript and some add-on plugins (which are apparently mostly done as well).
this all happened extra-corporately. so yeah .. not impressed to have that accusation thrown my way.
as for "practicality" arguments, if you mean "it's a technically superior solution" and "someone actually wrote the code" then .. yeah.. those are pretty good arguments. if you have a problem with those kinds of reasons, i can't help you.
but this one just takes the cake: daniel says, "of all people you know better that why don't you HTML coders learn the MFC and help us with our C# project" never works. Less Python scripters != more C++ and Qt coders."
now, since when is offering javascript, a bid to get c++ devs? seriously, next time think before posting, ok?
i think i also said pretty clearly at in my first reply to you: "the js bindings will happen first and then we can work backwards from the resulting API to see exactly what we will do for other languages."
does language fetishism make reading comprehension more difficult, or did you really just not read that?
see, if we create an api to bind to and then start getting people to write against in N different langauges and then we (innevitably) change the exported API .... we have a lot more code to touch. Kross certainly helps here, but playing with Kross i'm concerned that that API we'd create would be to shoehorn it into Kross rather than to create the "correct" API exposure we want.
we can easily jump to kross or even language specific bindings once we have one set down and working well. and since someone stepped up to write the js ones of their own free will, who am i to say no?
we've said from day one that js will be the primary language we promote for plasma extensions. that's never been hidden or promoted elsewise.
i will also say this: i've always been concerned about offering N different languages for desktop scripting because:
* it will make tutorials harder to write
* it will end up consuming a lot more resources as people mix python with ruby with $LANG widgets on the same desktop
* it will limit the "copy and paste" mentality of sharing i'd like to see occur
* graphical designers will either also suffer from similar useless bloat or else favour one langauge anyways (think about it: if it's a graphical designer, why would anyone care what lang it spits out the back end?)
balance that with this:
* how much better will it be to write applets in python or ruby versus javascript?
the answer had better be "a whole friggin' lot", and not just in theory but also in practice, to make up for the downsides.
nobody really has ever answered that for me, and i think i know why.
so we're going to try an experiment: we're going to put out js bindings and see how far they take us. we'll find out, finally, just what walls we run into with them.
@sebastian:
"Also it's interesting that you did blog about techbase and it's tutorials and failed to note the new SK Tutorial or the SK API counterpart"
*sigh* i'm not purposefully ignoring sk tutorials. that's just rediculous. i mentioned the new plasma tutorial (as a way to thank the person who wrote it) and the ones i started writing this week (as a way to "lead by example" in the whole "hey, write more tutorials people!") way.
so whatever you were trying to imply with the above, it's crap.
" and judging from them SuperKaramba improved a lot. The chapter about SuperKaramba on KDE4 even is more explicit."
yes, it has improved.
"While I guess coperation would provide better results, I guess good competition can't harm too, right?"
i think you need to both review the history (and note who started bringing the various efforts together) and then reflect on the current state of things (e.g. wirr's work, his viewpoint on it and my welcoming it into svn)
"kjs is getting the boot"
that's kjsembed, obviously, not kjs.
> but this was discussed at great length.
Well, I am very skeptical at those various discussions that always seem to happen behind closed doors and did start to ignore them a long time ago (I specialy like those "we decided at aKademy" intros). So, right, that's probably my fault but on the other hand it's a good protection against going angry to often about ppl that like to "decide" about things they arn't working on. Please see this sentences as general criticism not related to a single person or a project but to a human characteristic. That's why I like the KDE way of "those who codes aka does the work decide" so much :)
> but wirr was of the opinion that it was a bridge to ease people from SK to a new way of doing things
and what is wrong with this point of view? or didn't you looked at it from your "how can this be useful for plasma" view too?
> so for you to come here and say i'm pissing on someone else's work when all i'm doing is relaying what the person who did the damn work in the first place said to me
But how is it related to me or others that work on or with SK? Probably keep such battles private or/and on a personal level.
> two completely different rendering and data delivery systems
bah, now I've to be grumpy;
* deprecate KHTML and KPDF since KWord is there?
* deprecate Dolphin and Konqueror since Krusader is there?
* deprecate Kate and KDevelop since KWrite is there?
* deprecate Konversation since Kopete is there?
Well, I did looked very detailed at both, Plasma and SuperKaramba, and they have much less in common then any or at least many of the samples provided above. Also why again deprecate SK and not Plasma who was there first (discussions at aKademy again?)? Well, evil words but the point is: don't think to be able to deprecate other solutions cause you think your's is better since that will normaly fail horrible and may lead to ppl posting long messages at your blog ;)
> here's the reality check: nobody stepped up to help at all with kross scripting.
Guess we both had a discussion related to this already and I am fine (or don't care?) with the result.
But I wouldn't quote that sentence if there wouldn't be a but; iirc I made a very concret proposal, or? maybe you remember my very first words? anyway, it seems the code that was already committed does go into that direction :) So, nothing negative to say about it and I am not going the George Bush way to invalidate the "those who codes decides" rule now where I may not happy with the result (nope, I also wan't start an "eduring freedom" cause of it even if you would have galleons^n of oil ;)
> you may have noticed that kjsembed is getting the boot from kdelibs? this was requested by the person who was still working on it
This is plainly wrong. IIRC the person was working on it _till_ it got moved to kdelibs. So, Eric and me did try to fix all those bugs within last 6 months or so and now it even passes all the unittests I wrote for it. Now this same one guy changes his mind and proposed to destroy the base others build up without _any_ single word before (even more discussions at aKademy?). It's even more worse. A year ago I had a talk (at aKademy btw, hah, I can play that game too) with that person and did throw away the code-case I had so far that did build up on kjs direct rather then at kjsembed since the plan was to reuse the code in kjsembed. Man, this would be the 4th time I have to rewrite the Kross JavaScript support while I don't like JavaScript at all :-(
> now, since when is offering javascript, a bid to get c++ devs?
I guess the point here is, that the same thing is valid for javascript!=python!=ruby!=LUA!=whatever and I can only second that since that's the reason Kross does exist at all. Don't believe that users may just say "oh, it's not what I like to do in my free spare time but I'll do it anyway" since I would clearly not. One of the very cool things KDE is about (for me) is to accept my individualism and my strange taste of how a desktop should look and behave like. Provide defaults and leave room for free choise.
>> techbase [...] SuperKaramba tutorial
> i'm not purpose fully ignoring sk tutorials [...] so whatever you were trying to imply with the above, it's crap.
I try to imply: Why should someone write SK-tutorials if "SK being deprecated in 4.0" ?
and I even try to imply: It is _not_ deprecated!
>> While I guess coperation would provide better results, I guess good competition can't harm too, right?
> review the history [...] and then reflect on the current state of things
This was still related to "SK being deprecated in 4.0" and guess I don't got how review+reflect should change there anything? Should I also review+reflect if I like to wear green shirts rather then yellow ones?
A little extension that may needed before the wrong message got transfered;
"Man, this would be the 4th time I have to rewrite the Kross JavaScript support while I don't like JavaScript at all :-("
This does not mean, that I won't do it. But this does mean, that such things just can't be done 1 week before the freez. Specialy not if it means, to break others code. The way I would expect is to first talk with those that may got affected by such a move (that's one single mail with one single message to the kjsembed-mailinglist), then to look what may needed for the switch and how much time would be needed for it and finally once there is a plan everybody is able to follow, go with it.
Also there may another sign to get an idea that something goes wrong: any (even private) mails related to such a "remove next week?" proposal got just ignored and someone says something about a irc-discussion without providing any details. So, should I assume now that kjsembed will stay? Well, looks for me so...
> that always seem to happen behind closed
> doors
i would not consider irc and public mailing lists to be closed doors.
> and what is wrong with this point of
> view?
nothing. it's deprecated, not removed. which means that we need a pathway for the transitional time. and we have such a path for SK and it's even coming with an upgrade to the SK framework.
which is really why i'm so amazed at being launched at by you like this because it's a very level headed approach by all accounts and yet somehow it isn't good enough for you.
> they have much less in common then any
> or at least many of the samples
> provided above.
plasma provides the same genre of features SK does, namely an easy way to write desktop widgets in addition to a variety of other things. so i would beg to disagree here.
> Also why again deprecate SK and not
> Plasma who was there first
look, SK can stay around for as long as people use it and create for it. it's not like it's suddenly going to be "un-gpl'd" and witheheld.. but at some point the support for it within plasma will go away, though not in the immediate future.
SK can, if there is still appetite for it, return to being a hack-over-a-desktop-layer or it can even turn into its own full fledged desktop layer for all i care.
as for why plasma over SK, i think the reasons are pretty obvious if looked at objectively.
> (discussions at aKademy again?)
no, though that makes for a great conspiracy theory doesn't it? i can see it now, the next oliver stone movie! ;)
> I made a very concret proposal, or
yes, you did. as we both know proposals are one thing, code is another. and someone showed up with actual code. it happened to use qtscript.
i'm also not sure what part of "this lets us work out the APIs now that we have some real code to work with" is hard to understand. perhaps it was because i let you and daniel's petty invectives get to me earlier and you're just responding to my own vitriol. but c'mon, use your brain for a moment here: it's a very sensible approach to getting the exported API right. e.g. we can actually play with it in a very easy to manage sandbox.
> I guess the point here is, that the
> same thing is valid for
> javascript!=python!=ruby!=LUA!=whatever
yes, they are different languages. but when one gets past the language fetishism, perhaps it turns out that for scripting a desktop widget ... it doesn't frigging matter.
> Don't believe that users may just say
> "oh, it's not what I like to do in my
> free spare time but I'll do it anyway"
> since I would clearly not.
i agree that for people who are opinionated about their languages it matters. for the other 99% of humanity, it doesn't.
what i like about kross is how simple it can be to get things going. in my stock technical kde4 presentation i have a slide that shows how to add objects and run a script. it consistently gets people going "ooh" in the audience. i also mention on the slide before it how it supports multiple languages. guess which aspect people comment on and which one is usually considered a "nice to have"?
that's the perspective i'm trying to keep here in designing things. most people care more about getting somewhere quickly and easily than how they get there.
> One of the very cool things KDE is
> about (for me) is to accept my
> individualism and my strange taste of
> how a desktop should look and behave
> like. Provide defaults and leave room
> for free choise.
the framers of the american constitution had a very nice guiding principle: every person has a right to their liberty, but that liberty ends where another's begins.
too often i see in open source people will cater to everyone's whims on every matter and ... don't care when it comes with negatives that overwhelm the positives. yep, just keep pushing our pet fetishes until something sucks for everyone.
now, the desktop is not like most other applications. people don't choose to run it, it's just "there". nor are they ok when it takes up too many resources, whereas they'll often forgive a media player or web browser for its heft. they also expect it to Just Work.
these are things we can get really close to guaranteeing with JS that we can't with an N language approach when it comes to desktop widgets.
the N language approach is awesome for databases and would be cool for things like games, too. but that's not the desktop.
with that reality before me, i'm taking the conservative approach on day 1 and seeing where that takes us. if it shows up as lacking or we find the API we offer is complete enough in itself that we can sufficiently sandbox people in while giving them other languages to use, bully!
> I try to imply: Why should someone
> write SK-tutorials if "SK being
> deprecated in 4.0" ?
because they wanted to. sometimes there aren't more reasons than that. in this case, i'd suggest in addition to "want to" it's because SK has changed somewhat (as you noted, improved) and will be there in 4.0 and at least 4.1 for sure if not even longer.
i'm sure you understand the meaning of 'deprecated'.
> and I even try to imply: It is _not_
> deprecated!
then i suggest you make plans for it being a separate app at some point again.
which is pretty silly imho. i'd rather see us build one unified user base and pool efforts. but if you feel that because plasma only supports javascript right now that that's a good enough reason, well, hey, bring it on and lets see where the chips fall.
> This was still related to "SK being
> deprecated in 4.0" and guess I don't
> got how review+reflect should change
> there anything?
because i was the one who reached out to many of these communities some 2 years ago now to pull everyone together.
if i wanted to trample all over everything and really wanted some stupid "competition" i wouldn't've bothered and just gone after each user base directly.
iow, my actions don't support what you're implying about me. and i don't particularly appreciate that.
> The way I would expect is to first
> talk with those that may got affected
> by such a move
i believe that was the point of the email to k-c-d. and i think when harri and richard speak up on kjs related matters, i listen. since.. well.. they are pretty well the authorities (as in level of knowledge and involvement) on those topics, no?
yes, it sucks it was only a week before freeze. shit happens in life, and this seems like an attempt to not ship something we'd later have to lug around as a dead weight.
> any (even private) mails related to
> such a "remove next week?" proposal
> got just ignored and someone says
> something about a irc-discussion
> without providing any details.
obviously i can't speak on the private emails, but i see a one liner email from you in a thread where lots of thoughtful discussion was going on. and what you replied to turned out to be a non-issue since katepart uses kjs directly.
if you have a bigger issue with it, then maybe you should supply something more explicit than a one line reply in the middle of a conversation?
as for irc discussion, i've seen quite a number of discussions about kjs, qtscript and whatnot related to js in kde on irc. so .. yeah, it's not a quiet kabal thing, it's people talking in the hallways when they have the time to.
obviously you lack the forethought to knock on people's doors and discover exactly what kind of free software you can make for them, regardless if it makes sense or not. also, in the future please reduce you conversations to other developers at akademy. and please don't use that nasty word anymore, deprecated, i'm very offended by it.
So, to have at least some result with the time we both wasted here with that topic;
1. Kross
I don't have a problem with whatever you decided and I am clearly _not_ allowed to say anything related
to this here since I am not those one that codes aka decides nor would I be so stupid to assume that
Kross is in general and all situations better then anything else.
2. SuperKaramba
Please choose the same way I did with 1) by don't provide an official statement like "this is dead" (and
nothing more does deprecate mean) for something you don't work on. In honesty one of the reasons why I do
react now in such a way may also, that you arn't only in the board of directors but also have a lot of
influence with your wordings. So, it may even more important that you try to be political here and don't
provide bad feelings or wrong impressions to other contributors. Life and let die or something like this.
@Diego and @Anonymous
Just for the record: I am ignoring you both explicit since noone of you does code on SK. So, just join SK-development and I'll listen to you :)
@aaron thank you btw for the very detailed replies and keep up the great work on Plasma (which I would like to join if the day would just have more then those limited 24 hours)!
woah! It's a shame Sebastian doesn't have the manners to discuss this properly (coming to someone's blog to bitch is VERY poor form) because it sounds like there is some disagreement.
Anyway, thanks Aaron for all your hard work. It is really appreciated and Plasma is one of the things that I think will really make KDE stand out.
Post a Comment