Eugene Kuleshov <eu@md.pp.ru> wrote on 12/05/2005 12:04:06 PM:
> Any reasons why? Those all properties. Well, different kinds, but
still
> properties. So, put them under different sections in Properties view.
Just because of the way that view works. As you click on different
things, the contents of the view changes based on your selection. I do
not think this makes sense for something like our SVN Properties view
which is meant to be an interface for editing properties.
It doesn't make sense for the remote information because we would never
populate this information automatically as it is too expensive to
retrieve.
It doesn't make sense at all for the commit properties as that is
essentially running a "commit-type" operation against the remote
repository.
> Again why not? With Properties view user will have more responsible
UI. E.g.
> kick properties action from the repository view and properties view will
be
> populated asynchronously. I believe it would make much sense to do it
this
> way, then fix all the usability issues with repository properties
dialog,
> such as sorting properties by name, making dialog resizeable,
copy/change
> property values, etc.
I do not think there are usability issues with these items. Do you work
with a lot of repositories that have so many properties on items that you
would need to sort them? If so, we can add sorting support easily enough.
Also, it isn't possible to modify versioned properties in the repository,
so those options will never be made available.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Dec 6 04:45:29 2005