DEC
5
2007

KDE Commit-Digest for 2nd December 2007

In this week's KDE Commit-Digest: The beginnings of screen hotplug detection in Plasma, KRunner gets history support. Fifteen Pieces puzzle becomes the first Plasma applet in the game category. A block of bugfixing in KDevelop, with various other developments in areas such as a threaded debugger. Support for inequality constraints in Step, continued progress in the port of KEduca to KDE 4. Work on printing in okular. Work on Solid-based network management through NetworkManager. Various work towards Amarok 2. Milestones reached in the BitTorrent plugin for KGet. Subsystem rewrites (SSL, SFTP) in KFTP. OpenDocument format loading and saving work in KChart. Colour work in Krita, with Krita becoming one of the first applications to be able to paint in HDR. New Oxygen-themed sound effects, Oxygen icons are optimised for small sizes. New colour schemes added for KDE 4.0. Ruby language bindings based on the Smoke2 framework. Experiments in KBugBuster and on a Plasma "applet designer" application. Read the rest of the Digest here.

Comments

GIO actually uses the GObject model, but i don't see why wrapping a GObject based library with C++ classes or using it in a KIO slave should be a problem.


By Norbert at Sat, 2007/12/08 - 6:00am

"GIO actually uses the GObject model, but i don't see why wrapping a GObject based library with C++ classes or using it in a KIO slave should be a problem."

"Oh, you can just wrap it!" is not a solution.


By segedunum at Sun, 2007/12/09 - 6:00am

I agree, what KDE needs is a more capable KIO API built from the ground up on C++ and Qt.

The reason why KDE had to compromise (and I'm using "compromise" with all its negative connotations) to use HAL, NetworkManager, PackageKit, and PolicyKit even though these are built on GLib, is that RedHat is pushing GNOME and doesn't give a hoot about KDE. If you look at the projects listed above, they were all started by RedHat employees.

Now GIO/GVFS is different because KDE does *not* need to rely on it -- we have plenty of dedicated developers interested in making file access easy (look at KFTP and SMB4K). But what is missing is a flexible and powerful framework that will fit the needs of these developers. I'm going to propose such an API for KIO2 on kde-devel@kde.org in about a week in order to get feedback before implementing it.


By VladC6 (aka. Bob) at Sun, 2007/12/09 - 6:00am

> even though these are built on GLib

You are missing an important point: out-of-process infrastructure is being used through a communication protocol, e.g. HAL's API are a set of D-Bus interfaces.

Thus the client is totally unaffected by whatever dependencies are used to implement the service and in the very unlikely event that such an implementation is not acceptable, it can be replaced without any change on the client side.

I am not aware of any compromise KDE had to make in order to use such shared infrastructure implementations because the respective developers chose different means of implementing their side.


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> out-of-process infrastructure is being used through a communication
> protocol, e.g. HAL's API are a set of D-Bus interfaces.

I was certainly aware of that :)

> I am not aware of any compromise KDE had to make

1) The fact that someone with Qt/KDE skills has to learn C/Glib programming in order to fix bugs in HAL, NetworkManager, PolicyKit, PackageKit is IMHO a big disadvantage. Many new developers don't have the time or patience to learn two frameworks (QtCore and Glib), so knowing that they'll have to learn Glib anyway to solve hardware and low-level issues, they'll probably go ahead and improve GTK/GNOME apps due to their lower learning curve. Great way for KDE to lose potential developers to "the competition", don't you think?

2) Another drawback is that users have to install GLib on their system -- wasted hard drive space considering QtCore already does approximately the same functionality. I'm all for lean and mean systems with no bloat :)


By VladC6 (aka. Bob) at Mon, 2007/12/10 - 6:00am

> The fact that someone with Qt/KDE skills has to learn C/Glib programming in order to fix bugs in HAL, NetworkManager, PolicyKit, PackageKit is IMHO a big disadvantage.

I don't buy this argument, because those things are shared infrastructure and maintained by their own development teams, just like Xorg, libc, etc.

And, as I wrote before, should there really be a huge problem with the current implementation (very unlikely since quite some projects depend on them), one can always replace it with a new implementation.

> so knowing that they'll have to learn Glib anyway to solve hardware and low-level issues

Most application developers don't get into situations where they want to solve harware or low-level issues, not just because it might require a different language, but because it requires a respective skill set, domain know-how, etc.

