Bug 252526 - Time Selection (Clock) UI does not work / Memory consumption
Summary: Time Selection (Clock) UI does not work / Memory consumption
Status: CLOSED FIXED
Alias: None
Product: KOrganizer Mobile
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Maemo 5 Linux
: HI major
Target Milestone: ---
Assignee: Anselmo L. S. Melo (anselmolsm)
URL:
Keywords:
: 253944 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-27 11:50 UTC by Felix Wolfsteller
Modified: 2011-01-18 17:05 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Wolfsteller 2010-09-27 11:50:14 UTC
When trying to change the starting or end time of an appointment a clock is shown.

Mobing the clocks pointers does not work. The three input fields on its right side can be selected and then highlight. Interaction however is not self-explanatory. Also, the using them leads to a hang while memory consumption of korganizer-mobile raises roughly 1 MB per sec (htops VIRT).

Observed in version 4:4.5~20100927.1180086-1maemo1.1179477 .
Comment 1 Bjoern Ricks 2010-10-05 10:09:28 UTC
It's possible to set datetime without the new Time Selection UI:
critical -> major
prio is high
Comment 2 Anselmo L. S. Melo (anselmolsm) 2010-10-14 20:55:02 UTC
(In reply to comment #0)
> When trying to change the starting or end time of an appointment a clock is
> shown.
> 
> Mobing the clocks pointers does not work.

It was expected at that point. The clock pointers were disabled because moving them inside a SlideoutPanel was a big confusion. Now with the non-draggable panel the selection using clock pointers is possible again.

> The three input fields on its right
> side can be selected and then highlight. 

The three fields are two now. We don't use seconds at all, so there is no need for a third field. 

> Interaction however is not self-explanatory.

I also think it can be improved. In the first mockups there were labels indicating what each field is, IMHO they should reappear. Any other suggestion?

> Also, the using them leads to a hang while memory consumption
> of korganizer-mobile raises roughly 1 MB per sec (htops VIRT).
> 

Need to check this memory consumption, indeed.
Comment 3 Felix Wolfsteller 2010-10-15 11:20:06 UTC
It does work when double clicking or using other tricks for the self-build input field to agree that it received input (then also the clock will be redrawn). In this case, also the OK button will be enabled.

+1 for labels

Version 4:4.5~20101014.1185761-1maemo1.1185672 .
Comment 4 Felix Wolfsteller 2010-10-15 11:34:16 UTC
*** Bug 253944 has been marked as a duplicate of this bug. ***
Comment 5 Anselmo L. S. Melo (anselmolsm) 2010-10-24 23:15:46 UTC
Although it is not related with the selection in the Clock UI, the
SVN commit 1189373 [1] changes the way modules are set in both calendar and clock UIs. The list of objects used as modules were removed and a simple list of int is used, what contribute to reduce the memory consumption. It is not ideal yet, though.

[1] WebSVN link: http://websvn.kde.org/?view=rev&revision=1189373
Comment 6 Bernhard E. Reiter 2010-10-26 14:13:34 UTC
Going down with urgency and priority, because you can select
a time using the following method:

a) click on the digits, until they grow
b) wait a bit until you can slide to the other number up and down
   (can take several seconds)
c) once selected the new number, press the number again to shrink the dialog
again.
d) now you can press okay.
Comment 7 Bernhard E. Reiter 2010-10-26 14:13:59 UTC
Tested with Package: kdepim-mobile
Version: 4:4.6~20101025.1189542-1maemo2.1188357
Package: libqt4-experimental-gui
Version: 4.7.0~git20100908-0maemo1
Comment 8 Anselmo L. S. Melo (anselmolsm) 2010-10-26 15:41:10 UTC
(In reply to comment #6)
> Going down with urgency and priority, because you can select
> a time using the following method:
> 
> a) click on the digits, until they grow
> b) wait a bit until you can slide to the other number up and down
>    (can take several seconds)
> c) once selected the new number, press the number again to shrink the dialog
> again.
> d) now you can press okay.

