Also, unity7 for it to use the indicator instead of the legacy status icon.
The only issue is that it doesn’t show the icon in this case…
Glad to see that you have come across it! The snap is not really functional yet. The CLI is mostly running well but doesn’t have proper access to folders set up. It still does everything in ‘~/snap/maestral/’. The GUI still refuses to start…
The dropbox folder itself is indeed very likely to be visible and in the home folder. I am more concerned about hidden files and folders inside the dropbox folder. First, Maestral currently reads an “.mignore” file inside the dropbox folder for the user to specify ignored directories similar to “.gitignore”. This is of course a design choice and can be changed. Second, there may be hidden folders inside the Dropbox folder, created manually or by other programs such as git. Dropbox itself fully supports syncing them and I would therefore consider not syncing them with Maestral as a “bug”.
Otherwise, yes, it looks like I would need a network plug, unity7, home and possibly removable-media.
Why would it not show the icon?
There is no plug allowing access to hidden files, is there?
In the files are IN the dropbox folder they are visible.
The only files that are not visible are the invisible ones in the home folder.
I have a working (it seems) non classic snap.
The icon issue might be solvable, probably simply a system library is missing in my snap…
I uploaded the snap in this fork: https://github.com/LyzardKing/maestral-dropbox
I’m still testing it to add the desktop launcher…
Also the info (version/description I avoided to fill, just to get a working version)
Ah, that must have been a misunderstanding on my part. I expect all hidden files, even in subdirectories, to be inaccessible.
Looking at your snapcraft.yaml, it certainly is much simpler than what I have tried. I didn’t even know about the kde-frameworks-5-core18-sdk snap.
With the latest push to master in my fork the snap size is half than before.
I was installing maestral and qt multiple times.
Nice! What is the total snap size?
77 MB at the moment
It should contain everything needed, since the qt libraries can be fetched from the kde content snap.
Then it needs to be connected to the content snap, but that can be automated by opening a request on this forum (like Autoconnect ksnip to kde-frameworks-5-core18)
Yes, that is quite good. Its sill quite a bit larger than the macOS bundle, which comes in at 50 MB with all qt libraries included. The kde-frameworks-5-core18 snap alone is another 279 MB if people don’t have it already installed. But I appreciate that packaging on Linux works very differently…
I have also seen that you have started a discussion on auto connecting kde-neon here which makes a lot of sense to me.
In the latest push I enabled the icon and also reduced the snap size to 53MB.
Nice. By the way, thank you very much for taking the time do this. I was helplessly lost between the snap documentation and examples on github, many of which seem unnecessarily complicated. While I did get the GUI running in the end, the scaling of UI elements was all wrong and the status bar icon refused to show as well.
Just to understand, what does the cleanup step do? Does it actually install the kde-frameworks-5-core18 snap and then remove unneeded components?
Also, I noticed that you override the TMPDIR variable to XDG_RUNTIME_DIR for libappindicator to find the icons. This may have some unintentional side effects since Maestral uses TMPDIR as a staging ground for downloads. But it may be fine, depending on the value of XDG_RUNTIME_DIR in the snap.
Maestral tries to load the status icons from the user theme first (it installs its own icons in hicolor, which likely does not work from a snap) and falls back to loading the files from its own resources if this fails. This second approach has some problems on hi-dpi screens - Qt seems to mess up the resolution of the icons when passing them to libappindicator but I am not sure what exactly happens there. This may be worth keeping in mind.
The cleanup step doesn’t install anything, it just removes any file that is contained both in the snap and the kde content snap, to reduce size.
I think that changing the TMPDIR shouldn’t be an issue, it just changes where the tmp dir is for the snap, but it should then adapt the rest of the tmp uses… if that makes sense.
I’m using it now and it seems to work fine, but let’s test it a bit more.
Should I open a PR on the maestral-snap repo or the maestral-desktop repo?
Feel free to open the PR on the maestral-desktop repo. The snap repo was just for experimentation, to keep everything out of the way.
Thanks to the help of @LyzardKing, it sounds like the request for classic can be withdrawn. I agree that the home and optionally removable-media interfaces should be used instead of classic. If needed, The personal-files interface can be used for accessing hidden files that this snap is expected to own, but I suspect that is probably unneeded since the snap can save its data in either SNAP_USER_DATA or SNAP_USER_COMMON.
I’m removing this request from our review queue, but feel free to respond with more information if this is in error.
Absolutely right. How does one withdraw a request?
Hi @jdstrand
This snap still has one issue, linked in Qt5 appindicators not showing in gnome shell
The other problem is (same as ksnip) would be the autoconnection to the kde base.
I thought that since it is now used by the kde-neon extension, it would be (if not now soon) auto-connected, like the gnome base.
But that apparently is another discussion…
Any help in the indicator problem would be wonderful. It works for me in a clean ubuntu gnome vm, but it doesn’t seem to work for @sschott in an ubuntu vm.
It tuns out it that the icon does show, but in back on top of a black menu bar and therefore effectively invisible. The heuristics with Maestral uses to determine the appropriate icon for the platform apparently fail from within the snap. But this is another problem…
Nevertheless, as @jdstrand writes in the linked issue, this only works by setting the environment variables:
XDG_CURRENT_DESKTOP: Unity:Unity7
QT_QPA_PLATFORMTHEME: gtk3
There should be a better way to solve this…
@sschott - consider it withdrawn.
@sschott and @LyzardKing - I suggest bringing the appindicators issue up in the ‘snapcraft’ category so others skilled in this area can comment and/or suggest improvements for the situation.
Done already here: Qt5 appindicators not showing in gnome shell
I was just hoping you could point us in the right direction 