Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Sat Aug 02, 2008 3:47 pm   

Package sharing?
 
OK, I thought that when you shared packages, they would be shared--and by that, I mean that they would (or could, even if manually) synchronize themselves between the sessions using them at the same time.

So I create two sessions, "testA" and "testB", and a package they share between them, "test".

I open both sessions, each in its own CMUD instance (offline for this test, since I didn't want to bother with an actual game). Changes I make to "test" in either are only seen in the session I made them in. If I make changes to different settings, luckily it seems that the changes are merged on saving. However, if I make changes to the same setting, then whichever session saves last "wins" and overwrites the first.

With some more playing around, I guess the package shares like I would expect if I open both sessions in the same instance of CMUD. But that won't work for me.

This is how I was thinking of playing. I have played in a number of MUSHes at the same time. I want to connect to the N characters I have (N > 5) in any combination I want, and each has it's own window configuration. This seemed to be a perfect reason to use multiple CMUD instances for each. But I was going to set up packages for the game, and for the codebase, so that I could share easily among them all. So I'd probably have a "common" package for CMUD-generic stuff, a package for a given codebase (PennMUSH, TinyMUSH, or TinyMUX), a package for the individual game, and then the unshared package that is the character.

I can still do that, but is there any way I can "reload" one of the shared packages once I make a change in one of the instances? Otherwise, I'm in danger of editing the same setting in more than one of the instances, and losing one of the changes when I exit. And, I guess, this pretty much nixes any idea to keep any shared state between the game packages (like a common list of "buddies" for a game), since this could very easily be updated from more than one instance.

In zMUD, I used inherited settings, which had the same behavior of not updating the sessions using it. But at least it would make it hard for me to update the inherited package in a way that I would lose an edit.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Aug 02, 2008 5:07 pm   
 
No, this isn't what "shared" packages are. The "Shared" property just means that if you open 2 sessions that use a shared package in a *single* instance of CMUD, only a single copy of the package is loaded. If Shared is disabled, then each session would each load their own copy of the package.

When using multiple instances of CMUD, nothing is synchronized or shared at all, sorry. It's important to keep any data that is session-specific or that can change within the individual session files and not stored in a shared package.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Sat Aug 02, 2008 6:04 pm   
 
You haven't really explained why you need to use more than one instance of CMUD. If you are only using one instance, it should work.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Sat Aug 02, 2008 7:23 pm   
 
Because what I'm looking for are session windows that are basically independent of each other on the screen (I don't mind if they are in the same instance). Meaning that I can move them around, have one on top of another (or on top of other applications), minimize each separately, etc.

To illustrate:

1. Create 3 sessions, I called them testa, testb, and testc. I didn't fill in any MUD connection info, because for this I'm going to open them all offline.
2. Open each in turn, in a separate instance, doing a "#WIN Chat" to make a docked Chat window above the primary window.
3. Quit all instances.
4. Open testa in a fresh instance (offline)
5. Open testb in the same instance (offline)--Here we see the first inconvenience. It's opened into a tab in the main CMUD window.
6. Drag the testb tab out to make an independent window--next inconvenience, it's opened into a very small floating window.
7. Manually resize it, and yes, it does retain the Chat/testb windows in their docked locations.
8. Move this window to overlap the main window, with testa/Chat. Next inconvenience--it is always on top of the main window.
9. Open some other app, place it over the testb window. Next inconvenience, clicking in the testa window puts the testb window on top of the application--a pain if you're copy/pasting/editing between the two.
10. Mimimize the main window--next inconvenience, both testa and testb minimize.
11. Restore both, then minimize the testb window. It becomes this little titlebar at the bottom of the Windows screen.
12. Double-click this small titlebar--next inconvenience, it restores as a tab in the testa main window.
13. Drag it back out, it does float at its original size.
14. Now open testc (offline) in the same instance--Same expected inconvenience as before, there it opens as a tab in the testa window... BUT major problem, testb disappears. It's not a tab, it's not a minimized titlebar, nothing. It is in the CMUD Windows menu, though.
15. Select testb from the CMUD Windows menu--another inconvenience, it opens as a small window.
16. Resize testb--next inconvenience, where is the docked Chat window? You need to select it from the menu, then redock it.
17. Use the package editor to view testa's, testb's, and testc's windows setting. Each say that the testa, testb, and testc packages are all enabled for each window. But I think that's a lie, at least, because I couldn't seem to #SH a variable I defined in one window from another.
18. Close the testb window group, then try to re-open it into the same instance. Nothing happens.
19. Use the PE. You will now see two tabs for testb's package. Click on either, and inspect the testb window. The "Window is visible" setting has been cleared.

