@alan_g wow super detail answer thanks for the detail and the explaination.

@advocatux Thanks. I'm afraid I don't quite understand the idea behind the app. I suspect the intention is to freely select preferred apps and place them on a grid on the so-called desktop. Interestingly, an alternative selection of apps was simply implemented as an app itself. It would be nice if the default view was adapted to SuruDark. With the Tweak Tool many interesting variants are already possible. I would still like to be able to hide the permanent display of the device status. A refined UI could start with the following actions: Adding another mode to the fan and window mode, that uses tiles. Hiding respectively replacing the starter bar with a different one. Adding another launcher as one or more apps.

@fossMan Firstly, Wayland itself is not a library, so there will be no "autocomplete" for it. It's a protocol definition, which Mir implements. So you'd need just the Mir APIs to be completed. I don't know much about what all the fancy IDEs need for that, but it should be pretty easy to generate ctags definitions for Mir, which should work with several editors (like emacs or vim). I would expect some IDEs should be able to handle them as well, but I don't know.

Convergence is mostly a software thing. There are two parts to this: flexibility: the software including shell and application GUI adapts to the capabilities of the hardware it runs on. This means that the same software, with the same features, works well on a desktop, a phone or a toaster. agility: the software including shell and application GUI adapts to changes to the capabilities of the hardware is running on. This means that connecting a display, keyboard, dock etc. will enable user interactions optimized for these. Most existing software is not designed for either of these goals. The Ubuntu Touch experience of using "desktop" apps in Libertine speaks to this, it is possible to use these applications, but the interaction is poor because these apps do not adapt to the hardware. This can change but, like any change, there will be costs, pain and resistance until suddenly it will be done and everyone wonders why it was ever any different. But the software is only a part of what is being alluded to here. Real use-cases are not about using a specific piece of software, they are about accomplishing goals: publishing something, learning something, meeting someone. That needs a combination of user data, software and access to hardware. I've had a long career in software development and seen computing shift from centralized "mainframe" computers that hold the data and programs for multiple users to "personal" computers that hold a users data and programs and back to centralized "clouds" that hold all the data. That change has been driven by economics: changes in the costs of computers and of connecting them. While there are legitimate privacy and security concerns the economic drivers are currently pushing towards centralization and connections. Many apps are little more than optimized front-ends for data and computational services elsewhere on the internet. I think this trend will continue before a readjustment back towards "personal" computation. In this context, any "one device" we might carry is more about having the keys (or passwords) we need to accomplish our daily tasks than carrying all the software and data we use. If both my laptop and phone can support all my daily tasks interchangably, browsing the web, emailing, Telegram, IRC, software development, video calling, phone calls, SMS, etc. then I need only take the one best suited to the occasion. Having the same software and keys on both is what would make them interchangable. (And yes, phone calls are best on a phone while software development is best on a laptop, but making both possible gives me control.)

Unity8 is open source, and anyone can package it for their favorite distro and help do the work to make it usable. There's already work done on bringing it to Debian, Arch, Fedora, and SUSE, and that presumably means any derivatives thereof as well. However, the core UBports developers are not responsible for packaging it on other distros and integrating with them. There's also too much work to still be done with keeping the phones working and fixing issues there, to really concentrate on making Unity8 usable as a daily on PCs. There are also lots of changes on more recent distro releases which significantly impact Unity8/Mir usability, as described in the other thread started about Unity8 in 2019.

@marc_aurel I'm not very familiar with it, and haven't used it myself, so unfortunately not. It seems like maybe there is an issue with the version of lxd in use on your system. Probably should ask about that separately. But as I said, there isn't really much useful in terms of documentation in the unity8 tree. So for what you are looking for, is likely a waste of time to build it. Also, as scopes are going away, I suppose it doesn't make sense to publish the documentation. IIRC, most of the documentation is about widgets provided by Unity which scopes can "use" in their search results and previews.

ok I know

OTOH, I just today found a spare OTG USB cable in hand, and tried plugging in a mouse. Which worked very well--hats off to the UT folks.

Have you opened issues for these bug reports? There are numerous problems with Unity 8 on 18.04, and most of them are unlikely to get fixed soon.

So, I've had a chat with Gerry Boland (former primary developer of QtMir) and while this is not entirely straightforward to adapt QtMir to it does look feasible. The relevant changes would be in MirSurfaceItem. Excerpts of the relevant IRC log: to provide shaders, need to implement QSGMaterial somehow - https://doc.qt.io/qt-5/qsgsimplematerialshader.html and then use it in https://doc.qt.io/qt-5/qsggeometrynode.html#setMaterial https://codereview.qt-project.org/#/c/70577/7/lib/yuv_video_node.cpp looks vaguely appropriate. YUVAVideoMaterial is an implementation of QSGMaterial, whose createShader() implementation returns that handy QSGMaterialShader I think that's a good template to follow QtMir would need to have a QSGMaterial that also derived from mir::graphics::gl::Program, and took the necessary shader fragments and smushed them into the shader source it returns. Provide that as the mir::graphics::gl::ProgramFactory and then the Texture will supply you with the appropriate QSGMaterial

@donieck do it in two steps?

@gizmochicken said in 18.04 desktop - getting it working again: Note that, in addition to posting results for Mir 0.32.1 RC4 (installed from ppa:mir-team/rc), I also posted results for Mir 0.32.0 (installed from the UBports repo). Hope that helps. Just to follow up on this here: Unity8 is working for me with (or without) the Mir release 0.32.1 from ppa:mir-team/release. However, it isn't working with the gdm greeter, just lightdm. (I've not experimented with further greeters.)

It occurs to me that this might also help those interested in automated app testing.

@wgarcia you're right: https://code.launchpad.net/unity shows 7.5 as "trunk"

@pglushkov there's also a brand-new project to port UT to Raspberry Pi https://github.com/ubports/raspberry-pi/issues

@pixelr0 you forgot the link https://forums.ubports.com/post/8665

@gizmochicken said in No more "Mir EGL" on 1804LTS (Bionic): At the risk of revealing the I understand less than I purport to understand, I have one more question: I know this calls for speculation, but do you anticipate that the above mentioned problematic Qt based applications will behave reasonably well (as a stopgap) under the XWayland solution that you are currently developing for Mir? That is a reasonable expectation, although don't expect immediate progress! (We've not started coding yet,) But Qt applications are largely usable already (and Qt 5.9.4 was a significant improvement on 5.9.3).

@webdrake said in Organizing Unity8 work: @alan_g I'll reach out to @mariogrip directly w.r.t. all things UBPorts. You've been more than generous with your time, but is it OK to still ping you about Mir(AL)-related issues w.r.t. the USC refactoring? No worries if not. Yes, I'm still happy to receive pings about Mir(AL) related stuff (USC or otherwise).