Like “privacy” and “security” the word “convergence” has become a popular term these days. When words like these become popular, companies tend to redefine them to match whatever they happen to sell. For instance when Google says they protect your privacy they mean “from everyone but us.” When Apple says they are secure, they mean “as long as you give us full trust and total control.”
When most people think of the promise of convergence they think of what I’ll refer to as “real convergence”the idea of a single, portable computer that has your data and applications and that can be a desktop computer, a laptop or a pocket computer. To summarize: real convergence means taking your desktop computer with you in your pocket wherever you go. Fake convergence is the opposite: stretching a phone to fit on a larger screen.
You can read the rest of my thoughts on convergence in the full post:
Somewhere in the back of my head I remember a related discussion about usb c alt mode. Is this resolved? Is it possible to use an HDMI monitor connected to the L5 usb c ?
I’m hoping this will be resolved before my Evergreen arrives
I know I know but this is not the forum for the pinephone
Why not just showing us. …i/need some entertainment.
I just get suspicious when I see a copy of a piece more than a year old that’s very … March 2019 with the identen screencasts!
I follow the events in the forum almost daily and find this copy just a bit clumsy!
After awhile I stopped using the VM (it would never be usable in phone mode)
LinuxDeploy with XServer XSDL actually works pretty well for me today when I plug my keyboard and mouse into my phone. It is the only open source (https://github.com/pelya/xserver-xsdl) solution which, although often extremely glitchy to launch, works very seamlessly with a keyboard and mouse where my in-app mouse cursor actually follows my phone’s mouse cursor once it is launched and configured correctly. I have used it to edit images with GIMP and program an Arduino entirely from my phone. I expect that doing the same on a Librem 5 will be much more seamless, though, without as many glitches in launch, no matter what happens. Even in the worst case scenario where no convergence at all exists in Phosh, I could just launch another Wayland compositor in another TTY for a full desktop environment no problem.
I believe I had already tested desktop Firefox before, but for some reason seeing it this time (possibly for a second time), makes me the most excited I have been for anything in technology in a very long time, because it’s not just desktop Firefox, but smooth desktop Firefox, that even manages to run desktop YouTube more smoothly than I’m used too compared to my existing phone (a OnePlus One with a processor that I remember being just a tiny bit, insignificantly faster than the i.MX8M) on Waterfox. I guess Waterfox is just often very slow, though, especially with all the tabs I tend to have open, but… I don’t know, I guess I’m just seeing everything in a new light today. This isn’t as much of a phone with all the phone apps I’m used to, as it is a desktop in a phone form factor with all the desktop apps I’m used to. It is amazing to see YouTube function at a level of smoothness that competes with my desktop. Was there a lot of optimisation work for that? It seems like something must be optimised well. Maybe it’s just the lack of hundreds of tabs though, I don’t know.
This post is what made me finally register im definatly following to see where this goes! Having only a phone and a tablet has always been my “minimalist dream”
I used previous videos because I just needed something to illustrate the point I was trying to get across for people who aren’t familiar with convergence and I think showing a full-size browser turn into a “mobile browser” when you drag the corner (and the same with fractal) does a good job of illustrating what I’m talking about.
We have plenty of Dogwood videos planned and are making a lot of progress on USB-C video out on it as well, but we briefly paused it the last few weeks as the team has been focused on final extensive testing for Dogwood so we can ship it out.
I definitely agree that Purism has the right strategy in terms of convergence. Microsoft and early versions of Ubuntu Touch tried to do convergence by maintaining different software for the desktop and mobile, and Samsung DeX tried that for a while with an Ubuntu desktop. Android and later versions of Ubuntu Touch tried to do convergence by making the mobile environment and apps behave like a desktop.
Maintaining two separate sets of software for the desktop and mobile isn’t easy to maintain and is a lot of extra work. Using mobile apps as desktop applications results in poor software. Simplifying and adapting a desktop interface to work in mobile is better than taking a simplified mobile interface and blowing it up in size for the desktop.
Purism really has hit on the best strategy for how to do convergence by taking desktop software and adapting to work in mobile, because you get to use good software on the desktop. It is also the most maintainable strategy, because most of the desktop applications like GNOME Contacts already have maintainers, so it is much less work over the long term than creating new mobile apps. It also gives a path for thousands of GTK desktop application to be ported to mobile, which strengthens the GTK/GNOME ecosystem as a whole, since you get more total users and developers for existing applications.
I often wondered why those company’s tried to maintain two different platforms… i always thought it made more sense to leave it to the window manager how to paint stuff on the screen.
If i create a program, i should not have to wory about its looks, just its function. I’ll leave the looks up to the window manager. Wether it be a window manager on a desktop class device or on a mobile class device.
At least, thats how i think it should be… but im just a low level ruby programmer
The problem is that the window manager can only do so much. It’s useful to think of a window manager like a web browser in this context. Fifteen years ago if someone developed a website they would assume a screen resolution of 1024x768. Then as people got higher resolution displays designers discovered their websites looked bad (their single column, left-justified site left a TON of whitespace on the right side of the screen when a high-res display maximized the web browser). At the time web designers would “fix” this by centering their single column so you had a ton of whitespace on both sides!
Then people started browsing the web on their phone and discovered that very few designers built their sites assuming a small screen–web pages assumed 1024x768 which meant you had to constantly scroll left to right as images and text would roll off the side of your web browser’s small window. Or worse, it would all technically fit, but everything was so small it was hard to read. Eventually “responsive design” took over and web designers started designing sites that would adapt to a small display as well as a high resolution one.
The situation is the same right now with PureOS and Linux desktop applications in general, except Linux desktop UI is a decade behind website design. Phosh (our equivalent of a window manager) can only do so much if an application developer designs their app so that it can’t resize smaller than 1024x768. You can test this on any Linux desktop: resize the screen to 640x480 or even 800x600 and see how many apps work well! While we can scale the screen, if you scale too much you get buttons that are too small to hit with your finger.
This is why libhandy is so important–it makes it easy for a GTK app to adapt its widgets to a small screen or a large screen. In some cases this means turning a 3-column window into a single column, where you can switch columns by swiping left and right. In other cases it means converting the Alt menu along the top into a “Hamburger” button. Of course libhandy isn’t a hard requirement–you can implement adaptive design yourself just by making sure you can resize your application’s window to a small size and confirming things still work well.
I would need an area for the chat text to go, an area for the channelusers to be displayed, and an area for my ow text to enter. I could easily leave it to the widow manager where those are placed, no? And then the window manager could decide to place the userlist in an overlay because its running in mobile mode. Or as a full textfield because its running in desktop mode. I could tell what options the context should contain, but leave the looks to be handled by the window manager?
Ofcourse… all i’m saying could be bullshit, im not a programmer ive only recently started to get interested in Ruby (on Rails) so most stuff is still hocus-pocus to me
The libraries developers use to design GUI applications is the limiting factor here. GTK-based applications default where widgets are generally “free flowing” where possible. You as the designer, however, can hard-code buttons to always be side-by-side no matter what, but it’s discouraged. Applications that allow GTK to flow the widgets generally do better on the Librem 5, but sometimes widgets need more space than they are given, when you shrink a window that small.
Gpodder is a good example. It’s a Python/GTK application and it almost worked out of the box on the Librem 5 screen, however due to a few situations where columns were coded to be side-by-side (based on the assumption of a landscape mode desktop monitor) when moved to a smaller resolution portrait mode screen they needed more space. I was able to patch this myself with only a few minor changes to two files that dictated whether the columns were side-by-side or top to bottom.
You can check out my patches here and even if you aren’t a GTK developer it should be pretty self-explanatory what I changed by looking at the patches:
Note however that this didn’t make gpodder adaptive! If I were to connect the Librem 5 to a monitor, gpodder would still arrange these widgets in the same way. We need something like libhandy (or someone’s homegrown version of the same thing) to tell the app to detect what size it is, and change the orientation of the widgets accordingly.
My understanding the last time I looked at QT is that it takes more of a hard-coded approach where the designer describes exactly where each widget (button/text input box/etc) would go. In that case it would be a bit more challenging to leave it up to QT or the window manager.
The Nielsen Norman Group has an excellent series of free articles on graphical user interface design. Recommended reading for novices and experts alike. www.nngroup.com
I’ll follow up with a longer post later.
Or maybe the world needs a new widow manager, one that is to Linux what Bootstrap is to webdesign that way i could be busy with looks, instead of layout or something like that… if that makes any sense?
I think I’m missing something. Aren’t there still two separate platforms? 1 being X86_64 the other being ARM?
There are many applications I’ve encountered that only exist, on Linux, in the x86_64 space and I don’t see these working with convergence any better than x86_64 windows applications worked on windows phone (they had to be ported).
That’s only a problem with distributions that allow proprietary software into the distribution. It’s a problem then because the distribution doesn’t have the source code for the non-free software, so it’s up to the maintainer of that proprietary software to recompile it for non-X86_64 platforms.
PureOS is 100% free software so we don’t have that problem–we simply take the upstream source code and compile it both for X86_64 and ARM64 (in reality we end up repackaging upstream Debian packages for both architectures for most software, we only have to bother with recompiling software that’s unique to PureOS).
Instruction set architecture (x85_64 vs ARM) is completely independent of graphical user interface design.
By analogy with cars: the GUI is what the driver sees, while the ISA is what the mechanic sees. You can put a different engine into a Porsche, and it will still look like a Porsche, though you might not have exactly the same acceleration and speed.
The look, feel, and design of an app is identical whether it’s compiled for x86_64 or for ARM.
with the GNU/Linux ecosystem you can ALSO have MANY different window-mangers …
you can have a combination of BOTH tilling and non-tilling WMs … with free-software it’s all there waiting to be explored and improved upon …
excited about the possibility of a GNOME for mobile use + one of the other TILING window managers out-there that i haven’t decided upon yet …
it’s not exactly minimalist to have a an external keyboard with a mouse PLUS a docking-station on your desk when in desktop mode but that might be alleviated by using wireless connected tech (which i won’t regularly do)
im definatly following to see where this goes! Having only a phone and a tablet has always been my “minimalist dream” 