Mark Phippard wrote:
>> 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.
This is not necessary a bad thing. Used would see consistent view
of svn properties across entire Eclipse workspace. The only issue
would be a long-running operations where own SVN Properties view fits
better because it is not linked with the current selection/focus.
> I do not think this makes sense for something like our SVN
> Properties view which is meant to be an interface for editing
> properties.
That is exactly the purpose of properties view. You can plug in
your own editors or let user edit properties in place. You can even
provide your own custom panel it you want to (see properties handling
in WTP's XML Schema editor).
> It doesn't make sense for the remote information because we would never
> populate this information automatically as it is too expensive to
> retrieve.
I don't see why not, if you do that asynchronously in a background
job and cache results locally (and clean cache on refresh).
That would be much better then looking at frozen workbench window
for 30 seconds while properties dialog is waiting for server response.
Even if you won't go with Properties view it would make sense to use
your own SVN Properties view for this.
> It doesn't make sense at all for the commit properties as that is
> essentially running a "commit-type" operation against the remote
> repository.
Arguably. You could still pigy back to special section im
properties view focused on revision selected in a history view.
>> 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?
It is just look ugly when properties with similar name/prefix are
shuffled randomly in the list (even with 10 properties like in
subclipse's own repository).
> 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.
Hmm. I thought if you could rename/move resources you might as well
change properties implicitly creating new revision...
regards,
Eugene
Received on Tue Dec 6 06:42:58 2005