182
« on: January 18, 2018, 09:48:28 am »
I'm not inclined to revisit the building options, its working now. 9mins for a build of data and 13mins for a build of calendar. (the calendar deps don't need building very often but they are qtpim 55min, eds 15min).
As for other folk wanting the help, I wouldn't push people but there is the full range of things they can do if they feel so inclined:
1. Review the apps listed on the wiki, add pages for ones that don't have pages yet along with links to apps from their favourite other open source platforms detailing the features they particularly like and why we should use that as a base of a new app or to branch and patch that for use on gemini. Should especially give links to the upstream source code repository's if they know them, but fine to still list things if they don't.
2. Test out the current apps, easier once we have devices but the amd64 builds can be tested on a Debian9 virtualbox, which is how I'm coding them.
3. Review the translations, and translate for more languages, data has translations for the languages in the planet gemini dropdown on one of their forms, I figured that would cover the majority of users - they are just google translate output so likely to have some possibly 'interesting' word choices.
4. Folk keen on design/UX can review the apps with those kind of thoughts in mind.
5. Patches welcome for current apps (coders), bugs can be raised on github (non-coders). The interesting thing about say the calendar app is that as its mostly written in QML+Javascript you can just sudo edit the files after you've installed it to try out smaller fixes.
6. Pick an app that is so far not adopted and possibly after some discussion of the best direction to take hack away at it, once you've something you think can at least score say 50% on a usability metric I'll add it to the jenkins builds so we can get more folk testing it.
So as you can see there is plenty for any level of Linux user/developer to get involved with. If it turns out there is interest from more than just myself to stay full time on the Linux side and such folk pick this project as worthy of their time then we can have the discussions around picking a desktop environment/window manager and fixing up a nice set of shortcuts etc. Then possibly focusing efforts on a particular UI toolkit etc. Though I see no problem with having multiple app options for each type of app.
A note on why I'm happy to stick with Debian 9 - it gives us a solid well tested base for adding apps and had just about every WM/DM built for it. With the addition of stretch-backports you can get the latest apps generally a couple of months old, rather than over a year which is a common compliant from those who don't add the backports. The debian developers tend to patch upstream apps to avoid duplicating dependencies. So for example if you install telegram-desktop from the upstream developer you get a statically linked build of about twice the size of the debian one that is dynamically linked. The upstream developer is not interested in having to support the myriad of linux distros with all the different versions of the dependencies, so for simplicity they bundle everything in together. This particular example might be moot as the upstream developer dosn't do arm builds, debian do, and keyboard functionality is not the best so its a possible target for GKA branching and patching.