In this week's KDE Commit-Digest: Further XMP tag support in Digikam. Beginnings of a Plasma lock/logout applet and a weather applet, to display data from the existing weather data engine. Continued work on the new Plasma-based KNewsTicker applet. Continued work and development ideas in Parley. More various developments and optimisations in KHTML. Jamendo album download support in Amarok 2.0. Interface usability work in Kopete. Shredding functionality removed from KGPG. Fixes in the Sonnet spellchecking solution for KDE 4. Work on the foundations of KChart 2 in KOffice. Lancelot and Raptor develop as alternatives to the Kickoff menu of KDE 4.0. Okteta, a planned successor to KHexEdit, uploaded to playground/utils. KOffice 1.9.95 and KDE 4.0 Beta 4/KDE Platform RC1 are tagged for future release.
Comments
> especially considering that KDE3's menu didn't have that many options anyway
but it had one option that those three are missing - usable application menu :-p
... however, there should be one more alternative which will fix this for us evercomplaining; God(*) bless Robert Knight if he holds his promise
(*) whichever he prefers
Yep, and Dolphin is a Nautilus clone.
No intend to offend you, but these kind of comments are just nonconstructive considered as flaming by me.
In this context, I don't even see how you make that connection.
Then please wait and maybe run 3.5 and 4.X on the same system until its the right time to switch for you.
Delaying 4.0 until everyone is happy to switch from 3.5 is probably the slowest way of getting 4.X into shape.
Matt, I tend to think when someone says it will just work, that perhaps it should be delayed until it works the way they want it to work, rather than putting something out that isn't what they want, but is what they have to do to meet the release schedule. Just works put into my mind memories of the many press launches microsoft has held and had the blue screen of death appear. I only hope that when KDE offical launch this at the google launch, it is something they can be proud of, and that will draw users to it, rather than something that "just works"
It should be delayed until things work right, and not just work, which just reflects badly on the kde teams if they release crap that is full of bugs and not doing what it should do. I can go into any distro forum and ask if I should upgrade when kde4 is released, and always the same reply is that after the last major release people should wait til 4.1 because the last one was a nightmare full of bugs. Is that the kind of press kde4 wants if it just works?
The Trunk builds will have quite a few more deb depends for KDE 4 but with those accounted the SVN build process is starting to go a lot smoother. It's nice to see it come together.
I'm looking forward to it's release.
While there are some much great stuff in upcomming release, the Kickoff seems to be THE most disgusting one. Seriously.
If in 4.0stable it is only one i can choose, i will end up in switching back to fluxbox till Raptor or Lancelot gets stable. IMO Kickoff aint improvment .. its a step back =/
Your post is amazingly negative and at the same time uninformative.
Do tell *exactly* why kickoff doesn't work for you and it can be fixed. Don't do it (like you just did), and you're a lame troll demotivating those that do actual work.
I showed kickoff to my girlfriend yesterday, and she was really impressed (as I am, now I've given it some time). It looks good, performs rather well and you can find applications easily. (Type in "cd" if you want to burn a CD, for example, hoppa, there's k3b popping up. That's making the desktop and application accessible for those that didn't use it for years and happen to know about those app names.
Those that do not use the KDE 4 desktop on a regular basis should, at this point just shut up.
I'n not really fond of Kickoff either, mainly because browsing the applications is a pain. But then I have to admit that I've grown up with the old Windows menu, without being able to search etc - it's just about getting used to it, like everything else. And if you still don't like it, alternative menus are being developed.
Now back to my main point: [@mefisto] If Kickoff really is so "disgusting" as you describe it, and many agree with you, surly there has to be someone who can "port" the old KDE menu to Plasma? I don't know much about coding, but in my ears it doesn't sound too hard.
> it's just about getting used to it, like everything else
I do not agree, as for browsing applications ... but I would not repeat myself ;-)
the strenght of Kickoff is in reducing the need for browsing the applications - but for us used to fire up Krunner via alt+f2, kickoff brings no advancements in that field, so the ugly applications menu is all what is left ... and it is terrible to find out that the browsing experience is much worse than with classical KMenu
> surly there has to be someone who can "port" the old KDE menu to Plasma?
there should be reimplementation available soon - see http://bugs.kde.org/show_bug.cgi?id=150883
>> it's just about getting used to it, like everything else
>I do not agree...
Well, you should agree, as it is common consensus that a new way of doing something also means that you have to get used to it?!??! Very strange statement.
I also want to point out a point in favour of the oh-so-bad old application start menu: I could simple structure it the way I want to have it, and design and use it almost exactly the same way I structured and used the Windows-menus I unfortunately have to use at work.
Therefore I'm simply used to this kind of start menu both in work and at home, and I'm quick at using it.
This is not meant to troll about Kickoff, just expressing my hope that for dinosaurs like me a menu that is the same as it always has been will sooner or later be included in KDE4 ;).
> Well, you should agree, as it is common consensus that a new way
> of doing something also means that you have to get used to it?!??!
ok, let me explain:
let's pretend that I never used application menu before
now I am going to open 10 applications using the classical menu
then I am going to open 10 applications using the applications menu tab of Kickoff
repeat those steps 100 times - by that time I am "used to" Kickoff as well as to classical menu
but still, navigating applications menu in Kickoff is slower - so, it's not just the matter of "getting used to it"
I don't want to type in anything as my hand is on the mouse now I have to pick it up and use the keyboard??? I want a simple menu that is fast and is easy to find stuff. The classical Windows/KDE menu is that. Kickoff is far worse to find applications, you have to click all around multiple times to do something simple. I know Kickoff came from Suse and they supposedly did a usability study, I also know that one of the head people there is the original Gnome person. Would he not like to sabatoge KDE to make Gnome look like a better option, because Gnome is there long term plan, why else would you spend all those man hours porting YAST.
This is change for the purpose of change, not because something is better or more usable.
Your right!!! [sic] And the government is trying to hush it all up.
I'm not mefisto, but i'm working on KDE4, as many here, and i'm partialy using KDE4 and Suse with KDE 3.5 with kickoff to be familiar with this menu concept (even if it isn't the same code as the KDE4 one).
As i understand the several posts (here, ml, irc...), there are several way to use this kind of menu. Some guy likes type a search or the apps name, others are using always the same apps, so a dynamic "favorite" is perfect. There are also the perfect beginner, who doesn't know what to use... And there some people, and i'm part of them (maybe because i learnt computer with win95, 98, KDE... i don't know), which use and like a sorted apps menu to launch an app, with a very fastly mouse-over and 1 click, and no keyboard at all.
And kickoff, for us, kind of people which are maintly using the apps menu, is really a severe regression, when it is an improvement for others typing names or using favorite. We need 2 to 5x more time and click to launch an app. And with "severe regression", i mean it is really a pain to use.
That said, we can all give many big thanks to Robert Knight, because the fact are simple: Raptor or Lancelot will be not ready for 4.0. And because of him, and his really great work, we now have a working menu, and the 4.0 release will be possible. He deserve our total respect.
But KDE4 is not KDE4.0, the futur is not writen. (is it?):
- Raptor is developping interesting concepts, has a great dev&artists team..., planned usability tests
- Lancelot seems also developping interesting concepts, based on plasma (theme...)
- Kickoff could also be improved during the now->4.1 lifetime, taking care of the positive/negative feedback, and perhaps also put its best ideas in Lancelot and Raptor, which are using plasma technologies.
This doesn't deserve flamewars for me, because there are no choice, and Kickoff is a good tmp fix for a fucking big issue, before to see something better (Raptor? Lancelot? Kickoff v2?) for defaut, like Plastik replaced Keramik some time ago for theme.
Plenty of people have complained specifically about why Kickoff doesn't work for them (slow, needing to click several times, burying apps, etc) and they are rebuffed with "experts say it is better!"
I'm not opposed to including Kickoff, or porting it. I am opposed to it being the only option. Please give users the options for a base KMenu as well in KDE 4.0, and hopefully we'll have Raptor and Lancelot as well for 4.1
> the Kickoff seems to be THE most disgusting one
> IMO Kickoff aint improvment .. its a step back =/
please point your browser here: http://bugs.kde.org/show_bug.cgi?id=150883
do not be so negative and just tell Robert that you prefer classical menu, and so you are glad that he is going to include it - I guess he will be pleased that users praise his work ;-)
Dude... why switch to fluxbox? It's not like the developers are going to come knocking on your door to confiscate all copies of kde 3. You are allowed to just keep using kde 3 until kde 4 becomes settled enough for you (which may be 4.1 not 4.0).
But aanstelligen like you never seem to rely on common sense to inform their arguments...
Why?
Does that mean it is is removed because KGPG should not be able to shred files?
Greetings
strahler
"This feature was never related to GPG at all, is removed from KDElibs and had some security implications. Since it will not work at all from now on better completely remove it before users start to argue."
Advantage for those that bother to actually RTFA. :-)
And to explain the issue a bit better: this shredding doesn't work on modern filesystems, so it's useless anyway. Better not let the user have the illusion his files are shredded...
Could you define "modern"? On what filesystems does shredding actually work?
Fat16...
Won't work on any serious linux filesystem. There is no guarantee the FS will overwrite the file, if you write zero's into the file it's absolutely possible they will be written on an entirely different physical location - so you think you overwrote the file, but you have not.
what about the 'shred' command?
shred (1) - overwrite a file to hide its contents, and optionally delete it
shred(1) has the same problem - relies on overwriting in place. If you need this functionality, you'd better shred(1) whole partitions.
> i need a librarian to wander around shushing my classes up.
> "Ssshhhhhh! This is a library! There are other classes here
> trying to study!" you know, the kind with the sorta geeky glasses,
> hair bun and conservative clothes ... but cute.
>
> until then ... less debug output, please.
lol :)
What's planned for KDE4 application documentation?
Will there be a wiki of some sort to help improve it?
Hear! Hear!
KDE4 wiki of any sort right from the start (or even earlier) would be great improvement in communication and gethering momentum.
Hi.
Being a kubuntu user I tend to report my bugs at launchpad.net. If I report them there, but they need to get fixed upstream, do you guys who do the actual (excellent) work get to see the bugs?
I've reported a few.
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/156606
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/155676
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/153810
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/152935
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/152916
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/151303
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/128685
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/150555
https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/150536
While I could probably report the bugs in kde.org too, it's quite tedious to try to figure out where to report the bug just to be told that this isn't the right place. Ideally the distro should forward the bugs to where they should be if they can't handle them themselves.
Again, thanks for all your great work. When I get my paypal account I'll be sure to send some money your way.
Oscar
All kde apps have a Help/Bug report menu item.
Yes they do. And the first thing that happens when I click on it is that I must register my email to be able to submit a bugreport.
The problem isn't that I don't know how to do it, the problem is that I don't know if a bug that I see in my Kubuntu implementation of KDE is a kubuntu bug or a KDE bug.
> Ideally the distro should forward the bugs to where they should be if they can't handle them themselves.
This done for the distro by people like you who work on reporting bugs they find, and once they are familiar with the system, help sift through existing bugs and report them upstream if necessary (as well as other tasks).
There are several ways to know if a bug is an upstream bug or a distro bug. The easiest (but of course least accurate) is to use your intuition. The best is probably to compile KDE from SVN and compare. You can also try it in another distro. Or you can download the source deb and look at what patches kubuntu adds to see if there's anything in there that could be causing the bug (this also might help narrow down where the bug might be).
Reporting bugs on launchpad and on bugs.kde.org is fairly easy, and you can pretty much use the same text for both, so I don't think it's particularly tedious to report it in both places (at least not for you, the reporter ;) ). Just be sure to link the bugs to each other.
Oscar, as far as I can tell, there is a way to link the launchpad bug to the KDE bugzilla somehow and have the bug automatically sent upstream once it's confirmed to be an upstream issue. However, while the ubuntu people have ensured me that this feature does exist somewhere, I'm not sure how to set it up.
Cheers
Troy,
This is exactly what I wanted to hear. Thank you. Now I'll go "bug" some Ubuntu devs to get them to show me how I send my bugs upstream.
I do want to help. I'm just a bit lazy so I don't want to exert myself doing it. I'm hoping a little help with bug-reporting is better than nothing at all.
Yay for Kstars with the big fat telescope !!!!!!!!!!!!!!
professional APP!
I agree - that is an amazing hack!
Hear, hear, I thought no-one was going to mention it. Jasem, that seriously kicks ar$e, just about the ultimate KDE hack in my book :-) Today, Jasem's big telescope, tomorrow mpynes nu-cu-lear submarine: world domination is within our grasp!
Hello all,
the svn builds are getting better, plasma seems to be falling in place :) great work. There is one annoying problem with plasma, if one of the plasmoids segfaults due to a missing .so due to the plasmoid being unstable, plasma gets killed! plasma needs a bit more resilience from bad behaving plasmoids
+1
(frequently) compiling from SVN and watching the incredible rate of change has been a privilege! For a long time, every build I did contained an incredible number of new features and toys to play with. Now, things are getting more and more solid (the description of stable, not the KDE4 hardware system ;) and particularly since the last time I built everything is noticeably faster. I too have had plasma implode on occasion but I'm sure we're not alone in that and that a fix is on the way. Great Stuff!
PS. for those doing frequent rebuilds like myself, one thing i find handy is to occasionally nuke the ~/.kde4 dir (obviously as this is build from svn stuff there is nothing of permanent value in here for me at this stage) as it seems to help to rollback all my fiddling around that has accumulated in app settings etc and get a nice fresh set of default settings. YMMV
Borker great tip about refreshing the .kde4 directory :) I actually cleanup all the .* files from the kdedevel before trying out the next build. btw it still seems oxygen is not the default theme/style, make it default so more oxygen bugs/improvements can be suggested, not that important though as i change it after the settings get wiped off :)
first, it doesn't segfault due to a missing .so. it fails to load the object and says so.
however, a c++ based plasmoid going under will take plasma with it ... and plasma will attempt to restart itself at that point. there is little that can be done about that since running the plugins out of process is simply not an option.
this is why we will be encouraging people to write plasmoids in non-c++ languages as much as possible.
about non-c++ languages: is it currently possible to write a plasmoid in ruby? i checked the techbase, but couldn't find anything about the current state of the ruby plasma bindings. am i missing something?
The Ruby plasma bindings aren't usuable yet. The ruby version of the clock runs for about two minutes fine, and then a virtual method callback like Plasma::Applet.contentSizeHint() will fail. That throws a Ruby exception which isn't handled, and it causes Plasma to crash.
So the apparent memory corruption problem that causes the virtual method callbacks needs to be fixed. I not sure what is causing it because it doesn't happen when QtRuby or Korundum apps are run in stand alone mode. Secondly, the bindings runtime needs to handle Ruby exceptions more gracefully, and only terminate the Ruby applet and not the entire Plasma process.
Maybe the Ruby version of the Kross api will end up working better in practice, and there will be no need for a more complete implementation of the entire C++ api in Ruby. I haven't an opinion either way, but I do think it is very important to be able to write Plasma applets in Ruby.
That's really bad news, even more that the idea is that not only KDE guys, but others write plasmoids.
Now think about installing a nice and fresh weather plasmoid and suddenly you loose the panel, application menu, launcher, desktop wallpaper and icons...
To me, it sounds a bad idea all those fundamental items depend on plasma, I always thought from the start one plasmoid dying woouldn't kill others (in any case, users don't care if plasmoids are python, c, php or c++). :-(
But I hope the users pressure will eventually make things different.
As Aaron said, people will be encouraged to use scripting languages for their Plasmoids (which gives the additional advantage of being easily installed via GetHotNewStuff) as these will not have this problem, or will have it to far a lesser degree. Using C++ plasmoids should be no less stable than using C++ applets in the old kicker.
"But I hope the users pressure will eventually make things different."
Since this is a very fundamental design choice, I wouldn't get your hopes up :) Running stuff out-of-process gobbles up a lot more RAM, too.
I may be mistaken, but say a Plasma applet on the desktop crashing won't take out the Panel (and thus the Application menu) or the launcher (KRunner) because they're separate processes (but use libplasma internally).
I think there will be three processes:
1.) The desktop/wallpaper (i.e. KDesktop now)
2.) The panel/application menu (Kicker now)
3.) The 'launcher' aka KRunner(alt+f2 dialog on steroids + lock screen + maybe more?)
So if anything, you'll be in a better situation than in KDE3 (KDesktop going down would take the Run Command dialog down with it currently).
****** Apply patch by ereslibre to remove the "all network operations in a single window" option, currently broken anyway since kuiserver isn't even called anymore. (so much for all the hype around kuiserver...)
Kuiserver, is that that thing which was supposed to show all 'progress' things going on in the whole system, allowing to have them aggregated in one place? I was looking forward to that, but it seems dead... KGet does everything by itself (even has a plasma applet), and it seems the most important user of such a thing. Pitty, it sounded a sane solution to all the separate progress viewing/reporting/notification implementations (kget, ktorrent, k3b, ark etc etc). What happened with this plan/app/tool?
I'm also interested in this - I thought it was hooked into KJob, so that all KJob-using classes benefitted from it "automagically", as it were?
Amarok at some point used it, and now it seems gone. I wonder what the outcome will be...
That was a feature I was looking forward to, what a shame