Subject:
|
Re: LDView 3.1 on Mac OS X!
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Tue, 20 Feb 2007 03:12:48 GMT
|
Viewed:
|
9944 times
|
| |
|
|
In lugnet.cad.dev.mac, Travis Cobbs wrote:
| |
In lugnet.cad.dev.mac, Jim DeVona wrote:
| |
In lugnet.cad.dev.mac, Travis Cobbs wrote:
Boy, I should have just tried the development code from the start! However,
I tried it out this morning and I do encounter a problem when running
makeall. It boils down to this:
TCLocalStrings.cpp: In member function 'void TCLocalStrings::mbstowstring(std::wstring&, const char*, int)':
TCLocalStrings.cpp:1180: error: invalid cast from type 'QChar' to type 'wchar_t'
lipo: can't figure out the architecture type of: /var/tmp//cc960xuw.out
|
|
Looks like a string conversion issue, but I’m not sure if the architecture
reference implies something else. I’m not familiar with the QT APIs or many
C++ classes, so I haven’t really tried to figure it out.
|
I have to wonder what QChar is defined as in QT4. In QT3, it’s just an
integer type, as far as I can tell. The wchar_t type is just an integer
type (4-byte integer in Linux, 2-byte integer in Windows, not sure about
OSX). I suspect this error will go away if you compile against QT 3.3.7.
However, at some point LDView will be compiled under QT 4, so I’ll
investigate to see if I can figure out what’s up.
|
On my MacBook, wchar_t is a 4-byte type. I’m not sure about the QChar
definition. I’ve found a class definition in /src/corelib/tools/qchar.h/.cpp,
but my C++ is weak so on first glance I’m not sure how to interpret its type
compatibility.
| |
| |
Yes, I built my version with QT 4.2.2, which was simply the current version
being distributed by Trolltech. What problems, specifically, should I be looking for with QT 4?
I’ve found ftp//ftp.trolltech.com/qt/source/qt-mac-free-3.3.7.tar.gz, but
unlike QT 4, it’s not building successfully on the first try. Nevertheless,
could the casting error noted above be related to which version of QT I’m
using? At any rate, the border does look nicer - more compact - in the
screenshot you posted.
|
Take a look at todo.txt in the QT source directory of the cvs source. It
lists the QT 4 problems. As for the border, while the QT 4 border looks more
Mac-like, I definitely think the more compact border is more appropriate.
Once LDView itself is targeted more directly at QT 4, that will be one of the
things that get investigated.
|
The compact border is definitely more appropriate.
Regarding a few of the problems listed in todo.txt:
- repaint problem during model loading (paintEvent) bug ID 79310: I’m not sure what I’m supposed to see, but I don’t see any noticeable artifacts when loading models. The display remains black when loading the first model, remains displaying the previous model when loading a new one.
- toggle buttons on toolbar not work (toggle signal is not received, bug reported to Trolltech, bug ID 80931): If the “toggle buttons” are the “Wireframe,” “Seams,” “Edge,” “Primitive Substitution,” and “Lighting” buttons, then their appearance does change to indicate state just fine.
- Toolbar buttons initial status is always inactive, does not reflect the real, stored status (bug id 91403): The state of the buttons listed above does seem to be preserved from launch to launch, consistent with your previous selections and what is rendered.
The problems with the Open dialog don’t sound like bugs, per se, so much as
characteristic differences between the behavior of file selection interfaces
on different platforms (or between native and typical cross-platform toolkits).
That’s not to say it doesn’t pose a problem for some users, of course.
| |
| |
Anyway, as for my LDView 3.1 first impressions:
- Cutaway mode is cool.
- POV-Ray camera info export is going to be really handy.
- Automatic download of missing parts is also cool and very handy. I tested it with the example 8464.mpd model, and I was particularly pleased to find that Bricksmith can access the Unofficial parts too.
|
I’m glad that Bricksmith can make use of them. Does it have a UI to add new
directories to the part search path?
|
Nope, so I had feared it might not be able to access them. However, I’ve checked
and Unofficial is hard-coded as the unofficial parts directory name (in
Source/Other/MacLDraw.h, for those following along at home). You can set the
LDraw directory, of course, so it will just look for an “Unofficial” directory
within that.
| |
| |
- The variety of display options are fun.
- Snapshots are nice.
On the down side,
- The clunkier border and toolbar area you noticed with my QT version remain visible in full screen mode. (The strip between the toolbar and display is really part of the display border, as it remains visible when the toolbar is hidden.)
|
Full-screen mode in general isn’t optimal on the Mac (after all the menu bar
across the top of the screen and the Dock both stay visible as well). That’s
something that will be investigated, but I’m not sure if anything will be
done for true full-screen support. (There’s hope that I’ll eventually have a
Cocoa-native version of LDView. That one would have better full-screen
support, but it’s a long ways off.)
|
In fact, the menu bar and Dock do not remain visible in full screen mode with
this build, so it really is “full screen” (barring the border - which I suspect
is the sort of thing that could probably be eliminated with some QT 4
style property).
Full-screen example.
| |
| |
- I can’t seem to invoke “Fly Through” mode - the menu item becomes checked appropriately, but the status bar continues to read “Examine” and none of the fly through controls seem to be active. (In other words, except for the menu indicator, it remains in “Examine” mode.)
|
That’s very odd. It works fine in the version I compiled.
|
OK.
| |
| |
- Very minor - modifier key/mouse controls noted in help text are somewhat different on Mac OS X. Command instead of control, etc.
|
I plan to update the help file to state that anywhere you see the word
Control used, it actually means Command on the Mac. Additionally, Ctrl+click
equals right mouse button (as is standard on the Mac). If you see any other
differences in the modifers, let me know.
|
Command/control is actually the only change I’ve noticed. With a regular mouse
plugged in, right clicking performs as described; otherwise, yeah, control
click. Spinning the scroll wheel on my mouse does not zoom in or out, though.
| |
| |
It’s exciting to have a new tool in the Mac LDraw arsenal. Please let me
know of any way I can help bring 3.2 to fruition, from testing to simply
sharing more specific information about the problems I’ve noted. Also, given
the presumed Boost/QT dependency of the version I’ve built, and the fact
that you are incorporating more Mac OS X support in the next official
release, I’m thinking it might not be worthwhile to post the version I
compiled (as users will still have to install Boost/QT - something I hadn’t
thought of last night). What do you think?
|
That’s a tough call. On the one hand, only power users are likely to go to
the hassle necessary to get the QT and Boost shared libraries installed onto
their computers. On the other hand, as I mentioned, I don’t currently have
an estimated release date for LDView 3.2. Also, you should have static libs
for Boost already. If you just delete the shared ones and rebuild LDView, it
should remove that particular dependency. If you want, you can try building
QT 3.3. Here are my build command lines:
echo yes./configure -release -static -thread -fast -no-largefile
make symlinks src-qmake src-moc sub-src sub-tools
Before you build it, you have to edit mkspecs/macx-g++/qmake.conf, and update
the QMAKECFLAGS line to look like so:
QMAKECFLAGS = -pipe -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -DQTQLOCALEUSESFCVT
(Specifically, add the -DQTQLOCALEUSESFCVT to the end of the existing
line.)
--Travis
|
Thanks for that information. When I get another chance to sit down with this
for a while, I’ll tentatively work on building a self-contained version of 3.1
(as much as possible) so that people can use until your release is ready.
Thanks again for the effort and information.
Jim
|
|
Message has 1 Reply:
 | | Re: LDView 3.1 on Mac OS X!
|
| (...) I took a look at the QChar docs in both QT 3 and QT 4, and updated the failing line of code to call the unicode() function on the QChar object. This builds fine in QT 3, and should also build fine in QT 4. I haven't had a chance yet to see if (...) (17 years ago, 20-Feb-07, to lugnet.cad.dev.mac, FTX)
|
Message is in Reply To:
| | Re: LDView 3.1 on Mac OS X!
|
| (...) I have to wonder what QChar is defined as in QT4. In QT3, it's just an integer type, as far as I can tell. The wchar_t type is just an integer type (4-byte integer in Linux, 2-byte integer in Windows, not sure about OSX). I suspect this error (...) (17 years ago, 20-Feb-07, to lugnet.cad.dev.mac, FTX)
|
39 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
