Peter Hutterer wrote:
> For now, the rule is that handlers should not touch anything outside of their
> scope, and they cannot rely on being called in any particular order.
Fine. I think prop namespaces also could mitigate the problem, e.g.
driver.* Any plans for this?
> Let's see if that works. W
On Sun, Oct 12, 2008 at 06:17:20PM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > The patch I proposed does not make any guarantee over when a handler is
> > called. This automatically separates handlers so they cannot interfere with
> > each other, and dependency ordering is a nonissue, as y
Peter Hutterer wrote:
> The patch I proposed does not make any guarantee over when a handler is
> called. This automatically separates handlers so they cannot interfere with
> each other, and dependency ordering is a nonissue, as you cannot rely on it to
> begin with. Code that relies on other hand
On Fri, Oct 10, 2008 at 11:54:56AM +0200, Simon Thum wrote:
> > If so, a few questions:
> > - A handler that registers at the head of the queue, assumes it is before
> > other handlers. Thus it has to be aware of other handlers in the first
> > place?
> Yes, that would be the uncommon case, in
Peter Hutterer wrote:
> something like
>
> --
> RegisterHandler(myHandler, HEAD);
> RegisterHandler(otherHandler, TAIL);
>
> void myHandler(foo) {
>
>CallNextHandler(); /* causes otherHandler to be called */
>return PROP_HANDLED;
> }
> --
>
> Where CallNextHandler calls the handler next
On Thu, Oct 09, 2008 at 03:42:50PM +0200, Simon Thum wrote:
> One non-ignoring handler is invoked at max. For this we have to
> differentiate the RC.
> When a handler is invoked, it may decide to call a new function which
> allows it to pass through to handlers AFTER itself. A logical complement
>
Peter Hutterer wrote:
> right now, the properties are documented in the header files that define their
> names. They should eventually be added to the man pages, once they settle down
> a bit.
Fine, I'll be including a header.
> So based on the current implementation (the one that is in master), w
On Thu, Oct 09, 2008 at 03:20:36AM +0200, Simon Thum wrote:
> > So your point is to never have properties in the driver that could be in the
> > server? This may be tough, as drivers have a quicker turnover time, and
> > features can get added easier.
> Well, against double-handling a prop in gener
Peter Hutterer wrote:
> On Wed, Oct 08, 2008 at 11:05:07PM +0200, Simon Thum wrote:
> So your point is to never have properties in the driver that could be in the
> server? This may be tough, as drivers have a quicker turnover time, and
> features can get added easier.
Well, against double-handling
On Wed, Oct 08, 2008 at 11:05:07PM +0200, Simon Thum wrote:
> > Not necessarily. Once the server has support for X, we can just remove it
> > from
> > the driver and say that you need at least server Y with this driver version.
> > Or, once the server has a "XYZ" property, you can just make e.g. "
Peter Hutterer wrote:
> On Wed, Oct 08, 2008 at 09:12:44AM +0200, Simon Thum wrote:
>> Peter Hutterer wrote:
>>> Axis range changes are one example I can think of. The driver needs to
>>> update
>>> it for axis inversion, the server for scaling.
>> Hmm - that essentially forbids moving inversion i
On Wed, Oct 08, 2008 at 09:12:44AM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > Axis range changes are one example I can think of. The driver needs to
> > update
> > it for axis inversion, the server for scaling.
> Hmm - that essentially forbids moving inversion into the server (which
> co
Peter Hutterer wrote:
> Axis range changes are one example I can think of. The driver needs to update
> it for axis inversion, the server for scaling.
Hmm - that essentially forbids moving inversion into the server (which
could be done), because we'd never know if the driver wouldn't also do
it. Bu
On Wed, Oct 08, 2008 at 08:11:26AM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > The current code exposes to inconsistent updates, i.e. if handler N succeeds
> > but handler N+1 fails in setting the property, an error is returned to the
> > client although parts of the server now behave as i
Peter Hutterer wrote:
> The current code exposes to inconsistent updates, i.e. if handler N succeeds
> but handler N+1 fails in setting the property, an error is returned to the
> client although parts of the server now behave as if the property change
> succeeded.
I understand the problem, but are
The current code exposes to inconsistent updates, i.e. if handler N succeeds
but handler N+1 fails in setting the property, an error is returned to the
client although parts of the server now behave as if the property change
succeeded.
This patch adds a "checkonly" parameter to the SetProperty han
16 matches
Mail list logo
