Closed icecube45 closed 4 years ago
Oh geeze yeah I didn't even consider a screen that small! I kinda assumed the official pi touchscreen would be the smallest people would go
Yes I agree, but I'm worried that might not be enough. I'll try seeing how well it'll scale down, and see where else some space can be saved.
To be fair the actual screen is decently large. It's just the working resolution that's small. I'm actually not even sure what the proper resolution of this display is, being as I have a decent number of hacks/custom circuitry going on to be able to output to it. Just 320x224 "works". I should play around with it again.
Another idea/suggestion would be to be able to remove the bottom tabbar. I know currently there's the option to remove the volume controls from it. But in my case, I require none of the options it provides, and removing the bar altogether would save valuable screen real estate.
So is ia being stretched to fit to the display, or it is only using a portion of the display?
But yeah that's a good idea that, I can make the bottom bar a hideable feature.
It's being "stretched". Basically just a very large, low resolution display.
It all gets kinda weird by the fact that my pi is outputting RGB video, but the pi resolution is 320x224
Hey so before i do any more work for this feature, I was wondering if you could checkout the scaling
branch and see how it looks.
The catch (for now) is you'll need to modify the build process slightly like so:
cmake -DCMAKE_BUILD_TYPE=Release -DRPI_BUILD=TRUE -DRESOLUTION=.25 ../
make
the .25
means you want to use a resolution 4x smaller than the default, which in my testing was the best scaling factor for your resolution.
My main concern is that even if the UI \~looks\~ proportional, at such a low resolution things will not be legible at all. So I want to see if this is a viable way to go, or if I need to find another means of doing this.
While playing with the scaling, I was actually able to bump up my working resolution a little! Now at 480x234. Still not amazing, but larger!
For this new resolution, I tried both .5 and .75 scaling. I also disabled the bottom bar to increase screen real estate.
.5 Scaling felt nice, because there were no scroll bars in sight.
.75 Scaling felt nicer UX wise, but the left tabbar had tabs overflowing.
I removed the apps launcher tab, and the result is a really nice to use UI at .75 scaling.
So perhaps the solution for lower resolution screens is a combination of overall scaling + more customization around what is displayed.
For now, I'll be using this .75, no apps launcher, no volume bar version - it's quite nice.
Glad you got something that works for you! I'll start working on some native controls for the scaling / bottom bar / configurable tabs so that way you won't have to hack around it.
Using a resolution of .75, i did notice a few weird things (radio buttons are squares etc) so I'll need to figure out how to fix that stuff too.
Also I want to try some UI tweaks to optimize space, maybe adjusting some spacing and sizing in general.
Hi, Maybe on the UI side i can help, i'm working on a design for an infotainment system available at the link: https://www.figma.com/file/cVrvT0JnqFgGerpkrqrqTD/Intelligent-auto?node-id=0%3A1. The main goal for me is to have an uncluttered UI with a common design style and a focus on usability in the car. Feel free to check it out.
@ddellarocca Looks good! Alot of those components you have are going to be a bit harder to create in qt tho :p
Because this is mainly going to be used as a wrapper around android auto, my goal is to make it look as native as possible, which is why I've been following the material design guidelines as closely as possible. I do like the design of your media player tho, I'll see how I can incorporate that into qt (I'm thinking it would need to be some sort of overlay widget or something).
@icecube45 this scaling feature has been alot more work thank anticipated lol
I'm nearly there, just need to figure out how the resizing is going to affect the omxplayer (since the coordinates of that need to be explicitly calculated and set) and then how I can allow certain tabs to be hidden.
@rsjudka ok, got your point! So before looking into integrate it in your project give me some time so i can build and use AndroidAuto in this way i can adapt my design. Let me know what components are harder to create in qt. Anyway what do you use to develop the UI? qt creator?
sure take your time :) feel free to join the slack also if you want to bounce ideas off some of the members too
https://join.slack.com/t/opendsh/shared_invite/zt-e4r2nqsk-yhOh8zx6v2qbAEItOad_KA
dropdowns are a pain in qt to style (and also are basically a separate window ugh), the tab bar is not that customizable, and rounding buttons can sometimes get wonky :p
oh and UI was developed all in c++, no qt creator or designer
scaling now implemented and merged into develop!
Perhaps an issue pretty specific to me, but on very small displays IA is unusable.
For instance, my display is 320x224, even with scroll bars, settings are inaccessible, and the UI is very disproportionate.
Best solution would be having an overall scale factor for the UI, I think.