Build 10 -- Configs and more GUI

[Freddie]

The non-PC is a Mac. But I was just hoping that Mojo could talk to a VNC (again just to send keys, nothing fancy) since I am not sure there are many Mac broadcasters that work on multiple machines. And there are 000000 programs that work on mixed machines. Don't worry about it. I can just have Mojo talk to real VNC windows instead of just sending data to the VNC server (just feels clunky).

Is it good enough if Mojo does what HotkeyNet does? What exactly does it have to do?

Please don't hesitate to tell me what you really want. I have to implement a lot of stuff anyway so maybe it fits in easily.

The auto-update is I have to click accept on every update I do on the non-main machine. Lots of people probably have 1 machine, so 1 click to accept update is not so bad, but having to do it multiple times gets old. You don't have to force everyone to accept updates, just give us an option for "Accept updates in ____ secs" (1-20) checkbox so we can turn the feature on and pick a time (unless you want to pick a time).

In other words, if you do nothing, the program starts without updating? I'll check the ClickOnce documentation and see if that's selectable by the user.

[ElectronDF]

Actually I would like it to update in the time, since the program won't work if you have older versions talking to each other. I wanted the non-main computers to update in like 20 secs if I do nothing. I don't need everyone to want it, so that is why I put it as a default off checkbox.

Yeah, it is fine if Mojo works the same as HKN. I was just mentioning wishes. Mojo working is the priority, not it doing stuff just for me. There are probably 2 people that use PC-Mac boxing. There are probably 12-15 Mac only boxers. There are probably 2-5 Mac-Mac (multiple computers) boxers. Not worth spending time to do something that won't help a lot of people. I just thought copying VNC code would be something simple to do. Not something that is amazing, just to be able to send keys to a VNC server. Again, don't worry about it.

[Freddie]

Actually I would like it to update in the time, since the program won't work if you have older versions talking to each other. I wanted the non-main computers to update in like 20 secs if I do nothing. I don't need everyone to want it, so that is why I put it as a default off checkbox.

Oh, okay. I just checked, and Microsoft doesn't seem to provide a way to do that. They seem to give only four choices to the developer: turn off updates completely or have it the way it is now or postpone updates till the next time the program runs or check periodically (like every week). There might be a registry setting you can change.

Yeah, it is fine if Mojo works the same as HKN. I was just mentioning wishes. Mojo working is the priority, not it doing stuff just for me. There are probably 2 people that use PC-Mac boxing. There are probably 12-15 Mac only boxers. There are probably 2-5 Mac-Mac (multiple computers) boxers. Not worth spending time to do something that won't help a lot of people. I just thought copying VNC code would be something simple to do. Not something that is amazing, just to be able to send keys to a VNC server. Again, don't worry about it.

So you'd like Mojo to have the RFB protocol built into it (that's the protocol used by VNC) so it can talk to VNC directly as if Mojo itself is an RFB program?

I can imagine adding that down the road. That might be a good semi-standalone project for a programmer who wants to volunteer to work on Mojo. They could write a sort of driver (not a driver in the OS/kernel sense) that allows Mojo to send keystrokes via RFB.

[ElectronDF]

I hear you and thank you. /bow

[Aragent]

when Mojo.setup installs on windows 7 Ultimate its installing itself as far as I can tell in a non standard area.
C:\Users\[username]\AppData\Local\mojo and C:\Users\[username]\AppData\Local\apps\2.0\

Under desktop shortcut properties it only lists the path to the shortcuts name.
C:\Users\[username]\Desktop

In C:\Users\[username]\AppData\Local\mojo you have
mojo.draw_positions.txt
mojo.log.txt
mojo.settings.txt
mojo_engine.log.txt
mojo.engine.settings.txt

C:\Users\[username]\AppData\Local\Apps\2.0\Data\0330C0L4.HCJ\VPHZ3526 .H6P
I am assuming this is where we may add the xml files for the toons.

Now for the masses this is looks to be far more complicated and confusing
than just having the program install under

C:\Program Files\MOJO\
My hope also is that with mojo.setup, we will be able to choose in the future where we wish it to install.

[Freddie]

when Mojo.setup installs on windows 7 Ultimate its installing itself as far as I can tell in a non standard area.

It's being installed by Microsoft. Microsoft chooses the location of the binary files. This is how ClickOnce works.

This has been discussed here several times already.

The location is a cache, like the cache your browser maintains for web pages. The real copy of Mojo is on the web. You probably don't care where your browser caches web pages, and for the same reason, you don't need to care where ClickOnce caches Mojo's binaries. All you need is the data files, and (as I'll tell you in a moment) they are in the standard place where people should expect to find them.

In C:\Users\[username]\AppData\Local\mojo you have
mojo.draw_positions.txt
mojo.log.txt
mojo.settings.txt
mojo_engine.log.txt
mojo.engine.settings.txt

That's Mojo's data folder. It's in one of the two standard places for application data as defined by Microsoft. It's Microsoft that sets the standards, not you or me.

