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

Regarding that, QT 4.7 introduces a new declarative UI (QML). Sorta like XAML, but in javascript.

http://labs.trolltech.com/page/Projects/Graphics/Kinetic/DeclarativeUI

QT also includes a WebKit module that might be worth a look.

Hi vodkamartini,

> Regarding that, QT 4.7 introduces a new declarative UI (QML).
> Sorta like XAML, but in javascript.

Yeah I've looked at that a bit - it's totally brand new though, which scares me off a bit just in general. For example because it's new there really isn't much chance that very many people would already be familiar with that syntax, unlike HTML.

Also the general focus seems to be on making spinny whizzy animations with it, I'm not sure if much effort has been spent on using it for more regular application UIs.

Qt 4.7 is actually not even in final release yet, it's currently in beta.


> QT also includes a WebKit module that might be worth a look.

That is actually what I've been looking at - it's the easiest way to actually build WebKit without having to install a huge simulated UNIX environment (Cygwin).

- Michael

Music To My Ears...I now must be a lot of work involved but I'm sure Michael could pull it off...

In my opinion from a commercial point of view i think HTML UI will be in a more favorable position as it will enable users to more easily author their extensions given the fact that Michael will soon be unable to follow all the requests and may concentrate on the geometric core and the supporting api and sdk so that everyone might build own uis and features relevant to ones core business and Michael will maintain just a basic app..

sounds like a suggestion..))

"""""Michael will soon be unable to follow all the requests """"""""''

Michael is "Growing help" right now. As long as he waters and feeds it every day, all the forum requests will be handled with the same care!!! lol

Hi igor, yup that's one of the ideas behind using an HTML based UI in the first place - that it is more familiar to a wide range of people and that tends to make it easier for people to customize things or author new pieces of UI.

- Michael