Hi, > On 15.05.2013 16:04, Larry Becker wrote: >> This is this "kind of" thing. I'm not sure I fully understand your >> example though as I cannot see any reason to activate the menu with >> Attribute View 2 and to deactivate it with Attribute View 1 >> in SkyJUMP. >> >> >> Clicking the Attribute View belonging to the project and gives that project >> focus and enables menu items for that project's context. In this case, it >> is enabling and disabling based on the selection. >> > hmm, actually the simple Attribute Table dialog does not and i think never > did 'activate' a project. usually it merely serves as LayerManagerProxy and > stuff, so it is a kind taskframe by itself in this regard, just for one layer > only. we could of course implement this, not sure it is worth the effort. Don't know what 'activate' a project means exactly. I must see the code. I thing it is possible (easy?) to know what is the active frame, and from there, what is the active task if any. > the problem i see here is, that working with multiple taskframes (projects) > and several attribute windows open, it will be increasingly difficult for a > user to identify to which taskframe an attribute window belongs to. so wrt to > the quote below See my remark in the previous mail about prefixing attribute table title. Of course, it is not recommended to have many attribute windows belonging to multiple projects opened. > On 15.05.2013 00:34, Michaël Michaud wrote:> >> On the other hand, when there is no ambiguity and the plugin can get all the >> information it needs >> from the dialog box (ex. one project only, and a layer selector in the >> plugin dialog box), I cannot see >> any reason to grey it out. > i would not activate just because there is no ambiguity. OK, I should have said I would activate plugins when there is no technical reason to prevent the user from doing what he wants to do (technical reason may be lack of information or ambiguity). > this would be inconsistent, as it is not transparent to the user why a > plugin is enabled when editing only one task, but disabled when using more > than one. it's easier and more consistent to expect the user to activate the > taskframe explicitly. It would be transparent as the plugin would be activated every time a window related to a project is active (either a view or a table) and disabled when NO window related to a project is active. > it is important to understand that in the current OJ implementation main > toolbar attribute button windows simply represent just one layer of some > task, so only plugins that are meant to edit one layer should probably be > activated. i'd hesitate to even enable drawing plugins as the user might not > actually see the result immediately. Plugins may have results more visible in the attribute table (ex attribute calculator) or more visible in the view (ex. buffer), or both, or none of them (a plugin can just write a report). The important thing is the user must know which project/layer he is working on.
I agree that the case of plugins working on selection may be ambiguous if available when the attribute table is active. > but generally, yes of course enable checks often are inconsistent and need > lot's of finetuning especially for multi taskframe scenarios, which seem to > be sparsely tested to put it mildly. OK, let's start with plugins which have no reason to behave differently, but we'll have to decide in which direction to move. I'll try to make more specific proposals before changing. Michaël > > ..ede > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