Every Windows user account has two folders for user application data. The locations vary from one version of Windows to another, but you can find them quickly by opening a command window and typing these commands, which use environment variables which are defined by the OS:

(Edit: This isn't something a user will ever need to do. I'm telling you this because you're curious.)

dir %APPDATA%
dir %LOCALAPPDATA%

Now for the masses this is looks to be far more complicated and confusing
than just having the program install under

C:\Program Files\MOJO\

First of all, the masses won't be confused because 99% of them will never know or care. They have no reason to want to know about these folders. These are implementation details. These are technical things.

Second, the binaries cannot go there because ClickOnce won't put them there.

Third, data files should not go there because Microsoft tells programmers not to put data files there.

Microsoft tells programmers to put the user data where I put it (or alternatively in %APPDATA%).

My hope also is that with mojo.setup, we will be able to choose in the future where we wish it to install.

Why? Can you give me a reason?

Let's be clear on the tradeoff here.

In order to give users the option of controlling the location of Mojo's binaries -- an option that will be exercised by only a small fraction of them -- everybody has to give up ClickOnce.

ClickOnce has tremendous advantages. It's reliable; it's convenient; it's supported by a team at Microsoft; it guarantees that every user's Mojo is up to date; it's tested by Microsoft's quality assurance professionals on every version of Windows and hundreds of different computers; it's been tested by millions of users over a period of four (five?) years; and for what it does, it's extremely fast.

On the other side of the ledger, the advantages of installing binaries in c:\program files is ..... what exactly?

That the pathname would be shorter? Nobody will ever have to type it anyway.

P.S. Another thing. We're only talking about the installer. We're not talking about limitations on what you can do with Mojo. If you want to copy Mojo from the ClickOnce cache to c:/program files or anywhere else, go ahead. Nobody's stopping you. You can put it anywhere you want. The installer won't, but you can.

[thinus]

Let's be clear on the tradeoff here.

In order to give you control over the location of Mojo's binaries, everybody has to give up ClickOnce.

ClickOnce has tremendous advantages. It's reliable; it's convenient; it's supported by a team at Microsoft; it guarantees that every user's Mojo is up to date; and for what it does, it's extremely fast.

On the other side of the ledger, the advantages of installing binaries in c:\program files is ..... what exactly?

That the pathname would be shorter? Nobody will ever have to type it anyway.

Mojo is pretty small and I don't see it growing too big either which doesn't really present any problems for me. In general though, when you have limited space on expensive high performance storage like a SSD or Velociraptor you want full control over where application binaries and application data is stored. I don't know whether you can configure ClickOnce on the local PC in some way to control where it places binaries.

This is the thing that pisses me off about Microsoft though, they concentrate on flashy marketable changes and neglectbasic O/S features. Even ignoring any applications you might install and only looking at the O/S, have you ever tried moving the user profile folder, moving My Documents or Libraries, changing the default path of Program Files? Where do all the O/S updates download to, where are all the temporary files and rollback points stored?

You would expect a simple interface that allows you to configure all these locations, instead you have to resort to numerous registry hacks and environment path changes. In the case of user profile folders there are even more complications. On my laptop it was easier to just use a 3rd party partitioning tool to resize partitions instead of trying to change the location of the user profiles.

FU Microsoft. At least they improved networking in Vista / Windows 7. Finally.

Sorry, had to vent.

[Flekkie]

Would it be easy/appropriate to add a link from the actions menu to open the relevant folder? Alongside the create icon action.


I know the My Documents folder and others in that area can be moved to a different location by right-clicking them and editing the details on the locations tab. But I couldn't see this functionality for the AppData or the whole [Username] folder :/

[Freddie]

In general though, when you have limited space on expensive high performance storage like a SSD or Velociraptor you want full control over where application binaries and application data is stored. I don't know whether you can configure ClickOnce on the local PC in some way to control where it places binaries.

Unless you let Mojo page out to disk the location of its exe and dll files has no effect on performance. No effect at all. Given the way it's written and used that not likely to happen even if you're short of RAM, and that probably isn't very likely either for the category of users that you're talking about.

I don't know whether you can configure ClickOnce on the local PC in some way to control where it places binaries.

You can't tell ClickOnce where to put the files, but you yourself can put them wherever you want. Just copy or move them like any other files.

[Freddie]

Would it be easy/appropriate to add a link from the actions menu to open the relevant folder? Alongside the create icon action.

I don't think ordinary users have any need to open that folder or know about its existence. Moreover, they should be discouraged from opening it because if they change any of the files, they may break their Mojo installation.

It's called user data not because users should mess with it. It's called that because it's created on a per-user-account basis by Mojo.

The only reason we're discussing it is because I mentioned it in order to tell you how to add icons before the program has the user interface that people will normally use for that purpose.

In a day or two, I'll publish a build with the user interface and nobody will ever have to think about that folder again.

I'm exaggerating a little -- a small minority of users will want to fool around with the files manually. Two percent? Five percent?

That minority doesn't need a menu option. They will know where the folder is because it's in the standard place.