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

  • DONE: Learn more about development for Android and development of UIs with Qt Quick
  • DONE: Create an experimental app reusing as much existing Syncthing Tray code as possible
  • DONE: 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)
  • DONE: Update the Syncthing Tray website, documentation
  • Extend the app so it has at least a start page and an import that can cope with an export of the other app
  • Update forum thread
  • Upload an experimental build on GitHub
  • 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

Looking for hackers with the skills:

qt quick android syncthing tray

This project is part of:

Hack Week 24

Activity

  • about 1 month ago: frantisek.simorda liked this project.
  • about 1 month ago: mkittler started this project.
  • about 2 months ago: mkittler added keyword "tray" to this project.
  • about 2 months ago: mkittler added keyword "syncthing" to this project.
  • about 2 months ago: mkittler added keyword "android" to this project.
  • about 2 months ago: mkittler added keyword "quick" to this project.
  • about 2 months ago: mkittler added keyword "qt" to this project.
  • about 2 months ago: mkittler removed keyword qtquicksyncthingtrayandroid from this project.
  • about 2 months ago: mkittler added keyword "qtquicksyncthingtrayandroid" to this project.
  • about 2 months ago: mkittler originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    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.

    See section "Result" at the bottom for the current status after the hack week.

    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


    Sipario, less mobile phone, more social interactions by baldarn

    Mobile phone usage is addictive. There are adults addicted, but a huge problem is kids addiction We must do something to help avoid problems in this context.

    The solution

    Sipario, an app and community aggregator in order to help with smartphone addiction.

    Description

    The more you use Sipario, the more points you earn. If you use the smartphone, you will lose your points

    Business model

    How is this sustainable?

    I personally don't care, but sutainability of the business is key to possible investments.

    Sipario will allow commercial entities to join the network. The idea is to give commercial activities (eg: restourants, cinemas, theathers, ....) the ability to certify that users are not using the smartphones during the permanence in the place. this will allow then commercial activities to give coupons to users, in order to promote a good behavior and retain the customer

    Tech challenge

    if resources allows it, i would like to create an algorithm that leverage bluetooth for certify people proximity presence in order to avoid attacks from points rouge in the context of the app

    Goals

    Deliver:

    • android app
    • IOs app (some apple developers must join in order to do this)
    • backoffice app
    • BLE algorithm to certify nearby presence

    Resources

    https://en.wikipedia.org/wiki/Problematicsmartphoneuse

    https://pattidigitali.it/

    https://www.forbes.com/sites/garystern/2019/04/17/the-new-york-city-restaurant-that-prohibits-cell-phone-use-facing-backlash-or-cheers/

    Similar app

    https://play.google.com/store/apps/details?id=com.ascent&hl=en

    https://www.forestapp.cc/

    Website

    https://sipario.org


    Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino

    drawing

    Description

    A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.

    The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.

    On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).

    I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.

    Goals

    • Learn about Rust and micro-controllers (ESP32-C3)
    • Learn about mobile applications (Android and Kotlin)

    Resources