Chat logs about ZeroPhone/pyLCI
Conversations are in chronological order, with dates shown where they're known
IRC conversation about how pyLCI works
<demon`> hi! I like your zerophone project very much! First of all I have no experience in design and functionality of mobile phones, neither from hardware, nor from software point of view. But I have some python experience and therefore forked pyLCI and digged little through the code. <demon`> My first question is more or less theoretical: Do you plan to use the GSM/baseband component like from the shelve or is it intended to use some open source solution like osmocombb there, too? <CRImier> Hi demon`! Great to have you here =) <CRImier> As for now, I'm using a SIM800 modem - it's a proprietary off-the-shelf baseband, I've pushed some code for working with it in pyLCI repo yesterday. <CRImier> I'll be looking for open solutions, and while OsmocomBB is great, it's not as accessible and cheap, so it's pretty much a stretch goal for the project =) <demon`> CRImier: thanks for your answer! :D What is the concept of the pyLCI code? (I did not understand why all these global references are necessary :-( ) <CRImier> Which global references, exactly? <demon`> CRImier: oh sorry, I did not see your answer. I mean for example those input and output references [...] <CRImier> So, about those i and o globals - it's the easiest way to pass input and output objects to UI elements, which can be used in many different places in a single app. <CRImier> When apps are loaded, init_app is executed from each app and it receives the input and output objects which are then assigned to globals <CRImier> The concept of pyLCI code is simple - it's mostly based on UI elements (Menus, Refreshers, Printers, Dialog boxes, Listboxes etc.) <CRImier> Once UI elements are called ("activated"), they set hooks on certain keys (for example, "LEFT" key almost always exits the UI element), using input object, and print something on the screen, using the output object. <CRImier> pyLCI is largely based on Menus - you select a menu entry, click on it and the associated function executes, and that's how 90% of the workflow goes (in general, that's how many user interfaces work.) <CRImier> For example, you can activate another Menu =) <CRImier> from a menu, that is. Or you could activate your function that'd do something useful. <demon`> [...] Thanks for the explanation! From my point of view I have always a bad feeling when I see global variables (because it's error prone IMHO). <demon`> What I did not really understand: Is this code multithread or is it singlethread? <demon`> Do you plan to put an object oriented application framework around your UI elements to get rid of the global variables? <demon`> And my last question: What is missing and easy to be implemented? (Because as I said, I am absolutely newbie in case of smartphone hardware and software, but have some experience in python) ;-) <demon`> I forked the pyLCI part of the zerophone repo; is there any branch on which should developed? is this the right fork I did? [...] <CRImier> The global variables can be problematic, but 1) the only two globals that really matter are i and o, and you're supposed to know about them when developing an app (and I don't recall ever making a mistake with this, since you're not supposed to have variable names that short anyway, though I see your point and will think of all possible problems ) 2) there isn't really a better way to do this 3) this is the simplest there can be 4) and you don't even <CRImier> have to use "global i, o" anywhere other than init_app function (which is pretty much boilerplate)). In the way they're used now, globals aren't much worse than, say, an imported function (like "from time import sleep"), or a global-level helper function. <demon`> CRImier: OK, yeah I thought so, too. But better to ask first ;-) <CRImier> The code is multithreaded - in fact - it has more threads than necessary =( https://github.com/ZeroPhone/pyLCI/issues/6 However, this issue needs some careful consideration - thread count will be eventualy minimized, but there can be no functionality loss. <CRImier> Most issues are on GitHub: https://github.com/ZeroPhone/pyLCI/issues If you want a simple one to start with, I can give you one =) <demon`> Yeah I would like to contribute to a small simple (and not time critical) task. :-) <CRImier> There's an UX issue that needs to be solved, it's about scrolling in Checkbox UI element. List-like UI elements have this "scrolling" feature, say, a Menu entry text is longer than the screen can show - so when you select that text, it scrolls to the right so that you can eventually read it all. <CRImier> Checkbox UI elements are like Menus, but first character that is shown on the screen is either " " (space) or "*" (asterisk), depending on whether checkbox entry is selected or not. When scrolling, that character also scrolls off the screen - which is an UX issue =( <demon`> Is there any app already implemented showing this Checkbox UI? <CRImier> Yep, for example, apps/media_apps/volume. There should also be a test app in apps/example_apps/ (something something checkbox), it should have the minimal app which has a Checkbox. <CRImier> I'd suggest you check the test app first =) <CRImier> About "Do you plan to put an object oriented application framework around your UI elements?" pyLCI uses tons of objects (also, pretty much everything in Python is an object) - all the UI elements (except Printer, it doesn't need to store state) are implemented as objects, input and output objects are also objects (with fair bit of inheritance), and, in general, it's reasonably object-oriented (statement based on my experience with various <CRImier> Python-based UI and other frameworks) <CRImier> IMO wrapping it in objects even more would probably result in having to write more code than necessary, which is not a good thing to do when developing something =) <demon`> Yeah, I saw that there are lots of objects. I just meant something like (class App: self.input, self.output, createThisAndThatObjectFactory(), ...) such that one can get rid of these global variables. But as you already said, as long as there are only two well-defined variables i and o there shouldn't be any necessity to define such an app class. <demon`> I also don't know how such a framework behave in a multithread environment <demon`> So these are questions only :-) <demon`> Thanks for the nice support, anyway. I will have a look at the test app, and if there are additional questions arising, I will ask you directly in this channel. Further I will open a small feature branch and pull-request from there once the bug is solved. :-) <CRImier> You actually can define such a class and instantiate it in init_app() , it's just that it isn't that necessary for things to work =) I remember working with Pyro two years ago, when I was trying to implement splitting pyLCI core and pyLCI apps. Pyro actually needs all the functions it passes back and forth to be objects - and frankly, it quickly became a pain to work with =( There can also be "too many objects", it appears. <CRImier> I can actually imagine a possible problem with those globals: "for i in range(10):", where i then becomes inaccessible for such function =D
IRC conversation about alternative UI toolkits
<SirCmpwn> I'm interested in UI work, but I'm not interested in basing it off of pyLCI <SirCmpwn> are our interests compatible? <CRImier> SirCmpwn: ...I don't know how to interpret this question =D It's my interest for alternative UI frameworks to appear for ZeroPhone, as well as make sure pyLCI stays separate from the control logic of the phone, so that other UIs can be integrated without having a systemd-like hostage situation ;-P <SirCmpwn> gotcha <CRImier> That being said, I'm also trying to avoid the OpenMoko-like situation, where, as far as I know, for a long time wasn't a single UI that just worked reliably and quickly. Therefore, I'm focusing on an UI that's going to "just work", and let others have all the experimenting fun =) <SirCmpwn> well, I'm working on a GUI toolkit in general <CRImier> What's your language of choice? is Python acceptable, or so-so? <SirCmpwn> whose design is flexible enough to accomodate situations like the screen constraints on the zero phone <SirCmpwn> well, my GUI toolkit is written in C and I intend to write bindings to other languages (including Python, I like Python) <SirCmpwn> but I question the viability of Python as a UI driver for an embedded device, at least with a fancier GUI than what you have going on <CRImier> Provided you have a Pi Zero, I can assemble you a quick "UI development platform" and ship it to you. It's basically a ZeroPhone front board made into a shield, you plug it onto a Pi Zero and get a screen, buttons, WiFi and audio output. <SirCmpwn> that would be cool <SirCmpwn> I don't have a pi zero but I can obtain one <SirCmpwn> https://github.com/SirCmpwn/chopsui fyi <SirCmpwn> I also do work with wayland compositors and it might be cool to make the UI driven by wayland <CRImier> I can ship it next Monday, even. As for "viability" - it works, as of now. It does consume a little bit more of CPU that I'd like it to, but the development speed is amazing, and the features provided allow to do really cool things (compared to what I, with my skills, could do in C). So, that's why Python is my personal choice for this - it's just the language I'm well-versed in, and it does allow some really cool stuff to be done quickly =) <SirCmpwn> sure, and the great thing about an open source platform (esp on Linux) is that you can use the tools you like <CRImier> I'll check out the GitHub in half an hour's time, now finishing up an order for a ZeroPhone parts batch <SirCmpwn> cool <CRImier> Wayland does sound cool, it's the great new thing, AFAIK - I'm not too well-versed in Linux GUI stuff to actually assess this proposal =D <SirCmpwn> well, it would allow you to extensibly do things like a notification bar, for instance <SirCmpwn> but it could be overcomplex considering that there isn't much screen to share anyway <CRImier> Yeah, Linux is great at development. I'm pretty much developing the whole ZeroPhone on a ZeroPhone, excluding the PCB stuff. <SirCmpwn> on the other hand, it would be nice to be able build applications in any language that can be a wayland client (i.e. any language) rather than having to write plugins for some less flexible UI system <CRImier> Where are you located, approx. (country)? <CRImier> I'm asking this because I can throw some links to hardware that you will likely need, from, say, Adafruit or Pimoroni. In practice, that's 1) Pi Zero 2) Pi Zero case of some sorts (a lasercut layered one works the best for me) 3) USB-OTG cable (microUSB to USB socket) 4) USB plug to microUSB cable (for powering the Zero). <SirCmpwn> CRImier: united states <SirCmpwn> and I just ordered a pi zero <CRImier> Adafruit? <SirCmpwn> I have a USB OTG cable <SirCmpwn> no, canakit <SirCmpwn> adafruit is sold out <CRImier> Did you order it with any extras? <SirCmpwn> power and a microSD card <CRImier> Adding an official case would be very handy - the shield is considerably larger than the Pi Zero, so it will benefit from some bulk added. <SirCmpwn> I'll just print something out <SirCmpwn> need an excuse to unclog my extruder nozzle anyway <CRImier> Oh, that's a great idea! <CRImier> https://cdn.hackaday.io/images//7764031505416771468.JPG <SirCmpwn> nice <CRImier> https://cdn.hackaday.io/images//5746471505416806332.JPG <CRImier> This is how what I'll send out looks like - just that I don't have neither Pi Zeros nor cases to send out =) [...] <CRImier> Send me your address, to zerophone at protonmail dot com . <SirCmpwn> can do <CRImier> [...] Do you mind if I share this conversation over at ZeroPhone Wiki? I try to save conversations which can be useful to others, so that they're accessible after everyone's chat logs are long gone. <SirCmpwn> sure, though I'm not sure what sort of useful information can be gleaned from this log <CRImier> My views about alternate UI toolkits, mainly =) I just believe that collecting bits&pieces of information like might be useful for somebody that wants to read as much as possible about the project, I know I work this way myself.
Modularity & self-assembly
<Turbowaffle> Is there any plan on making the front panel modular? It would be neat to be able to design different display/input options <CRImier> Turbowaffle: Well, the front panel is a separate module by itself, so you might as well replace that - there's not too much to it =) Also, it's possible to replace both the keypad board and the screen breakout with other boards - screen breakout header can be adapted for different pinouts, and the keypad is replaceable, too, it's even 2.54-grid based - you might want to reprogram the ATMega reading the keypad, though, if you're replacing the default <CRImier> keypad with something that differs a lot. <Turbowaffle> Neat. I ordered a set of boards a while ago to get a feel for the size and layout of things, and try to get my smd soldering mistakes out of the way. <CRImier> Turbowaffle: did you order some parts, too? <Turbowaffle> A few random things. An assortment of buttons, some ATMegas, one of the GSM radio breakouts. I have most of the passives already, just have to sort through them :\ <Turbowaffle> I was thinking of trying a 1.4" SPI e-paper display as an exercise to do some 3d modeling for KiCAD. I used FreeCAD a while ago for a few different projects, but nothing specific for 3D <Turbowaffle> (I have a set of the Gamma boards) <CRImier> I've got a 2" PaPiRus with a breakout, will do some hacking on it in order to add it as an additional display - that'll likely be during the crowdfunding. <CRImier> I've ordered some extra parts for Gamma boards, like protection boards (different boards will likely be used in the Delta revision, cause ones I picked seem to be harder to source). So I can send you those you don't have =) <Turbowaffle> Oh, sweet! I'll look at the BOM and see what I might be missing.
On using stacking headers for ZeroPhone assembly
<Turbowaffle> @CRImier, do you know the name of the types of header you're using in https://hackaday.io/project/19035/gallery#dd6cba5dabb2d1b990df357589a56389 <SirCmpwn> on the GPIO pins? <Turbowaffle> Yeah, the double rows <Turbowaffle> it looks like "round pin" is the key word, just found some on google <Turbowaffle> I've used them in a couple quad builds and I like how easy they are to take apart, but I don't have them in any quantity <Turbowaffle> Is there a close-up of the interface between the keyboard and the front board? It can't quite tell from the images how it's connected <CRImier> Turbowaffle: those are also called "machined pins" <CRImier> I only used those in the first version, they proved to be harder to work with than desired, at least, in this configuration - now I'm using default pins, in fact, since the second revision. <Turbowaffle> Interesting, good to know. Is any of the design dependent upon the size of the headers? I have some Pi stacking headers that are maybe 1.5 times the height of just the normal female headers <Turbowaffle> If not, I was thinking of designing my case to allow "spacers", so you could potentially hold more or less stuff [...] <CRImier> Turbowaffle: front board uses non-stacking female headers, and back board uses simple male headers <CRImier> I tried to get longer-than-usual male headers from China, but it turned out the seller that listed them didn't actually have them <CRImier> I guess that spacers would be a given if you were to design a lasercut case =) <CRImier> Can you maybe find a photo of your stacking headers? [...] <Turbowaffle> The stacking ones I have are like these https://www.amazon.com/gp/product/B01IRRCEBK/ <Turbowaffle> Nice! I've been putting off soldering anything to mine yet <Turbowaffle> @CRImier, the headers are the only interconnects between the boards, ya? [...] <CRImier> Yeah, ZeroPhone uses one male and one female header <Turbowaffle> I was planning on at least doing my first one with stacking headers so I can take it apart, because I will definitely do something wrong <CRImier> Turbowaffle: you can actually take apart the phone with the headers that I currently use. The catch us - the Pi Zero has to be soldered to the back board =( <CRImier> The best idea I've had so far, unfortunately. [...] <CRImier> I do have one Pi Zero with stacked headers, I use it for testing <CRImier> https://cdn.hackaday.io/images//4225181506640053009.JPG <CRImier> https://cdn.hackaday.io/images//9433071506640061609.JPG <CRImier> Basically, a Pi Zero soldered on some stacking headers. So, if I'm sending [only] back&front boards to somebody that already has a Pi Zero (provided I don't have one [to send along]), I can actually test [the boards]