alpha1 appimage

[star-buck]

@Elv13 : Lets continue with 3.0.0 alpha1 appimage:

• filename: kde-ring_3.0.0_alpha1.appimage
• solve missing themeing packages
• fix older glibc requirement
• get rid of the old gui (edit: added as requested in Berlin)

[Elv13]

I have to setup a crosscompiling toolchain anyway since upstream requires full C++14 and C11 support (GCC 6.2+), so what are the desired target archs? Obviously linux-musl-x86_64, but do you want an linux-musl-aarch64 (newer Odroid) and linux-musl-armhf (raspberry Pi second gen and older Odroid) too? Should I add an ARMv6hf Android image too for easier touch testing?

[star-buck]

The only other arch interesting would be pine64, otherwise lets not waste effort on those until after a first official 3.0 release.

[TheAssassin]

Pine64 ships with an ARMv8 (a.k.a. arm64 as called by the Linux kernel) CPU.

[Elv13]

Also called aarch64 by target names (afaik)

On Oct 7, 2017 1:46 PM, "TheAssassin" notifications@github.com wrote:

Pine64 ships with an ARMv8 https://linux-sunxi.org/Pine64 (a.k.a. arm64 as called by the Linux kernel https://linux-sunxi.org/Arm64#Naming_conventions) CPU.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ring-project/ring/issues/21#issuecomment-334929504, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUxoAIAuQmuIujAfhyB4Pna3cI3BxwSks5sp2SogaJpZM4PxSuN .

[TheAssassin]

Yes, see the link to the Linux SunXI wiki I posted.

[Elv13]

Sorry, I sent it from mobile. So yeah, linux-musl-x86_64 and linux-musl-aarch64 appimages.

On Oct 7, 2017 1:50 PM, "TheAssassin" notifications@github.com wrote:

Yes, see the link to the Linux SunXI wiki I posted.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ring-project/ring/issues/21#issuecomment-334929689, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUxoDEyfXNlZivbtbOZkNCDhH4D42c_ks5sp2V5gaJpZM4PxSuN .

[Elv13]

The Kirigami branch has been merged into master. The old GUI has been removed (-12k line of code and -53k worth of assets and code) and Ring-KDE is now a pure QML/Kirigami application beside the configuration dialog. I will build the appimage tomorrow.

The ring-lrc fork as also been renamed libringqt as upstream drops support for Qt and the project are officially diverging. This resolve the patch issue and clean the way for libringqt to go back in KDE once its API is cleaned from the additions made to satisfy non-Qt uses (and full Qt API guideline support is restored).

Alpha1 last (and hardest) goal is finally met. A video will soon follow to showcase the newly ported features such as multi-participants management and video conferences. Previously, those features required the old UX. This is no longer the case, every mandatory operation are now exposed in the QtQuick/Kirigami user interface.

[star-buck]

That sounds like awesome progress forward.

Do we still share the underlying stuff with ring, so only the GUI diverges?

[Elv13]

Do we still share the underlying stuff with ring, so only the GUI diverges?

Basically, yes. The GNU Ring project has many layers:

• Libring: The library that implements the distributed network protocol itself. This is used by all clients, including Ring-KDE and is still 100% shared.
• The ring daemon: Optional component to use GNU Ring over DBus or RESTful. It's useful because both process can be hardened separately. Ring-KDE fully supports the Ring daemon. The appimage does not use the ring daemon but rather uses libring directly (see all the GitHub conversions as to why this step was unavoidable).
• Ring-LRC: A library I originally wrote and then heavily extended by another member of the original Ring team. We both left Savoir-faire Linux since then and maintainership was passed on to a new team. The library does 3 things:
  • Implement a client side object oriented API for the various ways to access Ring (via libring or DBus or RESTful). This portion will be kept by the new maintainers but they will drop Qt support in favor of raw C++ to reduce the number of dependencies of the whole GNU Ring project.
  • Implements support for contacts and the concept of a "person". The libring only talks in term of network addresses, hardware and URIs. It makes it unsuitable for developing Skype like (social) clients. Upstream is undecided as to what to do going forward with this. For now it is kept, but will probably be replaced or moved into the daemon at some point.
  • Provides full Qt and QML bindings: Upstream EOLed the Qt based Windows client in favor of a UWP (Windows 10 GUI toolkit) client. They will drop support for Qt and QML.