I concluded from this that I just couldn't live with that behavior. What I'd really like is that CMUD act like Firefox. Each window, while all running in the same instance, acts like a completely separate application. If I minimize one, only that one does. If I click on one, only that one comes to the front. Each has its own tabs, but of course, there's no "docking" in Firefox.

I currently have 11 characters that I can connect to on 8 different MUs. I probably only connect 2-3 at a time out of that set, but which I connect is mix and match.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Sat Aug 02, 2008 10:11 pm   
 
Zhiroc wrote:
5. Open testb in the same instance (offline)--Here we see the first inconvenience. It's opened into a tab in the main CMUD window.

What's wrong with that? Seems fine and how I'd expect.
Zhiroc wrote:
6. Drag the testb tab out to make an independent window--next inconvenience, it's opened into a very small floating window.

True, it could be bigger given that it already contains 2 windows, but no big deal IMHO.
Zhiroc wrote:
8. Move this window to overlap the main window, with testa/Chat. Next inconvenience--it is always on top of the main window.

Confirmed. Hmm, that might be a bug given that "Stay on Top" is not on.
Zhiroc wrote:
9. Open some other app, place it over the testb window. Next inconvenience, clicking in the testa window puts the testb window on top of the application--a pain if you're copy/pasting/editing between the two.

Confirmed (had to reduce the size of the main CMUD window to reproduce this properly). Again, this is probably something that can be fixed / improved (maybe only if you set "Task bar icon" for testb, which still currently suffers from the same problem).
Zhiroc wrote:
10. Mimimize the main window--next inconvenience, both testa and testb minimize.

True, but this is what I would expect given you pressed the minimize icon for the application. You can solve this by making testa an independent window and making the main CMUD window much smaller: now you can minimize testa on it's own.
Zhiroc wrote:
11. Restore both, then minimize the testb window. It becomes this little titlebar at the bottom of the Windows screen.

True, but again, given that it has no taskbar icon, there needs to be a way to restore the window. If you do give it a taskbar icon, you don't get the little titlebar.
Zhiroc wrote:
12. Double-click this small titlebar--next inconvenience, it restores as a tab in the testa main window.

I can't reproduce this: for me it just pops up the Window menu. Correction: I was playing with testa which I had also dragged out. testb does restore to a tab in the testa window (which is also still dragged out), so that is confirmed. A bit weird that the behaviour is inconistent here. Clearly, despite me having dragged both testb and testa into separate windows, testa is still the primary window. I'll redock testa with the main CMUD window, having made it big enough again.
Zhiroc wrote:
14. Now open testc (offline) in the same instance--Same expected inconvenience as before, there it opens as a tab in the testa window... BUT major problem, testb disappears. It's not a tab, it's not a minimized titlebar, nothing. It is in the CMUD Windows menu, though.

No, it hasn't. It's still visible, although my main CMUD window is over on the left while my testb is over on the right so it would be odd if it did disappear since they don't overlap. Hmm, even if I maximise the main CMUD window, testb is still floating over the top. I think I'll have to skip to 17 with my reproduction attempts here since I can't continue.
Zhiroc wrote:
17. Use the package editor to view testa's, testb's, and testc's windows setting. Each say that the testa, testb, and testc packages are all enabled for each window. But I think that's a lie, at least, because I couldn't seem to #SH a variable I defined in one window from another.

