What dbus-send commands control Clock & Calendar alarm settings?
asked 2014-12-25 00:46:35 +0300
tldr; User experience improves when functions of alarms, timers and calendar features, including programmable, loop-friendly alerts on the phone integrate well and include easily-consumed visual information (graphs) at a glance.
Update:
I tried $ dbus-send --system --type=method_call --print-reply --dest
ination=com.nokia.mce.signal.alarm_ui_feedback.ind 0 and something is amiss. Can someone suggest a correct way to interact with jolla-clock and mce timer functionality via dbus?
This (100% success = 3/3) captures dbus-monitor output to a variable (1) then outputs its value to a file (2). The output of dbus-monitor is all on one line, so I will try sed to fit some line breaks in. So, in Fingerterm:
signals=$(dbus-monitor);echo $signals>>signals
dbus-monitor>>signalsfile also works but echo $(dbus-monitor)>>signalsfile fails.
Please tell me how dbus can send signals (instructions) to the Clock process to set and/or (in)activate a named alarm or timer.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit settings could allow multiple looping countdowns as well as current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too.
They would show active loops and their loop sequences and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
An editable bar graph could show running time and custom alerts, to let users control irregular event notifications and logs. It allows start dependencies like previous counts or times completing, queueing of relative, scheduled, named alerts/alarms/notifications. Bar height can indicate alarm volume and such alarm sets might be made available in a calendar, to have alarm groups run on arbitrary dates and times. This may suit any user who has an activity that needs various cues but whose start is not precisely known. It can include any scheduled event, too, that starts early or late.
The integer fields would go in this next widget set (below) but would affect the properties on display for each of the timers above. The timers would all show their integer pairs as fractions near or in front of their graphical representations.
Is it possible to copy and edit copies of QML files, to fiddle harmlessly about and make a mockup to display in user nemo's home directory tree, on my Jolla?
The current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would exclude (fit around) fixed or scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, any item with dependent and independent events scheduled after it has a laborious knock-on effect on later calendar or timer item editing needs, potentially wasting a user's time. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their schedule easily.
I agree that a simple repeat button may be a nice addition. Some of what you want to do (I'm guessing you are talking about the pomodoro technique?) you can solve today using one of the sport apps, e.g. ZirkelTraining or TabaTimer. Some of what you want to do feels like it goes beyond the regular use case and perhaps better suited for a specialized app, not the basic timer app included in the base OS. OTOH with a sufficiently good UI even complex concepts can be understandable and it could be a powerful complement to the OS in the way similar to Google Now. I think you'll get more buy-in for your idea if you mock up some concept screens and a practical example of one of your use cases. You say it's an "obvious use case" but for me as a reader it is not so that would help me as a reader to understand what it is you are proposing.
stoft ( 2014-12-25 13:39:26 +0300 )editThanks for your input. I edited some of the careless language. Use cases and diagrams will follow soon. "Regular use case" does not fit with the unimplemented basic functionality under discussion, you are right. Further integrating the Clock-Calendar-Timer with bridging GUI functionality is something I believe ought not to need other apps.
rdmo ( 2014-12-25 14:49:59 +0300 )editA checkbox would work, but an integer field might be better. I decided to edit the question to reflect this viewpoint.
rdmo ( 2015-01-16 00:21:19 +0300 )edit$ mce -M -v -S
Module: /usr/lib/mce/modules/memnotify.so module lacks information
Module: /usr/lib/mce/modules/bluetooth.so module lacks information
Module: /usr/lib/mce/modules/sensor-gestures.so module lacks information
Module: /usr/lib/mce/modules/packagekit.so module lacks information
Module: /usr/lib/mce/modules/doubletap.so module lacks information ...
rdmo ( 2015-04-08 08:12:24 +0300 )edit