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.

Yes, well apple has about 1/10 market share, but this number goes up drastically with artists and designers even autodesk the most PC oriented company out there say that 30% of the customer prefer the mac platform, that is why they are porting alias studio 2010 to the mac, with promise of more coming in the 2011 releases...

and mcneel has over 12.000 beta users of mac rhino, transfer that into dollars.:)

Hi AdderD,

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

You can certainly suggest it, but you'd be wrong! :)

I have a lot of experience in developing UI, and I can definitely tell you that a markup based UI mechanism is a huge time saver once it is all up and running.

The big difference is that HTML has a layout mechanism built into it, so the HTML engine handles all the details about expanding entities to fit around text, stuff like that.

It's one reason why MoI has some unique features like being able to set a fine-tuned UI scale (any point size can be set, not just "large or small icons"), or being able to switch to different languages on the fly without restarting the program.

To try these out, in MoI go to Options / General, and adjust the "UI size" slider, and switch the "Language" dropdown to a different language.

As far as I know it would be quite difficult to make this same kind of functionality in a Qt app. But if you know of any examples of a Qt app that has similar functionality please let me know so I can take a look!

It's also a major advantage to have the ability to have small bits of script logic bundled along with the UI, to handle some UI specific things like hiding or showing different portions in response to various UI actions. In MoI's UI system most of the UI is implemented in this way, it is a lot faster and more flexible way to do things than trying to handle each little bit of UI in C++ code. C++ code is great for making the building blocks, but then script or markup is better to handle gluing the building blocks together and arranging them.


Basically without MoI's UI system I would not have been able to develop the UI to its current level. I would have been stuck back at one of the earlier iterations because it would take too much time to try new things.


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

Well, I'd love to see any example that has stuff like the dynamic scaling or language change!

The other factor is that when I developed MoI it was not like I had everything completely figured out from the very beginning. It was a long drawn out process to develop the UI and it went through many iterations. It helps to have a very flexible UI system when doing this, and not having to worry about coding layout makes it much easier to do experiments.

If I knew from the very beginning exactly how I wanted the UI to be set up, it would have been more possible to do it in a more "hard coded" kind of fashion (which is what happens when you rely more on C++ code to form the UI instead of markup), but that totally ignores the actual design process of iteration and experimentation.


> The newest version of QT can be used as LGPL and thus
> used in commercial products without a commercial license.

Yes, that's pretty cool and I am actually planning on trying it out, especially since they have WebKit along with it.

However, the LGPL release is something that literally happened a few weeks ago. Meanwhile I started on MoI 5 years ago. So I'm not sure how I would have made use of a brand new thing when I needed it 5 years ago? :)


Anyway those are some of the issues...

The main thing to keep in mind is that, yes it is great that Qt now has LGPL, but if it didn't when a project was started that does not help a whole lot.

- Michael