For those who have the necessary skills, e.g. our library/core developers, it is a bit less convenient but nevertheless possible, especially since they'll probably just need to find the issue and let the other project's developers fix it.

> Another drawback is that users have to install GLib on their system

Which they of course have anyway, especially on Linux distributions that are LSB compliant.

I really think this is blown out of proportion in this context ("desktop" services), because the IPC shields the clients from the service dependecies.

Consider how stupid it would look from your perspective if someone claimed they cannot use a desktop service because it's using portions of Qt (e.g. QtCore) for its implementation.

The project which develops and maintains a service decides on *its* implementation and tools, the projects developing and maintaining the various clients decide on *their* implementation and tools, neither choice affecting the other, everybody is happy.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> For those who have the necessary skills, e.g. our library/core developers,
> it is a bit less convenient

It would be interesting to see if the authors of KFTP and SMB4K agree to start working on the GVFS implementation of FTP/SFTP/SMB. My guess is that C and GLib will prove to be a disincentive to doing so.

Anyway, what I'm going to focus on first in KIO2 is the frontend (ie. Job classes, KFileItem, UDSEntry) in order to make it more flexible and more in line with GIO. That should actually make it easier to write a GVFS backend for KIO2.


By VladC6 (aka. Bob) at Mon, 2007/12/10 - 6:00am

> It would be interesting to see if the authors of KFTP and SMB4K agree to start working on the GVFS implementation of FTP/SFTP/SMB

My guess is that those protocols will be available from the actual GVFS team.

If the respective developers IO slave developers think they can do better, they can always implement the GVFS protocol daemon using Qt instead of GLib.

Remember that the protocol shields the other side from implementation details, thus if it is possible to implement a client using its technology stack, it is equally possible to implement a service using the same technology stack.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> If the respective developers IO slave developers think they can do better, they
> can always implement the GVFS protocol daemon using Qt instead of GLib.

From reading yours and Vlads comments i get the impression that KDE developers really have a wild passion for code duplication.

While i think having a KIO2 with pluggable backends is a very good idea, i'd just link GIO in-process (perhaps optionally with a default implementation for local filesystem only).

Qt and KDE provide and link tons of libraries, load thousands of icons, but linking a tiny GLib based library seems to be a big drama.

Sorry for being a bit provocative. ;-)


By Norbert at Mon, 2007/12/10 - 6:00am

I am merely detailing that an implementation can be replaced by a better implementation if necessary.

I am afraid I don't get the code duplication part, though.
KDE is basically always using suitable external implementations when available while even independent infrastructure work gets ignored for wild reasons if KDE developers started them.

> Qt and KDE provide and link tons of libraries, load thousands of icons, but linking a tiny GLib based library seems to be a big drama.

I thought it would be clear enough that the problem is not linking but rather layering a high level API on top of another high level API when one could rather implement the high level API directly.

You even acknowledge this in one of your own postings: "...This could also be seen as an advantage, because having a plain C API and another GObject API around would duplicate the number of symbols...."

It is a matter of how a project is designed. The common layer can be the protocol specification, e.g. HTTP, or a low level protocol handler library, e.g. D-Bus.

Both have advantages and disadvantages. A low level library makes it easier to use the protocol, but on the other hand is a lot more difficult to write.

Abusing high level API libraries for convenience leads to unnecessary restrictions, e.g. how xlib being used in toolkits basically forces synchronous calls while a low level protocol handler like XCB doesn't.

Libraries which have application developers as their target audience are usually designed differently than libraries for other library developers.

Again, the D-Bus library stack is an excellent example. The base library cannot dictate how bindings want to watch for socket activity, as some will want to do select() like constructs with event loops and other will want to use threads blocking on the socket.

The bindings on the other hand know which context they are usually used in and therefore can make this choice, e.g. Qt bindings using eventloop bases socket notifiers, Java bindings using threads.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> I thought it would be clear enough that the problem is not linking but rather
> layering a high level API on top of another high level API when one could rather
> implement the high level API directly.

I disagree. Layering a high level API on top of another high level API is ideal from design. Just like KIO::Netaccess wraps KIO jobs.

