#apertus IRC Channel Logs

Hello

Good, I added the _leftButtonBar in IScreen yesterday and also tested it, it works!

So what are the next steps?

but there is additional important step to implement

> please check the docs about show/hide the button bar, would be good to have automatic enabling when button is added, but also ShowLeftButtonBar(bool show)

base class should have general logic, like drawing the dialog and button bars, latter one at last, but the dialog drawing should be something like DrawContext() which will be overridden in the derived class, this drawing method should get x, y, width and height of available content area, which will be calculated in the base class, when it's clear which bars will be drawn

It can accept any, but the left is only for the ImageButton, right?

Okay

do you have a screenshot?

added a task to lab, for the screenshot button, so it's easier to do

as you are in control of the sidebar, which width did you supply?

the edges are still jagged, the conversion seems to be not that optimal

button 24x24

yes, maybe we need a different method, other than the xbm format for the conversion

bar is too wide, you can make it 30 or 32, as you don't need that much space around it

Okay

great to see sidebar progress!

onto the parametermenu now

and instead of making it a small pop up inside the settingsmenu decided to make the parametermenu fullscreen, very similar to an actual menu

same screen?

I would derive the parameter menu from IMenu

if you will only have like 3 selections, i don't see a need for a separate screen, but to be able to handle it, the widget is required

later we can ditch the IMenu, as it has no real purpose that is different from IScreen

sometimes popup sometimes whole screen

we could dim everything behind

the advantage of the pop-up menu I consider that you still see all the other menu items and current values

right, you convinced me to implement both options

full screen menu -> https://media.gettyimages.com/photos/menu-screen-on-a-canon-eos-450d-dslr-camera-the-cairngorms-february-4-picture-id133036820?s=612x612

so fo the small popup parameter menu would you derive imenu orr iwidget?

imenu was added for menus, but as we can have multiple different, e.g. WB will also use menu widget, the decision was changed to widget

ok

but we have multiple buttons around and can do it like T9

added to https://lab.apertus.org/T1182

never noticed, but they really hide other entries, when menu comes up

agreed

morning folks!

dimensions look good, the icon scaling looks a bit better but not great yet

btw, I strongly suggest to use a font suitable for the size and the fact that it is not anti-aliased ... same goes for the icons

just saying as it really looks unnecessarily ugly

display should be set to 320x240 and library version to Adafruit GFX Font

not a priority atm IMHO

What do you mean? They are black and white

yeah I am sorry it was a trick question :)

for the kind of symbols we are now starting to add it might make sense to make it 2 or more bits

4

mumptai: yes, version 3 is on the way to design completion

for the icons do you currently draw the rounded rectangle in the code and the icon as black image right?

Yes

of icons

true, but we had 8 bit icons before

but two additional shades might be enough to create smooth edges

that would indeed be more complicated/resource intensive

no mixing required

will not look good on dark background

sounds good

https://lab.apertus.org/T1191

as long as its monochrome yes

we need proof of concept first to see the improvements of the edges

https://lab.apertus.org/T1177#16981

and without images

last sentence for parameter menu, and before that about missing result images of the camera

but this we can try with dimming, whitening or hiding

it's not hard to add, duplicate fill, call it dim and let it go over all pixels and reduce the brightness, then draw the menu

dithering makes sense for large scale images with gradients, etc - for icons with clear geometry I don't think it will help much

" let it go over all pixels and reduce the brightness" that would require partial redrawing which is not possible currently or how do you mean?

for dimming we have to redraw whole screen, we don't have partial updates yet

do you have a quick method how to dim a color565 16 bit color value?

thanks

take a grey value and off you go, will end my work in am oment and assist a bit

will check the debug problems first, maybe then you will have some results on dimming

debug fixed in launch.json, working directory was wrong, this is the right one -> "cwd": "${workspaceFolder}/AXIOM_Remote_Firmware_Visualizer",

great, I subtract a dark grey to dim, interestingly it creates weird colors...

by the way, haven't set default build type to debug at the moment, so it requires cmake -DCMAKE_BUILD_TYPE=Debug .. for now

what happens if you multiply the pixel color by 0.8 or so?

nice, LSD effect

thanks , will try

your color makes everything green

https://pastebin.com/raw/4ri59Q1h

dimColor should be calculated only once and placed in the enum of colors of course, so the version is a hacky one for now

ah, was only checking the main page first, just a moment, my board was crashing because if dimming

but green is also much "stronger" in the subtracted color...

it does not affect gray that much, which is interesting

yeah but thats exactly what should happen with a grey value

what would be a good time to push?

se6ast1an, can the new micro revision be seen somewhere?

the monday irc meeting logs are a good starting point though

BAndiT1983: pushed, please give it a spin

a pdf export of the schematic can be found here: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/blob/r3/micro_rev3/micro_rev3.pdf

i just found the branch

the lfe5 is there for usb3?

it is also used as gpio expander

for usecases where all that flexibility is not necessary

sensor is gonna be an ar0330 again?

although nextpnr-xilinx is also coming along quite nicely

the first module we will develop will probably be the ar1335

if cost isn't an issue zynq ultrascale wouldn't be a bad option

powersupply is a similar annoyance, only thing, you need a 32bit ddr3 or ddr4 memory

okay, its complexity is daunting

but using a ready made devboard again could help there

for example this one: https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-ultra96-v2-g-3074457345638646173/ is quite cheap for what it is

its connected to the PS, and linux support should be "okay"

as xilinx likes to break stuff on their linux fork and always lags behind the upstream by quite a bit

yeah

might be hackable though (not so sure about that)

https://shop.trenz-electronic.de/de/TE0802-02-2AEU2-A-MPSoC-Development-Board-mit-Xilinx-Zynq-UltraScale-ZU2-und-LPDDR4?c=473

nice find

even better

very interesting trenz board, but how would you actually get data into the system? it says Benutzer-I/O but no details...

the pmods are likely to be too slow, 33R + ESD

most is used for pmod, buttons, LEDs and a vga output

yeah this board seem more like an actual dev board and not like the like a SOM kind of thing

good night