HaxeUI Ceramic

[edgy mason]

@burnt dune Have you ever tried windows with haxeui-ceramic? They seem to be really glitchy...

specifically the close buttons and stuff

once you move a window, you are unable to close it

ah nm i fixed it, the window container was too small

[burnt dune]

I do remember some issues but I thought they were pre rework stuff

[edgy mason]

right now it seems like everything is working

[burnt dune]

[edgy mason]

guessing cursors don't work?

[burnt dune]

they're hit and miss here and there

[edgy mason]

seems like windows break when they are overlapping

[burnt dune]

how bad are they breaking

[edgy mason]

you can't move them

[burnt dune]

could you shoot me over a repro to pin, it's fine if its just on haxeui's builder

just want something to quickly copy and paste so that when i have a moment for a side quest I can just quickly look at it

[edgy mason]

This should do the same
https://haxeui.org/builder/?47134e25

[burnt dune]

ty, i'll take a look asap

[edgy mason]

thanks so much!

there is also just normal depth issues

[burnt dune]

I guess windows add some complications to the setup, never tested them too much but I have an idea of where to look

I'm mostly operating with normal components and rarely have many issues

[edgy mason]

oh also, you can't move windows with touchscreen

not as big of an issue, but seems like it would be an easy fix. i can probably look into it

[burnt dune]

that surprises me a bit

I'm pretty sure all my events in the backend are using onPointer events

maybe something needed to be onMouse though

maybe I accidentally did onMouseMove somewhere

[burnt dune]

@edgy mason Just had a quick look at componentimpl

I suspect that particular issue is more to do with not mapping pointer down for touch

ceramic has touchId iirc

i'm only checking for mouse buttons

likely a simple fix

[edgy mason]

kinda what I assumed

is it this portion?

[burnt dune]

nah, i think it would be in onMouseButton

or somewhere around there

ceramic pointer events iirc act as an abstraction for touch as well

so it should be exposed already

[edgy mason]

ah probably have to fix it here?

[burnt dune]

it wouldn't be click

you are holding the mouse down, click is a different behaviour

[edgy mason]

oh ok

[burnt dune]

is my best guess

somewhere in here

but i could be wrong

i think the issue is simply with the window isn't registering the down but is likely registering the move

[edgy mason]

this works

not sure how onMouseRightDown should be implemented, maybe keep it the same

[burnt dune]

i think right click on touch devices is typically handled with multiple touches right?

[edgy mason]

long press

[burnt dune]

is that universal?

[edgy mason]

on chromeos and ios at least

for touchpad it would be multiple fingers

[burnt dune]

that sounds annoying 😄

[edgy mason]

i think you try to avoid right click on mobile for that reason

[burnt dune]

yeah, you'd want right click for tablet sized devices tho

[edgy mason]

honestly even on desktop right click is typically not ideal

[burnt dune]

tbh, i'm not sure if multitouch is easy to detect with ceramic or the pointer api

[edgy mason]

excluding context menus, it isn't very discoverable

[burnt dune]

long press seems like the right choice here

it's probably better to have it than not have it

[edgy mason]

https://ceramic-engine.com/api-docs/ceramic/LongPress.html

[burnt dune]

component wouldn't work very well here

[edgy mason]

add it as a component to the scene?

[burnt dune]

would rather just time it seperately so that its contained

and haxeui can have different right click events for different components

adding components to the scene seems a bit awkward

[edgy mason]

i'll see how hard it is

[burnt dune]

it'll basically be something like

check down time with current time, if time is around 500-600ms trigger right click event

if you don't need feel free to just leave it to the side and i can just add it to the list

[edgy mason]

should it also do that with mouse?

[burnt dune]

nah

if someone requests that one day it can be thought of but i doubt it'll ever be a thing

would be weird if you're dragging a window and a context menu pops up mid drag

[edgy mason]

wouldnt that be weird on touch too?

[burnt dune]

it would

might be something that can only be figured out whilst actually working with it

at least for me

what's touchIndex....

[edgy mason]

no clue, it is always zero (or -1) for me

[burnt dune]

that must mean a counter for number of fingers touching, right?

[edgy mason]

oh maybe

lemme test

hm not on my chromebook

[burnt dune]

you might have had the right idea at the beginning then

maybe onPointer events don't fully expose the touch api like i thought it might

maybe using the direct touch api would be better here

anyways sleep time

[edgy mason]

night!

https://github.com/Jarrio/haxeui-ceramic/pull/13

anyways here is this for now, I'll experiment with long press

I really don't see any reason to not use a component, it works just fine...

or it did, it decided to break lmao

[edgy mason]

Ok, in that same PR I commited a working version of the right click emulation thing

It uses a modified version of jeremy's long press component that only works on touch

[burnt dune]

hmm, i can't merge the onleftdown fix because i don't want to merge that longpress implementation

i'll actually just merge all of it for now and then switch it out later

at least something will be partially working there

[burnt dune]

Thanks!

[edgy mason]

Fair enough

[edgy mason]

is there a decent way to prevent clicks from going "through" windows

like if I have a ceramic visual with onPointerDown set, it shouldn't be clickable when a window (or other haxeui element) is over it

[ember plaza]

I don’t know about haxeui, but that’s the default behavior of Ceramic pointer events

[edgy mason]

Checks out, not sure why it isn't working with haxeui then. Maybe there is some weird depth stuff happening.

[ember plaza]

Could be

[burnt dune]

what I've done in my app is have a way to pause the input

on the visual

[edgy mason]

that sounds very tedious

and not that applicable in my situation I think

[burnt dune]

it is a bit awkward but it might be necessary for now

solving that becomes very awkward

it's only an issue in the backend because all pointer events are done on screen coords

I may try and look at that again one day, but I'm pretty sure the alternative is worse

I might be able to get it to work now and it would be nice to not have to have pause apis in my stuff

[edgy mason]

👀

[burnt dune]

I'll add it to the Todo list but I've messed with that stuff a lot and the current was the only thing I found that worked on all components and at least it's work aroundable otherwise

[burnt dune]

The issue was on some components Visual.PointerEvent would be fine but on others it wouldn't because rather than having the event tied to the component like haxeui expects the event is tied to the visual so you ended up in situations where some components were only interactable in certain areas

I'm really not sure if this is avoidable tho

[burnt dune]

@ember plaza there's no built in way for me to say visual.stopListeningToCertainEventsForAMomentPls() is there?

[ember plaza]

visual.touchable = false or override interceptPointerDown() or override interceptPointerOver() depending on your use case

[burnt dune]

touchable may work, intercept can't work because it's at a library level

touchable would at least give me the ability to add a simple api for handling this

[ember plaza]

Not sure what you mean by why intercept wouldn't work?

[burnt dune]

because it would require a user to implement the interception

[ember plaza]

Because the visual class is a class from the user? I thought the visual is created by haxeui

[burnt dune]

yeah but I'm not building ceramic haxeui components, i'm rendering existing components that have no awareness of ceramic systems

so I can't really utilise the intercept overrides unless i'm understanding it wrong

[ember plaza]

I don't see why you couldn't. In your backend you have complete control on what visuals you are creating from haxeui components, so you could as well create custom visual subclasses that are part of your haxeui backend building blocks which have a custom version of interceptPointerDown/Over

[burnt dune]

class ComponentSurface {
  public var visual:BaseVisual;
  //...other props
}

The chain looks like - AnyHaxeuiComponent extends ComponentSurface
2 issues with overriding from what I can tell
1 - I don't have access to the override because the visual is a property
2 - All "std haxeui" components are made in a backend agnostic way, it wouldn't be feasible going through them all adding intercepting rules to each component

