Re: N900 clock replacement [continued]
 

Ok, I will put it to cssu devel.

Re: N900 clock replacement [continued]
 

I am also running replacement worldclock on all my devices with no issues to my knowledge. IMO it has been very stable for sometime.

Re: N900 clock replacement [continued]
 

Pali, keep in mind that the sources in cssu gitorious represent an up-to-date version of the worldclock without date support. As that's how I always intended the first cssu release to be...

Re: N900 clock replacement [continued]
 

Now, any reason why version *with* date support couldn't arrive into CSSU, if they decided to do so, after all? Maybe reasons for absurd'ish silly splitting request vanished, too? ;)

Now, even if not, I really *do* hope, that they will include it the way, that won't require mumbo-jumbo rituals with altering dependencies, to allow (re)installation of version with date support. mp-fremantle-community-pr, I'm looking at you...

/Estel

Re: N900 clock replacement [continued]
 

Ade, can you push last version of clock-ui to gitorious, also with date support? cssu-devel is for unstable apps, where development should happen...

Re: N900 clock replacement [continued]
 

I thought I'd never see this happening....

Re: N900 clock replacement [continued]
 

Finally! :)

Using it since ages (date support) without any bad impact. But this has been said often enough.

Thanks to ade and pali (this can not be said often enough)!

Re: N900 clock replacement [continued]
 

I had only one problem with clock-ui (a long time ago, forgot to report it). I set the alarm to a day which has already passed. There's no "no alarms" text but no alarms are displayed (provided there are no future alarms)

Re: N900 clock replacement [continued]
 

In the latest version, you cannot select a date in the past (done button is grayed out).
But you still can select the current date with a time in the past, and you can reactivate a past (date) alarm. In these cases the alarm just dissapears. I could try to prevent that also.

@Pali: I will sort out the code for date support and put it in cssu gitorious soon.

Edit: all code is updated now

Re: N900 clock replacement [continued]
 

Ok, I will upload package to cssu-devel after you push changes to gitorious.

Re: N900 clock replacement [continued]
 

i haven't had a chance to try the app yet, but I would like to thank ade and pali for their positive conduct. as stated elsewhere, i'm sick of the childish behaviour and lack of respect shown in the popular threads i've read lately.

Re: N900 clock replacement [continued]
 

@ade
Are You referring to my post #396? I thought that You reproduced it, as in post #397.
Because clock replacement is going to the masses (repositories - finally!) I think it would be great to have this bug sorted too.

Re: N900 clock replacement [continued]
 

I would not call cssu-devel the masses. That's not what cssu-devel is created for at least...

You can still give it a second try: mention the device settings, the excact actions and exact reproducable results. I can not do anything if I cannot reproduce it.

Re: N900 clock replacement [continued]
 

Well if it helps, I cannot reproduce any issue in UK region settings.

Is there a way to stop the items on main screen being highlighted if you drag over them in portrait mode? It's not really an issue just doesn't look right.

Re: N900 clock replacement [continued]
 

Just tried to reproduce it once again and... I can`t.
Maybe it was some misbehave of my N900 or T8.2 fixed something, I don`t know. Tried to trigger this bug in many different ways but all is fine. Strange.

Re: N900 clock replacement [continued]
 

@sixwheeledbeast: that's a sort of default behaviour when creating it this way. OMP acts the same way in portrait mode.

@artpra
Thanks for retesting anyway

Re: N900 clock replacement [continued]
 

Version from git repo pushed to cssu-devel. I will be offline in next week. Have fun.

Re: N900 clock replacement [continued]
 

http://www.nomi.nl/images/upload/champagne%5B2%5D.jpg
ten chars

Re: N900 clock replacement [continued]
 

Hi
recently installed the replacement and I cannot set an alarm for today for example if I set for 3 hour from now it says time left 0 hs and it doest show the alarm
It´s there a way to solve it?

Re: N900 clock replacement [continued]
 

Did you explicitly set a date, or only set the time?
Is it reproducable and what device/language settings are you using?

Re: N900 clock replacement [continued]
 

Installed the clock ui in repos.
I set both of them date and time and my locale is spanish latin american and keybord us
It´s happening every time I´ve tried

EDit: except now maybe after 2 reboots I was able to set the alarm

Re: N900 clock replacement [continued]
 

I will do some tests later this day with this settings and the cssu-devel build and report back.

And remember: as long as you don't explicitly set a date (so only set the time), it should always work the "stock way", with no relation to any date.

Re: N900 clock replacement [continued]
 

guilledoc, I did find issues when using the am/pm timeformat in Spanish. I assume you have this timeformat, else I might not have tackled your issue :)

As I have no access to cssu-devel, I have updated the downloads in the openingspost (I was to lazy to update the version/changelog)
Also notice that the version in cssu-devel is numbered 0.6-1, and the version in the openingspost is already at 0.6.7.


Changes:

• It is no longer possible to reactivate an alarm with past date/time by pressing the icon in the alarmlist
• Made it harder to set a date/time in the past in the alarm edit popup
• Hopefully fixed Spanish am/pm timeformat issue as reported by guilledoc (which also resulted in wrong size of alarmtime font in alarmlist)

