nanogui: Thread: Newbie question--passing events between programs

Greg Haerr wrote:

> How about the idea of just implementing window property strings,
> ala X?  We need them for certain programs.  This would work
> also for your Tag idea if there were global properties as well.

Do you mean the whole full fat version with all the complexity of Atoms, 
proptery types, large properties that need multiple calls to retrieve 
the value, etc. or do you mean a much simplified version loosely 
modelled after the X window properties? I could go along with a 
simplified version but I wouldn't want to put the full complexity of X 
Atoms and Properties in Nano-X.

What do you need properties to do?

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

I don't know how the API development process works nor do I think I could
code such a thing, but if it means anything I put in my vote for
implementing IPC in the Nano-X server.

I also think it would be very helpful if a window can be found by another
window via a tag it broadcasts to the Nano-X server.  Perhaps also add a
flag in the tag of a window saying whether or not other windows are allowed
access it via its tag, in case a programmer doesn't want to allow
inter-process access to his/her program.

Cheers,
Henry Chea
Semcon Sweden AB

-----Original Message-----
From: Alex Holden
To: Greg Haerr
Cc: Henry Chea; ####@####.####
Sent: 1/29/2002 7:49 PM
Subject: Re: [nanogui] RE: Newbie question--passing events between program s

Greg Haerr wrote:
[snippage]
I think we should extend this API by adding three more calls to 
implement a list of tags and associated window IDs. That would allow 
clients to advertise their presence to other clients, enabling arbitrary
IPC via the Nano-X server.
[snippage]

: Do you mean the whole full fat version with all the complexity of Atoms, 
: proptery types, large properties that need multiple calls to retrieve 
: the value, etc. or do you mean a much simplified version loosely 
: modelled after the X window properties? 

I was thinking of the simpler version.



: I could go along with a 
: simplified version but I wouldn't want to put the full complexity of X 
: Atoms and Properties in Nano-X.
: 
: What do you need properties to do?

They're just atoms (hashed string value into an integer) associated with
a window, along with a value (string or integer?, malloc'd by server)

Regards,

Greg

: I also think it would be very helpful if a window can be found by another
: window via a tag it broadcasts to the Nano-X server.  Perhaps also add a
: flag in the tag of a window saying whether or not other windows are allowed
: access it via its tag, in case a programmer doesn't want to allow
: inter-process access to his/her program.

Currently, you can query all windows using GrQueryTree followed
by GrGetWindowInfo.  Use a predetermined window title as the
tag field.

Regards,

Greg

Greg Haerr wrote:

> : Do you mean the whole full fat version with all the complexity of Atoms, 
> : proptery types, large properties that need multiple calls to retrieve 
> : the value, etc. or do you mean a much simplified version loosely 
> : modelled after the X window properties? 
> I was thinking of the simpler version.


Ok, how about this:

typedef unsigned char GR_PROP;

/**
  * GrChangeProperty:
  *
  * @wid: the ID of the window the property is attached to
  * @property: the name of the property
  * @data: the data to be stored in the property
  * @len: the length of the data to be stored in the property
  *
  * Changes the data stored in the specified property attached to the
  * specified window. If the property does not already exist, it will be
  * created. The property name should be a zero terminated string. To
  * create a global property, attach it the root window
  * (GR_ROOT_WINDOW_ID). If data is a null pointer but len is 1, the
  * property is created with no data block attached to it. If len is 0,
  * the property is deleted.
  */
void GrChangeProperty(GR_WINDOW_ID wid, GR_CHAR *property,
                       GR_PROP *data, GR_COUNT len);

/**
  * GrGetWindowProperty:
  *
  * @wid: the ID of the window the property is attached to
  * @property: the name of the property
  * @data: pointer to a pointer to hold the address of the returned data
  * @Returns: the length of the returned data block
  *
  * Searches for a property with the specified name in the list of
  * properties attached to the specified window and returns the data
  * block associated with the property. If no such property is found, the
  * length is zero and the a null pointer is stored in the data pointer.
  * If the property exists but no data block is associated with it, 1 is
  * returned for the length and the data pointer is set to NULL. The data
  * block is allocated with malloc() at call time, and it is the callers
  * responsibility to free it when no longer needed.
  */
GR_COUNT GrGetWindowProperty(GR_WINDOW_ID wid, GR_CHAR *property,
                         GR_PROP **data);

These are basically much simplified versions of XChangeProperty() and 
XGetWindowProperty(). It's also possible to create an analog of 
XDeleteProperty() with just a #define:

#define GrDeleteProperty(wid, property) GrChangeProperty(wid, \
                                              property, NULL, 0)

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

