Windows 7: improvements and suggestions

Hey Nick,

I've been using W7 for a few weeks now and I figured I ought to name some annoyances I have with it so far, or improvements for that matter. Some might not be as W7 centered, but all-around I'm trying to go for usability here. :)

1) Updating the open/save dialogs. They are still using the old-style, and not nearly as slick in daily use as the new windows are. (Somehow the old style is too cramped and not nearly as useful to me when browsing for files.) I think it should be simple to implement based on this link: http://windowsteamblog.com/blogs/developers/archive/2009/04/16/light-up-with-windows-7-libraries.aspx

2) Fixing the World Configuration dialog. (Yeah, I'm bringing that one up -again-. :P) Concrete annoyances I am dealing with are as follows:

2a) The left treeview with all the different pages doesn't get redrawn properly. Clicking around leaves focus rectangles, using arrows leaves everything in a permanent selected state.

2b) Since using W7, I moved my taskbar vertically since it is far more useful that way on my widescreen setup, and it simply supports that better natively speaking. But because I vertically maximize MUSHclient right next to my taskbar (shortcut: Win+Shift+UpArrow), the world configuration dialog ends up having half the stuff under my taskbar due to that window being wider than my MUSH window. I'd love it if it could either remember the last-used position, or keep the real-estate on the current screen in mind and adjust accordingly. (Yeah I have two screens too - aren't those things a pain to program against? :/) I think I don't suffer this issue with other popups due to them being smaller, but I'd love for those to get similar treatment.

3) W7 has these nice new features for the taskbar. I'd love to make use of those. (I think there is the Windows 7 Code Pack or something with the appropriate headers)

3a) Pinning MUSHclient and right-clicking supports having a Recent list in there, called Jump Lists. I'd love to see that implemented since MUSHclient already does that under the hood anyhow.

3a+) I realized while writing just now that would probably start a new instance of MUSHclient. A new global option to have stuff started that way open in an existing instance of MUSHclient would be nice as well. (Before you ask what the advantage of this over the File->Recent Files menu is, this one allows you to pin often opened files, which beats having shortcuts all over your desktop or digging for particular world files.)

3b) There are other nice APIs available for the taskbar as well. The 'Progress Bar'-button comes to mind, which could be used from a scripting environment. You could use those for lengthy operations like searching a buffer, converting the spellcheck files, etc. There's several others as well such as Icon Overlays (think of a notification image when an immortal beeps you, you are being attacked, etc. Plenty of options there.) and thumbnail support (for which I have several ideas that would be nice to have, but I won't spam them here as they can be considered nice bonuses). All of this stuff would make for awesome stuff to use while scripting.

4) I think there's still some issues remaining with the installation locations and paths as well, although I didn't write them down. Never the less, I'll mention here where I believe files should be placed.

Plugin state files: C:\Users\XXX\AppData\Roaming\MUSHclient\state or whatever you want to call it.
MUSHclient settings: C:\Users\XXX\AppData\Roaming\MUSHclient\
Default example plugins (both the current scripts and worlds\plugins directories): C:\Users\All Users\MUSHclient (Perfect choice? No. But they are default 'user files' and should thus be user accessible, and as such do not belong in AppData\Roaming. Program Files is a bad location as well due to permission issues, but it might be acceptable as long as the directory structure implies they should not be used as live files to modify, eg \PF\MUSHclient\examples\.)
Default plugin-directory: My Documents / Documents library. (Perfect choice? No. But they are user files and should thus be user accessible with notepad etc, and as such do not belong in AppData\Roaming.)
Default world-directory: See the default plugin-directory above.

5) At some point, it would be nice to move away from the old Windows .HLP format. Yes, it works, and personally I prefer it over many of those HTML help things, but it is outdated and in need of updating. To be honest, I can imagine MS not even offering the download for that program when Windows 8 rolls around.


Okay, I'm done. I hope I don't sound too demanding - I still love MUSHclient. But it simply feels clunky now that I've moved on from XP.