Obviously Ring-KDE is a QML application and requires the QML bindings. Therefor our goals are diverging and a fork has to happen. I just talked face to face with the new maintainer literally a few hours ago around a beer. I mean, we both agree about this, there is no flame war or drama of any kind. For them, Qt support is problematic because the native UWP, Cocoa/macOS, iOS, Android and Gnome clients have to keep elaborate workarounds to be built on top of a Qt library (variable type conversions, Qt model/view emulation and so on). They are working on reducing the number of dependencies (@shadeslayer << enjoy_the_news) and Qt is a prime target for them to get rid of. Plus, they don't like having to review the volume of patches I was sending before the fork. They have zero automated tests and had to try manually to discover the impact in each clients using Ring-LRC (win32, macOS, Gnome) every time I submitted something. They fired the Q/A guy so the load fell back on the other devs and it was understandably unsustainable.

Good faith effort was made on both side until June to prevent this, but it clearly wasn't in either party interest to keep maintaining the Qt bindings upstream while only having a Qt (Ring-KDE) client developed by a third party. It isn't news, but is now fully official and acknowledged on both side (it started to diverge in July).

TL;DR: Ring-KDE still uses the same Ring protocol implantation as every other clients. All that changed was that the Qt bindings and some code associated with them fell back to me (the code author and main contributor). It's a good thing for both us and Savoir-faire Linux.

[TheAssassin]

@Elv13 is there a pre-release to test already available somewhere?

[Elv13]

The new pre-release: https://github.com/ring-project/ring/releases/tag/alpah1

Last week log

Always 99% done until I found another problem ;), so unusual in engineering!

• The CentOS update broke the CI cloud stack, thanks Murphy's law [fixed]
• The toolchain updates (general base system updates) made the appimage crash [fixed]
• The Kirigami fork I used was too old, I rewrote the patches on top of master and submitted them to Marco. The old patches were not suitable to be upstreamed anyway, so it had to be done at some point. [fixed]
• The official release of qqc2-desktop-style style was ported to be a genuine Qt plugin, the patches are submitted too [fixed]
• The fusion style QTabBar was not working, Marco and me fixed that [fixed]
• The appimage (and normal executable too) SIGILL on newer Ubuntu release due to a bug in the CryptoC++ library. It's an Ubuntu feature, not a bug, the hardcoded assembly used to detect the CPU is plain wrong. I prefer a SIGILL to a security flaw. I merged some upstream patches to get rid of CryptoC++ and replace it with another crypto lib. It's not part of the stable release, but is now in GNU Ring git-master. [fixed]
• The color scheme is imported. If none is found, Breeze dark is shipped with the appimage, but it uses the system one when available. [fixed]
• KF5::Config apparently fails to properly load QColor when optimizations are enabled. [fixed]
• The ring core library regressed with a bunch of new undefined references [fixed]
• I turned off the color emijo for this alpha. The Google Noto emoji font has a strange bug where numbers (1,2,3,4...) are colored white. For users of light theme, it ends up white on white. Fontforge crash when working with that font so I will need to find a new one or another tool capable of fixing the font. [todo]
• There was a nasty bugs in KF5::ConfigGui that only appeared in the near final build where the whole screen was painted black on black. This was due to undefined C++ behavior during static initialization (reported as BUG 387820 and mitigated on my side using yet more ugly patches). [fixed]
• I got a variant of https://bugreports.qt.io/browse/QTBUG-56351 when updating XCB. I rebuilt the toolchain with Qt 5.9.3 to get the bugfix. I had to fix a bunch of "regressions" due to improvement in Qt itself. I am not complaining, they will make maintaining this toolchain easier. [fixed]
• Spent a couple days testing the appimage on clear installs and fix whatever was found, which was quite a lot (due to the newly rewritten call code) [fixed]
• I did some tests with Eike and Bshan and fixed more bugs [in progress]

About the appimage

