It's still work-in-progess, but we have some good news. During the last weeks, with a massive help from @nfsprodriver , the new File Manager finally started to take shape.
We will probably release a testing version in the store next week, so you can provide us all the feedback about the new UI and - most likely - bugs
Hi everyone,
I'm Stefano Verzegnassi, I'm 25 and I've been a community contributor and maintainer of some of the Ubuntu Touch projects.
My relevant contribution to the official projects are the Document Viewer (and its LibreOffice integration) and the Terminal app (I've been maintaining it in its latter days, before it moved under the Canonical "umbrella").
Other popular works I've been working on are UT Tweak Tool and InstantFX, which got a decent reception.
Unlike the other stories above, I'm a Political Science student with a strong interest for technology and Open Source. I've been using Ubuntu since 2007 or so, and I started to follow the UT project for its ambitious vision.
While I'm not yet sure of the time I could dedicate to the project, I'd be more than happy to help keeping UT alive. 
Quoting from the Telegram supergroup:
We are within the fair use guidelines outlined by Canonical.
According to the Canonical’s IPRights Policy, there is no proibition against using a "UB-" prefix, which anyway doesn't necessarily imply an endorsement or an affiliation with Canonical. The goal of UBports is to make Ubuntu running on as many smartphone/tablet devices as possible, so we are really within the fair usage of the trademark, as we are part of the Ubuntu community.
"As long as there is no commercial use" (quote from Canonical's IP) we likely won't have any trouble.
The only problem that could be raised in future is our reference to the "Ubuntu Touch" project.
What we are currently shipping is exactly the same code Canonical wrote, so I don't expect any problem with this for now.
If things will change in future, we can simply rename our project as "UBports Touch" or "UBports OS". I don't see such pressure for changing this yet - just my opinion.
@Flohack Sure, it's in one of my earlier replies. (still WIP)
Here's how the "Donate" button might look in future OpenStore releases
Nice to see so many replies, thank you all for your help!
I'll try to keep this very brief. 
I see that moving files is somehow more important than other operations. We'll try to respect this evidence.
There will be improvements for the user interface, we want to be consistent with Suru specs as much as possible.
However there could be some exceptions, since a File Manager allows an high number of advanced features.
Our keyword here is probably "predictability" rather than "consistency".
In any case, we'll wave back to the forum once we have our first mockups.
We want to keep things as transparent as possible
I’m glad you mentioned "checking downloaded files" or "delete [files] when space is tight". We were expecting similar replies, and we’ve got a confirmation of how relevant is making such actions easier to perform.
SD card access: we'll probably allow it. According to the consensus we had at the App Devs meeting, there's no reason to prevent this.
Tabs: many of your replies concern this. This is for sure on our To-Do list. Implementation is still TBD.
Search: Yes, it's on the list. 
Scripts: This is an interesting option for the future, however it’s a feature that needs to be wisely designed. I think we’ll keep it in consideration for a mid term.
@Ads20000 A month ago, when I wrote it, many things were still unclear.
There were less people involved on the project, much less interest from the community, and the future of UT (and yunit) was much uncertain. During the last month, many people (even ex Canonical developers) jumped in, and many things got sort out. Also, the hype within the community increased a lot.
If you ask me what I think about convergence, I still think that it shouldn't be the first priority, since what has been left by Canonical still requires a lot of work. I still have some doubt that one single shell (which relies on many technologies written exclusively for Ubuntu Touch - e.g. the app confinement story, in particular) could satisfy the needs of both phones and desktops.
The question I ask myself a month ago was: could we expect people will still have interest on Unity 8 e.g. in an year? My answer now is that we can still put some effort on convergence, since now more people are involved on both projects, and keep everything alive.
Money and donations surely help, but I suspect there's still some trade-off. If you can't get developers to work on other parts of the platform too, it's hard to get things done. However this is not the case anymore
@bq4.5 No problem, we still have to improve the way we provide such information to the users.
For now, I'm leaving here a reference to some useful guide in our wiki - it could be useful for other people as well
Thank you again, please mind to report anything else you think is unexpected. We really need feedbacks from our community.
@demokrit, right!
We probably need anyway to get in touch with Canonical. There are interfaces for Ubuntu Personal/Touch, but I'm not sure they'll be supported in future. Their plan was to deprecate the transitional interfaces for content access, but I guess now they will be the only interfaces used on desktops.
For the confinement, the problem is not to run Snap, but running Snap with all the security enhancements. AppArmor itself is not a problem, but adding the module in the Android kernel might be (for what I understand of all that magic @mariogrip & co. usually do behind the scenes).
Click and Snaps are a bit different but, overall, yes, they are meant to solve the same problem.
Any opinion is welcomed here. Don't think I'm an expert here, I just know how to write some code -
mostly by mistake
@CyberAly There is no particular issue in building an OS upon what they have created, like ElementaryOS or Linux Mint did (well, in the LM case there have been a few).
But we can't use their name to promote ourselves. That's set in stone in their policies.
The most we can bring the Ubuntu name back is to keep that "ub-" prefix. Any usage of "ubuntu" or "-buntu" suffix is strictly forbidden. Using a "u-" prefix is not explicitly forbidden, but Canonical has already moved actions against such usage in the past.
It could be possible to ask Canonical to make "Ubports OS" an official flavour, but I can't see any real advantage in doing this. UBports would probably have to accept certain restrictions (e.g. in governance, I suspect), just for using the "Ubuntu" name. It is not worth, in my opinion.
UBports has already had a discrete coverage on the internet, so I don't believe they should completely wipe their current name away, at least for what concerns their team.
However - and I think it's a shared feeling here - the OS should really get its own brand and identity in future. To clarify my previous words, in case of emergency "UBports OS/Touch" could still be a valid fallback solution.
@Flohack Did you mean this?
It's just an early exploration done through a QML mockup, the UX design is currently the same used for scopes.
Conceptually, it should work as a JSON documents aggregator. Apps would be able to update their data in background, using the new account-polld service, or during app execution, and the homescreen would fetch those new data once they become available.
This way the homescreen would work like a sort of Google Now clone, without sending user's infos here and there. Everything relies on the availability of those data locally.
What it would get lost is the ability to perform per-scope and remote searches, however it would enforce a proper model where advanced features are provided by apps only. In any case, we could add a search bar in a different tab in order to allow online searches via Google, DuckDuckGo, etc. anytime.
This would be available for all the third party apps that'd like to use it, with the only limitation that their "homescreen widget" could expire if their data are not up-to-date.
A few integration cases I will probably take in account are: Apps, Events, Weather, News (e.g. Morning Digest, Afternoon Edition), Bookmarks, Contacts, Documents, Books, IM apps (e.g. for latest conversations list), Notes/Tasks, World Clock and Spotify playlists.
Of course, this is just an idea that hasn't been validated yet. Nothing has been decided yet.
If you’ve watched the latest UBports Q/A, you might already know that we’re looking to improve the File Manager.
Yesterday @Flohack and I briefly discussed this, and we agreed that it’s unclear how a File Manager is supposed to work in the “brave new world” of containers and app confinement.
While we all know how a File Manager should work on a desktop, this is not a trivial question for a mobile environment.
We have decided to run a short (informal) survey[1], in order to understand your real usage of the app. This is open to everyone willing to help, and I want to thank in advance all the people who are going to contribute.
Why do you think it’s important to have a File Manager on your phone? (Or why not?)
Which are the most important features for you?
Which are the common tasks you try to accomplish?[2]
How the current version of File Manager fails to meet your expectations?
==========
Note #1
This is not about bug reports, we are interested in your typical app usage. Please do not reply:
- add { missing feature | support for x | etc. }
- can't open { file format }.
We’re going to address those issues once we have the whole picture clear.
Note #2
I.e. "Why do you use those features?" A few examples:
- Accessing remote files through Samba.
- Cleaning up internal storage because memory is low.
Hi @Phil-UK,
I'm helping @Flohack with the Core Apps forks and the list he mentioned above is actually written using this other list as reference:
https://docs.google.com/spreadsheets/d/1xzNGy4zh6c-nICsodnjMEdHCPA7DEfkS8cRkXbXE8P0
It includes:
The list I wrote is actually meant to be the "all-inclusive list of everything someone could ever need on a convergent phone", so it is no way an official reference to the work UBports is going to do (I'm not even involved in UBports - just helping a bit here and there in other projects).
You're welcome to give it a check and tell us if we're missing something we'd need.
I have some question as well 
rules a bit, so that apps e.g. can save files in /home/phablet/Pictures?
Leaving the security questions apart[1] , you've greatly summarized the reason of our research.
File Manager escapes any abstraction provided by the system, but other apps don't. We end up with an unconfined app that actually seems even more "caged" than others.
I’m planning two different strategies in order to solve this:
Anyway, it's great to read you're going to improve SD card management, this would be a big change
======
[1] It’s all about enforcing consistent policies. We just had some early discussion on this topic for now, but I’m sure others will follow
@Phil-UK That's the point. For each service you use, there are at least other five services an OS should support. For example, WhatsApp has been the reason why I never switched to an Ubuntu phone as main device.
About core apps: I agree, there's a lot to be improved yet, and my rational thinking says that we should focus only on a small set of core apps, on a specific type of device (i.e. phone) and forget the rest.
What we'd need then is to provide the best development framework we could offer, in order to allow third parties to support those services with the minor effort.
I'm going a bit OT, but you can understand how I think that we should stop talking about convergence and focus on having something that really works first.
The biggest chance for me to switch to UT has been the BQ M10, as a replacement for my old netbook. I want convergence, but it needs to be something that really works, with no hackish stuff.
IMHO, if the BQ M10 was shipped with Ubuntu GNOME (and GNOME Shell), that would have been the best buy for everyone. UT was pretty far from offering such user experience.
This is something that should be considered for future development.
I missed this topic, but I see @Flohack has already provided solid arguments.
elementaryOS is backed by "elementary LLC" which likely enables them to handle money on a solid legal base. I gave a quick look at "Houston", the app store back end used by elementary, and it seems they only support a single service, called Stripe. I haven't tested personally, but what I see is that developers might likely have to create a Stripe account in order to receive donations.
This might add a further consideration: choosing a single service implies excluding others.
We could offer e.g. PayPal support, but I'm mostly sure our developers might (legitimately) ask to support Patreon, Liberapay, Bitcoins, etc. Not to mention potential existing service bans in specific countries. It might end up in a huge amount of work, for an app store service that merely counts 400 apps and has not fully shaped yet.
What we did in OpenStore, but we still need to expose it to the client app, is to let developers to specify a link of their choice for donations. This already enabled developers to received donations through the OpenStore web UI - e.g. Dekko.
I'm in charge to get this done in the client app. Despite my expectations, adding a single button to an existing hiearchy of informations is not so trivial; as a consequence, it might take a while before we could roll this out in a new update, since we have to redefine how we provide other metadata.
I'm currently redesigning the "Package Details" page in the OpenStore client, and the idea is to ensure that our "Donate" button would always be placed above the fold, in order to ensure that potential donors would not miss the opportunity to support the work of developers and contributors.
Here's how the "Donate" button might look in future OpenStore releases
Feedback welcomed!
@TLF I see you mentioned Document Viewer. I proposed a patch for this issue more than an year ago. I've pinged Canonical people several times, nobody cared to release an update in the Ubuntu Store - this is something somehow sad.
As former DocViewer developer, I'm really sorry to read this and I want to apologize.
I'll try to win my resistance, and plan to release a few small fixes in order to solve those issues that appeared over time.
@Mitu Sure, but it means to me that convergence, Click, and current phones support wasn't the focus for terminal-app since November, 2016. I know that terminal-app works on the phone without issues, but keeping phone requirements in sync was still desirable, and Ubuntu Personal images were much far from being stable and ready to be released. And there's no "legacy" branch for Ubuntu Vivid phone images either.
I respect Canonical developers, I had the honor to meet them and they are great people, but it seems to me that last days of the Ubuntu convergent platform weren't so happy
A development release of File Manager (v. 0.5.x) is now available on OpenStore. It won't uninstall the stable version you have already installed.
https://open.uappexplorer.com/app/filemanager.sverzegnassi
Please let us know your feedbacks, so that we can sort out the final fixes and release it as stable.
Thanks everybody for your help!