Re: N900 clock replacement [continued]
 

Did you compare it with the behavoir of the stock clock? As you say the N900 shows a wrong time systemwide, I do not see a relation with the worldclock right now.

Re: N900 clock replacement [continued]
 

With stock worldclock seems to be the same. What can it be caused by?

Re: N900 clock replacement [continued]
 

I actually meant have the possibly to select another timezone as UTC.

Not change all the timezone times to UTC over GMT.

Example

Local time 12:00 GMT +1
Brisbane 21:00 GMT +1
UTC 11:00 GMT -1

Re: N900 clock replacement [continued]
 

I don't understand what you mean. UTC is just (to put it simple) the more modern name for GMT.

Re: N900 clock replacement [continued]
 

Not exactly.
I know on a basic level they are the same, but they are calculated completely different, that is not an issue.

Scenario

If I want to put a timestamp on something like a website it is normally done in UTC.

If in London you are on DST (aka GMT +1), I have to remember to minus an hour to my time.
If not on DST, I have to remember not to minus an hour off my time.

Can a timezone be created that will always show GMT/UTC and never be altered by DST.

I suppose thinking about it a work around could be to have Iceland in my World Clock as they stay UTC all year.

Still I was imaging a option in the "World Clock" menu "Show UTC"

Does this make any sense, now?
:D


Edit...
Just realised I confused you with my table.

I meant

Local time 12:00 (GMT +1)
Brisbane 21:00 (GMT +10)
UTC 11:00 (GMT)

Re: N900 clock replacement [continued]
 

I get your point...
Will see if and how I do something with this :)

Re: N900 clock replacement [continued]
 

+1 for UTC as selectable timezone, it saves many round-trips to google for calculating UTC :)

/Estel

Re: N900 clock replacement [continued]
 

Changes as a result of the latest discussions:

• Repeating alarms will show there full daynames in the new alarm dialog when an alarm is set to repeat for one or two days. For more than 2 days, it will use abbreviations. Looks like the stock clock switches to abbreviations after 3 days, but that will give space issues in portrait mode (which the stock clock does not have to worry about :))
• The main page should use the systemfont ones again. Please check if the three icons in the main screen do align well over the default background, if used (the blue glow effect surrounding the icons, it looks okay in my case with my fonts)
• The date/time dialog now pops up after a long press on the local time in the worldclock screen. Note that the stock clock needs a short press, a small difference
• Introduced GMT/UTC as a separate timezone, which can be chosen from the list of cities. It comes with a small warning: I created a new city id for this, which is unknown to older versions of the replacement clock. So if you set this "new" timezone in your worldclock list and later revert to on older version of the replacement clock, then this version will crash on startup, because it does not know the id. Chances are very small this situation will arise, and can be solved by manually removing the number 999 from the city list in /home/user/.config/worldclock/worldclock.conf

Please report if bugs are encountered.
Download in first post is updated with a new version.

Re: N900 clock replacement [continued]
 

Thanks for the update.

All fixes/additions work at first look except one .. the fonts.
I now have a completely different font, I have never used.
It's not Nokia Sans and it's not my system font eithier (Ubuntu)

Also I have been pressing the image button trying to work out what it does.
After a while I realised it's the clocks wallpaper image but it only works on restart.
Do you think a hildon banner "will be applied on application restart" or the like would be useful?

Finally it may possibly be my font but in the "world clocks" if the timezone is plus two digits (GMT +10) the first letter of the Day is chopped off.
I am guessing there's not much room due to having the year in the date.

Re: N900 clock replacement [continued]
 

I thought I used the same code as before for the fonts, but apparently something is different then. I will investigate it. Maybe is due to a change in a QT Creator form after all.

Had the same idea about using a banner to inform about a restart to take effect, but it should be a message in the local language, like the rest. This is somewhat of a hurdle.

I do lose the dayname only if I select a GMT -10:30 timezone (in landscape mode). It may be due to the font, but also in dutch, the abbreviation is only two letters, not three like in your case.
I could remove the year to make room, but on the other hand I do like the added year. For space sake, I already remove the century digits.

