Hi dinos, I'm really glad that you're liking MoI!
> But after examining the application folder for a few
> hours, trying to figure out the internals of the application,
> this might have been the wrong decision.
But why are you basing your judgement on this kind of analysis of the application's internals rather than just basing it on the actual experience of using the program?
It's far more practical to look at how the end result actually functions rather than worrying all about theory...
> The sequence is probably: Cocoa -> X11 -> Wine -> Qt ->
> Webkit -> Your code.
Yeah, it does end up going something like that, although I think that X11 receives its stuff from the lower level internal CG library and not Cocoa directly which is also built on the same kind of low level stuff as well.
But generally these levels are just passing things through with minimal work done.
The couple of extra function calls involved would have been an issue on something like a 486 computer 20 years ago but on any computer made in the past 10 years or so it's not an issue at all.
The main proof of this is just in using the program itself - moving the mouse around and drawing things feels really very snappy and quick, the only exception is resizing windows, and I will be doing some work on improving that.
But the empirical evidence that I've seen and that I've heard universally from users about performance is that it's very responsive, and so the theoretical issue that you don't like the internal architecture just does not amount to an actual problem in real world usage.
> Moi3D is really fast now, but i can't imagine how much smoother
> it would have been if you could use OSX directly.
Maybe something on the order of 1 millisecond smoother (again, with the exception of window resizing) - most likely nothing that you would be able to notice or really be able to measure.
> But, as you go deeper into trying to make it look native, it will
> get complicated. A lot. You will have to address issues at the
> user experience level, and at a lower lever.
This has already been largely addressed in the most recent beta which has support for native file and save dialogs.
I think it's going to be an intentional design goal that other than at a few particular points like those dialogs that the UI for the OSX and the Windows versions will be the same, which in MoI's case works out ok since it was not really ever set up to look or behave like a standard boilerplate Windows program in the first place. So in the same way that I ignored many Windows UI conventions, it doesn't really bother me to ignore some of the OSX strict conventions as well and have something that has its own UI instead of boilerplate.
> Things like keeping all data in Applications Support in
> order to survive updates,
This is already done - as of the most recent beta things that are supposed to survive updates and be separate from a particular installation are stored in ~/Library/Application Support/Moi , like for example the moi.ini file lives there now so any settings that you set in this most recent beta will persist with a new beta.
So that's a solved problem, what's the big remaining issue with it?
> custom plugins that require something other than javascript, UI
> inconsistencies and a number of other issues i can't begin to
> imagine.
In the future if it's possible to make a custom plugin with a C++ dll and the same exact binary plug-in will work on both the Windows and OSX versions with the same binary, how is that a bad thing?
> And it will never be as smooth as a native app, even though the
> math are running at almost the native speed.
That's incorrect - math and pure calculations are absolutely running at 100% native speed - it's loading native x86 machine code and running that code directly on the CPU. That part is not "almost" native speed - it's fully native code execution.
> Now, unless some of the external libraries you are using are
> not available for OSX, your time might be better spent doing
> a native port.
The problem is that what you are asking for would require an enormous investment of time, there is so much stuff that would need to be rewritten, it's simply not something that is feasible for me to tackle.
And I have to balance that against what the actual practical benefit would be once all that work is finished, which would mostly seem to be just some kind of abstract architectural purity and not really any actual measurable improvement.
Anyway, I'm sorry that you're disappointed in some way with the OSX version, I guess I can understand that if you're really into consistency as a really high value thing that you might not like it when an app goes outside of that. There do exist some people that don't like the Windows version for the same kind of reason - that it does not just follow a standard Windows UI approach either. I guess if you're really into a program following a standard boilerplate UI with no deviation from standard controls and the like, that MoI just won't be a good fit - it's just not what MoI is about - right from the beginning I was not afraid to experiment with different kinds of UI with MoI and that's sort of embedded in its design philosophy that differences from a standardized UI are not automatically a bad thing.
I can understand though if this does not agree with your own design philosophy which from what you are describing it seems that it doesn't. And sure, I can understand that you wish that MoI was developed with the same design philosophy you have... But it's not.
I do wish though that you would be more concerned with actual empirical problems with the current OSX version rather than worrying so much about theoretical purity.
There were times when I wondered if it was really worthwhile to even attempt an OSX version because there is a kind of undercurrent of intolerance for things that deviate from the "one true way of Cocoa"... That's kind of what I'm getting from what you're describing here. But it seems that for the majority of people anyway, more practical concerns like "does it perform well", and "is it easy to use without special installation tricks" and things like that seem to trump worrying about architectural purity. And I think the current version is hitting those targets.
I mean like for example right now when I go to draw a circle, the circle redraws on the screen what appears to my eye as instant feedback from when I move the mouse. I don't understand how you think there is going to be any improvement on that? I mean what faster level is there than instant?
Maybe I should not have written all of this since you will probably perceive it as an attack on you. Instead please think of it as more of a disagreement with your conclusions.
- Michael
|
