Subject:
|
Re: LDView 3.1 on Mac OS X!
|
Newsgroups:
|
lugnet.cad.dev.mac
|
Date:
|
Tue, 20 Feb 2007 04:59:10 GMT
|
Viewed:
|
11181 times
|
| |
|
|
In lugnet.cad.dev.mac, Jim DeVona wrote:
| |
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.
|
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 it actually works as expected, but I don’t see why it wouldn’t. (The
only way to be sure it works is to use a non-English language setup in LDView
and verify that the special characters display correctly.)
Note that while I have committed the change to cvs, it takes a while for the
change to propogate to the anonymous cvs. I don’t know how long it takes, but
it’s no more than 24 hours.
| |
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.
|
So either the bug was specific to the Linux version of QT, or it has been fixed
since Peter discovered it.
| |
- 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.
|
Those are the buttons. I believe that the problem was that LDView didn’t update
when you clicked them. So clicking the wireframe toolbar button had no effect.
| |
- 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.
|
I believe this is in reference to choosing the LDraw directory. In that case,
you’re choosing a directory, not a file. However, if that worked for you, then
it would seem that this works OK on Mac OSX at least.
| |
| |
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.
|
Interesting. I wonder if it was just a coincidence that we both chose the same
hard-coded directory for Unofficial parts, or if Bricksmith’s author saw that I
had used it. I suspect the former, since LDView didn’t work on the Mac.
| |
| |
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).
|
That’s good. I guess now I just have to figure out why it’s drawing that really
large border across the top and the relatively large border around the other
sides.
| |
| |
| |
- 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.
|
It could be that that was broken in the Linux QT version of LDView 3.1, and is
fixed in the 3.2 code-base.
| |
| |
| |
- 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.
|
Scroll wheel support failed to make it into the QT version until after the 3.1
release. It was something I noticed after I started using the QT version more
heavily. It’s in the 3.2 code-base. (It even works with the Macbook touch pad
when you use two fingers and move up and down.)
| |
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.
|
You’re welcome. From what you said above, it sounds like the only real problem
with compiling with QT 4.2.x is the extra-large border around the main graphics
window. I suspect that can be dealt with fairly easily. I’ll probably download
the latest QT and see how it goes. I can also check to see if the
fly-through/examine switch is a QT 4 problem or an LDView 3.1 problem.
| |
Thanks again for the effort and information.
|
You’re welcome. And thank you for taking the time to get this going yourself on
your own. Knowing that it works fairly well in QT 4 is good to know.
--Travis
|
|
Message has 2 Replies:
 | | Re: LDView 3.1 on Mac OS X!
|
| (...) Hi, Travis. I've (URL) LDView 3.2> with Qt 4.2.2 using your updated code. I thought I'd share my leads on the remaining kinks before proceeding. First, how I got it to compile: I expanded libtool to /usr/bin/libtool at line 13 of Makefile.inc (...) (18 years ago, 21-Feb-07, to lugnet.cad.dev.mac, FTX)
| | | Re: LDView 3.1 on Mac OS X!
|
| I'm delighted to see another developer supporting the Macintosh. (...) Yeah, LDraw/Unofficial just seemed like the logical choice. That was feature that went nowhere, though. I never even documented it, because I didn't think anyone else supported (...) (18 years ago, 27-Feb-07, to lugnet.cad.dev.mac, FTX)
|
Message is in Reply To:
| | Re: LDView 3.1 on Mac OS X!
|
| (...) On my MacBook, wchart is a 4-byte type. I'm not sure about the QChar definition. I've found a class definition in /src/corelib/tools/q...ar.h/.cpp, but my C++ is weak so on first glance I'm not sure how to interpret its type compatibility. (...) (18 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
|
|
|
|
