[Xcb] obj-xcb questions

[Jamey Sharp]

On Wed, Jun 07, 2006 at 07:41:38PM -0700, Thomas Coppi wrote:
> Hello all,

Hi, Thomas!

> [W]hen generating code from the xml protocol descriptions in xcb-proto,
> some requests, such as GrabServer, UngrabServer, GetInputFocus, etc. do
> not have any field values.  This is a problem, because I am currently
> grouping requests into objects by the first XID in a field, which seems
> to be OK most of the time, but with these rules, these kinds of requests
> would be orphans.  Maybe they should go into the Connection object?

Yeah, I think putting orphans in the Connection object makes sense.

Note that orphans wouldn't be static methods of Connection, though.
After all, there can be more than one X server connection open, and
requests like GrabServer have to be sent to the right one. :-)

I gather you're concerned about what to do with orphans from other .xml
files, namely extensions? I think it's reasonable to create a new class
for each extension, where instances are created using a Connection;
orphans can then go in the appropriate extension's class. The
constructor for an extension can check that the extension is actually
available, which might be useful.

If you were actually only concerned about how to mix hand-written and
machine-generated code together into one class, I'd suggest putting the
hand-written code in a base class with a protected-visibility
constructor, and the machine-generated code in a subclass. I think that
addresses the issue pretty reasonably.

> 	The second problem is that some other requests, such as GrabPointer,
> GrabButton and TranslateCoordinates would, following the above rule, go
> into ObjXCBWindow, but that probably isn't where they should be...

Hmmm... It's not clear to me what's most useful there. How about
extending the rule this way: "If the request has more fields of the same
type as the first XID-typed field, then ignore the XID type and treat
the request as an orphan." Does that help?

I do see some small issues with your documented plans, too. :-)

I'm not sure Create* requests should be invoked from constructors for
their XID types. At the least, you have to allow constructing a window
object from an existing window ID without having CreateWindow called on
it, for example. (The window ID might have come from QueryTree, say.)
You might also consider allowing a particular window ID to be used in a
CreateWindow, then DestroyWindow, then another CreateWindow -- I believe
the protocol allows that, although it's probably unwise and confusing.
Anyway, letting CreateWindow be just another method in ObjXCBWindow
might make sense.

I'm concerned that you don't seem to be planning to support latency
hiding in any way. If I'm reading your notes correctly, you plan to
generate a function like this one. (Pardon the pseudo-syntax mixed from
several languages at once, but I don't know Objective-C.)

    XCBQueryTreeRep *ObjXCBWindow::QueryTree()
    {
        XCBQueryTreeCookie cookie = XCBQueryTree(c, self.xid);
        XCBGenericError *error;
        XCBQueryTreeRep *rep = XCBQueryTreeReply(c, cookie, &error);
        free(error);
        return rep;
    }

This function would block the caller until the request has been sent all
the way to the server (which may be a long trip), processed there, and
the reply has come all the way back. If you're going to return XCB types
from these functions, I think it should be the cookie types, not the
reply types. If you want to return reply objects, I think they should be
real objects with accessor functions that only force the cookie when
accessed.

Also, I don't see that you've considered error handling yet, so I want
to bring it to your attention. Objective-C supports exceptions, right?
It may make sense for you to generate code that tests whether
cookie.sequence is 0, whether *Reply returns 0, and whether an X error
occurred during a request -- then throw appropriate exceptions for the
various cases.

You comment that a list is always a pointer/array. This isn't exactly
true. X protocol list elements can be variable-length -- they can be
lists themselves -- so C-style arrays don't generally map to X lists.
You might take a look at the iterator code generated in XCB. It could be
considered a serious flaw in the XCB protocol descriptions that lists
with variable-length elements in requests are actually described as
lists of BYTE or similar right now...

As for how to relate the ConfigureWindow request with the ConfigWindow
enum, I agree that the XML ought to describe that relationship. We'd be
interested in suggestions for what that description should look like.

Finally, have you thought about memory management? If I'm not mistaken,
Objective-C is normally garbage-collected. XCB returns various
malloc()ed blocks that the caller is expected to free(). If you can get
those blocks to be automatically freed at the right time, that'd be
great.

I hope this mail was helpful. Do keep asking questions as needed. :-)

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060610/5e5ed3fd/attachment.pgp