As KIO is a lot more high-level than GIO (i wouldn't call GIO very high level), things might fit together quite well. And if there are incompatibilities i wouldn't expected them to be related to GObject style C, but rather hidden somewhere else in the implementation details. And if they exist, one should first try to sort them out by improving the GIO API. Rewriting everything from scratch should really be the last option to consider.

I think it's a wrong assumption that a C-API automatically turns into a high level API, just because it's using GObject.


By Norbert at Mon, 2007/12/10 - 6:00am

> As KIO is a lot more high-level than GIO

Yes, this would probably work.

I had been thinking about using the GIO model directly, since it would make file identifiers compatible.

KIO's Job API would probably be layered on top for compatability with older applications, but I am not sure one would gain a lot by only swapping the implementation.

But lets assume for a moment that such a backend change would have any advantage: does it work to have two D-Bus bindings work on the same connection?

> Rewriting everything from scratch should really be the last option to consider.

That's why I like the D-Bus software stack. All the protocol details are shared in libdbus and the application frameworks only have to implement their platform adapter code but have full control how they do it.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> I had been thinking about using the GIO model directly, since it would make file
> identifiers compatible.

yes - and it would align the whole data model behind file-management (the hierarchy displayed in file choosers, where removable media and network mounts are listed,...). a big step forward i believe.

if you want this, you definitely have to link GIO directly. if you only want the GVFS mount daemons it's probably better to write a separate client with QtDbus.

perhaps there could be still different flavors of the data-model, but at least it's desktop wide for all applications.

> does it work to have two D-Bus bindings work on the same connection?

I once discussed this on the D-Bus list. Surprisingly i found out that the QT-Dbus bindings don't use the default session bus connection (That's not optimal and should be probably fixed). Thus it will work, as GIO uses the default connection. Of course you have to compile Qt with GLib main loop support.


By Norbert at Mon, 2007/12/10 - 6:00am

> if you want this, you definitely have to link GIO directly.

I wouldn't see a reason why.
The architecture doesn't sound like it got hacked together and nobody any longer knows how it works. That's how Microsoft works, not Free Software developers.

Since I am a D-Bus bindings maintainer this is what I mainly base by reference on when it comes to wrapping.
Basically all bindings have their own set of assumptions, options and restrictions. It would be pretty close to impossible to implement one on top of the other, while it is pretty straight forward for all of them on top of the base lib.

> Surprisingly i found out that the QT-Dbus bindings don't use the default session bus connection

Right, I think the Qt4 bindings use private connections.

However I haven't seen an application using more than one binding on the same bus yet, would be interesting to see if this works.

Anyway, as I said I'll probably have time to look at this somewhen in spring and I am not ruling out wrapping the GIO implementation, but I will definitely also investigate the doing a native implementation.
At that time there will likely also have been work on its language bindings and all kind of wrapper issues already been solved.


By Kevin Krammer at Tue, 2007/12/11 - 6:00am

>> if you want this, you definitely have to link GIO directly.

> I wouldn't see a reason why.
> The architecture doesn't sound like it got hacked together and nobody any longer
> knows how it works. That's how Microsoft works, not Free Software developers.

what i meant is that a lot of the data model is managed in the in-process part of GIO/GVFS like maintaining the drives/volumes list (parsing/monitoring mtab etc). therefore having two implementations will likely cause a incoherent file-manager/file-chooser experience (for instance a FUSE mount getting listed in GTK filechoosers but not in KDE apps).

also, the IPC protocol might not always be the best place to standardize an interface. because GIO uses a model of dlopening the actual implementation, the frontend API might be the "standardized" interface, not the more complex IPC stuff behind that.

> However I haven't seen an application using more than one binding on the same
> bus yet, would be interesting to see if this works

If it doesn't, then that's a bug and should be fixed. It's not acceptable having to write cross desktop libraries in a terrible style like D-BUS bindings (dealing with main loop watches etc)


By Norbert at Tue, 2007/12/11 - 6:00am

> like maintaining the drives/volumes list (parsing/monitoring mtab etc)

I surely hope that it does not do this on Linux, where HAL is managing deviced and volumes.

But this is an interesting issue none the less. Since it probably manages user specific "virtual mounts", part of a KDE implementation would probably be "below" Solid, e.g. in a backend or additional backend, and part of it probably "above", e.g. the IO parts. Or, since those are not real mounts/volumes, probably totally bypassing Solid.

> therefore having two implementations will likely cause a incoherent file-manager/file-chooser experience

Quite unlikely. Assuming that the input data is equal, any derivation in the result would either be a bug in one of the implementations or an ambiguity in the specification, both fixable causes.

