maemo.org - Talk
Page 8 of 12 « First 67 8 910 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   N900 clock replacement [continued] (https://talk.maemo.org/showthread.php?t=81582)

peterleinchen 2012-09-03 19:30
Re: N900 clock replacement [continued]
 
Hi ade,

if you can not use the selected date time format of selected region, I would propose to use yyyy-mm-dd as fixed date format.
As 11/09 may be 9th of November (US) or 11th of September (GB). So it is not unique and may lead to confusion (at least it does for as German ;)).
Just a suggestion.

ade 2012-09-03 19:51
Re: N900 clock replacement [continued]
 
peterleinchen,

You do have a point (it crossed my mind too, but the year on the end should make the date format clear).
I will see if I will make the date order also regional, or use a month abbreviation, so there can be no misunderstanding.

And just noticed the months are not shown correctly in en_US settings when selecting a date. Going to work on that also.

edit:
* American regional settings should work correctly now when selecting date
* Date should now use regional format

Worldclock with date function is updated in first post.

ivgalvez 2012-09-04 10:25
Re: N900 clock replacement [continued]
 
ade, please check these logs.

You could distribute World Clock replacement via CSSU-Devel, as a first step before entering CSSU-Testing, without the need to wait for any HAM patches at all.

All you need to do is ask merlin1991 to grant you access to CSSU-Devel repository.

ade 2012-09-04 11:07
Re: N900 clock replacement [continued]
 
Don't know exactly when it was (perhaps two months ago), Merlin1991 said he would contact me if he had done his preparations/modifications in HAM.

I assume this is still valid. Could ask him again, but I don't want to push him.

If we want to distribute it without HAM mondifications, at least he has to tell me in what way he wants to see it included. Maybe I will try to ping him on #maemo-ssu this evening.

ivgalvez 2012-09-04 11:13
Re: N900 clock replacement [continued]
 
Yes, but the point here, is that it has been clarified in recent conversation at #maemo-ssu, that this shouldn't block the package to enter CSSU-Devel, only maybe for Testing.

You only need to ask for permission to access CSSU-Devel. That would make easier for people to install it and test it.

megaexer 2012-09-04 11:20
Re: N900 clock replacement [continued]
 
How about automatically checking "Alarm active" when you change the time of an inactive alarm? The stock worldclock does that.

ade 2012-09-04 11:32
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by ivgalvez (Post 1260835)
Yes, but the point here, is that it has been clarified in recent conversation at #maemo-ssu, that this shouldn't block the package to enter CSSU-Devel, only maybe for Testing.

You only need to ask for permission to access CSSU-Devel. That would make easier for people to install it and test it.
I understand, but I don't want to mess up things for users, so I also want some advice from these guys on how to do that the proper way.

@megaexer:
I didn't know the stock clock behaved like that. But it sounds logical and will look at it.

Edit: just had a discussion on #maemo-ssu:
Merlin1991 is going to create a package of the clock replacement (before the HAM modications are done). I think he is more skilled to make the right choices for this package than me. Can't give any exact date of when it will be ready.

Edit2:
Just updated both versions. Accepting a time while editing will now make an inactive alarm active (conform stock clock).
In the case of the version with date function: accepting a date will do the same.

artpra 2012-09-05 08:55
Re: N900 clock replacement [continued]
 
