[Xcb] obj-xcb questions

[Thomas Coppi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamey Sharp wrote:
> 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. :-)
 Of course, I don't know what I was thinking.
> 
> 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.
> 
 I never would have thought of that, but it seems like the best way.
>> 	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?
> 
 That seems to work.
> 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.
> 
 Well, this can certainly be done.  I can have two constructors
ObjXCBWindow, one that doesn't take an xid argument and creates its own,
and another that takes in an XID, and likewise for other objects where
it makes 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.
 I left out the most important part of XCB :(  Returning a new object
with accessor methods makes the most sense to me, as then the caller
wouldn't have to deal with direct XCB calls by himself.
> 
> 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.
> 
 It does support exceptions, however they are an extension created by
Apple and only supported on GCC 4.0 and above with the GNU runtime, or
on GCC 3.3 and above on OSX.  I'm not so sure about coding to such a new
feature, but it could always be #ifdefed out and fallback if gcc4 or osx
isn't detected.  I do agree, though, that error handling is very
important and needs to be addressed.
> 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...
Understood.
> 
> 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.
I'll have to get back to you on this one :)
> 
> 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.
There is a garbage collector, I've never really used it, but I'll look
into this, I agree it would make things easier.
> 
> I hope this mail was helpful. Do keep asking questions as needed. :-)
> 
 It was very helpful, and of course.
> --Jamey
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEjZajlU6kaExSKKoRAgvWAKCqXiakOYqnQerss9qBJ+BPC/BseQCgw8OO
vOuWl2PmaWt5rDo8yG1sbR8=
=o6kA
-----END PGP SIGNATURE-----