Okay, that patch is committed. I'm going to resolve the ticket now - 
there are a few nits, like I wouldn't show days in multiple months - 
no point since you've got all of them there - but those can be 
addressed over time on the lists. Thanks!

Okay, here's the patch to run against HEAD to see the DB 
optimizations, adding of the tooltips, and changing the year-event 
style to something more visually appealing than that aqua green color 
(who knows where I got that from!).



Also, I took out highlighting 'Today' for 2 different months.  So say 
today (Feb 1) is on the Jan. and Feb. month, it'll just highlight the 
Feb.  It looked goofy otherwise.



Overall, I think it's pretty complete. If there's something I missed, 
just let me know!

using the category color isn't going to fly. There should be a css 
class for days with events, which I believe there already is? And then 
themes can do what they want.

The "random and unpredictable" part is what I was afraid of.  There's 
nothing wrong with just bolding the events, but to me, it's kinda hard 
to spot the bold in the bunch for some reason, hence the color.  If 
you wanted a quick view of what your year looks like, using a color 
background would be nice.



How to implement it, I'm not sure.  If you really feel against it, 
just let me know and I'll yank it and provide a final patch.   
Otherwise, any ideas you may have to standardize it would be great! :)

I think the category color idea is nice, but it's going to be too 
random and unpredictable in practice. What's wrong with just bolding 
the date, like the month block does?



Also, you should definitely hit the database only once for the year - 
will cut down on recurring events being fetched and checked every time 
a *lot*.

Here is the tooltip addition patched on what you committed.  Putting 
that one random .php file I had in templates in the year.php was a 
good idea - started off as a template, but transformed and was never 
placed right ;)



Anyways, what I did was change the background color to the category 
color of an event on the day in question.  The thing is, it will of 
course only use the color of the last event as that's how I put it in 
the loop.  Do you think that this should just be a pref instead, or 
just leave it how it is as the point is to really know what days you 
have items scheduled.



The other question I had was in regards to performance.  In the loop, 
I grab the events for month 1, then month 2, etc.  Would it be better 
to grab the evens for the entire year in 1 query, or just hammer the 
DB 12 times?



Other than that, I don't think there's much more to do with it.

/Much/ better! :) I've gone ahead and committed it for now. Still 
needs a better presentation of the days with events, by default, and 
I'd like to see what the tooltips do to it - we're already fetching 
all the events, so it will only increase page size.

Just as an addition, once I get everything all done, I'll submit a set 
of patches against HEAD.  Sorry, but I feel bad for putting the whole 
files up =x

The month block was perfect!  Take a look at this and see what you 
think. I dropped down to 800x600 and it fit/looked just fine.



I didn't create patches (forgot to make .orig's!), so just replace the 
files (unless you really want me to create patches).



The one thing I did like was the tooltip's in the block, but that may 
impact performance too much, depending on how it's done I guess.  For 
now, I left it out, but I could play with it perhaps.



I want to be sure I get the look down first, and then work on 
functionality.  As you stated, this is for seeing more information, so 
the question really is, how much is too much?



Let me know.

800x600 would be ideal (usable at that, anyways), but 1024x768 is a 
must, IMHO (keeping in mind the Horde sidebar as well). Using 
percentages is great, but with your current code, it simply doesn't 
fit on my laptop's screen and scrolls off to the right.



Outlook doesn't even have a year view, but all of the ones that I've 
seen use single letter weekday abbreviations. That allows for seeing 
more information at once, which is, imo, the whole point of this kind 
of view. See the month block, also - it produces a single month of 
this kind of view.

The first comment, "This is pretty unreadable," got me thinking and 
then I realized that I run at 1280x1024 and it looked good to me!  So 
my question is, what resolution should I shoot for?  The reason I ask 
is because I have the entire table take up 100% of the width, and then 
use %'ages from there.



Should I create fixed widths-heights?  Should I nix the "Week X" as 
well?  Shortly after I submitted my original patches, I did abbreviate 
the names, but just down to Mon, Tues, etc.  But if you just want 
something like the date picker (which personally I think is too 
small), then of course it'll just have to be M-T-W, etc.



Let me know what you think.

This is pretty unreadable. I'd go down to single letters for the 
weekday headers, get rid of the add icons - the months should be about 
the same size as they are in the date picker. The day of the month 
should be the whole cell.



You're right that sidebyside is irrelevant in this view.

Oops! I just realized I goofed on creating the tar.gz file.  The 
directory kronolith/year is supposed to be in kronolith/templates/year



Just FYI.

Take a look at this and see what you think.  I'm gonna stay as far 
away from art as I can, so I ended up using the 'month.png' file in 
the tree_menu.



Also, I just picked a random color to show that there is an event on 
that day.  I guess a legend or something explaining that might not be 
the worst idea.



Lastly, I didn't include any of the $sidebyside stuff as I really 
didn't see a relevance, but I could be wrong of course.  I tried to 
clean up the code as best I could, so I apologize in advance for any 
errors :)



If there's something you'd like me to change, just let me know as I 
have no problem doing so.



Thanks!

I suppose that if this doesn't utterly kill performance it'd be 
doable. A patch would help it get done, though.

Would be nice to add a Yearly View to the views.   The way that Palm 
and other calendar programs do it is to just highlight the days that 
have an entry, which I think would be the best way to do it as 
actually displaying entries would be impossible.



Thanks.



-Mike