18736kB in size, -8MB from Alpha0, -166MB since the first AppImage! I made smaller ones but I prefer the ones that don't crash after 10 minutes ;). It enables 80% of the optimizations but not system wide LTO. As bugs such as https://bugs.kde.org/show_bug.cgi?id=387820 shows, doing so triggers changes in the code bahavior that have never been seen by the code author. They are bugs, but ones that only happen with LTO, so I need to submit more bugs reports to them and it's not a priority. LTO is enabled for everything that works well with it and is otherwise disabled. Beside that, 3mb comes from removing useless assets from the Emoji font and when I removed the old Ring-KDE QtWidgets code. 500kb come from removing the boost and cryptoc++ dependencies.

Anyway, there isn't much difference between 15MB anf 19MB. I think the static Ring-KDE AppImage SDK is now in great shape and the work done to create these tiny packages will be enjoyed by many projects now that someone took the time to test and catalogs all bugs/issues with static KF5 based apps.

All startup performance gains are cancelled by the lack of optimizations in the new TreeView code. I will enable the optimizations once they are stable enough. With those optimizations, it starts faster and the bottleneck is the number of thread the libring initialize and synchronize at startup.

Tested on

• Neon (latest)
• Ubuntu 17.04
• Gentoo

I also tested on Haswell and Sandy Bridge CPUs.

Changes since Alpha 0

The appimage works in all distributions.

After playing with the idea of using musl libc for a little while, I concluded that @TheAssassin is right and that it's more trouble than it's worth. The current image is built on a base system built with glibc 2.15 but fully updated. I moved the Docker image from Ubuntu to Gentoo in order to have the ability to lock the glibc version.

The appimage has a theme.

Marco Martin qqc2-desktop-style was ported to the Qt plugin system and added support for the Fusion style. Breeze isn't available as a stand alone theme yet so it's more trouble than it's worth unless told otherwise.

The peers timeline now has a nicer style

The design work of Uri is making this core feature pretty.

The address book is being rewritten in QML

It was blocking the "get rid of the old GUI" milestone so a basic port was made. Uri submitted a new design, but I have yet to implement it. For now it's barely working, but it's good enough for an alpha.

The dialpad, call manager and conference support is back

As requested in Berlin, I added this to Alpha1. It allowed me to get rid of the old interface. So far the following features are enabled:

• Display all calls
• A dialpad to send DTMF (call menu codes) to calls
• A toolbar to hang up and put the call on hold
• A button to add new calls
• Auto-completion of phone numbers
• A button to create and detach conferences

CLICK FOR VIDEO

What's missing:

• Clear indicators of the call state
• Clear visual clues of changes to the list
• Drag and drop is working 1% of the time (no idea why yet)
• Multiple conferences at once (nobody do that anyway)
• Attended transfer (a callcenter feature, you don't care about them)

(backend) New QtQuick views

To implement Uri vision and solve some unavoidable limitations, I spent some time writing new QtQuick model/views. At some point I will upstream them somewhere, but for now it's still stabilizing. Performance is great when optimizations are enabled, but for now I prefer to validate the full view after each changes. This has an O(N^2) complexity and is very slow. To do that it has to keep the full model in memory instead of a sliding window of what's visible, making things much worst. However it did address the limitations it was designed to fix, so it was worth the trouble and delays.

Shortcuts and notifications

I ported some KDE frameworks designed for QtWidgets applications to support Kirigami ones. It "works" on some systems but for unknown reasons not on Ubuntu 17.04 with Unity. I am investigating what's going on. It's wierd.

Manu small details left and right

A metric tons of papercuts have been addressed.

Known issues

• For some reasons the color scheme and actions don't work in unity. The menu elements are empty and clicking on them don't work.
• Video crash on Bshan computer, there's no additional info so far

What's next

I propose publishing Alpha2 Friday or Monday with:

• The new Contact editor GUI by Uri Herrata
• The Plasma mobile version for the Nexux 5X

They are both mostly implemented, but in branches as Alpha1 is already very late and the priority.

A couple days after Alpha2, I would publish Beta1 quickly followed by 3.0.0 before the end of the year as promised.