Hi Matthias! Exciting news indeed! I personally would love to see our platform on a phone!
Hi!
2017-09-03 17:27 GMT+02:00 Alberto Ruiz <aruiz gnome org>:
> [...]
>> Did anyone try to use GNOME on a smaller, phone-sized display already?
>
> Well, yes, Nokia did Maemo 10+ years ago and it was all Gtk+ based:
> https://en.wikipedia.org/wiki/Maemo
>
> The TL;DR of that story is... messy. They created a set of separate
> widgets, hildon, that didn't have a good story as to how they would
> make it upstream. Maemo's shell was stylus and keyboard driven and
> once the iPhone appeared everything changed...
>
> One thing they got right was making a product widely available to
> GNOME developers (N770, N800, N900...).
>
>> Is there interest in the community in actually making a "GNOME Mobile"
>> a reality (of course, Purism would help with that)?
>
> I think many of us would love to see that happening. But my take on it
> is that it will only happen if people step up to do the work.
Yeah, I remember that good old times :-) Reviving Maemo is not really
an option, fortunately ;-) GNOME is much different now, and phones are
as well.
Let's leave Hildon where it belongs, please.
Additionally, I would try to push for gtk4 adoption and improvements; the GTK team wants more drivers to deliver a better performance profile and features, whereas we can't touch gtk3 any more, in terms of API.
Building a mobile extension toolkit on top of GTK is a great way to ensure you're never going to ship anything remotely useful; working upstream so that the GLES rendering pipeline for GTK is efficient and performant gives a much better ROI in the medium to long term, and does not split the community and engineering effort. That much we learned during the Nokia days.
>> I am looking forward to your replies!
>
> I am not sure what you are trying to achieve with this email. Are you
> just trying to assess if the community would welcome a GNOME Mobile
> initiative? Because the response depends a lot on the specifics of how
> you want to do things.
Yes, pretty much that was the intent. At the moment, we do not know
yet how many resources we will have (if any at all, depending on the
crowdfunding) to make the phone and GNOME Mobile a reality, but
figuring out what would need to be done and how any such effort would
be received by the community is very valuable to know in advance.
One possible idea is to create a hackfest and get some of the consultancy companies to help sponsor it and sell it as a way to open a new market for them. After all, a successful phone means a new application market of which they could make money on consulting because they would know and understand the underlying stack.
Absolutely you should come to the Libre Application Summit and work with us to get the right people there as another alternative. Finding and attracting developers is probably a good first step. You might also look at the Tizen stack in terms of toolchain and what not. It already has a number of GNOME/GTK+ libraries already.
Again, leave Tizen where it belongs: on the trash heap of history.
If you want to create a platform, concentrate on the underlying vision, not on the stack diagram. We have had far too many of those littering the side of the road.
There are plenty of infrastructures that can deliver you an OS for a given hardware platform and architecture; whatever you ship to make your main UX should also be the underpinnings of your app development story, to minimise the impedance mismatch between what you have to optimise in your OS and what you have to optimise in your SDK.
> For example: are you going to be setting up a wikipage in
> wiki.gnome.org or are you going to have an in-house
> documentation/development process?
> Are you going to start writing
> mobile friendly widgets/apps in git(lab).gnome.org or are you going to
> host/bugtrack things yourselves? Are you going to start writing GNOME
> Shell extensions and patches for a mobile shell and contributing them
> upstream? Are you going to start profiling and improving GNOME Shell's
> performance on slow I/O?
If we do anything, it will be done upstream, as per Purism's vision.
So, developing an inhouse solution based on the GNOME stack wouldn't
be an option for us.
> These are a few ideas on how you might want to procede:
>
> - Communication: start communicating your vision of what a GNOME
> mobile is and document it on wiki.gnome.org and be vocal about it on
> planet.gnome.org as you make progress
> - Design: engage your designers with the design team early to see how
> we can create certain continuity between the desktop and the touch
> GNOME experiences
> - Planning: I would try to assess what are the specific technical
> challenges of the platform as of now, and start sketching a plan on
> how to overcome them
> - Iterate: I'd start trying to write a simple app (say, the messaging
> app) on a standard GNOME Shell session, look at the shortcomings, list
> them and have your developers start proposing patches and/or
> strategies to overcome those (at first, Gtk+ and GNOME Shell I'd say,
> but in the future flathub and GNOME Builder are other projects that
> you might want to engage wrt the developer experience aspect of
> things)
This is exactly the reply I was looking forward to, thank you! :-)
One possible problem is building GNOME under ARM. I don't know of any
GNOME desktop running on ARM processors. It might not be a big deal,
but who knows what problems occur? I would start with that first.
Of course you know of a GNOME desktop on ARM: EndlessOS supports ARM and ships on it. 😁
The problem is that GL drivers do not come for free or easy; even if you target free software drivers shipped inside Mesa, finding products that can be delivered at scale, and at a decent price point, is not trivial.
In other words: it's easy to get your hands on an Odroid SoC that can easily run GNOME, but you cannot turn it into a product that you can ship to customers.
This is massive obstacle to overcome for any OSV and ODM. Incidentally, if you're already in talks with an ODM that's promising you a SoC with generic Linux (non Android) drivers that are maintained, working, and free-as-in-upstream, be prepared to face disappointment. Vendors often have none of the interests (or the technical skills) to tell you the truth.
Ciao,
Emmanuele.