> also, the IPC protocol might not always be the best place to standardize an interface

Right. It depends on the goal, e.g. being reimplementable by other parties (a.k.a. open specification) or being private knowledge (a.k.a. proprietary, though legally reverse-engineerable)

> because GIO uses a model of dlopening the actual implementation, the frontend API might be the "standardized" interface, not the more complex IPC stuff behind that

Interesting!
When KDE developers do this they get flamed about "abstracting abstraction layers".

Nice to see that separating interface from implementation, even using plugable implementation, seems to be used somewhere else as well.

Incidentally this offers a third option for adoption: wrapping the backend loading and access in a native frontend interface.

> If it doesn't, then that's a bug and should be fixed.

It probably depends if the base library allows more than one callback registered for the same hook, e.g. the callback for incoming messages.

Probably easier to use private connections in libraries, so they don't interfere with anything the application is doing. After all the application should not have to care about implementation details of the library, e.g. if it uses threads or a certain event loop, unless the library is specifically written for such a use case.

> It's not acceptable having to write cross desktop libraries in a terrible style like D-BUS bindings

Well, it'sa tradeoff. The other option is to use threads internally for any kind of active functionality and let the application decide whether it wants foreign thread callbacks to be transformed into event loop events or let them directly access application data.

Traditionally Unix developers avoid threads for reasons like increased difficulty when debugging, but that is likely to change since multiple execution units are becoming pretty much standard.


By Kevin Krammer at Tue, 2007/12/11 - 6:00am

I'm afraid writing a better KIO won't fix the problem. Having the core engine of file management in the desktop layer is just wrong from design.


By Norbert at Mon, 2007/12/10 - 6:00am

While it would be nice to have it lower, i.e. on the operating system level, this would make desktop applications quite dependent on those operating systems.

Not even talking about the necessary API changes for authentification callbacks, async IO, etc.

Doing it at the user session level like KIO, GIO, GNOME-VFS is currently the only sensible approach, which might be retired in favor or a more system integrated approach when it becomes widely available.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> Having the core engine of file management in the desktop layer
> is just wrong from design.

I agree. KIO2 won't have a GUI dependency. It will depend only on QtCore, libsmbclient, libssh2, etc. I also plan to keep the separation between frontend (KIO API) and backend (kioslaves). So it will be possible to create a GVFS backend to KIO2. In fact, that might be even easier because the KIO2 frontend API will be quite similar to GIO.


By VladC6 (aka. Bob) at Mon, 2007/12/10 - 6:00am

KIO slaves don't depend on GUI either, they contact an UI server for that.


By Kevin Krammer at Mon, 2007/12/10 - 6:00am

> KIO slaves don't depend on GUI either, they contact an UI server for that.

Slaves don't depend on the GUI, but other parts of KIO (ie. Job classes) do. I hope to change this in KIO2. Here's what Thiago said about KIO:

----
KIO does GUI: it shows rename dialog boxes, download progress, delete
progress, it can ask for passwords, etc. Saying KIO is GUI-less is
incorrect. And I think that trying to separate things would just be too
difficult and add unnecessary complexity.

KIO has been made for KDE applications. And KDE applications have a GUI.
----

http://lists.kde.org/?l=kde-devel&m=119238531527435&w=2


By VladC6 (aka. Bob) at Mon, 2007/12/10 - 6:00am

So, that's the source of all those stupid dialogs, which bug's me every day and ever.


By Tempura at Tue, 2007/12/11 - 6:00am

> GIO actually uses the GObject model

From what I read in some mailinglist archives yesterday, this is unlikely. They were talking about including it in GLib which makes it impossible to depend on GObject.

> but i don't see why wrapping a GObject based library with C++ classes

Looks like more work than necessary, mapping the probably different way of dealing with things (e.g. signals) onto each other.
For example the D-Bus base library is pretty easy to deal with in language bindings, but the GLib D-Bus bindings assume a lot about its type model, etc.

The bindings are meant to be used by application developers, therefore use some convenience stuff, which makes them harder to wrap than the base library which is designed to be wrapped.

> using it in a KIO slave should be a problem

True, in this one doesn't need to mix object models, the implementation can use just GObject, no C++/Qt/KDE required


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

>> GIO actually uses the GObject model

> From what I read in some mailinglist archives yesterday, this is unlikely. They
> were talking about including it in GLib which makes it impossible to depend on
> GObject.

