We have moved to a new Sailfish OS Forum. Please start new discussions there.
1 | initial version | posted 2014-12-25 00:46:35 +0200 |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious use case is for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, reading, writing, mails, calls, etc.
2 | No.2 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious use case is for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
3 | No.3 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious use case is for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
4 | No.4 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious use case is for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep.
5 | No.5 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious use case is for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep.sleep. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
6 | No.6 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. The obvious One use case is might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
7 | retagged |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
8 | No.8 Revision |
I have the metronome on my Jolla, but when I need to time longer repeating fixed intervals precisely I cannot. A single check box in the Clock's timer settings could rectify this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this view:next widget set (below) but would affect the properties on display is the timers above.
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep. sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
9 | No.9 Revision |
I have the metronome on my Jolla, but when with it I need to cannot time longer repeating fixed intervals precisely I cannot. precisely. A single check box in the Clock's timer settings could rectify fix this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above.
above. I think the widget qml file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
10 | No.10 Revision |
I have the metronome on my Jolla, but with it I cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget qml file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot.of lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
11 | No.11 Revision |
I have the metronome on my Jolla, but with it I cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget qml file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml Local Jolla file CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
12 | No.12 Revision |
I have the metronome on my Jolla, but with it I cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget qml widget, aka. Local Jolla file CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
13 | No.13 Revision |
I have the metronome on my Jolla, but with it I cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this. Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget, aka. Local Jolla file CheckBox.qml file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated QML content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
14 | No.14 Revision |
I have the metronome on my Jolla, but with it I cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this. this looping timer issue and will allow multiple looping countdowns as well as the current non-repeating ones. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget, aka. file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated QML content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
15 | retagged |
I have the metronome on my Jolla, but it cannot time longer repeating fixed intervals precisely. A check box in the Clock's timer settings could fix this looping timer issue and will allow multiple looping countdowns as well as the current non-repeating ones. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
Better still would be a bar graph interface denoting time elapsed and custom alerts, to enable relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to a calendar for running alarm sets on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox would go in this next widget set (below) but would affect the properties on display is the timers above. I think the widget, aka. file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. Is it possible to copy and edit copies of these files to fiddle harmlessly about to make a mockup view to display on my Jolla? Or am I mistakenly looking at deprecated QML content?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
16 | No.16 Revision |
I have the The metronome on my Jolla, but it Jolla cannot time longer long repeating fixed intervals precisely. A check box intervals. Two integer fields in the Clock's timer editor settings could may fix this looping timer issue and will allow multiple looping countdowns as well as the current non-repeating ones.
They would do this by indicating which loop was running, if any, and how many loops were set to be run. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
Better still would be a A bar graph interface denoting could also denote time elapsed and custom alerts, to enable queueing of relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made copiable to available in a calendar for running calendar. Thid would allow alarm sets to run on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
The checkbox integer fields would go in this next widget set (below) but would affect the properties on display is for each of the timers above. I think the widget, aka. file:///usr/lib/qt5/qml/Qt/labs/components/native/CheckBox.qml has something to do here. 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 these files QML files, to fiddle harmlessly about to and make a mockup view to display in user nemo
's home directory tree, on my Jolla? Or am I mistakenly looking at deprecated QML content?Jolla?
The bar chart, for multiple relative alarms would be (imo) easier to set, compared to single relative alarms, though I see that the current countdown is limited to 24 hours and under with the current circular view.
These interdependent rescheduling capabilities would ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with dependent and independent event scheduled after it has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
17 | No.17 Revision |
The metronome on my Jolla cannot time long repeating fixed intervals. Two integer fields in the Clock's timer editor settings may fix this looping timer issue and will allow multiple looping countdowns as well as the current non-repeating ones.
They would do this by indicating which loop was running, if any, and how many loops were set to be run. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A bar graph interface could also denote time elapsed and custom alerts, to enable queueing of relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made available in a calendar. Thid would allow alarm sets to run on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item with (with dependent and independent event events scheduled after it it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
18 | retagged |
The metronome on my Jolla cannot time long repeating fixed intervals. Two integer fields in the Clock's timer editor settings may fix this looping timer issue and will allow multiple looping countdowns as well as the current non-repeating ones.
They would do this by indicating which loop was running, if any, and how many loops were set to be run. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A bar graph interface could also denote time elapsed and custom alerts, to enable queueing of relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made available in a calendar. Thid would allow alarm sets to run on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
19 | No.19 Revision |
The metronome on my GUIs on Jolla cannot time long repeating fixed don't yet countdown and repeat intervals. Two integer fields in the Clock's timer
editor edit settings may fix this looping timer issue and will could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones.
They would do this by indicating which loop was running, if any, and how many loops were set to be run. Related QML may be found here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A Further improvement with a bar graph interface GUI could also denote time elapsed and custom alerts, to enable irregular events whose start depends on the previous counts or times completing, queueing of relative, scheduled, named alerts/alarms/notifications. Bar height would indicate alarm volume and such alarm sets might be made available in a calendar. Thid would allow calendar, to have yhr alarm sets to run on arbitrary dates at given start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
20 | No.20 Revision |
GUIs on Jolla don't yet countdown and repeat intervals. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones.
They would do this by indicating which showing running loops and, for each, the loop was running, if any, and how many loops were set to be run. sequence and counts. Related QML may be found is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
Further improvement with a A än editable bar graph GUI could also denote running time elapsed and custom alerts, to enable alerts. This lets users control irregular events whose event notifications and logs. It allows start depends on the dependencies like previous counts or times completing, queueing of relative, scheduled, named alerts/alarms/notifications. Bar height would can indicate alarm volume and such alarm sets might be made available in a calendar, to have yhr alarm sets to groups run on arbitrary dates at given and times. This may suit any user who has an activity that needs various cues but whose start times. One use case might be for users who want to develop or enhance their habits and routines, who want some help in critical early, habit-forming stages... study, exercise, nutrition, reading, writing, mails, calls, optimising for Circadian biorhythms, etc.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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
21 | No.21 Revision |
GUIs on Jolla don't yet countdown and repeat intervals. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too. I'd upload a screenshot I just took but the widgets to upload images don't appear on my editing page.
They would do this by showing running loops and, for each, the loop sequence and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A än editable bar graph could also denote running time and custom alerts. This lets 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
22 | No.22 Revision |
GUIs on Jolla don't yet countdown and repeat intervals. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too. I'd upload a screenshot I just took but the widgets to upload images don't appear on my editing page.
They would do this by showing running loops and, for each, the loop sequence and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A än editable bar graph could also denote running time and custom alerts. This lets 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
23 | retagged |
GUIs on Jolla don't yet countdown and repeat intervals. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too. I'd upload a screenshot I just took but the widgets to upload images don't appear on my editing page.
They would do this by showing running loops and, for each, the loop sequence and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A än editable bar graph could also denote running time and custom alerts. This lets 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
24 | No.24 Revision |
GUIs on Jolla don't yet countdown and repeat intervals. with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too. I'd upload a screenshot I just took but the widgets to upload images don't appear on my editing page.too.
They would do this by showing running loops and, for each, the loop sequence and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A än editable bar graph could also denote running time and custom alerts. This lets 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
25 | No.25 Revision |
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the current non-repeating ones. Static regular scheduling is notably absent from the Calendar GUI too.
They would do this by showing running show active loops and, for each, the and their loop sequence sequences and counts. Related QML is here on the Jolla phone:
file:///usr/share/jolla-clock/pages/main/TimerItem.qml
A än An editable bar graph could also denote show running time and custom alerts. This lets 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
26 | No.26 Revision |
Update: This (100% success, 1/1 so far) captures dbus-monitor output to a variable then outputs its value to a file. The output of dbus-monitor is all on one line, so I will try sed to fit some line breaks in. In Fingerterm:
signals=$(dbus-monitor)
echo $signals>>signals
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
27 | No.27 Revision |
Update: This (100% success, 1/1 so far) captures dbus-monitor output to a variable (1) then outputs its value to a file. file (2). The output of dbus-monitor is all on one line, so I will try sed to fit some line breaks in. In Fingerterm:
signals=$(dbus-monitor)
signals=$(dbus-monitor)
echo $signals>>signals
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
28 | No.28 Revision |
Update: This (100% success, 1/1 so far) 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. In So, in Fingerterm:
signals=$(dbus-monitor)
echo $signals>>signals
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
29 | No.29 Revision |
Update: This (100% success, 1/1 so far) 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
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
30 | No.30 Revision |
Update: This (100% success, 1/1 so far) 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
(I didn't manage to nest 1 into 2.)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
31 | No.31 Revision |
Update: This (100% success, 1/1 2/2 so far) 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
(I didn't manage to nest 1 into 2.)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
32 | No.32 Revision |
Update: This (100% success, 2/2 so far) 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
(I didn't manage to nest 1 into 2.)2 to make a composite command in the way that might otherwise have been intuitive, echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
33 | No.33 Revision |
Update: This (100% success, 2/2 so far) 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=$(dbus-monitor);echo $signals>>signals
(I didn't manage to nest 1 into 2 to make a composite command in the way that might otherwise have been intuitive, intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
GUIs on Jolla don't countdown with repeats. Two integer fields in the Clock's timer edit
settings could allow multiple looping countdowns reps=(0>n+) as well as the 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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
34 | No.34 Revision |
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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
35 | No.35 Revision |
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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
36 | No.36 Revision |
tldr; User experience improves when functions of alarms, timers and calendar features 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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
37 | No.37 Revision |
tldr; User experience improves when functions of alarms, timers and calendar features 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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
38 | No.38 Revision |
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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
39 | No.39 Revision |
tldr; User experience improves improves when functions of alarms, timers and calendar features (including features, including programmable, loop-friendly alerts) alerts on the phone integrate well * and include easily-consumed visual information (graphs) at *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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
40 | No.40 Revision |
tldr; User experience improves when functions of alarms, timers and calendar features, including programmable, loop-friendly alerts on the phone integrate well* well and include easily-consumed visual information (graphs) *at 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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; echo $(dbus-monitor)>>signals)
To progress towards an answer to the Clock puzzle below, I want to find out if dbus
can send signals (instructions) to the Clock process so a named alarm or timer gets set up there.
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
41 | No.41 Revision |
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, 2/2 so far) 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
(I didn't manage to make a composite command in the way that might otherwise have been intuitive; (dbus-monitor>>signalsfile also works but echo $(dbus-monitor)>>signals$(dbus-monitor)>>signalsfile)
To progress towards an answer to the Clock puzzle below, I want to find out if fails.)
Please tell me how dbus
can send signals (instructions) to the Clock process so to set and/or (in)activate a named alarm or timer gets set up there.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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
42 | No.42 Revision |
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 ideally be able to fit themselves around fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early item (with dependent and independent events scheduled after it) has a tedious domino effect in which many individual calendar or timer items need to be individually manually edited, using a lot of time and mental energy. A paper diary or calendar suffers from this. A computer ought to enable its users to juggle their scheduling more easily.
43 | No.43 Revision |
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 ideally be able to fit themselves around exclude (fit around) fixed or other defined scheduled items, like meetings, meals and sleep defined in the calendar. Otherwise, when one early any item (with with dependent and independent events scheduled after it) it has a tedious domino laborious knock-on effect in which many individual on later calendar or timer items need to be individually manually edited, using a lot of time and mental energy. 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 scheduling more schedule easily.
44 | No.44 Revision |
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.) 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.