In this week's KDE Commit-Digest: Continued work in Plasma, particularly in the clock visualisations. Kalzium uses the GetHotNewStuff framework to download new molecules for its 3d viewer, plus speed optimisations for the rendering of these molecules. The start of fullscreen support in the Gwenview image viewer. Work begins on a WebKit-based KPart. A KControl module is created to allow for easy manipulation of KWin "Composite" settings. Continued work on the OpenChange Akonadi resource which enables interoperability with Exchange servers. Statistics plugin for a graphical representation of connection speeds in KTorrent. Improved handling of HDR imagery in Krita. Branch created for the integration of Solid-based connection management and notification in Konqueror.
Comments
Amen brother!!!
I just hope someone will take up this project ...BasKet really is one of the coolest and most useful things around.
It's a pity though that it's only mentioned at the bottom of Commit-Digest.
I'm really happy that plasma is finally coming into the commit-digest issues and more than that with a really nice video to blend into users expectations. It's a really early stage but I'm glad things are moving and as I can see all in a good direction.
Thanks KDE.
Yes, it's always good to see such progress. It's also really nice to have people giving us encouragement like this rather than just complaining.
So, thank you Rares :)
It's quite logical most people will only see the clock not realising that this means the whole system had to be written in order to make the clock show and work.
I appreciate very much what Plasma is trying to achieve ...I just hope it doesn't end up looking like a spawn of Vista+MacOSX - KDE (and Linux) has its own way logic behind the interface (virtual desktops, middle-click paste, shading windows, etc. etc.) and this should not be forgotten. I sure hope Plasma will in due time implement what Slicker (http://slicker.org) tried to do.
Don't get me wrong - I like what I see so far and I think you guys are doing great. I'm merely expressing my hopes now instead of being an ass about it when Plasma "1.0" comes out.
Keep up the good work ...and keep it good ;)
> I just hope it doesn't end up looking like a spawn of Vista+MacOSX
seeing as i think vista's desktop ui is a complete joke and MacOS X is a severe under-performer, i'd be disappointed with this as well. obviously we'll be learning from the things they do well (e.g. i think expose ideas are very interesting) as well as what they do wrong, but also providing a lot of both traditional kde stuff (you mentioned a few) as well as some new things.
That's what I wanted to hear ;)
You just made my day (sic!).
We're right behind you — just don't take the bitching kind as the majority of KDE users ...there majority is probably the wise bunch who just sits back and doesn't say anything before they see the end product.
Why do I have to think of Robot Chicken when I read your post title... ;)
thank you for the positivity. much appreciated. and there's so much more to come from our side =)
Plasma developers: you are doing a great job, so ignore the trolls! (Don't let them get to you, that's how they get their kicks). After watching the clock plasmoid video, all I can say is "wow!"...
Btw, if I understood some of the basic ideas behind Plasma, am I correct to assume that if you open 3 different clocks, they would all be feeding out of the same data source, one which is able to provide a "current time" feed?
Another question: are there plans to add support in Kross to a strong, static type functional language such as Ocaml or Haskell? Javascript does have a number of neat functional features (such as first-order functions and closures), but I am not very fond of its weak-type system.
Obviously, what I meant by "first-order functions" is actually "higher-order functions" and functions as "first-class" citizens in the language. That's one silly portmanteau...
While I'm sure this can be achieved with Kross, I'm under the impression that they are trying to keep the plasmoids agnostic of the system. Which means that languages such as Python, Ruby and Javascript can be run using only an interpreter, C++ and so forth cannot. Which means that the plasmoids that will be made available to automatic download through the NewStuff interface will only be the ones that are system agnostic.
As far as I understand it, Ocaml and Haskell do not fit this criteria, but I would happily be corrected.
Ocaml can be run under an interpreter ("ocaml"), actually.
I would be strongly interested in a projet to bring a good KDE and Qt support into OCaml, too. If some of you has more concrete ideas, i'd even try to help, but my lack of C++ knowledge is a real pain when it comes to KDE integration.
The different way i see are :
- scripting support with Kross
- kde binding using SWIG
- "silent" integration in some applications (ocaml code in the backend, like in kalzium or semantik)
If you're a Haskell fan, you could perhaps have a look at the Haskell-on-JVM thing : QtJambi may be the easier bridge here.
re different way, maybe add to the list;
- kde binding using Smoke
Smoke provides everything needed already and it should be imho easier to get bindings done using Smoke rather then SWIG. But in any case (so, whatever you like to use here, Smoke or Kross or ...) I would suggest to ask/talk about it before at the kde-bindings mailinglist.
In the meantime I came across the Qyoto/Kimono project, which aims to bring Qt/KDE bindings to C# and other .NET languages: http://cougarpc.net/qyoto/
With this in mind, there might be already a nearly-working-though-quite-convoluted way of integrating Ocaml with KDE:
- The language F# (which Microsoft pretty much copied straight from Ocaml) is part of .NET.
- The Qyoto/Kimono guys bring the Qt/KDE bindings for .NET.
- The Mono guys bring .NET for Linux.
Hmm... could this work? (Though using Smoke is still a better long-term solution).
"Though using Smoke is still a better long-term solution"
Well in fact Qyoto uses Smoke, and the code is based on the QtRuby code which in turn was based on the PerlQt code. We are quite close to a first release of Qyoto, and I've started working on the code generation for the Kimono KDE classes and that is looking good. We (Arno Rehn and myself) hope to have Kimono working by the time we give a talk at this years akademy.
Doing a complete binding for Qt/KDE is a heroic amount of work even using Smoke, and so I think that using F# is the best way to do KDE programming in a functional style. Another alternative is to try Scala with the QtJambi bindings and the JVM (and Nice?).
You are correct: Ocaml can indeed be run under an interpreter of sorts. It is in fact one of the more flexible languages around, since you can do the following with the same programme:
a) Compile to native code, nearly as fast as C/C++.
b) Compile to the bytecode of a VM, so the same binary can run in a very large number of platforms at fairly good speed, though not as fast as a).
c) Put the shebang #! at the beginning of the programme, and execute it as a script. Not as fast as a) or b), but excellent for scripting.
Anyway, me too, I am interested in bringing Ocaml goodness to KDE. Does anyone know if there are already any projects out there aiming for this?
In Kalzium we use OCaml (with libfacile) to solve a couple of eqautions. We do that because OCaml is _not_ needed on the users computers but only on comptiletime. So for the majority of us that means: My distributor needs to install it when he creates my deb/rpm-file.
Work on support for the Java language has started (see http://websvn.kde.org/trunk/playground/bindings/krossjava ). Thanks goes to google for sponsoring the development within there summer of code project and to all those KDE-developers out there for there fantastic work on KDE4.
> they would all be feeding out of the same data source
from the same DataEngine, which would be publishing one DataSource per timezone requested. so if 2 of the clocks were showing GMT and one was showing, say, CEST then the DataEngine would be publishing two DataSources, one for GMT and one for CEST, and two of the clocks would be getting their data from the former and the other from the latter. only one DataEngine would need to be in operation for this.
this is, in fact, how it already works =)
> Javascript does have a number of neat functional features
my goal is not to provide for language fetishism (don't worry, i suffer from it too ;), but to lower the barrier to entry. ocaml doesn't exactly help there =) that said, plasmoids are going to tend to be fairly simple things. individually, they aren't going to be full fledged applications. so languages like js are a fine fit.
> so languages like js are a fine fit
Don't get me wrong with the Ocaml vs. Javascript thing: I agree 100% with you that Javascript is indeed a very nice match for plasmoids. In fact, I have come to enjoy the language, after having an initial bad impression with it (that most programmers seem to share).
For me, there's only one thing sorely missing from Javascript: a strong type system. I have yet to find a good example that shows dynamic typing in a positive light. By this I mean an example where dynamic typing outweights its enormous disadvantages, and where the same thing could not be achieved in a type-safe manner via higher-order functions and/or parametric polymorphism à la Ocaml.
Thankfully, it seems (optional) type annotations will make their way into Javascript 2.0. Not nearly as sophisticated as types in functional languages, but a step in the right direction...
(And yes, I also agree that Ocaml is hardly the best choice for beginners. Though it's immensely rewarding for those willing to learn it!).
> I have yet to find a good example that shows dynamic typing
> in a positive light.
it's awesome for quick stuff, but surely sucks as you start to do almost anything resembling serious work. i haven't done much javascript, but with other dynamic typed languages i've had the pleasure of working with i've run into some real wtf's =)
> and where the same thing could not be achieved in a type-safe manner via higher-order functions
Correct me if I'm wrong, but that seems like a stupid definition. You can code absolutely everything in Assembler too, so why Ocaml? Although I have to confess I do not know this language, I guess the reason is just: Elegance leading to easier maintaining. Which is quite a good reason IMHO.
It might still be true you are right about weak typing, but your definiton for proving the contrary just sucks...
I don't think he's making a Turing tar pit argument. The point is that languages like OCaml frequently match the elegance that people typically claim for dynamically typed languages (like Javascript and Python), while retaining a static type system that's actually stronger than, say, C++.
So, the argument is: Why forgo the static safety checks by using Javascript (which, admittedly, can frequently be more concise than C++) when you can have both type safety *and* elegance with OCaml?
Have your cake and eat it, too.
> Correct me if I'm wrong, but that seems like a stupid definition.
You are wrong. Correction follows:
Don't confuse the universality of a Turing machine with the suitability of different languages for different tasks. Obviously you can implement any algorithm in whatever language you prefer, but that does not mean all languages are equally suitable for all tasks!
Real carefully my original statement: "I have yet to find a good example that shows dynamic typing in a positive light. By this I mean an example where dynamic typing outweights its enormous disadvantages, and where the same thing could not be achieved in a type-safe manner via higher-order functions and/or parametric polymorphism à la Ocaml".
Got it now?
>> For me, there's only one thing sorely missing from Javascript: a strong type system. I have yet to find a good example that shows dynamic typing in a positive light. By this I mean an example where dynamic typing outweights its enormous disadvantages, and where the same thing could not be achieved in a type-safe manner via higher-order functions and/or parametric polymorphism à la Ocaml.<<
I agree with you that the problem with Javascript is that it is weakly-typed. However, there are other dynamically-typed languages which don't suffer from that. Python is strongly-typed and type-safe and dynamically-typed. It's functions are first-class citizens, it's easy to write/use higher-order functions, and the type system is designed for parametric polymorphism through the use of duck-typing, instead of being designed to use a nominative type system like many other languages.
See: http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list
> However, there are other dynamically-typed languages which don't suffer
> from that. Python is strongly-typed and type-safe and dynamically-typed.
def foo(bar):
....if bar:
........return (1 + 2)
....else:
........return (1 + "screwed up")
Python accept this, and of course won't say anything unless you try foo(False).
What does "type-safe" mean to you ?
He's talking about strong vs weak typing and you're talking about dynamic vs static typing. I for one am tired of this confusion, go look it up.
>my goal is not to provide for language fetishism (don't worry, i suffer from it too ;), but to lower the barrier to entry.
I hope that means that I will be able to write a cool plasmoid in Ruby when KDE4 is out, that's what I'm learning it for since some time =) It's quite nice to learn, even for someone who doesn't know much about programming otherwise - I hope that works out.
When one is able to write/enhance Plasmoids and/or KDE programs with one of these so-called scripting languages, I'm sure that will bring some more people in who aren't coders but who are motivated enough to learn one of the easier languages like Ruby or Python because that gives them a very low entry barrier to participate.
there's a ruby kross .. uhm.. whatever they call it (backend?) so yeah, that should be possible, along with python
What about using Interview in qt4 instead of building a new MVC framework?
I know that the amount of data used by each plasmoid may not justify using interview but it could be worthwhile to investigate it.
Just my $0.02
Ben
I don't understand the news. Does this mean that webkit is (optionally) available within KDE and for example can be used in konqueror?
Thanks!
AFAIK, it is not yet possible but it's being worked on.
exactly; the goal is for it to be available as a full kpart but it's still a work in progress. go tronical, zack, george and friends!
I a kpart something konqueror can use when browsing the web like a rendering engine?
a kpart is something that any kde app can use to display data of a certain mimetype. many applications use khtml in this way, including kmail, akregator, amarok, kcontrol ..... so once the kpartization of webcore is done it can be used in all sorts of places.
there is some khtml specific in many of these apps that really needs to be abstracted out to an html rendering interface that all such parts can then provide, making the use of html rendering more generic.
and of course, webkit still has to integrate with a number of kde infrastructure components (cookiejars, wallets, etc)...
so much work left, but at least it is going... =)
does Webkit supports WYSIWYG?
thats really missing in KDE (And Konqueror)
> does Webkit supports WYSIWYG?
i don't know if the qt port of it is there yet, but safari certainly does.
Cool, thanks a lot for your time and explanation. It's really appreciated.
Also thanks a gazillion for you work on Plasma. Please don't get demoted from some of the comments. Just realize that some people have no insight in the framework and don't know that a clock is a proof of concept of the underlying framework and not the ultimate goal. I for one think the clock is extremely cool and when I realize that this is a proof of concept I really can't imagine what other great things will come.
Thanks!
OK, I'm a little confused now, so please bear with me :-)
I've seen various debates in the past over Webkit vs KHTML vs a merge of the two... Is the intent here to have the slightly hacky (I've heard) but highly functional Webkit engine as an alternative to KHTML, for those who can't wait for features to filter though?
as far as i've heard the goal is to eventually have WebKit (KJS and KHTML developed by apple) as the replacement for KHTML. fixes can than be made to WebKit benefitting both OSX and KDE communities.
first it will be available as option. logically.
but please forgive me if i'm wrong here.
Point is, some want what you write, others want to keep khtml and not merge with webkit, to stay in control.
So we'll have both available for some time, until one will clearly be the one used and/or developed most. Darwinism the FOSS way ;-)
FOSS=Darwinism :P
you know ...
"Open source is the ultimate expression of Darwinism, and evolution takes many forms, but one thing is for certain: There is no such thing as immortality for Linux, FreeBSD, or anything else for that matter."
Matthew Dillon
( from http://lists.freebsd.org/pipermail/freebsd-current/2003-July/006939.html )
At first sight I thought it was an "Heroes" quote :D
Why do you call Webkit "slightly hacky"? FUD?
i was able to see the first work done in plasma, in real, without even a direct internet connexion to my home, so thanks suse for your build service, and by he way for the first time, i got the pleasure to show a real new way of doing thing superior to my windows fanatic friend.
so thanks guy, you are making the future
Wow, that plasma demo is really nice. I'm very impressed by the architecture that asiego has talked about for Plasma, with the Data Engines and all that. It seems like a very slick and flexible way of doing things. With Kross too, it looks like a very bright future for Plasma.
I'm amazed at how fast things are going for Plasma now that things are coming together.
Reading through the Kwin composite hardware requirements [1] I wonder what the problem with Intel cards is supposed to be: the Intel drivers are most likely the best integrated and most advanced developed available. The free ATI drivers do not integrate with RandR 1.2 atm, for example.
Also, they do support everything to run AIGLX - and Beryl and such alikes.
So why is kwin-composite not working? What is different in kwin composite compared to Beryl or Compiz?
Btw., about Plasma: great to see the first visible results, I love it! I'm really looking forward to the engines and sources you developers will come up with!
liquidat
[1] http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/COMPOSITE_HOWTO?v...
KWin requires (for GL compositing) AIGLX, XGL or the proprietary nvidia driver. If these are not available, but XRender is, then certain effects will still work. If none of these are available, it'll be pretty much the same KWin you are used to from KDE 3.x...
I haven't gotten GL Compositing running on my system, but the XRender mode seems to work alright for me so far... I think it's just an X setting I need to change to make the GL stuff work.
KWin article in a few days - maybe tomorrow or wednesday... trying to put a little space between the digest an my article for maximum exposure of both :)
Cheers
GL for Kwin works fine here, tell me if you need screenshots or other things.