Tom Just a small feedback in regards to the "open in Venue" issue. Because it actually causes issues with the Venue Server, I would suggest removing this feature, until substantial testing has been concluded.
Anyway, just my 2 cents worth. Cheers, Jason. -----Original Message----- From: ag-tech-boun...@lists.mcs.anl.gov [mailto:ag-tech-boun...@lists.mcs.anl.gov] On Behalf Of Thomas Uram Sent: Friday, 1 October 2010 02:03 AM To: Lloyd Pearson Cc: AG-TECH list Subject: Re: [AG-TECH] AG 3.2 comments and problem list Thanks Lloyd for the feedback. I've commented below. I'll get these into Bugzilla in one form or another and send you pointers so you can track them if you like. On Sep 29, 2010, at 11:28 PM, Lloyd Pearson wrote: > Hello team, > > Some comments to 30 Sept 2010 on the Access Grid 3.2 final release on a > Windows XP SP3 PC. > > - If two or more VIC's are in use, each has the same title which > is the name of the virtual room. They need the names of each camera to > identify the VIC. This is important because with identical VIC's it isn't > obvious which VIC the opened camera windows on display in a conference came > from, and if one wishes to disable a camera during a conference, there is a > risk that all cams on the display will disappear! This should only happen if you're running multiple video consumers on one machine, or a video consumer and video service; this scenario is unlikely, as there's no benefit, but there is the drawback that you mention. Video producer vics are labeled with the capture device name, and are minimized at startup by default, so they shouldn't contribute to the problem described here. If your case falls outside of these, let me know and we'll address it. > > - All VIC's open in same place, and I'd prefer tiled or offset > layout as each VIC appears, rather than being invisible behind another window. See point above. > > - "Open in venue" command is still available in data folder for > Powerpoint files. I know we discussed problems caused by this option. It'll be reviewed for the next release. I think it's very useful functionality, so if the problems with it can be resolved, that would be the ideal way to go. I believe we also discussed problems with the "Open for All" option that occurs on the sharedapp context menus. It's clear why that option would be problematic, especially without options to always accept or always reject those requests (possibly with per-site options). > > - Can still get RAT 4.40 MBUS errors by moving RAT window or RAT > preferences window. Holding left mouse button down while mouse is on the > window is sufficient to cause the mbus error. This is a RAT problem related to, I believe, Tcl/Tk blocking the application during GUI operations. I don't know the specifics, but it should really be a bug in the UCL trac for RAT. > > - After rebooting the PC, 3.2 starts in unicast even though the > preferences "use unicast" box is unticked. Multicast unavailable remains on > display in Venue client window even after "use multicast" is selected. But > after closing and restarting AG, multicast available is displayed. "Use unicast" means use unicast without regard for the state of multicast. When unchecked, the system uses multicast if it determines that multicast is working (by trying to receive data from the configured multicast detection group, see Preferences); otherwise, it falls back to unicast. > > - The name of the selected virtual venue is no longer displayed > under the server address in big bold type. Not essential, but useful since > some people give a single-click on the virtual room and don't actually go > there as it normally requires a double-click. The name of the current Venue has migrated to the Venue Client title bar, so it also appears in the icon title when the VenueClient is iconified. > > > Regards, > Lloyd Pearson > AVCC Operator > University of Otago > Ph +64 3 479 8997 > lloyd.pear...@otago.ac.nz >
