[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] properties management

From: Eugene Kuleshov <eu_at_md.pp.ru>
Date: 2005-12-05 23:09:29 CET

Mark Phippard wrote:

>>>I do not think this makes sense for something like our SVN
>>>Properties view which is meant to be an interface for editing
>> 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 is not the editing part that I was talking about, I meant that the
> content of the view changes whenever you click on something.

   And what is wrong with that? SVN properties information is local,
so it should not be an issue.

>> 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 isn't going to happen (from me). I did not use the SVN Properties view
> because showing the properties was just a throw-in feature. The purpose
> of the dialog is to show the svn info output, specifically any lock
> information if the file is currently locked.

   Again, why can't you show locks in properties view and reuse
existing UI instead of building and them polishing new one? Note that
using modal dialog for slow operations is generally a bad idea...

>> Arguably. You could still pigy back to special section im
>>properties view focused on revision selected in a history view.
> The other suggestions are all valid and just a toss-up choice which way to
> go. This one I just do not agree with. I think this deserves a special
> option.

   It might. But with properties these editing options could be more
verbose to the user...

>> 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).
> I do not think I have ever seen anything with more than 4, but if it
> bothers you I have no problem adding sorting.

   http://subclipse.tigris.org/svn/subclipse/trunk/subclipse/ui has 8
and they don't fit into the default dialog without scrolling. It is
not like a big deal, but you would got much better polished UI with
less effort when using Properties view...

Received on Tue Dec 6 09:09:29 2005

This is an archived mail posted to the Subclipse Dev mailing list.