[Development] QStorageInfo

[Thiago Macieira]

On Friday 29 August 2014 15:01:31 Rutledge Shawn wrote:
> > And those libraries will open a D-Bus connection that we can't reuse, so 
> > that's more system resources spent.
> 
> 
> Well it's not like there isn't a technical solution to using qdbus instead. 
> (Would multiple instances of qdbus share resources?  If we can do that, why
> does udisks not do it?)  But it will take memory to load qdbus too, whereas
> libudisks2 may already be loaded.  And the fact that dbus does IPC with
> sockets is out of our control.

I was referring to the socket. The problem is that some Qt applications may 
require accessing the D-Bus system bus via QtDBus. If they do that and we also 
use libudisks, then the application has two open connections to the system 
bus. Remember that the system bus imposes resource limitations, including a 
maximum of 256 connections per user.

If you use QDBusConnection::systemBus(), the socket will be shared with all 
other users of that function.

As for whether QtDBus is already loaded, depends on your system. If you're 
using a Plasma desktop, it's definitely already loaded.
 
> > I'd still prefer to leave the detailed information to Solid. It's there 
> > already, has done that job for years and it doesn't depend on anything but
> > Qt 
 itself.
> 
> 
> Maybe we didn't need to add QStorageInfo at all then?  Solid is so universal
> that every app can use it on every platform?  I suppose on non-Linux
> platforms though, you'd typically have to ship it along with the app (along
> with Qt itself).  On my system it's a whole megabyte.  (And still depends
> on Qt 4, but that will change eventually.)

The only thing is that Solid is available under the LGPL licences only, so 
some users may not be able to use them. I see value in having some basic 
functionality in QtCore that is available under the enterprise licence too, 
but I don't think we need to duplicate Solid.
 
> We could remove QStorageInfo (it's not released yet).  Or solid could come
> to depend on it, and maybe shrink a bit by removing code that duplicates
> what ours is doing.  (Doesn't seem likely though, does it…)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center