I've started using Win7 now too, removed WinXP totally. I'll give my thoughts about it and MC in a bit.

But I do agree about the look of it. CMUD has a major advantage over MC because of this, and a lot of players who play in a simple manner would pick CMUD. MC looks a lot like I'm using Windows 98 in Win7 and it just throws me off.

I've been testing MUSHClient 4.43 in a VM, running Win 7. I'll post back here, a bit more of the output/quirks/debugging info as I pull up more.

I've been using MUSHClient with the internal taskbar vertical for as long as I remember, and have never had an issue with the bar covering up a MUSH world, not even in Windows 7. Or, are you talking about the MS Explorer taskbar??

I'm talking about the global, refurbished taskbar. See the following screenshot: http://img407.imageshack.us/img407/3610/mushclientmeetstaskbar.png

Ok, I wrote a ridiculously long rant here, luckily for all you who have to read this, I decided to delete it and write something shorter.

As a user of an extremely outdated OS, all I can say is that as long as it doesn't break compatibility with my system, I don't care, but in my experience it is /frustratingly/ common for programs to stop supporting older stuff in order to make room for newer stuff, because the newer stuff simply will not work with the older stuff, either that or the programmer is just too lazy to keep supporting the older stuff and quite mistakenly assumes there's nobody still using the older stuff. One of the many great things about MUSHclient, is that it's still compatible with everything back to Win 95, which means pretty much everybody can use it, regardless of how old their system is.

I haven't had a chance to try Windows 7, I've heard them all say how great it is, but I still have yet to hear of a feature that I really need. I still remember when Win XP came out, and I looked at it, and saw they made the window borders unnecessarily fancy, other people thought how good they looked, all I thought about was how much extra space they wasted on the screen and immediately changed it to the classic appearance, same with the start menu, they didn't seem to make anything easier, they made it more complicated just 'prettier'. And I /still/ hate the fact I can't end tasks directly with Alt-Ctrl-Del and kill runaway programs that are eating up the processor, no I have to wait for the dialog to load up while the other program is eating up the processor, and they /stupidly/ made it so some programs can even lock me out from hitting end task on them, and give me permission denied messages even when I'm logged in as administrator, I actually had to pull the freaking battery out of my laptop in order to recover from one program that froze my system, because it would not let me shut down or restart. It's one of the reasons I still like Win Me, at least on this if a program gets run away, I can just kill it, on XP it seems I either have to restart my computer, or just try to wait it out. Granted at least I can tell /which/ program is eating my processor on XP, but it does me no good if I can't kill the process in question.

On Windows versions with the NT kernel (NT 4.0, Win2k, XP, Vista, Win7) the hotkey to bring up task manager directly is CTRL+SHIFT+ESC.


Expecting new software while refusing a newer operating system is not a lasting strategy...

The problem is, it is hard to get enthusiastic about spending hours making basically cosmetic changes, for a program that makes about $US 20 per month from donations.

As Cage_fire_2000 says, effort needs to be expended to make sure changes are backwards compatible as well, so that improving the program for the 5% that use Windows 7 does not break it for the 20% using Windows 98, for example.