How about I remove the year in landscape and only show it in portrait? I think the code change for that is not too big. The landscape notation would resemble the stock clock one, and the portrait mode (which has more space for this) would add something extra in this case.

Re: N900 clock replacement [continued]
 

FYI 'Wed' is cut off in both portrait and landscape with my fonts

Re: N900 clock replacement [continued]
 

Yeah, I can image not everything can be displayed in some cases, even though the GTM is on another line and has no influence. I am going to remove the year indication in all cases to make the rest fit easier.

Re: N900 clock replacement [continued]
 

A new round:

• Second attempt to restore the systemfont in the mainscreen
• The year digits are removed from the worldclock screen. Conform stock clock and it creates space needed in certain circumstances.
• Removed the menu option to show/hide the background. It gave too much confusion (restart needed) and discussion (correct translation in the menu). I think most just want the background. It is still possible to disable the background as a kind of hidden option, "Background=false" has to be set in "/home/user/.config/worldclock/worldclock.conf".

Download updated.

Sixwheeledbeast, how does the font and alignment look now in your case?

Re: N900 clock replacement [continued]
 

:)
Thank you. All sorted.
Removing the year worked too.

Re: N900 clock replacement [continued]
 

Now i understand, why you insisted so much into bug-hunting: You can' read the binary clock. :D

Re: N900 clock replacement [continued]
 

I hope I can read binary.
I use it at work a fair bit. ;)
The truth is I just like finding bugs :D

Re: N900 clock replacement [continued]
 

Maybe I was a bit too lazy then...:rolleyes:

Anyway, it now only needs a short press (changed in the latest download).

Re: N900 clock replacement [continued]
 

ade, as adding new (existing) FOSS replacements of closed bits to CSSU is slow as hell (and probably, going to become even slower) could You upload it into repositories?

If You don't have time to do it, I can volunteer - if even for my own convenience. Updating it from TMO thread for months now is kinda tiresome :) (I know, we damn suers become lazy bastards).

Thanks a lot, in any case.

/Estel

Re: N900 clock replacement [continued]
 

In this thread you can see it as been in the extras-devel repo for a short while. AapoRantalainen had packaged it and uploaded it. But just before that, Aapo, Freemangordon and I had a discussion on IRC, where Freemangordon and I had the impression the deal was, it was best not to upload it. Freemangordon wanted a good integration with CSSU, and as it overwrites the stock clock (not besides, like OMP), a good strategy has to be found. So Aapo removed the packages from extras-devels afterwards.

At the moment, Merlin1991 is rewriting HAM to deal with these kind of CSSU changes the best way.

I do have plans for a new feature, but am not planning to do any changes till integration in CSSU, unless real bugs are found or changes are needed for CSSU integration.

Re: N900 clock replacement [continued]
 

It;s absolutely understandable. It's just that current idea of CSSU maintainers is to provide separate, optional repo for FOSS replacements of closed Fremantle bits, which will take muuuch time.

It's quite a pity, that Your work on additional features You have ideas for, must be postponed for time unknown. Maybe we can consider current version CSSU candidate, and any new would be "extra" variant for repositories? :) Just suggesting

/Estel

Re: N900 clock replacement [continued]
 

@ade

I've spotted a few very minor things with the latest worldclock.

If you already have your local time as any city (Local time - London) for example, it will still let you add that city as a world clock.

If you change to another timezone you have to completely close worldclock to update to that timezone.

Also it would be nice if the World clock city list was in proper time order.
Currently it's 0, 1, 10, 11, 12, 12:30, 13, 14, 2, 3 etc ...

If it's an auto-sort thing an easy fix could be adding leading zeros 01, 02, 03, 04 etc ...

Edit...

Also the 11:30 and 12:30 timezones have there day name (Wed) cutoff in landscape only. I thought removing the year had fixed that but alias not in all timezones.

Re: N900 clock replacement [continued]
 