This method is available since the first versions of the time selection UI.
This result shows we need to give a kind of tip to teach the user how to use this interface.
Comment 9 Anselmo L. S. Melo (anselmolsm) 2010-10-26 17:59:54 UTC
renaming the bug report to include the memory consumption issue
Comment 10 Bernhard E. Reiter 2010-10-26 18:07:10 UTC
Anselmo: How is the memory issue connected to the usability problem?

One problem is that it is not intuitively how stuff works.
And then there is the problem that it is way to slow.

I personally would display the next and previous choice once 
hour or minute is selected. Then I would _not_ require a second touch
to actually make the selection.

In addition I would make the pointers of the click touch and draggable.
Comment 11 Anselmo L. S. Melo (anselmolsm) 2010-10-26 18:24:17 UTC
(In reply to comment #10)
> Anselmo: How is the memory issue connected to the usability problem?
> One problem is that it is not intuitively how stuff works.
> And then there is the problem that it is way to slow.

Bernhard: They are not connected, but the memory thin was included in the original report.

> I personally would display the next and previous choice once 
> hour or minute is selected. Then I would _not_ require a second touch
> to actually make the selection.

IMO the selectors could be bigger to allow selection without a previous click.
I'm not happy with the current flow too.

> In addition I would make the pointers of the click touch and draggable.

This (old) code exists and is being ported.
Comment 12 Eduardo M. Fleury 2010-10-26 19:21:41 UTC
WRT to the memory consumption reported in the first post, I'm working to reduce that. We've spotted some large C++ objects that are always loaded. I'll try to use Loaders in order to keep only one of such objects in memory at a time.

Meanwhile, I've pushed a commit to reduce the QML memory consumption in the Calendar widget.

SVN commit 1190015 by eduardofleury:

Mobile Calendar: Refactor to reduce memory usage

The Calendar Widget was using ~800 kb of memory, by reducing
the number of elements it's now using ~600 kb.

Removed from CalendarDay (42 instances):
 - One MouseArea
 - One Image
 - One Item
 - Two states

Removed from Calendar
 - Connections in each day

Added to Calendar
 - One big MouseArea to handle day selection

I'm also using repeaters in Calendar.qml to improve readability.

 M  +78 -441   Calendar.qml
 M  +13 -54    CalendarDay.qml

http://websvn.kde.org/?view=rev&revision=1190015
Comment 13 Bernhard E. Reiter 2010-10-27 11:37:35 UTC
If the memory consumption is on the only reason that the time widget does not work, I suggest we open up another issue for it.
Comment 14 Anselmo L. S. Melo (anselmolsm) 2010-11-26 16:36:29 UTC
SVN commit 1201037 by amelo:

Select time using the clock hands

Besides the selectors, now it's possible again to set the
time using the clock. Tests on device probably will show
the need of adjustments.

CCBUG:252526
CCBUG:257692



 M  +28 -15    Clock.qml  
 M  +2 -0      calendar/ClockDialog.qml  
 M  +69 -96    calendar/clockhelper.cpp  
 M  +25 -16    calendar/clockhelper.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1201037
Comment 15 Till Adam 2010-11-27 19:18:33 UTC
Works ok for me now. Please re-test.
Comment 16 Bernhard E. Reiter 2011-01-18 17:05:33 UTC
The clock works in principle now, which means the memory problems probably are gone. There are a number of usability issues with it, one is:
Bug 263557 (Time selection usabilty: clock digits very hard to hit)

Tested: windows-ce/Kontact-Mobile/testing/2011-01-17-02-23

Kontact Touch on N900 still has issue with the am-pm switch, but
this probably is gone with later revisions. Otherwise we should open a new dialog for it.

Version: 4:4.6~.20110110.1010.giteb759d8-1maemo1.1213397
Package: libqt4-experimental-gui
Version: 4.7.0~git20101111-0maemo1