My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 201: Arbitrary differing slotMinutes increments
13 people starred this issue and may be notified of changes. Back to list
Status:  ExportedToGithub
Owner:  ----
Closed:  Aug 2015


Sign in to add a comment
 
Reported by rickcur...@gmail.com, Nov 20, 2009
At the moment there is support for only 1 slotMinutes increment, however it would be great to be 
able to use 2 or more alternating values. I would like to use fullcalendar for a project but it requires 
events to be displayed using a number of alternating increment values such as:

10
7/8
8/7
8
6
7/7/7/7/7/7/7/11

(Yes, that last one is a genuine scheduling requirement for one user of the system I have built!)

I appreciate that the single value increments I've listed can obviously be catered for already within 
fullcalendar but I've included them just to show the range of increments I'm intending to use. To 
clarify only one of these increment values would be used at a time on any single calendar view.

Does this feature exist already? If not I will look into adding it myself but obviously I'd like to keep 
using the standard fullcalendar plugin in order to keep it up to date.

Thanks for the great plugin!
Nov 27, 2009
Project Member #1 adamrs...@gmail.com
hello. fullcalendar currently can't do anything like this. when you say "8/7" do you
mean there would be a slot at 12am, 12:08am, 12:15am, 12:22am, etc?

you'd probably want to specify when the first line happens, because i'm assuming you
wouldn't want it to always start at midnight, right? (if so, it is in the pipeline:
https://code.google.com/p/fullcalendar/issues/detail?id=205)

but back to your original request, this sounds like it might be useful to other
people, but i have to think a little bit more about the best way to do it.
Labels: -Type-Defect -Priority-Medium Type-Enhancement
Nov 27, 2009
#2 rickcur...@gmail.com
Hi, yes you're right, the multiple increments would require specific start and end times. You're exactly 
right about the timings being like 12.00, 12.08, 12.15 etc. In that example the increments fit within the 
space of an hour, but some would be non-standard like the 7/7/7/7/7/11 increments I mentioned in my 
original post. 

If you can cater for these that would be awesome!

Thanks,

Rick
Dec 21, 2009
#3 rickcur...@gmail.com
Hi,
 Great to see the start and end time parameters added in the recent release. Do you think there's any likelihood 
of seeing multiple increments supported down the line? 

Cheers,

Rick
Oct 7, 2010
Project Member #4 adamrs...@gmail.com
(No comment was entered for this change.)
Status: Maybe
Aug 13, 2013
Project Member #5 adamrs...@gmail.com
(No comment was entered for this change.)
Summary: Arbitrary differing slotMinutes increments (was: Can we have Multiple slotMinutes increments)
Status: Accepted
Labels: -Type-Enhancement Type-Feature
Aug 15, 2013
Project Member #6 adamrs...@gmail.com
 Issue 1701  has been merged into this issue.
Jun 5, 2014
Project Member #7 adamrs...@gmail.com
By the way, this pull request, mentioned in a previously merged issue, is pretty good:
https://github.com/arshaw/fullcalendar/pull/94
(via @Ne0x)
Jun 7, 2014
Project Member #8 adamrs...@gmail.com
 Issue 2107  has been merged into this issue.
Jun 11, 2014
Project Member #9 adamrs...@gmail.com
 Issue 2181  has been merged into this issue.
Aug 19, 2014
#10 danielb...@gmail.com
Is there any update on this? PR #94 seemed pretty promising, is anyone working on this?
May 26, 2015
Project Member #11 adamrs...@gmail.com
 Issue 2498  has been merged into this issue.
Jun 18, 2015
#12 DutchSp...@gmail.com
Is anyone working on this? PR #94 seems to be good but is somewhat dated (2 years ago - version 1.6.1) and doesn't support day view.