Yep. And I know the stock clock does not. But when I am abroad I want to know what the local time at home is. So I want to add that clock. But I can't as long as I am still home. I can only add it if I am in that other timezone. And what if I return from my holiday? I don't know if the stock clock will remove it, because it is localtime again? And if so, I have to add it again for my next holiday.
It does not make sense to me, I just want to add my own timezone as one of the visible timezones, why should the clock prevent me from that?

Time is updated, the local timezone is probably only determined at startup.

Seems that the stock clock has no order at all. I think most people will search by entering the cityname, not by its GMT offset (which will mostly be unknown to them).

As usual, I will see if things are worth changing in terms of functionality and the amount of effort it costs.

Re: N900 clock replacement [continued]
 

+1

It would be useful, but nevertheless, it's only cosmetic thing (and I'm sure sixwheeledbeast is aware of that, he just mention everything he find, as pro tester :) ), so if it doesn't require much effort - sure, it's welcome. If not, we will still have sound sleep :)

/Estel

Re: N900 clock replacement [continued]
 

Ok if it's functional that's cool. It seems silly but when you explain it like that it could possibly be annoying to follow the stock clock.

That makes sense, possible to restart worldclock on change?

Fair point, I was looking for places with a certain timezone when I noticed this, compared to my normal type the city in method.

Thank you for your quick response as always. :)

Re: N900 clock replacement [continued]
 

And here we have another update (sorry Estel, blame sixwheeledbeast :))

Update of timezone after change of timezone
The replacement clock will now update the local timezone in the worldclock screen after it has been changed from within the replacement clock. No more restart required.

Sorting of the world clock city list
Is was alphabetically on the GMT offset, while the stock clock does not logically sort. If the sort was to be changed, I would do the sorting on the city name. So the list is now sorted alphabetically on cityname

About the dayname cutoff in 12:30 timezones sixwheeledbeast later reported: it does not happen in my case (tested with default font and droid sans). Maybe I will have a closer look later.

Re: N900 clock replacement [continued]
 

No worries, it's pleasant kind of pain :) Of course having it in repos, would cut off pain, leaving pure pleasure.

Thanks for update!

/Estel

Re: N900 clock replacement [continued]
 

Ok so I am back again....
I suppose you could say this was self inflicted.

Upon playing about in 12 hour mode (messing with cooktimer)
I spotted that upon switching from 12 hour mode to 24 hour mode required a restart.
Can the worldclock timezone update be easily implemented to make this update on a change?
Also the "Currently GMT XXX" seems only to be updated when you navigate away and come back.

Thanks for the last update BTW. The automatic update of the main screen really makes this application feel polished. Restarts always make applications feel disjointed.

P.S. I think sorting city's alphabetically was a good call.

Re: N900 clock replacement [continued]
 

The automatic update of the current GMT was not that hard. So I had good hopes for automatically updating when switching for 24H to AM/PM and vice versa. Until I hit this bug:https://bugreports.qt-project.org/br...rklog-tabpanel (no, it is not only symbian)

That resulted in using some hildon functions and checking for 24H-AM/PM changes at moments it could have been changed, then modify it in the relevant parts (mainscreen, worldclock screen, alarmlist, new alarm etc). It took me the greater part of this day to change it. And it is not the first time I notice Qt has issues with locale settings in Maemo.... :mad:

Changelist:

• Current GMT in mainscreen updated directly after changing
• 24H-AM/PM switches in the replacement clock are directly applied to all clock parts
• Setting an alarm within 30 seconds using the current time led to a "23:60 until alarm". It will now display "24:00 until alarm"

Download is updated with the latest version.

Re: N900 clock replacement [continued]
 

Last changes revealed a small regression to me which I now fixed in the most recent download.

Hildon time I now use returned "ip" for "pm" in Finnish. Mismatching to Qt locale, returning "ip." (including dot), resulting in mixing up am/pm and some layout issues.
Should also fix other possible comparable am/pm notation issues.

Sorry to all finnish clock replacement users in 12h modes :)