Settings in _windows_ are not visible to other windows in other packages. They have to be in modules. So you need to create a module within e.g. testb and set it to Global. However, I'm not sure of the syntax to access these variables. EDIT: Just using @avar works if in a Global module.
Zhiroc wrote:
18. Close the testb window group, then try to re-open it into the same instance. Nothing happens.

Not quite true. For me, another Chat window opens. But testb does not. So there is clearly a problem here.
Zhiroc wrote:
19. Use the PE. You will now see two tabs for testb's package. Click on either, and inspect the testb window. The "Window is visible" setting has been cleared.

Confirmed. I did notice something somewhat similar (most likely the same bug) the other day with an earlier CMUD version, but I thought it might be related the New Connection stuff I posted bugs about.
Zhiroc wrote:
I concluded from this that I just couldn't live with that behavior. What I'd really like is that CMUD act like Firefox. Each window, while all running in the same instance, acts like a completely separate application. If I minimize one, only that one does. If I click on one, only that one comes to the front. Each has its own tabs, but of course, there's no "docking" in Firefox.

Agreed: this behaviour seems best for my purposes (not so important if you are always in CMUD, but if you are multitasking...), each with it's own independent taskbar icon too - currently they all change state together even if you have separate task bar icons for each session. And "Boa Constructor" is an example of an application that has independent sub-windows but a main panel at the top (where the CMUD menu bar and toolbar can go).
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Aug 02, 2008 10:37 pm   
 
I'll look into this more after WorldCon when I'm back on my development system. But in general I am limited by what the Window Docking system that is used in CMUD can do. This is a 3rd party component and is very complex because Windows itself doesn't support docking multiple windows (like multiple windows with their own menus) into a single window.

The docking system does a lot to try and keep undocked windows "on top" of the main application window. This is because otherwise it's too easy for a window to get lost behind the main window where you can't access it. Windows has several bugs dealing with "stay on top" windows, and you can see these bugs sometimes when dealing with Windows dialogs (like the File dialog, or the File/Open dialog, or an error dialog). These windows are not handled by the docking system (they are built-in Windows dialogs) so the docking system can't handle making sure they stay on top. In other words, without this feature in the docking system, then floating MUD windows would also disappear behind the main application window and be hard to access. Or course, you *can* turn on a task-bar icon for each of these windows, which can help some. But not everyone wants their child windows to all have task bar icons.

Double-clicking a window in this Docking system toggles it between being docked or floating. Double-click should not be used to "restore" a minimized window. Click the "restore" button in the window caption to do that.

So yes, there are some "inconveniences" involved in the window docking system (like windows getting on top of other applications), but the reality is that there just isn't any way to do this all "perfectly". Everyone has different needs and I've learned that I can't please everyone. I chose the best window docking system that is available, and I don't plan to spend my time trying to tweak their source code (which then prevents me from updating their components when they fix bugs or add features). I used to do a lot of "tweaking" of 3rd party components and that just resulted in a less stable application where I couldn't keep up with 3rd party bug fixes. With the 2.0 version of CMUD I went away from that philosophy and have adopted a new philosophy where I don't modify 3rd party components unless I can do it in an object-oriented way that doesn't involve directly editing of their source code. Because the docking system acts at a low level with the Windows API, I have less control over it than I do with other 3rd party components.

But even so, the current system works well for most users. Sorry it doesn't work as well as you need it to for your situation.

Like I said, when I get back I will run through your specific testing steps to see what I can reproduce and which are bugs that I can actually fix and which are just things that need to be lived with. But honestly, this kind of stuff is a very low priority right now as I'm working on the mapper stuff. So you'll have to be patient with it.

Finally:
Quote:
Because what I'm looking for are session windows that are basically independent of each other on the screen

