Any plans to support anything other than RPi?

[asriel-danctnix]

We're interested of packaging this to Alpine Linux (or postmarketOS), however these are the problem that hold us back:

• This shell is using connman, while postmarketOS uses NetworkManager, this means that if we don't use connman, then we can't connect to AP.
• Screen dimensions are hard-coded (800x1280), this means that it'll only works on that specific display, this also does not only affect us, but also to people who uses a different LCD type.
• Custom MCU is used to read battery information.
• raspi-gpio is used to read power button state, I'm pretty sure there are other way of handling this, like elogind, or hook that specific event.
• The terminal that you use (yat) is unmaintained, and currently only targets Qt 5.10, we use Qt 5.12 on Alpine Linux.

Any plans on support anything other than Raspbian and your current Raspberry Pi setup? This shell would look good to be used on tablet computers like Pinetab and many more.

• postmarketOS issue: https://gitlab.com/postmarketOS/pmaports/issues/443

CC: @dreemurrs-embedded @PureTryOut @DolphinChips

[penk]

Hi @asriel-danctnix, thanks for the feedback, it would be cool if we can make CutiePi shell a more general offering.

• For screen resolution and default apps, this is an easy one, could be a setting file loading at runtime. Also you might be interested in the Wayland branch, which I believe is more future proof?

• For hardware key events and battery reading, how is this done in Alpine or postmarketOS? Would love to adapt those.

• Network manager could be tricky, do you guys have KDE/networkmanager-qt package in the repo? It pulls lots of KDE framework bits which I don't like.

[DolphinChips]

For screen resolution and default apps, this is an easy one, could be a setting file loading at runtime. Also you might be interested in the Wayland branch, which I believe is more future proof?

We can set screen resolution with environment variables, but shell still should handle placing all UI elements so they would fit on screen.

Network manager could be tricky, do you guys have KDE/networkmanager-qt package in the repo? It pulls lots of KDE framework bits which I don't like.

Yes. we do (https://pkgs.alpinelinux.org/package/edge/community/x86_64/networkmanager-qt), and it doesn't seen to pull any KDE dependencies.

[penk]

@DolphinChips Thanks for the info, that looks good.

I'll check if we can reuse networkmanager-qt on Raspbian, if it's feasible then I'll make a PR to get rid of ConnMan dependency.

[Danct12]

Network manager could be tricky, do you guys have KDE/networkmanager-qt package in the repo? It pulls lots of KDE framework bits which I don't like.

You may also not need that, I believe you can use dbus + policykit to control NetworkManager, use it to connect to Wi-Fi.

battery reading

Most systems uses upowerd to read battery status, so you should adapt that:

pine64-pinephone:~$ upower -i /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         yes
  updated:              Tue Feb 18 15:09:32 2020 (20 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             yes
    state:               discharging
    warning-level:       none
    energy:              0 Wh
    energy-full:         0 Wh
    energy-rate:         0 W
    percentage:          99%
    icon-name:          'battery-full-symbolic'

pine64-pinephone:~$ 

[penk]

@Danct12 manually control NM is painful, I'll try to get (at least part of) plasma-nm working.

[PureTryOut]

Well don't bother with plasma-nm if you're afraid of dependencies. You just need networkmanager-qt really for Qt bindings.

[MightyM17]

Any new updates on this? Would love to get CutiePi Shell on my Tab :smile:

[fancsali]

Well, just bumped into this, and I'd be chuffed to get this working on my old Chromebook under pmOS...

... so +1! :wink:

Can this be chopped up and addressed one issue at a time @asriel-danctnix & @penk? It's more likely that people can chip in.