| |
Hello,
In LPub, is it possible to specify the physical resolution for generated images?
Not the pixel width & height, but the physical document width & height in
inches, and the resolution in pixels/inches. Of course, this affects only
printed documents.
It seems LPub generates all images at a default 72 pixels/inch. It'd be sweet
if that could be controlled in the dialogs - it'd save changing each image's
resolution by hand, anyway. Maybe just a set of controls:
[checkbox] Resolution: [textbox]
similar in layout & operation to 'Threshold/Depth/Jitter' on the POV Rendering
tab. Or even a step further; text boxes for physical Width/Height and
Resolution, and the ability to set either Width/Height or Resolution, and see
how that setting alters the other... something like the Document Size controls
in Photoshop's Image Size dialog, I imagine.
I can elaborate further, if the above doesn't make sense.
Cheers,
Remi
|
|
| |
In lugnet.cad.dev, Remi Gagne wrote:
> Hello,
>
> In LPub, is it possible to specify the physical resolution for generated images?
> Not the pixel width & height, but the physical document width & height in
> inches, and the resolution in pixels/inches. Of course, this affects only
> printed documents.
Sorry. No not yet.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Remi Gagne wrote:
> > Hello,
> >
> > In LPub, is it possible to specify the physical resolution for generated images?
> > Not the pixel width & height, but the physical document width & height in
> > inches, and the resolution in pixels/inches. Of course, this affects only
> > printed documents.
>
> Sorry. No not yet.
>
> Kevin
Hi Remi,
I'm working on DPM and DPI now.
Here is what I plan on doing:
You set the page size in either inches or centimeters. You define the
resolution in terms of DPI or DPM. You control the magnification. For example,
if I have a 1 inch page size, and a lego part that appears a half an inch wide,
with a magnification of 1.0, the part should take up half the page. With a 2x
magnification, the part should take up the whole page.
Changing DPM/DPI does not change the relative sizes of things with respect to
the page size, it just makes sure everything has more or less pixels.
Now I just have to figure out how to compute everything down to pixels and
we're good to go.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > In lugnet.cad.dev, Remi Gagne wrote:
> > > Hello,
> > >
> > > In LPub, is it possible to specify the physical resolution for generated images?
> > > Not the pixel width & height, but the physical document width & height in
> > > inches, and the resolution in pixels/inches. Of course, this affects only
> > > printed documents.
> >
> > Sorry. No not yet.
> >
> > Kevin
>
> Hi Remi,
> I'm working on DPM and DPI now.
>
> Here is what I plan on doing:
>
> You set the page size in either inches or centimeters. You define the
> resolution in terms of DPI or DPM. You control the magnification. For example,
> if I have a 1 inch page size, and a lego part that appears a half an inch wide,
> with a magnification of 1.0, the part should take up half the page. With a 2x
> magnification, the part should take up the whole page.
>
> Changing DPM/DPI does not change the relative sizes of things with respect to
> the page size, it just makes sure everything has more or less pixels.
>
> Now I just have to figure out how to compute everything down to pixels and
> we're good to go.
>
> Kevin
Most of this feature is done. I had to identify every LPub meta-command that
had something with the units of pixels, and treat them as a new class of
"units", meaning known absolute distances (i.e. meters or inches.) Every time
these values are used, the class they're in automatically converts the results
to pixels (simple multiplication), and voila, we've solved almost all the
resolution dependent issues. The size of the window used is the same size as
the page.
I've got a bit of math to figure out, but the plan is to give the user a control
called magnification (or zoom). Changing magnification changes the image size
of the model relative to the page.
Magnification of 1.0 makes a model that is 8 inches wide when measured from the
viewer's vantage point exactly fit in an 8 inch page. Decreasing the
magnification makes the model image smaller than the page, increasing the
magnification to greater than provides a magnifying affect.
I'm told the new L3P will provide true orthographic projection, but with the
current version of L3P, I approximate orthographic (no perspective) with a very
small camera lens angle. I'll have to use trigonometry to figure out the camera
distance for the current L3P.
The only issue left is fonts. I have to figure out how to express fonts in real
world units and how to map that to points or whatever. Time to learn more new
stuff. If anyone is knows much about this topic let me know.
Scalable fonts would probably be best to use (if they can be found).
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
SNIP
>
> The only issue left is fonts. I have to figure out how to express fonts in real
> world units and how to map that to points or whatever. Time to learn more new
> stuff. If anyone is knows much about this topic let me know.
>
> Scalable fonts would probably be best to use (if they can be found).
>
> Kevin
Maybe the following link does help you a little bit:
http://en.wikipedia.org/wiki/Point_%28typography%29
If you use truetype fonts it should not be a problem to print them in the
correct size.
cu
mikeheide
|
|
| |
In lugnet.cad.dev, Michael Heidemann wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
>
> SNIP
>
> >
> > The only issue left is fonts. I have to figure out how to express fonts in real
> > world units and how to map that to points or whatever. Time to learn more new
> > stuff. If anyone is knows much about this topic let me know.
> >
> > Scalable fonts would probably be best to use (if they can be found).
> >
> > Kevin
>
> Maybe the following link does help you a little bit:
> http://en.wikipedia.org/wiki/Point_%28typography%29
>
> If you use truetype fonts it should not be a problem to print them in the
> correct size.
>
> cu
> mikeheide
I just found the following in my VB description:
1440 Twips = 1 inch
1 Twips = 1/20 point (DTP)
1 cm = 567 Twips
1 point = 0,3515 cm (72 dpi)
maybe this is also useful.
cu
mikeheide
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
The only issue left is fonts. I have to figure out how to express fonts in
real world units and how to map that to points or whatever. Time to learn
more new stuff. If anyone is knows much about this topic let me know.
Scalable fonts would probably be best to use (if they can be found).
|
I learnt a fair bit fiddling with Freetype in
txt2dat, which has to translate
point size to ldraw units. Freetype makes it pretty easy, as it gives you a nice
API that works for lots of scalable fonts. I chose not to support non-scalable
fonts in txt2dat, so not sure how hard they are to use.
ROSCO
|
|
| |
In lugnet.cad.dev, Ross Crawford wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
The only issue left is fonts. I have to figure out how to express fonts in
real world units and how to map that to points or whatever. Time to learn
more new stuff. If anyone is knows much about this topic let me know.
Scalable fonts would probably be best to use (if they can be found).
|
I learnt a fair bit fiddling with Freetype in
txt2dat, which has to
translate point size to ldraw units. Freetype makes it pretty easy, as it
gives you a nice API that works for lots of scalable fonts. I chose not to
support non-scalable fonts in txt2dat, so not sure how hard they are to use.
ROSCO
|
Hi Rosco,
I’m going to make my font dialog, and default font picker only work with
scalable fonts. They are perfect for this kind of situation. I guess that is
why they were created by Adobe a long time ago (I read the Wiki!)
Thanks,
Kevin
|
|
| |
I've got the math and implementation of resolution (dots per
inch/meter/millimeter) as well as magnification for controlling model size
relative to the page all worked out. Magnification 1.0 means a model that
appears 8 inches wide will just fit in an 8 inch page. Smaller magnification
makes the model appear smaller, larger magnification lets you zoom into the
model (though you don't have control over where the camera looks). No more
camera distance stuff. No more camera distance stuff. All parts in the entire
building instructions will be at the same scale unless you intentionally change
magnification.
Scalable fonts are the ticket for building instructions, because they are easy
to work with when changing resolution.
One new metacommand
0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
defines the resolution.
The values in the LDraw file are either in inches, or centimeters, depending on
what resolution says. Sorry, no meter or millimeter expressions, just inches or
centimeter. No unit string like "INCHES" "IN" or "CM". The units are implied
by resolution.
One issue is that some meta-commands currently are in pixels (margins, divider
thickness, etc.) If LPub does not see a RESOLUTION metacommand it will assume
pixels, and convert them internally to inches. The ldraw file could remain in
pixels, or I could let you choose to convert.
I'm no officianado on the metric system and desk top publishing so if there are
any interesting topics specific to this, please let me know.
I just wanted to boast a bit (ok, maybe more than a bit) at what LPub 4 is like.
A long time ago Ahui pointed out that LPub 1 was not really a building
instruction generator. It just automated the process of creating some of the
artwork for building instructions. LPub 2 tried to address this with layouts,
but it was combersome and problematic at best. LPub 4 is a building instruction
editor. LPub 3 was aborted.
LPub 4 is page oriented and shows you the building instructions in the page as
they appear after applying all the meta commands. You specify all margins, line
thicknesses, and the page size in the units you chose when specifying
resolution. You can zoom in and out, and scroll around the page. You can save
the building instructions to a PDF file. Sorry, no web page stuff yet.
You can convert a submodel to a callout with one menu choice "Convert to
Callout". You can move the callout around the screen by clicking to select and
then click, drag, and release. You can add a pointer with one menu choice. If
possible, LPub provides you with a horizontal or vertical pointer. If not
possible it bases the pointer in corner closest to the assembly image. If you
do not like the pointer, you can drag the tip around, you can move the base
around, and change the base thickness, all with the mouse. Arrows (rather than
the triangle based pointers) will come later.
You can have nested callouts.
To go from single step to a (multi) step group, you use one of two menus "Add
Next Step" or "Add Previous Step". To move a step to the next or previous
row/column (i.e. past a divider) takes one menu click. You can have nested
callouts inside the step group, or inside the page.
With all these activities, LPub updates the LDraw file with the proper
metacommands, which you don't have to know.
You can manually edit the LDraw file from within LPub too (for those advanced
features not yet implemented in the GUI).
You will be able to specify Parts List parts (of a specific color) individual
magnification as well as orientation (not done yet). Half-size and orientation
files supported. You can turn on/off parts list per step in callout/step
groups. You can not have parts lists in your instructions.
Much tighter syntax checking with feedback from the edit window highlighting the
line in error.
It does not require L3P, only ldglite 1.2 or higher. You provide a
magnification. If it is not right, you change it. LPub will not automatically
adjust if the model is cropped by edge of page.
There is help for each menu item. There are balloons that tell you what the
model path is (e.g. /rooster.ldr/right-leg.ldr), as well as simple balloons that
tell you you are in a callout, or step number, or page number.)
I've worked hard at using simple vocabulary... placement becomes move, scale
becomes size, PLIs become parts lists, multi-step groups (a bit redundant eh?)
become step groups. Callouts are still called callouts. I want kids to be able
to use it easily.
I don't have a comprehensive help/tutorial done.
There are some advanced things not done yet:
insertion of pictures
pages without any steps in the (cover page, inside cover page, inside back page,
back page).
insertion of simple drawing shapes like lines, arrows, triangles, rectangles,
etc.
insertion of arbitrary text.
There are some not done yet having to do with the PLI:
Resize the PLI with the mouse.
Substitute some of the parts in the PLI with this other part.
Ignore these parts and don't put them in the PLI.
BOM is not done, but I'd like to implement an interactive BOM mechanism where
you can get a list of the steps where all the parts are used, click one, and
automatically go to the page/step where it was added to the model.
These things will not be finished before you get a chance to try it, but this
will:
Individual magnification and orientation of parts in PLI.
Due to compiler differences, I've got to do some work before it will even
compile for the Mac (but that is all mechanical, very little actual figuring out
stuff needs to be done.)
Did I whet your appetite?
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> I've got the math and implementation of resolution (dots per
> inch/meter/millimeter) as well as magnification for controlling model size
> relative to the page all worked out. Magnification 1.0 means a model that
> appears 8 inches wide will just fit in an 8 inch page. Smaller magnification
> makes the model appear smaller, larger magnification lets you zoom into the
> model (though you don't have control over where the camera looks). No more
> camera distance stuff. No more camera distance stuff. All parts in the entire
> building instructions will be at the same scale unless you intentionally change
> magnification.
SNIP
> Did I whet your appetite?
>
> Kevin
Only one question is left!
When can we get that?
cu
mikeheide
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> One new metacommand
>
> 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
>
> defines the resolution.
Shouldn't that be:
0 !LPUB RESOLUTION <value> (DPI|DPCM)
Based on this:
> The values in the LDraw file are either in inches, or centimeters, depending on
> what resolution says. Sorry, no meter or millimeter expressions, just inches or
> centimeter. No unit string like "INCHES" "IN" or "CM". The units are implied
> by resolution.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > One new metacommand
> >
> > 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
> >
> > defines the resolution.
>
> Shouldn't that be:
>
> 0 !LPUB RESOLUTION <value> (DPI|DPCM)
>
> Based on this:
>
> > The values in the LDraw file are either in inches, or centimeters, depending on
> > what resolution says. Sorry, no meter or millimeter expressions, just inches or
> > centimeter. No unit string like "INCHES" "IN" or "CM". The units are implied
> > by resolution.
>
> --Travis
When I looked around on the net I saw references to DPM and DPMM.... I didn't
see DPCM.... it does make complete sense to use DPCM, but I wasn't sure people
would think its a standard name.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > One new metacommand
> > >
> > > 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
> > >
> > > defines the resolution.
> >
> > Shouldn't that be:
> >
> > 0 !LPUB RESOLUTION <value> (DPI|DPCM)
> >
> > Based on this:
> >
> > > The values in the LDraw file are either in inches, or centimeters, depending on
> > > what resolution says. Sorry, no meter or millimeter expressions, just inches or
> > > centimeter. No unit string like "INCHES" "IN" or "CM". The units are implied
> > > by resolution.
> >
> > --Travis
>
> When I looked around on the net I saw references to DPM and DPMM.... I didn't
> see DPCM.... it does make complete sense to use DPCM, but I wasn't sure people
> would think its a standard name.
I'd say that DPM or DPMM make perfect sense. The thing is, your description
said that units are all in CM or IN, and that M and MM aren't supported. And
yet, you force the user to specify which units to use in either IN, M, or MM.
That seems very inconsistent.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > In lugnet.cad.dev, Travis Cobbs wrote:
> > > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > > One new metacommand
> > > >
> > > > 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
> > > >
> > > > defines the resolution.
> > >
> > > Shouldn't that be:
> > >
> > > 0 !LPUB RESOLUTION <value> (DPI|DPCM)
> > >
> > > Based on this:
> > >
> > > > The values in the LDraw file are either in inches, or centimeters, depending on
> > > > what resolution says. Sorry, no meter or millimeter expressions, just inches or
> > > > centimeter. No unit string like "INCHES" "IN" or "CM". The units are implied
> > > > by resolution.
> > >
> > > --Travis
> >
> > When I looked around on the net I saw references to DPM and DPMM.... I didn't
> > see DPCM.... it does make complete sense to use DPCM, but I wasn't sure people
> > would think its a standard name.
>
> I'd say that DPM or DPMM make perfect sense. The thing is, your description
> said that units are all in CM or IN, and that M and MM aren't supported. And
> yet, you force the user to specify which units to use in either IN, M, or MM.
> That seems very inconsistent.
>
> --Travis
I'm actually can provide all of the above and to the math, I just don't want to
have units expressed in individual meta commands. I ony want one unit and to
have it expressed in the resolution meta command. So I could even have DPDM.....
(decimeters? ;^)
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > In lugnet.cad.dev, Travis Cobbs wrote:
> > > > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > > > One new metacommand
> > > > >
> > > > > 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
> > > > >
> > > > > defines the resolution.
> > > >
> > > > Shouldn't that be:
> > > >
> > > > 0 !LPUB RESOLUTION <value> (DPI|DPCM)
I agree. It was inconsistent. I've provided DPM, DPCM, DPMM, and the values
specified in meta commands are scaled appropriately.
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > In lugnet.cad.dev, Travis Cobbs wrote:
> > > > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > > > One new metacommand
> > > > >
> > > > > 0 !LPUB RESOLUTION <value> (DPI|DPM|DPMM)
> > > > >
> > > > > defines the resolution.
> > > >
> > > > Shouldn't that be:
> > > >
> > > > 0 !LPUB RESOLUTION <value> (DPI|DPCM)
I agree. It was inconsistent. I've provided DPM, DPCM, DPMM, and the values
specified in meta commands are scaled appropriately.
|
|
| |
> I agree. It was inconsistent. I've provided DPM, DPCM, DPMM, and the values
> specified in meta commands are scaled appropriately.
DPCM might be enough: Photoshop (which can be considered as a reference...) only
has DPI and DPCM.
Philo
|
|
| |
In lugnet.cad.dev, Philippe Hurbain wrote:
> > I agree. It was inconsistent. I've provided DPM, DPCM, DPMM, and the values
> > specified in meta commands are scaled appropriately.
>
> DPCM might be enough: Photoshop (which can be considered as a reference...) only
> has DPI and DPCM.
>
> Philo
Thanks Philo!
I've limited to dots per inch inch and dots per centimeter. This is nice from a
formatting pespective because margins and sizes fall into smaller ranges than
with inches and meters.
Kevin
|
|
| |
Hi folks,
For those interested, I thought I'd give you a peek at LPub 4.0's GUI. I
started with and LPub free file well, except for PLI sub kind of metas. I
converted the submodels to callouts, placed the callouts, added pointers to the
calloutss, and placed the pointer tips all with the mouse.
I've got a lot of stuff to test, before I let Philo have a crack at it, but it
is getting better fast.
http://www.brickshelf.com/gallery/kclague/LPub4/lpub.png
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> Hi folks,
>
> For those interested, I thought I'd give you a peek at LPub 4.0's GUI. I
> started with and LPub free file well, except for PLI sub kind of metas. I
> converted the submodels to callouts, placed the callouts, added pointers to the
> calloutss, and placed the pointer tips all with the mouse.
>
> I've got a lot of stuff to test, before I let Philo have a crack at it, but it
> is getting better fast.
>
> http://www.brickshelf.com/gallery/kclague/LPub4/lpub.png
>
> Kevin
It looks like this project is coming along nicely! Great work.
Jim
|
|
| |
In lugnet.cad.dev, Jim DeVona wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > Hi folks,
> >
> > For those interested, I thought I'd give you a peek at LPub 4.0's GUI. I
> > started with and LPub free file well, except for PLI sub kind of metas. I
> > converted the submodels to callouts, placed the callouts, added pointers to the
> > calloutss, and placed the pointer tips all with the mouse.
> >
> > I've got a lot of stuff to test, before I let Philo have a crack at it, but it
> > is getting better fast.
> >
> > http://www.brickshelf.com/gallery/kclague/LPub4/lpub.png
> >
> > Kevin
>
> It looks like this project is coming along nicely! Great work.
>
> Jim
Thanks Jim!
I've spent weeks of vacation time working on this. Good thing I have a lot
more.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> Hi folks,
>
> For those interested, I thought I'd give you a peek at LPub 4.0's GUI. I
> http://www.brickshelf.com/gallery/kclague/LPub4/lpub.png
Wow Kevin! Looks awsome. Will it also come with LDconfig support, unofficals and
custom folders, background images ... furthermore are those arrows coming from
MLCad or has 4.0 its own generator?
w.
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > Hi folks,
> >
> > For those interested, I thought I'd give you a peek at LPub 4.0's GUI. I
> > http://www.brickshelf.com/gallery/kclague/LPub4/lpub.png
>
> Wow Kevin! Looks awsome. Will it also come with LDconfig support, unofficals and
> custom folders, background images ... furthermore are those arrows coming from
> MLCad or has 4.0 its own generator?
>
> w.
Hi Willy,
Thanks! Background images are already in as is ldconfig.ldr. The arrows come
from your generator in MLCad.
When you say unofficials and custom folders, what are you thinking? Since it
uses ldglite, there are some rederer features I do not have control over.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
Hi Kevin,
> When you say unofficials and custom folders, what are you thinking? Since it
> uses ldglite, there are some rederer features I do not have control over.
I was refering to the use of unofficial and custom parts and the possibilities
to include them into BI without the need to store them in the <LDRAWDIR>Parts
folder or include them in Parts.lst.
w.
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
>
> Hi Kevin,
>
> > When you say unofficials and custom folders, what are you thinking? Since it
> > uses ldglite, there are some rederer features I do not have control over.
>
> I was refering to the use of unofficial and custom parts and the possibilities
> to include them into BI without the need to store them in the <LDRAWDIR>Parts
> folder or include them in Parts.lst.
>
> w.
You are more knowledgable on this topic than I am. As far as the assembly
images go, at least for now I'm at the mercy of LDGlite. I've made good use of
the superb document and specifications on LDraw.org. I want to thank all
involved in updating the specifications and website.
I did not find any "official" specification for alternate pathing of parts. I'm
very interested in implementing the standard, or the defacto standard, if I knew
where to find an explanation.
In PLI's, LPub displays the parts color name (from LDConfig), the part number
(yes, even on the Mac version Allan!), and the part title. Currently I get
these titles from PARTS.LST, but that is not sufficient, and it is a short
sighted implementation.
I also get part length from the titles, so supporting unofficials is important.
I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
getting LPub going there. I know it is unix (which I know very well), but I did
not find make or the gcc tools (which I also know very well) using find.
I'm antsy to get going there. Any ideas on where to get started?
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> getting LPub going there. I know it is unix (which I know very well), but I did
> not find make or the gcc tools (which I also know very well) using find.
>
> I'm antsy to get going there. Any ideas on where to get started?
I think those and other development tools are available as an optional install
from your system DVD, if they're not already present on the machine.
Jim
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Willy Tschager wrote:
> > In lugnet.cad.dev, Kevin L. Clague wrote:
> >
> > Hi Kevin,
> >
> > > When you say unofficials and custom folders, what are you thinking? Since it
> > > uses ldglite, there are some rederer features I do not have control over.
> >
> > I was refering to the use of unofficial and custom parts and the possibilities
> > to include them into BI without the need to store them in the <LDRAWDIR>Parts
> > folder or include them in Parts.lst.
> >
> > w.
>
> You are more knowledgable on this topic than I am. As far as the assembly
> images go, at least for now I'm at the mercy of LDGlite. I've made good use of
> the superb document and specifications on LDraw.org. I want to thank all
> involved in updating the specifications and website.
>
> I did not find any "official" specification for alternate pathing of parts. I'm
> very interested in implementing the standard, or the defacto standard, if I knew
> where to find an explanation.
>
> In PLI's, LPub displays the parts color name (from LDConfig), the part number
> (yes, even on the Mac version Allan!), and the part title. Currently I get
> these titles from PARTS.LST, but that is not sufficient, and it is a short
> sighted implementation.
>
> I also get part length from the titles, so supporting unofficials is important.
>
> I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> getting LPub going there. I know it is unix (which I know very well), but I did
> not find make or the gcc tools (which I also know very well) using find.
>
> I'm antsy to get going there. Any ideas on where to get started?
>
> Kevin
LDView and MLCad shows a way for solving this issue.
In the MLCad.ini you can define alternate search path for parts, so you do not
have to mix official and unofficial parts.
Also LDView has the possibility to search in different directories.
cu
mikeheide
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> I did not find any "official" specification for alternate pathing of parts. I'm
> very interested in implementing the standard, or the defacto standard, if I knew
> where to find an explanation.
The LSC voted on that, and officially declined to specify an official location
for unofficial parts.
> I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> getting LPub going there. I know it is unix (which I know very well), but I did
> not find make or the gcc tools (which I also know very well) using find.
You have to install the dev tools from the OS CD (DVD?) that came with your Mac.
They aren't installed by default (which is probably a wise choice on Apple's
part).
> I'm antsy to get going there. Any ideas on where to get started?
Once you've installed the dev tools, you'll have all the command line tools you
expect. Having said that, qmake on QT for Mac actually generates an XCode
project by default instead of a makefile, and I'd recommend just going with
that. I can send you the .pro file (input for qmake) that I created from the
source tree you sent me if you want (unless I already did).
--Travis
|
|
| |
In lugnet.cad.dev, Michael Heidemann wrote:
> LDView and MLCad shows a way for solving this issue.
> In the MLCad.ini you can define alternate search path for parts, so you do not
> have to mix official and unofficial parts.
> Also LDView has the possibility to search in different directories.
Additionally, LDView is hard-coded to look in the <LDrawDir>/Unofficial/Parts
and <LDrawDir>/Unofficial/p directories when it doesn't find a part in its
search path. It then attempts to download unofficial parts from the part
tracker into that directory if it can't find the part (assuming the user hasn't
disabled this feature).
It could be argued that the user should be able to configure where unofficial
parts get downloaded to, but I'm not sure I'll ever implement that. The way it
is now basically produces a de-facto standard for anyone using LDView, and
adding a configuration option for this would defeat that.
As it happens, BrickSmith on the Mac has these directories in its search path
also (which was purely coincidental; Allen and I didn't talk about it, and
neither of us was aware of the other's use of that directory at the time we did
our implementation).
Willy has a tutorial and sample MLCad.ini file that sets up MLCad to look in
these Unofficial directories.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > I did not find any "official" specification for alternate pathing of parts. I'm
> > very interested in implementing the standard, or the defacto standard, if I knew
> > where to find an explanation.
>
> The LSC voted on that, and officially declined to specify an official location
> for unofficial parts.
>
>
> > I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> > getting LPub going there. I know it is unix (which I know very well), but I did
> > not find make or the gcc tools (which I also know very well) using find.
>
> You have to install the dev tools from the OS CD (DVD?) that came with your Mac.
> They aren't installed by default (which is probably a wise choice on Apple's
> part).
>
>
> > I'm antsy to get going there. Any ideas on where to get started?
>
> Once you've installed the dev tools, you'll have all the command line tools you
> expect. Having said that, qmake on QT for Mac actually generates an XCode
> project by default instead of a makefile, and I'd recommend just going with
> that. I can send you the .pro file (input for qmake) that I created from the
> source tree you sent me if you want (unless I already did).
>
> --Travis
Hi Travis,
Thanks for the help. I have a .pro from Orion. I have to update it, because
the list of files has changed, but that should be straight forward.
Thank you very much,
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> Thanks for the help. I have a .pro from Orion. I have to update it, because
> the list of files has changed, but that should be straight forward.
>
> Thank you very much,
You're welcome. Can you verify that you got my email messages regarding the
source tree you sent me? I never got any responses to the messages I sent you,
and I want to make sure they got through.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > Thanks for the help. I have a .pro from Orion. I have to update it, because
> > the list of files has changed, but that should be straight forward.
> >
> > Thank you very much,
>
> You're welcome. Can you verify that you got my email messages regarding the
> source tree you sent me? I never got any responses to the messages I sent you,
> and I want to make sure they got through.
>
> --Travis
Hi Travis,
I did not get any emails from you about the code tree. Would you please try
again?
Thanks,
Kevin
|
|
| |
In lugnet.cad.dev, Michael Heidemann wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > In lugnet.cad.dev, Willy Tschager wrote:
> > > In lugnet.cad.dev, Kevin L. Clague wrote:
> > >
> > > Hi Kevin,
> > >
> > > > When you say unofficials and custom folders, what are you thinking? Since it
> > > > uses ldglite, there are some rederer features I do not have control over.
> > >
> > > I was refering to the use of unofficial and custom parts and the possibilities
> > > to include them into BI without the need to store them in the <LDRAWDIR>Parts
> > > folder or include them in Parts.lst.
> > >
> > > w.
> >
> > You are more knowledgable on this topic than I am. As far as the assembly
> > images go, at least for now I'm at the mercy of LDGlite. I've made good use of
> > the superb document and specifications on LDraw.org. I want to thank all
> > involved in updating the specifications and website.
> >
> > I did not find any "official" specification for alternate pathing of parts. I'm
> > very interested in implementing the standard, or the defacto standard, if I knew
> > where to find an explanation.
> >
> > In PLI's, LPub displays the parts color name (from LDConfig), the part number
> > (yes, even on the Mac version Allan!), and the part title. Currently I get
> > these titles from PARTS.LST, but that is not sufficient, and it is a short
> > sighted implementation.
> >
> > I also get part length from the titles, so supporting unofficials is important.
> >
> > I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> > getting LPub going there. I know it is unix (which I know very well), but I did
> > not find make or the gcc tools (which I also know very well) using find.
> >
> > I'm antsy to get going there. Any ideas on where to get started?
> >
> > Kevin
>
> LDView and MLCad shows a way for solving this issue.
> In the MLCad.ini you can define alternate search path for parts, so you do not
> have to mix official and unofficial parts.
> Also LDView has the possibility to search in different directories.
>
> cu
> mikeheide
I understand and respect wisdom of the the LSC's decision to not define where to
store unofficial parts.
I was wondering if the LSC would consider defining how one defines the paths to
unofficial directories? At least that would give us some commonality to the
solution of unofficial parts.
Respectfully,
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part number
(yes, even on the Mac version Allan!), and the part title. Currently I get
these titles from PARTS.LST, but that is not sufficient, and it is a short
sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the original
LDraw distribution? You can’t rely on that being present. Not being able to rely
on a DOS utility, Bricksmith reads the part library and generates its own XML
parts list; I assume other programs do something similar.
| |
I got a Mac mini yesterday, so I’m at the bottom of the learning curve on
getting LPub going there. I know it is unix (which I know very well), but I
did not find make or the gcc tools (which I also know very well) using find.
I’m antsy to get going there. Any ideas on where to get started?
|
Congratulations! This is wonderful news for Mac LDraw users. I have fielded
numerous requests asking for an instruction-generation tool in Bricksmith, and
I’ve always been ashamed to respond that there isn’t one, never will be, and the
process of doing it manually is probably too hard for them to figure out. I
eagerly anticipate being able to direct people to a real solution. Thanks for
making the capital investment to support us!
As others have noted, in order to get the developer tools on your Mac, you need
to install the Xcode Tools package. It is found somewhere on your Mac OS
installer DVD. That installs the gcc toolchain, Apple’s graphical IDE, and lots
of other stuff.
Allen
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> As it happens, BrickSmith on the Mac has these directories in its search path
> also (which was purely coincidental; Allen and I didn't talk about it, and
> neither of us was aware of the other's use of that directory at the time we did
> our implementation).
>
> Willy has a tutorial and sample MLCad.ini file that sets up MLCad to look in
> these Unofficial directories.
Hi Kevin,
I bet you've already found what Travis's talking about; if not the tutorial can
be found here:
http://www.holly-wood.it/mlcad/ini-en.html#scan
Initially I used <LDRAWDIR>Unofficial_Parts since MLCad was the first prog
supporting unofficial parts but agreed with Travis and Allen to change it to
<LDRAWDIR>Unofficial after the LSC had voted down the proposal.
w.
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> Hi Travis,
> I did not get any emails from you about the code tree. Would you please try
> again?
Sorry to everyone else for having this on a public forum, but since Kevin
doesn't appear to be receiving my emails, I feel that I need to post this here.
I just resent all the messages I've sent you in the past month or so. I
strongly suspect that they're all going to end up in your spam box; please check
that, and do what you can (if anything on yahoo) to stop getting them tagged as
spam. If you don't get them, or you can't get my address marked as non-spam,
you're probably going to have to send me another email address I can use to send
you stuff. I could try sending from another address also, I suppose.
--Travis
|
|
| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title. Currently
I get these titles from PARTS.LST, but that is not sufficient, and it is a
short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the original
LDraw distribution? You can’t rely on that being present. Not being able to
rely on a DOS utility, Bricksmith reads the part library and generates its
own XML parts list; I assume other programs do something similar.
|
As will LPub before it is made available to the public. Thus the comment about
short sighted. Now that I have an example on what to do, I’ll implement that
instead. There is one class that will have to be changed, and no one else needs
to know the difference.
| |
| |
I got a Mac mini yesterday, so I’m at the bottom of the learning curve on
getting LPub going there. I know it is unix (which I know very well), but I
did not find make or the gcc tools (which I also know very well) using find.
I’m antsy to get going there. Any ideas on where to get started?
|
Congratulations! This is wonderful news for Mac LDraw users. I have fielded
numerous requests asking for an instruction-generation tool in Bricksmith,
and I’ve always been ashamed to respond that there isn’t one, never will be,
and the process of doing it manually is probably too hard for them to figure
out. I eagerly anticipate being able to direct people to a real solution.
Thanks for making the capital investment to support us!
|
It turns out that I get an employee discount through work, even though I don’t
work for Apple. Who could resist?
Now, if someone would make a platform independent editor, we’d be in fantastic
shape!
| |
As others have noted, in order to get the developer tools on your Mac, you
need to install the Xcode Tools package. It is found somewhere on your Mac OS
installer DVD. That installs the gcc toolchain, Apple’s graphical IDE, and
lots of other stuff.
Allen
|
I’m grateful for all the help.
I’ve gotten LPub to build successfully, and am working on interfacing to
renderers. On vidoze I used ldglite originally on LPub 4, and all was well.
Don Heyse had added some features to ldglite to make it easier for LPub to work
with, by adding some of the L3P camera lens and positioning options, and getting
it to render offscreen. Today, the Mac version of ldglite does not have these
features.
LPub 2 supports LDView, which I hadn’t gotten around to doing with LPub 4 until
last night. Travis was nice enough to make the L3P camera command line option
changes to LDView a few years back. I’ve not got LDView and LPub 4 working well
on the Mac yet, but that will be just a matter of debug time.
I’m very excited.
Kevin
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > As it happens, BrickSmith on the Mac has these directories in its search path
> > also (which was purely coincidental; Allen and I didn't talk about it, and
> > neither of us was aware of the other's use of that directory at the time we did
> > our implementation).
> >
> > Willy has a tutorial and sample MLCad.ini file that sets up MLCad to look in
> > these Unofficial directories.
>
> Hi Kevin,
>
> I bet you've already found what Travis's talking about; if not the tutorial can
> be found here:
>
> http://www.holly-wood.it/mlcad/ini-en.html#scan
>
> Initially I used <LDRAWDIR>Unofficial_Parts since MLCad was the first prog
> supporting unofficial parts but agreed with Travis and Allen to change it to
> <LDRAWDIR>Unofficial after the LSC had voted down the proposal.
>
> w.
Thanks Willy! I'll work on this very soon.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
I’ve gotten LPub to build successfully, and am working on interfacing to
renderers. On vidoze I used ldglite originally on LPub 4, and all was well.
Don Heyse had added some features to ldglite to make it easier for LPub to
work with, by adding some of the L3P camera lens and positioning options, and
getting it to render offscreen. Today, the Mac version of ldglite does not
have these features.
|
Yeah, gotta work on that... But hey, the kids just got a macbook! And, as
of yesterday, it has a sneaky ssh login just for me so I can soak up some of the
idle cycles from across the living room.
But...my notes on libpng for OS-X are about 5 years old. Is
this the current recommended way to
get it? If so, what does the code patch do? Is the patch still needed? I ran
the script without patching and was able to build an executable with the
resulting libpng, but I didn’t actually try the png functions yet, because...
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
Have fun,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
But...my notes on libpng for OS-X are about 5 years old. Is
this the current recommended way
to get it? If so, what does the code patch do? Is the patch still needed?
I ran the script without patching and was able to build an executable with
the resulting libpng, but I didn’t actually try the png functions yet,
because...
|
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if you
just run it and open its sample file.
--Travis
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview?
|
One of those.
No. They don’t distribute the full library; you would have to merge together all
the updates with the original LDraw DOS package. Not fun.
| |
and where do you folks put the LDRAWDIR on the MAC these days?
|
Wherever you want it. If Bricksmith is installed, you can find out where the
LDraw folder is by issuing the following terminal command:
defaults read com.AllenSmith.Bricksmith “LDraw Path”
On Bricksmith’s first launch, it automatically searches in /Applications,
/Library, ~/Library, and directories relative to Bricksmith.app itself
(which is where it usually finds it).
Allen
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if
you just run it and open its sample file.
|
Thanks guys for all the help. I grabbed BrickSmith and moved the ldraw
folder that came with it to /Library. I wanted both anyhow so it seemed
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
Kevin, if you want to test it I put a beta of just the executable
here.
Enjoy,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
How about I send you a universal binary of a static libpng? (If I remember
correctly, it was a real pain to make.)
| |
I haven’t fetched the LDRAW parts library yet. So what’s the best way to
get the parts for the Mac -- With bricksmith? In ldview? Straight from
ldraw.org? -- and where do you folks put the LDRAWDIR on the MAC these
days?
|
I think I got mine via BrickSmith, which is kind of sad, really, but I just
checked, and LDView will happily download the official library on the Mac if
you just run it and open its sample file.
|
Thanks guys for all the help. I grabbed BrickSmith and moved the ldraw
folder that came with it to /Library. I wanted both anyhow so it seemed
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
Kevin, if you want to test it I put a beta of just the executable
here.
Enjoy,
Don
|
Hi Don,
It worked!
Now I just have to figure out how to get my main menu and popup menus to work
on the Mac from Qt!
Thanks!
Kevin
|
|
| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title. Currently
I get these titles from PARTS.LST, but that is not sufficient, and it is a
short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the original
LDraw distribution? You can’t rely on that being present. Not being able to
rely on a DOS utility, Bricksmith reads the part library and generates its
own XML parts list; I assume other programs do something similar.
|
snip
LPub does not need a total list of parts, so it doesn’t have to scan all the
paths. It does need the titles of parts that are used however. Since parts.lst
is a precomupted list of some of them, LPub reads it and puts the contents in an
associative array.
If we need the title for a part not in the array, we check the list of paths
(which now includes Unofficial/Parts, et. al.). If found, the part file is
opened, then title extracted and thrown in the associative array.
So, Willy, LPub supports the unofficial parts path stuff, including Helpers, and
Custom Parts. Do we want to add Development/Parts Development/P?
Development/P48?
So, this leads to a few more questions......
Allen,
You know those obtuse MLCad meta’s we talked about, like rotation step, buffer
exchange, GHOST? Sounds because LPub supports these, you might want to add them
to BrickSmith.
Don,
Did you get a chance to add the unofficial path support to LDGLite?
Kevin
|
|
| |
In lugnet.cad.dev, Jim DeVona wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
>
> > I got a Mac mini yesterday, so I'm at the bottom of the learning curve on
> > getting LPub going there. I know it is unix (which I know very well), but I did
> > not find make or the gcc tools (which I also know very well) using find.
> >
> > I'm antsy to get going there. Any ideas on where to get started?
>
> I think those and other development tools are available as an optional install
> from your system DVD, if they're not already present on the machine.
>
> Jim
So, popup menus work, but my main menu does not show up.
I found this information on trolltech:
http://doc.trolltech.com/3.3/mac-differences.html
but I don't know what it means to run out of a bundle.
Qmake created
lpub.app
Contents
Info.plist
MacOS
PkgInfo
Info.plist contains
<?xml version "1.0" "file://localhost/System/Library/DTDs/Property/List.dtd>
<plist version="0.9">
<dict>
<key>CFBundleIconFile</key>
<string></string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleGetInfoString</key>
<string>Created by Qt/QMake></string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleExecutable</key>
<string>lpub</string>
<key>NOTE</key>
<string>Please, do NOT change this file -- It was generated buy
Qt/Qmake.</string>
</dict>
</plist>
PkgInfo contains
APPL????
It would seem these files are related to the issue, but I've got no idea how to
change them to use widgets.app as indicated by trolltech.
Any ideas?
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In lugnet.cad.dev, Allen Smith wrote:
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
| |
In PLI’s, LPub displays the parts color name (from LDConfig), the part
number (yes, even on the Mac version Allan!), and the part title.
Currently I get these titles from PARTS.LST, but that is not sufficient,
and it is a short sighted implementation.
|
Is PARTS.LST the file that gets generated by some DOS utility in the
original LDraw distribution? You can’t rely on that being present. Not
being able to rely on a DOS utility, Bricksmith reads the part library
and generates its own XML parts list; I assume other programs do
something similar.
|
LPub does not need a total list of parts, so it doesn’t have to scan all the
paths. It does need the titles of parts that are used however. Since
parts.lst is a precomupted list of some of them, LPub reads it and puts the
contents in an associative array.
|
I believe a MAC version mklist utility used to generate the PARTS.LST
file comes bundled with the OS-X version of ldglite. Source code is
available, so anyone can build it on whatever platform they like.
There may be better ways to build the list, but PARTS.LST should always
be available as the least common denominator.
| |
Don,
Did you get a chance to add the unofficial path support to LDGLite?
|
Not yet, but soon...
Don
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> So, popup menus work, but my main menu does not show up.
OK, that's very very strange. LDView's main menu "just worked" (mostly). I had
to do some fixups to make it fit the Mac style, but it was perfectly usable
without those. It "just works" when compiled with QT 4 also.
> I found this information on trolltech:
>
> http://doc.trolltech.com/3.3/mac-differences.html
It's not talking about the menu you think it's talking about. The "Application
Menu" on a Mac isn't the application's menu, it's the first item in the
application's menu, with a title that matches the application name. The
"Bundle" they're referring to is just the app wrapper (the LPub.app dir).
--Travis
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> So, popup menus work, but my main menu does not show up.
Just out of curiosity, what IS in the menu bar when the LPub window is the
current active window?
--Travis
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> So, popup menus work, but my main menu does not show up.
>
> I found this information on trolltech:
>
> http://doc.trolltech.com/3.3/mac-differences.html
>
> but I don't know what it means to run out of a bundle.
>
> Qmake created
>
> lpub.app
> Contents
> Info.plist
> MacOS
> PkgInfo
>
> Info.plist contains
>
> <?xml version "1.0" "file://localhost/System/Library/DTDs/Property/List.dtd>
> <plist version="0.9">
> <dict>
> <key>CFBundleIconFile</key>
> <string></string>
> <key>CFBundlePackageType</key>
> <string>APPL</string>
> <key>CFBundleGetInfoString</key>
> <string>Created by Qt/QMake></string>
> <key>CFBundleSignature</key>
> <string>????</string>
> <key>CFBundleExecutable</key>
> <string>lpub</string>
> <key>NOTE</key>
> <string>Please, do NOT change this file -- It was generated buy
> Qt/Qmake.</string>
> </dict>
> </plist>
>
> PkgInfo contains
>
> APPL????
>
> It would seem these files are related to the issue, but I've got no idea how to
> change them to use widgets.app as indicated by trolltech.
I'm not too familiar with Qt or Trolltech's recommendations, so maybe someone
else can help work out what you need to do. The Mac version of LDView 3.2 is a
Qt app, so maybe Travis can get you started.
The application bundle structure applies to most apps, though, so if you're not
familiar with that yet, take a look at some other applications to see how it
works. Right-click an application and select "Show Package Contents" - you'll
see the same sort of directory structure. Contents/Info.plist provides all sorts
of meta-data about the program
(http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html),
Contents/MacOS typically contains the actual executable, and Contents/Resources
holds pretty much anything else - icons, help, etc. (Although Qmake presumably
sets all this up for you.)
The CFBundleExecutable property in Info.plist identifies the executable in
Contents/MacOS that runs when you launch the application.
Jim
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > So, popup menus work, but my main menu does not show up.
>
> Just out of curiosity, what IS in the menu bar when the LPub window is the
> current active window?
>
> --Travis
All I get is a single menu item in the menu bar above the desktop. It says
LPub. The contents of the menu are not from LPub though.
I've built LPub using QMainWindow. It has a function that returns a pointer to
the menuBar(). I build all my main menus using that.
Maybe you're doing things differently?
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> All I get is a single menu item in the menu bar above the desktop. It says
> LPub. The contents of the menu are not from LPub though.
>
> I've built LPub using QMainWindow. It has a function that returns a pointer to
> the menuBar(). I build all my main menus using that.
>
> Maybe you're doing things differently?
LDView has its main menu inside the .ui file for the main window. It was
created and is maintained in QT Designer. Take a look at LDView.ui to see if
there's anything obviously different there.
--Travis
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> So, Willy, LPub supports the unofficial parts path stuff, including Helpers,
> and Custom Parts. Do we want to add Development/Parts Development/P?
> Development/P48?
Perfect - many thx! Don't think there is any need for "development" but
"<LDRAWDIR>LSynth" wouldn't hurt. You could then store all constraints and
synthesis parts in that folder without the need to mix them with the official
parts or rebuild Parts.lst, while I, as maintainer of the MLCad.ini, could
include a search path and scan for LSynth by default.
w.
|
|
| |
In lugnet.cad.dev, Willy Tschager wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > So, Willy, LPub supports the unofficial parts path stuff, including Helpers,
> > and Custom Parts. Do we want to add Development/Parts Development/P?
> > Development/P48?
>
> Perfect - many thx! Don't think there is any need for "development" but
> "<LDRAWDIR>LSynth" wouldn't hurt. You could then store all constraints and
> synthesis parts in that folder without the need to mix them with the official
> parts or rebuild Parts.lst, while I, as maintainer of the MLCad.ini, could
> include a search path and scan for LSynth by default.
>
> w.
I figured that Development would be use by parts authors. I was offering it as
an alternative to D:work_in_progress. LSynth it is.
Kev
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Kevin L. Clague wrote:
> > All I get is a single menu item in the menu bar above the desktop. It says
> > LPub. The contents of the menu are not from LPub though.
> >
> > I've built LPub using QMainWindow. It has a function that returns a pointer to
> > the menuBar(). I build all my main menus using that.
> >
> > Maybe you're doing things differently?
>
> LDView has its main menu inside the .ui file for the main window. It was
> created and is maintained in QT Designer. Take a look at LDView.ui to see if
> there's anything obviously different there.
>
> --Travis
Hmmm..... one major difference is that I didn't use the designer for any of my
GUI.
I wonder if that is why things are different.
Kevin
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> Hmmm..... one major difference is that I didn't use the designer for any of my
> GUI.
>
> I wonder if that is why things are different.
I'm guessing it's related, but there's presumably something you did that QT
Designer doesn't do, or vice versa. Obviously QT is designed so that apps can
be written completely without using QT Designer.
One thing you might do is create a QMainWindow subclass in QT Designer, add menu
items to that, then set that as the superclass of your current main window
class. See if the Desinger-designed menu shows up.
To be honest, I would think it would be a lot easier to maintain your main menu
using Designer. If the above test menu shows up, you might consider just doing
that and getting rid of your source-code based menu/action building.
--Travis
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Kevin L. Clague wrote:
> > > All I get is a single menu item in the menu bar above the desktop. It says
> > > LPub. The contents of the menu are not from LPub though.
> > >
> > > I've built LPub using QMainWindow. It has a function that returns a pointer to
> > > the menuBar(). I build all my main menus using that.
> > >
> > > Maybe you're doing things differently?
> >
> > LDView has its main menu inside the .ui file for the main window. It was
> > created and is maintained in QT Designer. Take a look at LDView.ui to see if
> > there's anything obviously different there.
> >
> > --Travis
>
> Hmmm..... one major difference is that I didn't use the designer for any of my
> GUI.
>
> I wonder if that is why things are different.
>
> Kevin
problem fixed.
extern void qt_mac_set_native_menubar(bool);
qt_mac_set_native_menubar(true);
Kevin
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
to be the way to go. Then I built a new (universal?) ldglite with your
static libpng and some patches to render offscreen via the carbon fns. It
didn’t work from an ssh login (carbon is forbidden), but when I logged
locally I got a png file without opening a graphics window. Cool!
|
If you used my code as an example for Core GL setup, then the error was due to a
bug in my code. If not, put the following in your CGLPixelFormatAttribute
array, and it should work even via ssh:
CGLPixelFormatAttribute attrs[] =
{
kCGLPFADepthSize, (CGLPixelFormatAttribute)24,
kCGLPFAColorSize, (CGLPixelFormatAttribute)24,
kCGLPFAAlphaSize, (CGLPixelFormatAttribute)8,
kCGLPFAStencilSize, (CGLPixelFormatAttribute)8,
kCGLPFAAccelerated,
kCGLPFAPBuffer,
kCGLPFARemotePBuffer,
(CGLPixelFormatAttribute)0
};
The last setting (kCGLPFARemotePBuffer) is the important one for remote
rendering. Note, thought, that you don’t want that setting set when saving a
file from the UI. I suspect that you can skip the kCGLPFAAccelerated entry.
I updated LDView, and it now works fine remotely via ssh from an account
different than the logged in user (and probably when nobody is logged in; I
can’t test that right now).
--Travis
|
|
| |
In lugnet.cad.dev, Kevin L. Clague wrote:
> problem fixed.
>
> extern void qt_mac_set_native_menubar(bool);
> qt_mac_set_native_menubar(true);
>
> Kevin
OK, now that's just plain weird. Glad to hear it's fixed, though.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > to be the way to go. Then I built a new (universal?) ldglite with your
> > static libpng and some patches to render offscreen via the carbon fns. It
> > didn't work from an ssh login (carbon is forbidden), but when I logged
> > locally I got a png file without opening a graphics window. Cool!
>
> If you used my code as an example for Core GL setup, then the error was due
> to a bug in my code. If not, put the following in your
> CGLPixelFormatAttribute array, and it should work even via ssh:
>
> | CGLPixelFormatAttribute attrs[] =
> | {
> | kCGLPFADepthSize, (CGLPixelFormatAttribute)24,
> | kCGLPFAColorSize, (CGLPixelFormatAttribute)24,
> | kCGLPFAAlphaSize, (CGLPixelFormatAttribute)8,
> | kCGLPFAStencilSize, (CGLPixelFormatAttribute)8,
> | kCGLPFAAccelerated,
> | kCGLPFAPBuffer,
> | kCGLPFARemotePBuffer,
> | (CGLPixelFormatAttribute)0
> | };
>
> The last setting (kCGLPFARemotePBuffer) is the important one for remote
> rendering. Note, thought, that you don't want that setting set when
> saving a file from the UI. I suspect that you can skip the
> kCGLPFAAccelerated entry.
>
> I updated LDView, and it now works fine remotely via ssh from an account
> different than the logged in user (and probably when nobody is logged in; I
> can't test that right now).
Actually it turned out that despite the warning message my settings
did work from a remote ssh login as a different user. The old AGL code,
while it worked locally (that was a surprise), did not work remotely and
produced the same warning message:
_RegisterApplication(), FAILED TO establish the default connection to the
WindowServer, _CGSDefaultConnection() is NULL.
When I searched for that I found some dev notes for daemon developnemt
that said carbon and opengl calls were not allowed for this sort of thing.
Since it warned me but still worked I wonder if this was more of a
problem with older versions of OS-X.
I took a peek at your code, but pbuffers make me nervous. I sorta
remember a Dev Connection table that showed them as unsupported on
some of the older Macs. (Like before 10.3)
So I skipped the pbuffer and went straight to ordinary offscreen
memory for the absolute lowest performance. ;-) I only use the stencil
buffer for editing mode, and I forgot to ask for alpha, but got it
anyhow with this setup:
CGLPixelFormatAttribute attribs[] = {
kCGLPFAOffScreen,
kCGLPFAColorSize, 32,
kCGLPFADepthSize, 32,
0};
Have fun,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Kevin, if you want to test it I put a beta of just the executable
here.
|
Apparently this is working for others, but when I run it (on an original MacBook
in OS 10.4), all I get is a bus error. Did you compile it as a Leopard app?
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Kevin, if you want to test it I put a beta of just the executable
here.
|
Apparently this is working for others, but when I run it (on an original
MacBook in OS 10.4), all I get is a bus error. Did you compile it as a
Leopard app?
|
Err, I rushed it and sorta botched the build. So a few files got built
with no PPC code. I rebuilt it, but didn’t get a chance to borrow an
older machine to test it on yet.
Hey, maybe (probably) you know this. What’s involved in supporting
a G3, or say OS 10.3? I don’t know my way around the compiler switches
well enough yet to turn off altivec or use the older libraries.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Err, I rushed it and sorta botched the build. So a few files got built
with no PPC code. I rebuilt it, but didn’t get a chance to borrow an
older machine to test it on yet.
|
Actually, I don’t have a PPC Mac, just the previous OS version. I believe that
if you don’t get everything right for the “universal” stuff, it will give you an
error at link time. I know that’s what it does to me if any of the libraries
aren’t universal and I try to do a universal build.
| |
Hey, maybe (probably) you know this. What’s involved in supporting
a G3, or say OS 10.3? I don’t know my way around the compiler switches
well enough yet to turn off altivec or use the older libraries.
|
No idea. I know how to set up the OS setting in XCode, but I don’t know
off-hand even how to do that in a Makefile.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Err, I rushed it and sorta botched the build. So a few files got built
with no PPC code. I rebuilt it, but didn’t get a chance to borrow an
older machine to test it on yet.
|
Actually, I don’t have a PPC Mac, just the previous OS version.
|
That’s interesting. I built it on a new laptop with the version of XCode
that comes with leopard. However I just added the arch targets to the
old makefile (but missed one of the libraries). So I guess the default
is to target leopard only. I suppose I should try to build from an
XCode project and see if it’s easier to target older OS versions and
CPUs with that.
| |
I believe
that if you don’t get everything right for the “universal” stuff, it will
give you an error at link time. I know that’s what it does to me if any of
the libraries aren’t universal and I try to do a universal build.
|
It let me link in an X86 only lib without an error. Maybe there was a
warning, I didn’t pay too much attention. I can imagine reasons why
you *might* want a special lib that’s only called from the X86 code.
| |
| |
Hey, maybe (probably) you know this. What’s involved in supporting
a G3, or say OS 10.3? I don’t know my way around the compiler switches
well enough yet to turn off altivec or use the older libraries.
|
No idea. I know how to set up the OS setting in XCode, but I don’t know
off-hand even how to do that in a Makefile.
|
I found some documentation, but I printed it and don’t have it on hand
right now. It sure looks easier to do from the XCode gui though.
So what’s the oldest, junkiest Mac that’s known to run the LDView executable?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
So what’s the oldest, junkiest Mac that’s known to run the LDView executable?
|
No idea. Whatever it is, it needs Tiger, though, since LDView is built to
require Tiger. It presumably needs a G4.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
So what’s the oldest, junkiest Mac that’s known to run the LDView
executable?
|
No idea. Whatever it is, it needs Tiger, though, since LDView is built to
require Tiger. It presumably needs a G4.
|
For what it’s worth, Tiger will run on a 300 MHz G3. While it certainly wasn’t
fast, I don’t recall ever encountering any software that simply said “I need a
G4”. That’s not to say there’s no reason why such software couldn’t or shouldn’t
exist, of course.
Jim
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Err, I rushed it and sorta botched the build. So a few files got built
with no PPC code. I rebuilt it, but didn’t get a chance to borrow an
older machine to test it on yet.
|
Actually, I don’t have a PPC Mac, just the previous OS version.
|
That’s interesting. I built it on a new laptop with the version of XCode
that comes with leopard. However I just added the arch targets to the
old makefile (but missed one of the libraries). So I guess the default
is to target leopard only. I suppose I should try to build from an
XCode project and see if it’s easier to target older OS versions and
CPUs with that.
| |
I believe
that if you don’t get everything right for the “universal” stuff, it will
give you an error at link time. I know that’s what it does to me if any of
the libraries aren’t universal and I try to do a universal build.
|
It let me link in an X86 only lib without an error. Maybe there was a
warning, I didn’t pay too much attention. I can imagine reasons why
you *might* want a special lib that’s only called from the X86 code.
| |
| |
Hey, maybe (probably) you know this. What’s involved in supporting
a G3, or say OS 10.3? I don’t know my way around the compiler switches
well enough yet to turn off altivec or use the older libraries.
|
No idea. I know how to set up the OS setting in XCode, but I don’t know
off-hand even how to do that in a Makefile.
|
I found some documentation, but I printed it and don’t have it on hand
right now. It sure looks easier to do from the XCode gui though.
|
Since I already lost this once, I’m gonna stash it here just in case.
To compile something that runs on Tiger from a makefile on Leopard add
this:
CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk
That should make it build and run with the older Tiger sdk and libs.
Add -arch i386 -arch ppc and I should be able to make a universal
binary for 10.4 and up. (I hope)
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Since I already lost this once, I’m gonna stash it here just in case.
To compile something that runs on Tiger from a makefile on Leopard add
this:
|
Good idea.
| |
CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk
That should make it build and run with the older Tiger sdk and libs.
Add -arch i386 -arch ppc and I should be able to make a universal
binary for 10.4 and up. (I hope)
|
I’ll be happy to be your Tiger test subject, but I can only test Intel.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
Since I already lost this once, I’m gonna stash it here just in case.
To compile something that runs on Tiger from a makefile on Leopard add
this:
|
Good idea.
| |
CFLAGS+= -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
LDFLAGS+= -isysroot /Developer/SDKs/MacOSX10.4u.sdk
That should make it build and run with the older Tiger sdk and libs.
Add -arch i386 -arch ppc and I should be able to make a universal
binary for 10.4 and up. (I hope)
|
I’ll be happy to be your Tiger test subject, but I can only test Intel.
|
Ok, give this one a try.
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
That one works for LPub. The buffer isn’t getting flushed to the screen right.
I have to resize or force a redraw in order. Are you calling CGLFlushDrawable
at the end of your drawing code?
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Ok, give http://ldglite.sf.net/ldgliteosx1_2_1beta2.zip a try.
>
> That one works for LPub. The buffer isn't getting flushed to the screen
> right. I have to resize or force a redraw in order. Are you calling
> CGLFlushDrawable at the end of your drawing code?
No, I use glfinish(). I've had all sorts of problems over the years
with Apple because I often render in the front buffer to emulate
the various ancient ldlite immediate rendering modes. Does it update
ok when you spin the model with the mouse? I think that's pure back
buffer rendering (at least until you're done spinning). What about using
-n4 on the command line? That's the ldlite command to render the whole
thing before displaying it. It looks like I forced that mode when the gl
render string contains "RADEON 7000", so I must have had problems with
that one too. Really, at this point I should probably give up rendering
in the front buffer except perhaps for editing mode and maybe for the
slow software renderers.
What does ldglite print for GL_VENDOR and GL_RENDERER?
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > In lugnet.cad.dev, Don Heyse wrote:
> > > Ok, give http://ldglite.sf.net/ldgliteosx1_2_1beta2.zip a try.
> >
> > That one works for LPub. The buffer isn't getting flushed to the screen
> > right. I have to resize or force a redraw in order. Are you calling
> > CGLFlushDrawable at the end of your drawing code?
>
> No, I use glfinish(). I've had all sorts of problems over the years
> with Apple because I often render in the front buffer to emulate
> the various ancient ldlite immediate rendering modes. Does it update
> ok when you spin the model with the mouse? I think that's pure back
> buffer rendering (at least until you're done spinning). What about using
> -n4 on the command line? That's the ldlite command to render the whole
> thing before displaying it. It looks like I forced that mode when the gl
> render string contains "RADEON 7000", so I must have had problems with
> that one too. Really, at this point I should probably give up rendering
> in the front buffer except perhaps for editing mode and maybe for the
> slow software renderers.
>
> What does ldglite print for GL_VENDOR and GL_RENDERER?
Sorry about the self reply, but now I'm really curious about this.
I found myself an old G4 EMac with a Geforce2 and OSX Tiger for testing
and everything worked ok. It also worked on an Intel Macbook with
the Intel GMA X3100 graphics. So I guess that means I've got the
universal binary build process down.
Now I just need to fix the display bugs on some systems. I'm guessing
they use ATI chips, but it'd be nice to know for sure. It'd also be nice
to know if the -n4 arg makes it better, because if so I'll make that the default
moving forward.
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Sorry about the self reply, but now I'm really curious about this.
> I found myself an old G4 EMac with a Geforce2 and OSX Tiger for testing
> and everything worked ok. It also worked on an Intel Macbook with
> the Intel GMA X3100 graphics. So I guess that means I've got the
> universal binary build process down.
Sorry for not responding, but I didn't remember to look at it while I was at
home. I'll try to do so tonight.
> Now I just need to fix the display bugs on some systems. I'm guessing
> they use ATI chips, but it'd be nice to know for sure. It'd also be nice
> to know if the -n4 arg makes it better, because if so I'll make that the default
> moving forward.
Actually, my Intel MacBook (one of the original ones) has Intel motherboard
graphics. Probably a different model than yours, but Intel nonetheless.
--Travis
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Sorry about the self reply, but now I'm really curious about this.
> I found myself an old G4 EMac with a Geforce2 and OSX Tiger for testing
> and everything worked ok. It also worked on an Intel Macbook with
> the Intel GMA X3100 graphics. So I guess that means I've got the
> universal binary build process down.
Here's my info:
Vendor: Intel Inc.
Renderer: Intel GMA 950 OpenGL Engine
Version: 1.2 APPLE-1.4.56
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Sorry about the self reply, but now I'm really curious about this.
> > I found myself an old G4 EMac with a Geforce2 and OSX Tiger for testing
> > and everything worked ok. It also worked on an Intel Macbook with
> > the Intel GMA X3100 graphics. So I guess that means I've got the
> > universal binary build process down.
>
> Here's my info:
>
> Vendor: Intel Inc.
> Renderer: Intel GMA 950 OpenGL Engine
> Version: 1.2 APPLE-1.4.56
Hmmm, I guess that's slightly different from the GMA X3100, which
seemed to work for me. If you get a chance, try and run it with
-n4 on the command line. That should render everything in the back
buffer like 99.99% of the opengl programs out there.
Thanks again,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Hmmm, I guess that's slightly different from the GMA X3100, which
> seemed to work for me. If you get a chance, try and run it with
> -n4 on the command line. That should render everything in the back
> buffer like 99.99% of the opengl programs out there.
The -n4 didn't have any noticeable effect. What exactly does n4 mean. I know
it means "draw to back buffer", but what does the n and the 4 mean?
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Hmmm, I guess that's slightly different from the GMA X3100, which
> > seemed to work for me. If you get a chance, try and run it with
> > -n4 on the command line. That should render everything in the back
> > buffer like 99.99% of the opengl programs out there.
>
> The -n4 didn't have any noticeable effect.
Arrgh, that's not good. It worked for me whenever I had a problem
like that. I guess I'll have to use the OSX flush function. Are
you by chance using partially transparent windows, or something
fancy like that?
> What exactly does n4 mean. I know it means "draw to back buffer",
> but what does the n and the 4 mean?
It's hooked to an ldlite variable that tracks what level is
being rendered (P=1, Part=2, Model=4, Other=8). Don't ask me what
other means. I think this was documented with the 2.4 release notes
for ldlite, but I lost track of that. I posted the ldlite 2.3
release notes as the ldlite sourceforge web page at some point, but
that doesn't mention it. So I suppose it's possible that I made the
whole thing up myself 6 years ago, but my memory from that time is
gone now.
Have fun,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> In lugnet.cad.dev, Travis Cobbs wrote:
> > The -n4 didn't have any noticeable effect.
>
> Arrgh, that's not good. It worked for me whenever I had a problem
> like that. I guess I'll have to use the OSX flush function. Are
> you by chance using partially transparent windows, or something
> fancy like that?
Nope. It starts out partially under my dock, which I keep on the left. I can't
remember if I ever moved it completely out from under the dock or not, but I'm
pretty sure I did. (As a note, I looked around, and it appears that
HIWindowGetAvailablePositioningBounds is the Carbon API to use to avoid
overlapping the Dock; GLUT REALLY should use that automatically when you ask it
for a maximized window.)
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > In lugnet.cad.dev, Travis Cobbs wrote:
> > > The -n4 didn't have any noticeable effect.
> >
> > Arrgh, that's not good. It worked for me whenever I had a problem
> > like that. I guess I'll have to use the OSX flush function. Are
> > you by chance using partially transparent windows, or something
> > fancy like that?
>
> Nope. It starts out partially under my dock, which I keep on the left.
> I can't remember if I ever moved it completely out from under the dock
> or not, but I'm pretty sure I did. (As a note, I looked around, and it
> appears that HIWindowGetAvailablePositioningBounds is the Carbon API
> to use to avoid overlapping the Dock; GLUT REALLY should use that
> automatically when you ask it for a maximized window.)
Hmmm, a partially obscured window. Sounds like a clue. I'll have to
run some tests with a side mounted dock on the G4. And I should probably
look back and see what I did on windows when the annoying popup tooltips
were driving me nuts.
Thanks,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Hmmm, a partially obscured window. Sounds like a clue. I'll have to
> run some tests with a side mounted dock on the G4. And I should probably
> look back and see what I did on windows when the annoying popup tooltips
> were driving me nuts.
Well, I pulled the window out from under the dock, and that didn't help. On an
unrelated note, why will it only open models in the current directory? If I
give the full path to a model in a different directory, it fails to load it.
--Travis
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Hmmm, a partially obscured window. Sounds like a clue. I'll have to
> > run some tests with a side mounted dock on the G4. And I should probably
> > look back and see what I did on windows when the annoying popup tooltips
> > were driving me nuts.
>
> Well, I pulled the window out from under the dock, and that didn't help.
Yeah, but the hint helped me. With the side mounted dock I was able
to reproduce the problem (or a problem at least) on the G4. I cleaned up
some of the buffer swapping and window reshaping code, and it seems
to work better for me now. Of course I seem to be moving further and
further away from glut with every fix. Oh well. If you want, you could
try out this one and see if it's better on your system.
http://ldglite.sf.net/ldgliteosx1_2_3beta5.zip
> On an unrelated note, why will it only open models in the current
> directory? If I give the full path to a model in a different directory,
> it fails to load it.
I've started looking into that. It does the same thing on linux, I think.
I suspect I broke that a while ago when I added some code on Windows to
find the path to the executable in order to run lddesignpad plugins.
It's been a long time since I did much testing on anything but windows.
Have fun,
Don
|
|
| |
In lugnet.cad.dev, Don Heyse wrote:
> Yeah, but the hint helped me. With the side mounted dock I was able
> to reproduce the problem (or a problem at least) on the G4. I cleaned up
> some of the buffer swapping and window reshaping code, and it seems
> to work better for me now. Of course I seem to be moving further and
> further away from glut with every fix. Oh well. If you want, you could
> try out this one and see if it's better on your system.
>
> http://ldglite.sf.net/ldgliteosx1_2_3beta5.zip
Yep, that fixed it.
--Travis
|
|
|
