>Yeah there is a pretty good separation, things like actions on a UI control
>talk to the core app through the scripting interface.

Benefits of a good design! That initial planning and the long gestation period paying off :-)

Dan

Michael,

Care to share some insight into the technologies you are thinking about using?

I'm still interested in the scripting and UI aspects of MoI, although I've recently returned to a full-time job status which has pretty much eliminated any time to devote to MoI at the moment. But since my full-time job is developing open source scripting and rapid UI development tools, I might be able to provide some useful feedback based on that and my 40+ years as a developer :-)

Hi Dave,

> Care to share some insight into the technologies
> you are thinking about using?

Currently I'm evaluating WebKit (Qt port). For the kind of text layout that I like to work with probably either WebKit or Mozilla seem to be the main choices...

- Michael

Hi Michael...

Quote from Deelip Blogs :
Michael sent me one of the first early test images from the engine development which shows how texture mapping also works for applying a line type pattern along the curve in addition to the blended edges.




So this is also another area that you are working on... ?

Hi Anis,

> So this is also another area that you are working on... ?

No, that's an area that I already worked on 6 years or so ago, that was an early test image for MoI's curve drawing engine.

That engine is not new, it's been in use in every version of MoI that has been released, it is what draws curves on the screen. The dashed line types are currently used by default for drawing the grid and also for the hidden-line display.

- Michael

Previously I suppose its the line for 2D drawing.

Hi Anis, well at some point this same engine will be used for drawing linetype properties assigned to curves. But the tricky part about that is more about designing the UI for setting such properties.

- Michael

Michael,

Well, given those two possibilities, I guess I would personally favor Webkit, mainly because all of the tool frameworks I've been building for the last several years all work with Qt (or wxWindows) :-)

If you remember some of the screen shots I posted a while back, the UIs were all created using the tool set I've been developing, running on top of Qt. If you go that route, hopefully you'll also open up the scripting interface to use other languages, such as Python. Since your low-level API is COM-based, that should be fairly easy to do, since Python already has pretty good support for COM I've heard.

Just FYI, the new Lightwave CORE system is Qt-based and supports Python scripting. I've had no problems integrating my framework into CORE to produce new UI's in the few experiments I've tried so far...

Hi Dave, well I'm not sure about focusing on Python anytime soon - all my own existing scripts and commands use JavaScript.

The nice thing about JavaScript is that it's also the most natural script language to work with to add bits of logic to the HTML UI as well, since it's the main language for HTML.

But yes since MoI's script API is COM based that should help make it possible to use a variety of different controllers for it.

- Michael

My 2 cents.

1) If you want to stay on windows go the .NET 4 route.
- Has great COM interop
- WPF is great for UI (xaml is easy for users to play with, and has great tool support)
- WPF also has D3DImage, so directx interop is handled well (no airspace issues).

2) If you want to go multiplatform, go with QT4.
- Very nice API, makes you wonder what the win32 people were thinking.
- Great opengl interop, which makes it well suited for graphics-oriented apps.
(e.g. Maya, Mudbox, Maxwell, Nuke, Realflow, etc)

Oh man,

Michael if you could somehow make Moi cross-platform, I would kiss my windows machine goodbye and Rhino with it, and solely focus on Moi and Mac:)

It would be the sweetest deal I have seen in a long time!

Hi olio, well don't get too excited just yet - I'm just in the process of experimenting with things a bit to get a feel for how much work will be involved.

If it is going to take a tremendous amount of work then I probably won't be able to do it anytime soon.

But I want to do some testing and research now to get a better feel for what is involved.

- Michael

Michael

I was thinking, perhaps you could use LUA for scripting (so you don't have to use javascript)?

+1 for Qt

Very nice options, skinable, css based, multiplatform and visually nice.

Cheers!

Thomas

Yes, Qt is good for C++ GUIs.

If I didn't do most of my work in C# I'd probably use it too :P

Hi NightCabbage,

> I was thinking, perhaps you could use LUA for scripting
> (so you don't have to use javascript)?

Well, the problem is that you can't use LUA to add script directly inside of an HTML page - JavaScript is the standard mechanism for scripting HTML.

It's kind of awkward to have 2 scripting languages instead of just focusing on 1 scripting language throughout the whole program.

- Michael

Oh sorry, I thought you were going to ditch the HTML based system? My bad!

Hi NightCabbage,

> Oh sorry, I thought you were going to ditch the HTML
> based system? My bad!

Well, I hope to still use HTML, I prefer using it for UI because of its text handling, layout flow and word wrapping capabilities.

That's why I'm looking at WebKit right now, since it could possibly give me those same capabilities but with an engine that is distributed with MoI instead of an external dependency.

- Michael

Laugh, I am SOOO tempted to spend the weekend recreating MOI's interface in QT or WPF, though I doubt it would influence your decision. I think it's cool that you're taking the rebel's route, and it's definitely something to use as a showpiece for alternative UI. Truth be told I was already expecting you to start replacing a lot of the .png assets with SVG when trident 5.0 came out.

Hi vodkamartini, there is actually quite a bit more UI involved than it first appears, since there are 111 bits of command UI.

> QT or WPF

Well, one huge problem with WPF is that it would lock me even more tightly into being Windows only.

Native Qt is a possibility, but after looking into it there are several parts that I don't like - the overall design of it shows that it's really primarily meant to be driven from C++ code (like having code that directly creates widgets).

For tweaking it is a lot easier for a "power user" to edit an .htm file than it is for them to edit some C++ code and compile it in order to make changes or plugins.

Qt does have a method to load UI configurations from .ui files, but when I looked into that the .ui files were kind of like direct XML data dumps of C++ objects, they did not seem particularly easy to edit directly in a text editor.

One of the nice benefits of HTML is that it is very easy to edit in a text editor, it's easier to write simple UI that may include some little bits of script code along with it for UI-specific logic, which greatly helps in keeping a separation between UI stuff and core C++ code stuff. Also HTML is much more widely used and more likely familiar to a wider range of people than the Qt UI XML data file format.

So although I'm sure that it would be possible to whip up something close to MoI's UI in native Qt, I'm very dubious that it would be possible to keep the same level of really easy authoring/customizing that comes with having the UI made up of all user-editable .htm files. This aspect of UI authoring will become more interesting in the future with MoI when I have more emphasis on extensions and plugins.

MoI's UI also has some features that I have not seen in Qt applications like the ability to scale the UI up or down freely, and easy translation by just creating a single Strings.txt file... There would likely be some pretty big stumbling blocks trying to bring 100% of MoI's UI functionality over.


It's just easier to experiment with layout-driven things with HTML, having a flexible HTML based UI was especially crucial in the earlier stages of MoI when the UI was not all finalized, the flexibility really helped me to be able to experiment with things and actually come up with the current UI.


- Michael