State (Objects displayed, refresh, etc.)

Collaboration diagram for State (Objects displayed, refresh, etc.):

Files
file	state.h

Data Structures
struct	draw_update_data_t

Functions
int	ged_view_update (struct ged *gedp)
int	ged_blast (struct ged *gedp, int argc, const char *argv[])
int	ged_draw (struct ged *gedp, int argc, const char *argv[])
int	ged_E (struct ged *gedp, int argc, const char *argv[])
int	ged_eac (struct ged *gedp, int argc, const char *argv[])
int	ged_erase (struct ged *gedp, int argc, const char *argv[])
int	ged_how (struct ged *gedp, int argc, const char *argv[])
int	ged_illum (struct ged *gedp, int argc, const char *argv[])
int	ged_lod (struct ged *gedp, int argc, const char *argv[])
int	ged_shaded_mode (struct ged *gedp, int argc, const char *argv[])
int	ged_redraw (struct ged *gedp, int argc, const char *argv[])
int	ged_who (struct ged *gedp, int argc, const char *argv[])
int	ged_zap (struct ged *gedp, int argc, const char *argv[])
int	ged_rect (struct ged *gedp, int argc, const char *argv[])
int	ged_keypoint (struct ged *gedp, int argc, const char *argv[])
unsigned long long	dl_name_hash (struct ged *gedp)

Variables
todo once this settles	down

Detailed Description

Geometry EDiting Library Object Selection Functions.

Todo:

• both the drawn state and the selection state need a rethink, particularly since they need to sync when an interface is visually indicating one or both sets of information.

There are three things we may want from either:

1. "minimal" list of active entities - the shallowest paths that fully express the set of active objects
2. "input" list - what the user has actually specified to create the current state
3. "solids" list - the full paths to the solids that will be the sources of the actual geometry shown in the scene. A complication here is drawing modes that evaluate the geometry, which will not have child solids but will themselves be holding a temporary set of generated view data.
4. "active" list - the set of all paths between specified/minimal and solids that are implicit active

Both #1 and #3 can be generated from #2, although how quickly this can be done is a concern as hierarchies get large. #3 is necessary for graphical interrogation of scenes to build selection sets, since it is those solid objects that the user will be interacting with. (In the case of a selection set built solely from graphical selection #2 and #3 will be the same. However, since the drawn scene will more likely have been specified with one or a small number of higher level objects, the #2 draw list needs to be used to generate a #3 list to support building up the selection list.)

When a "who" command is run the user is probably looking for #1, but that is not as clear in the select case - in a tree view, selecting a comb and all of the children of that comb have different implications for editing. The former, unless the comb is a top level object, implies editing the instance of the comb in its own parent. The latter implies editing the comb definition, altering the position of its children. Unlike the former, the latter will impact ALL uses of comb, not just a single instance. That would imply select should default to #2, but that's most likely not what is desired if the user has selected large numbers of individual solids from #3 - they MAY want that, but they may also be seeking to specify groups of regions or higher level objects to manipulate. That implies the need to expose some "collapse" operations to the user so they may identify wholly selected parent objects and "promote" to them.

We also need an efficient way for both drawing and selection codes to look up and manipulate the state of their corresponding information in the other container. When drawing, the interface may need to illuminate selected objects (which can be selected even if not drawn, and so will need to "appear" selected.) This requires being able to interrogate the #3 select list from the drawing code to identify if a given full path is selected. Likewise, when a selection occurs, drawn objects will need to have their illuminate state updated - the #2 select list will need to generate a #3 select list and then update (illuminate or de-illuminate, as the case may be) corresponding solids on the #3 drawn list. All this needs to also happen quickly, to handle large selections and de-selections on very large geometry hierarchies. The lists may also be invalidated by geometry editing operations, and so will need to be quickly validated against the .g state or updated in response to .g changes.

A complication on the #2 lists is what happens if an erase or deselect command removes part of a previously specified object. In that case a new #2 list must be generated which captures as much of the original semantic intent of the user specification as possible - "expanding" the relevant entries from the #2 list to their solids, removing the solids from the user specified removal parents, and then collapsing the remaining solids back to a minimal set.

Another #2 alteration case is when a higher level specification "subsumes" previous #2 paths into it. The existing paths must be recognized as subpaths of the specified path, and removed in favor of it.

At the moment, we have explicit logic in the drawing code for handling the above cases, using db_full_path top matching. Syncing between the selection and drawing codes is imperfect - draw does not currently check for selected status when creating scene objects.

Design thoughts - what if for both the ged drawn and selected lists we stash unordered sets of path hashes to indicate activity, and then add/remove those hashes based on specified paths and the related solid tree walks? To generate the #1 set from the #2 we get the parent of each #2, check if all the parent's children are in #4, and if so add it to #4 and process its parent and so on. If we find a parent without all of its children in #4, remove it from #4 if present and report it as a #1. To go the other way, do a full path tree walk calculating hashes as we go and populating #4. Any solid we reach that way is part of #3. If the view containers maintain unordered maps of hashes to scene objects, the selection code can directly identify any active objects. The highlighting update pass would be one iteration to clear all flags, and then a second over the #3 hashes from the selection to set illum flags on the currently selected objects. As long as the same hashes are used for both, no further processing would be necessary to ID selection changes.

Draw objects also still need to be synced with the .g state in response to update notifications from the .g I/O callbacks, which report directory pointers... we need a way to flag solids based on that info as well, which probably means we still need to keep the db_full_path associated with the scene object. May want to re-examine the current two-tier storage system and just make all solid objs top level entries. If we're willing to re-calculate the "drawn" #1 list on the fly, and not worry about #2 for the drawn objects case, that may simplify some things.

Function Documentation

ged_view_update()

int ged_view_update

(

struct ged *

gedp

)

ged_blast()

int ged_blast	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Erase all currently displayed geometry and draw the specified object(s)

ged_draw()

int ged_draw	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Prepare object(s) for display

ged_E()

int ged_E	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Prepare object(s) for display

ged_eac()

int ged_eac	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Prepare all regions with the given air code(s) for display

ged_erase()

int ged_erase	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Erase objects from the display.

ged_how()

int ged_how	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Returns how an object is being displayed

ged_illum()

int ged_illum	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Illuminate/highlight database object.

ged_lod()

int ged_lod	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Configure Level of Detail drawing.

ged_shaded_mode()

int ged_shaded_mode	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Set/get the shaded mode.

ged_redraw()

int ged_redraw	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Recalculate plots for displayed objects.

ged_who()

int ged_who	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

List the objects currently prepped for drawing

ged_zap()

int ged_zap	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Erase all currently displayed geometry

ged_rect()

int ged_rect	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Rubber band rectangle utility.

ged_keypoint()

int ged_keypoint	(	struct ged *	gedp,
		int	argc,
		const char *	argv[]
	)

Set/get the keypoint

dl_name_hash()

unsigned long long dl_name_hash

(

struct ged *

gedp

)

Variable Documentation

down

todo once this settles down

Definition at line 139 of file state.h.