You say this, but then you talk about those sessions trying to share a package. Running 2 instances of CMUD is the way to handle two sessions that you want to be completely independent. So there is nothing wrong with doing that (and it's why CMUD does that and zMUD doesn't). But if you want your sessions to be independent, then they should *not* try to share a package. As soon as you do that you are making the sessions dependent, and for dependent sessions you should be running them within a single instance of CMUD.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Sat Aug 02, 2008 11:27 pm   
 
Zugg wrote:
The docking system does a lot to try and keep undocked windows "on top" of the main application window. This is because otherwise it's too easy for a window to get lost behind the main window where you can't access it. Windows has several bugs dealing with "stay on top" windows, and you can see these bugs sometimes when dealing with Windows dialogs (like the File dialog, or the File/Open dialog, or an error dialog). These windows are not handled by the docking system (they are built-in Windows dialogs) so the docking system can't handle making sure they stay on top. In other words, without this feature in the docking system, then floating MUD windows would also disappear behind the main application window and be hard to access. Or course, you *can* turn on a task-bar icon for each of these windows, which can help some. But not everyone wants their child windows to all have task bar icons.

There should be no way to lose a window: you should be able to Ctrl-Tab to it or find it in the Windows menu (and make it visible from there). Therefore there should be no reason to use "stay on top" behaviour (the Windows form) unless the user specifically want it, and there should be no reason to keep undocked windows "on top" unless the user specifically asked for "floating" behaviour (the docking system form of on-top-but-only-in-the-application). Maybe the solution is to change the behaviour when the user ticks the Taskbar icon option so that the window becomes completely separate in terms of its window-like behaviour (independent minimise, restore, etc. and crucially Alt-Tab and click on taskbar), basically by CMUD spawning a new instance of the docking system with this window in it. This would make it impossible to redock the window into another window without first unticking the Taskbar icon, but I don't think that's a big problem - in fact I think it's better that way: it's too easy to screw up your layout at the moment by docking a completely separate session into another session (which I did by mistake once when I was trying to replicate the above procedure).

Edit: Having a window with a taskbar icon but not in Alt-Tab is pretty weird anyway! I think the manual should also be in Alt-Tab if you gave it a taskbar icon, and be a properly independent window, i.e. if you click on it in the taskbar, it is only the manual that comes to the front and not all the CMUD windows.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Sun Aug 03, 2008 1:12 am   
 
I'm on XP Pro SP2, btw. No guarantees on what happens in Vista :)

The problem is that the window behavior I want, I get with running multiple instances. The package behavior I want, I get by running in one instance.

BTW, in zMUD, I run nothing in "the main window". In fact, I have no main window at all, except for the toolbar. Every session is run in two floating windows (a "main" one, and the Chat one), placed one on top of another. Each time I open a session, these two floating windows get created in the last place they were on the screen. In the case they overlap, whichever I click in last is on top of the other.

Yes, I get the "all zMUD windows go on top of all other apps" and the "minimize a window produces a small titlebar" effect. Wanting the fully independent windows is part of a nirvana. But try as I might, I can't get a single CMUD instance to give me as close as I've gotten to my desired window behavior. If I start with the docked testa windows in the main one, if I undock them I'm left with a big blank main window. If I open a new testb session, it isn't open undocked like in zMUD, but docked into the main window.

What I'd probably think is the way I'd like to go, is to run multiple instances. It's probably easier not fighting with the windows docking system. I can probably write the packages in a way to be read-only. It looks like variables that don't exist are created in the window if run by either alias or trigger, so that is good. But existing variables in the shared package are modified in the package if the code writes to them.

For this to work well, I think I'd need a way to "reload" a package by hand. So, I could modify the "shared package" in one of the instances, then manually save and update other running instances. That wouldn't be a real chore to me. (I don't see a way to do that in the PE right now).

It would also be nice (but I think I can get around this), if a "read-only" package (or we can call it something else) always:

a) when a variable inside it is updated by code, creates the variable in the same class in the window. This allows you to make the package variable be a default, but if the script modifies it, the window gets a private copy. This is very much like how virtual memory systems handle "sharing of private data", called copy-on-write.

