Re: RFE #876613

"Jerzy Kaczorowski" <[email protected]>
Newsgroups gmane.comp.version-control.cvs.gui.devel
Message-ID <[email protected]>
Hiroaki,

>I was invited here by Jerzy, because I
>posted patches and requests at ease too much ;)

Well, keep posting those patches! We have 89 open bugs with 66 feature
requests and only 15 patches. I would hope these numbers to be reversed ;)

>Originally, my subject was that the state column
>should not be too sensitive by translation.
>But as Jerzy says, the type information might not be
>necessary in the state column from the beginning.

The code we are talking about is in the CvsEntries.cpp at the end of
Entries_SetVisited function where we are setting the description for entries
elements. That is used in the Status column.

For the folder we can have:
"Ignored Folder"
"NonCvs Folder"
"Folder"

For the files we got:
"Ignored"
"NonCvs file"
"Conflict"
"Binary" or "Mod. Binary"
"Unicode" or "Mod. Unicode"
"File" or "Mod. File"

To begin with I am contemplating to change the column name to "State" to
indicate that it's not exactly the same as the result of "cvs status"
command but it reflect to more "local" information. But I am not quite sure
on this because it may confuse people a little bit.

But most important is the change of the description text itself. I suggest
to change as follows:
For the folders:
"Ignored"
"Unknown"
""

For files:
"Ignored"
"Unknown"
"Conflict"
"Resolved"
"Modified"
""

The reason is that information about the type is redundant - it's already
contained in the Option column and the icon for the file. From CVS "state"
perspective the type isn't much important.

I propose to change "NonCvs" into "Unknown" for it being shorter and in use
for filter descritpion for a long time now. It just seems to be more
natural.

Additionally we would use empty string for folders and files that are "up to
date". That would reduce the noise and expose the files that are potentially
more of interest to the user - modified or unkwnon ones. To help expose the
files of potential interest the sorting algorithm for state column would
apply "empty always looses" strategy. That means that when sorted by state
the files with non-empty description would always be on top of the list both
in ascending and descending order. In my experience that sorting approach
helps a great deal.

That is just a proposal for now and since it will impact all platforms I'm
waiting for comments or suggestions. It should help with translations a
little bit and thanks to the new sorting approach it will make sure that
important things are always on top and clearly visible. I am using that same
approach in CvsIn while I'm hacking WinCvs and I find it quite helpfull.

Best Regards,
Jerzy

----- Original Message ----- 
From: Hiroaki Itoh
To: [email protected]
Sent: Saturday, January 17, 2004 8:16
Subject: [cvsgui-dev] RFE #876613


How do you do, everyone? I'm Hiroaki Itoh, in Japan.
I was invited here by Jerzy, because I posted
patches and requests at ease too much ;)
Since I also have the main occupation,
since English reading and writing are hard for me,
and since time difference(between U.S. and
Japan) is 17 hours, so communicating with me might be
difficult and slow, but since I'll try hard it,
please watch me gently.


Jerzy said:
> I think we will discuss that on cvsgui-dev list with others first
> because it will affect other platforms too...

Please see
  http://sourceforge.net/tracker/index.php?
func=detail&aid=876613&group_id=10072&atid=360072
first.


Originally, my subject was that the state column
should not be too sensitive by translation.
But as Jerzy says, the type information might not be
necessary in the state column from the beginning.

What do you think, everyone?


 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/cvsgui-dev/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.