Content Hub - suggestions for improvement
-
Hello,
I have a few thoughts on Content Hub's direction - let's open the discussion
-
Read-only mode:
Let's say I have a music file, being for example a recording. I'd like to play it in a music app or media player app, but without exporting it and adding to library. Could it be possible in future to have to have a view option, so that I could just play it via music app, but not copy to its directory? Alternatively, it could be copied to a kind of app's temp directory, which would be cleared every time application is closed and not listed in file lists, media libraries etc.
I think it could be a default behavior for many apps, such as gallery or music app - they could by default just view the file, but have an "Import" action, which would move the file from the temp directory to app's Imported directory, as it's done automatically today. The other option could be modifying the file in temp directory in app and export it to another app as "save". In that way I could open a text file via text editor (in temp dir), edit it and export it to file manager to save it (or to Dekko to email it) - without storing it in text editor's dir, or even without the need for text editor's dir as well. Some apps would not need the storage directory - they could allow only to view files and export them to other apps. -
Multiple actions per app:
For example gallery app could be used for either viewing the photo, or editing it. Content Hub screen could be rearrange from grid to list view, and apps could list its actions if there was more then one. -
Exporting only when needed:
I'm browsing my photos folder using file manager and want to - let's say - .zip a few of them. I want to check, if the file is the photo I want in my archive. I open the file with gallery and the file is exported and duplicated in gallery (the other copy of the photo appears at today's date) despite the fact that this particular file is actually in folder accessible from Gallery app all the time.
I think that Content Hub should detect such case and prevent exporting it again. Insteadm, app just should be made open its own file.
Doable?
-
-
As part of the File Manager refactoring, I've been working on a draft for Content Sharing back in August. The main problem was that users were expecting File Manager to load any content type, rather than exporting it through ContentHub; then, I started a comparison with the Android platform.
TL;DR
What I found by far was:- Ubuntu Touch does not actually distinguish between private storage and public storage. Third party apps can only access private storage (i.e. ~/.local/share/app_id)
- Ubuntu Touch does not provide any Android-like intent for opening files, and the respective XDG protocol (xdg-open) is not supported as well.
- In Ubuntu Touch, all these features above are replaced by ContentHub, which causes huge issues in UX.
- The whole SD card acts like a public storage on Android - but it's out of scope for this specific topic
My wild guessing for your questions
-
That seems hard to achieve in the way we would expect on a desktop - I guess - for the reasons explained above. The confinement rules and the non-standard way content are handled does not seem to integrate with standard tools.
-
This could be achieve already:
2.1) Apps like gallery-app could prompt for a specific action when there's a transfer on-going
2.2) A single click package could ship more than an application registered to ContentHub.
2.3) For specific "well-known" actions implemented by core-apps, third party applications could rely on UrlHandler. For instance, this is what we're planning to do with the new File Manager, when we will add the built-in text editor. -
When I still was the DocViewer maintainer, I've been asking to ContentHub devs to expose the original path of an imported file, in order to prevent this (in a sane way).
-
This is part of the draft I was working on:
1 ) Allowing apps to access specific sub-folders in XDG user's paths. That would be possible by adding 4 new AppArmor permissions, for a total of 16 lines added.
2 ) Changing the path where core apps import ContentHub files.
The current situation is:- ~/Documents/Imported/*
- ~/Music/Imported/yyyy/MM/dd/hh/mm/ss/*
- ~/Pictures/imported/*
- ~/Videos/imported/*
I would propose to change them as follow:
- ~/Documents/Apps/<app_id>/*
- ~/Music/Apps/<app_id>/*
- ~/Pictures/Apps/<app_id>/*
- ~/Videos/Apps/<app_id>/*
The major effects are:
- We would provide a proper separation between private storage and public storage
- Apps that currently uses ContentHub for exporting pictures, could easily (re)gain ownership on the exporting content
- Exporting content via ContentHub to a core app would be de-facto deprecated, so your point 3) would be fixed.
ContentHub would still be available for sharing files between third party apps. - MTP would be available for third party apps too. This might be useful for e.g. platform emulators, since users would be able to sideload ROMs in ~/Documents/Apps/gameboy.appmaintainer/*
Issue you mentioned at 1) would also be solved in the 80~90% of cases. For instance:
- An audio recorder app could use the new "public_music_folder" policy and save recordings in the Music folder.
- Received media on Telegram would automatically be stored in the Pictures folder, and they would be available in gallery-app
- Uncovered cases are mostly about the hack/dev tools currently available in the OpenStore. However, as they require restricted permissions, they are not a huge problem.
I haven't found the time for further validations, as I planned to check how these policies would work with ~20 different apps currently available on OpenStore.
Anyway, it might be worth to add them to this discussion in order to have more proposals, and try to see the overall picture -
I feel that there are a few drawbacks here:
- It will be problematic for apps having files, which are not easy to classify as a document/music/video/picture (for example sound effects, source files, exportable game saves, compilation outputs, recorded sounds).
- After recording sound with a sound recorder, it would still add to the music library, which would be very irritating. The same, document viewer would include on its list every source file of an app you develop convergently, as they would probably need to land in the document viewer folder.
In my opinion things should be much closer to what they are now:
- Each app still has its own directory. Apart from that, there are XDG directories, which can be accessible for apps having proper permission (just as it is now).
- Make "HubIncoming" directory cleared every time app is closed (or base it on app's flag, so that legacy apps not supporting the new way wouldn't break). This directory's content is never listed in app's file list, music library, gallery etc.
- After importing, app does whatever it wants with the file. If the file is not needed permanently, it is left as-is and viewed - on closing app it will be removed. If the file is needed, it is moved within the app's cache to another subfolder.
- Until this step, the changes in Content Hub might not be needed at all, also no new permissions are needed. Here the development of the Hub itself kicks in: multiple actions for application. A Click package can register multiple actions for Content Hub. Having this while exporting you can decide, whether you want to view the image in gallery (for example) or export it. Hypothetically you could export multiple files to the gallery at once. They will be moved by the gallery's code to other subdirectory (Imported for example) and made persistently available in the gallery app. At the same time, you could return to the app from which you exporting without even a need to show the gallery screen at all, and have just a toast from Content Hub saying "Files exported".
- Public subfolders are only good in some cases, but the current approach to them is OK. For example camera is a source of pictures that should be generally available - that's why it places them in public Pictures folder, where it has its subdirectory to indicate the source. The same approach could be used for music streaming app (such as Jamendo client for example) - you could quickly download a song and place it in app's subdirectory in music. When you do this it is also instantly available for the stock Music app.
- The other case which needs to be changed in Content Hub is announcing the source path to the destination app, so that it could be used to prevent importing if source file is accessible as-is.
- Content Hub also needs an option to have a default apps for mimetypes. Exporting a file should allow to specify, whether to use the default app (best for viewing files) or show a list. File manager could have "Open" and "Open with..." actions to trigger.
I also believe that text file editor build in file manager is not a good idea. People might want in future use different text editors. That's why clicking on a text file should trigger Content Hub and not the internal view/edit mode. Also I believe that the full-fledged app for file editing should be present, so that it could import files via Content App from the other apps as well. Having the option to set the default app to view the file will solve the problem of having to choose an app every time.
For sideloading, your approach makes it slightly easier, but stiil I think it is not a problem to put a file via MTP in Downloads folder and import it (and move to permanent app storage) to the app (your game boy example).
I'm also not a fan of app subdirectories in public folders, as it clutters them. It's a nice approach for apps that are source of publicly available media (such as camera app), however I wouldn't like to have a separate directory in ~/Documents for almost every app I install. Let's leave the Documents directory for the documents themselves.
On the other hand, I believe that there should be an option to create a custom directory in the home folder (for example Projects or Dropbox), which could be available for MTP and apps that user explicitely permits. In that case the Game Boy emulator could create a directory ~/Game Boy Roms, where you could sideload ROMs via FTP. They could be accessible for multiple emulators as well. This approach could be great for custom content types, such as mentioned ROMs or developer's projects accessible for example from Seabass.
-
Hi, can you tell what is the current situation, how did you decide to improve Content Hub performance and behavior? Many Thx
-
Not much really has changed in the content hub.
I like the intention of content hub but currently it limits the functionality that's getting in the way of a good UX.
This is just my opinion -
@kugiigi I've only just got used to how things work now in OTA 8. I believe it would be almost impossible to judge from a textual description whether an alternative approach would be better or worse. There are so many use cases that it would take weeks to properly evaluate an actual implementation.