edelib: XSettingsData Class Reference

edelib 1.0

- Main Page
- Related Pages
- Modules
- Namespaces
- Classes
- Files

- Class List
- Class Hierarchy
- Class Members

Public Attributes | List of all members
XSettingsData Class Reference

Main data shared between client and manager. More...

`#include <edelib/XSettingsCommon.h>`

## Public Attributes
Display * | display
int | screen
Window | manager_win
Atom | selection_atom
Atom | manager_atom
Atom | xsettings_atom
XSettingsList * | settings
unsigned long | serial

## Detailed Description

Main data shared between client and manager.

This structure is shared between client and manger. (should not be confused with ordinary sharing like memory sharing etc.)

This is short explaination what are differences between official XSETTINGS protocol.

Both client and manager implementations use this structure althought some members they fill it on different ways, notably manager_win. Manager will create and initialize manager_win variable but client will try to figure it out if manager is running. Rest of the members are filled in usual way.

Why complicate things like this? First of all XSETTINGS protocol nicely distinguish client and manager roles, where client can only read settings and manager set them and keep them in one place. Main problem with this is that client can only read those settings, but not change or alter them, so if client wants to save it's preferences it has somehow communicate with manager.

To avoid that, via current implementation, client will behave like half-manager (sorta of) and it can directly write to manager space. Will this cause races? Probably, but as long as client peak/write/read it's own settings problems should not occur; manager will setup initial settings at the startup and will not change them during runtime (most of, for me, known managers does not do this).

Alternative would be to create some communication channel with manager, but this will create incopatible manager with ones already developed. On other hand this will be the only solution if we are starting to get a lot of races.

If someone knows better way to handle this, please mail me; I will be happy to hear alternatives.

## Member Data Documentation

Display* display

display running XSETTINGS

Atom manager_atom

manager atom

Window manager_win

manager window

int screen

screen running XSETTINGS

Atom selection_atom

atom containing current screen number

unsigned long serial

a number used to check changes

XSettingsList* settings

list of settings we currently have

Atom xsettings_atom

XSETTINGS atom

The documentation for this class was generated from the following file:

- edelib/XSettingsCommon.h