b) Such a package's scripts will first look from the window, rather than the package itself, when trying to read a variable.

A last thing I'd want is for CMUD to alter its titlebar so that when running multiple instances, I know which is which on the taskbar.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Sun Aug 03, 2008 1:38 am   
 
Zugg wrote:
Quote:
Because what I'm looking for are session windows that are basically independent of each other on the screen

You say this, but then you talk about those sessions trying to share a package. Running 2 instances of CMUD is the way to handle two sessions that you want to be completely independent. So there is nothing wrong with doing that (and it's why CMUD does that and zMUD doesn't). But if you want your sessions to be independent, then they should *not* try to share a package. As soon as you do that you are making the sessions dependent, and for dependent sessions you should be running them within a single instance of CMUD.

To be clear, I want the "windows" to be independent. I don't mind if they interact behind the scenes (i.e., sharing packages).

Think Firefox. Independent windows, but they all share the same memory image, cache, settings, etc.

There may be nuances of sharing packages between sessions... and how to make that work is yet to be seen. For example, take a common case of a "buddy" package that highlights certain character names. It makes sense to have the code shared between all the sessions (particularly if you are the developer). Update the code once, all your sessions get the benefit. But the data/configuration... that's a different question. "Bill" may be your buddy on game A, but not the "Bill" on game B. Thus, the data has to be different.

This is very much like Operating Systems and libraries. Generally speaking, code is always shared, but data is either not shared, or shared via a copy-on-write system (much like I described in another post).

My desired scheme for packages is to have one for the character (of course, the private package for the windows). Then one for the "game", one for the "codebase", maybe one for a "generic codebase" (i.e. shared between MUSH/MUX codebases), and then one for "code/game independent settings" (e.g., the Buddy package is essentially non-specific to codebases). This setup would let me keep one copy of things and let me share all that work as I move around games/codebases.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun Aug 03, 2008 1:52 am   
 
For your item labeled "b", the design is actually the reverse. When using a variable name that does not have specifically defined location: a script referencing that variable will look first it its own package, second in the window that controls the script, and finally in all other packages that window can see. This particular piece of the scoping order was hammered out during extensive testing. The idea is that a variable included directly in a package should take precedence over any other variable of the same name. Part of this is based on the idea that a package author will include variables they expect to use nearly exclusively within thier published package. Another part is that 2 authors may use the same variable name for very different values.

The next part of what was hammered out in the whole scoping process was where a new setting of any kind should be placed. It was determined that the right place was the window that is controlling the script creating the setting. This once again goes back to a package author not having that setting as part of thier package. The particular setting is expected by the author to be window specific, and they need to be able to have it behave that way.

Actually your item 'a' seems to be requesting exactly how things are. As I described above, the scoping rules seem to provide what you want. I am not totally sure that your 'a' and 'b' are mutually exlcusive, but I think they are.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1244

PostPosted: Sun Aug 03, 2008 2:26 am   
 
Zhiroc wrote:
I'm on XP Pro SP2, btw. No guarantees on what happens in Vista :)
I'm on Vista SP1.

Zhiroc wrote:
It would also be nice (but I think I can get around this), if a "read-only" package (or we can call it something else) always:
Packages can already be made read-only - next to the shared check-box.

Zhiroc wrote:
a) when a variable inside it is updated by code, creates the variable in the same class in the window. This allows you to make the package variable be a default, but if the script modifies it, the window gets a private copy. This is very much like how virtual memory systems handle "sharing of private data", called copy-on-write.
This is also how Vista 32-bit works for the Program Files path (for stuff like ini files). It might be nice that if a package was read-only, writes are redirected to the window (or maybe they are already are).

Zhiroc wrote:
A last thing I'd want is for CMUD to alter its titlebar so that when running multiple instances, I know which is which on the taskbar.
That would be nice.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net