Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 13-Nov-2008, Ben Abbott wrote:

| This changeset adds the properties "screensize" and  
| "screenpixelsperinch" to the root object.
|
| To set the property values local to my machine I've added the lines  
| below to my ~/.octaverc
|
| set (0, "screensize", [1 1 1440 900])
| set (0, "screenpixelsperinch", 74.951])
|
| Those value correspond to my Mac PowerBook. The defaults should  
| probably be;
|
| set (0, "screensize", [1 1 1024 768])
| set (0, "screenpixelsperinch", 72])

I checked in the two patches

  http://hg.savannah.gnu.org/hgweb/octave/rev/66165de2cc42
  http://hg.savannah.gnu.org/hgweb/octave/rev/5cc594679cdc

so that Octave will now get values for these properties from the
system if it is using X11.  But I don't know how to do the same for
Windows or OS X (without X11).  So it would be helpful if someone who
does know could submit a changeset to add the appropriate code in the
new display_info::init function.

On my system, X11 returns slightly different values for the X
and Y dimensions in millimeters, so the computed pixels per inch in
each direction is different.  I average the two to come up with a
single value (94.514 on my system).  But I'm not sure that this is the
correct thing.  Comments?

I also added the screendepth property.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Shai Ayal-2
On Thu, Jan 22, 2009 at 4:56 AM, John W. Eaton <[hidden email]> wrote:
> On my system, X11 returns slightly different values for the X
> and Y dimensions in millimeters, so the computed pixels per inch in
> each direction is different.  I average the two to come up with a
> single value (94.514 on my system).  But I'm not sure that this is the
> correct thing.  Comments?

I thought this was a backend related task not really belonging in
"core" octave. However I understand gnuplot does not give this info.

the fltk backend (quite stagnant at the moment) updates screensize
only since fltk only reports the width and height of the screen in
pixels, not in any other units, so I suppose we will have to use code
like you propose in it as well.

Shai
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Shai Ayal wrote:

| On Thu, Jan 22, 2009 at 4:56 AM, John W. Eaton <[hidden email]> wrote:
| > On my system, X11 returns slightly different values for the X
| > and Y dimensions in millimeters, so the computed pixels per inch in
| > each direction is different.  I average the two to come up with a
| > single value (94.514 on my system).  But I'm not sure that this is the
| > correct thing.  Comments?
|
| I thought this was a backend related task not really belonging in
| "core" octave. However I understand gnuplot does not give this info.
|
| the fltk backend (quite stagnant at the moment) updates screensize
| only since fltk only reports the width and height of the screen in
| pixels, not in any other units, so I suppose we will have to use code
| like you propose in it as well.

Things like

  octave:1> get (0, 'screensize')
  ans =

        1      1   1600   1200

  octave:2> set (0, 'units', 'inches')
  octave:3> get (0, 'screensize')
  ans =

      0.00000    0.00000   16.92877   12.69658

will work without creating a figure.  So it might as well be something
that is part of the core.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Shai Ayal-2
On Thu, Jan 22, 2009 at 6:47 AM, John W. Eaton <[hidden email]> wrote:

> Things like
>
>  octave:1> get (0, 'screensize')
>  ans =
>
>        1      1   1600   1200
>
>  octave:2> set (0, 'units', 'inches')
>  octave:3> get (0, 'screensize')
>  ans =
>
>      0.00000    0.00000   16.92877   12.69658
>
> will work without creating a figure.  So it might as well be something
> that is part of the core.
>
> jwe
>

OK. But I don't know how hard it will be to make this cross platform.
We might try to "steal" some code from fltk to discover the platform.
I have never tried this before so I'm not sure how simple it is.
I think we already have some platform discovery code in configure and
other places (I recall Michael added some for windows) so maybe we do
have some foundation to build upon.
Anyway, I do not have access to a windows and/or OSX  development
environment so I cannot help here

Shai
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Shai Ayal wrote:

| OK. But I don't know how hard it will be to make this cross platform.
| We might try to "steal" some code from fltk to discover the
| platform.

Why?  This seems to be a compile-time thing.  We can discover if the
build system has X11, or is Windows, or is OS X, and then we just need
to know how to get the screen characteristics on those systems.  I
provided the example code for X11.  Now someone else needs to do the
same for Windows and OS X.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton

On Wednesday, January 21, 2009, at 09:56PM, "John W. Eaton" <[hidden email]> wrote:

