eventBasedUI

@Carsten did you got frankOL’s eventBasedUI working?
I try to merge it, but it does not really work.
Do I miss something? I am working on v4.1Alpha

Just added a simple Reality Editor auto subscription model and cleaned up the library.
I think it can not get more simple.
I used the unique socked session id.

@Carsten I will try to cleanup the different methods for sending the object IDs and possition IDs.
You spend some time on it so far. I think since all pos values and all obj values are handled together at all time, it does not make sense to combine obj+pos.
I belive this was a leftover from the Arduino Yun. But we probably can separate it?

yes thats right.
for now I would stick with pos, since it is used throughout the entire project.
And it is not to far off from its meaning: Position in Object.

OK… I debugged the data communication and kicked out some unused code.
The combination “pos+obj” is removed entirely from the server.
I removed the 12 UUID dependency from the server and the Reality Editor.
I could do this easily since every object has the property “name” as well (In weiser Vorahnung ) .

I plan to upload the new Reality Editor version to the app store next week. getting close to finalize it.
Still some debugging.

Are there any features that are super important that I should add?

Here is the changlog for the upcoming reality editor version 1.6.0.
If you have anything that should be added. Speak up now…

• Improvement: The GUI renders 29% faster in iOS 8 and higher due a switch from UIWebView to WKWebView.
• Improvement: UIs are only transformed if the transformation matrix has changed. Saves Javascript processing time.
• Improvement: Lines show the perspective correct size according to the depth.
• New Feature: Unconstrained Editing allows the free positioning of UI’s in 3D Space.
• New Feature: Editing mode shows now, if the UI is visually behind the marker.
• New Feature: Reset Button allows to put a UI back to the default position.
• New Feature: send and receive global broadcasting messages among all UI’s. .addGlobalMessageListener(callback) and .sendGlobalMessage(message);
• New Feature: Subscription to Model View and Projection Matrix.
• New Feature: UI’s can now render full screen and subscribe to the 3D position relative to the marker. This allows the support for WebGL.
• New Feature: A touch Overlay indicates where the finger touches the display and provides guidance when connecting IO-Points
• New Feature: IO-Points are now responsive. The Reality Editor provides states.
• New Feature: Lines between IO-Points are now animated dot lines, that indicate the direction of a signal flow.
• New Feature: The GUI buttons are redesigned for more visible space.
• New Feature: New super fast startup. Up to 50 most used targets are permanently stored in the device. The Reality Editor automatically checks all target files and updates target files if they have changed on the server. This requires open hybrid version 0.3.2+
• Bugfix: More responsive checkboxes for the settings menu.
• Bugfix: UI’s are now sandboxed. It prevents the UI from loading web content on the GUI Interface level.
• Bugfix: Downloader registered multiple instances of an object.
• Bugfix: 3d transformation perspective was off and is corrected with individual corrections for each device class.

You have a point.
I was thinking that maybe we should just add a neutral state for mode p or n or even just replace the instant response with an f so that the reaction on p or n is not given.

d= digital, f = floating point, n = negative step, p= positive step.
d, f , n and p all have an absolute floating point value between 0 and 1 or exactly 0 and 1 as part of their message. I think this value should always be send right after connection. P and N should be send as f. d should be send as d. This way we make sure that there is a unified rule for sending data. This makes sure that at any point a controlling action will cause an expected reaction. If we would introduce options to chose from, it could generate more confusion then it could solve. Because you never would know what you get, when you draw a line.

I see another point need to be taken care of and that is what happens when the connection is disconnected.
Imagine a robotic arm that is placed on position 0.5. If we started originally on position 0 then connected intentionally a knob to it that moves the arm to position 0.5. We are aware of the knob controlling the arm and expect its change of position. If we disconnect the arm anytime later it would go back to maybe an unexpected position since we might not even be aware what the line is actually connected to in the first place? Should it stay in place? Should it go back to 0?However with a light, it should maybe just turn off again as being “not in use”.

I think we can formulate a clear rules for when one thing is controlling another thing, but when the thing is left alone by it self, it should be set back to what the creator thought is rightfully designed. Therefore we will need to add a default state to an IO-Point. This default state will be returned to in case the connection is lost. This however requires that the origin and the destination point keep a record of all links and that the reality editor sends links and deleted links to both and not just the origin.

Further down this is also very useful for data verification, where the destination only accepts data signed with the ID of the active link… Anyhow. Its a bit of a plan we would need to spend some time on. For now point 1 can be implemented easily (or @Carsten you already have the code?). Point 2 needs some more thoughts.