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

Hi olio,

> Yes, it is a terrible shame that Moi3D is not developed for the Mac

I wish I could do it, it would definitely be a great fit!

But unfortunately it is going to take a lot of work to make that happen. Since I am only a single person doing all the work on MoI it is just not possible for me to do some kinds of things that require a lot of time.

There are only 24 hours in a day... I have not found a way around that yet.

Hopefully in the future I can start making some steps towards it, but it will be a long drawn out process.

- Michael

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

That is actually an interesting way to go about it. But, QT can do those sort of things too. I don't have any really good examples to show you at this point but I am in the process of making a cross platform .3DM viewer so maybe I'll implement some dynamic UI scaling and language selection. QT definitely supports translatable user interfaces. I don't know a lot of languages outside of English but I do know some Spanish and German so maybe I could translate a few strings to test this out. In QT you can set interface elements (widgets) to have a certain orientation to each other and the main window and scaling will preserve the relationship. So, I'll try to prove it to you. I think that the best way to demonstrate an ideal is to put your money where your mouth is! ;)

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

Yes, that's totally expected and normal. Hindsight is always 20/20 and nobody every does everything the best way on their first try. Development is an iterative process. Also, development tools change over time.


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

Yes, it just went LGPL so that really would not have helped much 5 years ago. 5 years ago QT existed but it was nowhere near as good or full featured as it is today. Of course, MFC was crap back then too... So it sounds like 5 years ago you almost certainly did make the right decision. However, today being cross platform might actually be important. I'll grant you that 5 years ago linux was only a server OS and macs were not as important a market segment as they are today. Today I'm hoping to influence as many developers as I can to code in a cross platform manor. I'm a major cross platform zealot on the rhino forum too. So much so that I started to develop the aforementioned cross platform 3dm viewer (with QT).

Be sure to post the viewer here for us to get a look at.

Hi AdderD,

> That is actually an interesting way to go about it. But, QT
> can do those sort of things too.

It can do kind of vaguely similar things but not up to the full level of what I need.

It is the combination of markup + layout + script logic that makes for the best flexibility.

Here's a quick example of the kind of flexibility that I need to help me work with UI in the most effective way:



It's a simple example as far as what is often needed in MoI, but there are actually a lot of things happening there.

Notice how some controls are being hidden or shown based on the checkbox, and when the new controls are shown, the labels have longer text but the labels and input fields adapt to the new text length?

That kind of adaptability to changing UI, including text length and visibility is important for what I in particular need to do. It is not as important for a lot of conventional UI which does not do such things, but as you may have seen by now MoI does not really have a conventional UI. Doing a Qt UI is just a better fit for a more typical basic program UI that more closely follows standard conventions (and limitations! :) .

Then the key thing is not just that I'm hiding and showing UI there, but that it is extremely easy and natural for me to create UI like that, since all the code for hiding and showing things is done completely in script without needing to put that logic in C++ code only. The speed (in development time) at which that happens helps me a lot in developing the UI.

It also allows for 3rd parties to do similar types of things without having to write C++ code to handle the UI.

Maybe that will help you to understand more about why using Qt does not deliver what I am looking for in a UI toolkit.


> I don't know a lot of languages outside of English but I do
> know some Spanish and German so maybe I could translate a
> few strings to test this out.

Just make sure you do an actual "real world" type of test where for example the German strings become 4 times as long and need to make the UI elements expand and word wrap to multiple lines to hold the larger text!


> In QT you can set interface elements (widgets) to have a
> certain orientation to each other and the main window and
> scaling will preserve the relationship

Yeah, the basic kind of layout mechanism where a widget is either a fixed size and located relative to another one or the window edge, or where it is some percentage size of the main window are common things in many UI toolkits.

But that's a primitive system once you try to get a lot more things like embedded forms, like in the example I show above.

To get real flexibility, a widget's size should be determined dynamically to fit around the text that is contained within it, including allowing that text to word wrap to multiple lines if necessary.

That's what an HTML based UI engine delivers and that is different than the typical old-style widget docking and sizing mechanisms.

Again, often times conventional UI is done with fixed size widgets that will do things like clip long text instead of adapting to long text. That can be fine if you want to limit your UI, but I need something more flexible than that.

As far as I have been able to tell the Qt toolkit does not do these kinds of things, here is a quote from their Layout documentation:


That's not suitable for me - especially having widget sizes fixed in pixel size does not allow it to adapt to dynamically shifting text content, and being oriented towards being hand-written C++ code is not as flexible as dealing with it through script and markup...


> However, today being cross platform might actually be important.

It definitely is, and I do wish that I was cross-platform!

But I'm not willing to use a more primitive UI mechanism to get there... That kind of system can be fine for basic UI but it does not really cut it for my needs, which I've tried to explain to you in more detail above with some examples. I would never have been able to get to my current UI design with a more primitive layout system.

