Re: ffalarms 0.3 -- recurring alarms
On Mon, Oct 26, 2009 at 09:16:49PM +0100, Łukasz Pankowski wrote: > Of course you can do it simpler using repeat instead of shell for loop, > than this kill-hack is not needed: > > [alarm] > repeat=10 > player=sh -c 'mdbus -s org.freesmartphone.odeviced > /org/freesmartphone/Device/LED/neo1973_vibrator > org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10' > volume=-1 With this setup, I get an error message that "file" is not defined, and it reverts to defaults. If I define a dummy file, then this works. Thanks for your work! signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Fri, Oct 30, 2009 at 8:14 AM, Vikas Saurabh wrote: > I was about to report it...I guess empty file should be handled gracefully > > --Vikas thanks, that did it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
> r...@om-gta02 ~ $ ffalarms > icalerror.c:99: BADARG: Bad argument to function > ffalarms: icalerror.c:100: icalerror_set_errno: Assertion `0' failed. > Aborted > r...@om-gta02 ~ $ > > any ideas? It happened to me as well...and its probably you have got an empty .ffalarms/alarms file in your home directory. Just delete the file and the app would come up again. I was about to report it...I guess empty file should be handled gracefully --Vikas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
2009/10/29 William Kenworthy : > On Thu, 2009-10-29 at 23:52 +0100, Łukasz Pankowski wrote: > new ffalarms ive been using a recurring alarm all week with no issue. around tuesday i found that you can set the days of the week in the alarm. this was after i had already made the alarm so i figured i would let it be. today i deleted the recurring alarm as soon as the delete was acknowledged ffalarms seg'ed. now running ffalarms seg's r...@om-gta02 ~ $ ffalarms icalerror.c:99: BADARG: Bad argument to function ffalarms: icalerror.c:100: icalerror_set_errno: Assertion `0' failed. Aborted r...@om-gta02 ~ $ any ideas? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Thu, 2009-10-29 at 23:52 +0100, Łukasz Pankowski wrote: > William Kenworthy writes: > > > On Wed, 2009-10-28 at 22:39 +0100, Petr Vanek wrote: > >> On Wed, 28 Oct 2009 21:32:03 + > >> Al Johnson (AJ) wrote: > >> > >> >On Wednesday 28 October 2009, Petr Vanek wrote: > >> >> >I meant that it ought to behave that way in future, not that it > >> >> >would in the current version. I don't care if the phone goes to > >> >> >sleep during the snooze interval so long as the alarm goes off > >> >> >again five minutes later! > >> >> > > >> >> :) sure, now it didn't wake up itself and me neither :)) > >> >> > >> >> what if the unlocking 1-2-3-4 pattern is configurable, how would > >> >> snooze get in then? > >> > > >> >How about puzzle to stop the sound, display the message and show the > >> >ACK slider? If you don't ACK then there's another alarm after the > >> >snooze interval. > > When I implement snoozing (repeating the alarm if not ACK) I consider > easy turning off the alarm for the first time (most probably a button), > and a puzzle in a snoozed mode (all but first time). > Now that sounds a good compromise > >> > >> that would do just fine for me, just some people wanted to get rid of > >> the puzzle... > >> > >> Petr > >> > > > > Even without the puzzel, you still need an acknowledge button for the > > alarm so thats not a problem. The problem with the puzzel is 4 buttons > > with small, unreadable text that have to be pressed in a specific order > > when you have just been woken up and are disoriented, cant find your > > glasses and your grumpy, just woken up better half is berating you for > > the umpteenth time for not being able to turn off the alarm :( > > The digits could be made bigger. This would be a big help > > I considered it a feature that until I the digits are blurred means I am > not awaken, ie alarm should still play. But the story is of course > different when you do not want to wake up the rest of the house. > Yes, I am an early riser in a house of late risers - what a pain but at least I get the place to myself - as long as I am quiet Everyones use case is different! The trick is getting it flexible enough to satisfy the majority ;) BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
William Kenworthy writes: > On Wed, 2009-10-28 at 22:39 +0100, Petr Vanek wrote: >> On Wed, 28 Oct 2009 21:32:03 + >> Al Johnson (AJ) wrote: >> >> >On Wednesday 28 October 2009, Petr Vanek wrote: >> >> >I meant that it ought to behave that way in future, not that it >> >> >would in the current version. I don't care if the phone goes to >> >> >sleep during the snooze interval so long as the alarm goes off >> >> >again five minutes later! >> >> > >> >> :) sure, now it didn't wake up itself and me neither :)) >> >> >> >> what if the unlocking 1-2-3-4 pattern is configurable, how would >> >> snooze get in then? >> > >> >How about puzzle to stop the sound, display the message and show the >> >ACK slider? If you don't ACK then there's another alarm after the >> >snooze interval. When I implement snoozing (repeating the alarm if not ACK) I consider easy turning off the alarm for the first time (most probably a button), and a puzzle in a snoozed mode (all but first time). >> >> that would do just fine for me, just some people wanted to get rid of >> the puzzle... >> >> Petr >> > > Even without the puzzel, you still need an acknowledge button for the > alarm so thats not a problem. The problem with the puzzel is 4 buttons > with small, unreadable text that have to be pressed in a specific order > when you have just been woken up and are disoriented, cant find your > glasses and your grumpy, just woken up better half is berating you for > the umpteenth time for not being able to turn off the alarm :( The digits could be made bigger. I considered it a feature that until I the digits are blurred means I am not awaken, ie alarm should still play. But the story is of course different when you do not want to wake up the rest of the house. > > BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wed, 2009-10-28 at 22:39 +0100, Petr Vanek wrote: > On Wed, 28 Oct 2009 21:32:03 + > Al Johnson (AJ) wrote: > > >On Wednesday 28 October 2009, Petr Vanek wrote: > >> >I meant that it ought to behave that way in future, not that it > >> >would in the current version. I don't care if the phone goes to > >> >sleep during the snooze interval so long as the alarm goes off > >> >again five minutes later! > >> > > >> :) sure, now it didn't wake up itself and me neither :)) > >> > >> what if the unlocking 1-2-3-4 pattern is configurable, how would > >> snooze get in then? > > > >How about puzzle to stop the sound, display the message and show the > >ACK slider? If you don't ACK then there's another alarm after the > >snooze interval. > > that would do just fine for me, just some people wanted to get rid of > the puzzle... > > Petr > Even without the puzzel, you still need an acknowledge button for the alarm so thats not a problem. The problem with the puzzel is 4 buttons with small, unreadable text that have to be pressed in a specific order when you have just been woken up and are disoriented, cant find your glasses and your grumpy, just woken up better half is berating you for the umpteenth time for not being able to turn off the alarm :( BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wed, Oct 28, 2009 at 2:39 PM, Petr Vanek wrote: > that would do just fine for me, just some people wanted to get rid of > the puzzle... should be a conf option. i for one like the puzzle ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wed, 28 Oct 2009 21:32:03 + Al Johnson (AJ) wrote: >On Wednesday 28 October 2009, Petr Vanek wrote: >> >I meant that it ought to behave that way in future, not that it >> >would in the current version. I don't care if the phone goes to >> >sleep during the snooze interval so long as the alarm goes off >> >again five minutes later! >> > >> :) sure, now it didn't wake up itself and me neither :)) >> >> what if the unlocking 1-2-3-4 pattern is configurable, how would >> snooze get in then? > >How about puzzle to stop the sound, display the message and show the >ACK slider? If you don't ACK then there's another alarm after the >snooze interval. that would do just fine for me, just some people wanted to get rid of the puzzle... Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wednesday 28 October 2009, Petr Vanek wrote: > >I meant that it ought to behave that way in future, not that it would > >in the current version. I don't care if the phone goes to sleep during > >the snooze interval so long as the alarm goes off again five minutes > >later! > > > :) sure, now it didn't wake up itself and me neither :)) > > what if the unlocking 1-2-3-4 pattern is configurable, how would snooze > get in then? How about puzzle to stop the sound, display the message and show the ACK slider? If you don't ACK then there's another alarm after the snooze interval. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
>I meant that it ought to behave that way in future, not that it would >in the current version. I don't care if the phone goes to sleep during >the snooze interval so long as the alarm goes off again five minutes >later! :) sure, now it didn't wake up itself and me neither :)) what if the unlocking 1-2-3-4 pattern is configurable, how would snooze get in then? Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wednesday 28 October 2009, Petr Vanek wrote: > >> don't forget to fit in the "Snooze" slider too, please :) > > > >It shouldn't need a separate slider. If you turn off but don't ACK it > >should be equivalent to a snooze. > > tried that this morning and no snooze, i mean i could snooze but > the phone went to sleep :) I meant that it ought to behave that way in future, not that it would in the current version. I don't care if the phone goes to sleep during the snooze interval so long as the alarm goes off again five minutes later! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
>> don't forget to fit in the "Snooze" slider too, please :) > >It shouldn't need a separate slider. If you turn off but don't ACK it >should be equivalent to a snooze. tried that this morning and no snooze, i mean i could snooze but the phone went to sleep :) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
jeremy jozwik writes: > 2009/10/25 Łukasz Pankowski : >> Hi >> >> I have just released ffalarms 0.3, it adds recurring alarms, please test >> it before depending on it. >> >> For me the most missing feature now is being able to edit the alarms and >> postponing in the acknowledge window. Ideas and comments are welcome. > > ive just thought of something. instead of using the enlighten > fullscreen mode. which kills the UI if the keyboard is set to none. is > there any way you could borrow the render-above-all bit of code from > literki? if you run literki you can position the keyboard above the > menu bar, thus emulating the fullscreen mode. > > would make for a much more stable package while we wait for a working > enlightenment. Hi, I will try to look into this issue looking at literki, if it will be easy to workaround I will add it as an option in config file (hope to look at before the next release). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Tuesday 27 October 2009, Petr Vanek wrote:
> >>> ||
> >>> | Message|
> >>> |
> >>> |
> >>> | [Turn off slider] |
> >>> | [ACK slider] (*) |
> >>> |
> >>> | {Close button} (*) |
> >>> |
> >>> ||
>
> don't forget to fit in the "Snooze" slider too, please :)
It shouldn't need a separate slider. If you turn off but don't ACK it should
be equivalent to a snooze.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
>Again, perhaps something thats suited to a config setting. When I set + configurable unlock shr-today upon wake up :) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
>>>
>>> ||
>>> | Message|
>>> ||
>>> ||
>>> | [Turn off slider] |
>>> | [ACK slider] (*) |
>>> ||
>>> | {Close button} (*) |
>>> ||
>>> ||
don't forget to fit in the "Snooze" slider too, please :)
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Tue, 2009-10-27 at 08:09 +0100, Richy wrote: > > One thing I have noticed with 0.2 is that the alarm isn't very loud and > > the FR seems to go to sleep before the alarm gets loud enough to hear - > > its inaudible except when there is nearly no environment noise. 0.1 > > seems to get a lot louder, and faster. Something to think of for your > > todo list is checking the profile setting before sounding the alarm - an > > alarm going off in a meeting is just as disruptive as a phone ring. > > > I disagree. There is nothing worse than sleeping in, because you > forgot to put your phone back into "ring"-mode. Also, I don't wont to > be woken up during night from calls and sms. > > Richard > Again, perhaps something thats suited to a config setting. When I set a phone to be silent, I want it/need it to be totally silent - something important might depend on it. The treo650 has the best solution Ive ever seen to this :) In shr its possible to set up any of the 4 profiles - perhaps add another thats "All silent", or have a checkbox to set it to phone or all. Thinking on it, its not really ffalarms responsibility, but squarely a profile setting for a master audio kill switch. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
> One thing I have noticed with 0.2 is that the alarm isn't very loud and > the FR seems to go to sleep before the alarm gets loud enough to hear - > its inaudible except when there is nearly no environment noise. 0.1 > seems to get a lot louder, and faster. Something to think of for your > todo list is checking the profile setting before sounding the alarm - an > alarm going off in a meeting is just as disruptive as a phone ring. I disagree. There is nothing worse than sleeping in, because you forgot to put your phone back into "ring"-mode. Also, I don't wont to be woken up during night from calls and sms. Richard ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Mon, 2009-10-26 at 22:48 +0100, Łukasz Pankowski wrote:
> William Kenworthy writes:
>
> > Can I add to that request? - Ive just upgraded to ver2 and forgot I had
> > knobbled the puzzel on the old version ... so once .3 hits the shr feeds
> > I will have to spend more time decompiling, figuring out how it works,
> > kill the puzzel then compile it back up again - painful way to fix what
> > is to me a major usability problem (I cant see the numbers without
> > glasses, and of course I am not wearing glasses when the alarm goes off
> > in the morning :)
> >
> > Perhaps, make it a configuration option would make good sense then you
> > can continue torturing those poor souls who like it :)
>
> :))
>
> >
> > Its quite a good, reliable program, far better than the basic elementary
> > alarm and I use it most days more than once. Good work.
>
> Thanks. Would turning off the alarm with a slider (please read my reply
> to Marcel for details) be fine for you?
>
> I have done the one line hack for you (as I know the code :)) -- it
> makes every of four buttons immediately solve the puzzle. Attached
> ffalarms.edj, put it as /usr/share/ffalarms/ffalarms.edj in your neo and
> it should work with ffalarms 0.2.4 and ffalarms 0.3 (not much tested :)).
>
> The change was:
>
> Index: ffalarms.edc
> ===
> --- ffalarms.edc (revision 60)
> +++ ffalarms.edc (working copy)
> @@ -523,7 +523,7 @@
> script {
> new s[2];
> getsarg(1, s, 2);
> -clicked(atoi(s));
> +emit("solved", "");
> }
> }
> }
>
>
Hi Lucasz, thanks for that - pretty similar to what I have done.
I have a particular HATRED of sliders - particularly the way shr uses
them - they take several swipes before they work and require careful
placement of the finger to "grab" them and move. To me a slider is for
analog values - buttons are for on/off.
I realise you are worried about the alarm being accidentally
acknowledged - never found that to be a problem because I usually use
something like shr-today so the alarm comes up with the screen protected
(and shr today already uses a slider - gr - so then there are
serial, multiple sliders to deal with - :) Even when I
dont use the today screen, there doesnt seem to be any problem when
carrying the phone in a pocket. Looks to me like a problem that doesn't
need solving. Note that the alarms on the other phones I have at home
dont have such devices so I question whether they are necessary at all.
This why a "disable/enable" in the settings file might be the easiest
way to deal with this.
One thing I have noticed with 0.2 is that the alarm isn't very loud and
the FR seems to go to sleep before the alarm gets loud enough to hear -
its inaudible except when there is nearly no environment noise. 0.1
seems to get a lot louder, and faster. Something to think of for your
todo list is checking the profile setting before sounding the alarm - an
alarm going off in a meeting is just as disruptive as a phone ring.
0.3 is coming to shr-u soon so I'll see if that's any better in the
sleep department then.
Billk
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Marcel writes:
> Am Montag, den 26.10.2009, 23:09 +0100 schrieb Łukasz Pankowski:
>> Marcel writes:
>>
>> > Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
>> >> Marcel writes:
>> >>
>> >> > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
>> >> >> Hi
>> >> >>
>> >> >> I have just released ffalarms 0.3, it adds recurring alarms, please
>> >> >> test
>> >> >> it before depending on it.
>> >> >>
>> >> >> For me the most missing feature now is being able to edit the alarms
>> >> >> and
>> >> >> postponing in the acknowledge window. Ideas and comments are welcome.
>> >> >>
>> >> >>
>> >> >> Notes:
>> >> >> - add support for recurring alarms, attaching messages to alarms, and
>> >> >> choosing alarm date from a calendar
>> >> >>
>> >> >> - add configuration option for alarm volume, alarm_script and
>> >> >> alsa_state
>> >> >>
>> >> >> Download:
>> >> >> http://projects.openmoko.org/frs/?group_id=260&release_id=580
>> >> >> (I also provide libical, in case it is not in your distro)
>> >> >
>> >> > Yay! I use ffalarms mostly more than once a day and it's just great to
>> >> > have it. Thanks for your work! :)
>> >> >
>> >> > Although I know you're not too fond of it - what about making it
>> >> > possible to simply turn an alarm off without that puzzle? It's quite
>> >> > annoying me from time to time, especially when I'm just finishing it
>> >> > when its regenerating and I need to hear that alarm once again...
>> >>
>> >> Yes I am quite attached to the puzzle it is there since the beginning
>> >> :). BUT: it is there for the particular purpose to avoid accidental
>> >> turning off of the alarm. And now Elementary [1] comes with the widget
>> >> that plays that rule well enough -- slider -- without the annoyance of
>> >> the puzzle (yes, I say it too).
>> >>
>> >> v0.3 adds the acknowledge window that displays after the puzzle, and
>> >> consider merging the two into one acknowledge window with two sliders:
>> >>
>> >> * first one to turn off the alarm sound (when it is loud you want to
>> >> turn of this first and not read the message), then
>> >>
>> >> * the second to acknowledge you read the alarm message (this will appear
>> >> if you slide the first one).
>> >>
>> >> What do you think of such interface?
>> >
>> > The slider is a good idea, already works fine in shr-today. (Which
>> > didn't survive my scaling experiments very well...)
>> > I'm not sure if two windows for turning off the alarm and then
>> > acknowledging the alarm messages are nessecary. Couldn't we have one
>> > slider in the upper third of a window to turn off the alarm (maybe even
>> > red?! I fear that might be hardwired to the theme...), the alarm message
>> > in the middle and the acknowledgement switch for that on the bottom. So
>> > one could if there's no mesage or its trivial just slide the lower
>> > slider and both the message window and the alarm disappear/stop without
>> > having to slide twice. What about that? :)
>>
>> I was saying about one window:
>>
>> ||
>> | Message|
>> ||
>> ||
>> | [Turn off slider] |
>> | [ACK slider] (*) |
>> ||
>> | {Close button} (*) |
>> ||
>> ||
>>
>> where (*) are hidden until you slide the turn off slider.
>>
>> The other idea which might be better is to use single slider which you
>> slide right to turn off the alarm and slide back to ACK it.
>>
>> |--|
>> | Message |
>> | |
>> | |
>> | [Turn off=> / <= ACK slider] |
>> | {Close button} (*) |
>> | |
>> |--|
>>
>> I think it is even simpler and not that annoying, what do you think?
>> (I hope you like it).
>>
>> In your idea I would be afraid I can use the wrong slider (may be would
>> require the ACK slider to be normal size (to make the difference
>> obvious) which would be less finger friendly), but would have to test it
>> on myself see if it is a real or imaginary problem.
>
> First approach: I'd have placed one slider at the top and one at the
> bottom of the window, with the alarm message (in case such exists) in
> between them. Isn't that enough to differentiate them?
>
> Would the second approach require one to "drop" the slider once to make
> E recognize that it has been slided? Or could one slide it right and
> back in one movement? I guess the former is the case... I'd still prefer
> some approach that allows getting rid of the window with just one
> movement/click. And what I see right now: Do you plan to make another
> button to close the window visible after sliding ACK? That seems too
> complicated to me.
Yes, it would require to "drop" the slider, (2) below is simpler.
1) Your interface is with two sliders and no buttons.
That may be a good aproach, I wi
Re: ffalarms 0.3 -- recurring alarms
Am Montag, den 26.10.2009, 23:09 +0100 schrieb Łukasz Pankowski:
> Marcel writes:
>
> > Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
> >> Marcel writes:
> >>
> >> > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
> >> >> Hi
> >> >>
> >> >> I have just released ffalarms 0.3, it adds recurring alarms, please test
> >> >> it before depending on it.
> >> >>
> >> >> For me the most missing feature now is being able to edit the alarms and
> >> >> postponing in the acknowledge window. Ideas and comments are welcome.
> >> >>
> >> >>
> >> >> Notes:
> >> >> - add support for recurring alarms, attaching messages to alarms, and
> >> >> choosing alarm date from a calendar
> >> >>
> >> >> - add configuration option for alarm volume, alarm_script and alsa_state
> >> >>
> >> >> Download:
> >> >> http://projects.openmoko.org/frs/?group_id=260&release_id=580
> >> >> (I also provide libical, in case it is not in your distro)
> >> >
> >> > Yay! I use ffalarms mostly more than once a day and it's just great to
> >> > have it. Thanks for your work! :)
> >> >
> >> > Although I know you're not too fond of it - what about making it
> >> > possible to simply turn an alarm off without that puzzle? It's quite
> >> > annoying me from time to time, especially when I'm just finishing it
> >> > when its regenerating and I need to hear that alarm once again...
> >>
> >> Yes I am quite attached to the puzzle it is there since the beginning
> >> :). BUT: it is there for the particular purpose to avoid accidental
> >> turning off of the alarm. And now Elementary [1] comes with the widget
> >> that plays that rule well enough -- slider -- without the annoyance of
> >> the puzzle (yes, I say it too).
> >>
> >> v0.3 adds the acknowledge window that displays after the puzzle, and
> >> consider merging the two into one acknowledge window with two sliders:
> >>
> >> * first one to turn off the alarm sound (when it is loud you want to
> >> turn of this first and not read the message), then
> >>
> >> * the second to acknowledge you read the alarm message (this will appear
> >> if you slide the first one).
> >>
> >> What do you think of such interface?
> >
> > The slider is a good idea, already works fine in shr-today. (Which
> > didn't survive my scaling experiments very well...)
> > I'm not sure if two windows for turning off the alarm and then
> > acknowledging the alarm messages are nessecary. Couldn't we have one
> > slider in the upper third of a window to turn off the alarm (maybe even
> > red?! I fear that might be hardwired to the theme...), the alarm message
> > in the middle and the acknowledgement switch for that on the bottom. So
> > one could if there's no mesage or its trivial just slide the lower
> > slider and both the message window and the alarm disappear/stop without
> > having to slide twice. What about that? :)
>
> I was saying about one window:
>
> ||
> | Message|
> ||
> ||
> | [Turn off slider] |
> | [ACK slider] (*) |
> ||
> | {Close button} (*) |
> ||
> ||
>
> where (*) are hidden until you slide the turn off slider.
>
> The other idea which might be better is to use single slider which you
> slide right to turn off the alarm and slide back to ACK it.
>
> |--|
> | Message |
> | |
> | |
> | [Turn off=> / <= ACK slider] |
> | {Close button} (*) |
> | |
> |--|
>
> I think it is even simpler and not that annoying, what do you think?
> (I hope you like it).
>
> In your idea I would be afraid I can use the wrong slider (may be would
> require the ACK slider to be normal size (to make the difference
> obvious) which would be less finger friendly), but would have to test it
> on myself see if it is a real or imaginary problem.
First approach: I'd have placed one slider at the top and one at the
bottom of the window, with the alarm message (in case such exists) in
between them. Isn't that enough to differentiate them?
Would the second approach require one to "drop" the slider once to make
E recognize that it has been slided? Or could one slide it right and
back in one movement? I guess the former is the case... I'd still prefer
some approach that allows getting rid of the window with just one
movement/click. And what I see right now: Do you plan to make another
button to close the window visible after sliding ACK? That seems too
complicated to me.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Marcel writes:
> Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
>> Marcel writes:
>>
>> > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
>> >> Hi
>> >>
>> >> I have just released ffalarms 0.3, it adds recurring alarms, please test
>> >> it before depending on it.
>> >>
>> >> For me the most missing feature now is being able to edit the alarms and
>> >> postponing in the acknowledge window. Ideas and comments are welcome.
>> >>
>> >>
>> >> Notes:
>> >> - add support for recurring alarms, attaching messages to alarms, and
>> >> choosing alarm date from a calendar
>> >>
>> >> - add configuration option for alarm volume, alarm_script and alsa_state
>> >>
>> >> Download:
>> >> http://projects.openmoko.org/frs/?group_id=260&release_id=580
>> >> (I also provide libical, in case it is not in your distro)
>> >
>> > Yay! I use ffalarms mostly more than once a day and it's just great to
>> > have it. Thanks for your work! :)
>> >
>> > Although I know you're not too fond of it - what about making it
>> > possible to simply turn an alarm off without that puzzle? It's quite
>> > annoying me from time to time, especially when I'm just finishing it
>> > when its regenerating and I need to hear that alarm once again...
>>
>> Yes I am quite attached to the puzzle it is there since the beginning
>> :). BUT: it is there for the particular purpose to avoid accidental
>> turning off of the alarm. And now Elementary [1] comes with the widget
>> that plays that rule well enough -- slider -- without the annoyance of
>> the puzzle (yes, I say it too).
>>
>> v0.3 adds the acknowledge window that displays after the puzzle, and
>> consider merging the two into one acknowledge window with two sliders:
>>
>> * first one to turn off the alarm sound (when it is loud you want to
>> turn of this first and not read the message), then
>>
>> * the second to acknowledge you read the alarm message (this will appear
>> if you slide the first one).
>>
>> What do you think of such interface?
>
> The slider is a good idea, already works fine in shr-today. (Which
> didn't survive my scaling experiments very well...)
> I'm not sure if two windows for turning off the alarm and then
> acknowledging the alarm messages are nessecary. Couldn't we have one
> slider in the upper third of a window to turn off the alarm (maybe even
> red?! I fear that might be hardwired to the theme...), the alarm message
> in the middle and the acknowledgement switch for that on the bottom. So
> one could if there's no mesage or its trivial just slide the lower
> slider and both the message window and the alarm disappear/stop without
> having to slide twice. What about that? :)
I was saying about one window:
||
| Message|
||
||
| [Turn off slider] |
| [ACK slider] (*) |
||
| {Close button} (*) |
||
||
where (*) are hidden until you slide the turn off slider.
The other idea which might be better is to use single slider which you
slide right to turn off the alarm and slide back to ACK it.
|--|
| Message |
| |
| |
| [Turn off=> / <= ACK slider] |
| {Close button} (*) |
| |
|--|
I think it is even simpler and not that annoying, what do you think?
(I hope you like it).
In your idea I would be afraid I can use the wrong slider (may be would
require the ACK slider to be normal size (to make the difference
obvious) which would be less finger friendly), but would have to test it
on myself see if it is a real or imaginary problem.
>
> --
> Marcel
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski: > Marcel writes: > > > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: > >> Hi > >> > >> I have just released ffalarms 0.3, it adds recurring alarms, please test > >> it before depending on it. > >> > >> For me the most missing feature now is being able to edit the alarms and > >> postponing in the acknowledge window. Ideas and comments are welcome. > >> > >> > >> Notes: > >> - add support for recurring alarms, attaching messages to alarms, and > >> choosing alarm date from a calendar > >> > >> - add configuration option for alarm volume, alarm_script and alsa_state > >> > >> Download: > >> http://projects.openmoko.org/frs/?group_id=260&release_id=580 > >> (I also provide libical, in case it is not in your distro) > > > > Yay! I use ffalarms mostly more than once a day and it's just great to > > have it. Thanks for your work! :) > > > > Although I know you're not too fond of it - what about making it > > possible to simply turn an alarm off without that puzzle? It's quite > > annoying me from time to time, especially when I'm just finishing it > > when its regenerating and I need to hear that alarm once again... > > Yes I am quite attached to the puzzle it is there since the beginning > :). BUT: it is there for the particular purpose to avoid accidental > turning off of the alarm. And now Elementary [1] comes with the widget > that plays that rule well enough -- slider -- without the annoyance of > the puzzle (yes, I say it too). > > v0.3 adds the acknowledge window that displays after the puzzle, and > consider merging the two into one acknowledge window with two sliders: > > * first one to turn off the alarm sound (when it is loud you want to > turn of this first and not read the message), then > > * the second to acknowledge you read the alarm message (this will appear > if you slide the first one). > > What do you think of such interface? The slider is a good idea, already works fine in shr-today. (Which didn't survive my scaling experiments very well...) I'm not sure if two windows for turning off the alarm and then acknowledging the alarm messages are nessecary. Couldn't we have one slider in the upper third of a window to turn off the alarm (maybe even red?! I fear that might be hardwired to the theme...), the alarm message in the middle and the acknowledgement switch for that on the bottom. So one could if there's no mesage or its trivial just slide the lower slider and both the message window and the alarm disappear/stop without having to slide twice. What about that? :) -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Marcel writes: > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: >> Hi >> >> I have just released ffalarms 0.3, it adds recurring alarms, please test >> it before depending on it. >> >> For me the most missing feature now is being able to edit the alarms and >> postponing in the acknowledge window. Ideas and comments are welcome. >> >> >> Notes: >> - add support for recurring alarms, attaching messages to alarms, and >> choosing alarm date from a calendar >> >> - add configuration option for alarm volume, alarm_script and alsa_state >> >> Download: >> http://projects.openmoko.org/frs/?group_id=260&release_id=580 >> (I also provide libical, in case it is not in your distro) > > Yay! I use ffalarms mostly more than once a day and it's just great to > have it. Thanks for your work! :) > > Although I know you're not too fond of it - what about making it > possible to simply turn an alarm off without that puzzle? It's quite > annoying me from time to time, especially when I'm just finishing it > when its regenerating and I need to hear that alarm once again... Yes I am quite attached to the puzzle it is there since the beginning :). BUT: it is there for the particular purpose to avoid accidental turning off of the alarm. And now Elementary [1] comes with the widget that plays that rule well enough -- slider -- without the annoyance of the puzzle (yes, I say it too). v0.3 adds the acknowledge window that displays after the puzzle, and consider merging the two into one acknowledge window with two sliders: * first one to turn off the alarm sound (when it is loud you want to turn of this first and not read the message), then * the second to acknowledge you read the alarm message (this will appear if you slide the first one). What do you think of such interface? [1] ffalarms was up to 0.2.2 an Edje interface because this way it was running well on 2008.12, which was much used at the beginning of 2009. Łukasz > > -- > Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
lukp...@o2.pl (Łukasz Pankowski) writes: > Jeffrey Ratcliffe writes: > >> On Mon, Oct 26, 2009 at 02:07:32AM +0100, Łukasz Pankowski wrote: >>> - add support for recurring alarms, attaching messages to alarms, and >>> choosing alarm date from a calendar >>> >>> - add configuration option for alarm volume, alarm_script and alsa_state >> >> Brilliant - I can almost throw my old phone away now. I'm just missing >> one last feature - I would love an option to vibrate instead of ring - >> ringing wakes the rest of my family, whilst vibrate just wakes me. :-) > > I may add vibration support in the next version. For now you can > do that by setting fancy alarm player in ~/.ffalarmsrc: > > [alarm] > volume=-1 > player=sh -c 'for x in `seq 1 10`; do kill -CHLD "$PPID" || exit; mdbus -s > org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator > org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10; done' Of course you can do it simpler using repeat instead of shell for loop, than this kill-hack is not needed: [alarm] repeat=10 player=sh -c 'mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10' volume=-1 > > the kill command is to test the parent process is still running as > killing the this sh process with sig TERM for some reason does not work > (may be you now a better way to do that?) > > for explanation of "volume=-1" see [1] > > One way to support it would be to make ffalarms aware of phone profiles, > so that if the profile is Silent or Vibrate than it Vibrates instead of > playing the alarm (and may be start playing after a minute). > > [1] http://ffalarms.projects.openmoko.org/#configuration > >> >> Regards >> >> Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Jeffrey Ratcliffe writes: > On Mon, Oct 26, 2009 at 02:07:32AM +0100, Łukasz Pankowski wrote: >> - add support for recurring alarms, attaching messages to alarms, and >> choosing alarm date from a calendar >> >> - add configuration option for alarm volume, alarm_script and alsa_state > > Brilliant - I can almost throw my old phone away now. I'm just missing > one last feature - I would love an option to vibrate instead of ring - > ringing wakes the rest of my family, whilst vibrate just wakes me. :-) I may add vibration support in the next version. For now you can do that by setting fancy alarm player in ~/.ffalarmsrc: [alarm] volume=-1 player=sh -c 'for x in `seq 1 10`; do kill -CHLD "$PPID" || exit; mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10; done' the kill command is to test the parent process is still running as killing the this sh process with sig TERM for some reason does not work (may be you now a better way to do that?) for explanation of "volume=-1" see [1] One way to support it would be to make ffalarms aware of phone profiles, so that if the profile is Silent or Vibrate than it Vibrates instead of playing the alarm (and may be start playing after a minute). [1] http://ffalarms.projects.openmoko.org/#configuration > > Regards > > Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Al Johnson writes: > On Monday 26 October 2009, Christ van Willegen wrote: >> Dzen dobry Łukasz, >> >> I've noticed that when the alarm sounds, the FR turns off after some >> time. I've never needed to depend on the alarm, but it's not nice when >> you alarm clock itself falls asleep ;-) >> >> Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for that. > > I would prefer it to go to sleep again and try later. I don't want my alarm > clock to run its battery flat because I slept through it, or my phone too run > flat because I forgot to cancel an alarm. It should not suspend until it plays the alarm to the end, that is and should be the proper behavior. (You can configure the number of repetitions if you think it plays to long: in default configuration it is around 5 minutes). On the other hand it is true that if you do not acknowledge the alarm it currently just suspends and does nothing with it. It could retry after let say 10 minutes (which would be configurable) and try it let say five times and only then give up, that is a reasonable feature request. I will add it to my TODO list. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Christ van Willegen writes: > Dzen dobry Łukasz, > > I've noticed that when the alarm sounds, the FR turns off after some > time. I've never needed to depend on the alarm, but it's not nice when > you alarm clock itself falls asleep ;-) > > Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for > that. Dzień dobry Christ That is strange, ffalarms (since 0.2.3) does request CPU resource, that is before starting the alarm you should observe CPU is not ,,enabled'' (unless other program requested it): $ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState CPU 2>/dev/null False If you start an alarm, for example with: $ ffalarms -s now you should observe that ffalarms requested CPU resource $ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState CPU 2>/dev/null True and so the system should not suspend. Does it give false for you? Łukasz > > Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
2009/10/25 Łukasz Pankowski : > Hi > > I have just released ffalarms 0.3, it adds recurring alarms, please test > it before depending on it. > > For me the most missing feature now is being able to edit the alarms and > postponing in the acknowledge window. Ideas and comments are welcome. ive just thought of something. instead of using the enlighten fullscreen mode. which kills the UI if the keyboard is set to none. is there any way you could borrow the render-above-all bit of code from literki? if you run literki you can position the keyboard above the menu bar, thus emulating the fullscreen mode. would make for a much more stable package while we wait for a working enlightenment. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On 26 Oct 2009, at 08:47, Christ van Willegen wrote: > ... > I've noticed that when the alarm sounds, the FR turns off after some > time. I've never needed to depend on the alarm, but it's not nice when > you alarm clock itself falls asleep ;-) > > Is that fixable (on SHR-U)? Dear Boss, This is why I'm late for work. Clearly this morning's tardiness is upstream's fault. Please file a bug with them. I am marking your complaint about my late arrival in the office as "CAN'T FIX". Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Mon, 2009-10-26 at 12:40 +0100, Marcel wrote: > Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: > > Hi > > > > I have just released ffalarms 0.3, it adds recurring alarms, please test > > it before depending on it. > > > > For me the most missing feature now is being able to edit the alarms and > > postponing in the acknowledge window. Ideas and comments are welcome. > > > > > > Notes: > > - add support for recurring alarms, attaching messages to alarms, and > > choosing alarm date from a calendar > > > > - add configuration option for alarm volume, alarm_script and alsa_state > > > > Download: > > http://projects.openmoko.org/frs/?group_id=260&release_id=580 > > (I also provide libical, in case it is not in your distro) > > Yay! I use ffalarms mostly more than once a day and it's just great to > have it. Thanks for your work! :) > > Although I know you're not too fond of it - what about making it > possible to simply turn an alarm off without that puzzle? It's quite > annoying me from time to time, especially when I'm just finishing it > when its regenerating and I need to hear that alarm once again... > > -- > Marcel > > Can I add to that request? - Ive just upgraded to ver2 and forgot I had knobbled the puzzel on the old version ... so once .3 hits the shr feeds I will have to spend more time decompiling, figuring out how it works, kill the puzzel then compile it back up again - painful way to fix what is to me a major usability problem (I cant see the numbers without glasses, and of course I am not wearing glasses when the alarm goes off in the morning :) Perhaps, make it a configuration option would make good sense then you can continue torturing those poor souls who like it :) Its quite a good, reliable program, far better than the basic elementary alarm and I use it most days more than once. Good work. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: > Hi > > I have just released ffalarms 0.3, it adds recurring alarms, please test > it before depending on it. > > For me the most missing feature now is being able to edit the alarms and > postponing in the acknowledge window. Ideas and comments are welcome. > > > Notes: > - add support for recurring alarms, attaching messages to alarms, and > choosing alarm date from a calendar > > - add configuration option for alarm volume, alarm_script and alsa_state > > Download: > http://projects.openmoko.org/frs/?group_id=260&release_id=580 > (I also provide libical, in case it is not in your distro) Yay! I use ffalarms mostly more than once a day and it's just great to have it. Thanks for your work! :) Although I know you're not too fond of it - what about making it possible to simply turn an alarm off without that puzzle? It's quite annoying me from time to time, especially when I'm just finishing it when its regenerating and I need to hear that alarm once again... -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Mon, Oct 26, 2009 at 02:07:32AM +0100, Łukasz Pankowski wrote: > - add support for recurring alarms, attaching messages to alarms, and > choosing alarm date from a calendar > > - add configuration option for alarm volume, alarm_script and alsa_state Brilliant - I can almost throw my old phone away now. I'm just missing one last feature - I would love an option to vibrate instead of ring - ringing wakes the rest of my family, whilst vibrate just wakes me. :-) Regards Jeff signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Monday 26 October 2009, Christ van Willegen wrote: > Dzen dobry Łukasz, > > I've noticed that when the alarm sounds, the FR turns off after some > time. I've never needed to depend on the alarm, but it's not nice when > you alarm clock itself falls asleep ;-) > > Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for that. I would prefer it to go to sleep again and try later. I don't want my alarm clock to run its battery flat because I slept through it, or my phone too run flat because I forgot to cancel an alarm. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Dzen dobry Łukasz, I've noticed that when the alarm sounds, the FR turns off after some time. I've never needed to depend on the alarm, but it's not nice when you alarm clock itself falls asleep ;-) Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for that. Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
2009/10/25 Łukasz Pankowski : > Hi > > I have just released ffalarms 0.3, it adds recurring alarms, please test > it before depending on it. fantastic! more then willing to test this. thanks. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ffalarms 0.3 -- recurring alarms
Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. Notes: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Download: http://projects.openmoko.org/frs/?group_id=260&release_id=580 (I also provide libical, in case it is not in your distro) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