I think they want to include it in the GLib package, not in the libglib shared library. That way they can link libglib and libgobject. At the moment it's not included in the GLib package, the package is "gio-standalone".

Just have look at the API docs - it's GObject based. I think they are using GObject interfaces for the modular design: To plug GVFS into GIO where it's available. For instance on Windows they don't want to use GVFS.

However, the API is pretty "flat" C:

http://library.gnome.org/devel/gio/unstable/GFile.html

A bit more OO are the stream classes:

http://library.gnome.org/devel/gio/unstable/GInputStream.html
http://library.gnome.org/devel/gio/unstable/GFileInputStream.html
http://library.gnome.org/devel/gio/unstable/GSeekable.html

I still think in most cases it makes no big difference if you wrap a GObject style library or a C library with a hand-crafted object model like D-Bus. And forwarding GObject signals or plain C callbacks is quite a similar story as well.

AFAIK, GIO and GVFS are completely modeled in GObject (also the daemon side), therefore there is no "base library" without GObject. This could also be seen as an advantage, because having a plain C API and another GObject API around would duplicate the number of symbols.


By Norbert at Sun, 2007/12/09 - 6:00am

> I think they want to include it in the GLib package, not in the libglib shared library.

Hmm, must have been a misunderstanding on my part then. They were discussion glib vs. gobject things so I assumed is was a matter of API vs. gvfs implementation.

> For instance on Windows they don't want to use GVFS.

What is planned to be used on Windows for remote access then?

> However, the API is pretty "flat" C

Uhh, evil!
I am C++ developer, I prefer "grouped", you know stuff like data and related function pointers, implicit context :)

> I still think in most cases it makes no big difference if you wrap a GObject style library or a C library with a hand-crafted object model like D-Bus.

It really depends on the API.

What I tried to explain with the example of D-Bus is that the base library is easier to wrap because it doesn't assume stuff left and right. The GLib based bindings for example assume that an object to be exported is derived from GObject.

This is obviously good design for the libraries use case, e.g. being used by GLib based applications, but would be horrible for something using another object model because instead of implementing a simple callback and handling method calling yourself, you'll have to write some kind of generic object model adapter which usually gets veeery messy, if possible at all.

The way D-Bus's softwarestack is designed allows sharing the base library between otherwise different toolstacks, only frameworks where accessing a C library is hard work, e.g. Java, Mono, are using their own protocol implementations.

In the case of GIO I don't think it would be worth the effort of splitting the current client library in such a way, since it would be quite some effort for probably very little gain (depends how complex the protocol is).

I haven't found any protocol specification yet, so I assume the control flow (and probably metadata) is D-Bus based and the data is using unix domain sockets (at least on Unix).

Should be pretty trivial to implement the D-Bus API using Qt bindings and reading/writing/waiting on a local sockets isn't rocket science either.
Could be a candidate for KDE 4.1, any pointer to the respective specs?


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> What is planned to be used on Windows for remote access then?

Nothing i guess - just linking the native filesystem. Windows has remote access built in.

> ... so I assume the control flow
> (and probably metadata) is D-Bus based and the data is using unix domain sockets
> (at least on Unix).

AFAIK, yes.

> Should be pretty trivial to implement the D-Bus API using Qt bindings and
> reading/writing/waiting on a local sockets isn't rocket science either.
> Could be a candidate for KDE 4.1, any pointer to the respective specs?

I don't think there are any specs, but i'm sure Alexander Larsson can tell you more. Also about the client side intelligence required to work with the GVFS daemons directly.

You can ask him here:
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list


By Norbert at Sun, 2007/12/09 - 6:00am

> Nothing i guess - just linking the native filesystem. Windows has remote access built in.

Interesting.
I have to admit I am not very up-to-date with Windows technology, my experience is largely XP based and this version could barely do FTP, no SFTP or similar.

> I don't think there are any specs, but i'm sure Alexander Larsson can tell you more.

Right.
I'll probably have time for this between 4.0 and 4.1, sounds like a good thing to do.


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> I have to admit I am not very up-to-date with Windows technology, my experience
> is largely XP based and this version could barely do FTP, no SFTP or similar.

don't know either, i've read somewhere there is a SFTP plugin. but at least it has SMB built in and available for all apps.

> I'll probably have time for this between 4.0 and 4.1, sounds like a good thing to do.

very cool!


By Norbert at Sun, 2007/12/09 - 6:00am