Looks good.  Do you think we need anything special to store
longwords rather than just string data?  If we store longs as
&long, sizeof(long) it'll work, but the data will be client-processor-endian
dependent, that probably doesn't matter...

Regards,

Greg



: Ok, how about this:
: 
: typedef unsigned char GR_PROP;
: 
: /**
:   * GrChangeProperty:
:   *
:   * @wid: the ID of the window the property is attached to
:   * @property: the name of the property
:   * @data: the data to be stored in the property
:   * @len: the length of the data to be stored in the property
:   *
:   * Changes the data stored in the specified property attached to the
:   * specified window. If the property does not already exist, it will be
:   * created. The property name should be a zero terminated string. To
:   * create a global property, attach it the root window
:   * (GR_ROOT_WINDOW_ID). If data is a null pointer but len is 1, the
:   * property is created with no data block attached to it. If len is 0,
:   * the property is deleted.
:   */
: void GrChangeProperty(GR_WINDOW_ID wid, GR_CHAR *property,
:                        GR_PROP *data, GR_COUNT len);
: 
: /**
:   * GrGetWindowProperty:
:   *
:   * @wid: the ID of the window the property is attached to
:   * @property: the name of the property
:   * @data: pointer to a pointer to hold the address of the returned data
:   * @Returns: the length of the returned data block
:   *
:   * Searches for a property with the specified name in the list of
:   * properties attached to the specified window and returns the data
:   * block associated with the property. If no such property is found, the
:   * length is zero and the a null pointer is stored in the data pointer.
:   * If the property exists but no data block is associated with it, 1 is
:   * returned for the length and the data pointer is set to NULL. The data
:   * block is allocated with malloc() at call time, and it is the callers
:   * responsibility to free it when no longer needed.
:   */
: GR_COUNT GrGetWindowProperty(GR_WINDOW_ID wid, GR_CHAR *property,
:                          GR_PROP **data);
: 
: These are basically much simplified versions of XChangeProperty() and 
: XGetWindowProperty(). It's also possible to create an analog of 
: XDeleteProperty() with just a #define:
: 
: #define GrDeleteProperty(wid, property) GrChangeProperty(wid, \
:                                               property, NULL, 0)
: 
: -- 
: ------------ Alex Holden - http://www.linuxhacker.org ------------
: If it doesn't work, you're not hitting it with a big enough hammer
: 

Greg Haerr wrote:

> Looks good.  Do you think we need anything special to store
> longwords rather than just string data?  If we store longs as
> &long, sizeof(long) it'll work, but the data will be client-processor-endian
> dependent, that probably doesn't matter...

I don't think we'll ever support different endian client and server, do 
you? It would require breaking the API in several places and adding an 
awful lot of support code to keep track of the type of every piece of 
data that goes over the network so that it can be byte swapped if 
necessary. As long as we stick with the requirement that the client and 
server have the same byte order the server doesn't need to know what 
type of data is stored in a property, just how many bytes long it is.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

: I don't think we'll ever support different endian client and server, do 
: you? It would require breaking the API in several places and adding an 
: awful lot of support code to keep track of the type of every piece of 
: data that goes over the network so that it can be byte swapped if 
: necessary. As long as we stick with the requirement that the client and 
: server have the same byte order the server doesn't need to know what 
: type of data is stored in a property, just how many bytes long it is.

Yes, I think I agree.

Regards,

Greg