ade,
I`m glad that You are still working on this and keep pushing it for CSSU - it really is time for that. Many more less tested and even making problems packages (operator name widget anyone?) are already there.

Estel 2012-09-05 12:56
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by artpra (Post 1261429)
ade,
Many more less tested and even making problems packages (operator name widget anyone?) are already there.
As per merlin1991 @IRC, it's because "they were made by people inside CSSU". Who is that elite'reish group, and why ade can't be included - as worldclock maintainer[1] - remains unknown.

/Estel

[1]AFAIK, no one in CSSU is working on "everything", so it should be normal that author is responsible for maintaining own creation inside CSSU, still being considered part of CSSU team.

ade 2012-09-05 13:55
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by Estel (Post 1261535)
As per merlin1991 @IRC, it's because "they were made by people inside CSSU". Who is that elite'reish group, and why ade can't be included - as worldclock maintainer[1] - remains unknown.

/Estel

[1]AFAIK, no one in CSSU is working on "everything", so it should be normal that author is responsible for maintaining own creation inside CSSU, still being considered part of CSSU team.
Estel,
I don't know if there is a clear line between being CSSU member or not. I am a project member in cssu-developers git (clock-ui, source maintainer only), but I am not that involved (by choice) in discussions and decision making which takes place on IRC. The latest seems to imply that the focus rapidly switches to other topics and earlier agreements tend to shift to the background. It's not the way I like to see it, but somewhat understandable nevertheless.

I do not share your feeling that I am excluded by the CSSU (core) team in whatever way. But I do think the more intimate people get things done more easy. I could push harder for CSSU inclusion of the replacement clock, but personally I am not that extremly driven to get it in CSSU. It would we nice of course, and I hope Merlin1991 does remember this remark to create a package for the replacement clock :D

Hopes this clears thing up...

ade 2012-09-06 17:12
Re: N900 clock replacement [continued]
 
The replacement clock has its own wiki page: http://wiki.maemo.org/Clock_replacement

For now it is mainly focusing on the differences between the stock- and replacement clock.

AapoRantalainen 2012-09-07 11:12
Re: N900 clock replacement [continued]
 
Without looking code, I can claim there are some 'new' without 'delete' (not critical, but reminding you about valgrind).

Against: 7f4dc197eb371f0550fa964445781f41fab7cc37
Code:
==6037==    at 0x4832090: operator new(unsigned int) (vg_replace_malloc.c:255)
==6037==    by 0x397DF: World::getAMPM() (world.cpp:138)
==6037==    by 0x3A957: World::loadCurrent() (world.cpp:245)
==6037==    by 0x3D227: World::World(QWidget*) (world.cpp:75)
==6037==    by 0x17797: MainWindow::MainWindow(QWidget*) (mainwindow.cpp:169)
==6037==    by 0x135A7: main (main.cpp:51)

==6037==    at 0x4832090: operator new(unsigned int) (vg_replace_malloc.c:255)
==6037==    by 0x3A977: World::loadCurrent() (world.cpp:247)
==6037==    by 0x3D227: World::World(QWidget*) (world.cpp:75)
==6037==    by 0x17797: MainWindow::MainWindow(QWidget*) (mainwindow.cpp:169)
==6037==    by 0x135A7: main (main.cpp:51)

==6037==    at 0x4832090: operator new(unsigned int) (vg_replace_malloc.c:255)
==6037==    by 0x14DDB: MainWindow::getAMPM() (mainwindow.cpp:201)
==6037==    by 0x177CF: MainWindow::MainWindow(QWidget*) (mainwindow.cpp:173)
==6037==    by 0x135A7: main (main.cpp:51)

I suggest to drop generated file(s) from git, i.e. Makefile (generated by qmake + Alarm.pro)


On git: chmod a-x Alarm.pro *.ui

ade 2012-09-07 11:35
Re: N900 clock replacement [continued]
 
You could very well be right about the missing deletes. I will check the code for that.

I am not sure if we can remove the *.ui files from git, as they represent the layout. Afaik they are created by Qt Creator and not generated by something else.

edit: added some deletes in the code and updated the executables. I am not sure if all reports are valid (for example the one in main.cpp and mainwindow.cpp:169). Delete ww (from line 169) in mainwindow.cpp would lead to a segfault. But I am not a C++ expert, so I may try to delete it in the wrong location :)

ade 2012-09-23 21:47
Re: N900 clock replacement [continued]
 
Did some experimenting with GCC 4.7.2. and thumb2 for the replacement clock.

Results are as follows:

Code:
GCC version    thumb  size worldclock  worldclock-with-date
4.2.1          no        422712            476040   
4.7.2          no        278636            309779
4.7.2          yes        225292            246364
(files are stripped, size in bytes)

It shows the thumb versions are almost half the size, but even without thumb, files are smaller with 4.7.2 (experienced the same with other programs compiled).
Speed gain will not really be noticable for this program, but Freemangordon has posted some nice results in the thumb kernel thread.

For those why want to try the thumb2 version and have a thumb2 supported kernel: download is in the opening post.

Estel 2012-09-25 07:24
Re: N900 clock replacement [continued]
 
Yay, thumb2 compiled ade's worldclock! Thanks a lot!

As thumb repos are separate one (kinda CSSU fork, although it's author hate such naming ;) ), maybe You could send it to freemangordon as package, just the way like busybox-power does it, for thumb? It should be compatibles with Your plans re clock replacement and "basic" CSSU.

/Estel

ade 2012-09-25 11:02
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by Estel (Post 1271859)
Yay, thumb2 compiled ade's worldclock! Thanks a lot!

As thumb repos are separate one (kinda CSSU fork, although it's author hate such naming ;) ), maybe You could send it to freemangordon as package, just the way like busybox-power does it, for thumb? It should be compatibles with Your plans re clock replacement and "basic" CSSU.

/Estel
I would not mind if it appeared in the thumb repos first. But in the end, it is Merlin1991 that could/would do the next (packaging) step, not Freemangordon or some personal packaging attempt from myself (which can be seen as non CSSU compliant). If someone wants to poke Merlin1991 for that as a reminder, be my guest.

toxaris 2012-09-27 06:17
Re: N900 clock replacement [continued]
 
Hello.

I dont know if enyone else have experienced this behavor.
Anyway, lets say you create a new alarm occasion 07:30 named Regular Workday (name isnt nessesary).
Activate your alarm and at 07:30 the alarm awakes you but you want to snooze so you hit the snooze. And when the alarm awakes you again 10 later you hit stop. Now, if you look at you saved alarm called Regular Workday, the alarm-time have been changed to 07:40.
Is it supposed to be like this?

Estel 2012-09-27 07:56
Re: N900 clock replacement [continued]
 
Good catch. Doesn't look very convenient, so I suppose it's a glitch, not feature ;)

michaaa62 2012-09-27 08:09
Re: N900 clock replacement [continued]
 
Face it, that is the AI, social engineering and behavioral computing at work!
Good job,@ade!

ade 2012-09-27 09:52
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by toxaris (Post 1272805)
Hello.

I dont know if enyone else have experienced this behavor.
Anyway, lets say you create a new alarm occasion 07:30 named Regular Workday (name isnt nessesary).
Activate your alarm and at 07:30 the alarm awakes you but you want to snooze so you hit the snooze. And when the alarm awakes you again 10 later you hit stop. Now, if you look at you saved alarm called Regular Workday, the alarm-time have been changed to 07:40.
Is it supposed to be like this?
No, this is not how it supposed to work, and it has not worked like this. Must be some stupid regression I introduced in a later version, although I have not made specific changes to this part.

I will try to fix it this evening (local time).

ade 2012-09-27 19:47
Re: N900 clock replacement [continued]
 
It was indeed a bug I introduced (in early August).

The time did not actually shift after a snooze, but the snooze time was added to alarm time displayed. Editing it without change after snooze would indeed shift the time.

All versions can be found repaired in the openingspost. Please update if your version is dowloaded after july.

sixwheeledbeast 2012-09-27 21:15
Re: N900 clock replacement [continued]
 
Thanks

Extra QR Codes for thumb compiled users.
Ade moved QR's to OP

peterleinchen 2012-09-27 21:31
Re: N900 clock replacement [continued]
 
Hey ade,

are you sure this version is better? ;)

Got this in x-term (when clock did not want to start from status-menu):
/usr/bin $ worldclock
worldclock: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by worldclock)
with
/usr/bin $ ll /usr/lib/libstdc\+\+.so.6*
lrwxrwxrwx 1 root root 18 Sep 10 2010 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.9
-rw-r--r-- 1 root root 865504 Mar 16 2010 /usr/lib/libstdc++.so.6.0.9

Something wrong on my device? Or?
Possibly my N900 needs a reboot (having strange behaviour with internet connectivity: online, but no connection shown). Will post later...

--edit
As sixwheeler already said below: a reboot did not cure. Using normal plain worldclock.

sixwheeledbeast 2012-09-27 21:35
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by peterleinchen (Post 1273086)
Got this in x-term (when clock did not want to start from status-menu):
/usr/bin $ worldclock
worldclock: /usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by worldclock)
Confirmed for me too, using "normal" compiled with date support.

ade 2012-09-27 21:47
Re: N900 clock replacement [continued]
 
No problem here...

I compiled it using gcc 4.7 this time. Maybe it need some newer libraries. I will recompile it using gcc 4.2 and replace the files asap.

ade 2012-09-27 21:57
Re: N900 clock replacement [continued]
 
I seem to have newer libraries:

Code:
rwxrwxrwx    1 root    root            19 Sep 24 16:53 /usr/lib/libstdc++.so -> libstdc++.so.6.0.17
lrwxrwxrwx    1 root    root            19 Sep 24 16:53 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.17
-rw-r--r--    1 root    root      1071104 Jul 25 00:43 /usr/lib/libstdc++.so.6.0.17
I have updated the default clock without date (first download).

Does it look okay now? I see it now looks for libstdc++.so.6

peterleinchen 2012-09-27 22:07
Re: N900 clock replacement [continued]
 
Yes and No.

It starts, but it takes 10-15 seconds before it shows up (a behaviour which I have noticed with the last versions also, but there it was 3-5 seconds).

ade 2012-09-27 22:13
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by peterleinchen (Post 1273102)
Yes and No.

It starts, but it takes 10-15 seconds before it shows up (a behaviour which I have noticed with the last versions also, but there it was 3-5 seconds).
I think that might be your device in this case... I do not notice it, but I will do a clean and a recompile to be sure.

clock_with_date is now also updated with gcc 4.2 compiled version.

Maybe the newer libraries are related to CSSU-test. Have to look into this...

Edit:
@peterleinchen:
I did a clean rebuild. Could you download the default clock again and see if it makes a difference?

peterleinchen 2012-09-27 22:20
Re: N900 clock replacement [continued]
 
Just started afew times, from terminal and also status-menu. And I am down again at 3-5 seconds :confused:, which is still quite long. Or normal?

--edit
Downloaded again your latest fresh build. And this one is starting much better (less than 3 sec :)). However this may be ...

ade 2012-09-27 22:25
Re: N900 clock replacement [continued]
 
I think that is quite normal peterleinchen.

artpra 2012-10-26 08:44
Re: N900 clock replacement [continued]
 
@ade
I have problem with worldclock - I`m using thumb version (don`t know if is it the newest, installed it the same day when You published it). Adding new alarm doesn`t work anymore - worldclock closes immediately, when clicking "Date" button on "New alarm" dialogue. Running it from xterm outputted "Illegal instruction".
Is it only my device (I`m using latest CSSU-thumb) or not?

ade 2012-10-26 09:27
Re: N900 clock replacement [continued]
 
I do not experience issues myself, otherwise I would have done something about it :)

Please make sure you have the latest version downloaded first.
I am using the thumb compiled version with date function on an almost daily base, but other than that I don't think this version is thoroughly tested by others. Setting an alarm not using an explicit date does still work?
Let me know if you still have the crash using the latest version...

artpra 2012-10-26 10:34
Re: N900 clock replacement [continued]
 
To be 100% sure, I just downloaded/installed/rebooted (1 minute ago) this version: Thumb version worldclock with date support (for thumb2 supported kernels) from here http://dl.dropbox.com/u/42147901/wor...ture_thumb.zip - so I have (and had - judging from date stamp and file size) running the latest version.

Problem is still here - every time I use "Date" button in "New alarm" window (doesn`t matter how that window it is invoked), worldclock is instantly terminated.

PS - creating new alarm without changing its settings (so with current date and time) works, adding name too.

ade 2012-10-26 10:48
Re: N900 clock replacement [continued]
 
yep, I can reproduce it with Polish regional settings.

edit:
Can't believe how sh*tty and inconsistent maemo is at times :mad:

All the languages I tried return me something like "Saturday 27 October 2012" when I request a long date. But no, in Polish I get "sob 27.10.12". Not really a long date format, is it? Once I set another language for the format itself, I get a polish date like "piątek 26 październik 2012". But that is by using a Qt method, which I can't use, because it determines it's language by looking wrongly at the regional settings, not the device language. Sigh...

Estel 2012-10-26 19:00
Re: N900 clock replacement [continued]
 
Hey, guys, where - while creating new alarm - is "date" option? I'm using polish settings too, yet I have never been able to run into it - it seems, that I must have avoided this option all-together.

when I open "new alarm" window, I can only change repeat settings (days of week, when alarm should be repeated), and it's working fine. What I'm missing?

// Edit - strike that, I was using wrong version (one without alarm on date support).

/Estel

ade 2012-10-26 22:14
Re: N900 clock replacement [continued]
 
I have now also been testing the "with date version" with Polish, Russian, Czech and Spanish (next to Dutch, French and English UK/US).
Had to fix some things with Polish, Russian and Spanish; that is the disadvantage if you rely on literal strings :p

Just updated the "worldclock_incl_date_feature_thumb" version for that.

edit: German, Portugues, Danish, Norwegian and Italian also look okay. Swedish fixed

@artpra, could you try the new version?

artpra 2012-10-30 10:04
Re: N900 clock replacement [continued]
 
@ade,
it works!

One suggestion though: when setting an alarm in clock app, we are thinking about an alarm to set on about some hours or few days from now, not months. For long periods of time (weeks and months), we use calendar app, with much more options for each entry.
I want to say that new alarm date settings should be "days-focused", not "months-focused" and therefore I suggest to change date button description (in "New alarm" dialogue) from "mon, 1 november 2012" to "monday, 1 nov 2012" if it`s possible of course.
It will give more space too - now polish date description barely fits to button/screen ("śro, 31 października 2012").

ade 2012-10-30 18:44
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by artpra (Post 1287483)
@ade,
it works!

One suggestion though: when setting an alarm in clock app, we are thinking about an alarm to set on about some hours or few days from now, not months. For long periods of time (weeks and months), we use calendar app, with much more options for each entry.
I want to say that new alarm date settings should be "days-focused", not "months-focused" and therefore I suggest to change date button description (in "New alarm" dialogue) from "mon, 1 november 2012" to "monday, 1 nov 2012" if it`s possible of course.
It will give more space too - now polish date description barely fits to button/screen ("śro, 31 października 2012").
When I introduced "setting an alarm on a specific date" in the replacement clock, I anticipated some reactions (either negative of positive). Having received virtually non of them, it does not seem an option people are waiting for. Perhaps people are already used to enter these kind of alarms in the calendar app or use Alarmed for that.
As it was an option I wanted myself, I would have added it myself anyway. But it does imply I more or less see this version as a personal fork now, extended for my personal preference. In that context, I am fine with it's current state, and one can try it if he or she sees any usability in it.
Of course I still do want (to try) to fix real "showstopper" bugs if found.

sixwheeledbeast 2012-10-30 21:04
Re: N900 clock replacement [continued]
 
Quote:
Originally Posted by ade (Post 1287687)
Having received virtually non of them, it does not seem an option people are waiting for. Perhaps people are already used to enter these kind of alarms in the calendar app or use Alarmed for that.
Sorry I did mean to reply but TBH I have never really needed to use this feature since I installed it.
I have been so used to Calender for date events, and alarmed for repeat events, IAH I doubt I would use it.

However, I do not see why you would need to fork.
The feature is useful (to some) and does not alter any default behaviour.
I would be fine with it being a permanent feature of worldclock.

Estel 2012-10-30 23:10
Re: N900 clock replacement [continued]
 
Same here - it's ncie feature to have, that doesn't block or restrict "stock" features (even if it don't use it, personally - yet, probably due to habits).

I don't see much reason for keeping two separate versions or worldclock (4 if you count thumb) - not much reason to not install the most "augmented" one.

/Estel


All times are GMT. The time now is 15:19.
Page 8 of 12 « First 67 8 910 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8