There are some docs here:

http://svn.gnome.org/viewvc/gio-standalone/trunk/txt/

AFAIK GIO does the local-file stuff in-process (with threads for async ops) and for remote file systems it uses the GVFS plugin to connect to a main daemon and to a number of multi-threaded "mount daemons" where each of them represents a connection (or a pool of connections) to a certain server. Because of the stateful "mountpoint" model, GIO/GVFS never has to talk to authentication systems actively. Passwords are passed to the mount operation in the GIO client, triggered on the users demand (only in file-managers or -choosers, normally). Once you have "mounted" a server or share, you will never be asked for a password again.

Alexander Larsson wanted to avoid that password dialogs pop up unexpectedly in normal file-operations like they do in KIO or Gnome-VFS. This might answer your question about user interaction: It's always done on the client side by the file-manager, file-chooser or application (or perhaps some helper layers built into toolkits). Because of it's "passive" design, GIO/GVFS can stay completely desktop/toolkit independent, therefore it should be quite easy to wrap KIO around it.

Cookies i think are off-topic for GVFS, because it is not designed to provide the infrastructure for web-browsers. It's target is file management.

To understand the API, have a look at the sources:

http://svn.gnome.org/viewvc/gio-standalone/trunk/gio/

particulaly gfile.h is a good starting point.


By Norbert at Sat, 2007/12/08 - 6:00am

> http://svn.gnome.org/viewvc/gio-standalone/trunk/txt/

Thanks, I will have a look.

> AFAIK GIO does the local-file stuff in-process [...] and for remote file systems it uses the GVFS plugin to connect to a main daemon and to a number of multi-threaded "mount daemons" ...

Ah, I see.

Well, in this case it would probably be best to also handle local file access traditionally (whatever the application wants to do) and implement a KDE or probably even a Qt library for communicating with those daemons.

No change for application developers who only access local files, no dependencies with probably different release cycles, but still common handling of remote access, shared infrastructure.

> Passwords are passed to the mount operation in the GIO client, triggered on the users demand

Hmm. This is probably part of the docs you linked to, but how does the user or client know when authentification is needed?

> This might answer your question about user interaction

Yes. The client or rather the library the client uses does all the interaction handling, one more reason to implement this correctly (as in "suiting the expected behavior of KDE application developers") from protocol level up.

> Cookies i think are off-topic for GVFS, because it is not designed to provide the infrastructure for web-browsers.

Cookies were just an example of connection related data. I guess in the GIO model the application has to receive this data and then pass it to the other application through a different channel, e.g. D-Bus.

Would be intersting if a connection can be "transferred" to another application, e.g. the file manager getting the first few bytes of a remote file for MIME detection and then transferring the connection to the "viewer" application, so that it doesn't have to connect again.


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> Well, in this case it would probably be best to also handle local file access
> traditionally (whatever the application wants to do) and implement a KDE or
> probably even a Qt library for communicating with those daemons.

don't know. for the local file system it might also make sense to share code, as this would make the whole drive/volume and trash handling more harmonic (also quite confusing at the moment).

> Hmm. This is probably part of the docs you linked to, but how does the user or
> client know when authentification is needed?

Usually the filemanager or application would find a dir-entry with the type "mountable" (a share on an smb-server for instance). the next step would be running the mount operation.

> Would be intersting if a connection can be "transferred" to another application,
> e.g. the file manager getting the first few bytes of a remote file for MIME
> detection and then transferring the connection to the "viewer" application, so
> that it doesn't have to connect again.

Forget about the weird model of KIO, passing single threaded slaves around. GIO/GVFS mount daemons work very much like FUSE filesystems, and accept multiple client connections in parallel. Therefore this is just a matter of caching in the mount daemon process.


By Norbert at Sun, 2007/12/09 - 6:00am

> for the local file system it might also make sense to share code, as this would make the whole drive/volume and trash handling more harmonic

For "mount" operations probably yes, I was thinking about file data access, e.g. mmap vs. read/write access depending on application needs.

> ... the next step would be running the mount operation.

After reading the overview docs you had linked to earlier it is now clear that the mount operation does callbacks when it needs authentification data, so password/keystore integration would be possible in client library implementation, good.

> Therefore this is just a matter of caching in the mount daemon process.

Yes, excellent. Also clear from the docs, should have read them earlier, sorry for that.


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> For "mount" operations probably yes, I was thinking about file data access, e.g.
> mmap vs. read/write access depending on application needs.

