125366 - Calendar does not maximize to window size (too big)

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Brett Denny]

I'm using Moz nightly build 2002021108 and installed the calendar through the
XPI.  On 1024x768 resolution and my taskbar two rows high, when I maximize the
calendar the status bar/component bar is hidden below the taskbar.  If I have
the taskbar at 1 row then it looks fine.  Basically, it doesn't maximize to fill
the *available* screen space.  The rest of Moz works fine.

Comment 1

[mental]

See this too, and this is not bug 110057.  Confirming.

Comment 2

[Oliver Klee]

Might be related to bug 118750.

Comment 3

[Mike Potter]

I have worked on this all afternoon, I don't know how to fix it.

Comment 4

[Karl Guertin]

Attachment: Massive patch that fixes resizing

As promised, here is the code to resize the month view. Most of the changes are
in calendar.css, where I basically rewrote the month rules. I shifted some
boxes around in calendarMonthView.xul to make the structure simpler and
resizing easier. Added a onresize prototype that calls the refresh function and
added the call to resize the month view to the global prototype. With that, the
resizing works for month view. There is a heavy performance hit in going to
partially transparent boxes, people with lower power machines will have trouble
unless we make a skin with no transparency. This change was necessary in order
to get resizing with the minimal amount of change, but as an added bonus the
user gets to put whatever they want as the background. To use this, simply
stick a file called userBackground.png in the skin/modern directory (with the
rest of the skin stuff). 

Since I received no comments on the multiple months across the top of the month
view, they're in as well, I patched goToPrevious and goToNext to take an
optional number and then go that many back or forward. The back and forward
arrows have been changed to ones that are larger and better match the rest of
the modern theme (the old ones were too pointy), that file is attached next.

I think that covers it, this patch should cover the following bugs:
bug 110057
bug 118750
bug 125366 (this bug)
I can confirm there are no images in monthview for text (bug 1180803)

Files changed (/mozilla/calendar/resources is the root):
jar.mn
skin/modern/calendar.css
content/calendar.js
content/calendar.xul
content/calendarMonthView.js
content/calendarMonthView.xul

(btw, windows programs inserting <CR>s are a pain when you're trying to diff)

Comment 5

[Karl Guertin]

Attachment: previous/next arrows

previous/next arrows, I wish you could attach more than one file at a time...

Comment 6

[Colin Phillips]

Ok, 2 things.

Firstly, please don't remove contributors names from files (calendarOverlay.css
at the very bottom of the patch).  -- Unless you have a reason to.

Secondly, we're missing the following graphics, which make the patch apply, but
not compile properly.

+    skin/modern/calendar/all_day_event.png (skin/modern/all_day_event.png)
+    skin/modern/calendar/prevnextarrow.png (skin/modern/prevnextarrow.png)
+    skin/modern/calendar/userbackground.png (skin/modern/userbackground.png)

After that, I'm looking forward to seeing this work!

Comment 7

[Colin Phillips]

Nevermind about the prev/next arrow graphic, I see it.

I still need a png of the all_day_event & the userbackground.png

Comment 8

[Colin Phillips]

Ok, I hacked the patch in, here's a few thing I've noticed.

1) The performance is reallllllllllly bad
2) The top bar doesn't flex (the arrows & other months are in fixed positions on
screen), this will have to be changed.  We'll also change it in the other views,
but that can be done after we apply this patch.
3) We want a white background on the names of the week, to make them stand out
(this comes directly from our graphic designer).
4) This patch breaks resizing of the week & day views (there is an awful lot of
whitespace on the right when you resize them.  We may have to make this patch
work for all views.
5) As you shrink the month view, you begin to lose events in the view.  To see
this, add 4 events in a day.  The 4th event will be a blue dot on that day. 
Shrink the view height wise.  The event completly disappears as your shrink the
view, and is not viewable (except by the left column list). -- As you shrink the
view, events should likely all become the little dots.
6) If you collapse the left column (via the grippy), then events on a day have
different colors on the border.  Events will have a blue top, left, and bottom
border, but a red right border.
7) The bar at the top of the screen with the months is not centered vertically.
 It looks a little awkward with not enough spacing at the bottom.
