-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wires drawing, port from OF to ImGui #19
Comments
First port testing, i have the wire drawing fine, but canvas translation/zooming doesn't update on ImGui bezier cables. I'm updating the link points using the same coordinates as the actual links (OF): PatchObject->outPut[j]->linkVertices.at(i).x/y It seems something related with some offset between ImGui canvas and ofxInfiniteCanvas canvas? |
I'm wondering what the issue was. Issues that I could think of, or you might run into :
|
The issue was a mistake i made, i forgot to scale and translate the link start/end points by the canvas ( canvasView.scale and canvasView.translation ) Now it's working real fine, with negative position too! |
Btw, did you see the pin drag/drop (Gui only, very basic) feature ? (drag/drop pins, yellow border) |
Yes, i've already added there the dragging from outlets creating link! Did you know how to change the border yellow color? I'm not finding it... |
I think it's |
Thanks, i didn't checked the new style vars from imgui 1.75! ImGuiCol_DragDropTarget did the trick! And i've added the missing vars to MosaicTheme |
Just pushed a commit with this issue solved: d3cod3/ofxVisualProgramming@c34b226 Try it a little, and confirm me it's ok to close this issue! |
Looks good. The points you describe work nice although I found some small things.
|
About the mouseoffset on the dragging pin, i couldn't solve it as you suggest, using your hack in this case (wires are been drawed in canvasDrawList, outside the node) will result in having the end of the wire overlapping fine with the pin drag center, but the mouse pointer still displaced a little on the left. Now, i've tried to invert the hack, and set the invisible button position on the pin, without the displacement:
instead of:
but then the dragging stop working. I'm still on it, considering other solutions, but i have a question, the needs for a data payload managed from imgui is really necessary? we have now all the data communication managed from ofxVP, what can improve having this payload management inside imgui? Anyway, i'm apply some hacks to have the offset problem solved, for now.
|
For the cursor offset, you can leave it like this and I can have a look later, if you wish. Do you work with the Metrics window to inspect Window Regions, content zones, etc. ? Sometimes graphics draw outside of regions but interaction zones are cropped/inactive. Agree for the theme and resizing. Sometimes it's just easier to be able to resize it manually, in case automatic sizing doesn't work / anything; I like to preserve the possibility. As you said, most objects won't need it. I guess we can go for MinimumSize by default, objects [can/must] set their custom size, non resizable by default, but they can enable resizing. I agree for minimalism/simplicity/dataflow-logic too (I don't know the old MaxMSP very well) but sounds good to improve accessibility. To be continued in #20. About your question, I don't completely understand what it's about; could be easier with example code. The ImGui pin callbacks are pretty simple and minimal template to work with drag&drop interaction, we can easily map them on ofxVP(parameter?) internals, even on compile time. I'm not sure this is what bothers you... from my point of view we're almost there. // All this will probably be managed by the upcoming parameter class.
// Tell ImGui there's a drag source with of dataType X, with a getter to the data
ImGui::SetDragDropPayload(Object.pins[0]->Data.typeID, &Object.pins[0]->Data.ID, ... );
// Accept dragged data of type X
ImGui::AcceptDragDropPayload( Object.pins[0]->Data.typeID );
int dataID = memcpy(...); // get ImGui drag data
ofxVpObject->connectWith( getParamOrPin(dataID) ); // Instruct ofxVP to connect Another question, the |
OK, now i understand it better, so the idea was to switch to imgui to manage the connection or the "data communication" (i didn't explain myself fine). So i'm going to add more items to the check list here. Basically:
instead of the original:
but it's a temporary hack, we'll need to fix it properly, together with the mouseoffset position probably. And last, about
They are temporary, i added them as you're using the same overwriting var for the different pins positions, continue... |
I'm having an issue with drag and drop mechanism inside imgui_node_canvas, i have implemented a re-connect logic (clicking on a previously linked inlet, the cable detach and it can be re-linked on another inlet pin), is working perfectly from one node to another, but not trying to switch form an inlet to another of the same object. I'm missing something, BeginDragDropSource and BeginDragDropTarget code blocks should work on pins in the same object? or not? Implemented and working:
I would like to add disconnect from clicking the inlet on the link and dropping it on the canvas (outside any object), i've tried a lot of combinations, but none worked, do you have some suggestion? |
I also noticed something like that where drop targets don't accept drag sources in the same window. This sounds related, probably ImGui not triggering drag/drop properly. I have no idea why it acts like that but thought it would not be problematic, now it is. Neither do I know if this behaviour is normal in ImGui; looks like there are no specific flags for controlling this behaviour ( |
Ok, i'll leave it like that for now, basic functionality is running fine, i've tested it all day and fixed some bugs, i'm going to clean some code now and commit the changes. d3cod3/ofxVisualProgramming@faf6c56 I'm leaving the ImGuiDragDropFlags_AcceptNoDrawDefaultRect flag commented in order to see the yellow rect of the drag and drop mechanism, to fix the inlets drop area rect position. Test it when you can, i'll wait for feedback |
Got some time for testing. :) (Mosaic 0.4.0_master)
Small details:
|
About the menu, let's talk about it and put on the table design proposals, but i need to close this quickly, in September a course will start and we'll need to have the documentation ready with the new Mosaic interface by end of August. About the label in the middle of the cable, that was my choice, after trying it on the mouse cursor, because when near the supposedly connecting outlet, the label of the outlet will overlap with the label of the dragging cable. But i'm open to suggestions and to try different designs ( this too we need to close it soon for the same reason as above ) At small editor zoom scales, we can disable the pin hover, is not useful anyway to connect stuff when is too small About the outlet cables, i think it's because the positions are managed from OF, and by default Mosaic refresh at 30 fps, while imgui at 60, but you can change that fro main menu -> System -> FPS |
Well, for the node parameters gui, I see 2 options :
I don't know about September, the work on the table keeps expanding :p Didn't think about that for the labels in the middle. Lets keep it like this ? |
Ok then, as i see it we leave the node parameters gui in the menu for now, is working fine and do not mess with the patch as the old config button, then, when the Inspector will be ready, we'll switch from the menu to the Inspector, including we can maintain both if we prefer it. Doing that, i'll be able to prepare the docs for next course, and we'll be able to continue working without rush. |
…etails below --] 1. ImGuiExNodeCanvas ported to engine-tester for better testing. Integrates ImGuiExNodeCanvas so test-objects have the same mechanisms as mosaic-objects. 2. Breaking changes to ImGuiExNodeCanvas : Simplification (and rewrite) of the nodePins & nodeConnections mecanisms. Optimises and fixes issues on ImGui api calls, specially drag&drop. Warning : No more objectID and pinID in imgui namespace, only pinUID. This is also a new pin interface proposal / tryout (easily reversable). Main visual difference: The inlet disconnect becomes a reconnect. Labels are rendered on other locations. To be discussed in d3cod3/Mosaic#19 3. Parameters : Fixes a linkType variables glitch that messe everything up, injecting unalloated memory blocks. Also started adding some asserts to prevent writing incompatible code. Adds some utility methods to speed up writing redundant code.
Hey, I ended up rewriting the nodeCanvas technically (see link above), which also led me to play with graphical changes. UI Changes
It isn't perfect now and doesn't match your left-to-right logic. |
About the UI changes, i like the link label moved to the right end of the cable, it looks fine, but i do not like the pins label being drawn inside the node window, it overlaps the node content and make it visually messy, i prefer to have the node content always clean and with the best visibility. The native ImGui Hover on the invisibleButton was giving me some problems, don't remember now in details, but i remember that i opted for the pin distance because solved those problems, anyway, is during testing we didn't find any quirks with that, it doesn't really matter using one or the other. I don't imagine right now the left/right click interactions with pins, but everything useful is obviously welcome, as doesn't affect user interaction, it's really important for this project to maintain the simplest usability as possible, because one of the core point of Mosaic idea is to have a software that can be used by someone with zero experience, after one hour introduction, as by an experienced programmer/artist/performer building his/her complex patches for live sessions. An extreme example could be blender 3d software, is an amazing piece of software, but is really hard to learn, with millions of things to configure, while Mosaic aim at exactly the opposite, lot of possibilities with a really simple and visually clean user interface ( the PureData concept i've talked about some time ago, but not so extremely minimalist ) I'm seeing in the gif something that we'll need to fix, when connecting, a see that the receiving inlet param goes gray ( deactivated ), that is obviously for the loop problem, but visually we are interrupting the dataflow, because while the origin param is changing, it will not reflect those changes in the nodes chain. We'll need to find a solution for that, even if that means to make a pointer copy ( as it is right now ), or substitute the editing param for a simple not editable text when the inlet is connected ( instead of graying it ), but that will not solve the issue for other data cables as textures or sound buffers or vector, etc... Anyway, great work, i think that probably the most difficult part is already done! |
Thanks for the exhaustive feedback. I agree with the idea of simplicity, I'll continue to play around keeping that in mind. :) For the pin distance we'll keep the invisibleButton, the more native code the better. Ftr, the problem (before) was that we didn't The label position to the end of the cable is nice, and that's also why I put the label in the continuity (right side) of the pin. So when you drag, the connecting label is on the left of the pin, the connected label on the right side of the pin. About the greyed-out pin (red), in the gif I made all links white so there's no colour distinction yet. So the hovering pin being "greyed out" is not about the endless-loop protection; but about an incompatible variable type, indicating you cannot connect it. Edit: Oh I misunderstood the greyed-out param. Indeed it's gray=disabled, a question of not mapping Another point I'm not happy with is that params and pins are not horizontally aligned; you have to hover the pin to know which one you're grabbing (or count their nth position in both lists). While this is very modular, it's interfering with the data-flow logic; don't you think so ? A solution I imagine is to dray them this way on small zoom scales, and aligned to params when zoomed ? (would need some work to implement) |
Great idea about the labeling! So if i understand it correctly, maintaining the "old way" with label outside the node for when hovering pins, and using the "new way" with label inside the node when dragging a new cable and hovering the pin. About the params and pins not horizontally aligned, yes, i agree with you, but if you check all the actual objects, only a small set will actually needs this visual alignment, most of the objects have their pins unrelated with gui parameters Anyway, for the objects that will need it, yes, it will be better to have the pins aligned with the related params ( right now i think the only object with this need is the "constant" object, and as it only have one inlet/param, they stay centered and aligned at every zoom level ) Edit: if we really want to have a solid graphical way of positioning pins and params, we should use here the modular synths approach, as VCV Rack software for example: where connections ( pins ) are near the param control ( knobs in most cases ) this will probably need a lot of work, but we can think about that |
The text was updated successfully, but these errors were encountered: