In D20655#647806, @davidedmundson wrote:

We copy udisks xml already. I don't think it ends up any better. Otherwise we have a compile time dep on a runtime plugin, which inevitably means we need to make it optional which only introduces more real-world bugs. It also means future devs know what we were compiled against.

Marking as requesting changes for the extra include, but personally I think it's generally good to go.

move statics into namespace

put statics in namespace

thx

Regarding API, done is a little bit vague.

In D28682#644914, @astippich wrote:

Then it's fine from my application point of view. I can add a corresponding start signal for convenience, though. Your call.

In D28673#644778, @broulik wrote:

Yeah, can probably be a startsWith

In D28682#644430, @astippich wrote:

In D28682#644414, @bruns wrote:

In general fine for me.

How will Elisa deal with the indexer maybe crashing inbetween? Do we also need a signal for a batch start?

From my (limited) understanding, the finishedIndexingFile will no be emitted when an indexers crashes, does it? Then I think it is fine without an additional signal as long as the done() signal is still emitted as it is possible to reset the applications' internal list. Or will it retry some files of the current batch?

In general fine for me.

In D28400#643965, @bcooksley wrote:

Sorry, but that isn't how this works. Also, you will notice that one of the failing platforms is FreeBSD. Which is freely available and OSS.

In D28400#643934, @bcooksley wrote:

The following is notice that the following reviews/commits are being scheduled to be reverted in 24 hours due to the FTBFS on Windows and FreeBSD:

• 2b9c468816459a318dd2c8fe96e5e5acf1cedfd1
• 2fa16a2865dc385f1106c3eadb363bbe9d1244b1
• d4494ee496640325fb6fd72b80f12c5c4b124d22

There are two possible ways of changing the caching, and each one will break behavior for one of two different groups of users:

Btw, label() is a bad name, it can be confused with the filesystem label to easily. Maybe shortName().

I think it would be better to not change behaviour for any backend, but just default label() to description() everywhere.

In D26113#642022, @meven wrote:

In D26113#642018, @bruns wrote:

In D26113#641998, @meven wrote:

In D26113#641190, @bruns wrote:

In D26113#581228, @ngraham wrote:

As Vaults are not backed by an fstab entry, it would be the responsibility of Vaults to set a useful name (via x-gvfs-name).

What I'm saying is that I think it makes sense for Solid to provide a better default display string so each app doesn't have to do this.

What I'm saying is that Vaults should set a meaningful value via x-gvfs-name so Solid has not to invent something. Then Solid can use that, and it would be consistent everywhere.

I see, so I think we should add a "displayName" (or label() similarly to StorageVolume) function to Solid::Device, so that x-gvfs-name is used for this or the mount point when not defined and keeping description as is : a verbose description of the Device that could be used in tooltips for instance.
This displayName would default on description() so that it would be an opt-in change by Device implementation and then users can choose between description() and displayName() depending on the context and role they need. So here in kfileplacesitem we would replace description() by displayName().
Does this idea make sense to you @bruns ?

Its already there:

grep x-gvfs-name  /etc/fstab 
//pebbles/share /mnt cifs defaults,x-gvfs-show,x-gvfs-icon=yast-samba-server,x-gvfs-name=SambaShare

solid-hardware5  details /org/kde/fstab///pebbles/share
udi = '/org/kde/fstab///pebbles/share'
  parent = '/org/kde/fstab'  (string)
  vendor = 'pebbles'  (string)
  product = 'share'  (string)
  description = 'SambaShare'  (string)
  icon = 'yast-samba-server'  (string)
  StorageAccess.accessible = false  (bool)
  StorageAccess.filePath = '/mnt'  (string)
  StorageAccess.ignored = false  (bool)
  NetworkShare.type = 'Cifs'  (0x2)  (enum)
  NetworkShare.url = 'smb://pebbles/share'  (string)

A lot of users won't have a x-gvfs-name for whatever reason and we can't expect them to be take savy with root access to set up a x-gvfs-name mount option.
I see your point but my last one was how to make the display by default better (not using description()), but keeping displaying x-gvfs-name value when defined by the user.

In D26113#641998, @meven wrote:

In D26113#641190, @bruns wrote:

In D26113#581228, @ngraham wrote:

As Vaults are not backed by an fstab entry, it would be the responsibility of Vaults to set a useful name (via x-gvfs-name).

What I'm saying is that I think it makes sense for Solid to provide a better default display string so each app doesn't have to do this.

What I'm saying is that Vaults should set a meaningful value via x-gvfs-name so Solid has not to invent something. Then Solid can use that, and it would be consistent everywhere.

I see, so I think we should add a "displayName" (or label() similarly to StorageVolume) function to Solid::Device, so that x-gvfs-name is used for this or the mount point when not defined and keeping description as is : a verbose description of the Device that could be used in tooltips for instance.
This displayName would default on description() so that it would be an opt-in change by Device implementation and then users can choose between description() and displayName() depending on the context and role they need. So here in kfileplacesitem we would replace description() by displayName().
Does this idea make sense to you @bruns ?

looks good to me otherwise

In D28555#641390, @dfaure wrote:

Sounds like the size check should stay then.

@dfaure: probably this:

In D26113#581228, @ngraham wrote:

As Vaults are not backed by an fstab entry, it would be the responsibility of Vaults to set a useful name (via x-gvfs-name).

What I'm saying is that I think it makes sense for Solid to provide a better default display string so each app doesn't have to do this.

.