8) The days appear much too large & too bold.  Shouldn't stick out so much.
9) The months appears too large.  They should be prevelant, but not so much so
that when you shrink the view, they are the only thing that really stands out.

Obviously some of these are fairly trivial, and having the funcitonality is
great.  I'll gladly deal with some of these issues on my own (once the patch is
tweaked a little), but I just wanted to make note of them all.

What can you (Karl) do about 1, 2, and 5?

Comment 9

[Karl Guertin]

about the files: I have no clue why all_day_event.png is in there, I didn't
include a userbackground.png because you can use anything (I'm using comic
strips on mine, and don't really feel like checking them into the tree).

Regarding:
1. Absolutely nothing. It's the transparency calculations that are killing
performance (I did mention it when commenting on the patch). Your options are to
either live with it, not have a background image, or not have resizing.
2. add flex="1" to all the boxes affected :] (this is minor and I can fix it
without difficulty)
3. I made them green because the background is white, they don't stand out due
to a white background if the entire calendar is on a white background.
4. I know, I plan on patching day and week views, I just don't want to get my
branch too far out of sync with everything else, I had enough trouble making
this patch with all the revisions to the affected files when I was making it. I
can temporarily fix this, but I'd rather just add a function to make them fit
the screen. This I would plan after 5.
5. This is a planned addition in the future. If you get the window view small
enough, two events won't fully fit on the day. After fixing 2. this will be the
next thing I do.
6. again, I can probably fix this. I really didn't check day and week too
carefully since I was only working on month.
7. It looks centered on my version of the files. March does not look centered
for some reason but I believe the box and its contents are centered.
8. change the font size to .8em then
9. I am unsure of your request here.

Comment 10

[Colin Phillips]

Ok.  You should likely use the new all_day_event.gif's that we made yesterday. 
Otherwise, I think you pretty much addressed everything.  I may put a few tweaks
on it in once it's in, but nothing too major.  So are you going to make a new
patch that addresses (some of) the above issues?  We're going to have a problem
with the userbackground.png file in the jar.mn file if we don't include one.

Comment 11

[xyzzy]

Since you are discussing it, I would like the background image turned off for
the time being.  While I like the image, I'm on a slow CPU, and I notice major
performance problems with the Calendar, especially.  Perhaps it can be added
back in the future as a pref?

Comment 12

[Colin Phillips]

I concur.  Can we maximize for performance to start, and add coolness later?  I
guess that would mean removing the whole transparent boxes thing you mentioned.

This will be a whole different patch.  :)

Comment 13

[Colin Phillips]

Just to note, the bug Karl mentioned 1180803 is actually bug 110803 (Calendar
should not use images for text).

Comment 14

[Karl Guertin]

Attachment: temporary patch to fix compiling problems

I didn't expect this to get checked in so fast without userbackground.png and
with all_day_event.png in the jar.mn file. This patch takes them out.

Comment 15

[Colin Phillips]

This patch didn't go in, did it!?

Comment 16

[Colin Phillips]

Comment on attachment 76291 [details] [diff] [review]
temporary patch to fix compiling problems

Not needed, as this was never actually checked into the tree

Comment 17

[Karl Guertin]

Attachment: patch, version 2

Comment 18

[Colin Phillips]

Comment on attachment 76161 [details] [diff] [review]
Massive patch that fixes resizing

obsoleting

Comment 19

[Karl Guertin]

Attachment: previous/next arrows to match the theme change

some comments:
1. Added ability to toggle background image with it being off by default, it's
on the context menu. Took the userbackground.png off of jar.mn so it's not
required unless you want a background.
2. fixed
3. fixed
4. not addressed, for a later patch
5. later patch, it'll take me a day or two, would prefer to get this patch in
6. wfm
7. fixed
8. fixed
9. fixed

Comment 20

[Colin Phillips]

Comment on attachment 76162 [details]
previous/next arrows

obsoleting

Comment 21

[Karl Guertin]

Attachment: patch, v.2.1

fixed colinp's issues, more spam for everybody :]