I did try utilising intercepts for haxeui components in the past but it didn't go very far

[ember plaza]

Again, that's not a problem. Your BaseVisual class, let's say it maps to ceramic.Visual, at some point you are assigning an actual visual instance to that property from your backend, right?

So why can't you assign a subclass of ceramic.Visual instead?

(subclass, which override interceptPointer*

[burnt dune]

because there's no interception rule that applies to all contexts

maybe i'm remembering things wrong, it has been a while since i've messed around with that stuff

[ember plaza]

As long as you override interceptPointDown/Over, you can make the logic you want, you could make it use custom options you assign to your visual subclass, so that doesn't mean every visual has to behave the same, you are free to do whatever you want in your override, again, not an issue, just a code architecture to get right

[burnt dune]

If you think its possible i'll take another look at it at some point

maybe was just a skill issue x)

[ember plaza]

That's probably a bit less intuitive than just using visual.touchable for sure, especially if sometimes your BaseVisual is not a plain ceramic.Visual, but nothing that can't be solved imo 😄

[burnt dune]

it is, base visual is basically a manager for all the various kinds of visuals that exist x)

class Base extends Visual {
    public var solid:Quad;
    public var slice:NineSlice;
    public var rounded:RoundedBg;
    public var gradient:GradientMesh;
    public var clipQuad:Quad;
    public var bgImage:Quad;

    public var border:Border;
    public var roundedBorder:RoundedBorder;
//...
}```

but it should still be fine to see if i can create some kind of useful behaviour on Base itself

[ember plaza]

Oh I see, then that's even easier, you simply override interceptPointerDown/Over in this Base class and you control what it returns from additional custom fields in that same class

[burnt dune]

Yeah, i think touching is the way to go

a quick experiment

override function interceptPointerOver(hits:Visual, x:Float, y:Float) {
    if (customVisuals == null) {
        return false;
    }
    trace(customVisuals.length);

    for (visual in customVisuals) {
        if (visual.hits(x, y)) {
            trace('blocking');
            return true;
        }
    }
    return false;
}

This doesn't work with a modal dialog as an example

because the visual that I want to intercept is not part of the hierarchy

that was the missing detail to help fill the "why it isn't applicable"

[ember plaza]

Mmmh, I guess, or you could override interceptPointer_ on the shared parent of your modal and the rest of the ui

[burnt dune]

It does block the interception but the issue is because the modal adds a layer over the entire UI

it ends up always intercepting

or at least some content is always intercepting something

when it shouldn't be

[burnt dune]

that's not really possible at a user level

a user can't add an override because a haxeui surface isn't the visual directly

and it adds complications anyways, like, i don't think it's in the nature of haxeui to have to manually handle these behaviours on a per component basis

it should be handlable

i think with touching it probably is

[ember plaza]

I don't really know what's your use case anyway. If it's just to disable interactions on what's behind a modal, then there are plenty of simple ways to do that, either touchable = false on the hierarchy behind your modal, or a full visual that listens to pointer events thus blocks them

That kind of use case doesn't require to override interceptPointer___

[burnt dune]

haxeui has its component system, and sometimes we want to add custom non-haxeui components to the setup. In the scope of haxeui, overlap checks are relatively stable but things get a bit confusing when we introduce non haxeui components

2 mins and i'll record an example

^logo doesn't want that to happen

the chart isn't a haxeui thing so its got its own input handlers

for this use case, i just added a pause api to the chart to block the inputs i don't want to occur and just toggle it when a dialog is shown

Logo wants something like this built into the haxeui backend which is what i'm not entirely sure is possible without breaking other things

it seems like such a context aware use case that i'm not sure is wise to mess with/introduce into the backend

always can make it togglable i guess but yeah, hopefully that at least illustrates the problem a bit

might be hard to still figure it out if you haven't played around with haxeui a bit though

[ember plaza]

I'd solve that by simply adding a transparent visual that takes all screen space, put it right behind the modal, and make it listen to onPointerOver(this, _ -> {}) and onPointerDown(this, _ -> {})

Or if you want to prevent interacting with what's behind the modal itself only (and not around the modal), then make the modal root visual itself listen to pointer over/down

If that doesn't prevent events on what's behind, well, that means you are using other means than visual pointer events to handle interactions (maybe by using screen events directly?)

[edgy mason]

It uses screen events

idk enough about haxeui to know if that is avoidable

[ember plaza]

Ah I see, then nothing that I suggested above will work as that system is entirely bypassed

It’s either haxeui reads screen events and dispatches them to the right haxeui component OR components which listen to visual events and let Ceramic do the dispatch. But having each component individually read screen events is not going to work, which explains your issue

[burnt dune]

yeah, i know why it occurs

and it is solvable, i just don't know if i can provide a solution from the backend

I don't believe I can

but the touchable option did give me an idea to try

[burnt dune]

ahh, not in the mind for it tbh. I don't think there's a good way to do this, probably better to just manually handle it

and I suspect all backends would have the same issue any way

[edgy mason]

Is there no way to attach the events to the visuals themselves?

[burnt dune]

not without breaking other things, but feel free to mess around with it

you might be able to figure something out that I couldn't

simple components work but slightly more complicated ones don't

but i did this so long ago that I can't recall where things specifically don't work

[edgy mason]

Kinda an intimidating codebase lol

[burnt dune]

all event handling is done in the same place you added the touch events to

its very likely you'll see visual.onPointer somewhere in the file if you ctrl f for it

just commented out

when you do visual.onPointer you're using ceramic's system which now adds a scope to the event

that haxeui doesn't actually know about

[edgy mason]

Hm and that causes problems?

[burnt dune]

ya

take a simple example visual.onPointerDown

now all pointer events are scoped to the visual you apply the event to

haxeui components don't really work like that, they're actual ui-like

if you have 2 pointerdown events in the same component

now because ceramic is looking for the visual, where you'd expect 2 events to fire, you only fire the one you're over

components don't really work like that

[edgy mason]

Too late for me to think lol. But I think I get the gist.

[burnt dune]

i defo think all backends will have this "issue" though

all backends afaik use screen coords

nothing unique to the ceramic backend here

[humble shore]

i dont think all backends have this issue (if im understanding it)... haxeui delegates the event handling to the backend, and its up to you what you do with it, ideally, for mouse events it should be scoped to the component (visual) in question... there are also screen mouse events, which are also used, but something like "click on a panel" would be using the visuals event system (i would assume)

there is also event.cancel(), but not sure if that is linked up in haxeui-ceramic, or how that would work

[burnt dune]

i'm sure they will

the events are applied outside of the haxeui scope, there's no way for haxeui to know to behave any differently with them

[humble shore]

but the events are captured ON the component in other backends

[burnt dune]

i think you're missing something

[edgy mason]

He seems to understand?

[burnt dune]

If you make a custom FlxSprite that has its very own logic for FlxG.mouse.overlaps() and then you make a haxeui wrapper for that sprite. There is no way for haxeui to implicitly know about the overlap check, flixel is just going to run it

regardless of what event mapping you do on the component itself

its two different systems

[edgy mason]

Wouldn’t you just dispatch the event then?

I am confuseled

[humble shore]

but is that the same thing we are talking about? I thought the issue is just that events are "going behind" and making it to other components

but from what i understand cermic iteself doesnt do that

[edgy mason]

Events go behind HaxeUI components into ceramic visuals

[burnt dune]

Nah, that's not really the issue

[humble shore]

which is somewhat normal (depends on the backend), but this is where .cancel() comes in: https://haxeui.org/builder/?c5fd397a

[burnt dune]

If all components are haxeui components then everything is fine and there's no "issue"

the nuance here is when you're wrapping a custom thing and interfacing with haxeui

[humble shore]

no, i get that, but im saying, if you have two ceramic visuals and they overlap and both have pointer event listeners, do you get one or two events if you click the overlapping part? (no haxeui)

[edgy mason]

One

[burnt dune]

if you're using visual.pointerDown the event is the top one, there is a system in ceramic that you can mess with that gives you control over this though iirc

[humble shore]

and is haxeui-ceramic using visual.pointerDown?

[burnt dune]

its using screenevents

[humble shore]

i think it should be using visual.pointerDown, no?

[burnt dune]

it doesn't work

[humble shore]

why?

[burnt dune]

the behaviour isn't consistent, i did this so long ago i can't remember where it fails

[humble shore]

all the other backends use events ON the componentimpl thing (FlxSprite Sprite, Element, etc)

haxeui uses screen events also

to track certain things, but the up, down, in, out, etc should all be on the component

haxeui-kha doesnt have this concept (since there are no "sprites") but haxeui-kha implements it instead

[burnt dune]

I would be very surprised if this issue didn't exist in other backends

[humble shore]

can you point me to you mouse handling componentimpl code i haxeui-ceramic?

[burnt dune]

https://github.com/Jarrio/haxeui-ceramic/blob/master/haxe/ui/backend/ComponentImpl.hx#L889

[humble shore]

i think it depends on the backend, if the default behaviour of the host framework is to not dispatch two events for overlapping "things" then you wouldnt have the issue - i think the problem is your mouse input code is sidestepping ceramics visual pointer input system

and "onMouseMove" is a global mouse handler i take it?

[burnt dune]

wdym

[humble shore]

i mean, where is onMouseMove setup?

what calls that? Im guessing is screen wide

[burnt dune]

https://github.com/Jarrio/haxeui-ceramic/blob/master/haxe/ui/backend/ComponentImpl.hx#L1146

yeah, it's a screen thing

[humble shore]

so that feels incorrect to me:

html5: `element.addEventListener(EventMapper.HAXEUI_TO_DOM.get(type), __onMouseEvent);`
openfl: `this.addEventListener(EventMapper.HAXEUI_TO_OPENFL.get(type), __onMouseEvent, false, 0, true);`

flixel looks to be using screen events, so i would expect the issue there, kha too but it works around it (maybe flixel also)

[burnt dune]

simple example of using visual.onPointer event

this dropdown no longer fires an event because there's an icon sitting on top of the "visual" that has assigned pointer event

[humble shore]

why is there a pointer event assigned to the icon?

[burnt dune]

there isn't

that's the point

[humble shore]

im guessing you can control that in cermic?

but thats pretty much the behaviour logo is after, i think? Just not with "everything"

[burnt dune]

yeah but its not correct

that isn't how you're meant to interact with a dropdown

[humble shore]

but thats a backend issue thats worth fixing imo, the solution (again, my opinion) isnt "fuck it, screen events for everything"

[burnt dune]

this is how it's meant to work

[humble shore]

i get the issue

ceramic now thinks the icon is "over the top" of the thing behind (which it is) and so its blocking the pointer event

[burnt dune]

I don't really understand how I can solve that without making a lot of assumptions

[humble shore]

thats the fun of writing backends 😄

[burnt dune]

but everything regarding the backend works

this is an interfacing issue with things outside of the backend

[humble shore]

im not saying it doesnt work, im saying that, to me, screen events for everything isnt the right way to go when the host framework has altenatives, i appreciate that complicates things (not saying i have a solution)

iirc openfl has some "odd" things with mouse events that haxeui had to work around (though i think the opposite in that case)

[burnt dune]

well, it certainly might not be the correct the solution

but i defo tried hard to make visuals work

and i couldn't get it to

[humble shore]

i guess you need jeremy to help, because the pattern isnt uncommon (i mean, the behaviour you showed in your first video would also apply to ceramic at large and wouldnt be right)

like, no haxeui, you have a visual 100x50, and inside that you have an image 90x40 which is "whatever"... lets say the outer visual is your "button", then then same would happen in that the inner image would block pointer events

im guessing there is a way round that

[burnt dune]

well the ceramic way would be to handle that usecase specifically as far as i can tell

something like ```hx
override function interceptPointerDown(..) {
if (hasIcon) {
return false;
}
}

