Perhaps I'm playing devil's advocate, but think of this from a developer standpoint as well. Do you really need the overhead of tracking and storing each column size? Why devote the logic and storage space to handling custom sizes? I personally would be much happier if Versions just did The Right Thing and showed me the most it could with the columns I've selected.
- Quinn On Feb 20, 2009, at 4:09 PM, kiddailey wrote:
*DEFINITELY* agree. And my gut says that option 2 is the best approach. Perhaps allow it to be stored (along with which columns are on/off) on a per-working copy/repository, because I can definitely see a need where I might want to have it different for two different projects. For example, if I'm the only user on a project, I don't need to see the name column, but I would if there were multiple users. This, in addition to not remembering window position, window size, and folder open/close states are my biggest pet peeves with Versions. I waste way too much time getting everything back into the last usable state. On Feb 19, 7:58 am, Peter <difos...@gmail.com> wrote:Hey,Every time I start Versions I proceed to change the column sizes underthe Browse view. The Base, Last, Date and Author columns are biggerthen they need be and the Name column is too small. I like to maximizethe Name column so I can see filenames instead of '...'. Now for the feature request, I see two possibilities: 1) Intelligent automatic column sizing - Try to make the contents fit as well as possible within the window size automatically2) Remember a user's column sizes - They will likely work with similar content so being able to tune the sizes as desired would be a nice wayto go about it as well If this should already work like this but it doesn't for me for some reason then please consider this a bug report :) Regards, Peter
smime.p7s
Description: S/MIME cryptographic signature