dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
org.freedesktop.Gypsy.Satellite.SatellitesChanged and
org.freedesktop.Gypsy.Time.TimeChanged signals.
But GPS is off.
I think neither of the events makes sense in this case and wastes cycles.
Probably not good for battery life.
Tilman Baumann wrote:
dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
org.freedesktop.Gypsy.Satellite.SatellitesChanged and
org.freedesktop.Gypsy.Time.TimeChanged signals.
But GPS is off.
I think neither of the events makes sense in this case and wastes cycles.
Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
Tilman Baumann wrote:
dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
Michael 'Mickey' Lauer wrote:
Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
Tilman Baumann wrote:
dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
Am Wednesday 17 September 2008 18:24:30 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
Tilman Baumann wrote:
dbus is
Michael 'Mickey' Lauer wrote:
I felt a dbus interface for that would be nice. It's not in use
yet, but we need something like that anyways when we want to support
waking up arbitrary dbus clients for PIM events.
What about a interface where a process can register a timer event for a
Michael 'Mickey' Lauer wrote:
It's important though that people
understand why we need all these abstractions. It's not because we love high
level interfaces, it's because we need to prepare for application
_integration_.
Yea, but there are things which are already solved and people are
Am Wednesday 17 September 2008 18:52:16 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
I felt a dbus interface for that would be nice. It's not in use
yet, but we need something like that anyways when we want to support
waking up arbitrary dbus clients for PIM events.
What about
Am Wednesday 17 September 2008 19:07:50 schrieb Tilman Baumann:
Michael 'Mickey' Lauer wrote:
It's important though that people
understand why we need all these abstractions. It's not because we love
high level interfaces, it's because we need to prepare for application
_integration_.
On 9/17/08, Tilman Baumann [EMAIL PROTECTED] wrote:
I see fso walking a fine line between genius and insanity. :)
settingsd vs. gconf would be one of these cases. I just refused to
really think about it yet, so i don't really know how much sense it
makes. I think i would not like the
Michael 'Mickey' Lauer wrote:
How do these programs know each other? Are all supposed to concurrently
program the RTC? = Boom.
That's why i'm suggesting this abstraction.
Programms should never set the rtc. They should just tell the backend
that they need a timer for a specific time, and the
Federico Lorenzi wrote:
On 9/17/08, Tilman Baumann [EMAIL PROTECTED] wrote:
I see fso walking a fine line between genius and insanity. :)
settingsd vs. gconf would be one of these cases. I just refused to
really think about it yet, so i don't really know how much sense it
makes. I think i
Michael 'Mickey' Lauer wrote:
I see fso walking a fine line between genius and insanity. :)
Agreed. But you'll never know on which part you walk unless you start moving.
That's what we're doing atm.
Please help us to stay on the genius' path ;)
Happyly.
At the moment i'm just observing
Tilman Baumann wrote:
And for the wakeup stuff. Well besides at there is not much of a stable
interface i guess, besides some acpi and nvram cruft.
I guess a dbus interface suits well for that. But needs to be more
abstract (register timer for callback/signal, remove timer). :)
But somehow
14 matches
Mail list logo