but that isn't how you would want to do things in a haxeui backend

jeremy's solution with the visual.onPointer method is basically the same as what i'm doing currently with the screen events

the "bridge" is just different

altho i suspect for something like a dialog it might actually automatically be handled

especially a modal one

[humble shore]

can you cancel events in ceramic? Im guess not since they arent events

[burnt dune]

you can intercept them on the visual but not cancel

[humble shore]

so i guess one tweak you can do, but not sure if it will help logo, is something like:

    function onMouseMove(info:TouchInfo) {
        if (!eventMap.exists(MouseEvent.MOUSE_MOVE)) {
            return;
        }

        root().screenToVisual(info.x, info.y, point);
        var x = point.x;
        var y = point.y;

        var listener = eventMap.get(MouseEvent.MOUSE_MOVE);
        var hittest = this.hitTest(x, y);
        if (hittest) {
            var event = new MouseEvent(MouseEvent.MOUSE_MOVE);
            event.screenX = x;
            event.screenY = y;
            listener(event);
                        if (event.cancelled) { // something like that on all of them
                            return false;
                        }
        }
    }

at least then "event.cancel()" should work

[burnt dune]

that's still in haxeui land tho

[humble shore]

doesnt that return false stop it from propogating up?

[burnt dune]

it's defo an oversight for the backend, but it wouldn't affect the core issue here

[humble shore]

yeah, fair enough

[burnt dune]

my chart doesn't work with the haxeui events

[humble shore]

yeah, but i was thinking (maybe) if you return false in the global handler it tells ceramic not to process anymore handlers? No idea (was a guess from the visual version)

[burnt dune]

the best I can do is toggle a visuals touchable property

but yeah, simply changing screen.onPointerOver to visual.onPointerOver and table hovers now behave incorrectly

    @:bind(this, UIEvent.SHOWN)
    function onShow(_) {
        if (charts == null) {
            return;
        }
        charts.display.pause = true;
    }

    @:bind(this, UIEvent.HIDDEN)
    function onHide(_) {
        if (charts == null) {
            return;
        }
        charts.display.pause = false;
    }

All you really need to do to workaround the problem is this

and i think this is relatively intuitive and you get full control over the problem

[humble shore]

i guess the issue there is the hard link

like, how you gonna do that for messages boxes? Or dropdown lists, etc

[burnt dune]

wdym

ah, i see

yeah, not ideal but i couldn't come up with something better

[ember plaza]

You can intercept events, meaning a visual in hierarchy can prevent an event from being fired on on of its children

[ember plaza]

This is definitely not a normal pattern in Ceramic, something isn’t done correctly in the haxeui backend regarding pointer events imo

[ember plaza]

I agree that using ceramic’s pointer events on visual should be preferred. If then you hit some edge cases for haxe ui, we can discuss them, but I believe they can be handled with standard ceramic api and, if needed, intercepting events

Binding directly to screen events is not correct

[burnt dune]

@ember plaza how would you handle something like this

with on visual events

the issue with the on the visual approach is there ends up being edge cases everywhere

most things break in some manner

[ember plaza]

That’s the same question I would have, the icon shouldn’t block the event, something done wrong

[ember plaza]

This should work

If it doesn’t, well, something going wrong in the setup

[burnt dune]

there's nothing wrong with the setup, it's just how components can be built

actually, there might be for this particular case

but i really don't want to go into

i've been down this rabbit hole too many times

