On Tue, Apr 17, 2007 at 08:35:01AM +0200, Vincent Torri wrote:
> On Tue, 17 Apr 2007, Carsten Haitzler (The Rasterman) wrote:
> and what about the case the xcb backend is used and the user does not use
> these new functions, but the old ones ?
The idea is to have the xcb back be a drop in replace
On Mon, 16 Apr 2007 23:38:36 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]>
babbled:
>
>
> On Mon, 16 Apr 2007, Brian Mattern wrote:
>
> > On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote:
> >
> > in that case, could you wrap up the _fetch() call into the _get() one,
> > and get ri
If I understand correctly, you want to
1) create that api for the XCB backend: _prefetch, _fetch and
_response
2) for the Xlib backend, to add _response, which would in fact be the
current _get function
3) the _get data be for both backend :
***_get (***)
{
***_prefetch(***); /* does not
On Mon, 16 Apr 2007, Brian Mattern wrote:
> On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote:
>
> in that case, could you wrap up the _fetch() call into the _get() one,
> and get rid of the global that stores the reply between the two calls?
no, I can't, because some ecore_x call m
On Mon, Apr 16, 2007 at 04:18:32PM -0500, Brian Mattern wrote:
> On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote:
> The problem i see is that for prefetch to really serve any purpose, the
> code has to hit the event loop between prefetch and fetch/get. It will
> be hard to guarantee t
On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote:
> On Mon, 16 Apr 2007, Brian Mattern wrote:
> >The following will not work:
> > prop1_fetch();
> > prop2_fetch();
> > prop1_get();
> > prop2_get();
> >(both get() calls will use the reply from prop2_fetch())
>
> Yes, that last one will
On Mon, 16 Apr 2007, Nathan Ingersoll wrote:
> On 4/16/07, Vincent Torri <[EMAIL PROTECTED]> wrote:
>>
>> Yes, that last one will not work, and it is in purpose. The reason : when
>> you ask for a reply, you want to use the informations returned by the X
>> server. So there is absolutely no int
On 4/16/07, Vincent Torri <[EMAIL PROTECTED]> wrote:
>
> Yes, that last one will not work, and it is in purpose. The reason : when
> you ask for a reply, you want to use the informations returned by the X
> server. So there is absolutely no interest in calling _fetch if you don't
> plan to use the
On Mon, 16 Apr 2007, Brian Mattern wrote:
> prefetch() currently sends a request to the server, and adds a 'cookie'
> to the end of a queue to track this request.
>
> fetch() shifts a cookie off the front of the queue, and blocks until
> a matching response has been received, placing the reply i
On Mon, Apr 16, 2007 at 12:54:25PM -0500, Nathan Ingersoll wrote:
> Nice work Vincent. As we discussed on IRC, there are a few changes to
> the API I would like to propose to reduce the differences between the
> two engines (Xlib or XCB) as it becomes more complete.
I agree with Nathan that having
Nice work Vincent. As we discussed on IRC, there are a few changes to
the API I would like to propose to reduce the differences between the
two engines (Xlib or XCB) as it becomes more complete.
This change introduces some slightly different calling conventions to
ecore_x, which I would consider a
Hey,
ecore_x with xcb backend is in cvs.
Consider it as alpha, even pre-alpha, code. Especially, don't start to
port your code to that api yet.
I have chosen a design for the api. It might not be the best. But I can
only hope that other devs will help me to improve it.
regards
Vincent
12 matches
Mail list logo
