 | | | | | | |
| |
|
I know you've already mostly decided on a direction, but I figured I'd throw in
my two cents. LDView takes a different tack for cross-platform support: all the
back-end code is cross-platform C++, but the UI code is platform-specific. So
my Windows UI is written in Win32 (not MFC, for various reasons), my Mac UI is
written in Cocoa, and my Linux UI is written in Qt. (The Qt version is
maintained by a separate developer.)
Given that there is a Qt version of LDView, it would seem that the Windows and
Mac versions are a waste of time. However, I've personally found that doing the
native UIs produces better end quality, and over time I've gotten fairly good at
keeping as much code as possible in the shared portion. As an example of this,
I have a class in the shared code that purely handles input, and then does all
the processing on that input necessary to decide what to do. The
platform-specific calls just tell it things like mouseDown(shiftKeyFlags,
location), or keyDown(shiftKeyFlags, keyCode), and it handles the rest,
including notification-based requests for screen redraws.
So, when the user clicks and drags the mouse in the main window of LDView, the
UI code simply sends a mouseDown() call, followed by mouseMove() calls, and the
input handler takes those and does all the rest. Assuming LDView is in examine
mode, the mouse down location is recorded. Then, when the first mouseMove()
call comes in, it calculates the deltas, informs the viewer to start rotating at
an appropriate speed, and then sends a redraw request notification. The UI code
receives the redraw request notification and does whatever is necessary in the
specific UI to force the view to redraw. The viewer itself checks to see if any
kind of animation is ongoing at the end of its frame draw. If so, it
immediately request another redraw. (The actual redraw happens a little later,
or there'd be infinite recursion, but you get the idea.)
This is all predicated on the fact that the actual renderer in LDView is generic
OpenGL code. It probably wouldn't work so well otherwise, but I personally find
it to work well overall.
--Travis
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Travis Cobbs wrote:
> I know you've already mostly decided on a direction, but I figured I'd throw in
> my two cents. LDView takes a different tack for cross-platform support: all the
> back-end code is cross-platform C++, but the UI code is platform-specific. So
> my Windows UI is written in Win32 (not MFC, for various reasons), my Mac UI is
> written in Cocoa, and my Linux UI is written in Qt. (The Qt version is
> maintained by a separate developer.)
>
> Given that there is a Qt version of LDView, it would seem that the Windows and
> Mac versions are a waste of time. However, I've personally found that doing the
> native UIs produces better end quality, • <snip>
>
> --Travis
Thanks for the insight,
Actually the more 'local' feel to interfaces is the reason why I'm a bit more
leaning towards wxWidgets at the moment, it uses native controls where possible
on all platforms. But Qt is clearly more featured so I'll probably be using that
for more advanced GUI's if customers are visually fixated.
Roland
| | | | | | |
