[Librem-5-dev] A few questions about development

Chris Hessing chris at open1x.org
Wed Jan 23 11:52:47 PST 2019


Hi Dorota, and Guido!


On 01/23/2019 09:57 AM, Dorota Czaplejewicz wrote:
> Hi Chris!
>
> On Wed, 23 Jan 2019 09:34:10 -0700
> Chris Hessing via Librem-5-dev <librem-5-dev at lists.community.puri.sm> wrote:
>
>> Hello all,
>>
>>
>> First, let me say that if I am posting this to the wrong list, please
>> let me know which list is the correct one to post to.   (I figured these
>> were development related questions, so they should go on the development
>> list.)
>>
>>
>> I'm working on a TOTP app, primarily for the Librem 5, but one that can
>> also be used on Linux (and eventually possibly Mac, Windows, and maybe
>> even Android).   I have been developing it on Linux, and then building
>> and running it on the emulator to test. During that process, I've come
>> across some issues, and questions.
>>
>>
>> If anyone has answers to any of these questions, please keep in mind
>> that I am developing this app using Qt, which might mean things are a
>> little different from an app developed using GTK.
>>
>> So, on with the questions :
>>
>> 1. Is there any good way to detect that the device the app is running on
>> is a Librem 5? --  I may be off about the intent here, but I suspect
>> that apps running on the Librem are expected to run full screen.  So,
>> being able to detect the device would allow me to put some special
>> Librem 5 code in to run the app fullscreen.
> It shouldn't be needed at all, it's the compositor's job to understand whether applications should be full screened or not. All applications will be full screened with the final default Librem 5 compositor, and we're not planing to introduce non-full-screen mode for anything but dialogs so far.

I've seen that the terminal app fills the screen (except for the header 
and footer).   Is it expected that the compositor is in a state that any 
GUI app should work the same?

I am attempting to use QML with Qt, and I am seeing a window instead of 
the full screen I would expect.    What information can I provide to 
help chase the problem down?   (Or, is it expected that Qt development 
will be widgets based and not QML?   I have not tried a widgets based app.)

>> 2. How are apps expected to terminate when running? --  I ran in to a
>> couple of problems that prompted this question.   First, when I built
>> the Qt app on the emulator and ran it, the title bar was tiny, and there
>> was no "X" button visible, so no obvious way to close the app.   Second,
>> when I added code to show the app full screen, Qt removes the title bar
>> completely, so again, there was no way to close the app.   If apps are
>> expected to be closed using the "X" button, I can change the way it goes
>> full screen to keep the title bar, but that just runs me in to the first
>> issue in this list.
>>
> The answer to this question is related to the previous answer: the compositor is aware of the full screen status, and it will provide a way to close the application. You're seeing a missing X button because the compositor is not final, and I would count this as a bug.

Fair enough.   For now, I added a "Quit" option to the side-bar menu.   
But, I'll remove it as things progress.   What additional information 
can I provide to help figure out the bug?

>
>> 2a. Is it expected that Qt developers will use the KDE Kirigami
>> framework (or some other framework) to make apps look/work properly on
>> the device?
> That depends on how deep we go with the idea of "properly", but in general we want to support any kind of Qt applications. The details on what to use to make it look similar to GNOME apps are still being worked out.

Fair enough.  My current implementation of the app isn't exactly 
beautiful.  I wanted to make it look better, which is why I loaded it on 
the emulator.

I also realize that building a "proper" app is probably a topic with a 
wide variety of opinions.   I mostly included the "properly" in there to 
see if there was a suggested way to do it, that might result in less 
friction.   But, it sounds like that will come in the future.

>> 2b. If a specific framework is expected, can you provide any useful
>> links to examples of how to install it in a dev environment?   (Or, even
>> tell me if a certain Linux distro is a good one to use as it is easy to
>> set up the development environment.   When it comes to development
>> resources, I have a ton of hardware (and the power bill to prove it!),
>> but not a ton of time. ;)
> As you mention later, we're continuously building our documentation here: https://developer.puri.sm/Librem5/Apps/index.html
>
> PureOS is the distro we're focusing on, and we're documenting starting with GTK as the recommended framework. Time is indeed a scarce resource, especially with so many possible frameworks and languages users will want to program with, so if you can contribute your own findings, we're going to be grateful:
>
> https://source.puri.sm/Librem5/developer.puri.sm/

I'm not sure I have much worth contributing so far, but I am willing to 
help out as much as my "free time" will allow.    What is the best way 
to start to contribute?   Is that site similar to github? Should I 
create my own branch and then send in a pull request when I have 
something that I think is worth sharing?

I'll take a look at what you guys have already done with GTK+ and see if 
I can put something similar together for Qt developers.   I'm far from 
an expert on Qt, but I have been using it for many years now.


In re: to Guido:  I set up a Debian VM the other day for development.   
I'll also try to track down a PureOS installer to set up a VM of that.   
I'm guessing that PureOS is what you guys are using, so that will be the 
path of least resistance?

>> 3. According to the developer documentation, apps can be distributed
>> either as flatpak or .deb packages.  The app I am working on will
>> require more components of Qt than what are installed on the emulator by
>> default.   If I package the app as a .deb, will the phone properly
>> handle asking for root permissions to install the extra packages?   Or
>> do I need to use a flatpak?   (I have no experience with either
>> packaging method, so I'd like to avoid learning one and finding out that
>> it won't work.   Right now, I am leaning towards creating a .deb as I
>> suspect there is more information available on how to do it.)
> I would recommend using Flatpak, as this seems to be something we'll be supporting properly. If you want to have an early preview of what software installation will be like, give GNOME Software a try.

Great!  Guido also provided some examples in his response.  I'll take a 
look at those and see what I can come up with.

Is there some place that I should be watching to learn more about the 
status of the "store" app?   So that once it is available I can start to 
make changes to my build process to get things working?


Also, FWIW, I was originally leaning toward a .deb because Flatpak seems 
like it would add a lot of bloat to any downloadable packages.   For 
example, my app needs (so far) a few extra Qt modules that aren't in the 
current emulator package.   I suspect many other apps will be similar.   
It seems kinda silly to package those extra libraries in each app that 
might need them.  Sharing those components is why we have DSOs!  ;)   
(Please don't take that comment the wrong way.  If you guys feel that 
Flatpak is the way to go, then that is what I'll use.   I just tend to 
be a bit anal about how large an app download ends up being!)

>> 4. After sliding up the key guard and entering the PIN, you are
>> presented with (on the emulator) a screen with a title bar, and some
>> buttons in the footer, but is otherwise blank.   Is the idea that apps
>> will show up on that screen?
> Apps will present themselves similar to how they already do, try running the terminal to see.

Yeah.  I saw how the terminal was presented, and figured that was 
probably the end goal.   I was just a little surprised when my tests 
with Qt ended up wildly different.

>> 5. When installing an app, what should the app be doing to have its icon
>> show up in the appropriate place?
> I take it that you mean the launcher. I think it needs a correct .desktop file.

Does the .desktop file need to be installed in any specific location?  
Or is it the same as .desktop files under the Gnome desktop?   And, will 
it be the same format that the Gnome desktop uses?

>> Thanks!
> Hope that helps, but don't hesitate to ask more questions!
>
> Cheers,
> Dorota


Will do!

Thanks again for the prompt answers!



More information about the Librem-5-dev mailing list