#apertus IRC Channel Logs

Hi, morning!

now I'll do the header files conversion which will be same as last time, right?

yes

it's looking better than the last time -> https://pasteboard.co/J7GXmEf.png

but we still need to do adjustments, i know that "a" in apertus has slight bow down, but it introduces more jagged lines and should be straightened out

I'll do that now, first I wanted to do the process on one image file

ok

Hi all

how is it going?

I'm having a fresh look at T1184 (I stashed all of my changes till now)

weather is getting better, was rainy

well, the "knob press inner circle area" approach does not seem that attractive anymore. It was too finnicky

what I figured out was that when you push a flag, it's effect is applicable to *past* (as far as the imgui loop flow is concerned) GUI items -- not the ones that come later on

wait, did I say that right?

you mean the 942 issue on dear imgui?

no, the other one, about drawing button in the center of the knob and check the event, if it gets it first, before the knob

panintended: what happens if you stack another button on top of the knob, in the center? is the click still affecting the knob?

regarding your question, of course you're right, as the flags are for the last object, it's a stack or so

yes, the original knob "button" is the one affected in such case

This has dragged on quite a bit though, I mentioned to se6ast1an that if I don't have a solution by today I can release the task for others to give it a shot

take your time, but it would be interesting to know how clicking is handled

Yes, I'm adding a button exactly where the InvisibleButton of the knob is (and with the same dimensions). it is indeed drawn last (the knob image is drawn on top of it), but again the knob is affected instead of the new button

this is quite interesting, would have suspected that it work in reverse of draw order

what do you mean? you uncommented the is_hovered line? because for me it worked

i've just added a button in the center and tried to hover with the mouse over it

this is what makes me also wonder what else is available in the lib and if it can be helpful -> https://github.com/ocornut/imgui/issues/2464

set higher width, so it's outside of the knob also, it's working as long as the mouse is not inside the knob, definitely some obstacle there

ok, moved drawing before invisible button and it's active on hovering, even if the other half is beyond the knob, so the order is still top-down and not Z-index

now we have hen-egg principle ;) but at the moment i miss a clue what to search for

maybe a second invisible button for the area of the real button and then checking is active for the second one

but i'm sure there are easier and better methods

works!

it's not properly centered and sizes were changed for testing, but it's a little problem

ah, so beginchild creates a new context (or sorts)

yep, like a group which is on top

thanks, I can continue with this solution for the knob press if you also agree

I'd imagine the restyling would not be terribly difficult. and besides the main purpose of the visualizer would be to test certain aspects of the firmware without having the hardware at hand, correct?

is this for some sort of compliance or can I change that?

probably not cleaned up properly back then

great!

very good, have you committed it to your repo?

which one?

wait, DrawIcon() is good like it is, please adjust the conversion process

black background and white icon is what it was before and should stay like that, much more intuituve

but I still think the makefile can look better and somethings can be added to that, will do that

metal_dent[m]: why are you listing any file you're converting? in the makefile you have wildcards, which should allow to convert files at once, e.g. ones ending with _icon would get simple conversion and logo different approach

sed is too intrusive if you have to switch forth and back, maybe it can operate on temporary file or solely in RAM, don't like that original file is modified in the process, this can break the data

but it needs proper command to do it in-place without overwriting the file

did anyone test the fullscreen parameter menu GUI yet, will create a screencapture video soon

morning folks!

*dammit, touchpad moved the cursor: still on separate branch, but will try to merge

good day Bertl

se6ast1an: looks good, will check details later, as WB page would be a bit fo playground for overall menu widget testing

virtual serial idea tested, will now add more code, basic idea is to use predefined ports -> socat PTY,link=/tmp/axiom_remote_port,raw PTY,link=/tmp/axiom_beta_port,raw

great

as I might want to show that as well in the video

when will you need it?

just push when you are ready

good choice, or gawk if you need more context

probably overkill, but an option as well

input file -> https://github.com/apertus-open-source-cinema/AXIOM-Remote/blob/dev/Firmware/Media/Icons/monoRingLogo.xbm

so, most likely you want to change the pixel_data_ring to pixel_data[]; and make the struct itself generic

the data is already in the right format, so all you need is to add the width and height

alternative approach would be to use the .xbm file as is (i.e. include it) and make the struct contain a const char * to the .xbm data simply using the monoRingLogo_width and monoRingLogo_height in the struct

https://pastebin.com/raw/T3FeM8P5

why?

well, I have no clue what he wants or doesn't want there, but it might be worth checking :)

I also included the cleanup I mentioned earlier, I hope I didn't go too crazy :D

I'm going for a run, will check when I'm back

:)

Bertl: as we have headers, no need to have .xbm there

the xbm is intended for C inclusion, why convert it?

well, if you like to rename .xbm to .h, sure, why not, might be confusing but will work with any extension

will merge now

panintended: it works good, but i can't find a visual indicator, or should the image of the knob be extended?

also what do you mean with corners interfering with knob rotation in your comment? while testing it was no problem to rotate the knob or click the button, no hiccups also during rotating the knob and going with the mouse over the button (mine was smaller, as we don't need a very large button)

just pushed a small fix from my side to fix an issue with the fullscreen parameter menu

me or panintended?

line 111, replace InvisibleButton with Button and replace text there by Click, then the area is visible

button is a bit too large, so line 17 can be 0.3 * knobDiameter

https://pastebin.com/eXRNR8U1

the button only turns "visible" when hovering over it though

we could alter the knob graphic though

that was also the idea, maybe we can have invisible button with light overlay when over click area, when image is adjusted

ah, sub-task is better

https://lab.apertus.org/T1196

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

thanks!

or do we still have some bigger block which is not covered yet at all?

indeed we are making very good progress

would you be interested in this as your next task?

nah, I was lucky that I had BAndiT1983 there to bug when I needed help :)

it's one of my tasks to be available for discussions and helping when required, so it's not bugging at all

I've been over this task before. Can you elaborate? What is the need for BUTTON_UP events from a functional perspective

highlighting of buttons

merely visual thing, could also be accomplished with just a slight delay, like 200ms before action and without button event

but events are also important for continuous activity

BAndiT1983 what do you think about this?

metal_dent[m]: now i will write it the third time: use xbm:home_icon.h as target, the "xbm:" notation in front of it defines the format, that's it

BAndiT1983: could you repeat that for me? :)

https://www.youtube.com/watch?v=1jSTiKHOFEI

panintended: the lines from this thread are looking useful -> https://github.com/ocornut/imgui/issues/1537

BAndiT1983, regarding the PR: I basically went with a circular clickable area becaused I presumed that (1) a big part of the knob should be pressable without the need for a visual cue (I guess to be similar to a real life remote) and (2) following that, when using a large rectangular clickable area, if the user unknowingly clicks on the corner of the area first, the knob wasn't rotatable.

PR was very good, some smaller adjustments were required, visualiser should represent real hardware, but we should give people visual cues, thinking of newcomers in first place, which have never seen the remote in real

* mean have a look at the link you sent

area code works great, knob image has to be adjusted for proper indication, but that's a small thing

I'll assign T1185 to myself, OK?

cool

off to bed now as well ... have a good one everyone!