If no one is working on this I can try to implement this by myself. (Only I don't have much experience with JavaScript or jQuery)

I think it should be manageable in `TimeGrid.js` at `slatRowHtml:` but I'm not sure.

I hope that this feature is added soon.
Jun 18, 2015
#13 danielb...@gmail.com
I had two students of mine take a quick look at implementing this feature, but it was probably out of their abilities. I would really like to see this feature implemented.
Jun 19, 2015
#14 kleisa...@gmail.com
I started to work on this.
Live demo: http://kleisauke.nl/fullcalendar/demos/timeslots-views.html
GitHub fork: https://github.com/kleisauke/fullcalendar

I've implemented the left timeslot axis, which can be set using `slots: [{start: '07:35', end: '08:20'},{start: '08:25', end: '09:10'}]`.
The events are currently displayed at the wrong time. I'm not sure what is causing this but I think that the calculating inside of `computeTimeTop:` (at `TimeGrid.js`) needs to be fixed for usage with custom timeslots. (I hope that someone can help me with this)
Jun 23, 2015
#15 danielb...@gmail.com
I can see that you've added some code which corrects the rendering of events, is the demo now out of sync?
Jun 23, 2015
#16 kleisa...@gmail.com
Demo is not out of sync, did you try another browser or to clear your cache?

I've now also added some code to support dragging and resizing correctly. Dragging between day and all day events still needs to be fixed. Also resizing all day events needs to be fixed.
Jun 23, 2015
#17 danielb...@gmail.com
Sorry, works now after hard reload.

What about events which don't start/end at the respective slot start/end times? For instance, if there were an event starting at 13:00 and ending at 15:00?
Jun 23, 2015
#18 kleisa...@gmail.com
Currently is that not working correctly, I've added it to the demo if you want to see it.

For my purpose the times always start/end at the timeslots also if you resize or drag it (then it snaps on the timeslot and skips the breaks).

If you want, I can try to correct the calculation in `computeTimeTop:` if the times doesn't start/end at the timeslot.
Jun 23, 2015
#19 danielb...@gmail.com
It would be useful in my case, and probably in other cases as well.

Thank you very much for taking the time to implementing this!
Jun 25, 2015
#20 kleisa...@gmail.com
The calculation in `computeTimeTop` is corrected if the times doesn't start/end at the timeslot. Also resizing all day events is fixed and dragging between day and all day events is fixed.

I've also implemented a new `snapOnSlots` option if this option is set to true then it snaps on the timeslot while dragging/resizing. If it's set to false then it snaps not on the timeslot but it snaps to the duration what is set in `snapDuration` (default half an hour).
Demo without snap on timeslot: http://kleisauke.nl/fullcalendar/demos/timeslots-views-without-snap.html
(It throws sometimes `Uncaught TypeError` exceptions while dragging, I've to fix that)
Jun 25, 2015
#21 danielb...@gmail.com
The drag seems to be slightly buggy. For instance, if I drag the 7:35 - 9:10 event (Fri 2/13) to the *middle part* of the 10:15 - 11:00 slot, it will snap to the 11:05 - 11:50 slot instead.

But otherwise, great work!
Jun 25, 2015
#22 danielb...@gmail.com
OK it is even more specific than that: if I grab the event at the top, this bug doesn't manifest itself. It only does so if I grab the event box around the middle. This is not a showstopper.
Jun 25, 2015
#23 kleisa...@gmail.com
Thanks for your bug report!

I can reproduce this bug and I think I know where it goes wrong. At `computeSlatTops` there is some top position calculation without breaks. If we have `snapOnSlots` to false we need to change this calculation to support breaks.

Can you check this demo which doesn't have any breaks?: http://kleisauke.nl/fullcalendar/demos/timeslots-views-without-snap-and-breaks.html
Jun 25, 2015
#24 danielb...@gmail.com
Checked it, seems to be working just fine.
Jun 26, 2015
#25 kleisa...@gmail.com
I've fixed this bug, dragging/resizing works now correctly when `snapOnSlots` is set to true or false.
Jun 29, 2015
#26 danielb...@gmail.com
Will you issue a PR for the original project?
Jun 30, 2015
#27 kleisa...@gmail.com
A pull request has been made for this at https://github.com/arshaw/fullcalendar/pull/238
Aug 21, 2015
Project Member #28 adamrs...@gmail.com
Discussion for this issue has moved to the following URL:
https://github.com/fullcalendar/fullcalendar/issues/472

This is because Google Code is shutting down. Apologies if you are being pestered with these notifications. This is a one-time event.

Happy coding,
Adam
Status: ExportedToGithub
Sign in to add a comment

Powered by Google Project Hosting