Re: N900 clock replacement [continued]
 

So sould I install the version in the openingpost?

Re: N900 clock replacement [continued]
 

Especially if you are indeed using am/pm: yes please.

Re: N900 clock replacement [continued]
 

@ade
newest version installed (from yesterday), found bug. I`ve got the feeling, that it`s related to previous one, that I couldn`t reproduce and now it surfaced again after your recent code changes.

Go to alarm list, use new alarm button, set time to some hour that is preceding current time (i.e. if it`s 11:00 now, set it to 10:00 or 9:00) and make it repeatable (any days). Save it. Now when in alarmlist, disable it (untick): repeat days are gone and alarm time is changed to current time.

Re: N900 clock replacement [continued]
 

Okay artpra, I could not replay your exact steps, but I could find a consistent issue that was very similar. It turned out it was at least related to the Polish date format. I fixed it in my testcase, so could you install the version from the openingspost (I again replaced them with an updated version) and report back?

Re: N900 clock replacement [continued]
 

Bingo! Now is fine, I couldn`t reproduce it anymore - another bug hunted ade.

Re: N900 clock replacement [continued]
 

Is the new version ready for cssu-devel?

Re: N900 clock replacement [continued]
 

As a matter of fact, I contacted Pali soon after the post you are referring to, and he almost immediately pushed a new version to cssu-devel.

As I noted before, the version number in cssu is somewhat lower that the one I use in the openingpost. So that way you may not notice a new version in cssu.

I do have two changes waiting here to be made public. One is just a fix to make it even harder to set a time/date combo alarm in the past. The other one is offering custom alarm tones per alarm.

The latter is still a challenge. The change needed for that in order to make it work is not in osso-systemui-alarm.c (even the related code was there), but most likely in libhildon-plugins-notify-sv.so. This means someone with the skills of Freemangordon also needs to reverse engineer this part to make it adaptable. He said that he will probably do that, so we have to wait and see. Of course you can pester him about that every ones and a while ;).

Re: N900 clock replacement [continued]
 

Sorry I now understand what you mean. How confusing :confused:

Re: N900 clock replacement [continued]
 

I will ask Pali to raise the version number to get in sync in case of a new release is there.
The reason I still have downloads in the openingpost, is to offer a pre-cssu-devel testversion (as I cannot upload to cssu-devel myself) and to offer a thumb version.

Re: N900 clock replacement [continued]
 

Problem with version number is that I do not want to have version holes in repositories.

Better could be, if you can change version number of your non repository versions to "repo_ver-minor_your_ver". So it will be higher as repository, but next new repo_ver in repository will be higher as your last minor.

Re: N900 clock replacement [continued]
 

What is practical drawback of version hole in repositories (aka, is it just aesthetic, or is there any real reason for generating such confusion?)

Re: N900 clock replacement [continued]
 

That's fine with me. Only issue I can see for now is that I already was at 0.6.7, so people who have installed that version will not see cssu-devel updates for a while?

Re: N900 clock replacement [continued]
 

Fixing future problems with bisecting.

I think that those people which installed package manually can install new version manually again (and maybe waiting for your updates...)

Re: N900 clock replacement [continued]
 

Minor update:

Regarding the last bullet: for some background info see http://talk.maemo.org/showpost.php?p...&postcount=111 and later posts.
Bottom line: worldclock should be ready for it (it now already puts custom alarmsounds in the alarm queue), but the alarm framework itself is not. The alarm(sound) button therefore is grayed out for now.

Notice that the version numbering has changed (see discussion in previous posts). I will upload the new sources to gitorious soon and inform Pali, so he can put the new version in CSSU-devel. If you can't wait or want the thumb2 version, see the openingspost.

Re: N900 clock replacement [continued]
 

Thanks ade and pali.

Now that it entered CSSU (what I really like), I feel like I am a bit outdated with my N900 (still on PR1.3.1).
I checked the deb and it has some dependencies to libqt4 libraries from CSSU. As I do not know what consequences this might have, I just extracted the binary and using it. I did not see any problem yet (libqt4 4.7.4cssu against 4.7.0maemo).
Just one question: do you plan to support non-CSSU user for future updates? (if not, will it be possible to use binary on its own, as now)?
Thanks.

Re: N900 clock replacement [continued]
 

Hmm, good point, I am on CSSU for ages, so I no longer pay much attention to these kind of details :)

Pali did the packaging for me, so he could tell best if there is a reason for depending on cssu libqt4 libraries.

I can't think of any specific reason though, it always worked fine with non-cssu libqt4 libraries. And I see no reason to depend on cssu libs if it is not explicitly needed.

But let's wait for Pali's view on this first, he follows this thread most of the time.

Re: N900 clock replacement [continued]
 

Source package has *no* version dependency.

Binary package depends on qt version (or newer) which was used at compile time. And because my scratchbox which compiling packages for cssu-devel has for obvious reason enabled cssu repository (so have qt from cssu), my clock-ui deb packages depends on qt from cssu.