I think that will only work in the simplest case. Consider the following view:
It becomes significantly more complicated, since it's not a 1-1 mapping between the depot and the workspace. Perforce has a built in function to deal with this sort of thing called 'p4 where' that shows how a particular file gets mapped through the view:
rpetti@petti:~/workspace/Install/trunk/Installers$ p4 where build.properties
Here it shows the depot path, the workspace path, and the path of the file on disk. The only problems here are that the values are space delimited, making it difficult to parse reliably, and the command needs to be run for every file in the changelist.
There are two ways to get around the parsing issue. The first is that you know what two of the delimiters are from the get go: In this case '//rpetti' which is just the name of the workspace and '/home/rpetti/workspace' which is the workspace root. You could hypothetically use those values to reliably parse the output.
The other is to ask perforce to output the results as a marshalled python dictionary (using 'p4 -G where'). The problem is that I haven't been able to find a java library for parsing these, so you might have to write one.
So ideally, when the plugin finishes grabbing a changelist description, it will proceed with finding the mapping of every file in the changeset by running 'p4 where'. It will then dump this information into a new field in the FileEntry class. The getAffectedPaths() function would just need to be changed to reference that new field instead of the depot path.
If this is too much, then I can take another look at it maybe this week or next week? I admit that I've been putting this one off since it didn't seem all that critical at the time.