Thanks to the Devs who are keeping Unity 7 alive in Ubuntu 18.04. I have been enjoying using it after installing a clean minimal install of the 18.04 iso and running sudo apt install ubuntu-unity-desktop ! Thus far, everything is working just fine. I did additionally install the extra compiz configuration packages and unity tweak tool and synclient package for my laptop, but those were just for fine-tuning purposes for my own usage.
Here’s to more Unity 7 in the Linux and Ubuntu world! Keep up the great work! Still working great 1 month later!
I’m running off the oibaf PPA on mesa 18.2-dev and I can say I’ve noticed Unity to be smooth 100% of the time when triggering expose, which typically gets sluggish after a while.
I installed Unity without that ppa just added it for testing. Everything seems fine and nothing is broken, I just uninstalled freepats. Some of the unity settings aren’t translated, they appear in english like Security & Privacy and Sharing.
Edit: Ohh… and Online Accounts is using the wrong icon if you use another icon theme. Papirus is using credentials-preferences.svg for Online Accounts, I don’t know if that’s the upstream naming pattern.
Can someone confirm issues with mounting iso or img files with nautilus? When I try to mount one it asks me for the sudo password, but that never happened in previous releases. I’m also not able to properly unmount them, only after a restart the entries disappear, then I tried nemo and it worked fine.
I think it’s an upstream issue, cause I installed Ubuntu 18.04 in a VM without installing Unity and in Gnome-Shell the same issue appears. I should mention that I only used the minimal install option on both installs, maybe that’s the reason.
If it is an upstream issue, can someone please file a bug report, cause I have no idea where and how.
The diff isn’t file managers, it’s Archive Mounter vs. Disk Image Mounter. The later requires auth as set by org.freedesktop.udisks2.loop-modify-others
You can edit that if desired… (- /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy
Ok thank you but it isn’t working as intended. If you press the Cancel button at the authorization dialog it’s mounting the file too and if you unmount them, the entries don’t disappear until he next restart. Installed Fedora 28 to check it and there are the same issues.
Unlike previous post this behaviour can be confirmed (dismissing auth mounts anyway, after unmounting entry remains)
So file a bug on gnome-disk-utility and or udisks2
(- as mentioned if that action, (udisks2) is set to <allow_active>yes</allow_active> then this poor behaviour can’t happen with Disk Image Mounter
Thank you for conforming it. The strange thing is, I installed 17.10.1 in a VM and mounted an iso file and there is no auth needed and they get properly unmounted (disappear from nautilus). Checked the settings of org.freedesktop.UDisks2.policy in both 17.10.1 and 18.04 for loop, they are identical, also checked the groups of the users, they are also identical.
The bug seems to be already reported, I will add my info there and thanks again, cause I didn’t know that’s an issue with gnome-disk-utility and not nautilus. I would have never found it.
On a bit further thought (never use this option myself so was a little ‘fooled’) don’t think there is any real bug here. There is no auth needed to mount, the dialogue is just asking for auth to modify the ‘device’. It’s possible in the past that occurred after mounting when accessing the ‘device’?
So now it’s just taking care of that right away.
Hi all,
I wanted to put this out there for a little feedback to the way I approach testing. I’m trying to develop procedures that are easily repeatable. Please take a look at my attached document and let me know if this is something you guys want to proceed with.
It seems you aren’t able to differentiate between mounting a loop device & modifying a loop device. The auth requested is for modifying. Maybe the act of mounting shouldn’t presume the intent to modify, if not that’s the bug. Mounting still occurs with no auth requested or required.
That’s possible. I don’t know it isn’t clear in the bugreport what the problem was and what they fixed, but at least it should be fixed and that’s the important part.
One problem I’ve found while using Unity with patched Nemo is that upon changing the desktop background, compiz seems to hard-freeze. Not even restarting lightdm can one get out of it, either go down to to ttyx and kill -s9 compiz, or reboot.
I believe this might be related to changing the background for the user at lightdm, as it reverts back to the default image (I do have the gsetting btw), whereas if I switch back to Nautilus it works OK.
Any movement with getting Unity fully integrated into Bionic? I’ve been playing with it in VirtualBox but it isn’t as fully functional as it is in Xenial. 18.04.1 will be released any day now, I imagine and I have to decide whether to stay on Xenial, upgrade to Bionic and hope I don’t find the Unity integration too annoying in its current state, or just switch over to Linux Mint.
I am not sure what you mean, have been running unity on 18.04 since release, it is as fully functional and integrated as I can remember and a lot smoother and more stable than default genome shell . VB is not a way to test Unity or any 3d desktop for that matter , most graphic effects won’t work because VB only has very basic graphic driver.
I don’t know it isn’t clear in the bugreport what the problem was and what they fixed, but at least it should be fixed and that’s the important part. 