Comment 22

[Colin Phillips]

Comment on attachment 76439 [details] [diff] [review]
patch, version 2

new patch 2.1

Comment 23

[Colin Phillips]

Attachment: Problem with sidebar

Karl,

I've found that this happens when you collapse the sidebar.  We need to address
this issue before I'll check this one in.

Comment 24

[Karl Guertin]

Attachment: patch, v.2.2

The last patch was without the updated CSS, so most of the problems marked
fixed weren't. Sorry about that. This new one has the CSS files and some better
commenting. To see what this calendar looks like from my computer, see
http://www.grayrest.com/moz/cal/streched.png and
http://www.grayrest.com/moz/cal/normalwithbg.png.

Comment 25

[Colin Phillips]

Comment on attachment 76447 [details] [diff] [review]
patch, v.2.1

deprecating for patch v2.2

Comment 26

[Colin Phillips]

Ok, I checked in patch 2.2 (with a few tiny tweaks -- namely localization of the
context menu items).

I'm leaving this bug open because the bug is meant to address resizing of all
views, not just the month view.  Hopefully we can get work started on them very
soon.  I'll be starting work on some simple parts of the day & week view today
(namely making the header look the same as in month view), but the actual visual
display of these views is going to be horked in the next XPI.

Comment 27

[Brett Denny]

Ha, ok... well this wasn't what I meant when I filed the bug... I had actually
never seen the problem that had been fixed until today I was playing with the
day view and changing the screen size.  I'm glad that's being worked on in any
case.  

What I originally *meant* for this bug to address, was that the calendar window
itself didn't maximize on the desktop - the status/component bars would be
hidden under the taskbar on Windows if it was more than one row high.  That
seems to have been fixed anyway though.  Good work all!

Comment 28

[Mike Potter]

I think that got fixed when the month view was redone.

Comment 29

[Colin Phillips]

Brett,

I think that was bug 118750

Comment 30

[Karl Guertin]

Attachment: Week Resizing, v. .9

This patch (almost) fixes resizing in week view. The solution in this patch
suffers from two bugs that I am not willing to fix. They are:

1. Resizing the unifinder does not resize the events. This can be easily fixed
if someone can figure out how to catch the view being resized by the splitter
and call the refresh events function. This also affects day view and the
unifinder itself.

2. If there is an event on the last day of the week, the positioning of the
events gets messed up. I cannot figure out why this occurs, I've spent hours on
it to no avail. The workaround is to resize the unifinder (doesn't matter how
much, it can be one pixel) and refresh the events. You can refresh the evens by
resizing the window, changing views, or changing weeks. The unifinder can be
resized in any view, it doesn't have to be the week view.

Notice that this patch changes the jar.mn to reflect the change from
week-view-corner.gif to week-view-corner.png. This has been done because I did
a slight redesign of the view and needed a bigger corner and because I thought
we were trying to move from .gif to .png.

The redesign was done because I had to change the css to make it resizeable
anyway and to address bug 133758 by making the labels deliberately off center.
It's not a bug, it's a feature. Once the nits for this patch are addressed,
I'll be unavailable to do more work till June.

Comment 31

[Karl Guertin]

Attachment: week-view-corner.png

This file needs to be placed in BOTH the modern and classic skin.

Comment 32

[Karl Guertin]

Attachment: Week Resizing, v.0.9.1

Forgot to change the jar.mn for both classic and modern. Also removed the 1px
blank gif from the jar.mn because it's not used anywhere.

Comment 33

[Colin Phillips]

*** Bug 137587 has been marked as a duplicate of this bug. ***

Comment 34

[Colin Phillips]

Week view patch checked in.  There's still some issues with it, but I think this
is better than what we had.  We'll let this settle in CVS for a little while (as
I'm really busy right now), then I'll take a look at the bugs related to this one.

Comment 35

[Steven Rieder]

This bug doesn't just exist on WinXP, it exists on Linux as well.

Comment 36

[Mike Potter]

I think this is fixed now, all the views resize fine for me.

Comment 37

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Sunbird Only. Be afraid for your sanity!