[
https://issues.apache.org/jira/browse/PIVOT-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161540#comment-13161540
]
Volker Seibt commented on PIVOT-656:
------------------------------------
Without the patch trunk is as slow as 2.0 on our slow network drives.
I integrated the changes into trunk and after testing I've created a new patch
because the structure of TerraFileBrowserSkin has changed, especially the task
for asynchronously reading the filelist had been restructured since 2.0.
I tested on the FileBrowsing example from the tutorial (because my application
has little problems with 2.0.1) . Everything seems to be fine but shoud of
course be tested by somebody else.
While testing I found another issue: if a removeable drive is removed after
reading the list of drives and then this removed drive is selected in the list,
this (wrong) drive selection is kept but the filelist keeps the content of the
previous drive.
I changed the selection event to switching back to the previous drive and
rereading the list of drives if a drive can not be read. While testing this I
had no realy problems with removing drives, only our slowest network drives
disappeared from the list and I had to reopen the sheet to access them again.
This change is also included into the new patch.
> FileBrowserSheet seems frozen while browsing network folders
> ------------------------------------------------------------
>
> Key: PIVOT-656
> URL: https://issues.apache.org/jira/browse/PIVOT-656
> Project: Pivot
> Issue Type: Improvement
> Affects Versions: 1.5.1
> Reporter: A.J.
> Fix For: 2.1
>
> Attachments: apache-pivot-terra-fileBrowserSkin-performance.patch
>
>
> Our customer complains about the FileBrowserSheet being unresponsive while
> browsing network folders.
> I haven't been able to reproduce this in my development environment but I saw
> this in 'action' (or inaction in this case).
> They click a folder then ... nothing happens, they wait, then wait. They are
> free to try other folders (I guess this is asynchronous task) but nothing
> happens.
> I've asked them to navigate the same network path with the Windows explorer
> which has no apparent problem (some slowdowns at worst).
> So, it's hard to say where the problems is (no stack trace) but there is a
> problem.
> One first improvement that could be done would be to display an hourglass
> (busy cursor) while the current I/O operation is pending.
> Another one could be also to set a timer after which the I/O operation would
> be canceled (or abandonned) and give back hand to the calling code.
> That's all I'm thinking fo r now.
> As soon as I can get some more info on the origin of the problem, I'll update
> this issue.
> Cheers,
> A.J.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
