In this week's KDE Commit-Digest: Plasma applets can now be dragged from the desktop to the panel. More internet data sources for the Picture Frame and Comic Plasmoids. Configuration dialogs are added to many Plasmoids. The in-development "WorldClock" Plasmoid supercedes the KWorldClock standalone application. A new Plasma applet: Conway's Game of Life. KRunner becomes completely plugin-based. Support for editing GPS track lists in Digikam. More work on expanding theming capabilities across KDE games. A variety of enhancements in KOrganizer. Initial work on a web interface to control downloads in KGet. Work on paths and snap guides in Karbon. A HTML part plugin in the scripting application creator, Kommander. Mono (C#) KDE bindings reach a usable state. Python support in KDevelop4. A return to development work on Decibel. KMail gets a new maintainer, with already-noticeable improvements. KBluetooth and KRecipes begin to be ported to KDE 4. The game Kollision moves from playground/games to kdereview. A new game, KDiamond, is imported into KDE SVN. Read the rest of the Digest here.
Comments
Well, contrary to Sebastian above, there are definitely some features I would like to see re-implemented in KDE4.
I've been using KDE 4.0.62 several hours to do my usual work on it and noticed some stuff I really miss :
- I use quite a lot the "Copy to" and "Move to" entries in the contextual menus in Konqueror, especially when browsing FTP sites. Having the possibility to browse through my entire tree to select the target is an extremely handy feature IMO. To my dismay, this does not seem to be available in either Dolphin or Konqueror anymore, and this is really a shame, as I find this feature much more useful than KGet.
- The Google/Wikipedia/etc search menu in Konq has really become for me a must have, and I find it really sad that it's not available yet.
- Having the possibility to have a specific wallpaper for each virtual desktop is not just an aesthetic feature : it allows you to know all the time on which desktop you are without even thinking.
- I've seen that the taskbar can be resized in height (good) but I really hope that in the end, it can also be resize in width. With 16:9 screens, I really appreciate to be able to contentrate the taskbar in a reduced width.
- It seems to me that it is possible to change the default file manager from Dolphin to Konqueror. Unfortunately, I've not found yet how to do that. And that's too bad as after using both, I definitely prefer Konq as a file manager.
On the plus side, now that I can use composite, I must say that I really like the Expose and Desktop Grid effect : fast and efficient. :-)
> I use quite a lot the "Copy to" and "Move to" entries in the contextual menus in Konqueror
...
> To my dismay, this does not seem to be available in either
> Dolphin or Konqueror anymore, and this is really a shame
We are aware about this and will do our best to reintroduce this feature again for KDE 4.1. The reason that it was not available anymore in KDE 4.0 was mainly because we've been running out of time to port this from KDE 3.x.
> It seems to me that it is possible to change the default file manager
> from Dolphin to Konqueror. Unfortunately, I've not found yet how to
> do that. And that's too bad as after using both, I definitely prefer
> Konq as a file manager.
Yes, we should fix this too for 4.1... As a temporary solution: the Dolphin handbook has not been updated for the KDE 4 version of Dolphin and provides a description for KDE 3 how to make Dolphin the default manager. This should now also be valid the other way round: how to make Konqueror the default file manager. So please open Dolphin, open the Dolphin Handbook (F1), go to "5. Frequently Asked Questions" and "5.2. How do I make Dolphin my default manager". Hope this helps :-)
Thanks for the info. The time problem is an issue I perfectly understand. ;-)
Just to be clear, the reasons I would like to switch back to Konq as a file manager is not to be viewed as a critic of Dolphin, it's just that I use my file manager a lot with explorer-like view, using URLs with many filters (like "*.jpg") in it and I felt I was more at ease with Konq. But there are things in Dolphin I really like too (the grouping of different files by type is really nice). I understood I would get them in the KDE4 konq also, so all the best. :-)
> But there are things in Dolphin I really like too
> (the grouping of different files by type is really nice).
> I understood I would get them in the KDE4 konq also, so all the best. :-)
Thanks :-) The grouping features and all other view-dependent features from Dolphin will be available in KDE 4.0.2 also for Konqueror (David Faure has already backported those things).
I would appreciate it a lot if Dolphin also had the File Associations KCM embedded as a configuration dialog page. I use to adapt, tweak and change those associations regularly, and have stumbled over the lack of file associations in Dolphin a few times already, even if I don't (yet) use it as my primary file manager.
If you don't know that this stuff lies around in System Settings' "Advanced" tab then you're completely lost on this matter. Sounds like an easy fix?
Oh, and thanks for lingering around on the dot, Peter... I think it really shows in the quality of Dolphin's user interface :)
Hm... guess I don't want to belong to the "reports bugs only on the Dot" group, so: http://bugs.kde.org/show_bug.cgi?id=151094
That bug suggests that this is supposed to exist since December at least, but I still can't find any file association configuration in my Dolphin (on Kubuntu's KDE 4.0.1). Hm, strange.
I've reopened the bug and added to my TODO-list :-)
btw, you can quickly open this in krunner by typing "filetype" or "file associations" or just "association" (the latter is currently broken in trunk due to my recent fiddlings =)
> The Google/Wikipedia/etc search menu in Konq has really become for me a must have, and I find it really sad that it's not available yet.
it's in extragear/base. if you want to use it, you have to compile it too. there's also a crashmanager that let you restore tabs after a chrash, but it seems to be broken atm
regarding the defaul file manager. right clickt on a folder -> preferences and then click on the little wrench on the right, in the same line as "Type: folder". from there put konqueror at the top and it should work
Thanks for the info regarding Google search.
> regarding the defaul file manager. right clickt on a folder -> preferences
> and then click on the little wrench on the right, in the same line as "Type:
> folder". from there put konqueror at the top and it should work
Damn, I should have thought about that. Thanks!
Regarding the search bar, I suggest using the keyword shortcuts, or whatever they're called in konqueror.
Just type: "ctrl+L" then "gg: " and whatever you want to search.
"wp:" does wikipedia, and there are many others.
It makes for a cleaner interface, and I find it's much faster.
PS. Konqueror developers: it would be nice to right click a search field on a webpage, and choose "Create Search" from the context menu. I don't know if that's implemented yet.
One of the features I liked most in KDE3 was the hability to set a global key shortcut to any app in the menu.
Is there plans to bring this feature back into kde4 or it is out for "good"?
I miss opening dlphin with win+e ;)
++ - would also like to see this make a return. It's a great usability feature!
Huh? As far as I know, that ability has been in Kde4 from the beginning, though it didn't work flawlessly pre 4.0.1
It's in system-settings under "advanced" (or whatever the tab is labeled in english). The dialog is very similar to the one from Kde3. I've set win+d to start Dolphin. Seems more fitting.
I think they are speaking about KMenuEdit and not SystemSettings.
That is correct.
Yep. In kmenuedit you can set a keyboard shortcut that will run/open an application (like win+f for firefox).
KDE4 removed those, but left some global keys and removed a bunch (like win+D to show desktop) while adding new ones (mostly for plasma).
s,plasma,kwin,
Can I add my pet request for Dolphin? ;)
When I have a directory open in details view and sorted by name, I can just start typing letters to jump to files starting with that letter. That works, except that the view jumps to file, but the file is not highlighted, so I get confused and have to still search for it in the visible files. It would be nice if the first match got highlighted, so if I type "test" it would jump to the first file starting with "test" (as it does) and also highlight that file (which it currently does not, but just about every other file manager does).
I'll report a bug on this if you don't already know about it... I didn't see anything related in the bug database.
Otherwise Dolphin rocks. Thank you for this great app :) I really liked konqueror back in KDE3, but it was just way too complex most of the time. Dolphin is much better suited to the task of file management, without losing the powerful features that made Konq good for me.
Please, report that feature request in bugs.kde.org. ;)
> Can I add my pet request for Dolphin? ;)
Sure ;-)
> That works, except that the view jumps to file, but the file is not highlighted
This issue is on my internal TODO list quite some time and I'll try to fix it during this week.
> Otherwise Dolphin rocks. Thank you for this great app :)
Thanks! We are currently also taking care that Konqueror gets back all features it had in KDE 3 (e. g. on the weekend we added a tree-support for the details view).
> This issue is on my internal TODO list quite some time and I'll try to fix it during this week.
This is fixed now on trunk.
Piggybacking on your request...
Wouldn't it be nicer if typing in a few keystrokes automatically highlighted ALL matching files in the current folder/view?
That way I could, say, type in "IMG" and then all of "IMG0001.jpg", "IMG0002.jpg", etc. would be readily selected to be dragged onto another folder, opened in Krita, or whatever..
That could be further refined with wildcards or even regular expressions (!).
I could also post this wish to bugs.kde.org as a follow-up on yours, if you like the idea.
Makes it easier to select multiple files with the same prefix.
Makes it harder to select a single file.
I would rather have the latter.
Well if you want to see all the files, then I think what you want is the filter function. Ctrl+i and start typing.
For the single highlight, my usecase is to go into a folder looking for a file I know the name of and want to open. So I know I want to open "weddingsongs.txt" and I just type wed in the folder, it jumps me down to where I want (or very close to it) and I hit enter to open it. After that I'm done with it, and really don't want a filter active in the directory or anything else. Also most lists allow this type of navigation so it's very consistent.
Thanks Peter by the way for your response! I look forward to future versions of Dolphin.
Is it just me, or do other also think plasmoids are beginning to look more and more like.....normal windows? I mean, if I look at al the stuff that get's added to it, it seem like properties for a normal window app. Resizing, DnD, Widget's, etc. Then why not give up the whole idea of plasmoids en make them little "normal" apps with some extra features like noborders, etc? What is the use-case?
Amen to that.
I never saw the need to replace the whole desktop stack just because the old panel (kicker) had a messy codebase and was difficult to maintain. Then again, I never liked the concept of "widgets" (not just in KDE, but also Apple's or Vista ones).
To me, applications are just applications, no matter how heavy or lightweight they are. Artificially calling them "plasmoids" and then putting them under a completely different interaction paradigm goes against well-accepted usability laws (i.e. it introduces "modes").
I remember having seen a paper on a new concept of "layered" window groups. The window manager would keep separate "layers" of applications according to their intended usage, eg: one layer for the usual workhorse apps, another one for little accessories (calculators, clocks, weather applets...), another one for background tasks (eg: Amarok). The user would then be able to choose what applications he/she would like to see on which layers, and whole layers could be brought to the front, pushed to the back, hidden, etc.
That's a cool idea because it would be 100% orthogonal to the concept of virtual desktops. Of course, the resulting interface could turn a bit too complex for most typical usage patterns.
But then again, the same idea could have been easily implemented just with virtual desktops: Desktop #1 is for work, Desktop #2 is for utils, and so on.
I don't know what the Plasma devs have in mind for the future, so please, don't take this as jab. Though, as it currently stands, the whole Plasma concept seems to me as a bit of a "me too" feature, rather than something really needed.
I like the enforced MVC Pattern on Plasma, but thats something any normal App Developer should code like :-)
The second Thing i like, is that everything can be contained in everything,
which make it easy to ajust to any form factor (but every formfactor has to be coded seperatly :-( if its not trivial zooming possible)
a third nice thing is the supported animations, but i think QT can do this too?
but i am with you guys, the same could be done with a normal toolkit and normal windows, and the QT Windows are styleable with CSS, which is better than the possibilities plasma gives...
but its all about the vision, is it ? :D
Thats Vision with a capital V.
But I don't agree. You need some sort of framework for little programs to exist on the desktop or panel. Kicker had applets, and plasma has plasmoids. It's really not so radically different. You can't make things like the battery monitor or the clock or the device notifier into standalone apps, because the memory consumption would be through the roof, and getting them to integrate into a panel would be very tricky.
So you need some sort of plugin system. That's what plasmoids basically are. They just happen to provide way more possibilities and much cleaner design than the old kicker applets. The new hip thing is to call these plugins widgets/gadgets/wookies whatever but they're still basically the same applets that they used to be, with added flexibility to exist outside a panel. Sure you could run gkrellm instead of a plasmoid, but then it wouldn't integrate into your desktop, it just kind of sits there. I never used superkaramba or any other widget system for exactly that reason. There was no integration. Now with plasma, there is.
From a users POV you may be right, its just the same. Which sounds great to me as it means we can make sure that usability problem is avoided.
The point of Plasma is to allow people (including you) to create something on their desktop themselves. So even if people don't have a lot of experience coding can do something nice.
I'm sure that a lot of people said the firefox framework was not valuable either until loads of new 3rd party plugins started appearing :)
> just because the old panel (kicker) had a messy codebase and was difficult to
> maintain.
that was what got me started thinking about things, but not the ultimate reasons that i arrived at *due* to thinking about things. please don't frame things incorrectly, as much as i appreciate you creating a mythology around my actions. ;)
> Then again, I never liked the concept of "widgets" (not just in KDE, but also
> Apple's or Vista ones).
so you never liked the taskbar? or the pager? or...? those are just "widgets" only insanely cumbersome to write, not very agile (e.g. can't move them about) and were all written in c++ as the only real choice.
you are confusing "widget" with "toy" because that's what most widget systems end up creating: little toys, some of which are slightly useful.
> Artificially calling them "plasmoids"
there's nothing artificial about it. they aren't traditional applications in form, nor are they meant to be. they are components designed to work together.
> and then putting them under a completely different interaction paradigm goes
> against well-accepted usability laws (i.e. it introduces "modes").
which modes are these?
(and don't even get me started on the "yes, everything is perfect as it is right now. don't... change.. a ... thing." sillyness)
> I remember having seen a paper on a new concept of
> "layered" window groups
omg, it's containments! only with a zui as well! you'd think plasma might actually be useful now! ;-P
> the whole Plasma concept seems to me as a bit of a "me too" feature
yes, emphasis on "seems to me". i understand you don't grok it, that's cool. eventually you will. it just takes time for us to get all the ideas out there for consumption.
Don't fret about how plasmoid creators are creating plasmoids. That has nothing to do with what plasma actually is. Plasma is an infrastructure, and it's powerful. Plasma brings the possibilities of almost infinite user interface customization. As a general rule, everything you see on a KDE 4.0 desktop is a plasmoid. Not just the desktop widgets. The panel is a plasma "containment", the desktop is a plasma "containment", the plasma applets are plasmoids, the icons on the desktop are plasmids, and finally, the desktop widgets are plasmoids. Everything is run by plasma. and it's ingenious.
The reason that I'm so excited about plasma is because it gives the possibilities, by creating new containments and plasmoids, to design complete new desktop interfaces. Such as the one defined here: ftp://ftp.netlabs.org/pub/voyager/docs/MezzoGreypaper.pdf I'm about to hike the Appalachian trail, but I think that that's what I'm going to do when I get back. I'm sure that KDE will be mature enough by then.
Have a good holiday, hopefully you won't forget about the Mezzo interface. I had a read through the paper you linked and seems indeed very interesting. I may try SymphonyOS just for that... or see if Kubuntu's got some packages...
Unfortunately, that project is dead. Although you can download a CD, they never made a complete implementation. In my opinion, KDE 4.0 is a perfect platform to build such an interface on.
you forgot, its the same as "everything is a window", so there is no difference betweens this an "everything is a plasmo-whatever", but you start from scratch @ your technology stack
> Then why not give up the whole idea of plasmoids en make them little "normal"
> apps with some extra features like noborders, etc? What is the use-case?
* the ability to arrange the components together however you want
* the ability to switch quickly between different groups of them
* the ability to have little bits of App A sit next to App B (easing away from monolithic application development)
* scripting components, sharing them easily
* the ability to recreate a primary interface with very little work even for different form factors
see, the whole point is sets of components with clear interfaces between them. making them little applications completely negates the benefits of that approach.
what you might be confused over is that plasmoids can be very useful. so you automatically relate that to what you already know (applications, windows!). but you know what? you *can* run a plasmoid as its own little normal app: plasmoidviewer . you can't go the opposite way when your item is an application from the start.
and because of that we end up with IM apps that can't drag a contact to the desktop, panel or pretty much anywhere else and have a reasonable representation of it, to give one bleedingly obvious example.
Yep, I'm one of them. I don't care if the Digest is a few days late. I prefer it being thorough, rather then timely.
As long as the digests come out in a regular fashing (weekly to bi-weekly) and bring interesting information that shows great amounts of PROGRESS. I'm fine. Those digests is what I and many people use to get a quick snapshot of KDE development.
I'm sure they also help in keeping interest in the project and keep new programmers involved and exited about it.
Oh and to the posting/whining question:
Most people read the digest and respond to it because its
A) faster
B) easier
to respond to than the complicated bug-report procedure. I can make a post here under 30 seconds. It takes much longer to do the same under bugs.kde (let alone the politics and complicated procedure to even get bug reports accepted and acknowledged. So not worth it (unless it's a REALLY BIG problem) ) Besides more people read the digests than the bug reports. (not to mention the dot.kde viewership :) )
dot.kde is also read by non-geeks (programers, developers, Linux nerds, etc.) So real users feel much less intimitaded to post her. As well as non-geeks usually avoid bug report lists (as they speak too much "geek", and non-geeks do not feel that they can contribute in a useful way anyway.)
So again: Thank you for the digest, and thank you to the dot.kde.
what about the z-order - or layers - for the plasmoids ?
something like back to front, send to back and stick on top.
also to fix the overlaying problem when more than one plasmoids cover the same area .
I think it's already in the TODO , but I just didn't notice it anywhere.
Regards,
Mohamed
http://bugs.kde.org/show_bug.cgi?id=156876
Summary: "you can now set the zorder by click on the applet handles."
i contemplated a more complex set of z-order GUI controls, but opted for a simpler approach of click-to-bring-forward which seems to work rather well for the overwhelming number of cases. i'm very hesitant to add too many controls for this particular feature set right now since that can easily lead to insane numbers of controls and suddenly we have krita and not a desktop ;)
but at least now you can, indeed, control the z-ordering. weee! =)