>On 13-Nov-2008, Ben Abbott wrote:
>
>| This changeset adds the properties "screensize" and  
>| "screenpixelsperinch" to the root object.
>|
>| To set the property values local to my machine I've added the lines  
>| below to my ~/.octaverc
>|
>| set (0, "screensize", [1 1 1440 900])
>| set (0, "screenpixelsperinch", 74.951])
>|
>| Those value correspond to my Mac PowerBook. The defaults should  
>| probably be;
>|
>| set (0, "screensize", [1 1 1024 768])
>| set (0, "screenpixelsperinch", 72])
>
>I checked in the two patches
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/66165de2cc42
>  http://hg.savannah.gnu.org/hgweb/octave/rev/5cc594679cdc
>
>so that Octave will now get values for these properties from the
>system if it is using X11.  But I don't know how to do the same for
>Windows or OS X (without X11).  So it would be helpful if someone who
>does know could submit a changeset to add the appropriate code in the
>new display_info::init function.

On Mac OSX there is a compressed XML file ...

        /Library/Preferences/com.apple.windowserver.plist

... which contains the screen width/height/depth (supports several displays as well). It does not contain dpi info though.

In any event, would it be acceptable to parse the info via a system call? For example, ...

$ /usr/libexec/PlistBuddy -c "Print :DisplaySets:0:0:Depth" /Library/Preferences/com.apple.windowserver.plist
4

$ /usr/libexec/PlistBuddy -c "Print :DisplaySets:0:0:Width" /Library/Preferences/com.apple.windowserver.plist
1280

$ /usr/libexec/PlistBuddy -c "Print :DisplaySets:0:0:Height" /Library/Preferences/com.apple.windowserver.plist
1024

Better yet, if octave is able to parse compressed XML files, the information can be read directly.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Michael Goffioul
In reply to this post by John W. Eaton
On Thu, Jan 22, 2009 at 2:13 PM, John W. Eaton <[hidden email]> wrote:

> On 22-Jan-2009, Shai Ayal wrote:
>
> | OK. But I don't know how hard it will be to make this cross platform.
> | We might try to "steal" some code from fltk to discover the
> | platform.
>
> Why?  This seems to be a compile-time thing.  We can discover if the
> build system has X11, or is Windows, or is OS X, and then we just need
> to know how to get the screen characteristics on those systems.  I
> provided the example code for X11.  Now someone else needs to do the
> same for Windows and OS X.

Under Windows, it would be done using GetSystemMetrics and
GetDeviceCaps functions.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Michael Goffioul wrote:

| On Thu, Jan 22, 2009 at 2:13 PM, John W. Eaton <[hidden email]> wrote:
| > On 22-Jan-2009, Shai Ayal wrote:
| >
| > | OK. But I don't know how hard it will be to make this cross platform.
| > | We might try to "steal" some code from fltk to discover the
| > | platform.
| >
| > Why?  This seems to be a compile-time thing.  We can discover if the
| > build system has X11, or is Windows, or is OS X, and then we just need
| > to know how to get the screen characteristics on those systems.  I
| > provided the example code for X11.  Now someone else needs to do the
| > same for Windows and OS X.
|
| Under Windows, it would be done using GetSystemMetrics and
| GetDeviceCaps functions.

Does the following program do the right thing?

Thanks,

jwe


#include <iostream>

#include <Windows.h>

int
main (void)
{
  HDC hdc = GetDC (0);

  if (hdc)
    {
      int ht = GetDeviceCaps (hdc, VERTRES);
      int wd = GetDeviceCaps (hdc, HORZRES);

      std::cerr << wd << "x" << ht << " pixels" << std::endl;

      double ht_mm = GetDeviceCaps (hdc, VERTSIZE);
      double wd_mm = GetDeviceCaps (hdc, HORZSIZE);

      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;

      double resy = wd * 25.4 / wd_mm;
      double resx = ht * 25.4 / ht_mm;

      std::cerr << resx << " resx" << std::endl;
      std::cerr << resy << " resx" << std::endl;

      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;

      int depth = GetDeviceCaps (hdc, BITSPIXEL)

      std::cerr << depth << " bit depth" << std::endl;
    }
  else
    std::cerr << "failed to get device context" << std::endl;

  return 0;
}
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
In reply to this post by bpabbott
On 22-Jan-2009, Ben Abbott wrote:

| Better yet, if octave is able to parse compressed XML files, the information can be read directly.

I'd rather call a few simple functions from C++ like on other
systems.  Does the following work?

jwe


#include <iostream>

#include <CGDirectDisplay.h>
#include <CGDisplayConfiguration.h>

int
main (void)
{
  CGDirectDisplayID display = CGMainDisplayID ();

  if (display)
    {

      size_t ht = CGDisplayPixelsHigh (display);
      size_t wd = CGDisplayPixelsWide (display);

      std::cerr << wd << "x" << ht << " pixels" << std::endl;

      CGSize sz_mm = CGDisplayScreenSize (display);

      CGFloat ht_mm = sz_mm.height;
      CGFloat wd_mm = sz_mm.width;

      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;

      double resy = wd * 25.4 / wd_mm;
      double resx = ht * 25.4 / ht_mm;

      std::cerr << resx << " resx" << std::endl;
      std::cerr << resy << " resx" << std::endl;

      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;

      size_t depth = CGDisplayBitsPerPixel (display);

      std::cerr << depth << " bit depth" << std::endl;
    }
  else
    std::cerr << "failed to find display" << std::endl;

  return 0;
}
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
On Thursday, January 22, 2009, at 10:36AM, "John W. Eaton" <[hidden email]> wrote:

>On 22-Jan-2009, Ben Abbott wrote:
>
>| Better yet, if octave is able to parse compressed XML files, the information can be read directly.
>
>I'd rather call a few simple functions from C++ like on other
>systems.  Does the following work?
>
>jwe
>
>
>#include <iostream>
>
>#include <CGDirectDisplay.h>
>#include <CGDisplayConfiguration.h>
>
>int
>main (void)
>{
>  CGDirectDisplayID display = CGMainDisplayID ();
>
>  if (display)
>    {
>
>      size_t ht = CGDisplayPixelsHigh (display);
>      size_t wd = CGDisplayPixelsWide (display);
>
>      std::cerr << wd << "x" << ht << " pixels" << std::endl;
>
>      CGSize sz_mm = CGDisplayScreenSize (display);
>
>      CGFloat ht_mm = sz_mm.height;
>      CGFloat wd_mm = sz_mm.width;
>
>      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;
>
>      double resy = wd * 25.4 / wd_mm;
>      double resx = ht * 25.4 / ht_mm;
>
>      std::cerr << resx << " resx" << std::endl;
>      std::cerr << resy << " resx" << std::endl;
>
>      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;
>
>      size_t depth = CGDisplayBitsPerPixel (display);
>
>      std::cerr << depth << " bit depth" << std::endl;
>    }
>  else
>    std::cerr << "failed to find display" << std::endl;
>
>  return 0;
>}

The program's output is below.

1280x1024 pixels
380x310 mm
83.9019 resx
85.5579 resx
84.7299 avg dpi
32 bit depth

I can confirm the numbers are correct as well ... well almost. The physical size of my screen is 14.75x11.75 inches.

>> [1280,1024]./[14.75,11.75]
ans =
   86.7797   87.1489

The manufacturer likes to claim 15x12inches

>> [1280,1024]./[15,12]
ans =
   85.3333   85.3333

In any event, looks good to me.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Ben Abbott wrote:

| The program's output is below.
|
| 1280x1024 pixels
| 380x310 mm
| 83.9019 resx
| 85.5579 resx
| 84.7299 avg dpi
| 32 bit depth
|
| I can confirm the numbers are correct as well ... well almost. The physical size of my screen is 14.75x11.75 inches.
|
| >> [1280,1024]./[14.75,11.75]
| ans =
|    86.7797   87.1489
|
| The manufacturer likes to claim 15x12inches
|
| >> [1280,1024]./[15,12]
| ans =
|    85.3333   85.3333
|
| In any event, looks good to me.

OK.

Is it reasonable to assume that all current OS X systems will have
CGDirectDisplay.h and CGDisplayConfiguration.h and these functions?

How should we decide that we are using OS X?  Are there any
preprocessor macros we can depend on?  We currently do this on Windows
systems:

  #if defined (_MSC_VER)
  #define __WIN32__
  #define WIN32
  [...]
  #endif

  /* Define if we expect to have <windows.h>, Sleep, etc. */
  #if defined (__WIN32__) && ! defined (__CYGWIN__)
  #define OCTAVE_USE_WINDOWS_API 1
  #endif

