20

Probably the most painful part of using gnome apps under KDE and visa versa is the inconsistency in file dialogs.

I'm talking out my **** a bit here because I don't know exactly the code mechanics of this but... it would be real neat if, instead of constructing the actual dialog, the application made a call to the DE to obtain a file selection; and the file selection dialog was instantiated by the DE; the results returned to the application. Just some basic IPC.

That way the file dialog would always be consistent with the current DE (and at least some file browsing methods and tools associated with it). A default dialog would still be needed for cases where the DE didn't provide this service. But in the case it did, applications would blend in much better. (firefox I'm thinking of you)

In firefox case this would work lie
FF(request for file) > gnome(redirect request) > kde (Do the job) > gnome(return result) > FF(be happy)


Might be this could be done by patch to gnome for kde users and vice versa.
For 1 DE users this would do the job, for multi-DE users, well they are used to both dialogs, so no big problem for them if this solution doesn't fits them

gnome == gtk?

Basic file dialogs are not the problem, customized ones are.

E.g. application specific widgets in the dialog, like properties of the application's data type, etc.

An additional problem is protocol support. A KDE file dialog supports quite a range of possible file access protocols, it could return an URL the calling application cannot handle.

Cheers,
_

anda_skoa wrote:Basic file dialogs are not the problem, customized ones are.

E.g. application specific widgets in the dialog, like properties of the application's data type, etc.

An additional problem is protocol support. A KDE file dialog supports quite a range of possible file access protocols, it could return an URL the calling application cannot handle.

Cheers,
_

what about letting to anything that KDE allows, but for non default URL, make a copy to tmp and return link to lets say /tmp/User/[real file name.ext].

This way would any protocol be accessible.

Also gnome is going to the forward to 3. So if KDE developers would start writing support for something like in post1, I'd bet gnome (and might be other DE's too) would join the idea.

Lukas wrote:what about letting to anything that KDE allows, but for non default URL, make a copy to tmp and return link to lets say /tmp/User/[real file name.ext].

It is a work around, not a good solution and has its own share of problems, e.g. hard to detect when a file needs to be uploaded again, when it can be deleted, etc.

Lukas wrote:Also gnome is going to the forward to 3. So if KDE developers would start writing support for something like in post1, I'd bet gnome (and might be other DE's too) would join the idea.

I have been working on similar things in the past and I bet they wouldn't

Cheers,
_

This sounds like something that KDE would have to do, i.e. watch for and intercept gnome/gtk file picker api calls, replacing them with their own.

anda_skoa wrote:I have been working on similar things in the past and I bet they wouldn't

Sad to hear

Sad to hear but not unexpected... different dev teams have different visions for how things should work. But the KDE community seems to be playing a grater role in freedesktop matters recently. Perhaps this is one path forward.

Another may be to make an independent library of the KIO stuff - so that many apps could make use of a common high level way of abstracting file access. I guess the "G" camp have their own approach to that also (GVFS/GIO). Question is how can we allow both to grow and compete while still allowing increased interoperability. This is happening (but has been a long road) with audio.

Some discussion here http://osdir.com/ml/general/2009-07/msg09908.html