[Blama]

Hi Isomorphic,

thanks, I'll wait for a new build and retest.
To clarify, with 1) (new events after the 1st are always All-day) I meant in the Month-view. The logic of where the click is decides the type works as you say in Day and Week-view. In Week-view even for multi day events.

And also for 3) dynamic height of the longEventsLayouts I was taking about the Month-view (like in the video in #18). The current size increase in Day- and Week-View makes sense to me and also looks good.
If you also were taking about Month-View: Is there a difference between Normal and All-Day events in the Week-view, apart from the design? I don't think there needs to be w.r.t. to placing. Here in google calendar the normal and All-day events are being treated equally and placed next to each other.



Best regards
Blama

[Isomorphic]

hi Blama, we've made some changes to address bad behaviors- on your points:

1. the issue of whether a cell-click (up and down in the same cell, even with movement) creates a long event (all day) or a regular event (within a day), is supposed to rely on where you click the mouse - if you click in the layout that houses the long events, it should open the eventDialog and create an All Day event - elsewhere in the cell, it should open the eventEditor and create a regular event. We'll take a look at whether this is a bug with area-detection, all-day detection or with it not resetting the All Day checkbox in the eventEditor

2/3. single and multi day event-dates are now validated as expected

4. hover not close to the mouse - you weren't seeing a link-hover here, but a cell hover, which happens as soon as the mouse enters the new cell and, by default, doesn't move until the hover-value changes - you can now set Calendar.hoverMoveWithMouse to true, and it will propagate to the individual CalendarViews, updating the hover more often and moving it with the mouse. We'll switch this on by default. If you wanted to test the idea, you can set hoverMoveWithMouse to true on monthViewProperties in your current build.

Fixes mentioned above are in the queue and will be in tomorrow's builds.

For your second section:

1. We already have the capability to simply show all events as "longEvents" in the monthView, that is, as canvases rather than links. We'll likely add a property to allow that, and styling can be made to look similar to Google's offering, but we won't go much deeper in that redesign unless we have parties interested in improving that aspect of the widget.

2. [All Day] disappearing from the ghost-canvas during drag is a bug - we'll fix it, likely for tomorrow's builds

3. on the dynamic height of the longEventsLayouts - by default, those layouts have a short default height, 10px, just to allow somewhere to drag-create long-events - when you start a drag, we create a ghost-canvas which is taller than that default short layout height, so we resize the layouts interactively in order to display the ghost-canvas without clipping. We already have a change locally to have longEventsLayouts have a minimum height of one longEvent-height, rather than 10px, which will prevent the runtime resizing you see. This should be in tomorrow's builds as well.

[Blama]

Hi Isomorphic,

wow, that's fast!
I also have general feedback (tested in Month-view):

- When you create an event and make it "All day", the next time you create an event, it's also "All day". I'm not sure this is on purpose.
- Single day events don't have validators "Time Start < End" and display with the selected Start time
- Multi day events don't have validators "Date Start < End" and just don't display on "Save Event"
- If you hover events from right to left in month view very quickly, the hover box is displayed too far right IMHO, not where the mouse stopped.



General month view design feedback:
- I like the "google calendar"-design of the All Day events very much. I'd say that it would look better for normal events if they also had a google calendar "chip"-design on hover.
- The "[All Day]" displayed for All Day events is removed on Drag and shows up again after Drop. This would look better if it was there the whole time.
- I'm not sure the dynamic height change of week rows with content is on purpose, but it is really confusing. A fixed height like in google calendar would look better IMHO, but perhaps you have reasons for this.




Best regards
Blama

[Isomorphic]

Thanks Blama - both issues have been fixed in 15.0, along with an optimization that prevents frequent updates of the ghost-canvas during drags, even when the dates hadn't changed.

Please retest with tomorrow's builds.

[Blama]

Here is an even shorter sequence of clicks also causing the issue:




Best regards
Blama

[Blama]

Hi Isomorphic,

the Drag-and-Drop issue happens eventually in Month-view.
Here is a video where you can see that the length of the two events is suddenly the same after drag and drop:



Best regards
Blama

[Blama]

Hi Isomorphic,

I can see that all the issues are fixed using SNAPSHOT_v15.0d_2026-02-19 here + allowLongEvents: true.

I noticed this issue:
The "Delete event" Button in the event details window does not work for "All Day"-events. It works for other events.

There is also a Drag and Drop event change issue, that I can't reproduce yet.

Best regards
Blama

[Isomorphic]

Following up - all three issues mentioned here have been fixed in 15.0 for tomorrow's builds, and autotests added.

We're still making enhancements and optimizations, and will port the whole back as far as 13.1 when we have everything addressed.

[Isomorphic]

On post #9, ah, in the WeekView - we see it now and will get it fixed today.

[claudiobosticco]

Deleting long events with the "X" of the event does not work.
I do not see any error message in the Developer Console log. Tested with FF147.

Hi Blama , you're right - in 13.1 it doesn't work in the week view (it works in month and day views, though).
I didn’t notice because I override eventRemoveClick in my application. Good catch!

[Blama]

On your post #6, from "put off by a few pixels", we were going to say that's the drag-area for creating long-events, like the vertical gap you see to the right of regular events - but of course "cut off" means something entirely different!

Sorry, I meant "cut off" of course.

Best regards
Blama

[Blama]

the close buttons seem to work fine, even in 13.1 - if you see issues, please provide more information

Hi Isomorphic,

retested here (SNAPSHOT_v15.0d_2026-02-06, also in v13.1p_2026-02-15, tested with FF and Edge, nothing in the Developer Console log):


Best regards
Blama

[Isomorphic]

No problem, we'll backport everything in the next few days - in the meantime, 15.0 has more recent code if you want to test.

On your post #6, from "put off by a few pixels", we were going to say that's the drag-area for creating long-events, like the vertical gap you see to the right of regular events - but of course "cut off" means something entirely different! :) We'll fix that top:-1px for events in the first row - it's not related to long-events, but it's been around for a long time.

[Blama]

We'll let the feature settle, then we'll announce it.

Hi Isomorphic,

sorry for the crossposts. Will wait a bit and looking forward to the blog post.

Best regards
Blama

[Blama]

Tops of normal events are put off by a few pixels, if they start at 0:00.