blob: f6d1043059dad381a60bf3150576b708141d7275 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
-> for version 1.0
* XfconfBackend needs to do better validation on channel and property names
* unit tests - some done, need:
- locking test
- RemoveChannel() test
- PropertyChanged notification test
- GetAllProperties() test
- tests for all the array and struct stuff
* MCS settings migration code
- special backend to read config entries
- script/c code for users who want to migrate all their settings to
xfconf and ditch MCS entirely
* expire channels from memory if they aren't accessed for a while
* add a GetAllChannels() method to enable a gconf-editor type app
* implement the PropertyChanged signal
- should fire whenever SetProperty() is called and a value is set.
+ optimise by checking previous value; don't fire signal if the value
hasn't really changed. will this slow down the daemon too much?
- file system monitoring. if a backend file changes, the daemon needs to
re-read the file, but must save the old property tree so it can figure out
what has changed so it can send appropriate PropertyChanged signals
+ what happens if a channel isn't loaded into memory and its backing file
changes? load it and send PropertyChanged for all properties? that
could be very bad.
* separate XSETTINGS daemon that reads values from xfconfd
* libxfce4mcs-client dummy implementation that forwards to libxfconf
* cmdline get/set/query tool so the config store can be scriptable
-> for future:
* transaction support
* network support - allow remote displays and such
* do some caching in the client library? seems wasteful of memory, but it
could allow the daemon to ditch its copy of a channel's properties more
often.
|