Update: Ruqola ('zypper in ruqola') is now in Tumbleweed and Leap 15.2!
For Hack Week 19 (Feb 2020) main goal is to test, polish packaging, potentially do fixes and select a snapshot to submit to openSUSE Tumbleweed. Upstream made one release but it was not optimal, development pace has sped up a lot lately and the client has become more stable and usable.
See below for OBS repository from which one can install Ruqola on Tumbleweed (note: due to newest Qt version requirements one cannot install it on Leap 15)
Hack Week 18 (2019)
Since we are moving to Rocket.Chat as our default chat solution it would be nice to have a more resource friendly application than the heavy Electron based one. There is a Qt based client called Ruqola for Rocket.Chat, while having basic functionality its still far from useable.
This project aims to get Ruqola in a shape where it's good enough for basic daily usage, once that state is reached we can extend to more advanced topics (like video chat).
Testing Ruqola with Hack Week work integrated
Install Ruqola from OBS on Tumbleweed:
sudo zypper ar https://download.opensuse.org/repositories/home:/tjyrinki_suse:/ruqola/openSUSE_Tumbleweed/ ruqola
sudo zypper in ruqola
The patches discussed on this page have been integrated in the packages.
Development
The code can be found here:
- https://cgit.kde.org/ruqola.git
- https://github.com/KDE/ruqola (mirror)
Build dependencies on Tumbleweed:
sudo zypper in libqt5-qtwebsockets-devel libqt5-qtnetworkauth-devel kirigami2-devel kwidgetsaddons-devel ki18n-devel kcrash-devel kcoreaddons-devel extra-cmake-modules libqt5-qtdeclarative-devel kdoctools-dev syntax-highlighting-devel libQt5DBus-devel knotifications-devel qtkeychain-qt5-devel kitemviews-devel libqt5-qtquickcontrols
Build environment on Tumbleweed:
mkdir build
cd build
cmake ..
make && ./bin/ruqola
Unit tests with error logging:
make && CTEST_OUTPUT_ON_FAILURE=1 make test
Progress
Day 1
- Research of code and build requirements
Day 2
- Packaging for SUSE
- Successful reverse engineering of 2FA/ totp login
Day 3
- Support TOTP login with 2FA-enabled accounts bug 409212 review D22111
- Prefer logging in via the saved auth token bug 409213 review D22112
Day 4
- Improval of 2FA UI and test coverage
- Unable to configure accounts
- Notifications don't disappear
- Unable scroll down members list
Day 5
- Another round of updating the patches
- Handling for invalid 2FA codes
- Cache folder with account name ends up in home
- Updated OBS packages to latest upstream changes and new patch versions from Phabricator
- TODO
Future
August
- Submit the package to Factory after all patches have been merged to upstream and upstream made a release.
Looking for hackers with the skills:
This project is part of:
Hack Week 18 Hack Week 19
Activity
Comments
-
over 5 years ago by martinsmac | Reply
Hey, I create one bug about pop-up messages: https://bugs.kde.org/show_bug.cgi?id=409245
-
over 5 years ago by martinsmac | Reply
Bug about "Configure account" : https://bugs.kde.org/show_bug.cgi?id=409246
-
over 5 years ago by martinsmac | Reply
Bug about "group list" icon on room: https://bugs.kde.org/show_bug.cgi?id=409247
-
over 5 years ago by tjyrinki_suse | Reply
Packages for Tumbleweed available at https://build.opensuse.org/project/show/home:tjyrinki_suse:ruqola - they include a snapshot of upstream added with Christian's patches for 2FA (to be merged to upstream later, PRs open).
I'll only submit to Factory likely in August after the first upstream release is made and 2FA patches merged to at least trunk.
-
over 5 years ago by tjyrinki_suse | Reply
Ok trying again the link ruqola packages at OBS
You can install it with these zypper commands.
-
over 5 years ago by thomas-schraitle | Reply
Congratulations, great project! Could someone turn on the build for Leap 15.0? It's still supported. ;-)
-
over 5 years ago by tjyrinki_suse | Reply
@thomas-schraitle Hi (sorry, I was on vacation) .. unfortunately Ruqola requires Qt 5.12.0 and Kirigami2, so some very recent stuff, so compiling at least against basic 15.0 (or 15.1) does not work. If there's a Qt 15.0/15.1 OBS repository with those, then I could maybe compile against it
Similar Projects
Create an Android app for Syncthing as part of the Syncthing Tray project by mkittler
Description
There's already an app but code/features already in Syncthing Tray could be reused to create a nicer app with additional features like managing ignore patterns more easily. The additional UI code for the app could then in turn be re-used by other parts of Syncthing Tray, e.g. to implement further steps in the wizard as requested by some users. This way one "UI wrapper codebase" could serve GNU/Linux, Windows and Android (and in theory MacOS) at the same time which is kind of neat.
Goals
- Learn more about development for Android and development of UIs with Qt Quick
- Create an experimental app reusing as much existing Syncthing Tray code as possible (already in the works)
- Build Syncthing as a library also for Android and use it in the app (already done but needs further testing and integration with the rest of the app configuration)
- Upload an experimental build on GitHub and make it accessible via the Syncthing Tray website, documentation and forum thread
- Extend the Syncthing API to download single files on demand (instead of having to sync the whole directory or use ignore patterns)
Resources
- Android SDK/NDK and emulator
- Qt Quick
YQPkg - Bringing the Single Package Selection Back to Life by shundhammer
tl;dr
Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.
The Past and the Present
We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.
You can search packages based on name, description, "requires" or "provides" level, and many more things.
The Future
YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.
Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?
For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.
But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.
The Idea
YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.
For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.
For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.
Preparatory Work: Initializing the Package Subsystem
To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?
Yes, it is: That part is already working:
https://github.com/yast/yast-ycp-ui-bindings/pull/71
Go there for a screenshot
That's already halfway there.
The complete Ruby code of this example is here. The real thing will be pure C++ without any YaST dependencies.
The Plan
- DONE: Clone libyui where libyui (high-level), libyui-qt, libyui-qt-pkg live