In this week's KDE Commit-Digest: Heavy refactoring and work on merging translation branches in Lokalize (which is renamed from "Kaider", and moved from playground to kdesdk). Work on a question editor in KEduca. Work on real-time cloud imagery in Marble. An initial implementation of a new undo stack in KWordQuiz. The start of a KAlgebra, Rot13, KWorldClock, and Pastebin Plasma applet, with the inclusion of more functionality from KDE 3.5 (such as the multi-row taskbar panel) in Plasma. Progress in scripting support and functionality in Plasma. The "Now Playing" data engine and applet, and the fuzzy-clock Plasma applet move into kdereview. Viewports support declared "complete" on the KDE desktop. "FlipSwitch" window-switching effect in KWin. The start of a KIO slave for handling arbitrary NEPOMUK resources. Draft implementation of a KABC resource based on Akonadi. Wholesale merges from the enterprise branch of KDE-PIM back into the main KDE branch. Move to complete support for the MPRIS media player interaction standard, and support for Video CD's and Audio CD's in Dragon Player. Dragon Player moves from kdereview into kdemultimedia for KDE 4.1. Last.fm streaming radio now works in Amarok 2. Work on gradient editing in Karbon. The Kooka scanning application finds a new maintainer, with various initial improvements. KSystemLog moves from playground into kdereview. Krone, a simple expense manager for KDE 4, is added to KDE SVN. Read the rest of the Digest here.
Comments
While you're at it, you could add the cube too, I think it uses 3D too :)
yeah.. having a cube like in compiz would be amazing.. I'm really missing it... but before this can be added I think that the overall performance of kwin-composite must be improved... at least on my ATI X700 with the latest fglrx it's unbearable slow :-(
but nonetheless: great work kde guys!
I've been toying for a while with the idea of having a KWin Effect Competition with a small cash award as the prize and the Oxygen guys as judges. It might prove burdensome for Seli, Rivo and the Oxygen fellows, though :(
I think that's a great idea - I would definitely donate a little cash towards it. I think there should be a competition for plasmoids as well though, it would help the kde 4 desktop reach feature parity with 3.5 a lot quicker and also help encourage much of the innovation we have been hearing a lot about.
+1
good idea, lets do a fundraiser first and then the competition.
Yes!! Please port the rest of compiz over to Kwin.
I REALLY miss the effects.
Cube, expose, coverflow, among others.
kwin has an expose-like effect already, no?
Please:
At the very least make parity to the effects and speed compiz fusion has. At the best add speed and add original effects.
People love the effects. I hope in the future they will be turned on by default if the system is capable of handling them. (distro's are you listening?)
Thank you Danny :)
First off, the KDE4 K3B port looks amazing!
I was wondering about the icon overlays that were mentioned in the "KDE 4.1 Feature Plan": http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Feature_Plan
This means *ALL* icons will have the overlay not just the ones on the desktop? Does this mean Plasmoids are actually going to be inside Dolphin?
The overlay for desktop icons will have features that the Dolphin overlay wouldn't need, like resizing and rotating. Chances are they'll be separate overlays anyway, since it would be silly to have a Plasma dependency in Dolphin.
Also nice to see that Raptor is confirmed (to be aiming) for 4.1, I'm excited to see it action with the plans they have for it.
I don't see why a feature like rotation is necessary in one place, but not in others. Besides, it generally shows better design when features are orthogonal to where they're used.
> This means *ALL* icons will have the overlay not
> just the ones on the desktop?
No, currently we just try finding a solution for Dolphin/Konqueror to select files in the single-click mode in an easy way. It has not been decided yet about adding other overlays too (from the current point of view I'd say that there is no need for this). BTW: this feature can also be turned off...
> Does this mean Plasmoids are actually going to be inside Dolphin?
Technically no, but for sure we'll try to stay consistent from the look and feel where it makes sense. Plasma raises the bar for applications making things visually handsome :-)
I think this is a solution to a non-problem. I mean, what use is selecting something if you don't then do something with it? (drag, copy, delete etc). All the possible actions one could want to take are available in the right click menu. Including (potentially) right click -> select, if you really do just want to select a file and then do nothing with it.
I'd prefer to leave the whole icon available for opening the file, and if one wants to take a specific other action, right click.
And besides, one can already easily select (and then do nothing with) an icon in single click mode. If in detailed list view, click anywhere on its row except for its name (it in blank space next to name, on the date etc). There was a justified bug report made when things were changes to a single click anywhere on the row opened the file and it was changed back and works now as well as before. If in icon view, lasso a single icon.
The old ways are a bit clunky, but are they broken enough to cut the target size of an icon to a third when the right click menu does everything one would need? I mean seriously, hover over an icon then select "actions"? I doubt many KDE users are going to be using old one button apple mice.
I strongly disagree. I find it a lot easier to press the Del key than aim at the delete option in the context menu. Muscle memory.
That said, the icon-overlay solution sounds too clunky and I'm pretty sure using it wouldn't be fun. Actually, my ideal selection method would be middleclicking.
"The Kooka scanning application finds a new maintainer, with various initial improvements."
What? I read it over and over again. There is a new maintainer? To bad that there is no information on the Kooka homepage. However, I'm really glad to hear this!
BTW, any news about Decibel?
Having recently acquired a wonderful new scanner and then finding that it didn't work with Kooka, I've volunteered to step in and maintain/update that application. It won't reappear in kdegraphics until it has been ported to KDE4 and gone through the review process, but if you are interested you can compile from SVN (branches/work/kooka-kde3) and try it out. Any feedback will be appreciated!
I'm concentrating on the code so far rather than the web pages, but that will get updated sometime...
Hi Jonathan,
thanks for the kind reply. Now there is a name. I'm glad that your scanner was not working with Kooka. :)
Right know I'm using Kooka the way it is since this tool is working quite well for me. Thus I don't know if I'll find the time to give you some feedback (sorry) unless I stumble in a serious issue with the current version. But I certainly will dig through SVN some time (maybe today ;) ).
About the web page. Of course there is no need to hurry or so. You will certainly publish some information when Kooka is in the appropriate shape.
Kind regards & keep up the good work.
jimB
Well done for jumping in as maintainer!
I've dabbled a bit in libkscan and kooka. Reported some memory problems a while ago and recently added a photocopy button on one of the drop down menus, even though I'm a bit of a newbie with qt.
Can I be of any help?
Regards
Alex
Thank you for keeping this project alive!!
I know there is probably a lot of other basic stuff that needs to be updated first, but is there any chance we will see the Tesseract and OCRopus projects from Google integrated for better OCR capabilities?
http://code.google.com/p/ocropus/
http://code.google.com/p/tesseract-ocr/
Personally I don't like the Vista effect, but I'm sure it'll make some happy. Great work!
While reading that part of the digest, I thought of a new window-switching effect. Just a crazy idea that popped up, I haven't given it enough thought yet; but hey, let's share it and see what you think.
I think one word is enough to describe the effect, as it has become quite known: Coverflow. Or, should I say "Windowflow"? ;)
Do'h. Just did some searching, and it seems that effect already exists in Compiz:
http://artipc10.vub.ac.be/serendipity/uploads/screenshots/mandriva2008/k...
http://www.youtube.com/watch?v=xBRRe2PP4CY
But still, wouldn't it be a nice effect for KWin? =)
plz dude, no more effects, stop dillusioning, on this or that supercalifantastickool effect, there are way other stuff to be done first to have all the *bling* working at full throttle , i.e, projector Hotplugging, blank sync, rendering, namely.
KDE devs: Don't listen to the trolls !!, after all kde will win in the long run, there is nothing more appealing than plus+ functional desktop.
I'm really tired of the meme "just works".
For instance compiz is super fast and nice, but it's cramped of glitches.
Sure from most users standpoint (and maybe some programmers), it's perfect, gives all the bling it promises, it's state-of-the-art-code. But what about when you browse a flash web and the cpu spikes % 100 usage ?? hehe, not so "state-of-the-art",I guess... maybe compiz category should be degraded to : "maybe works", or works best web pages flash where the it's colour is apricot.
And don't get me wrong I like compiz a lot.
ppl will fall out over the time.
Kwin really does lot more, it has less bugs and does lot more for day to day usability.
We need stuff that works great, and usefull also, (err shouldn't that be named! ;) "program")...that's the word
NOT a demo-ware!!
Before Cube and all this things are implemented, i would very much like the idea of nice and smooth blend-in and blend-out, just like in KDE3 but faster and with less bugs.
>> KDE devs: Don't listen to the trolls !!,
Uh? Was the troll part directed at me? I don't see how I'm trolling - if my post really offended you, please tell me how and, if it makes sense, I'll try to avoid it in the future. To me, giving a suggestion != trolling.
>> plz dude, no more effects, stop dillusioning, on this or that supercalifantastickool effect, there are way other stuff to be done first to have all the *bling* working at full throttle , i.e, projector Hotplugging, blank sync, rendering, namely.
Plz dude, I don't think you're the one to tell what the developers should be working on. Sure, some things are more important to users, but AFAIK the developers are still free to work on what they want.
In this case, we have someone who knows OpenGL and has implanted the first(?) 3D KWin effect. If that's what he like to do, should we stop him and rattle off things that are "more important" than "*bling*"?
That's what I would call trolling.
I never said that I _must_ have that effect, nor did I say that it was fantastic. I just gave a mere suggestion, and if you don't like it, why not just ignore it or at give some constructive critic.
>>Uh? Was the troll part directed at me?
nah, it was not specifically directed to you, it's just the general climate on the bling o-factor ;-)
please of course... come on everyone is free to do whatever till heart content == open source!,
You know everyone rambles on the same subject ..."I want widgets to do xxx, I want windows to fly that xx way, etc ,etc."..
IMHO _boring_!
Didn't not intented trolling, you really twisted what I said.
>>Plz dude, I don't think you're the one to tell what the developers should be working on
hmm, sorry, you are right and I am wrong, I am an ugly, stinky and stupid troll.
Anyways as a matter of fact I do have a constructive critic.
The compiz guys already started their decorator port of Kwin/Kde4,
http://gitweb.compiz-fusion.org/?p=compiz;a=commit;h=176a81107c9b7743985...
http://gitweb.compiz-fusion.org/?p=compiz;a=commit;h=d29094df5fcc0c0e1eb...
why have a duplicate list of excentric complex features requests, it's just too much, why don't just leave the hard ones to them ?
>> Plz dude, I don't think you're the one to tell what the developers should be
>> working on
> hmm, sorry, you are right and I am wrong, I am an ugly, stinky and stupid
> troll
What am I missing here?
Users have every right to tell developers what they think about the project. I think that it is called FREE SPEECH! Nobody said that the developers have to listen to the users (only that it would be a good idea if they did so). Developers can be as arrogant as they want, but the question is what the intention of the KDE project is. Do we intend to make a usable DeskTop to be used by the public, or is it just to amuse the developers? I really doubt that, in the long run, a project that continues to be partially done, and with serious quality issues, will be successful with anyone other than *NIX Geeks.
Maybe I was unclear, and I apologize if it offended anyone. However, that is my point of view:
"Users have every right to tell developers what they think about the project." Yeah, I completely agree. But that's not what I meant; you can't _force_ developers to do anything. That's what it all boils down to.
I gave a suggestion of what I think could be a neat effect. And joekey1 responded with, what sounded to me like, "shut up troll, the developers should work on making KDE more stable". Could be because of my (lack of) English skill, but that's how I interpreted his post.
While I agree that stability is more important than bling, I still want to stand by my point: users are free to give suggestions, constructive critic etc, but shouldn't decide what the developers have to work on. If someone likes to implant KWin effects, should we force him/her to fix bugs in KDElibs instead?
If you find something unstable, you're free to report bugs or get the devs' attention in other ways; but you can't force anyone to fix that bug, can you?
> ... you can't force anyone to fix that bug, can you?
No, users can't. However, the developers need to take steps to see that more bugs are fixed and fixed quicker. I leave it to the developers to decide how to organize a quality management group. All that I can say is that it needs to be done, and soon.
What trolling are you talking about?
People like eye-candy. And while it may not help productivity for certain effects, people still like them.
"People like eye-candy. And while it may not help productivity for certain effects, people still like them."
SOME people like eye candy. SOME people don't like eye candy and probably a lot of people don't care. I don't like it because:
1. KDE4 is far from being finished and there are things much more important for the developers to focus on like getting the configuration tools finished and working properly.
2. I'm concerned about bloat. The RAM usage on my machine using KDE4 is more than twice what it is using KDE3. My machine can handle it (2 GB RAM) but my wife's machine (512 MB) will start to hit limits and the VM will start running which will slow her machine down. Some people say just buy more RAM because RAM is cheap. DDR2 RAM is cheap now but the older type of RAM that my wifes machine needs isn't. I showed KDE4 to my wife and she likes it but there's no way she'll want me to put it on her machine if it means we have to buy a new machine for her or spend a lot of money upgrading the RAM. If I see the memory footprint drop later then I'll probably put KDE4 on her machine otherwise I won't. There must be a lot of other people in that same situation that have machines about 7 years old and are now using KDE3 but won't use KDE4 because it's too bloated.
The only special effect I like is the magnify feature that sometimes makes it easier to read or see objects. I hope the developers don't add more eye candy to KDE4. Please make it reliable, implement the configuration features we need and reduce the memory footprint if you can.
You worry about bloat when every KWin animation is a separate plugin, which is only loaded if you've enabled it?
...
:-p
I don't know how the animations are implemented but one thing for sure KDE4 does take a lot more memory than KDE3. I'd rather see the developers working on finishing KDE4 and making it work right and reducing the footprint than working on unimportant things.
Most of the extra memory usage comes from Qt4's double-buffering of widgets, which virtually eliminates flickering. It's a design choice, so if you disagree with it, take it up with TT - it's largely out of KDE's hands.
And correct me if I'm wrong, but won't the next QT release (4.4?) fix this?
I don't know, to be honest: I'd *imagine* "Alien" would reduce the need for double-buffering when resizing and such, but I'm not sure if it would be so effective that TT would turn double-buffering off. My guess is "no" :/
Yes. I second that.
Eye candy was the whole reason I dumped Vista and went over to linux.
If it weren't for compiz fusion's effects I wouldn't have bothered.
There just isn't the same amount of eye candy (and useful eye candy) on ANY other operating sytem at the moment.
Now I love linux.
You are right about the functionality and getting KWin to work more perfectly before introducing more blings but I think that it's unfaif to describe peoply as trolls just because they request more blings.
T am a very loyal KDE user and I can wait but to tell you the truth, I also miss some of Compiz-Fusion's blings. Some are overkill but some are just breathtaking beautiful and also useful.
I too hope to see some of these useful effects/functions implemented in KWIN 4 as an option for those who love them :)
I allready have a little bit of this Coverflow (but called it ringswitch). It is not yet committed as there are still some things to do :-) Give me some more weeks then I think it will be ready, but actual sources can be find in KWin mailing list.
Martin, you rock! :)
I tried the FlipSwitch, and it's very smooth. However, when using it I found some small issues such as:
- With only two windows, the animation was a little bit weird. I hope you notice what's wrong, as I don't know how to explain it. "Back and forth" is the best description I can think of.
- Hold down and (given that you have keyboard repeat enabled). Just hold for some seconds and then release the keys. The animation doesn't stop, it'll continue for a while without any apparent method to stop it.
- And finally: better support for multiple monitors. Right now it's between my two screens, which is a little bit annoying (because of the "gap").
Otherwise it works very good, great job! Do you want me to file these issues bugs at bugs.kde.org?
Thank's for the feedback :-D
>> With only two windows, the animation was a little bit weird. I hope you notice what's wrong, as I don't know how to explain it. "Back and forth" is the best description I can think of.
I know, but I liked it that way, so I did not try anything to fix this issue ;-) Perhaps I'll do something about it. At the moment: "It's not a bug - it's a feature" :-D
>> Hold down and (given that you have keyboard repeat enabled). Just hold for some seconds and then release the keys. The animation doesn't stop, it'll continue for a while without any apparent method to stop it.
Actually there is a method for it. The animation will continue until the correct window is selected. Ok, I have never tried with holding both keys at the same time. I don't know if this is a real usecase ;-) If you press in a moderate way the animation will continue correctly. By the way - just tested: boxswitch does not work correctly with this use case, too.
>> And finally: better support for multiple monitors. Right now it's between my two screens, which is a little bit annoying (because of the "gap").
That's bad. I only have one screen and of course not tested with two. What are you using? Xinerma or something like that? But I think I know the problem. I'll test it with my laptop and try to fix it :-)
>> Hold down and (given that you have keyboard repeat enabled). Just hold for some seconds and then release the keys. The animation doesn't stop, it'll continue for a while without any apparent method to stop it.
Just fixed this bug with revision 770090. Thank's for the hint ;-)
>> "It's not a bug - it's a feature" :-D
Haha, fully acceptable.
>> Just fixed this bug with revision 770090. Thank's for the hint ;-)
Did I mention that you rock?
>> That's bad. I only have one screen and of course not tested with two. What are you using? Xinerma or something like that? But I think I know the problem. I'll test it with my laptop and try to fix it :-)
I use Nvidia's twinview, a snippet from my xorg.conf:
Section "Device"
Identifier "Device0"
Driver "nvidia"
Option "TwinView" "True"
Option "TwinViewOrientation" "RightOf"
Option "UseEdidFreqs" "True"
Option "MetaModes" "1280x1024, 1280x1024; NULL, 1152x864; NULL, 1024
x768; NULL, 800x600; NULL, 640x480"
Option "UseDisplayDevice" "CRT, DFP"
Option "TwinViewXineramaInfoOrder" "DFP-0"
Option "AddARGBGLXVisuals" "true"
Option "DisableGLXRootClipping" "true"
Option "RenderAccel" "true"
Option "AllowGLXWithComposite" "true"
Option "TripleBuffer" "true"
EndSection
will k3b now be renamed to k4b (kde 4 burning)?
or what does k3b actually stand for?
I never got it...
http://dot.kde.org/1145245411/1145247602/
ah, thanks
I would like if they put the old progress icon back instead of the new big progress-bar...
Don't get me wrong, but isn't fixing A LOT of bugs more important than implementing new functionality to apps? I (and many, many users) will never be able to use those new versions of apps as long as the core of KDE is not stable enough. And that's not good at all.
"Don't get me wrong, but isn't fixing A LOT of bugs more important than implementing new functionality to apps?"
This may blow your mind, but many devs can do both of these things at once! Also, KDE is a volunteer-driven project, so people will work on what they want: it's all very well to say "people should be fixing bugs in KDE before adding features to apps", but how are you going to make it happen? Also also, the people working on apps probably aren't the same people working on KDE core, and may have none of the competencies that the libs hackers require - lib and app work is often very different and require different skillsets.