Summary: Some people dislike that the Module Manager remains open after launching a module. (However, the thread is worth reading for the hilariously bad advice which one of the posters gives for how to close the Module Manager…)
My first response was that the real problem the posters on this thread have is that they use a window manager which doesn’t let them group windows. On reflection, I still think that Windows is a crap window manager (consider that it has about the same feature set as twm had circa 1987), but it got me thinking about whether there really is any utility in keeping the MM running after a module is started.
I think these were the reasons why we made the MM persist:
To prevent more than one MM from running at a time.
To collect all logging from all running instances of VASSAL:in one file.
To prevent a module from being loaded while being edited.
(If there are more reasons, someone should remind me of them.)
I think all three of these reasons are bad ones for keeping the MM open after launch. The code we have now for preventing multiple MMs from running is does not depend on whether the MM stays open after a module is launched. There’s no problem with having each MM start a new log, and then hand that log file off to its child process when the MM closes. Finally, we could use file locking to prevent a module from being edited twice or loaded while edited. This would provide even more safety than we have now, as on some systems file locking would prevent such nefarious things as the module being deleted out from under us, also.
A major reason for the complexity of the code in VASSAL.launch is that the MM has to communicate with (potentially) several child processes. We could pitch a few hundred lines lines of code if the MM didn’t have to do this, and it would make the MM code a lot less twisty.
Thoughts? Does anyone here like the fact that the MM stays open now?
Absolutely! When developing (modules, not Vassal), I am often jumping into and out of a module. When making major changes, you just need to quit and restart. It would be a pain to have restart the MM every time. I would vote for a new Global preference ‘Close Module Manager after opening module’.
Alternatively, I would be happy if the MM closed when playing a module, but did not close when editing a module.
But, in the greater scheme of things, it is of low importance to me. I would not fuss whatever is decided.
Also, why couldn’t these people just minimize the MM? Or ignore it and let it drop into the background. Their actual argument for closing it nonsensical.
Is there really a big difference for you between bringing the MM back from
being minimized and starting it again? I would expect it to be one click
either way. The MM should start much faster the second time than the first
time, as a big chunk of the load time on the first startup is getting the
Java libraries in memory. For comparison, how long does it take you to
get a new MM if you close an MM and then immediately start a new one? If the
issue is that the MM starts too slowly even the second time, then it might
be worth looking at why (my guess: reading module metadata, which we should
cache) to see if it’s possible to optimize most of the startup time away.
That would involve doing all of the work to make the MM close after
loading a module without giving us any of the benefits of making the
code simpler.
I think it bugged them having an extra window in their minimize list. I
agree that their argument is a poor one. I’m only interested in it
because of the conclusion they draw.
Ah, you use it differently from me. I tend to have 10+ windows open at
once, so I’ll always minimize the MM when I’m not using it. Even if I
didn’t, some other window would get in front of the MM before I wanted
it again, so I’d still have to change focus somehow.
by people complaining about things in the wrong places. I don’t know why,
but there are people out there who will say “OMG, WHY WON’T THE DEVS FIX
THIS!!?” in places where no reasonable person would expect the developers
ever to see it. I’ve seen this for many, many different pieces of software.
It’s stupid, but there it is.
At least for testing, since I’m not really that active in playing
games with Vassal right now. But being able to launch more than one
module, or to not have to re-launch if I’m doing tests such as trying
a module, changing the preferences, and then re-opening it is
convenient.
But then, I’m a Mac user, and typically have lots of windows open at
once. My impression from watching Windows users is that they prefer
to have a single window open at a time, and have it fill the screen.
I have lots of overlapping windows and find it more useful to have
that ability. I would also imagine that for someone engaged in
multiple (PBeM) games at the same time, it would be convenient to open
them all and then proceed to doing the moves.
On the other hand, I can see that for players who only play one game
and perhaps only have a single module downloaded, it would seem to be
in the way and not give any particular benefit to have the module
manager stay open. Based on numbers, I would guess that there are a
lot more users who have only a single module than users who have
multiple modules – but I have no data to back up that supposition.
So, if the developers decide to make the module manager exit, it would
be nice to make that controlled by a preference rather than be
automatic. That way one could tailor the behavior to the likes of the
individual user.
I’d like to see it close after you’ve launched a module, as mentioned Windows sucks at grouping and I’d prefer to have just one tab rather than two or three.
On Wed, May 13, 2009 at 09:18:22AM -0700, Dezartfox wrote:
And I would prefer it stays open because I have a decent window
manager, and starting a new VASSAL process is a pain in the butt for
me half the time (running as a different user and redirecting the
display). I fully realize that my use case is an extreme border case.
Jeff
–
“The man who does not read good books has no advantage over
the man who cannot read them.”
– Mark Twain
I would prefer to leave it open when editing modules. Playing I really suppose it does not matter much to me either way.
For playing preference for one or the other for me would be purely aesthetic.
For editing for me it is pretty important, the way the program is structured right now, to leave the MM open. Many, many, many, too many edits do not save and load properly in the module editor without an editor restart (the real crux of this problem).
This means right now if/when you have to save, quit the editor, and restart the editor that is painful enough. If quitting the editor took you all the way out of VASSAL and you had to restart the Module Manager that would be worse.
So for me the inconvenience of having to restart the manager when editing a major change trumps the aesthetics of having to deal with an extra minimized window tab.
But… eh… it is not vital, the sky will not come crashing down if you decide to do otherwise.
a) have the module manager invisible if the player is launched by double clicking on an actual module?
and
b) close the module manager automatically, if the player is launched by double clicking on an actual module?
My guess is no. I don’t believe that we know how VASSAL was launched.
M.
P.S.: I think we should add the task manager trick to the FAQ. I found it inspiring.
and… I found this one (I am now 100% Fedora so I had no idea, but here it is…)
so this may really be an odd issue…
EDIT - oddly, I just tried this on my Fedora 10 x86_64 Gnome 2.24.3 and it groups the Module Manager window separately from the Editor windows. So one can not get rid of the MM window by grouping, although one can combine the two windows for the editor into one group.
I don’t know that Linux and Windows XP/Vista are really that different in this regard then?
Windows does group tasks that are not part of the same process tree. I’ve tested this with another program (Putty), started 4 of them, they are all running as completely independent tasks and Windows happily groups them.
I’ve tried to find out exactly what is required to enable the grouping to succeed, without success so far.
Vista won’t group the MM with a Player because they are running different programs on the command line
MM : C:\Program Files\Java\jre6\launch4j-tmp\VASSAL.exe
Player: C:\Program Files\Java\jre6\bin\java
So any number of Players and Editors windows will group together as a group of ‘Java’ applications, while the MM sits by itself as a ‘VASSAL’ application.