I reverted to much simpler times. One of the things that irked me is that I’m displaying a month/year on the calendar when it’s displayed right above it in the clock module. So, I made it optional. One can choose to turn off the header or leave it on. For those of you who don’t display the clock (or who put it elsewhere), it’s helpful to leave the header on, but if you have the clock enabled, there’s no sense in adding the month and year right below it again. This trims the header and keeps a clean interface.

And I left the ability for the end user to create a custom CSS file and modify the look (I turned the header back on for this preview):

In the above example, the custom CSS added a bullet point in between the month and year (which does not exist in the default CSS), made the year digits brighter, and colorized the current day. There are several nested elements that will allow the user to customize how they want their calendar to look. I’m looking at you guys who also have a colorized version of the weather module. :)

CSS styling can be changed by anyone. At this point I’m just playing with it whenever I take a break from actually writing code. There are still bits of code that I don’t like. The trouble with being OCD.

And after a quick rewrite to use Moment.js instead of cumbersome Javascript calculations, I also did a bit of styling. I opted not to go the CSS route because the reality is, this is table-worth data, not CSS. It solves a lot of headaches to be honest. I did incorporate proper language translations. It just reads your locale and uses that.

• Still to-do is allowing for a Sun/Mon start of the week.

@idkmynameiskyle, yep, though again, I look at the amount of information one could possibly have on any given day and how to format things neatly and visible.

As an example, if I look at my Google calendar and pick one week (this week), this is what it looks like:

Notice the '+7 more' line that I pointed out. I can’t see those in a standard weekly view. I have to either click on the link there, which trigers a pop-up with the remaining items, or switch to a daily view to see it all.

Again, this is me personally. Your calendar may not be as crazy populated as mine (and I even turned OFF two others for this.) But I have to think of the possibility that someone might have multiple events in one day, specially in a family setting where everyone is doing their own thing.

One thing at a time @billp100. Your request is still in my queue. I did this yesterday because it was on my mind and it’s easier for me to just write the code out while I’m thinking about it, than it is to just ponder ideas and stick to my ‘I shall not write code this long weekend.’ mantra. So yeah, it happened.

Basically, this is what I have in my queue:

• compact monthly view of a calendar (what I’ve done above and still being worked on)
• full screen width calendar with events populated (this has issues I’m trying to address)
• a running week of events (somewhat in progress already)

For the issues I’m referring to above, I look at my own calendar and days where I have so many things going on that it will not all display in the allowable space. On a regular computer, you can click to expand the day and see it all. You can’t do that on a default, touch-free MM install. Adding that ability now relies on the user also including a touch screen, or a mouse to navigate the calendar. To me it does no good if I have a calendar where I can not see all the events.

Now, this may not be an issue for you specifically, but I have to think of the over all population and every possible scenario and how to address them. So yeah, I’m still working on that and trying to figure out a (better) solution.

The better question is, what’s the preferred display, something small and in the corner, or having it take up the full width of the monitor? I’m of the school where I want small, concise and not taking up all the space. However, this isn’t about me, it’s about the user. :)

I think I will pull it out of the default calendar module and keep @MichMich’s default calendar implementation as-is, while I push this into a different module. I need to figure out what to call it, or how to make it work with the other one without breaking things. Having made the decision to pull it out of the default module also means I can easily integrate other features without causing too much bloat on the default one, such as a weekly view version.

And yes, having the week start on Monday vs. Sunday is easily implemented …

I said I was not going to write any code this weekend. Really, I did. But when thinking of a simple calendar display, it was way easier for me to just sit down and fiddle. This is still in its infancy, but this is what I’m working on for now. It’s a simple, empty calendar display with nothing other than today highlighted. It is still the same (default) calendar module. You just pick which you want displayed, either a blank one, or one where you configure your calendar URLs for it to fetch the data. At least, this is what I did for now. I may end up pulling it out and into a separate module, together with the weekly display one that I’m also working on.

There’s no formatting present, in fact it’s all done with tables, something I am going to change as I really don’t like tables. Much easier to format when you’re dealing with CSS elements. But at least I can give you a taste of what it looks like so far.

Just the blank calendar:

And if I stack them:

Comments/Suggestions/Requests/Questions … let 'em rip.

Things still todo:

• Replace table with CSS elements
• Allow for proper language translation
• Cosmetics

With the majority of you saying it’s working with the above change, I went ahead and made a pull request against the branch. When @MichMich has time, he’ll review and merge. I’m still waiting to hear from @andy952 to see if there still is a problem.

@andy952, can you send me your calendar link privately and I’ll test it out on my system, see if I find any errors.

@garnett, both public and private Google calendars work. I have both displayed on mine.