Search Mailing List Archives
[p4-feedback] bug reports and feature requests (1)
nick.drummond at cs.manchester.ac.uk
Thu Apr 30 07:48:50 PDT 2009
>> I could perform the same functions with a set of command-line tools and a
text editor, if I wished.
Well, you could, but...
>> a one-chance opportunity to recall the last mouse click
For just handling the views this would not be impossible but I doubt someone
that was this un-familiar with the interface would easily find the "undo"
I don't think I can realistically have an undo for the last mouse press.
This is well beyond what most applications would do.
I don't even want to think about how hard this would be. A mouse click can
do an awful lot of things. Many of them pluggable.
>>Curious that it isn't fixed in the one I pulled down fairly recently...
Build 108 was a while back.
>> I didn't save it, so the list entry should not have appeared.
Perhaps this is a bug.
>> if the program is going to keep my (implicitly defined) preferences
around, it should do so in a more granular and controllable manner
We would like to have per-project preferences - it is a big thing on the
list - but unfortunately we don't have the resources at the moment to do
this large change (and more importantly get it right).
>> The problem is that a user might try to use the color as a hint for
finding the View in the Menu Bar
OK, if anyone else thinks these two views should be in the View | classes
menu then I'll move them
>> there are ways to show this [floated/split view header colour] without
breaking the visual connection that the background color provides (eg, use
some sort of stipple or hash pattern, as well as a color).
OK, on the list.
> Refresh User Interface
I'm sure this is just a bug in the property hierarchy views
2009/4/28 Rich Morin <rdm at cfcl.com>
> At 18:22 +0100 4/28/09, Nick Drummond wrote:
> > We haven't had the resources to do a full UI review, so appreciate
> > the notes (although I think a lot will be low priority).
> I can't argue with your priorities. The program is quite usable
> (eg, coherent, consistent, flexible, powerful), so getting it to
> generate a full range of well-constructed ontologies is (IMHO)
> the most important challenge.
> However, I would submit that P4's UI is its main justification for
> existence. After all, I could perform the same functions with a
> set of command-line tools and a text editor, if I wished. However,
> P4's integration makes it more of a specialized IDE than an "editor".
> Finally, details matter, particularly when they violate the Principle
> of Least Astonishment and/or leave the user feeling annoyed, confused,
> trapped, etc. So, please keep these nits on the list...
> > "close" button in views ...
> > Cmd-Z is reserved for undo on the model and nothing else. I think
> > anything else would be unintuitive.
> Point taken, but a menu item could still take on this role. BTW,
> it's a bit unfortunate that there is a collision between "View" as
> a P4-specific UI element and the Apple standard of using a "View"
> menu for generic appearance changes to the application. Sigh.
> > Once a view is closed there is no guarantee that the place it would
> > go still exists.
> What I have in mind is a one-chance opportunity to recall the last
> mouse click. As in "OMG, what did I do and how do I get it back?"
> So, just put things back the way they were before th user clicked.
> > Why are you closing the view if you want it back? Is this when
> > you've made a mistake? I don't think this is likely.
> People commonly make positional errors when using pick devices (eg,
> mice, track pads). Given the tiny size and close proximity of the
> View icons, new users are quite likely to make this error. And, if
> a new user closes a default View, s/he may not remember which one it
> was, let alone know how to get it back. Restoring the entire Tab
> seems like a rather onerous remedy for such a minor mousing error.
> > "Object property axioms" section ...
> > This has been fixed for a few releases
> Glad to hear it. Curious that it isn't fixed in the one I pulled
> down fairly recently...
> > "Welcome to Protege" dialog: ...
> > Did it not exist when you saved it?
> I didn't save it, so the list entry should not have appeared.
> > "Create new OWL" uses the same view settings each time; there
> > doesn't appear to be any (reasonable) way to reset them to the
> > "factory defaults".
> > The tabs can be reset to default as you said before. I don't
> > understand the problem. There are no "per project" settings.
> I'll try to come up with a clearer scenario. IIRC, the problem
> was that I (a) started an ontology, (b) fiddled with the Views
> in some of the Tabs, and (c) killed off the ontology and quit
> the program.
> When I restarted the program, the Tabs retained my View changes.
> My take is that, if the program is going to keep my (implicitly
> defined) preferences around, it should do so in a more granular
> and controllable manner.
> > There are no "per project" settings.
> Perhaps there should be. :)
> > OWLViz tab
> > ...
> > How do I get OWLViz to try dot(1) again? (Refresh User Interface
> > should do this, but doesn't.)
> > I don't know how it was written, but I guess once you've set the
> > path in the prefs it tries again.
> This may not be obvious to the user, but if you search the PATH each
> time for the dot(1) program, it may become a non-issue...
> > Background colors of View headers ...
> > OWLViz shows classes and is the class colour. DL Query arguably
> > shows more than classes, but it doesn't offend me that it is class
> > colour.
> I guessed that the logic went something like that. The problem is
> that a user might try to use the color as a hint for finding the
> View in the Menu Bar. Given that these aren't in the "Class view"
> sub-menu, s/he will have to look around until s/he finds them in
> the Misc sub-menu. Basically, it's a violation of consistency.
> > Also, split and floated views do not maintain the same background
> > color as the original view.
> > I think this is to show they are not synchronizing with the selection
> That's fine, but there are ways to show this without breaking the
> visual connection that the background color provides (eg, use some sort
> of stipple or hash pattern, as well as a color).
> > Refresh User Interface
> > This removes the visible indication of selection from (say) the Data
> > Properties View, but does not actually de-select the View.
> > OK. Added to the list (is this a problem?)
> My take is that "Refresh User Interface" should restore the UI (insofar
> as possible) to an appearance and behavior that reflect the internal
> state of the program. Mostly, it does.
> However, the treatment of selected items is inconsistent. If an item
> has been selected, it is used as the subject of (some) neighboring Views.
> Currently, although this is still the case after a refresh, the selected
> item is not highlighted. So, the user has no indication of which item
> the other Views are showing, etc.
> Anyway, thanks for the prompt and detailed response. Congratulations on
> producing a fine program!
> http://www.cfcl.com/rdm Rich Morin
> http://www.cfcl.com/rdm/resume rdm at cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
> Technical editing and writing, programming, and web development
> p4-feedback mailing list
> p4-feedback at lists.stanford.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the p4-feedback