I am pretty sure that I would need to upgrade my old Visual Studio to develop for Windows 7, so that is a cost of $US 299 for Visual Studio 2008 Standard Edition or $US 799 for Visual Studio 2008 Professional Edition (I'm not sure which one I need).



I can't reproduce that in my copy of Windows 7 - looks OK to me.



I agree about improving the installer, that is on the "to do" list. That affects Vista, Windows 7, and possibly XP to an extent.



Remembering where you put the configuration dialog would be a simple change, at present I think it centers it.

---

Remembering that MUSHclient is open source, anyone at all can release a "Windows 7 revamped version". As for me, I don't mind making changes, like remembering where you last put the world configuration, if I can do that without having to pay hundreds of dollars for Visual Studio.

I believe Standard would suffice. In fact, I'm using my Academic edition... though I think that comes with limitations on commercial use.


I've wanted to try porting it to C#, but I haven't had the interest lately. One of the big benefits would be getting away from MFC, among others...

EDIT: Also, it would be a LOT more conducive to the 'open source' nature of MUSHclient to have a public repository anyone could pull from to check out the current source. I especially love Git (and Github), and am using it for my widget framework development. Anyone can 'fork' the project, i.e. copy the repository (but retain versioning links), and you can merge branches, etc. I think it would fit MUSHclient perfectly... Maybe you should check it out?

As for porting, that would be great, apart from the extensive work required. If I had the energy, it would be nice to make a version that compiled under gcc, without needing MFC.

However as so much of it was developed using MFC, that is virtually a rewrite. There is extensive use of the MFC string classes, linked lists, dialog handling, and much of the scripting support uses MFC interfaces.

Probably it would be quicker to write a new client from scratch than go through, and virtually for every line, make a change to remove any MFC dependencies.

As for Git, I'll take a look at that.

I used to maintain a bzr repository, but nobody cared so after a few months I just stopped. bzr is basically like git in terms of distributed version control.

If there's interest, I can start maintaining it again.

David - Did you host it yourself, or was it on a GitHub-esque website? I don't have (much of) a problem downloading yet another VCS technology, but I really like GitHub's features and would rather stick to hosting there over self-hosting using another software.

If you'd host it at somewhere like GitHub or Sourceforge, though... could you post a link? I'm curious.

I hosted it myself. I prefer bzr over git (I find it makes the simple things simpler to do than git), and (at the time) there was little enough interest it didn't really make sense to invest in putting it up on LaunchPad (a bzr version of github).

Keep in mind that "hosting" git and bzr repositories means nothing more than making an http link available. There are of course other fancy features like nice web interfaces; I was using a bzrweb interface that did a lot of that.

All this said I don't have any stake in hosting this, I just did it because a few people said it would be nice to have a repository and it was easy for me to do. The only thing I care about is that Nick sanctions one place as the "official" repository, even if he's not the maintainer.

Aren't there any free headers available for the new W7 specific stuff? And I thought most things could be fudged around using GetProcAddess() to keep stuff working on older OSes.

The reason I am not messing around with the sourcecode myself is that last time I tried, I couldn't get it to compile for the life of me, and I read other reports of people having had trouble with it as well. If I need to put in more than 1-2 hours just to get a few simple warnings to go away, and even more to finally get it to compile, then it isn't worth my time to contribute.

So instead, I just throw suggestion after suggestion here on the forums. :)

I'm writing my own client based heavily on the core functionality of MUSHclient. Part of that effort is to update the look-and-feel of the app to a more modern XP/Vista/Win7 interface.

However, I'm moving MORE towards MFC and standardizing all the non-MFC stuff (Nick tends to lean toward STL these days) to use MFC classes instead. A big part of what I love about MS Visual Studio is the libraries for interfaces, utility, and debugging facilities. It's very well documented and very well integrated into the IDE. If anyone ever makes an IDE that comes even close to VS, I might consider making the switch, but I so far have had problems with every major non-VS IDE I've ever tried.

I haven't looked into the Win7-specific libraries yet, but I am using the MFC 2008 Feature Pack to incorporate some of the Office 2007 visual elements (and really liking it all so far).

As a final comment, I don't need the backwards compatibility in MUSHclient, but I know many, many people appreciate it a lot. I'm actually impressed that it continues to work well in newer versions of Windows with little trouble. It's always been a speedy and extremely stable application, which I personally appreciate immensely!

I agree MUSHclient is very speedy, I tried simpleMU once, and while I really liked the spawn feature it's very awesome, on my 933 Mhz computer, the GUI was peculiarly slow in comparison to MUSHclient for some reason, just clicking the different buttons seemed to lag strangely, I can't imagine why, but it did. I also love the scripting functionality of MUSHclient, there's very few programs that let you customize them with scripts(some that I /really/ wish they would as it would instantly multiply their usefulness ten fold and allow for much more versatility.)

