From: Mark J. <mr...@le...> - 2003-08-19 19:19:12
|
On Tue, Aug 19, 2003, Amitha Perera wrote: > On Mon 18 Aug 2003, Mark Johnson wrote: > > recently, while trying to view the output of several edge detectors in > > the same window in a coherent manner, it came to my attention that > > there's currently no good way to show/hide large sets of soviews, or > > even to be able to quickly alter the style associated with a large set > > of soviews while still maintaining individual highlighting. > > How about using multiple tableaux, one for each set? You could arrange > them something like > > vgui_composite_tableau +-- vgui_active_tableau +-- vgui_easy2D_tableau > | > +-- vgui_active_tableau +-- vgui_easy2D_tableau > | > +-- vgui_active_tableau +-- vgui_easy2D_tableau > | > +-- vgui_active_tableau +-- vgui_easy2D_tableau > i believe the problem with this setup is that easy2D_tableau would be highlighting its own soview. meaning that, with the setup above, 4 different objects could all be highlighted at once as the mouse is moved over them. or, in the case of choosing just 1 as the "active" tableau but with all 4 being viewed, highlighting would be limited to that tableau, and would require some user interaction to highlight other soviews that weren't part of that tableau but that were being displayed by one of the other 3. > > This is just an idea. What you say also sounds good, but I'm a > somewhat afraid the interface for these things will explode beyond > management. To me, the philosophy behind vgui is very Unixish: a set > of small tools that you can string together in any way you want. > i'm not sure what you mean by saying the "interface... will explode," but i do agree that a lot of functions (like in easy2D) could be cluttered with having "vcl_string which = "default" " arguments added in. but to the casual user who didn't want to take advantage of the new functionality, things would work as they always did. Mark Johnson mr...@le... > > Amitha. |
From: Amitha P. <pe...@cs...> - 2003-08-19 22:09:55
|
Amitha Perera wrote: > This is just an idea. What you say also sounds good, but I'm a > somewhat afraid the interface for these things will explode beyond > management. To me, the philosophy behind vgui is very Unixish: a set > of small tools that you can string together in any way you want. Mark Johnson replied: > i'm not sure what you mean by saying the "interface... will explode," > but i do agree that a lot of functions (like in easy2D) could be > cluttered with having "vcl_string which = "default" " arguments added > in. but to the casual user who didn't want to take advantage of the new > functionality, things would work as they always did. The latter statement is true of just about any method or function you add to a class. The result is a TargetJr-like mess, as people add "locally useful" functionality. This is a general observation, not meant as criticism of your particular suggestion. To my suggestion of a composite tableau, Mark replied: > i believe the problem with this setup is that easy2D_tableau would > be highlighting its own soview. meaning that, with the setup above, > 4 different objects could all be highlighted at once as the mouse is > moved over them. or, in the case of choosing just 1 as the "active" > tableau but with all 4 being viewed, highlighting would be limited > to that tableau, and would require some user interaction to > highlight other soviews that weren't part of that tableau but that > were being displayed by one of the other 3. This is true. But can't you use shared styles? Looking back at your original message, you wrote: > there's currently no good way to show/hide large sets of soviews, or > even to be able to quickly alter the style associated with a large set > of soviews while still maintaining individual highlighting. Each soview can be given a pointer to the same style object. I believe that is the point behind vgui_style. Changing, for example, the line width of this style object should then change the line width of all the objects tied to the style. Adding a "visible" variable to the style object, and the appropriate code in the vgui_displaybase hierarchy to use the variable, should be relatively straight-forward. To me, this is simpler than "named groups". It has the added benefit of applying directly to the 3D soviews. Esstentially your group "name" is the style object pointer. Presumably you could further group a small set of style objects at the application level, depending on how you formed the groups. However, I haven't done this myself, so I am probably missing something. Again. :-) Amitha. |
From: Mark J. <mr...@le...> - 2003-08-20 13:58:12
|
> Amitha Perera had concerns that 'the interface for these things will > explode' > > Mark Johnson replied: > > i'm not sure what you mean by saying the "interface... will explode," > > but i do agree that a lot of functions (like in easy2D) could be > > cluttered with having "vcl_string which = "default" " arguments added > > in. but to the casual user who didn't want to take advantage of the new > > functionality, things would work as they always did. > > The latter statement is true of just about any method or function you > add to a class. The result is a TargetJr-like mess, as people add > "locally useful" functionality. This is a general observation, not > meant as criticism of your particular suggestion. I agree that one doesn't want these core classes to become overly complicated. And it's true that usually added methods don't alter functionality -- but since I'm proposing changing the existing functions in vgui_displaybase to add functionality, it's nice that it won't require scripts to plow through the whole CVS tree and alter everyone's code. The changes would occur and be transparent to users at large. > > This is true. But can't you use shared styles? Looking back at your > original message, you wrote: > > > there's currently no good way to show/hide large sets of soviews, or > > even to be able to quickly alter the style associated with a large set > > of soviews while still maintaining individual highlighting. > > Each soview can be given a pointer to the same style object. I believe > that is the point behind vgui_style. Changing, for example, the line > width of this style object should then change the line width of all > the objects tied to the style. Adding a "visible" variable to the > style object, and the appropriate code in the vgui_displaybase > hierarchy to use the variable, should be relatively straight-forward. > This is very close to being a solution to the problem -- in fact, this is what I originally started to implement when trying to achieve the desired functionality in vgui. However, the actual GUI interface that we're trying to support requires that groups of objects be able to have different style attributes for each object. Take, for example, a situation in which you want to run an edge detector multiple times on the same image with different values of the variable sigma, and then you'd like to compare the results. And say that usually when running the edge detector, the output is thin and thick lines that represent the "strength" or "confidence" associated with each edge. So now, to view those outputs together with any kind of clarity, it would be convenient to be able to place a "style override" on a certain set of objects. That style override could be a show/hide boolean or a color-replace option, or any combination of show/hide, color-replace, or properties (line width, etc.) alterations. To me, such a concept seems like basic functionality, something that people would incorporate into programs on a regular basis to allow UI changes at runtime to allow better visualizations of algorithm results. Now perhaps this could be achieved by having some sort of "style override" element included in all soviews. But that seems more complex than just grouping elements at the displaybase level and providing methods to change aspects of a particular group's display at that level. Mark Johnson mr...@le... |
From: Amitha P. <pe...@cs...> - 2003-08-22 03:10:49
|
Mark Johnson wrote: > To me, such a concept seems like basic functionality, something that > people would incorporate into programs on a regular basis to allow UI > changes at runtime to allow better visualizations of algorithm results. > Now perhaps this could be achieved by having some sort of "style > override" element included in all soviews. But that seems more complex > than just grouping elements at the displaybase level and providing > methods to change aspects of a particular group's display at that level. First, let me agree with you that the concept of grouping the objects is good and important. We are disagreeing about how to achieve this functionality in vgui. I think you have a reasonable solution, but I'm trying to figure out if there is a way to achieve it without changing vgui as much. I write this up front to keep this discussion to a "objective" pro/con analysis of the different ways we could achieve the desired results. Is anyone else on the list interested in following this discussion? If not, I'll suggest that Mark and I take it off the list, and we'll post back a summary of what we same up with. Going forward with the technical stuff: > Amitha Perera wrote: > > Each soview can be given a pointer to the same style object. I believe > > that is the point behind vgui_style. Changing, for example, the line > > width of this style object should then change the line width of all > > the objects tied to the style. Adding a "visible" variable to the > > style object, and the appropriate code in the vgui_displaybase > > hierarchy to use the variable, should be relatively straight-forward. > > > > This is very close to being a solution to the problem -- in fact, this > is what I originally started to implement when trying to achieve the > desired functionality in vgui. However, the actual GUI interface that > we're trying to support requires that groups of objects be able to have > different style attributes for each object. This does not mean that one object is simultaenously associated with multiple styles, does it? I just want to make sure I'm not misunderstanding the problem you describe. My understanding is that the string labels form a group, with each so_view in exactly one group. Then, you can quickly set/reset the style parameters for each group. BTW, in your current implementation, where are the "old" values stored, when the style is overridden? Does the displaybase keep track of the change history, or does the client application simply say "change all this attributes"? > Take, for example, a situation in which you want to run an edge detector > multiple times on the same image with different values of the variable > sigma, and then you'd like to compare the results. And say that usually > when running the edge detector, the output is thin and thick lines that > represent the "strength" or "confidence" associated with each edge. So > now, to view those outputs together with any kind of clarity, it would > be convenient to be able to place a "style override" on a certain set of > objects. That style override could be a show/hide boolean or a > color-replace option, or any combination of show/hide, color-replace, or > properties (line width, etc.) alterations. I guess I'm not understanding the problem exactly. To me, the output of one run will be associated with one (set of) vgui_style objects. The output of the other run will be associated with another (set of) style objects. The client application will keep track of these style objects. When the client wants to change the style of the first set (to change colour, say), it'll retrieve the style object that it stashed away, and change the parameters. And perhaps keep track of the old settings if an undo is necessary. Right now, vgui_easy2D does not have the required functionality, but that is an easy change. With this undescribed change, my solution to the situtation you describe above would be something like map<string,vgui_style_sptr> named_style; edge_list = run_detector( param1 ) vgui_style_sptr style1 = new vgui_style( ... ) easy2D->set_style( style1 ) foreach e in edge_list easy2D->add_line( e.v0(), e.v1() ) endfor named_style["Detector param 1"] = style1 edge_list = run_detector( param1 ) vgui_style_sptr style2 = new vgui_style( ... ) easy2D->set_style( style2 ) foreach e in edge_list easy2D->add_line( e.v0(), e.v1() ) endfor named_style["Detector param 2"] = style2 ... string user_picked_name; ... vgui_style_sptr style = named_style[ user_picked_name ] width_undo_list.push_back( style->line_width ) named_style["Detector param 1"]->line_width = new_width easy2D->post_redraw() Here, the burden of maintaining names and style associations is put on the client. This allows the client to dictate what to change, when, whether the associations are with strings or something else, and maintain undo information as necessary. [ There are more extensive changes implied here. For example, dealing with smart pointers to style objects. This may break client code. However, I think it will be better, because the currently system is somewhat fragile. It's not clear who owns the style object, and when should be removed, and the interaction between the style manager and user-defined styles is not so clear. Documenting and clearing up that mess would be valuable by itself. ] Now, as you say, it may be quite common for applications to require grouping by strings. Perhaps the easiest way to do this is to subclass easy2D to provide the grouping? Actaully, this could be done for your current implementation, if I understand you. All the subclass would do is add one data member (the map) and a few methods to set a "current name", and override vgui_displaybase::add to associate the current string with whatever object is being added. Amitha. |
From: Peter V. <Pet...@es...> - 2003-08-22 10:34:53
|
AP> my solution to the situtation you describe above would be something like AP> AP> map<string,vgui_style_sptr> named_style; AP> AP> Here, the burden of maintaining names and style associations is put AP> on the client. Actually, this solution (using a map) is exactly what we came up several years ago in TargetJr's GUI as the best way to go to store properties of visual objects and their interrelationships. See the Database package. Actually, several maps were used, e.g. to link points to overlay views, hence the "display the edgel overlay", or "switch off the point overlay" functions of the GUI were implemented by running through these maps. Maintaining names was indeed also put on the client, but there was one global set of maps for storing unnamed, globally accessible relations. The Database package is a very neat piece of software, worth of being reused! -- Peter. |