|
Locked
Looking for a brave soul to try a Windows installer
I've created a first version of a Windows installer. I'd like to have somebody try it and tell me how to make it better.
Also, does anybody know how to make a "Windows icon file"? If I can get one of those, the installer can set the various icons to something less generic. The installer can be downloaded from: As you can see from the name, this is a new version. Testing is not complete (the installer is really meant to test the _installer_, not the new version). It has the updated decoder selection GUI of the 9.3 test version, with only a little additional tuning. The Lenz LI100 support seems to be working, though, and there are a couple of other minor improvements. Because this is a test version, it will install "alongside" any existing install you've got. This means that you'll have to set it's preferences, etc, but on the other hand you won't lose your locomotive roster and settings if the installer doesn't work. Thanks in advance, I appreciate the feedback. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) Am working off a huge email backlog, call if it's urgent. |
|
Locked
Re: new decoder selection list boxes
Sorry for the slow reply, it's been a busy week. Also, I've rearranged the paragraphs below so the reply makes more sense, and coincidentally to put the good news first.
At 3:30 PM -0700 6/19/02, Robin Becker wrote: Bob,No problem. I _like_ getting feedback like this, and wish there was more of it. I shortened the list to just manufacturers that have one or more decoders defined. That does make it cleaner, thanks. A manufacturer will also show up if one of their decoder is seen when doing an identify, just so it's clear what was seen by the programmer; in that case there's still no decoder name shown though. Making it default is a good idea, I'll try to do that. I tried to switch back to a combobox (selection box) for the manufacturer, but with the decoders in a list it looks really ugly. But that got me thinking of another approach, see below. Would it be possible to update the mfr and decoder list selections when theGreat idea! I did that. The mfr name list was scrambled when I first ran the update. AfterRight, that's due to the auto-index-on-update feature that's still missing. I've got to get to that pretty soon... I was able to open more than one programmer setup window at the same time.This is just laziness on my part. I was putting off fixing this until I had ops mode programming working, but it's not yet ready yet. The idea was that you could open as many ops-mode windows as you want, but only one that used the programming track. I'd prefer to not fix it now, as I'd rather fix it as part of reworking the first screen to include an ops-mode button. OK? It looks like the decoder family names show up in the decoder list. I foundAll of these points are correct, and important. When I was working on this interface, I was mostly concentrating on the case of Digitrax and Lenz decoders (which I have). They have a large number of defined decoders in a couple of families. For them, the interface seems to work OK. You select "Digitrax", and get a pretty long list, and just look for your decoder; you can ignore the family names. But people tend to refer to decoders as "FX decoders", so if that's what you think you've got, you can select that family and it also works. And when you push "ident", it shows you a nice list of the possible specific models within the family that was identified by CV7. Unfortunately, it seems that this breaks down for Soundtraxx. They've done a better job of identifying specific _decoders_ with CV7, so there's less of a need for the "family" idea. And the list of all Soundtraxx decoders you get when you select the manufacturer is _really_ hard to read because of that. I started to think of a way to use indenting to make all this clearer, but it soon occurred to me that I was recreating a "tree" structure. So let me ask the accumulated wisdom on the list: Would a tree GUI work better? The idea would be to have a single part of the selection window (probably with scroll bars) that shows a tree ala the various "Explorer" things. The tree would have three levels: Manufacturer, with family below that, and decoder below that. For cases like Soundtraxx DSD Diesel, where there's no clear distinction between family and model, just the model would appear directly under the manfacturer name. At first, just the list of manufacturers would appear. You could click on one to open it, and see all the families and decoders. Selecting a decoder or family would let you push the open-programmer button. Only one could be selected at a time. If you use the ident button, the tree would be closed-up except for the part of it that satisfies the identify results. If that's a specific decoder, that'll be open and selected. If a family was identified (e.g. Digitrax FX), the tree will be open to them, with the general family selected, and all the individual decoders visible. If the model (CV7) wasn't recognized, all the decoders for that manufacturer will be unfolded. Etc. The only thing that I can think of that this would make _more_ difficult is "I've got a DH142 decoder, and I can't remember which manufacturer made it"; in that case, the user would have to open all the manufacturer names to look for it. (I could start with everything open in the tree, but that's really annoying to people who're looking for a specific thing). And in that case, clicking ident will go to the right place anyway. This has the other advantage of being easy to code. What do people think? Should I code it up so people can try it? Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) Am working off a huge email backlog, call if it's urgent. |
|
Locked
New GUI for selecting decoder type
I've tried to put together people's suggestions on how to improve the process of selecting a decoder for DecoderPro. Robin, sorry, but I just couldn't get pop-down menus to work well.
I'd like your opinions on whether this is an improvement, what should be changed, and even whether we should go back to the old one. To try it, download then install it by copying the unzipped files to your existing directory (you should probably keep your old files just in case). The decoder selection panel is now two lists: on the left, a list of all manufacturers, and on the right a list of decoders. It starts with all decoders we know about listed. If you pick a manufacturer, the right list becomes just those decoder models. The ident button works basically as before. There's new logic for handling unknown manufacturer codes, unknown decoders from known manufacturers, and certain errors. The status at the bottom of the window is much more verbose, and hopefully more informative. I'm looking forward to comments. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
|
Locked
Re: Serial port too slow? Can anything work.
This is great!
toggle quoted message
Show quoted text
We've been hacking around in some quite complicated code trying to fix this. It's only (so far) a problem on Windows, and I've be very happy to add the JNI code to call that function. Would you be willing to compile it and send me a library? I don't have any build tools on my test windows machine. Or perhaps somebody else could do that? Thanks! Bob --- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:Well, I installed JMRI on my 1 year old laptop and it says that myapps? --
-------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
|
Locked
Re: Serial port too slow? Can anything work.
At 9:58 AM +1200 6/4/02, Alex Shepherd wrote:
If we go down this path does it mean that we will have to migrate theThe RXTX folks have two versions of their library, called 1.4 and 1.5. The member function names and arguments, classnames, functionality, etc, are identical between the two. Version 1.4, which is what Mike used on Linux if I recall correctly, implements the same API as Sun's javax.comm, so it works without any changes to JMRI. That's nice, because we can use RXTX on some machines, and other implementations on other machines. Right now we use RXTX on Linux & MacOS X, Patrick Beard's implementation on MacOS classic, Sun's on Windows, and IBM's on OS/2. The RXTX version 1.5 puts all the classes in an "org.gnu.io" package tree, instead of the javax tree. Apparently this is important for certain uses which are intended to be 100% "free" software. So as long as we stick with the 1.4 version, we should be OK. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957) |
Bob Jacobsen