MFC is very good to get things up quickly, like dialog boxes. The whole thing is fine if you don't mind being locked into a development platform you have to spend hundreds of dollars on every few years to upgrade, and only works on Windows, and not OS/X or Linux.

As for STL, you can of course intermix them. MUSHclient these days uses the MFC classes for lists, etc. for older stuff, and is moving towards using STL classes for more modern things.

Some of the list management in MFC is clunky, and it is hard to just convert to STL (they may have improved it). For example, when traversing a list you have to get the start position, *and* then the first item as two operations, like this:



Compare to STL:



The difference is that in the MFC version you have to get the pointer to the data *and* move the position onwards at the start of the loop. So, if the data happens to be the one you want you can't "remember" the position because it has already been advanced.

And, I can't move the GetNext into the for statement, because that is processed at the end of each iteration, and the GetNext has to be done at the start of the iteration.

In my example, pluginpos is now pointing to the *next* entry, while I process pPlugin.

However in the STL version, it (the iterator) is pointing to the *current* entry while I process *it (the data it points to).

This difference makes it fiddly to change to/from STL/MFC list operations without carefully thinking about what happens if you want to leave the loop early.

All good points, and I'm pretty well aware of the differences already, having used both for many years now. I still just find MFC easier for my own uses, and I don't mind being locked into the platform. (Cross-platform gets too messy too quickly for me to really even consider it when just coding my own stuff for fun.)

Microsoft has made some advancements with their use of ATL and WTL now, too.

I really like the MS coding practices, and I get a little sloppy when I start pulling in things like Boost or STL. It's just who I am.

That would be nice. Not sure if it has to be Git or Github though, since Bzr has Launchpad and SVN (if you don't want to use DVCS) has Sourceforge. Plus, there are alternatives to Github too, though I happen to like Github.

Is the project currently SVN? Switching to a DVCS isn't too challenging from SVN, though I've yet to transition a major project over.

It's currently CVS, hosted on my inhouse private server. I don't want to open that server up to the world, however I don't mind uploading the current version to somewhere, and then committing further changes to that place instead.

So, if we just take a snapshot of the current source, whether it is CVS or anything else doesn't really matter. The only way it would matter would be if someone wanted to compare (say) version 4.45 to version 4.38.

For me to host the source somewhere public I would need a system that I can put on the gammon.com.au web server. David Haley previously put up a BZR repository, however my mind had a bit of a brain freeze when I tried to understand how to use it.

I prefer to keep control over the source in the sense that I would like it to be on a server (like this web page) over which I control to the extent that ads don't appear, and that if I keep paying the bills, it will stay active.

Now if anyone wants to recommend a system that I can install on the Futurequest server, that will be easy for me to upload future changes to, please do. It would need to use:

• PHP for the web pages
• MySQL for the database (if any)
• Probably not require some other server running, as Futurequest may not permit that (although I could be wrong about that)

All of the version control systems discussed so far have web interfaces that let you explore the repository, so you don't have to use GitHub, Launchpad, SourceForge, etc.
You could move your CVS repository as-is and use one of the web packages (might be perl, not PHP) for online browsing.

Personally I would recommend against SVN since its branching is (in my experience at least) still kind of nasty, while being far nicer than CVS. You can always use DVCS programs like plain old VCS, where you have a single master copy and only commit to that, and don't bother with branching etc.

That said, I'm not sure what the exact goal is here. Is it realistic to think that somebody will fork the code, and it will later get merged in as-is? I think it's more realistic that patches will be accepted (with modifications etc.) in which case it doesn't really matter what VCS everybody is using. I think people can use VCSs for their own work, of course, as it makes tracking patches far easier, but I'm not sure that the work-required to benefit-obtained ratio is a good one yet.

As a matter of opinion, I would like to mention that GitHub is (a) free for open-source projects, and (b) you can take down the repository if you really feel like it. Git itself is actually quite easy to use, and I'm surprised at how easily I got into it after reading a couple of the tutorials at GitHub. In relation to David's mention of SVN's branching, Git branches are really quite wonderful.

I'm just curious, but is there any particular reason you want to host the repository directly on gammon.com.au? Like I said, you have a pretty high degree of control over the repository's existence with GitHub hosting. And really, GitHub is just a public face - since git is decentralized, you really have a whole repository on your computer, which you can locally commit to, etc, etc, and only push upstream (to the public repository) when you're ready. (I'm planning on having two public branches for my framework, stable and development, and merging from development to stable to mark official changes and updates. The development branch would be visible so that anyone could still see and check out the source of what's coming. It's really, really simple.)