Probably apps or wrapper layers are supposed to use a combination of

gboolean g_file_is_native(GFile *file);

and

char* g_file_get_path(GFile *file);

i they want to work with mmap or O_RDWR (when done with the mounting etc...)


By Norbert at Sun, 2007/12/09 - 6:00am

Right, this is what I have been referring to as local file access.


By Kevin Krammer at Sun, 2007/12/09 - 6:00am

> take the "Plasma approach" and not guarantee binary compatibility
> in the KDE4 release.

plasma is a new technology that isn't in kdelibs. libkicker *never* guaranteed binary compat, though the 3 classes in kdeui that kicker used were. it's a slightly different story to a 7 year old kio library that is used pretty much everywhere, works well and resides in kdelibs.


By Aaron J. Seigo at Thu, 2007/12/06 - 6:00am

Hopefully the mimetyp recognition will improve for "remote" protocols. (as it does not work well or at all in KDE3)


By ferdinand at Wed, 2007/12/05 - 6:00am

The new oxygen sounds reminds me of Mac OS 7.

http://websvn.kde.org/trunk/playground/artwork/Oxygen/sounds/new/

The sounds are all played on a keyboard synthesizer and all sound very similar, making it hard to tell the difference between and error and a notification. IMHO they don't have any relation to the topic they are trying to convey. The error and warning sounds sound too mellow. Doesn't anyone know how to do fancy effects ala shattering windows?

Also, the log in and log out sounds are way too long -- almost as bad as:

http://www.youtube.com/watch?v=Mt1bgsvsWms


By Kory at Wed, 2007/12/05 - 6:00am

I like the sounds, mellow is good. But I agree that some of them are too long and lack distinction.


By Skeith at Wed, 2007/12/05 - 6:00am

I like them too. I listened to them cold, ie without reading the design yet, to get a clean first impression.

for i in *.ogg; do echo $i; sleep 1; ogg123 $i; done

so i could see what they are supposed to be, and listen to them "hands off". The first time I thought they sounded a bit Bontempi but that was through the X60's tiny speaker. With desktop speakers they sound good, plenty of breadth to the sounds.

2 observations, forgive me if these are known about:

*) The login/logout sounds are distorted at any level on my sound card. It's the third to sixth notes played on the right (i think) hand at the beginning of the login sound that are too loud and especially distorted.

*) The im.msg.in/out sounds are fine played alternately (try "while true; do ogg123 im.msg.in.ogg; ogg123 im.msg.out.ogg; done") but get monotonous when one side is not replying. Could I suggest the maker does an additional 'in' and 'out' sound, slightly lower than the first one, that quality IM clients (Kopete ;)) can play alternately with the first one.

That way you would get a 'conversation' effect, read this in a fixed width font*, from left to right with each char representing one SFX:

In: ^_ ^_^_^ ^_^_ ^_

Out: *.*. * *.*.*. and so on.

*I thought Dot could do some HTML - at least the posting form says it can.


By Will Stephenson at Wed, 2007/12/05 - 6:00am

Take a look at
http://techbase.kde.org/Projects/Oxygen/Sound_Theme_Technical_Specification
http://techbase.kde.org/Projects/Oxygen/Sound_Theme_Naming_Specification

Theres a lot of thought, time, and effort gone into the sound theme by Nuno Povoa, so I think to dismiss them and say they have no meaning, because they sound similar is a bit unfair. I would give him the benefit of the doubt.

Personally, I think having sounds like shattering windows/glass would make the desktop sound like a cartoon, and Oxygen (including sounds) is trying to move KDE away from things like that.

I do agree that the login/out sounds are *just* a bit too long, but i believe those are being shortend.


By David at Wed, 2007/12/05 - 6:00am

The Oxygen widget style is in my opinion moving KDE closer to a cartoon-like desktop: the buttons are too round and have a too big border, also the scrollbars are too heavy (and why is their color green?), the shading of the window background is also not reducing the cartoon-like effect, the fact that the title bar cannot be distinguished from the rest of the window gives the impression that usability has to make place for playful fanciness (if I want to move the window by dragging its titlebar, where do I have to click?). The roundedness and the shadings in the Oxygen widget style does (in my opinion) not fit the Oxygen icons which have a more square-like look with sharp edges (the Oxygen icons are very good and look professional). In my opinion, a style like QtCurve is much better suited for the Oxygen icons and looks also more professional (with "professional" I mean: non-cartoonish; the Oxygen widget style is nice and is clearly made by professionals, but it is not suited to be used in a professional environment).

