first, we don't need to block on geoclue being available. when/if it becomes an option, great. but seriously, the geoclue stuff isn't where the bulk of the work is. geoclue hooks into a number of different mechanisms and services, but it's taking that information and doing stuff with it that matters and which takes the real coding efforts. the plasma dataengine already implements a couple of sources and is available here and now so we can start right away with hard work bits.
so .. to your list:
* Fix Geoclue to be fully Gnome independent (Inge has a patch?)
this is not a blocker. move on.
* Add a Qt-only abstraction layer for Geolocation services (including Geoclue as one backend) to kdesupport
* Add a KDE wrapper for the Qt abstraction layer (if needed) into kdelibs
i don't think we need both; if configuration is needed, the kconfig or nepomuk (depending on what kind of config) comes into the picture, but that can happen elsewhere. there's no need for wrapping-the-wrapper imo. the one thing that is made easier with doing it using KDE stuff rather than Qt-only is the http communication using KIO.
* Add a Named Location service to kdelibs or kdebase
this could be implemented right now, e.g. in the plasma dataengine. this could transition to a separate library later if needed/desired.
* Add improvements to desktop session management in kdebase
there has been quite a bit of talk about this in the plasma camp, maybe you can find some of the plasma people there.
* Add a KCM for Named Locations
i think we need to be careful not to turn this into such an ordeal for the user through UI scaffolding that it becomes unuseful. while a kcm would be nice for management, i think setting up a named location should be done right from perhaps the network manager applet or some other part of the desktop workflow that is already at the user's fingertips.
* Add support to apps and desktop
this is biggest point, yes, and one we've only started on. it's easy to point at a dozen or more different places you could add meaningful geolocation features with just a dozen or two lines of code each.
* Apps to advertise their Events and Actions
* GUI to allow users to link Events and Actions
events and actions? that sounds so generic as to be a GUI nightmare and too ill-defined to result in a meaningful, consistent implementation. this part sounds like it could use some more refinement, i and nepomuk is really the place for the storage. personally, i think what's more useful/important is to define what kinds of events we want to react to and build from there. starting with a generic framework for this is asking for fuzzyness in the results imo.
concrete plans
first, we don't need to block on geoclue being available. when/if it becomes an option, great. but seriously, the geoclue stuff isn't where the bulk of the work is. geoclue hooks into a number of different mechanisms and services, but it's taking that information and doing stuff with it that matters and which takes the real coding efforts. the plasma dataengine already implements a couple of sources and is available here and now so we can start right away with hard work bits.
so .. to your list:
* Fix Geoclue to be fully Gnome independent (Inge has a patch?)
this is not a blocker. move on.
* Add a Qt-only abstraction layer for Geolocation services (including Geoclue as one backend) to kdesupport
* Add a KDE wrapper for the Qt abstraction layer (if needed) into kdelibs
i don't think we need both; if configuration is needed, the kconfig or nepomuk (depending on what kind of config) comes into the picture, but that can happen elsewhere. there's no need for wrapping-the-wrapper imo. the one thing that is made easier with doing it using KDE stuff rather than Qt-only is the http communication using KIO.
* Add a Named Location service to kdelibs or kdebase
this could be implemented right now, e.g. in the plasma dataengine. this could transition to a separate library later if needed/desired.
* Add improvements to desktop session management in kdebase
there has been quite a bit of talk about this in the plasma camp, maybe you can find some of the plasma people there.
* Add a KCM for Named Locations
i think we need to be careful not to turn this into such an ordeal for the user through UI scaffolding that it becomes unuseful. while a kcm would be nice for management, i think setting up a named location should be done right from perhaps the network manager applet or some other part of the desktop workflow that is already at the user's fingertips.
* Add support to apps and desktop
this is biggest point, yes, and one we've only started on. it's easy to point at a dozen or more different places you could add meaningful geolocation features with just a dozen or two lines of code each.
* Apps to advertise their Events and Actions
* GUI to allow users to link Events and Actions
events and actions? that sounds so generic as to be a GUI nightmare and too ill-defined to result in a meaningful, consistent implementation. this part sounds like it could use some more refinement, i and nepomuk is really the place for the storage. personally, i think what's more useful/important is to define what kinds of events we want to react to and build from there. starting with a generic framework for this is asking for fuzzyness in the results imo.