EDIT: I should note, the public repository on GitHub is public only for reading; only approved collaborators can directly push to it, such as yourself.


David: It's not that unrealistic to expect interested parties to fork the code. At the very least, you can pull a copy of the code down to look at, which is one great benefit. And if you decide to make your own changes to it, there's no reason not to make a public fork. It helps to share ideas and innovation, even if briefly; WillFa forked my widget framework a while back in order to make a fix to the source, which I incorporated afterwards.



Not exactly a huge issue, considering that nobody can do that easily now anyways except by going backwards through the released source downloads. (As an aside, another big reason I'd love a public repository is because I can actually see the source after every release. Most source releases currently skip several versions... and the diffs file for 4.45 hasn't been released, at any rate, so at the moment you couldn't keep a local up-to-date copy if you tried. ^_^;)

<this part is optional to read>
Here's an example of a typical workflow for me with Git:

1. Make changes, test, typical stuff...
2. git status - see what files I changed, and if there's anything I created that needs to be added to the repository.
3. git diff <filename> - see what exactly I changed, helps when I'm reviewing my changes and/or writing a commit summary
4. git commit -a - commit my changes straight to the local repository. The -a flag just skips the 'staging area', which I haven't had a need for yet.
5. Return to 1 if I'm not ready to push to GitHub just yet, say, if I just want to save my work.
6. git push origin development - Push my changes in the development branch up to 'origin', i.e. the GitHub repository.

Only really a handful of commands. It all feels very easy when I actually do it, and I haven't been using it that long at all. (SVN always confused me regularly.)

The various library changes meant the diff would have been megabytes long, so a full source release is probably required.

Makes sense, it was just an afterthought. My point being, a publicly accessible system would eliminate the need for either diffs or source releases.

Well, sure, except that that the last time we went through this and I started maintaining a public repository tracking the released diffs, interest level was basically zero after the initial statement of "it would be nice if ...". :-)

FWIW, I'm not arguing against the idea of repositories in general. I'm simply observing that the development pattern for MUSHclient thus far, where changes are quite localized, has not seemed to make the need for forking very high. You say it's not unrealistic to expect people to fork, but, well, in practical experience so far it actually is.

Frankly, if even just the cvs repository were publicly available, the (vast?) majority of these benefits would be available without needing to change anything for Nick other than simply making the repository available. MUSHclient is so mature in its core development that it's rather unlikely for forks to appear; empirically speaking, changes suggested to Nick so far tend to be captured in rather small patch files. Major changes have always been made by Nick himself in almost atomic units, and released shortly thereafter, where it doesn't really matter if changes are available the second he commits them internally. It's actually rather unsurprising to me that the widget framework was forked, as that is a far more dynamic project (in terms of heavy, active development).

Basically, I think that the benefits in this particular case might be being conflated a bit with the benefits in general.

One big reason I haven't contributed other than downloading to glance through the code once in a while, is that getting it to a compiling state is a pain in the ass. If there were a public repository which was in a 'ready-to-go' state for a recent compiler (VS2005/VS2008/VS2010), I'd implement at least some of the features I've suggested over the years that Nick didn't feel were worth his time.