Wires drawing, port from OF to ImGui about mosaic HOT 26 CLOSED

Finished porting! Just need some code cleanup.

Rendering in imgui + click on wire for selection
multiple wire selection with TAB key
wire remove (all selected) with BACKSPACE key

from mosaic.

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

from mosaic.

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.

from mosaic.

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?

from mosaic.

Previous problem solved!

from mosaic.

I'm wondering what the issue was.
Did you notice that you're drawing to the old positions though, not the ImGui positions.
Notice that addPin(&pos) updates the position. You get the coordinates in absolute window coordinates, the coordinates that ImGui uses everywhere, and they are automatically updated every frame. If you manually update them, there's probably something wrong.

Issues that I could think of, or you might run into :

• The menu offset (20px top) if the canvas is not positioned at [0,0]
• I dont know what happens when positions are negative, below the origin of [0.0]

from mosaic.

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!
Thanks

from mosaic.

• Pins position fixed, as link start/end
• still drawing link creation (draggind from outlet) in OF
• link hover/selection still buggy

from mosaic.

Btw, did you see the pin drag/drop (Gui only, very basic) feature ? (drag/drop pins, yellow border)

from mosaic.

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...

from mosaic.

I think it's ImGuiCol_DragDropTarget or ImGuiCol_NavHighlight, there might be missing variables in MosaicTheme.
There's at least missing colors : ImGuiCol_Separator, ImGuiCol_SeparatorHovered, ImGuiCol_SeparatorActive.

from mosaic.

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

from mosaic.

Just pushed a commit with this issue solved:

d3cod3/ofxVisualProgramming@c34b226

736e7a5

Try it a little, and confirm me it's ok to close this issue!

from mosaic.

Looks good. The points you describe work nice although I found some small things.

• The tab key allows cycling boxes into nodes/windows too, multi select on the same key feels a bit weird. Why not the commonly used LSHIFT key ?
• Dragging a pin, the drag center is too far from the mouse. I've had a similar issue with the header dragging part. ImGui has some weird mousPos() behaviour that indicates the mousPos relative to the pos.Min of the clicked item. Solution: On click, store mouse offset to InvisibleButton and add that to current mousePos in all next dragging-frames.
• In the Mosaic theme, some focus/hover colors change very little, making the node gui harder to understand. Specially for the resize handle. ( ImGuiCol_ResizeGripHovered & ImGuiCol_ResizeGrip )
• There's some weird behaviour with pin connections. Dragging the inlet of Constant drags the outlet. If trying to connect it, it will never connect, although it allows disconnecting the connected outlet to the dragged inlet.

from mosaic.

• tab key changed for SHIFT key

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:

ImGui::SetCursorScreenPos( pinLayout.curDrawPos );

instead of:

ImGui::SetCursorScreenPos( pinLayout.curDrawPos + ImVec2( -pinLayout.pinSpace.x, 0) );

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.

• About the theme, is a wip, i want to maintain a "grayscale" design in general, but of course some details needs changes. But especially about the resize handle, i would like to remove the capability to all the objects that doesn't really need to be rescaled, i think that in design terms this will lead to visual confusion. I really like PD or Max minimal aesthetics, and despite the similarity between Mosaic an TouchDesigner, i would prefer to maintain as much visual order as possible. But this is related to #20 , so we'll discuss it there.

• pin behaviour fixed, drag is available from outlets only (drop only available on inlets)
  This is another "usability design" issue i would like to discuss, i really prefer the PD or previous Max graphical interaction that let user connect stuff in the dataflow direction only (outlets to inlets only), mainly because i think is better for learning and teaching with Mosaic, the interaction follow the logic and reinforce the understanding. We can open another issue if you want to analyze this topic, let me know what you think.

from mosaic.

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.
What is it you call the "data communication managed from ofxVP" ?
This is how I imagine the payload, maybe that helps ?

// 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 outletsPositionOF variables, are they temporary to fit current VP behaviour ? What are they used for in VP ?

from mosaic.

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).
At first, i was thinking to leave that outside imgui, but now i see it, it will be cleaner as you propose it.

So i'm going to add more items to the check list here.

Basically:

1. Add connect/disconnect methods inside PatchObject class (now are managed from outside, in ofxVP class, for example: connect object 4 pin 2 with object 8 pin 0), so i'm going to create internal methods to PatchObject->connectTo(fromPin, toObject, toObjectPin), PatchObject->disconnectFrom(objectID,objectPin) and PatchObject->disconnectLink(linkID)
   The second one will be for mouse re-connect wire from a previously connect one (imagine you have a cable to inlet pin 2 and want to move it to inlet pin 4, or to another inlet of another object).
   The third will be the basic disconnect.

2. Implement the logic inside the imgui DragDropPayload code block

