@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, the part with the ID’s really is a mess 
Yes I agree we should separate obj and pos ID’s. That would simplify things. For example in the WebUI for the “live status page” you need pos but you have to extract it from pos+obj and for that you have to know the length of the unique id which is pretty weird and who knows in the future the length of the unique id might change and break everything. And semantically it also makes sense to separate pos + obj because pos only needs to be unique within an object, Additionally I think we could rename pos to iopoint or something because that’s what the value represents.
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?
1 Like
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.
1 Like
One point just came to my mind: For most objects it makes sense that upon the creation of a connection the receiving IOPoint is immediately updated with the value of the sending IOPoint. For example take two lamps where you connect the brightness. The user expects that when the connection has been made the two lamps have the same brightness. On the other hand if you have a knob which delivers relative values (mode “p” or “n”) you don’t want the connected IOPoint to be updated without the knob being turned. For example it would be weird if you connected the knob to the volume of a radio and it would immediately increase the volume by one step.
I think the developer should be able to define per IOPoint if it sends it’s current value upon link creation.
I sort of already implemented the immediately update part in my fork but didn’t make it configurable by the developer yet. But I think it’s pretty easy to implement.
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.
I agree.
I don’t think it can be as simple as that. p and n are used to increment a value at the receiving end. But usually you don’t want to increment something directly upon connection. At least I can’t think of an example right now. That’s what I wanted to express with the knob and radio volume example. I think d and f should be updated immediately but not p and n.
What I implemented is super easy, I just call the objectEngine function when a link is created to trigger the send event. That’s one line of code. But as I said I don’t think that’s sufficient.
Point 2 I agree with. That’s probably gonna be quite the challenge 