Andreas Beck wrote:
>
> > right, it will not be used to get the system working. However it is nice
> > to be able for clients to query what sort of configuration the system
> > currently has. See xdpyinfo, xinput, and friends.
>
> Sure. How often do you use them and for what purpose ? Ask a normal user
> what they do ... most won't know.
How often I use that is totally beside the point. The fact is that users
want to configure their input devices.
> It's debugging stuff, and if you need it, you can tune up LibGGI debugging
> or similar stuff or talk to the device.
right, that's just what I propose, sort of.
> > now consider the user wanting to configure (graphically, with all kinds of
> > other jazz...) his windowing system, i.e. setting up the kind of event
> > types he wants to use, i.e. the sensitivity of the stylus, etc.
>
> Look at LibGIC. It does just that. And I do not see, why the user has an
> advantage of seeing that the device he wants to use as a mouse is a
> "Wacom Intuos 1234 Tablet, Revision 567, Firmware-Rev 89,
> lefthanded-Stylus-option-installed, with-bumpy-surface-option-installed"
> instead of "Wacom Intuos 1234 Tablet".
because different revisions might support different capabilities. And as soon
as I'm able to take advantage of these advanced capabilities, the user might
want to know whether the device can do X or Y. I guess you never used gimp
with a tablet. Else you would understand what I'm talking about.
> The additional info is not needed - on the contrary - for an average user it
> is probably rather confusing.
I'm not suggesting that people have to deal with that stuff. But a powerful
windowing system that can be configured to take advantage of arbitrary devices
has to be able to present the necessary info to the user.
And no, X and Unix are *not* examples of how to do it. They perform rather
poorly, if it comes to User Interfaces.
> > right, and the problem I pointed out is still there: a potential buffer
> > overflow for long 'contents'.
>
> Do you _really_ think that this is a problem _in_practice_ ? From an
> academic point of view, it surely is, but ...
yes I do. You sound like software engineers twenty years ago, pointing out
that two positions are enough to represent a year.
> If you really think it is a problem, you can use something like:
>
> char varname[some_fixed_size];
> int varnamestart;
> char content[some_fixed_size];
> int contentstart;
that is hackish. Of course, with fixed size events that's the way to go.
But why use events in the first place ?
> > indeed. But I doubt that for this kind of information we really want an
> > asynchronous API. These metadata are usually queried once (either at
> > startup or whenever a new device is plugged in), and then dealt with by
> > the high level layers.
>
> And how do we get them through e.g. the tcp-event-bridge ? By adding an
> extra metadata connection ?
hmm, I don't really care for network transparency at this point. The level
of network transparency is rather poor on this level, so I wouldn't use it
anyway. I would (or in fact, I do) use CORBA a couple of levels above, to
exchange semantic info, i.e. much more coarse grained (just in case you are
going to point out how slow that is...)
> > The same would be true for my proposed dictionary. It would be associated
> > with a device, so memory management shouldn't be an issue.
>
> Across process boundaries ?
no, of course not. See how complex CORBA's resource management is to deal
with resources in a location transparent way. But CORBA uses true polymorphism
so there is little performance loss if you are colocated (since you can just
plug in a proxy that doesn't need any marshalling)
> > > Events are not objects like in an OOP language. The point is, that if
> > > you want to be able to ignore unknown stuff, you need a generic way to
> > > free it.
> > <rant>
> > I sometimes really wonder why people still consider C such a wonderful tool.
> > You'd never have such trouble in C++.
> > </rant>
>
> You have, trust me. If you don't have the object definitions at compile time
> and thus have code in your executable to deal with the new object, you are
> screwed, if you receive it from somewhere, like from an external source.
sure, you need some componentware to deal with the marshalling, ABI mapping, etc.
People have been doing that for quite a while. Look at mozilla xpcom, or CORBA
itself.
But that's not really the point. I never thought that network transparency was
an issue for GGI, and I still don't think it is. The GGI architecture is not really
robust for that (as our discussion proves).
> > Seriously, I don't see a big deal in adding a simple function to query
> > (synchronously, much like the giiQueryDeviceInfoByNumber() function you
> > pointed out) that returns heap allocated data (with clear ownership
> > semantics !) with additional information that can't be obtained with
> > events.
>
> See above. It ruins the possibility to tunnel this info through a stream.
right, but I never found any documentation/discussion pointing out that everything
in GGI must be 'streamable' (in your sense). This is really the first time I
hear such a constraint.
It is funny, as you pretend that only few people would be interested into the
kind of 'extension' I have in mind. How many people do you think have to pass
events through streams ?
And, how do the functions you pointed me at relate to this discussion ? I.e.,
don't they assume random access memory, i.e. as in a local address space ?
> > My proposal is to add a synchronous* interface to GII to let users query
> > device information. That would (IMO) even render the current command
> > events obsolete.
>
> If you find a good solution that will keep the stuff stream-transparent,
> o.k. - otherwise I don't think it is worth the small gain.
>
> The command events were created for exactly the purpose of keeping
> everything transparent, even across processes and towards kernel drivers.
well, the linux evdev driver (the one mapping raw input to /dev/input/event0)
at least seems to have other limits than GII events, i.e. by means of ioctl
I can query a couple of metadata. All I want is a way to transparently access
these data through GII. If GII only allows for a subset of these to be passed
through, I can't really consider it a 'General' Input Interface, i.e. users who
want to get more data have to bypass GII, which seems contradictory to the spirit
of GII/GGI, doesn't it ? That's my point about flexibility.
Regards,
Stefan
