All great questions and observations. I've included some comments below, but some of the developers on the Update Center project will be following up on specific topics. They're all motivated to receive feedback, consider it and make improvements in the user experience. Clearly there are some practical constraints involved, but I suspect there are also some improvements that will be straightforward.
Thanks,
Chris
1) Coordination amongst the parts:
The Software Update GUI (the cute one) and the Update Tool GUI (the manually started one) do talk to each other behind the scenes. Not having the SW Update GUI come up when the Update Tool GUI is already running is certainly an enhancement that we could consider rolling into the code. The interaction is present, it's just a tweak to modify the behavior under this circumstance.
2) Install pre-requisites:
Users do not need to install wxWidgets and Python outside of the packages that are installed via GlassFish. If someone encounters a situation where they felt compelled to install these components outside of what's delivered as part of GlassFish, then there's a bug.
As was pointed out, on Linux 64-bit platforms, some additional 32-bit compatibility OS level packages (not Python, not wxWidgets and not X) may need to be installed separately. Details here:
http://wiki.updatecenter.java.net/Wiki.jsp?page=UC2Documentation.ReleaseNotes.2.3#section-UC2Documentation.ReleaseNotes.2.3-PlatformRequirements
This is an aspect we are enhancing on two fronts:
* Expressing external dependencies within the packages such that they can be flagged during installation. Thereby avoiding cases of clicking on something and it not working.
* Ideally, eliminating the external 32-bit compatibility dependencies by embedding proper 64-bit minimized native binaries.
3) UI inconsistencies and fit and finish:
Please elaborate with specifics. The team will assess and attempt to address any of these issues. We're aware of some, but you may have uncovered additional issues. If you don't mind sending details and screenshots to dev_at_updatecenter.dev.java.net, that would be helpful.
4) Multi-threading:
The Update Tool GUI uses threads in a number of circumstances, but your observation about the single threaded operation during download is probably accurate. Our lead developer of the GUI will follow-up on this thread (no pun intended!) to better understand what functions apart from "cancel" you would like to perform while an update transaction is in process. This is less of a Java vs Python topic than a "what would the user like to do?" topic.
5) Why not Swing?
Pretty simple: Since the underlying pkg(5) packaging system is mainly implemented in Python and during initial development of the Update Tool in 2008 there was no cost effective Java->Python solution, using a multi-platform, Python-based GUI framework made sense. Otherwise, we would have happily used Swing from the get go.
If and when the currently thin Java binding to pkg(5) greatly expands, then we would be in a better position to reimplement the GUIs in Java. The good news is that the substantial amount of underlying logic is proven and can be reused.
BTW, it's pretty funny in that developers and users of some of the non-Java products that use Update Center and the pkg(5) system are actually pleased that the GUIs and underlying pkg(5) system are not written in Java. We hear cries from these quarters of "Don't make the user install Java!" I suppose we just can't win. :)
More FAQs on the overall Update Tool and underlying pkg(5) system are available here:
http://wikis.sun.com/display/IpsBestPractices/Frequently+Asked+Questions
[Message sent by forum member 'ckamps' ]
http://forums.java.net/jive/thread.jspa?messageID=371729