The main way forward for me for cross-platform is to try and shift to WebKit or Gecko which will deliver to me the same kinds of advantages that I mentioned above but not be tied only to Windows. This is going to be a bit difficult though, like I explained earlier in this thread neither of these engines is currently set up to be as extensible for writing new controls as mshtml is. Of course the source code is available to work with and change but it takes quite a bit of time to get in there and get familiar with it enough to do that. I do plan to do some experiments with WebKit in between MoI v2 and v3, I have already done a bit of tinkering where I've ruled out using wxWebKit, but I think that QtWebKit has a lot more possibility.

Anyway, I can understand that you want to evangelize cross-platform UIs to make it so you can more easily get software that runs where you want it! But please don't think that all program UI needs are the same and can easily fit in the same box, that is not the case.

- Michael

>Be sure to post the viewer here for us to get a look at.

I'll try to remember to post here too once things are rolling well. I've been talking about it on the Rhino forums. Actually, I must admit, I've tried MoI but only briefly. I'm really a rhino user. But MoI has some draw for me. I like it's GUI, I like the better meshing (better by FAR!), I keep hearing great things about it. So I'm certainly interested in MoI and I try to keep up on it from time to time.

So, my viewer was geared to allow some of us on the Rhino NG to be able to view 3dm models in linux (or OSX or windows) without a copy of rhino. Since MoI uses 3dm it will work to view MoI models too. It's certainly not meant to ever become anything even close to a replacement for MoI or Rhino but some people (namely clients) need only view models not generate them. For such people a standalone viewer would be ideal. This viewer will be open source once I get it to a point that I feel is suitable for general public use/hacking. This should be soon. I've been trying it on 32bit Vista and 64bit Debian linux so I can at least vouch for cross platform support between linux and windows. OSX should be possible but I am far from a fan of macs so I go nowhere near XCode or macs in general.

At any rate I hope to have a sourceforge project going by the end of the week. If I forget to link to it here then slap me.

>It can do kind of vaguely similar things but not up to the full level of what I need.
>It is the combination of markup + layout + script logic that makes for the best flexibility.
>Here's a quick example of the kind of flexibility that I need to help me work with UI in the most effective way:
><SNIP>

Thanks for that detailed explanation. As I said in my above post I'm more interested in MoI than experienced so I hadn't really done enough with the GUI to know much about it other than screenshots and some very limited use. From screenshots and my dim recollection the GUI looked reasonable enough to replicate in QT. From your description I see that things are not as simple as I had believed. I think that a lot of what is going on in MoI's GUI *could* be done in QT but at a greater (and maybe much greater) development cost.

QT now (I think it's new in 4.3 or 4.5) supports a forms based layout that might be closer to what you need it to do but I have zero experience with it yet so I might just be making things up.

Thanks again for the explanation. If I ever do happen upon a solution that looks like maybe it's what you are looking for I'll shoot you a message. Otherwise, best of luck in your investigation of cross platform ways to get your HTML based GUI to happen!

And, for what it's worth, I think MoI looks pretty sweet! Keep up that good work.

Hi AdderD,

re: Viewer - yeah that is something that a variety of MoI users could be interested in as well, so it would be cool if you could mention your progress on this forum as well if you remember! :)


> I think that a lot of what is going on in MoI's GUI *could*
> be done in QT but at a greater (and maybe much greater)
> development cost.

Certainly it is possible, but my best guess would be that it leans quite a bit towards the "much greater" side...

Also, maybe you're not aware of this but I'm the only developer working on MoI, so it is important for me to try and leverage already existing stuff when it is possible to do so.

Otherwise I would end up spending all my time working on the engine stuff and not on actually designing the UI. Leveraging an HTML engine gives me a significant amount of text and layout handling power along with it, which meets my particular needs better.


> QT now (I think it's new in 4.3 or 4.5) supports a forms
> based layout that might be closer to what you need it to do

I've taken a very brief look at that (that's the Qt Designer stuff you are referring to?), but it seems to be oriented more towards making kind of traditional dialog box windows as far as I can tell.

And don't get me wrong, it certainly looks like there is a lot of functionality and useful stuff in Qt as well, for a lot of projects I'm sure that it would be a great choice just using its normal stuff. I happen to have a pretty different UI than what is typically done though so it tends to be harder for me to benefit from a prepackaged toolkit to the same degree.


> And, for what it's worth, I think MoI looks pretty sweet!
> Keep up that good work.

Thanks!

- Michael

perhaps It will also be interesting to looks @ what methods, tools Autodesk StudioTools and Siemens NX have been using to bring their product to OS X...(just a thought)

NX 6 UI Rocks, thanks god they did not go for a another stupid Ribbon UI