(Does GCC define __WIN32__ and WIN32 automatically?)  I'd like to do
something similar for OS X to define OCTAVE_USE_OS_X_API.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, John W. Eaton wrote:

| (Does GCC define __WIN32__ and WIN32 automatically?)  I'd like to do
| something similar for OS X to define OCTAVE_USE_OS_X_API.

For now, I went with

  #if defined (__APPLE__)
  #define OCTAVE_USE_OS_X_API 1
  #endif

Is there something better we should use?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
On Thursday, January 22, 2009, at 01:33PM, "John W. Eaton" <[hidden email]> wrote:

>On 22-Jan-2009, John W. Eaton wrote:
>
>| (Does GCC define __WIN32__ and WIN32 automatically?)  I'd like to do
>| something similar for OS X to define OCTAVE_USE_OS_X_API.
>
>For now, I went with
>
>  #if defined (__APPLE__)
>  #define OCTAVE_USE_OS_X_API 1
>  #endif
>
>Is there something better we should use?
>
>jwe
>

... looking over the current sources, toplev.cc has

#if defined (__APPLE__) && defined (__MACH__)
        mac_system = true;
#endif

I'm not sure why both are checked (are there any existing Apple computers that don't have Mach Kernel?). In any event, for the sake of consistency, should both be checked?

Ben



Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Michael Goffioul
In reply to this post by John W. Eaton
I used the attached code instead (note the use LOGPIXELSX/Y and
ReleaseDC). The results are:

1280x800 pixels
320x200 mm
101.6 resx
101.6 resy
96 resx_log
96 resy_log
101.6 avg dpi
32 bit depth

Michael.


On Thu, Jan 22, 2009 at 3:08 PM, John W. Eaton <[hidden email]> wrote:

> On 22-Jan-2009, Michael Goffioul wrote:
>
> | On Thu, Jan 22, 2009 at 2:13 PM, John W. Eaton <[hidden email]> wrote:
> | > On 22-Jan-2009, Shai Ayal wrote:
> | >
> | > | OK. But I don't know how hard it will be to make this cross platform.
> | > | We might try to "steal" some code from fltk to discover the
> | > | platform.
> | >
> | > Why?  This seems to be a compile-time thing.  We can discover if the
> | > build system has X11, or is Windows, or is OS X, and then we just need
> | > to know how to get the screen characteristics on those systems.  I
> | > provided the example code for X11.  Now someone else needs to do the
> | > same for Windows and
OS X.

> |
> | Under Windows, it would be done using GetSystemMetrics and
> | GetDeviceCaps functions.
>
> Does the following program do the right thing?
>
> Thanks,
>
> jwe
>
>
> #include <iostream>
>
> #include <Windows.h>
>
> int
> main (void)
> {
>  HDC hdc = GetDC (0);
>
>  if (hdc)
>    {
>      int ht = GetDeviceCaps (hdc, VERTRES);
>      int wd = GetDeviceCaps (hdc, HORZRES);
>
>      std::cerr << wd << "x" << ht << " pixels" << std::endl;
>
>      double ht_mm = GetDeviceCaps (hdc, VERTSIZE);
>      double wd_mm = GetDeviceCaps (hdc, HORZSIZE);
>
>      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;
>
>      double resy = wd * 25.4 / wd_mm;
>      double resx = ht * 25.4 / ht_mm;
>
>      std::cerr << resx << " resx" << std::endl;
>      std::cerr << resy << " resx" << std::endl;
>
>      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;
>
>      int depth = GetDeviceCaps (hdc, BITSPIXEL)
>
>      std::cerr << depth << " bit depth" << std::endl;
>    }
>  else
>    std::cerr << "failed to get device context" << std::endl;
>
>  return 0;
> }
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
In reply to this post by bpabbott
On 22-Jan-2009, Ben Abbott wrote:

| On Thursday, January 22, 2009, at 01:33PM, "John W. Eaton" <[hidden email]> wrote:
| >On 22-Jan-2009, John W. Eaton wrote:
| >
| >| (Does GCC define __WIN32__ and WIN32 automatically?)  I'd like to do
| >| something similar for OS X to define OCTAVE_USE_OS_X_API.
| >
| >For now, I went with
| >
| >  #if defined (__APPLE__)
| >  #define OCTAVE_USE_OS_X_API 1
| >  #endif
| >
| >Is there something better we should use?
| >
| >jwe
| >
|
| ... looking over the current sources, toplev.cc has
|
| #if defined (__APPLE__) && defined (__MACH__)
|         mac_system = true;
| #endif
|
| I'm not sure why both are checked (are there any existing Apple computers that don't have Mach Kernel?). In any event, for the sake of consistency, should both be checked?

