@rrraptor , i've realized that this code actually triggers snapping not only when the window is dragged but when any mouse dragging happens. this is a waste of resource (and also sometimes it moves the window when it is partially out of the screen, that's how i noticed the issue. i don't know why yet - EDIT: it's because // is different for negative values). in any case how can i know that a window is dragged (or resized)? EDIT: for the resize part there is the callback, so that's fine. only the drag move is a question. EDIT: i've noticed that this version also has the issue that if i only drag the window only slightly then it does not set 'isMouseDragging' to positive and therefore the window is not snapped at all. - to correct this i can change the first line to local dragFlag = self:isMouseDown(KeyCode.MOUSE_LEFT) but then it is an even more waste of resources.
thanks, looks good, i will check. actually there should be an event when moving is finished, it still seems to be a waste to compute the snapping point all while moving the window even though only when it is not moved anymore it becomes relevant.
@rrraptor , if you remember those issues with 'triangles in top right of items', it is still wrong in new version. i still need to do this workaround of yours:
@rrraptor , i want to make color buttons in a palette to be sources for drag'n'drop but they should not be targets for drag'n'drop. how can i do that? thanks
@rrraptor , if you remember those issues with 'triangles in top right of items', it is still wrong in new version. i still need to do this workaround of yours:
@rrraptor , i want to make color buttons in a palette to be sources for drag'n'drop but they should not be targets for drag'n'drop. how can i do that? thanks
@rrraptor , about the colorbuttons, isn't it possible to send the 'regular colorbutton payload' from such a custom color button, so that i need only to redefine the 'non-target' color buttons and can leave the rest as they are? (also the dragndropped thing is a bit different for default color buttons, but i can probably recreate their look).
i got the following crash: [1355] ../Common/imgui_src/imgui.cpp: mouse_button >= 0 && mouse_button < ImGuiMouseButton_COUNT when calling: IO:setMouseDown(event.touch.mouseButton, true) (where event.touch.mouseButton was what i got by some touch event) in a windows exported exe when i used an app called superdisplay to use my android samsung tablet and pen as a display/drawing tablet for the window device.
@rrraptor , sadly the 3 day trial of superdisplay expired and i did not check what was the value. in any case it should not crash even if an unexpected value is received.
what is the difference between IO:setMouseDown(event.touch.mouseButton, true) and IO:addMouseButtonEvent(event.touch.mouseButton, true) ?
so i've found another very similar app (called easycanvas). there if i touch the screen with my finger on the android tablet (connected as a screen to my windows pc using this app) then it crashes the same way. i added a print just before the crash line and event.touch.mouseButton is equal to 0!
EDIT: so knowing this i could do a workaround to change the value to 1 whenever it received 0, but it would be great if 1. gideros would recognize the 'button' correctly 2. imgui would not crash even if it gets an incorrect button value
Comments
Is it possible to fix it somehow?
With anti-aliasing (80 nodes, ~1140 triangles each):
Without (90 nodes, ~500 triangles each):
In both scenarios I have artifacts even though In a second test I have significantly less triangles
Fragmenter - animated loop machine and IKONOMIKON - the memory game
87k triangles, 80 nodes - artifacts
Maybe it is the vertices...?
https://github.com/ocornut/imgui/blob/268565079c56600c197602683391a1bc8afba014/imconfig.h#L94
So the question is: do we have vertex offset support?
Likes: MoKaLux
800 nodes:
Performance is bad, but no artifacts ^^
Likes: MoKaLux
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux
EDIT: for the resize part there is the callback, so that's fine. only the drag move is a question.
EDIT: i've noticed that this version also has the issue that if i only drag the window only slightly then it does not set 'isMouseDragging' to positive and therefore the window is not snapped at all. - to correct this i can change the first line to local dragFlag = self:isMouseDown(KeyCode.MOUSE_LEFT) but then it is an even more waste of resources.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
actually there should be an event when moving is finished, it still seems to be a waste to compute the snapping point all while moving the window even though only when it is not moved anymore it becomes relevant.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: keszegh
isHoveringFlag = ImGui:colorButton(string_ID, color [, alpha = 1, ImGui.ColorEditFlags =
0, w = 0, h = 0])
here actually the order of the last 3 param is w,h,flags, isn't it?
Fragmenter - animated loop machine and IKONOMIKON - the memory game
(also the dragndropped thing is a bit different for default color buttons, but i can probably recreate their look).
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Fragmenter - animated loop machine and IKONOMIKON - the memory game
[1355] ../Common/imgui_src/imgui.cpp: mouse_button >= 0 && mouse_button < ImGuiMouseButton_COUNT
when calling:
IO:setMouseDown(event.touch.mouseButton, true)
(where event.touch.mouseButton was what i got by some touch event)
in a windows exported exe when i used an app called superdisplay to use my android samsung tablet and pen as a display/drawing tablet for the window device.
Fragmenter - animated loop machine and IKONOMIKON - the memory game
This is a function that converts gideros button to imgui buttons: https://github.com/MultiPain/Gideros_ImGui/blob/61cc4dc35111fb2f91325c875c1021f1acb1aad7/main.cpp#L726
So, available values are: 1, 2, 4, 8, 16
"button" is any ImGui mouse button (check here)
what is the difference between
IO:setMouseDown(event.touch.mouseButton, true)
and
IO:addMouseButtonEvent(event.touch.mouseButton, true)
?
Fragmenter - animated loop machine and IKONOMIKON - the memory game
EDIT: so knowing this i could do a workaround to change the value to 1 whenever it received 0, but it would be great if
1. gideros would recognize the 'button' correctly
2. imgui would not crash even if it gets an incorrect button value
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux
Fragmenter - animated loop machine and IKONOMIKON - the memory game
addMouseButtonEvent allows you to add mouse inputs directly to imgui: https://github.com/MultiPain/Gideros_ImGui/blob/61cc4dc35111fb2f91325c875c1021f1acb1aad7/main.cpp#L10114