Closed
Bug 351902
Opened 18 years ago
Closed 18 years ago
15 and 30 minute events barely usable on many displays
Categories
(Calendar :: Calendar Frontend, defect)
Calendar
Calendar Frontend
Tracking
(Not tracked)
RESOLVED
FIXED
Sunbird 0.3
People
(Reporter: dmosedale, Unassigned)
Details
Attachments
(1 file)
1.56 KB,
patch
|
dmosedale
:
first-review+
|
Details | Diff | Splinter Review |
Since the 24 hour views have landed, it's really difficult to see and use 15/30 minute events. In the slightly longer term, there are some design issues to be dealt with. For 0.3, however, we propose to try a workaround such that the number of pixels per minute is set differently in the day and week views, in the theory that people sometimes want the overview (weekview), and sometimes the zoomed view where everything is visible.
Reporter | ||
Updated•18 years ago
|
Flags: blocking0.3+
Whiteboard: [needs patch]
Comment 1•18 years ago
|
||
So what do you want to change for each view? Do you want to increase the pixPerMin on day view? I'm not clear on which view needs to grow/shrink... http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-multiday-view.xml#63
Comment 2•18 years ago
|
||
The relevant fields are <field name="mMinHorizontalPixelsPerMinute">1.2</field> <field name="mMinVerticalPixelsPerMinute">0.5</field> , see also http://lxr.mozilla.org/mozilla/source/calendar/base/content/calendar-multiday-view.xml#1651 At the moment those values are the same for the day and week view. If I understand dmose correct, the idea is to increase the values for the day view.
Comment 3•18 years ago
|
||
In order to make a 15 minute item readable, mMinVerticalPixelsPerMinute needs to be around 1.5. But at this size, you can only see about 4 hours (depending on screensize etc, ofcourse) I think a change that big is not what we want. A value of 0.7 at least makes 30 minute events have a readable title. That might be a better way to go.
Comment 4•18 years ago
|
||
Patch makes the value for dayview slightly higher.
Attachment #238914 -
Flags: first-review?(dmose)
Updated•18 years ago
|
Whiteboard: [needs patch] → [patch in hand][needs review dmose]
Reporter | ||
Comment 5•18 years ago
|
||
Comment on attachment 238914 [details] [diff] [review] change value Looks good; two-levels of review on a bug this trivial isn't likely to benefit the patch or the reviewers. r1/r2=dmose.
Attachment #238914 -
Flags: first-review?(dmose) → first-review+
Reporter | ||
Updated•18 years ago
|
Whiteboard: [patch in hand][needs review dmose] → [patch in hand][needs checkin]
Comment 6•18 years ago
|
||
Comment on attachment 238914 [details] [diff] [review] change value var viewElement = document.getAnonymousElementByAttribute( this, "anonid", "view-element"); viewElement.daysOffArray = []; // add a preference observer to monitor changes var pb2 = Components.classes ["@mozilla.org/preferences-service;1"] .getService(Components.interfaces.nsIPrefBranch2); pb2.addObserver("calendar.", this.mPrefObserver, false); + + var viewElement = document.getAnonymousElementByAttribute(this, "anonid", "view-element"); + This results in a double-declaration of viewElement.
Comment 7•18 years ago
|
||
Patch (with jminta's comment fixed) checked in
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Whiteboard: [patch in hand][needs checkin]
You need to log in
before you can comment on or make changes to this bug.
Description
•