okay to explore if its something quick to fix but so far all suggestions are basically at the rabbit holes entrance point

it would be more worthwhile if it solved more than 1 thing (that is workaroundable)

[ember plaza]

That’s not trivial but problems are going to come back over and over again if you keep adding workarounds imo

From my point of view, you should only use pointer events on visuals for the haxeui backend, which will make Ceramic do most of the work. Then if something doesn’t work as expected, investigate it, it’s likely hierarchy that is wrong, or an event handler bound to the wrong visual, or the size or position of a visual being wrong, but Ceramic pointer events system is expected to be reliable, it’s been used extensively on released projects with plenty of events

(So in other words, avoid pointer events directly from screen, unless for things like drag/drop patterns, which may use screen pointer move event (but between visual-bound pointer down/ups)

[burnt dune]

more workarounds are introduced with the visual approach though

basically any component can become draggable

pointermove is necessary for all components

i'm not sure what haxeui actually uses it for but it seems like something that needs to be mapped

[humble shore]

drag uses screen events to calc position etc

[burnt dune]

is that all pointermove is used for?

[humble shore]

nope, down is also used to hittest things sometimes, like when you click outside a dropdown popup

but the initial trigger that brings up the dropdown box (ie, the click on the button) is on the component itself

[burnt dune]

i mean the MouseEvent.MOUSE_MOVE event

[humble shore]

possibly, not sure... sounds reasonable, i cant think of another time its particularly useful

[burnt dune]

i guess it could be something a user may want to use for a custom component either way

[humble shore]

all "drag" type usages

[burnt dune]

fair

[ember plaza]

I don’t know if that’s the case already, but you should avoid binding pointer event handlers that you don’t use, like, if a component doesn’t interact with pointers, no onPointerDown() and so on should be bound. And if a component stops listening to an event, same, you should unbind the ceramic one with offPointerDown etc…

[burnt dune]

yeah, haxeui handles that already

[humble shore]

yeah, haxeui will ask you for an event, im assuming you arent just blindly binding event handlers "just in case"? (not related to above, just because of what J said)

[burnt dune]

i'm doing it in mapEvent()

[ember plaza]

Anyway, if at some point you want to bite the bullet regarding this @burnt dune , you could use visual pointer events everywhere, then if some specific case doesn't work, I can give you some flags to add which will tell you at Ceramic level what visual is catching a pointer event, in case it doesn't go where you would expect it goes

(ceramic_debug_touch is the flag)

The way pointer events work on visual is like this:

A visual is selected on the pointerDown event. If a visual catches that event, it will automatically catch the following pointerUp event (so you won't have pointerDown on one visual and pointerUp on another one)

[burnt dune]

why you gotta bait me like that

[burnt dune]

i don't really think the flag is that useful

it's relatively clear what's happening here

the over event is on the component visual, but the children are overlapping it so it doesn't apply the over event

[ember plaza]

when you have a child that has the over event, you could still consider that any parent listening to the over event is also at the "over" state

[burnt dune]

how would I determine that?

[ember plaza]

You iterate over visual.parent until you have no parent

[burnt dune]

I guess I could do that but would that be an okay assumption to make? 🤔

maybe for overs its fine and down events obviously it wouldn't be

how would i "fire" that event as well?

or would the idea be, don't intercept it at all if there's a parent

okay, no no no no, this is bad territory 😂

[ember plaza]

You could indeed override onInterceptPointerOver(), which would allow you to know when your current visual being over-ed has one of its children getting the next pointerOver event, so in that situation you could keep your "over" state on

[burnt dune]

i don't understand where this "over" state comes from though

like what am i toggling there, the event itself is the over state

[ember plaza]

I think that's something you'd need to manage, like if you want to know, when a new pointerOver happens, if some visual was over-ed already, and that visual is a parent one in the hierarchy, some how you need to keep that data somewhere

This is code architecture problem. Ceramic gives you the information (not always very trivial info to get, but the raw info is here)

[burnt dune]

yeah but what i'm trying to guage is what's the value add here because it isn't clear

currently I don't need to do that level of work or state tracking and within the context of haxeui it all works

i guess the value add is you wouldn't need to manage "visual pointer events" at all because now ceramic has enough context to handle it all

but it seems like a lot of effort with a high risk of failure

[ember plaza]

I don't know, you are showing me an issue with how pointer over events are being problematic when nesting them, I telling you how you can address that with Ceramic

[burnt dune]

no no, logo is showing me an issue and you asked me to describe what's going on

i have a solution for it

i'm trying my hardest to avoid exploring this 😂

[ember plaza]

I figure 🤣

[burnt dune]

i've wasted too much time on it, it's a physical repulsion every time i mess with that intercepts override

[ember plaza]

Touch/Mouse events are always a mess anyway, difficult to get right, especially when using an API that you didn't make yourself

[burnt dune]

it never works out and every time it crops up again the potential solution to explore is almost always more complex than the last time

[unborn dragon]

Always a mess except in Flash displayobjects 🥲

[edgy mason]

weird question, but would it be possible to have a function that checks if a haxeui component is over a spot?

just to streamline manually pausing

[unborn dragon]

Isn’t there findComponentsUnderPoint?

[edgy mason]

oh hmm

[edgy mason]

now that i think of it, probably wouldn't work 😅

[burnt dune]

[burnt dune]

I did add a basic thing but i'm not doing anything with it for now

basically changed the add to be addInternal for haxeui things and now the publicly facing add function will keep a reference to any customVisuals added to the visual

so that may allow some kind of thing to be added at some point

[unborn dragon]

Is the issue deeply technical or just doing it? I have a mouse handler I did in heaps, flixel has one that's similar, both are along the same lines as OpenFL/Flash

But I haven't thought about it enough in ceramic to see if it's more than that

[burnt dune]

I don't think it's deeply technical

it's just thinking it through a bit

all the information is there about figuring it out in some way I think, it's just about finding the right place to slot the check

my mind is very deep into my project and I don't really want to step out of it

[unborn dragon]

Mood

But it’s something I can work on or at least make a proposal for since I’ve done this now twice for haxeui

[burnt dune]

oh really? where'd you deal with it

[unborn dragon]

Aligning flixel’s existing mouse handling with bubbling/covering what’s behind, and then in my lil framework on top of heaps basically starting from scratch

Biggest question would be if it should be a ceramic solution or backend solution

[burnt dune]

ceramic already supports this out of the box

I'm circumventing that system because I couldn't get it to work

all pointer over/down events are done on the screen rather than the visual

[unborn dragon]

Ok so backend, make the ceramic solution work or make a mouse handler on top of it

[burnt dune]

first item in datasources never has data associated with it

[burnt dune]

can anyone help me debug this

with any item renderer data source setup, the first items act weirdly

The data is always nulled so I can never do anything with it

so if i click on the View chart, +Link or Show trade buttons they all result in null references

but the data did apply at some point

i have no idea where or what is causing that

I have

    private override function onDataChanged(data:Dynamic) {
        super.onDataChanged(data);
        if (data != null) {
                }
        }

but it still seems to get nulled

and why is it only the first one

@:xml('
<item-renderer styleNames="tradeCard tradeCard-breakeven" style="padding: 10px;" width="300" height="160">
    <vbox style="padding: 10px;" width="100%" height="100%">
        <h4 id="uititle" />
        <h5 id="uidesc" />
        <hbox id="uitags" height="100%">
            <item-renderer>
                <taglabel id="tag" />
            </item-renderer>
        </hbox>
        <vbox width="100%" />
        <hbox width="100%" height="100%">
            <button id="viewChartBtn" styleName="mutedBtn" text="View Chart" />
            <hbox width="100%" />
            <h5 id="uidate" text="2025-06-29 11:21" />
        </hbox>
    </vbox>
</item-renderer>
')
class AnalysisCard extends ItemRenderer {
    var save:ChartSaves;
    public var chart:ChartSplitter;

    private override function onDataChanged(data:Dynamic) {
        if (data != null) {
            super.onDataChanged(data);
            save = cast(data, ChartSaves);

            uititle.text = save.title;
            uidesc.text = save.description;
            uitags.dataSource.add({
                tag: {
                    text: "test"
                }
            });
        }
    }
}

Nothing too complex going on here

[unborn dragon]

Just testing the default list example, it seems like half the time there are two component events being dispatched when I click a button inside an item renderer

I think renderer within a renderer and custom components does put this into "more complex" territory tho

event.target isn't ever null

[burnt dune]

yeah its only when you're doing an item renderer component

normal lists work fine

lemme see if i can make a simple repro

it happens all the time for me so shouldn't be too hard

[unborn dragon]

What exactly is null? The components uititle and stuff or the data?

[burnt dune]

the data that was assigned to it

okay, it works fine with listview even though i'm sure it hasn't at some point... lets try box item renderers

maybe it depends on the complexity of the custom component

[burnt dune]

package ui.pages;

import haxe.ui.core.ItemRenderer;
import haxe.ui.containers.VBox;
import haxe.ui.events.UIEvent;
import haxe.ui.events.MouseEvent;

@:xml('
<vbox style="padding: 5px;">
    <CustomItem />
</vbox>
')
class TestPage extends VBox {
    public function new() {
        super();
    }

    @:bind(this, UIEvent.READY)
    function onListReady(_) {
        for (i in 0...10) {
            this.dataSource.add({
                name: 'Item $i'
            });
        }
    }


}

@:xml('
<item-renderer>
    <button  id="click" text="Click" />
</item-renderer>
')
class CustomItem extends ItemRenderer {
    @:bind(click, MouseEvent.CLICK)
    function onBtnClick(_) {
        trace(this.data.name);
    }
}

If you click the first button it will give you a null error for data.name, but the other buttons will work fine

https://haxeui.org/builder/?f6333ec6 works fine in the builder

[unborn dragon]

I can't actually find when it sets that renderer's _data to null

Happens with only one item in the list as well

But because the itemIndex is -1, the 0th item might be overlapped by a template/garbage/dummy renderer

So the other backends might have this as well but handle overlapping object mouse events correctly?

There is always +1 items in the parent's child components list, so that might be the template, including in builder

It's not feasible to trace components (need to add a tostring or something to componentimpl), so I can't right away tell what type the extra child is

This works after the first click

So yeah something like that

@burnt dune

It also happens with 0 items in the list, there's still something there and it goes away with the above code on click

[burnt dune]

that's what i suspected was the issue, the "definition component" is stealing the event somehow

[unborn dragon]

It doesn't in builder

Like even with 0 items it doesn't see the click event

[burnt dune]

yeah its so weird

[unborn dragon]

May be a recent core thing then, idk what release builder is on

Or your event unregistering is off, only two things I can think of

[burnt dune]

there's nothing specific about handling this kind of case in other backends as far as i could tell though

[unborn dragon]

If the others add the event and then immediately remove it would be backend specific

I'm not sure what goes on internally with the first item

[burnt dune]

    @:bind(viewChartBtn, MouseEvent.CLICK)
    function onViewChartClick(e) {
        trace(this.data == null);
        trace(this.save == null);
        if (this.data == null || this.save == null) {
            trace('blocked');
            this.hidden = true;
            return;
        }
        }

This creates an infinite loop in my actual app lol

seems like the mouse event constantly fires

[unborn dragon]

It did continue through when I hid the template, you may be continuing through onto itself or something weird

[burnt dune]

so the theory is, there's a dummy component overlapping

and for some reason that dummy component is remaining interactable

I have no idea what I'd be missing here tho

I handle visibility

[unborn dragon]

This is pretty much the only backend related code in itemrenderer. Have you ever confirmed your unregistering events works?

[burnt dune]

never did confirm but I also haven't had any obvious issues, that seems like something that would cause issues in more places than item renderers

I'm guessing the mouse event stuff is finding the hidden component because it's at the point, despite being hidden

wonder if I added a skip hidden components clause if it would 'work'

unmapEvents does work

[viscid tartan]

HaxeUI Ceramic

[burnt dune]

filtering the getComponentsAtPoint for hidden doesn't make a difference

private function findChildrenAtPoint(child:Component, x:Float, y:Float, array:Array<Component>) {
    if (child.hitTest(x, y) && !child.hidden) {
    array.push(child);
    for (c in child.childComponents) {
      findChildrenAtPoint(c, x, y, array);
    }
  }
}

Just added the hidden check here

interesting.... the visual's visable property is set to false but the haxeui components hidden property is set to false as well?

if i do the check on the visual's visible prop i get into that infinite loop situation with the if (this.data == null) this.hidden = true

@unborn dragon oh dang, I think we got it

yeah, there's a before and after in there

much thanks for helping solve that one, its been bugging me for ages

does seem weird that component.hidden isn't accurate with component.visual.visible

but it does seem to work

[unborn dragon]

They should be 1:1… but maybe a more extreme example of when you shouldn’t set the backend’s property. We had minor issues in Flixel setting xy and not left top

[burnt dune]

I don't ever set the hidden property directly so it's weird that it's out of sync

at least not in the handleVisibility function, I'll double check later just incase

[burnt dune]

https://haxeui.org/builder/?5aaeec07

Works fine in the builder

anyone got any idea where in the backend this issue could originate?

[unborn dragon]

I can't find where the discussion was, but why does a container with no children block mouse events to the stuff underneath?

[burnt dune]

#1209142804819869736 message here's the convo area, about to head to bed

but I actually don't know, the general idea is, it's due to using screen events for component level mouse events

so it's either build on top of the existing solution with some kind of mouse helper or convert it to visuals where ever necessary

but I don't actually know if the above options are required, it might be something simple as well

I've messed with mouse events a lot and current solution was the best I could get going

but I also started it whilst being quite a beginner to ceramic

[unborn dragon]

Ok for the time being, I can just remove the check for components above this and I'm good. Will have to see if that affects any composited containers tho

I think using screen pretty much forces you to either more precisely hittest everything in the depth-sorted displaylist per frame or have some kind of static eventWasHandledPleaseIgnore assuming that components will see the event in order of their depths

But then not using screen forces you to either draw roundrect/9slice/etc manually or figure out a way to unify all the Base classes

With drawing them manually seeming like the baseline across the other backends

[unborn dragon]

The most recent commit doesn't display my Stack/ScrollView/Grid container, with the last line here being the issue

I'm not sure which level of child it's happening at in my project, I can dig further if needed

[burnt dune]

dang, I thought there was something buggy with using active there but couldn't find it

it solved another issue

[burnt dune]

There's defo a bug here, but I don't think it's the bug that you were expecting

it seems to be handling click throughs fine

seems to work the same in current version, not sure what the actual bug was meant to be

[burnt dune]

do you have a simple builder repro for the problem? I thought logo did, but it doesn't

I can't repro the click through problem myself

[burnt dune]

weird depth issues again 🙃

maybe will come back to it later

but at the very least mouse handling seems to be correct

maybe I accidentally fixed it after logo reported the issue, msg are you on latest?

[unborn dragon]

I had a button covered by an empty vbox with a defined w/h

I was on latest yeah, can test later today

[burnt dune]

can you try latest commit and see if the issue still exists, might actually be a super simple fix, changing the order of this just solved an issue in my app

[unborn dragon]

Yeah I can try tonight

[unborn dragon]

This fixes that issue, or at least doesn’t cause it to happen yeah

I didn’t dig into why bc that’s a little weird the order matters

[burnt dune]

nice!

[burnt dune]

I think it makes sense from ceramic's viewpoint, no idea why i never thought about it before

but I suspect toggling visible on an inactive visual is redundant in ceramic's eyes, so it probably just returns

[unborn dragon]

Ohh

[burnt dune]

yeah, i picked up on it when i setup a sliding draw that you could toggle with space bar, it went something like
> open fine > space > close fine > space > white box(?) > space > close fine > space > open fine

something about that particular sequence made me immediately jump to that section of the code

[burnt dune]

I've just pushed an update to the backend that requires the latest haxeui-core

[unborn dragon]

That's implied for using libs like haxeui and heaps lol

I PR'd an addition to style handling, honestly didn't even notice it existed until today

There are others in that realm that can maybe easily be added as well

[unborn dragon]

The spot in componentimpl where you handle the tint filter, do you think that’s the best spot to add/handle filters that require shaders?

I want to add saturation and hue rotation, and it doesn’t seem like ceramic has something shader-adjacent like flash’s color matrix filter

[burnt dune]

can be there or somewhere else, i don't particularly mind. i did consider having a seperate class just for neatness but that's also not necessary

[unborn dragon]

I guess I’ll see, I just don’t know about the management side of the filters, being removed and not double added etc

[burnt dune]

its fine, any mistakes or whatever i'm not really fussed

i haven't messed with shaders much in ceramic or much at all

[unborn dragon]

Maybe needs a better asset handler 😂

But this works

[unborn dragon]

I'm dumb and realized I just want to set the hue of the image and not rotate the existing value, so I need my own shader anyway

[unborn dragon]

https://github.com/Jarrio/haxeui-ceramic/issues/16 Made the issue, thought I did before sorry

[burnt dune]

just curious, what happens if you turn off pointer events

on the empty vbox

[unborn dragon]

Can check later but would it disable events for its children?

I pretty much only use absolute, so I can have things all over the place leaving huge empty spaces

[burnt dune]

I'm not sure how haxeui would handle it, but, the behaviour currently is 'expected' I think, not 100% sure. Could you try immediately returning false in componentimpl for the function that checks if there's components over something - the source of the behaviour is likely there

[unborn dragon]

I mean I currently have those checks deleted, which is back to “click through all objects”

It mostly works for me since I don’t have overlaps, but the mouse out thing still persists

It’ll be a while til I can get to my PC tho

[burnt dune]

dw about it

[burnt dune]

now that i'm smarter with my haxeui and indirectly ceramic knowledge

gonna see if i can sort out some of these issues in the ceramic backend

got some ideas that i never had before to fix some things 😄

[burnt dune]

Before depth change^^^

haxeui ceramic depth working solidly now 😄

at least before i check whether logo's keyboard editor breaksdown 😅

@edgy mason https://github.com/TheKeyboardEditor/TheKeyboardEditor can you recompile so i can test pls

gonna see if i can avoid the screen events here as well now

but i can't seem to repro the issue ya'll are saying

[burnt dune]

i'm clicking whenever mouse is still and the underlying components aren't activating

so that's working correctly i presume?

[edgy mason]

lemme try rebuilding

[burnt dune]

hope its good 🤞

[unborn dragon]

Still haven't gotten a chance, but a test case for me would be to put a button at 0,0 and 400,400 within an absolute and then a button underneath that at 200,200

[burnt dune]

oh wow.... its been so long since i've seen my app 😭

my app seems to be working with the new depth change which is promising but i do think logo's app plays more with depth than mine does

[ember plaza]

What did you change regarding depth handling?

[burnt dune]

https://github.com/Jarrio/haxeui-ceramic/commit/0eac50f4732965515e2d3b9e88b03916a435e426 simple 😄

The reason i never thought about this before was i just didn't understand how haxeui manages its own depth

now i understand that, syncing the two up is extremely simple

[ember plaza]

Now I’m curious how depth works in haxeui

[burnt dune]

haxeui just tells the backend whether the component should be placed at the bottom or the top of the depth hierarchy

The functions just returns an int, named index so that wasn't something that is "obvious" without some experience 😄

[burnt dune]

what's supposed to happen?

button above presses the button below?

https://haxeui.org/builder/?25e4f95f

?

[unborn dragon]

You can press all 3 buttons since they don’t overlap

Right now you can’t press the middle one since it’s covered by the container

[burnt dune]

OHHHHH I think I understand the oversight with logos issue. It fails outside of haxeui land

[unborn dragon]

No boxes and no width height, just buttons of the default size

[burnt dune]

I think that would be expected behaviour, especially with a recent convo with jeremy I had

[unborn dragon]

With two in an absolute above the 3rd one

[burnt dune]

but its hard to guess without an example of what the issue is

[unborn dragon]

But the container is empty, and the other backends process the click on the “covered by invisible” button

If there were actual contents in the container at that location, it should intercept the event

[burnt dune]

please give a simple builder example when you can, its hard for me to figure out what the issue actually is and it doesn't really make sense to figure it out when the example is like less than 10 lines of xml

logos issue at least can't be solved without dropping down to local events though.... will see if i can get that to work now

oh hey... what do ya know... now that depth works it seems like normal visual events are good as well? 🤔

[unborn dragon]

<absolute>
    <absolute>
        <button text="1st" top="0" left="0" />
        <button text="2nd" top="400" left="400" />
    </absolute>
    <button text="3rd" top="200" left="200" />
</absolute>

My GH issue is that mouse events should not go through any solid components, should go through invisible parts of containers, and should dispatch mouseOut when the component is removed

[burnt dune]

2nd part should occur - yes

1st part need to play with it a bit

it does work on the builder at least

[burnt dune]

This example works for me locally

[unborn dragon]

Ok cool, it didn't work before and it did work when I removed all the overlap hittest checks, and I assume you still have those in place

Oh wait I'm dumb, the button should be before the absolute

<absolute>
    <button text="3rd" top="200" left="200" />
    <absolute>
        <button text="1st" top="0" left="0" />
        <button text="2nd" top="400" left="400" />
    </absolute>
</absolute>

[burnt dune]

all buttons are getting pressed for me currently, maybe it was funky depth things going on

I have the latest commit on haxeui-ceramic running currently, so no mods, stashed the quick changes to see if local mouse events worked

[unborn dragon]

Does the example make sense? When I said I was away from PC I meant for a while lmao

[burnt dune]

it does make sense why something like that would get blocked

[unborn dragon]

The other thing I was thinking was if there was a ceramic property that would make something transparent to mouse clicks until it gets styled, so a container wouldn’t block unless you actually give it a background

[burnt dune]

I think i did actually add that

[unborn dragon]

Oh ok

[burnt dune]

i mentioned it when talking to logo

but, you should also try the haxeui css pointer-events: false and see if that achieves the effect

not sure if that would absorb events though

ironically, if we switch to local visual events, it might 😄

at which point, ceramic's visual.touchable prop may actually work fine for you as well 🤔

[burnt dune]

ahhhh, my local solution was pausing events

not something official

okay, so here's why i used screen events i think. If you notice in areas where you'd expect to be able to click on the component

You can't click on it

so I couldn't open the colour picker by clicking on the black rectangle

had to touch the grey part

item 1 buttons text "absorbs" the interaction as well

it works in places and doesn't in others and I'm not sure how to address that particular issue

I think that's because of how ceramic propagates its depth

it goes to the visual that is on top at the point of the interaction

[edgy mason]

Sorry I forgot midway through doing it. Gimme a bit bahaha.

[burnt dune]

@unborn dragon are you good with this solution?

if component gets disabled, i just switch the cursor back to default

not sure how appropriate that is

maybe applystyle is better

[unborn dragon]

Looks right for my cursor at least, it should still do mouseOut but it helps a lot in the short term

Or, I can't tell if you mean it's dispatching mouseOut now

Once I eat dinner I'll be able to do code 🙂

[burnt dune]

its not dispatching mouseOut, because haxeui removes the event

            case MouseEvent.MOUSE_OUT:
                if (eventMap.exists(MouseEvent.MOUSE_OUT)) {
                    screen.offPointerMove(_onMouseOut);
                    eventMap.remove(MouseEvent.MOUSE_OUT);

                    if (Cursor.current != DEFAULT && disabled) {
                        Cursor.lock = false;
                        Cursor.setTo(DEFAULT);
                    }
                }

so i just added this to the unregistering of the event here

not sure if ideal tho

it works functionally at least

does mouse over still trigger?

seems odd to unregister one and not the other

[unborn dragon]

I guess in openfl's case, mouseOut happens by default since haxeui is using its native mouse handling

[burnt dune]

wow it does, this might be a haxeui-core oversight

seems odd to track mouse over but not mouse out for disabled components

if anything, you'd want the opposite - no?

[unborn dragon]

Over should still go so you can track that something is blocking whatever is underneath, though it should just absorb the event

[burnt dune]

so gotta handle components removed cursor thing as well

[unborn dragon]

And then I think it's more "not over" instead of "out" once you mouse away from it

[burnt dune]

but that leaves an internal state of oddness because there's nothing really to flip the flag back to "not over"

I guess i can just hittest that locally cause #screenevents

ahhh, that's weird then....

[unborn dragon]

Right so openfl internally keeps track of the one sprite that's currently over, so haxeui is more or less outsourcing that to the backend

[burnt dune]

ceramic has that as well actually

I think that's tracked in App.app.screen

oh just saw openfl's cursor code

@unborn dragon not sure how to repro the cursor not changing for removed components issue

[unborn dragon]

Mmm I guess exactly what I'm doing is changing the index in a stack, so it may be a hidden thing instead

Not sure how that container works

Like hiding the button onClick instead of removing it

[burnt dune]

well pushed the fix for the disabled components and will wait for you to confirm whether the absolute issue is solved

also, will be nice to confirm if the depth stuff messed up your project in anyway

[unborn dragon]

I haven't had an issue with depth at all but yeah I can pull the latest

[burnt dune]

yeah, the depth issue was fine in most places just wasn't in all

now i think it should be rock solid in all places

[burnt dune]

booooo i thought you did it here and just went to check 😭

I think with that though, i'll head to bed

why 🤔

it compiles fine for me locally?

[edgy mason]

@burnt dune Recompiled and works for me, no real new behavior or fixes that i can see

dropdown icons might be broken?

[unborn dragon]

Cursor stuff looks OK initially, but I do have to move the mouse to make the change take place which may be a ceramic thing

[burnt dune]

can you try latest, took a guess - it works for me locally in a dropdown in my app

[burnt dune]

pushed a change, turns out you can handleDisabled directly in the backend - change is immediate now

[burnt dune]

hm... why are a lot of thet tabs not found?

so do you still have the window issue?

[burnt dune]

pushed another change, got fancy with it 😄

[burnt dune]

also, msg, can you confirm if https://github.com/Jarrio/haxeui-ceramic/issues/16 is fixed?

[edgy mason]

no change, see the color tab here: https://thekeyboardeditor.github.io/TheKeyboardEditor/

[burnt dune]

what should i be seeing?

[edgy mason]

this is a dropdown, it should have an arrow

[burnt dune]

I think it's a haxeui problem

[edgy mason]

hm?

[burnt dune]

https://haxeui.org/builder/?a6b8d4d2

i'm getting a null reference locally so app might be crashing before it can load an image

[edgy mason]

this looks wrong lol

[burnt dune]

yeah, there's a **problem** somewhere in core

I recon if that error gets fixed the dropdown will work

in ceramic i have the exact same outcome

very satisfying to see a catastrophic failure look exactly the same in both backends x)

[edgy mason]

baha

[burnt dune]

what about mouse events are they still not working as expected?

[edgy mason]

my primary issue was interactions between ceramic objects and haxeui components

[burnt dune]

yeaaaa, i figured. if you have any ideas on how to address this issue in ceramic i can switch it over to using local space

in skia, i bubble the events so it works fine for me

in ceramic i can't bubble the events because the way to intercept is done via inheritance, at least that's how I understand it

unlesssss..... i add a remote flag for interception that i can toggle and then map that in the backend eventimpl 🤔

i will try that!

[edgy mason]

🤞

[burnt dune]

ahhh i don't think it works in principle actually

because the propagation is tied to the visual rather than the event

maybe just confusing for me to think about

yeah that idea doesn't work

same outcome

will try a different approach...

is there a way in ceramic to know if something actually wants to listen to input events?

[edgy mason]

I think tracker lets you do something like .listensEventName()

[burnt dune]

the issue then becomes is how do i tell visuals outside of haxeui to not receive the event

orrr, how do i tell haxeui when certain things should trigger... another idea just popped up

nope, no clue how to do it

there may be some tiny little detail about how this stuff works in ceramic that i'm missing

best thing to do is just use haxeui's built in pauseEvents and resumeEvents setup - sorry I don't know where to go with that one :/

[burnt dune]

i'm confused about where these arrows have gone

[burnt dune]

@unborn dragon its been a lil bit, everything still working fine?

and are the problems all fixed

[unborn dragon]

Didn’t do much this week but no issues so far ✅

[unborn dragon]

Mm I did stash some changes, I should make sure that’s just the filter stuff and not anything more

On that note, I think it’s most appropriate to have the custom filter handling as another backend defined callback. Like a lazy customFilters(name, params) or something

So I’ll pr something for that soon

Not sure if here or in core though

[unborn dragon]

I readded my game border which has the spread out buttons, and I can click things underneath that layer without issues

I don't have any overlapping sprites is the only thing, to see if that works or not

Uh but might have that issue with the first itemrenderer being unclickable again... have to see if that's some other problem or not

[burnt dune]

interesting? i'm sure i tested it with a dropdown and it was fine

will try in my project where that failed in the past

[unborn dragon]

It was responding to hover events but not click

So like without looking at any code, maybe only click events are being blocked and hover events pass through to every object your mouse is over?

[unborn dragon]

Do you get this on cpp (Windows) builds? I updated my ceramic and linc libs, and I see that function in the .h and get code completion for it as well

Mmm I get a bunch of other similar errors after restarting my editor, so I'll ask in ceramic

[burnt dune]

before this, try a clean build (just in case)

[unborn dragon]

Like --clean or deleting the cpp project folder?

[burnt dune]

deleting the cpp project folder

all of them

[ember plaza]

and the out/ dir

[unborn dragon]

Yeah there's nothing in the project folder

[burnt dune]

because i tried ceramic build of my project app within the last week and it worked fine

[unborn dragon]

Let me try out

[ember plaza]

and your .haxelib 😄

(if you moved where ceramic is installed)

(the local one in your project)

[unborn dragon]

Will .haxelib get regenerated based on the yml definition or something?

[burnt dune]

yeah

my app compiled but i am running a git version of ceramic iirc

[ember plaza]

Yes, if your project is not doing anything hacky it should just regenerate everything on next build

[unborn dragon]

I did manually dev to my main haxelib for haxeui and some stuff

So looks like I have to readd that

[ember plaza]

You could specify a path in your ceramic.yml for those:
https://ceramic-engine.com/guides/ceramic-yml-reference/#haxe-libraries

[unborn dragon]

Same issue but I'm noticing now the error is coming from clay/src/clay/sdl/linc/ but my .haxelib references ceramic/git/linc_sdl

[ember plaza]

Mmmmmh, linc_sdl has been removed since it moved to SDL3

If you updated ceramic from git, you need to rebuild the tools

[unborn dragon]

I was gonna ask about that next lol... I did npm ci within runner, but there is no package-lock or whatever inside tools anymore so that section didn't do anything

Or post-install.js

[ember plaza]

node tools/install

[unborn dragon]

Ohh right

[ember plaza]

I really need to update those docs 😅

[unborn dragon]

I will PR it now lol

Actually I'll just make an issue since there's other node stuff in here too that I think isn't relevant anymore

I'll make a note, if you can comment on what changes are needed for the first installation section, I can PR it.

Ok it's zooming through c files so looks like it's all good now, thanks!

[burnt dune]

i think with sdl3 the cursor change don't work

so it'll just be a normal cursor if it compiles

[unborn dragon]

Least of my worries, will be trying out tracy to see if all my css usage is causing visible delays or if it's something else

[burnt dune]

nicee, its probably a simple fix anyways

just mapping to whatever the new sdl3 cursor enums are or something

[unborn dragon]

@burnt dune did you have to do anything special to get tracy working? I updated haxe and all, but it's not seeing cpp.vm.tracy package

I see ceramic/tools/build/include/cpp/vm which does not have the tracy stuff, but not sure if that's getting used over haxe

[burnt dune]

ceramic bundles its own haxe and probably won't have it available, you can shadow it into your project or put it in the ceramic bundled haxe

[unborn dragon]

Oh I didn't even notice that

[burnt dune]

i can't remember if more was needed

[unborn dragon]

Yeah I can work with that, thanks

[burnt dune]

if so, maybe just dupe the ceramic haxe folder and copy the tracy haxe in its place, may have some minor issues to fix

[unborn dragon]

Adding the "breaking changes from 4.x.x" versions of haxe and std into ceramic is not the move 😵 luckily the tracy stuff is a single file I can add in

[unborn dragon]

This is where I'm at for my filter support. Only creates a new one if it needs to

Ceramic being limited to single shaders is nice here bc I don't have to manage anything but a string

[burnt dune]

@edgy mason can you trigger a rebuild of keyboard editor at some point

Just pushed a bunch of changes to haxeui-ceramic, and seems good in my stale project

@unborn dragon lemme know if its good for you as well if you're fearless 😄

[edgy mason]

Rebuilding now

glad you are still maintaining this

[burnt dune]

the minimum goal for me was always to leave it in a "base state that's workable"

simple things like borders not working isn't really great imo

if the foundational things are solid, then i can relax a bit on the polish things like filters

[edgy mason]

https://thekeyboardeditor.github.io/TheKeyboardEditor/
Seems like the cursor in inputs are missing

not sure if that was always broken or not

or if it is just a tke thing

[burnt dune]

i'm not sure if i ever had cursors in inputs

[edgy mason]

it isn't particularly the best developed thing lol

i thought you did

[burnt dune]

maybe, my haxeui memory stack is diluted with skia/simple stuff

[edgy mason]

I would like to play with simple at some point, it seems really promising

[burnt dune]

i did change cursor things here, but i don't think i did anything that would remove cursor rendering 😆

[burnt dune]

still lots of polishing and stuff to be done but i've done a lot of cool things i couldn't tackle on ceramic

[edgy mason]

i meant the little vertical line, not mouse cursor for the record

[burnt dune]

oh, i'm not sure about that, i actually have a similar thing in simple wher i have no idea how to handle cursor styling

it isn't straight forward as its background dependent

but haxeui doesn't expose a text input cursor style afaik

i've got the main loop throttling working in simple stack, so app doesn't spin like crazy

wakes on events

IT SHOULD be pretty okay to build a mobile app with the simple stack theoretically, but, its still pretty early days

[edgy mason]

once i finish lotl, i would like to make a more minimalist component library for haxeui

[burnt dune]

but short term target is to not have my main project eat through a laptop battery

i think that's a fair checkpoint to aim for in the mid term

[edgy mason]

yeah, ceramic tends to do that

[burnt dune]

@edgy mason

I'm so happy with that cpu usage behaviour

you can see how various things like input events etc will make it work more or less

even the text input cursor will bump it up slightly

[edgy mason]

is the box plot implemented in a higher level api or is it just skia?

[burnt dune]

all chart stuff is implemented on top of my simple framework

so seperate from haxeui

[unborn dragon]

Yeah no issue, I actually forked and got rid of a bunch of stuff 😅

Streamlined backend just for my use case

[burnt dune]

curious, what did you get rid of? and what was the motivation?

[unborn dragon]

I made the base class a ceramic object and then removed your Base since I only ever need one thing

[burnt dune]

i did have a look around over the last hour or two and was hunting for things to cut but couldn't really see much

[burnt dune]

Lmao i get it 😂 Was something not working to make you do that?

[unborn dragon]

I’m trying to remember, I think it was something mouse related and it was faster to delete than try to fix

Maybe with overlapping sprites iirc

[burnt dune]

lol i forgot about that issue i wonder if i fixed that

[unborn dragon]

I think I tried working on it, but keeping everything that I don’t use working was a lot

[burnt dune]

yeah its fair

each task is basically its own visual

i simplified the setup a bit by having a single visual for it and just cast by type

[burnt dune]

assuming this was the actual repro, it seems to work now

[unborn dragon]

I’ll take a look in a bit. I’m also remembering the first itemrenderer in a container would get its mouse events stolen by the dummy one

[burnt dune]

hmmmm

[unborn dragon]

But I think it ended up being related to the overlapping sprites

[burnt dune]

<listview id="lv2" width="200" height="150" selectedIndex="1">
                        <item-renderer layout="horizontal" width="100%">
                            <checkbox id="complete" />
                            <label width="100%" id="item" verticalAlign="center" />
                            <image id="image" />
                        </item-renderer>
                        <data>
                            <item complete="false" item="Item 1" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="true" item="Item 2" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="true" item="Item 3" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="false" item="Item 4" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="true" item="Item 5" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="true" item="Item 6" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="false" item="Item 7" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="true" item="Item 8" image="haxeui-core/styles/default/haxeui_tiny.png" />
                            <item complete="false" item="Item 9" image="haxeui-core/styles/default/haxeui_tiny.png" />
                        </data>
                    </listview>

something like this example?

this one at least seem to be working fine

border styles should be more reliable now as well™ (i've defo said that before 😅)

[burnt dune]

besides the text input cursor is anything else look over?

I can't see anything myself

https://github.com/jarrio/haxeui-ceramic why does the ci come up off here

WARNING: no class found for component 'vbox' in '../../assets/main.xml'
WARNING: no class found for component 'box' in '../../assets/main.xml'
.haxelib/haxeui-core/git/haxe/ui/macros/ComponentMacros.hx:326: characters 50-52 : Unknown identifier : c0
./src/Project.hx:26: characters 16-66 : ... Called from macro here
.haxelib/haxeui-core/git/haxe/ui/macros/ComponentMacros.hx:348: characters 70-83 : Unknown identifier : c0
./src/Project.hx:26: characters 16-66 : ... Called from macro here
Error when running clay build with target web. (status = 1)
Error: Process completed with exit code 1.
weird error in the logs

[edgy mason]

Hm interesting

seems like ci has been broken since nov of 2025