Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: new feature that allows changing the time interval to 30 minutes. (close #1426) #1426

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

LuckyBressan
Copy link

Please check if the PR fulfills these requirements

  • It's the right issue type on the title
  • When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes/features)
  • Docs have been added/updated (for bug fixes/features)
  • It does not introduce a breaking change or has a description of the breaking change

Description

Hello, how are you?
I am very grateful for this calendar tool that you have developed, and today I would like to offer a new feature. This feature would be the ability to change the default 30-minute interval used for selections, event movement, and adjustments, to a customizable interval for developers, all through a new week option.


Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

@Zyron
Copy link

Zyron commented Oct 16, 2023

Love it! 😍

At my university lectures starts 15 minutes past the hour, so the ability to drag and drop at 15 minutes intervall will come in handy!

Google calendar supports moving events at 15 minutes intervall, so great that this now also is possible with Toast UI.

@mpsijm
Copy link

mpsijm commented Jan 6, 2024

This is exactly what I needed 😄 Referencing #187 here, since it looks like this PR fixes that issue 🙂

I've tested this in the Calendar widget in Grist. My steps were:

Diff for grist-widget/calendar

Note that this diff also contains a small change to the CSS in the Grist widget, to make sure that 15-minute events do not overflow. This is related to #563.

diff --git a/calendar/index.html b/calendar/index.html
index 39b479d..da2d6ed 100644
--- a/calendar/index.html
+++ b/calendar/index.html
@@ -1,7 +1,8 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
-    <link rel="stylesheet" href="https://uicdn.toast.com/calendar/latest/toastui-calendar.min.css"/>
+    <link rel="stylesheet" href="./toastui-calendar.min.css"/>
     <link rel="stylesheet" href="https://uicdn.toast.com/tui.date-picker/latest/tui-date-picker.css" />
     <link rel="stylesheet" href="https://uicdn.toast.com/tui.time-picker/latest/tui-time-picker.css">
     <link rel="stylesheet" href="screen.css"/>
@@ -68,7 +69,8 @@
   })();
 </script>
 <script src="https://uicdn.toast.com/tui.date-picker/latest/tui-date-picker.js"></script>
-<script src="https://uicdn.toast.com/calendar/latest/toastui-calendar.min.js"></script>
+<script src="./toastui-calendar.min.js"></script>
 <script src="https://unpkg.com/i18next@23.5.1/dist/umd/i18next.min.js"></script>
 <script src="https://cdn.jsdelivr.net/npm/i18next-http-backend@1.3.1/i18nextHttpBackend.min.js"></script>
 
diff --git a/calendar/page.js b/calendar/page.js
index 79b0eaf..440234f 100644
--- a/calendar/page.js
+++ b/calendar/page.js
@@ -147,10 +147,15 @@ class CalendarHandler {
     return {
       week: {
         taskView: false,
         dayNames: [t('Sun'), t('Mon'), t('Tue'), t('Wed'), t('Thu'), t('Fri'), t('Sat')],
+        timeStep: [0, 15, 30, 45],
       },
       month: {
         dayNames: [t('Sun'), t('Mon'), t('Tue'), t('Wed'), t('Thu'), t('Fri'), t('Sat')],
       },
       usageStatistics: false,
       theme: this._calendarTheme(),
diff --git a/calendar/screen.css b/calendar/screen.css
index 9ad7212..e278449 100644
--- a/calendar/screen.css
+++ b/calendar/screen.css
@@ -91,6 +91,11 @@ body {
 
 .toastui-calendar-timegrid {
   height: 100%;
+  min-height: 1500px;
+}
+
+.toastui-calendar-event-time {
+  min-height: 14px;
 }
 
 /*** BEGIN popup-related styling ***/
  • Host the custom Calendar widget somewhere publicly and use its URL as custom Grist widget

I probably haven't tested everything, but dragging and dropping the events to change the start/end dates works correctly at least, so that makes it usable for me 😄

One remark for the week.timeStep setting: would it make sense to make this setting only a single number, indicating the number of steps, assuming that every step has the same length? This could then be called timeStepsPerHour instead of timeStep. The default setting would then be 2, and a setting that would currently look like timeStep: [0, 15, 30, 45] would be written as timeStepsPerHour: 4.

@LuckyBressan
Copy link
Author

This is exactly what I needed 😄 Referencing #187 here, since it looks like this PR fixes that issue 🙂

I've tested this in the Calendar widget in Grist. My steps were:

Diff for grist-widget/calendar

  • Host the custom Calendar widget somewhere publicly and use its URL as custom Grist widget

I probably haven't tested everything, but dragging and dropping the events to change the start/end dates works correctly at least, so that makes it usable for me 😄

One remark for the week.timeStep setting: would it make sense to make this setting only a single number, indicating the number of steps, assuming that every step has the same length? This could then be called timeStepsPerHour instead of timeStep. The default setting would then be 2, and a setting that would currently look like timeStep: [0, 15, 30, 45] would be written as timeStepsPerHour: 4.

I'm glad that my change can help you in your project. 😁
I hope more people can see this pull request and use the branch in their own plans.

Regarding the configuration idea...

At the time I made the changes, I must have been quite distracted not to have simplified it this way. 🤣
I'll take advantage of the fact that you reminded me of this and update the code.

Thank you for your comment. 🫡

@ixeft
Copy link

ixeft commented Feb 6, 2024

I think your way of setting timeStep is more powerful : someone might want to be able to authorize moving by intervals of 10min and by intervals of 15min. timeStepsPerHour does not allow that while timeStep does (timeStep: [10, 15, 20, 30, 40, 45, 50]

@LuckyBressan
Copy link
Author

@ixeft
You are correct; the initial change is indeed more liberal/powerful in these terms. However, why not simplify? As soon as possible, I will try to update the PR so that if someone sets a value in the timeStepsPerHour attribute, the code will use that value; otherwise, it will use the timeStep. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants