Hi chocobanana,


> Perhaps gecko, webkit as discussed before to replace
> that nasty mshtml...

Yeah I think this is the best possibility for the future.

But unfortunately these other engines are way behind in the kind of extensibility that I really need to do a proper job. Mshtml.dll has a mechanism in it called IHTMLPainter that makes it pretty easy to make a C++ component that integrates into the browser at a very low level, participating directly in the painting of the page.

The other web platforms just do not have anything similar to this, they have instead focused energy only on things accessible to script code, stuff like the Canvas element. That's great for other types of stuff, but not really for trying to make custom controls like I need to do.

Hopefully in the future this will get better though. In the most recent version of Qt they brought in a version of WebKit that can be used in conjunction with Qt. I was hoping that this might be a good way forward but I took a look at it and the extension hooks are still too primitive, it does allow for a Qt control to be declared as an <object> tag in a page, so there is something there but the controls that way are kind of like an isolated island, I need better integration into the whole page like the mshtml.dll mechanisms provide. For example I need to be able to put down a custom painted background using C++ code, while letting the browser handle the text display in the foreground - that isn't possible with a clunky <object> method but works great in the IHTMLPainter method in mshtml.dll .


> Btw, is the educational version of MoI upgradeable to a
> future commercial version?

Yeah, I think I will set it up to allow that.


- Michael

Maybe I should think up a Metafive?

Braian

""""I think that he had a kind of prototype cooked up initially there to show what was possible, not really a complete working version.

If I understand correctly, he's been working on getting a full ported version for well over a year now and there is still quite a ways to go yet before it is actually finished!

It looks like there are going to be some pretty big problems with the finished port as well since it won't run any existing plugins or even any existing scripts since those are all done in VBScript instead of a cross-platform scripting language...

- Michael""""

Of course! I didn't mean to imply that it was stable. It was just a baby learning to walk. Take two steps, crash and repeat :) Considering their extensive beta periods, I wouldn't be surprised if it's not ready to ship at same time as V5 for Windows... About the scripting, i think I recently saw Dale mention something about adding new languages. But the plugin port is a pretty major issue. I think they plan to fully expose the feature set of Rhino's internal render engine, because they expect no render plugs to be available right away...

jonah

Hi Jonah,

> About the scripting, i think I recently saw Dale mention
> something about adding new languages.

That may help to give someone who is writing a completely new script an option to choose a language that will be portable.

But it won't help to enable any of the zillions of previously existing scripts to run...

I'd think that any "power users" on the Mac will still need to run the Windows version under Parallels/VMware even after the native Mac port is all complete... That seems like a pretty messed up situation.

- Michael

I'd think that any "power users" on the Mac will still need to run the Windows version under Parallels/VMware even after the native Mac port is all complete... That seems like a pretty messed up situation.

- Michael

that's why the sooner the better will be a wise choice for MoI, IMO

""""I'd think that any "power users" on the Mac will still need to run the Windows version under Parallels/VMware even after the native Mac port is all complete... That seems like a pretty messed up situation.

- Michael""""

That's probably true, but somehow I think only a small portion of users with big investments of plugins will feel the need to jump to OSX. If Win users migrated in a mass wave to OSX, it wouldn't really give McNeel much reason to work on the port in the first place... :) Rhino 5 will be 64 bit. So will there be any benefit to using OSX instead of PC?

jonah

Hi Jonah,

> That's probably true, but somehow I think only a small
> portion of users with big investments of plugins will feel
> the need to jump to OSX.

I'm actually not so much thinking about existing users, more about brand new users.

They'll ask a question about how to do something, and the answer will be - "use this plugin" or "use this script", and then they won't be able to do that.

For example they'll go to the Rhino labs page and see all the different plugins that are supposed to help them do various things, but they won't be able to use any of them...


> So will there be any benefit to using OSX instead of PC?

I think most of the OSX users would consider OSX itself to be the main benefit!


But the overall main reason to do a port is to attract more brand new users who are not already using the existing software since it does not run on their operating system, rather than for existing users.

- Michael

>I think most of the OSX users would consider OSX itself to be the main benefit!

CORRECT

>But the overall main reason to do a port is to attract more brand new users who are not already using the existing software since it does not run on their operating system, rather than for existing users.

- Michael

About 60% of the beta users are current Rhino users on Windows. I expect most will want to switch. I don't think we'll attract many non-Rhino users until we have a real Mac OS X interface. Robert McNeel
http://www.architosh.com/news/2008-08/0814_sig_interv_rhino_osx.html

McNeel Explains Leopard and 64-bit Rhino for Mac Users
http://www.architosh.com/news/2008-08/0814_sig_interv_rhino_osx.html

The bottom line is lots of parts have to be reviewed and in many areas they have to go back to the drawing board, BUT if they play their cards well that could ONLY result to a better PC and OSX software.
Anyway that's turning to a RhinoOSX thread, all I'm interested is to MoIOSX here...

Brians Metafive!

MoI is SOOO good!
Throughout the world, users buy new (no name!!!) PC OSs/progs (take your pick of Meta4S) to gain the benefits!

Suddenly, all the PC alternatives find they can provide solutions to "accommodate" MoI working in thier system!

AND!---Michael only had to stick to his guns!

(Has anyone a problem that Brian can not fix in a trice?---I have YEARS of experience in solving the problems of the world!)

Brian

Hi yannada,

re: "I don't think we'll attract many non-Rhino users until we have a real Mac OS X interface."

That's one of the things that can be good about doing a non-conventional UI like MoI, it tends to easier for it to go over to another platform without it seeming as strange.

MoI's UI is actually pretty Mac-ish looking already, it probably would not really need any kind of redesign at all to fit in well. It is too bad that it is such a difficult task to make it happen though.

- Michael

MoI's UI is perfect and almost everything MoI does up to now is better than "..." otherwise we would not be here talking. I only wish was my choice to choose the platform.

Maybe Platforms Mac/PC are not on the same level of price ;)

Hello Michael,
i'm not a progammer, and don't know what's all involved when porting a program to another platform, but this might be a good and quick solution for you: have a look at www.pisd.co.uk I've been working with them in several projects, they're very flexible and good guys.

btw. I'm a convinced mac user, and would love to be able to use moi natively on my mac! (though it works fine on vmware as well! )

aurelio

Hi aurelio,

> i'm not a progammer, and don't know what's all involved when
> porting a program to another platform, but this might be a good
> and quick solution for you: have a look at www.pisd.co.uk I've
> been working with them in several projects, they're very flexible
> and good guys.

Thanks for the tip! I'm sure those guys are great, but unfortunately there really isn't a good way for me to just hand the task over completely to another group.

To really do a good job of a port will require changing many of the structures of how MoI works internally.

So in this case, those guys would need to be making all kinds of changes to MoI, and at the same time I am also making changes to MoI to incorporate new features.

That kind of "multiple colliding changes in the same area" tends to create problems and additional work.

So unfortunately it would still require quite a bit of work from me even if I were to hire that group to work on it.

It's a great idea, and thanks for the link, but unfortunately that is not really going to help make it happen for my particular case.


It would help if I wanted to just make a kind of "static" port, that is to make a port that only ports a completely frozen snapshot version of MoI instead of trying to make a new common portable infrastructure. However, having a port of just a snapshot is not very good because it is not maintainable for future versions - each future version where new features are added would require another special port to be done, rather than having a common portable base.

- Michael

>But unfortunately these other engines are way behind in the kind
>of extensibility that I really need to do a proper job. Mshtml.dll
>has a mechanism in it >called IHTMLPainter that makes it pretty
>easy to make a C++ component that integrates into the browser
>at a very low level, participating directly in the painting of the page.
>The other web platforms just do not have anything similar to this,
>they have instead focused energy only on things accessible to
>script code, stuff like the Canvas element. That's great for other
>types of stuff, but not really for trying to make custom controls
>like I need to do.

May I suggest that using mshtml to draw the interface for your desktop application is like using a hacksaw to open a can of soup? Sure, it might work fine but why would you do that when can openers exist?

Also, QT is plenty customizeable and extensible all by itself. I'm sure it could produce the GUI layout of MoI without the need to hacksaw the soup can with HTML. The newest version of QT can be used as LGPL and thus used in commercial products without a commercial license. The advantage here is that QT apps tend to be quite portable.

Now, the COM issues are a little more difficult. Windows apps tend to get tangled up in COM and other MS goodness really easily. Probably more easily when the coder used to work at MS and probably got exposed to the water over there. ;-) Of course, that's a joke but one rooted in truth. We all are influenced by our experiences and so I'd assume that, unfortunately, code written by someone who used to work at "evil empire incorporated" would likely be inordinately attached to the standards of said corporate.

Yes, it is a terrible shame that Moi3D is not developed for the Mac, it would fit that platform beautifully and would serve many, many Nurbs hungry Mac users (myself included) that ahve been starved of windows only nurbs apps for too long...

Now Alias is going mac, Rhino is going too but Moi should be there first because in my eyes its already a mac application because if its interface:).

;)
Ventes = Sales (milliers = thousand)

Pillou Now translate that in dollars "LOL"

Rhino3d
Siemens NX
AliasStudio
Autodesk Lab has a new project that combines tech from SketchBook & ILoveSketch http://vimeo.com/2419011?pg=embed&sec=
Can you imagine MacTablet running that? I'm counting the days.