Now that I am giving my opinion on the look of KDE, I also want to say something about the color scheme: I think that a gray window background color is so old-fashioned, so Win95-like, that it should finally be replaced by some nicer color (any other OS, even windows, use better colors nowadays). Some beige color (e.g. #F6F1E3) as the window background would be much better and would also look professional (this color also fits nice with the Oxygen icons). I know that anyone can change the style and the color scheme, but we want to give a nice *default* look to KDE (one that does not repel potential new users; gray is repelling for me), don't we?


By Anonymous at Wed, 2007/12/05 - 6:00am

> if I want to move the window by dragging its titlebar, where do I have to click?

normally I click the top of a window for the titlebar.
A good guess is often near the buttons or where the window title is shown.


By anonymouse at Wed, 2007/12/05 - 6:00am

The Oxygengrey is quite different from Win '9x, so I think that argument doesn't go. I like the colorful parts contrasting with the white-grey, and I think it doesn't look unprofessional at all. At least more professional than XP and Vista and Mac OS X look... OK, maybe a bit less than plastik, but plastik was imho very corporate - guess that's why Gnome copied it ;-)

Anyway, after some time using it, I really grew fond of it - to the point of looking for a good looking style for KDE 3.x and not finding one :(


By Jos Poortvliet at Wed, 2007/12/05 - 6:00am

It seem like KDE always are going to have the complainers stating it's too cartoonish. I'm not sure if the term was ever used about KDE 1, back then it may not have been invented yet.

But at the first pre-releases of KDE 2, the complaing about the icons looking too cartoonish started. This also started to apply to the style, making the whole interface look childish and unprofessional. The old KDE 1 looks was much better in this regard.

When KDE 3.1 was released with the new Crystal icons and the Keramik style the complaints was that it made KDE look too cartoonish. And that the old style and icons, looked much more professional. Later when the style was changed to Plastik, naturally it looked unprofessional being cartoonish and childish.

Now with the artists hard at work with the new Oxygen style, there are no surprise it will become too caroonish. And thus unprofessional and childish. Compared to the old Crystal and Plastik, which look much more professional.

To remedy this I propose KDE change to Everaldo's Kids icons[1] as default, combining it with the creation of a matching style and window decoration. This will enable the KDE comunity to meet every complaint about the childish looks with a loud duh! And righteously ignore the silly complaint.

[1]http://www.kde-look.org/content/preview.php?preview=2&id=9144&file1=9144...


By Morty at Wed, 2007/12/05 - 6:00am

This is so freaking unmotivating... Nuno Povoa did a wonderfull joob documentation included somthing kde never had, but all people can say is that its crap and cant point the reason for it....
No wonder people get fed up with this.


By nuno pinheiro at Fri, 2007/12/07 - 6:00am

its my understanding all of this can be changed, so why would anyone really care? you have the option to change it so you do, end of story. NOTHING in this world will appeal to everyone, dont like the theme? make one you feel is better. done.


By Mike at Sun, 2007/12/09 - 6:00am

Interesting point raised. I started to think about the very popular Borealis sound theme on KDELook (http://www.kde-look.org/content/show.php/%22Borealis%22+sound+theme?cont...). Couldn't this theme have simply been implemented for 4.0 instead of a new one? It would've been much easier. Hopefully there will be an easy way to install alternate sound themes in KDE 4.


By Darryl Wheatley at Wed, 2007/12/05 - 6:00am

ACK because I'm also using Borealis. But if someone did import it, the window sounds should be disabled by default. I like dialogues being shown with a *plop*, but surely not anyone wants this.


By Stefan at Wed, 2007/12/05 - 6:00am

"But if someone did import it, the window sounds should be disabled by default."

IIRC, this was discussed on #oxygen and it was decided that, yes, window sounds will be disabled by default.


By anon at Wed, 2007/12/05 - 6:00am

I would prefer some discordance(?) when something is wrong. And the log in and out was too similar (As long as the shutdown/startup process doesn't pause while it plays the sound, I don't really care much for the length).
Other than that, I thought it sounded kind of professional;)


By Martin at Wed, 2007/12/05 - 6:00am

Pages