The original scope of this project saw mViewer Python as an extension to the Python environment; all of the real control was to be done there. As often happens, experience with a working system affected that thinking. Once you start interacting with a user interface, in particular, you subconsciously expect to do all the usual user interface things. And once you use a tool in its designed mode you start seeing other modes where it could be useful.
It has become apparent that there are improvements that would make mViewer much more useful and are described here. This list will evolve as we add functionality and receive more feedback.
The original idea was (and is) that a user/programmer in Python would marshall resources themselves, defining what images to display, how to stretch things, what overlays to place in what color, etc., then hand this off to mViewer to see.
Sitting in front of the interface, the first question is always "How do I open a file?", expecting a GUI widget. While the intent of mViewer was not to be just another interactive image display (and that is still the main focus), it was inevitable that that would immediately become a standard use pattern.
Fortunately, getting directory information from inside Python is straightforward as long as the information shown is fairly local to one directory (navigation with up/down/full-path controls), so file selection is not an overly complicated extension to make.
Note: This work is done, though we haven't properly written it up. If you run mView.py with the "-s" flag set, it will output a URL instead of bringing up a captive browser. You can paste that URL into any browser on any machine (firewalls allowing).
There are really two processes involved in the interface: Python as a web server and server-side compute engine, and the browser as a client-side display/interaction engine. As we fire up the browser from Pytho, it resides on the same machine. This makes sense if your data host and your display are co-located.
Many researchers, however, find themselves with a powerful desktop machine but their data on a server, essentially using the desktop as a remote terminal when performing data processing. For them, it would make sense to be able to fire up the mViewer Python code on the server with the data, then separately tell a browser on their desktop to connect to that session and act as the display interface for it.
This is remarkably easy: we just turn off the firing up of the browser from Python and instead emit an address for the user to cut and paste into a browser window.
Security is an issue, but not much of one. To start with, both processes are generally started by the same user and inherently have their permissisons. Second, the Python web server is starting on a random port known only to the user when they cut/paste. Finally, real security can be added using secure sockets or by encrypting the communications deliberately. Certainly the common use case of two fairly local machines within a firewall can be supported. Using a VPN connection, we have prototyped this on a home/work connection.
One of the things that is still done pretty manually and is hard to get right is symbol scaling when displaying a catalog overlay. This can be linear or logarithmic, based on flux or on an astronomical magnitude. However, it should be possible, using histograms of values, to make most of these decisions in an automatic way. This is probably something that will be addressed in future iterations of the Montage package C code.