3. Fix the inlet pins drop area rect, i'm experimenting some strange behaviour, especially in objects with more than 4 inlet pins, the drop areas are overlapping and confusing the payload drop, i've just used this for a better result:
   ImGui::InvisibleButton("nodeBtn", ImMax(ImVec2(pinLayout.pinSpace.x,pinLayout.pinSpace.y*.8f), ImVec2(1,1)));

instead of the original:

ImGui::InvisibleButton("nodeBtn", pinLayout.pinSpace, ImVec2(1,1)));

but it's a temporary hack, we'll need to fix it properly, together with the mouseoffset position probably.

And last, about inletsPositionOF and outletPositionsOF vars, i'm using them now to passing the pins positions (already inside imgui code) to the PatchObject update, that is still refreshing the
links start/end positions.
Inside drawImGuiNode():

inletsPositionOF[i] = ofVec2f((inletsPositions[0].x - _nodeCanvas.GetCanvasTranslation().x)/_nodeCanvas.GetCanvasScale(), (inletsPositions[0].y - _nodeCanvas.GetCanvasTranslation().y)/_nodeCanvas.GetCanvasScale());

outletsPositionOF[i] = ofVec2f((outletsPositions[0].x - _nodeCanvas.GetCanvasTranslation().x)/_nodeCanvas.GetCanvasScale(), (outletsPositions[0].y - _nodeCanvas.GetCanvasTranslation().y)/_nodeCanvas.GetCanvasScale());

They are temporary, i added them as you're using the same overwriting var for the different pins positions,
inletsPositions[0] and outletsPositions[0]
and i needed to have the positions stored separately for now.

continue...

from mosaic.

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:

1. connect from outlet to inlet
2. re-connect from previous link (switch link end)
3. disconnect (select link and backspace)

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?

from mosaic.

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 (ImGuiDragDropFlags_*). The demo window implements drag/drop on all color settings, drag&drop works fine there. Eventually it could be a call-order issue but ImGui uses "1 frame lag" to prevent that, so I think not.

from mosaic.

Got some time for testing. :) (Mosaic 0.4.0_master)

• The menu is nice for delete/duplicate, but I don't like having the settings in there.
  The old config button would be better indeed.
• The labels are very nice. The general feel is great indeed.

Small details:

• Dragging a pin, the label stays in the middle of the cable. I'd prefer to attach it to the mouse cursor.
• At small editor-zoom-scales, 2 pins can be hovered simultaneously.
• Dragging a node object, the outlet cables are animated smoothly, not the ones on the inlet side.

from mosaic.

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

from mosaic.

Well, for the node parameters gui, I see 2 options :

• The old Config button expanding the node size; which gives a lot of trouble (re)organising nodes on the canvas.
• #30 The inspector, showing the node's parameters when the node is selected on the canvas.

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 for the other small details.

from mosaic.

Hey, I ended up rewriting the nodeCanvas technically (see link above), which also led me to play with graphical changes.
The way it's now, everything UI is still possible, old behaviours are easily reversable. But the AddPin() and AddLink() have another mechanism, less specific to Mosaic.

UI Changes

• Before, an inlet pin could be disconnected by dropping an connected inlet on the canvas bg. This doesn't disconnect anymore; but they can be dropped on outlets to connect.
• The labels are on a different location. I think it's quite nice now, except if the cable goes from right to left. I'll add a better transition between the link being dragged and the
• I have not used your pin distance function but rather the native ImGui Hover on the invisibleButton().

It isn't perfect now and doesn't match your left-to-right logic.
I'd like to add different left/right click interactions on pins (inlet/outlet). One for reconnecting an existing cable (outlet), one for adding a new wire to the pin.
Another option (instead of Lclick/Rclick) could be to use 2 handles : drag the wire close to the pin to reconnect/disconnect, and drag the pin for connecting a new cable.
What do you think ?

A small GIF of the current state :

from mosaic.

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!

from mosaic.

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 pushID() before the dropzone, creating a dropzone with the same ID on all pins of the object, thus the actual drop being executed on all pins of the node (which have their own pushId())

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.
What about showing the right-side label on the outside of the node for hovered pins (old way), and the connection hover on the inside (new way) ? (like the gif) My main motivation for implementing this is that when nodes are close to eachother, labels and wires overlap, creating an even bigger visual mess.

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.
Nb, when you connect an endless loop, the pin connection is possible, but it just doesn't create the pin when you drop it. Maybe we can show a temporal warning saying this creates a loop, next to the pin ?
And also, for the details, there's no ptr copy right now, it's a simple check on the connecting value's address, matching it with itself (underlying value) and refusing to connect (if ==). Do you mean to find a way to connect non-crashing-impossible-values, or to change the graphical feedback of non-connecting-impossible-values (as the gif) ?

Edit: Oh I misunderstood the greyed-out param. Indeed it's gray=disabled, a question of not mapping isEditable() to isPinConnected(). It's intended as a temp debug helper. (and editing is still possible)

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)

from mosaic.

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:

https://vcvrack.com/

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

from mosaic.