This function does what, now?

Carnildo

I'm working on porting a text-layout library from Mac and Windows to Linux/X11. It's pretty clear that the Mac port was grafted on to a non-portable Windows implementation: the function signature (and my commentary) for one of the "implement this for your platform" functions follows. Note that when compiling for MacOS, the "HDC" type is typedef'd to be a synonym for the GrafPtr type, while HPEN becomes a synonym for "long".

/* Sets the pen-like drawing characteristics in the specified drawing context. */

/* I can't figure out what this is supposed to do.  Under Windows, the function
 * signature takes a HDC and a HPEN (integers with pointer-like semantics), and 
 * inserts the pen into the device context, returning the old pen.  Under MacOS,
 * the function signature takes a GrafPtr (a pointer to an opaque GrafPort struct)
 * and a long int containing a 12-bit RGB color (4 bits per channel), updates the
 * color of the GrafPort pointed to while resetting the line-drawing style to 
 * "normal", and returns a constant corresponding to 12-bit black (but with some
 * high-order bits set).
 *
 * What's the function signature supposed to be under XWindows, and what is the
 * function supposed to do?
 */

HANDLE SelectObject(HDC hDC, HANDLE object)

To make things more exciting, while a Macintosh GrafPort and a Windows device context are similar enough to be reasonably interchangeable, XWindows has nothing that bears more than a passing resemblance to either.

Bulb

@Carnildo said:

To make things more exciting, while a Macintosh GrafPort and a Windows device context are similar enough to be reasonably interchangeable, XWindows has nothing that bears more than a passing resemblance to either.

The XWindows Graphic Context (GC) has much more than passing resemblance to Device Context. It is pretty similar. Well, except things like that it does not have separate fill colour, but I suppose you don't need that.

The only problem is, that in Windows the SelectObject is used to select pens (line style + colour), brushes (fill colour), fonts and many other things, while X (both Xlib and the more modern XCB) have separate functions for all those things. But from your comment I infer OS X does not have a single function for all those things either.

acne

XWindow_

tdb

@Bulb said:

@Carnildo said:
To make things more exciting, while a Macintosh GrafPort and a Windows device context are similar enough to be reasonably interchangeable, XWindows has nothing that bears more than a passing resemblance to either.

The XWindows Graphic Context (GC) has much more than passing resemblance to Device Context. It is pretty similar. Well, except things like that it does not have separate fill colour, but I suppose you don't need that.

The only problem is, that in Windows the SelectObject is used to select pens (line style + colour), brushes (fill colour), fonts and many other things, while X (both Xlib and the more modern XCB) have separate functions for all those things. But from your comment I infer OS X does not have a single function for all those things either.

I don't know about XCB, but Xlib has a single function for that. It's called XChangeGC. Among other things, it can set foreground and background colors, line width and style, tile pattern and font.

If you are going to reimplement winapi functions in order to compile the code for X11, you might as well use winelib, which has them already. It sounds like the library could use a thorough overhaul and a portable interface.

Carnildo

@Bulb said:

@Carnildo said:
To make things more exciting, while a Macintosh GrafPort and a Windows device context are similar enough to be reasonably interchangeable, XWindows has nothing that bears more than a passing resemblance to either.

The XWindows Graphic Context (GC) has much more than passing resemblance to Device Context. It is pretty similar. Well, except things like that it does not have separate fill colour, but I suppose you don't need that.

If you're drawing something on Windows, a handle to the DC is the only piece of data you need. On XWindows, you need a GC, a Display, and a Drawable at a minimum. You can't just pass around a GC the way you would a HDC or a GrafPtr.

@Bulb said:

The only problem is, that in Windows the SelectObject is used to select pens (line style + colour), brushes (fill colour), fonts and many other things, while X (both Xlib and the more modern XCB) have separate functions for all those things. But from your comment I infer OS X does not have a single function for all those things either.

This library only uses it to change pens, which is going to make the port easier: once I figure out what it's supposed to do, I'll rename it to "ChangePen" or "ChangeLineColor" or somesuch, make it a thin wrapper to SelectObject() on Windows, and write the Linux version.

nat42

Sorry but where is the WTF here?

SelectObject is part of the Win32 API http://msdn.microsoft.com/en-us/library/dd162957(VS.85).aspx - as such, you would expect it to be used by a non-portable Win32 library responsible for drawing pretty-much anything to the Windows GUI [well, using the GDI atleast]

Unless this is one of the library's exports, I can't see anything that surprising here except that the Mac port could get away with keeping this function while crippling it so horribly. I think TDB is right, just use Winelib...

DaveK1

@nat42 said:

Sorry but where is the WTF here?

The way in which this portable library has been poorly partitioned into OS-dependent and OS-independent parts, such that it has a function that is named after a win32-specific API and which performs completely different operations depending on which OS port of the library you are running.

@Carnildo said:

It's pretty clear that the Mac port was grafted on to a non-portable Windows implementation

That.