When you start to delv into your next version, please remember not to smash the fly on the wall behind you....It may be ME!!!! :o

:)

We've got so many spiders around here recently that they've been doing a good job of eating up the flies...

Still been just in experimental/research mode so far, the current focus is getting some idea of how feasible it would be to move the UI off of mshtml.

- Michael

>the current focus is getting some idea of how feasible it would be to move the UI off of mshtml.

Interesting. What would be the motivation for that? Cross-platform compatibility?

Dan

Hi Dan,

> What would be the motivation for that?
> Cross-platform compatibility?

Yeah, cross-platform would be one goal of that.

But another goal is just reduction of external dependencies for greater long term stability - the main downside of mshtml is that different machines have various different installed versions of it. And it is possible for new versions of it to come along and change in behavior enough to cause problems.

If the UI could be driven in larger part from self-contained code it would take out a lot of those variables.

- Michael

Exactly, when I heard that you based your GUI around IExplorer I felt that was a very risky move!

Innovative, absolutely, but scary!

Being able to use HTML / CSS is really cool and lets you create some really gorgeous UIs I'd love to do similar with some of my personal apps, especially adding a bit of Flash here and there, but looking at the SDK, it was a learning curve I'm too lazy to fight through!


-Will

>If the UI could be driven in larger part from self-contained code
>it would take out a lot of those variables.

Mmm, I can understand wanting a greater degree of control of the UI's destiny... Sounds like a tough decision on the cost-benefit front though - somewhat abstract payoff in return for quite a lot of hard work (plus the opportunity cost). I guess if MoI's codebase is fairly well separated into edge and core segments and the UI portion doesn't much interpenetrate the core stuff it might not be such a burden?

Dan

By all means then....SMASH SPIDERS!!!! SMASH SPIDERS!!!!!!!!!!!!

Hi Will,



Actually the killer feature of doing the UI in HTML is just text handling - HTML layout engines have very sophisticated support for text handling, things like word wrapping long lines of text making the containing element larger and stuff along those lines.

It does tend to have a long learning curve to get up to speed using it for application UI though because it's not done very frequently so there isn't a whole lot of extra support materials (like examples, tutorials, etc...) for using it in that way.

- Michael

Hi Dan,

> Sounds like a tough decision on the cost-benefit front though -
> somewhat abstract payoff in return for quite a lot of hard work
> (plus the opportunity cost).

Yeah I don't really know yet what the cost will be, that's what I'm trying to get a feel for now by doing some experimentation.

But if you also lump in being able to run cross platform as another payoff, that adds up to a lot of potential benefit overall.


> I guess if MoI's codebase is fairly well separated into edge
> and core segments and the UI portion doesn't much
> interpenetrate the core stuff it might not be such a burden?

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

- Michael

>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!