There’s been a lot of discussion lately regarding widgets and our upcoming work on them. One implementation issue that these widget raise is level of abstraction. Specifically, is the Scene layer in Cesium meant to have an engine built on top of it, or is the Scene layer meant to be the engine itself? I personally think the answer is the later, but I just wanted to confirm that with everyone else. For example, let’s assume we have different tools that rely on user input, such as a “measure tool”, a “select tool” and a “bounding box zoom” tool. Whose job is it to keep track of which is the active tool? Shouldn’t an event get fired when the a new tool becomes active (either through the GUI or programatically). This type of functionality can’t be implemented in a widget alone, because of they have implications outside of itself. I think we can simply make incremental improvements to the scene layer as these needs arise, but I just wanted to get other’s thoughts before prototyping code.
A slightly tangential question: If we drop the idea of a box-select zoom tool (which Google Earth/Maps doesn’t provide by default), can we avoid “modes” entirely and pass that concept up to the app level? Apps that support modes would still need a way of telling the navigation widget that the user is in a special mode I guess, to disable the normal drag-pan action etc.
–Ed.
I don’t think so. For example, a measure tool (which Google Earth does have) would still have the same problem. How do I know that click-drag draws a line to and shows distance rather than moves the mouse? Someone has to maintain state. Pushing things up to the app level ultimately makes everything harder to use because we would be relying more on users to implement their own engine architecture (a lot of which would probably be re-inventing the wheel for every app).
I have to see what this code looks like more concretely, but my gut is it does not beyond in Scene. Scene is the graphical representation of the world; it is responsible for organizing primitives, and culling, sorting, and executing their commands. It is not responsible for the outside state related to the UI. Columbus view and 2D and sort of exceptions here because they impact everything inside the scene. Scene.js also has the most critical code in Cesium so we carefully weigh what belongs.
Specifically, why can’t the widget handle mange events? I must be missing something.
Also, I want to clarify our terminology, Cesium is already an engine. There is no layer named engine. A game engine doesn’t have a bunch of stuff and an engine on top; it is an engine. I know AGI has used the term engine otherwise, but this is not the norm.
Patrick
I’m not saying it necessarily belongs in Scene, as much as belonging in Cesium in general. What it comes down to is some thing has to be the central bookkeeper for cross-widget state and it’s not reasonable to push that up to the application level.
One option would be to have the primary Scene widget (being worked in the simpleWidget branch) be that layer of abstraction. The main toolbar widget would then depend on the scene widget and not just on the underlying Cesium types. This would mean that using the toolbar requires you use the scene widget as well, but I don’t personally see a problem with that.
I’m sure implementing some of these features will bring any problems to the surface (and quash concerns over perceived problems that might not be that big of a deal).
Comments below.
One option would be to have the primary Scene widget (being worked in the simpleWidget branch) be that layer of abstraction. The main toolbar widget would then depend on the scene widget and not just on the underlying Cesium types. This would mean that using the toolbar requires you use the scene widget as well, but I don’t personally see a problem with that.
+1. I also don’t see any problems, and suspect that everyone will use the widget moving forward. If there is a strong use-case, we could pull this coordinator out separately to a public object, but I’d rather not until we see the case clearly.
I’m sure implementing some of these features will bring any problems to the surface (and quash concerns over perceived problems that might not be that big of a deal).
+1. Right on.
Patrick