On Sunday, 2013-04-28, [email protected] wrote: > [email protected]於 2013年4月28日星期日UTC+8下午11時18分14秒寫道：
> > I always like the idea of GVFS mount daemons. I think that a Qt based > > implementation of at least the client library would make a nice official > > Qt > > addon, that is, assuming that a couple of the mount daemons can be made > > crossplatform. > > > > Basically getting remote file access available on all Qt supported > > platforms, > > even on those that do not support it themselves. > > > > When GVFS was introduced I investigated the option of implementing the > > protocol using Qt native facilities, but at that time maintainer > > Alexander Larsson said that the protocol wasn't stable enought yet. > > IIRC, there was some attempt in the past to make it work with Qt. > Kommodity http://websvn.kde.org/trunk/playground/libs/kommodity/ Interesting, didn't know about that one. Still a wrapper though, i.e. would still need GLib event loop integration which is only available in the Qt unix event dispatcher. > And there was also some work to make KIO slave work with Gtk+. > https://live.gnome.org/KioGioBridge Right, knew about that one. Not the best approach IMHO. > > > An alternative would be to use KDE's KIO slave, if you're OK > > > with the KDE dependencies. > > > > KIO will be one of the KDE frameworks rated as Solution, i.e. depends on > > runtime services (just like GVFS), but it has very little other > > dependencies. > > Really glad to hear that!! It's a long awaited feature. > Gvfs, however, has one thing that always beat KIO slave. > It's implemented in plain C and can hence be usable from nearly any > programs. Both GVFS mount daemons as well as KIO slaves operate as separate processes, communicating with the applications using (Unix domain) sockets and D-Bus. The sockets are as always a perfect dependency and license barrier, a client can always use a totally different implementation than the "server" (GVFS mount daemon or KIO slave) > C++ APIs, like KDE ones, are hard to use in C programs. Sure, but why would one use a library based on a different technology stack if the actual API is the protocol on the socket? It is like wrapping dbus-glib instead of either using the low-level protocol library (like Qt did) or implementing the protocol directly (e.g. Java, Mono, etc, did that). > Creating a C wrapper around a C++ library is really a boring task and I > guess nobody will want to do it. And it would be as pointless as wrapping a C application library. There are major differences in APIs on whether they are intended for other library developers or application developers. This is why xlib sucked so much, because it was originally intended for application developers but then always wrapped by toolkit developers. XCB allows toolkit developers to be far more effective because they don't have to wrap API that wanted to be "easy" for app developers. I personally always find it puzzling why the moment the socket type is not IP based, a large portion of people start to assume that there is some kind of dependency between servers and clients, right? Like if web browers written in C could only easily connect to web servers written in C, not to those written in C++, Erlang, Python, Ruby, NodeJS, etc. Hilarious thought, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
_______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
