20,741
edits
Canvas widgets: Difference between revisions
Jump to navigation
Jump to search
m
→Missing / Todo (08/2012)
| Line 59: | Line 59: | ||
* '''Use images inside Canvas''' (will also be needed for implementing the 2D panel wrapper): We need a new element type to also display images and other textures (eg. also the texture of another canvas) inside a canvas. Not everything can easily be represented using just vector graphics, so images will also be needed. {{Not done}} | * '''Use images inside Canvas''' (will also be needed for implementing the 2D panel wrapper): We need a new element type to also display images and other textures (eg. also the texture of another canvas) inside a canvas. Not everything can easily be represented using just vector graphics, so images will also be needed. {{Not done}} | ||
* '''Window Stacking''': New windows always appear on top of older windows. It would be nice to have the possibility to change stacking order (either reorder the windows or use z-buffer with different z-values) The window manager could eg. listen on a special signal property on each window (eg. /sim/gui/canvas/window[i]/raise) which moves the according window to the top of the current window stack. I'd prefer window reordering because it would make checking for a window at a given position very ease, because we'd just have to check for the first match in revers stacking order (from topmost to lowest window).{{Not done}} | * '''Window Stacking''': New windows always appear on top of older windows. It would be nice to have the possibility to change stacking order (either reorder the windows or use z-buffer with different z-values) The window manager could eg. listen on a special signal property on each window (eg. /sim/gui/canvas/window[i]/raise) which moves the according window to the top of the current window stack. I'd prefer window reordering because it would make checking for a window at a given position very ease, because we'd just have to check for the first match in revers stacking order (from topmost to lowest window).{{Not done}} | ||
* ''' | * '''Picking''': For mouse handling some kind of picking would be nice. As already mentioned, at least bounding box intersections will be needed.Forward mouse events to canvas elements (trigger onhover, onclick, etc.) The canvas could listen for creation of the signal properties and then add the according region to a list of monitored regions. If the cursor is in one of the regions the property is signaled.{{Not done}} | ||
* '''Support copy&paste''': I'm working on the selection part, but have no clue yet on how to access the system clipboard.{{Pending}} | |||
* '''Keyboard input''': I haven't thought too much about it and also haven't done anything, but we will definitely need access to keyboard events {{Not done}} | |||
* '''Clipping''': For different reasons we will need to be able to clip some elements to certain regions. It should work with specifying either a clipping rectangle or by using a path. OpenVG seems to have support for it, although I haven't looked into it too deep. We also need to ensure that it also works with text. At least rectangular regions are needed.(eg. group/clip-min[0..1], group/clip-max[0..1]) {{Not done}} | * '''Clipping''': For different reasons we will need to be able to clip some elements to certain regions. It should work with specifying either a clipping rectangle or by using a path. OpenVG seems to have support for it, although I haven't looked into it too deep. We also need to ensure that it also works with text. At least rectangular regions are needed.(eg. group/clip-min[0..1], group/clip-max[0..1]) {{Not done}} | ||
* '''[[Canvas Maps|Geographic Mapping]]''': It's very experimental, missing different projection modes (eg. vertical projection) and especially the Nasal API feels very hackish. {{Not done}} | * '''[[Canvas Maps|Geographic Mapping]]''': It's very experimental, missing different projection modes (eg. vertical projection) and especially the Nasal API feels very hackish. {{Not done}} | ||
* '''Animations''': I don't know if we should do animations just be using interpolator and settimer from Nasal or if we should implement some time-based animations directly in C++. At least we need some helper functions (eg. for blinking elements -> cursor, fading, ...) It would also be possible to implement animations purely in Nasal space, e.g. by supporting a subset of SMIL for SVG, so that existing tools could be used to created animated vector images that are converted to canvas properties by the Nasal parser. | * '''Animations''': I don't know if we should do animations just be using interpolator and settimer from Nasal or if we should implement some time-based animations directly in C++. At least we need some helper functions (eg. for blinking elements -> cursor, fading, ...) It would also be possible to implement animations purely in Nasal space, e.g. by supporting a subset of SMIL for SVG, so that existing tools could be used to created animated vector images that are converted to canvas properties by the Nasal parser. | ||
* <del>Improve PUI to allow eg. receiving mouse over events.</del> (osgGA will be used) {{Done}} | * <del>Improve PUI to allow eg. receiving mouse over events.</del> (osgGA will be used) {{Done}} | ||
| Line 69: | Line 69: | ||
** Implement some widgets in Nasal.{{Not done}} | ** Implement some widgets in Nasal.{{Not done}} | ||
** Check what is missing to implement the different hardcoded instruments.{{Not done}} | ** Check what is missing to implement the different hardcoded instruments.{{Not done}} | ||
** Maybe support displaying shapefiles.{{Not done}} | ** Maybe support displaying shapefiles.{{Not done}} | ||
* '''Unify the canvas creation a bit''': such that canvases can be moved seamlessly between the different placements (gui, model,hud, etc.). The normal model placement is great but the gui widget placement needs to be able to also use an already existing canvas.{{Not done}} | * '''Unify the canvas creation a bit''': such that canvases can be moved seamlessly between the different placements (gui, model,hud, etc.). The normal model placement is great but the gui widget placement needs to be able to also use an already existing canvas.{{Not done}} | ||
* '''Support multiple views/windows''': Currently the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views.{{Not done}} | * '''Support multiple views/windows''': Currently the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views.{{Not done}} | ||
* '''Documentation''': Read, ask questions, extend. I haven't done too much documentation (apart from inline documentation) just due to the reason that the API is not completely stable yet. You could also try different use-cases and maybe find some examples where the API lacks some features.{{Not done}} | |||
* '''Own ideas''': Come up with a new idea or something that I have already mentioned somewhere else {{Feedback}} | * '''Own ideas''': Come up with a new idea or something that I have already mentioned somewhere else {{Feedback}} | ||
* Find more work I've currently forgotten about :) {{Feedback}} | * Find more work I've currently forgotten about :) {{Feedback}} | ||