I gave this a quick read-through. Haven't had time yet to update
everything, so I can't apply it yet.
A few quick thoughts on the API.
I'd prefer to see a more object oriented API.
I.e. rather than having a single 'RemoteObject' that all calls go
through, have something like:
/org/enlightenment/wm
org.enlightenment.wm.Core
Restart()
Exit()
ListModules(OUT as)
org.enlightenment.wm.System
Suspend()
Hibernate()
Reboot()
Shutdown()
Logout()
LockScreen()
org.enlightenment.wm.Config
Set(IN s, IN v)
Get(IN s, OUT v)
GetMultiple(IN as, OUT a{sv})
/org/enlightenment/wm/module/<module_name>
org.enlightenment.wm.Module
Load()
Unload()
Enable()
Disable()
org.enlightenment.wm.Config
The names are still debatable, but I prefer having the modules as
separate objects on the bus. E could just create these for all available
modules, and provide a means for a module to fetch its bus object
(allowing it to register additional interfaces if desired).
Additionally, we may want to look into some of the existing specs for
things like power management, and if feasible, implement at least a
subset of them.
For config, i'm not sure how easily we can map dbus types to config
value types (or lookup values by property name). So, we may end up
needing individual get/set methods for each property (as the current ipc
is done).
Anyway, thanks for the initiative here.
Anyone else have ideas on how they'd like a dbus API for e to look?
Brian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
