|
| This Week... |
|
Kopete supports MSN http protocol. amaroK adds support for media:/ urls. Speedups in Krita and aKregator. Work continues on Quanta plugin for KDevelop.
|
Kévin Ottens has been working on how Konqueror displays the user environment. If you enter system:/ in the location box you will see links to Remote, Storage media, Home folder etc. Last week Home was changed to link to a list of read-writable /home directories. Before going further, Kevin asked for some feedback: [1]
|
I'd need some opinions about the work I've done until now and about my current plans about system:/. The basic idea behind this ioslave was to have one root allowing desktop users to easily browse the relevant places in the system. I want to push the idea further hence why I need to know if there are suggestions or objections.
In order to have this possible I developed mainly three ioslaves: - media:/ which allows to deal with your partitions, removable media, cdroms, etc. - remote:/ which allows to have "remote folders" and is possible to use thanks to knetattach. - home:/ which displays home directories of the users being in the same groups than the current user (because it's generally more relevant to share files with them), and the current user home directory.
Currently system:/ points to media:/, trash:/, remote:/, settings:/ and home:/ (which was committed yesterday). home:/ being the last part of my great evil plan: hiding the real file hierarchy!
I'm now almost able to do it, in fact if I could even do it now. Some of you may wonder "why hiding the unixian file hierarchy??? and push use of system:/???". The answer is simply that for a desktop user this unix file hierarchy is an implementation detail.
So, the current status of what I've done is exactly this : if you start browsing using system:/ you can stay in this virtual hierarchy and do all your daily work using it (as a desktop user, not a sysadmin).
So the user could use only this, but some entry point to the unix filesystem still remain, in particular the shortcuts to the home directory...
Where I'd like to go is the following : replace $HOME with home:/$USER everywhere, this way the user will be "on the right track" by default (in the system:/ hierarchy).
Of course this would raise some issues on interoperability mainly because there's no consensus about the available VFS protocols between desktops. I currently see two problems in this area (I'll use media:/ as example since it's older and more known, but everything I'll present is true with home:/ as well):- Opening a file in the system:/ (media:/) hierarchy. When opening a file with an application, the application is launched thanks to its desktop file, and %u is replaced with the file URL (a media:/ URL for example). It'll work flawlessly with most KDE applications since they support KIO. But, some of them don't really support KIO completely (Kaffeine for example because it uses xine which only support some protocols like http and file). Moreover, non-KDE applications know nothing about media:/ URLs!
Then two things have been introduced: - KIO::NetAccess::mostLocalURL() which allows KDE applications to resolve an URL to a file:/ URL if needed (and if possible). - X-KDE-Protocols key in desktop files, which allows to restrict the set of supported protocols for an applications. Anything not present in this set is automatically resolved to file:/ URLs if possible before launching the application.
This way, we keep the compatibility with most applications, and KDE applications are able to have more control on the process. I then consider this issue as solved, the real solution would be of course to ensure that any non-KDE application could deal with any KDE URL but that's definitely not feasible currently, it would require a common VFS across all desktops, something that we won't have before a long time IMO.
- Drag and Dropping a file from the system:/ (media:/) hierarchy. It's the same kind of issue than opening a file. The main difference being that the application is already running, so the only counter-measure that can apply is KIO::NetAccess::mostLocalURL(), then only KDE applications can resolve the URLs to file:/ URLs... I've find no real way to make it work for non-KDE applications. Suggestions are welcome!
Now I'm pondering on what to do:- a) Replacing $HOME with home:/$USER right now?
- b) Replacing $HOME with home:/$USER for KDE 4 only?
- c) Give up the whole idea?
- d) Something else?
Of course I tend to think I should apply a), but I would consider b) acceptable whereas I really dislike c). Of course, I'm open to any interesting "d)" proposal.
Any opinions? advices?
|
|
One issue raised is how this would work with non-KDE applications. If you opened a non-KDE document, how would the non-KDE application know where it was if it didn't understand kioslaves? Or, if you dragged and dropped a file on a non-KDE application, how would it know what file was dropped? David Faure provided a solution:[2]
|
|
We could provide resolved url(s) using the standard way (text/uri-list) and the kde-specific url(s) in addition, using another mimetype. Then the receiver can pick kde protocols if it's a kde app, otherwise the standard text/uri-list. Quite easy, except that KURLDrag can't call mostLocalURL itself, so it needs a new API for setting the list of resolved URLs.
|
|
This was implemented here. Would this hierarchy be confusing for users? Some think so, and look forward to having a viable search option. Could someone have trouble navigating through the hierarchy, and be unable to find their way 'home', or to the system:/? Does 'home' or 'remote' mean anything to our international users? What about bookmarks to commonly accessed remote sites?
|
Thiago Macieira suggested a solution to the international issue:[3]
|
|
Proposal #2: it could even go down to the KURL level: there's KURL::url() and KURL::prettyURL(). The latter is never supposed to be saved, or passed on to applications. And since KProtocolInfo is already used in KURL (due to uriMode), we could add a Name information to the .protocol file, which would be translated, and returned by prettyURL.
|
|
Fred Schaettgen wondered:[4]
|
|
But aren't you _changing the implementation_ by introducing the home ioslave instead of just hiding it from the user? What's the point of replacing /home/ with home:/? Both users (and applications) have to digest a new implementation detail now - their own files are accessed with some sort of ... protocol now, you know, like web pages, but unlike other files on their harddisk or files opened with openoffice, firefox, scribus, you name it. Are you sure this makes it any easier for them? And if a file is opened via the a home url you still have the untranslated "home:/" in your URL - that's again where the implementation shines through. If it's really about hiding the "implementation detail" a.k.a. file system hierarchy, I believe that ioslaves are not enough.
|
|
Kevin explained: [5]
|
It's not simply replacing /home/ with home:/, on some boxes, /home/ has subdirs and users home dir are in those subdirs (in my lab they use it so much that's completely mad), moreover most of the entries in /home/ are not relevant for a user, so by default it's restricted to the home directories of users in the same group than you.
...
For users it changes almost nothing IMHO, they'll keep clicking on the "Home" link which will open home:/$USER.
|
|
[1] lists.kde.org/?l=kde-core-devel&m=111973959921885&w=2
[2] lists.kde.org/?l=kde-core-devel&m=111980063413212&w=2
[3] lists.kde.org/?l=kde-core-devel&m=111980935807416&w=2
[4] lists.kde.org/?l=kde-core-devel&m=111986127402394&w
[5] lists.kde.org/?l=kde-core-devel&m=111986412111254&w
|
|
| Statistics |
|
Commits: |
2020
by 203
developers, 51582
lines modified, 3422
new files. |
|
Open Bugs:
|
8988
|
|
Open Wishes:
|
8402
|
|
Bugs Opened:
|
321 in the last 7 days. |
|
Bugs Closed:
|
325 in the last 7 days. |
|
|
Commit Summary |
|
Module
|
Commits
|
|
www |
|
|
l10n |
|
|
extragear |
|
|
work |
|
|
playground |
|
|
stable |
|
|
kdenonbeta |
|
|
kdepim |
|
|
kdelibs |
|
|
koffice |
|
|
|
Lines
|
Developer
|
Commits
|
|
|
Stephan Kulow
|
|
|
|
Laurent Montel
|
|
|
|
David Faure
|
|
|
|
Nikolas Zimmermann
|
|
|
|
Nicolas Goutte
|
|
|
|
Stephan Binner
|
|
|
|
Nicolas Ternisien
|
|
|
|
George Staikos
|
|
|
|
Till Adam
|
|
|
|
Renchi Raju
|
|
|
|
|
Internationalisation (i18n) Status
|
|
|
Bug Killers |
|
Bug Killer
|
Number Of Bugs Closed
|
|
Thiago Macieira
|
|
|
Alexandre Pereira de Oliveira
|
|
|
Aaron J. Seigo
|
|
|
Heinrich Wendel
|
|
|
Nicholas Nethercote
|
|
|
Seb Ruiz
|
|
|
Maks Orlovich
|
|
|
Matt Rogers
|
|
|
Klaus Staerk
|
|
|
Danny Allen
|
|
|
|
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes.png) |
![[*]](/images/standard/features.png) |
|
|
![[*]](/images/standard/other.png) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
![[*]](/images/standard/optimise.png) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
There are 115 selections this week.
|
|
Bug Fixes |
|
|
|
KDE-Base |
|
Nicolas Goutte committed changes in /trunk/KDE/kdelibs:
|
Allow the translation of the KDE palette names in the color dialog.
It is done by hard coding the names. (Idea by Stephan Kulow)
I have tried to make the code in a way to allow to add further KDE palettes
(like for examples the wish #107925).
(Note: it also "uninstall" (a.k.a. remove) the previous names of the
palette files.)
BUG:85565 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Till Adam committed a change to /trunk/KDE/kdepim/kmail/keyresolver.cpp:
|
Fix by Thiago Macieira <> for ingored signature type
selections.
Marc, this seems correct to me. How about
resolveSigningKeysFroEncryption and resolveEncryptionKeys? Do they have
the same problem?
BUG: 99089 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Frank Osterfeld committed changes in /trunk/KDE/kdepim/akregator/src:
|
fix in-place renaming by connecting to both QListView::itemRenamed(QLI*, col, QString) and KListView::itemRenamed(QLI*, QString, col)
signals
The QListView version works for folders and feeds, the KListView version works for Tag nodes. super strange
BUG: 102099
CCBUG: 96669, 93480 |
|
|
|
|
|
|
|
|
|
|
|