Re: N900 clock replacement [continued]
 

One thing I missed in the default osso-clock was the option to set an alarm on a specific date.

If I had to set a one time alarm within a week, I used the repeat option for that day and disabled that repeating alarm afterwards. Most of the time I was too lazy to fire up the calender, and through to all the step to set an appointment :o

- So next to the portrait mode, a new feature is added: setting alarms at a specific date.

It should be pretty straightforward. As long as you don't press the date button, you should not experience any difference with the current (replacement) clock.

By choosing and confirming a date, the alarm gets a specific date. By editing the alarm you can change the nature of the alarm, but an alarm with a specific date cannot be changed in a non repeating alarm with no date attached to it.

The stock clock cannot understand the alarms with a specific date, but can remove it or change it to a "standard" alarm.

It is not tested extremly extensive, but I did not encounter any mayor issues using it for about a week.

You can find it as a separate download on the first page, next to the "stable" replacement clock.

Re: N900 clock replacement [continued]
 

I found one minor bug: if you want to select another ringtone for alarm
alarm settings > alarm tone > more > select
then
done
then
choose alarm tone
then the old tone (before the whole procedure is shown)

Re: N900 clock replacement [continued]
 

yep, I can confirm this and will have a look at it.

Re: N900 clock replacement [continued]
 

Sorry for pestering, but what about repository, again? After all, if it will ever make it into CSSU, repo one can be replaced with dummy transitional package (standard Debian's way). Also, considering how CSSU is managed nowadays, it's doubtful, that clock replacement will be available from CSSU until at least 2014 :)

Sure, manual installation isn't so much of a problem, but useful things spread over TMO threads, was the thing that we were trying to fight with flames, yep? (+, TMO may disappear with end of 2012, or become read-only, or...).

Repositories seems to be both most convenient (for obvious reasons), and safe (X-Fade is still taking care about repos) way. Not demanding anything, obviously, just thing to consider :)

Thanks for Your constant work on it!

/Estel

Re: N900 clock replacement [continued]
 

@marmistrz:
It took me some time, but I think this glitch is fix now.
Both versions can be found updated in the first post.

@Estel:
Looking at the current -not that easy- discussion on IRC about inclusion of busybox-power in CSSU also gives me the feeling the replacment clock will not be added in CSSU on short notice.

I wouldn't worry about sources (git) or binaries (dropbox), as they are not hosted on TMO. I'll stick to my arguments I gave you the last time you asked (for now..) :)

Edit: just encountered a small bug in the version with date. Once an alarm with date was edited/created, it would threat other all other non repeating alarms as having a date when edited (until the clock was restarted). Fixed that also.

Re: N900 clock replacement [continued]
 

How this for a temporary solution.
Scan with mBarcode, select Open URL.
Yes, I no you still have to move the binary to the right spot, but it will save time finding the worldclock thread on my device.


[EDIT - Removed QR Codes as moved to first post thanks to ade]

Worth putting in the OP?

Re: N900 clock replacement [continued]
 

Nice idea! I have put them in the opening post.

Have you already done some testing with the new version with date? I did not get responses, meaning no problems are found, or just nobody is interested :)

Re: N900 clock replacement [continued]
 

Cool, will pull them out of my post as they take up a lot of space.... ;)

Sorry, haven't tried that one yet will do so now.
Will be easy with new QR codes :D

Re: N900 clock replacement [continued]
 

I am going to make a small change very soon in the version with date: it now always used "-" as a date separator, I am going to let it honour the (Qt) locale date separator. So no need to report about that :D

Re: N900 clock replacement [continued]
 

You beat me to it by seconds... was just going to mention that.

Will it be formatted like the world clock part, with the year replacing (GMT) part?

Re: N900 clock replacement [continued]
 

Qt and Hildon do not always use the same definition for date separators, and I do not know which is used in the worldclock part right now. But I will compare them.

The used format will be dd[seperator]mm[seperator]yyyy. This order will be fixed.

edit: updated download, now using regional date separator.