I don't know why it was done that way.  I think I'll leave in my most
recent change to configure.in that will define OCTAVE_USE_OS_X_API and
if __APPLE__ is defined, then use that in other places that check for
__APPLE__ or __MACH__.  OK?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Michael Goffioul
In reply to this post by Michael Goffioul
Better with the attachment.

On Thu, Jan 22, 2009 at 6:57 PM, Michael Goffioul
<[hidden email]> wrote:

> I used the attached code instead (note the use LOGPIXELSX/Y and
> ReleaseDC). The results are:
>
> 1280x800 pixels
> 320x200 mm
> 101.6 resx
> 101.6 resy
> 96 resx_log
> 96 resy_log
> 101.6 avg dpi
> 32 bit depth
>
> Michael.
>
>
> On Thu, Jan 22, 2009 at 3:08 PM, John W. Eaton <[hidden email]> wrote:
>> On 22-Jan-2009, Michael Goffioul wrote:
>>
>> | On Thu, Jan 22, 2009 at 2:13 PM, John W. Eaton <[hidden email]> wrote:
>> | > On 22-Jan-2009, Shai Ayal wrote:
>> | >
>> | > | OK. But I don't know how hard it will be to make this cross platform.
>> | > | We might try to "steal" some code from fltk to discover the
>> | > | platform.
>> | >
>> | > Why?  This seems to be a compile-time thing.  We can discover if the
>> | > build system has X11, or is Windows, or is OS X, and then we just need
>> | > to know how to get the screen characteristics on those systems.  I
>> | > provided the example code for X11.  Now someone else needs to do the
>> | > same for Windows and
> OS X.
>> |
>> | Under Windows, it would be done using GetSystemMetrics and
>> | GetDeviceCaps functions.
>>
>> Does the following program do the right thing?
>>
>> Thanks,
>>
>> jwe
>>
>>
>> #include <iostream>
>>
>> #include <Windows.h>
>>
>> int
>> main (void)
>> {
>>  HDC hdc = GetDC (0);
>>
>>  if (hdc)
>>    {
>>      int ht = GetDeviceCaps (hdc, VERTRES);
>>      int wd = GetDeviceCaps (hdc, HORZRES);
>>
>>      std::cerr << wd << "x" << ht << " pixels" << std::endl;
>>
>>      double ht_mm = GetDeviceCaps (hdc, VERTSIZE);
>>      double wd_mm = GetDeviceCaps (hdc, HORZSIZE);
>>
>>      std::cerr << wd_mm << "x" << ht_mm << " mm" << std::endl;
>>
>>      double resy = wd * 25.4 / wd_mm;
>>      double resx = ht * 25.4 / ht_mm;
>>
>>      std::cerr << resx << " resx" << std::endl;
>>      std::cerr << resy << " resx" << std::endl;
>>
>>      std::cerr << (resx + resy) / 2 << " avg dpi" << std::endl;
>>
>>      int depth = GetDeviceCaps (hdc, BITSPIXEL)
>>
>>      std::cerr << depth << " bit depth" << std::endl;
>>    }
>>  else
>>    std::cerr << "failed to get device context" << std::endl;
>>
>>  return 0;
>> }
>>
>>
>

foo.cc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Michael Goffioul wrote:

| Better with the attachment.
|
| On Thu, Jan 22, 2009 at 6:57 PM, Michael Goffioul
| <[hidden email]> wrote:
| > I used the attached code instead (note the use LOGPIXELSX/Y and
| > ReleaseDC). The results are:
| >
| > 1280x800 pixels
| > 320x200 mm
| > 101.6 resx
| > 101.6 resy
| > 96 resx_log
| > 96 resy_log
| > 101.6 avg dpi
| > 32 bit depth

So what is the correct thing to do?  Compute the pixel size, or use
the result from LOGPIXELSX/Y?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

bpabbott
Administrator
In reply to this post by John W. Eaton
On Thursday, January 22, 2009, at 01:57PM, "John W. Eaton" <[hidden email]> wrote:

>On 22-Jan-2009, Ben Abbott wrote:
>
>| On Thursday, January 22, 2009, at 01:33PM, "John W. Eaton" <[hidden email]> wrote:
>| >On 22-Jan-2009, John W. Eaton wrote:
>| >
>| >| (Does GCC define __WIN32__ and WIN32 automatically?)  I'd like to do
>| >| something similar for OS X to define OCTAVE_USE_OS_X_API.
>| >
>| >For now, I went with
>| >
>| >  #if defined (__APPLE__)
>| >  #define OCTAVE_USE_OS_X_API 1
>| >  #endif
>| >
>| >Is there something better we should use?
>| >
>| >jwe
>| >
>|
>| ... looking over the current sources, toplev.cc has
>|
>| #if defined (__APPLE__) && defined (__MACH__)
>|         mac_system = true;
>| #endif
>|
>| I'm not sure why both are checked (are there any existing Apple computers that don't have Mach Kernel?). In any event, for the sake of consistency, should both be checked?
>
>I don't know why it was done that way.  I think I'll leave in my most
>recent change to configure.in that will define OCTAVE_USE_OS_X_API and
>if __APPLE__ is defined, then use that in other places that check for
>__APPLE__ or __MACH__.  OK?
>
>jwe

I searched Nabble and found the thread below.

http://www.nabble.com/Re%3A-MacOSX%3A-ismac%28%29-implementation-p13071585.html

The relevant part is by Thomas Treichl

>> I think I can't answer this question by sure, I can only say that __APPLE__ is
>> the replacement for __darwin__ since MacOSX and __MACH__ seems to be there for a
>> long time. These macros have been introduced by GNU and are also used on the
>> Apple Developer website for the one or other example. There seem to be other
>> proprietary compilers for Mac available but I don't know if they come with these
>> macros.

I suspect that __APPLE__ && __MACH__ == Mac OS X and __APPLE__ && ! __MACH__ == OS9

For practical reasons, I don't see a reason to not assume all Apple's computers have a Mach Kernel.

Ben



Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

John W. Eaton
Administrator
On 22-Jan-2009, Ben Abbott wrote:

| For practical reasons, I don't see a reason to not assume all Apple's computers have a Mach Kernel.

OK.  I think we should use OCTAVE_USE_OS_X_API in the sources, and if
we need to change the way it is detected, at least we only have to
change it one place.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: [changeset] Missing ScreenSize & ScreenPixelsPerInch properties

Thomas Treichl
John W. Eaton schrieb:

> On 22-Jan-2009, Ben Abbott wrote:
>
> | For practical reasons, I don't see a reason to not assume all Apple's computers have a Mach Kernel.
>
> OK.  I think we should use OCTAVE_USE_OS_X_API in the sources, and if
> we need to change the way it is detected, at least we only have to
> change it one place.
>
> jwe
>

Hi,

just brought the twins to bed and now have 5 more minutes to put in my 2c worth
here. The macro definition about __APPLE__ and/or __MACH__ is described here:

   http://developer.apple.com/technotes/tn2002/tn2071.html

A copy of the relevant parts from this site:

   __MACH__
     This macro is defined if Mach system calls are supported.
   __APPLE__
     This macro is defined in any Apple computer.

They suggest to always use both macros with an && combination on modern systems
(that's also the same that I somewhere read in the GNU GCC documentation but
currently cannot find it anymore).

John, you were asking for CGDirectDisplay.h and CGDisplayConfiguration.h on all
systems? Generally yes, since MacOSX 10.3.9 and until at least 10.4.11 which is
my system (Ben can you please verify on your 10.5.x system). Here is my output
from a quick search:

bash /Developer/SDKs $ find MacOSX10.3.9.sdk -iname CGDirectDisplay.h
   MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/CGDirectDisplay.h
   MacOSX10.3.9.sdk/Developer/Headers/CFMCarbon/CoreGraphics/CGDirectDisplay.h

The other thing is that, John, you've written Carbon, not Cocoa. Cocoa is the
ObjC way for accessing the Apple user interface, whereas Carbon is the C-API. In
the changeset earlier you wrote

   #elif defined (OCTAVE_USE_COCOA_API)  // FIXME -- what should this be called?

which better should be changed to

   #elif defined (OCTAVE_USE_CARBON_API)

If somebody is interested in some more history about it I would suggest

   http://en.wikipedia.org/wiki/Carbon_(API)

I don't have any further notes. BTW, thank you very much for this port!

   Thomas
123