In order to preserve the "prevent unintentional moving" support, perhaps this would be best performed only inside of the image command. How's this for a scenerio:

You select something in the drawing and then call the image command.
The image command tests to see if anything is selected when it starts up and, if so, asks the user (in some intelligible way) if he wants to maintain those selections in order to move them along with the background.
If the user says yes then MoI does whatever is necessary to bind the selected objects to the background, but only for the duration of that particular invocation of the image command.
The user does whatever he's going to do, and when he leaves the image command, the bind is revoked.

This would seem to me to restrict the ramifications of the binding as much as possible. What do you think?



As for learning to program things for MoI, a "diging in" starting point is what I'm looking for right now. One problem I'm going to have with this is that, although I have some training in higher level languages, my entire career involved real-time assembly language programming of microprocessors. What language is MoI written in?

Thanks,
Mark

Hi Mark,

> The image command tests to see if anything is selected
> when it starts up and, if so, asks the user (in some
> intelligible way) if he wants to maintain those selections
> in order to move them along with the background.

I can forsee a lot of confusion with asking that question, because it's very frequent for people to go to the image command without any desire to move images around at all, like for example to just place a brand new image.

So that's going to be a confusing thing to pop up a message in an intelligible way when the question that they now have to answer doesn't have any relation to the task that they're trying to accomplish right then (like add a new image, adjust an opacity setting, hide an image, etc...) .

That's a big problem with popping up a modal question like that - it really has to definitely be relevant to what they are currently doing or else it will be both confusing and annoying to have to answer it as an additional step.


> As for learning to program things for MoI, a "diging in"
> starting point is what I'm looking for right now.

Well probably the first step is to explore the existing scripts - basically every command has a script file that controls how it operates and you can find all of them in the \commands sub-folder underneath MoI's main installation folder.

Similarly the main UI is defined by a bunch of HTML files in the \ui sub-folder inside of MoI's main installation folder.


> One problem I'm going to have with this is that,
> although I have some training in higher level languages,
> my entire career involved real-time assembly language
> programming of microprocessors. What language is MoI written in?

Hmmm, yeah so I guess really a first step would be to learn some JavaScript to start with - it's the language that is used for adding script logic to web pages so there are a lot of online resources that could get you started with some of the basics of JavaScript itself.

MoI is written in a combination of C++ and JavaScript - C++ is for the kind of core heavy lifting pieces and JavaScript is for controlling the overall command flow logic, like controlling the different stages of a command and calling services like point pickers to gather point inputs, and stuff like that.

The UI is done using HTML - if you look through the \commands sub-folder you'll find that each command has both a JavaScript .js file that holds the command logic and also a .htm file that contains the UI for the command.

You can make a new command by creating a new .htm and .js file that start with the command name and putting them in your \commands subfolder. You generally set up a keyboard shortcut to launch your new command. That's how the various plug-ins collected on Petr's site were created, see that scripting wiki link posted previously for a link to Petr's site.


It's going to be a pretty difficult area to dig into currently though, since I'm not ready yet to spend very much time supporting this area.


- Michael

Hi Michael,
I understand what you're saying about the confusion factor. You've obviously done a LOT of thinking about UI issues. That's why I said that the question would be asked only if there were things selected when entering the command. However, that may not be enough to keep things clear.

I understand that you're not particularly interested in tutoring people in programming add-ons to your software. I have had some basic classes in Javascript and C++ (the dreaded C++). I very much appreciate the information that you have already given me. I'm sure it is a difficult task, but others have done it. This will be a background project for me after several other projects that I have going on.

Thanks,
Mark

Hi Mark,

> That's why I said that the question would be asked only
> if there were things selected when entering the command.
> However, that may not be enough to keep things clear.

Yeah the problem is that many people may not expect for the object selection to have any significant relevance when going to the Image command. So because of that they may happen to have some objects selected and then have that message pop up.

- Michael

Hi Mark,

> I understand that you're not particularly interested in
> tutoring people in programming add-ons to your software.

Well, I think I will get there eventually - but I think I need to have somewhat more of the regular non-programming features more refined first before being able to do that though.

Another aspect that is difficult about concentrating on people making add-ons is that it tends to be difficult to make changes to the program structure when there are a whole lot of various external things that are depending on how things work currently. I want to refine things and add a bit more regular functionality first before I'll be really confident about locking things into place for a longer period which tends to happen with a focus on add-ons.

- Michael