Allow variable precision on the Gantt graph #3759
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#3759
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "jackymancs4/vikunja-frontend:feature/precision-gantt"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello,
this one may require some discussion to get ready.
When the number of days displayed is below 5 (arbitrary value), it enables the hour precision mode of the Gantt plugin. This allow precise organization of the work day.
One side effect of the PR is that it enable minute-level dragging precision on all views of the Gantt, removing the snapping effect even when viewing months long charts.
Tech notes
:chart-start
and:chart-end
both allow using native dates object. I'd like to use those instead of the string conversion also removing:date-format
.I would like to consolidate the Kebab related function in single file, and export what's needed from there.
Docs
https://zunnzunn.github.io/vue-ganttastic/examples.html#simple-hour-chart
With the old chart, we had a switch for that. I like your solution better.
I'm not entirely sure why we're using string dates instead of date objects. IIRC the library only supported strings back when we added it. I'm all for using date objects.
Do you have an idea on why that might be? We should keep the current behaviour. Maybe this could be made depending on the mode?
Great!
Will do.
I do. The snapping behavior was not a feature of the plugin, but a by product of those two lines:
and the capping behavior of
isoToKebabDate
If those two lines are restored, I cannot drag bars with sub-day precision even in hour mode.
You sure? I don't dislike the new behaviour.
Can be. The current problem in my tests:
I think that the snappy behaviour is inherently incompatible with a minute-level precision.
I may have found a solution based on 24H offsets when in day mode, but le me know if we can get away without it.
WIP: Allow variable precision on the Gantt graphto Allow variable precision on the Gantt graphHi jackymancs4!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://3759-feature-precision-gantt--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
The problem is the precision: When dragging without snapping, the tasks will grow in size as they are rounded to the next day. This could be a bug in the library but it's something we need to work with.
I think we should keep the day-level precision when all you can see are days and do something like 15 minute or hourly interval precision when you can see more. It will not be detailed enough anyway to reliably set minutes by dragging the task.
My last commit restore the snappy behavior on day precision mode. I'm fairly happy with the result. It's ready for review.
Awesome, I'll check it out next week when I'm at my computer again.
@ -146,0 +154,4 @@
const startDate: Date = new Date(e.bar.startDate)
const endDate: Date = new Date(e.bar.endDate)
if(task && ganttChartPrecision.value == 'day') {
Can we make
'day'
aconst
? And please use strict comparison.Looks like the snappiness is not present anymore.
I just tryied it on https://3759-feature-precision-gantt--vikunja-frontend-preview.netlify.app and dragging a bar snaps it to the closest day column.
Doesn't seem to work for me:
Can you describe what behavior do you expect?
What you screencasted is pretty much my definition of snapping.
Here's what I expected (current behaviour on try):
So snapping on drag instead of on release is a requirement for the PR?
Or are you referring to the potential enlargement of the bar when dragging it whole?
Both actually, it should keep the same behaviour as we have currently wrt snapping and not enlarge the task.
Hey @jackymancs4 do you still want to implement this?
Closing this due to inactivity. Please reopen or ping if you're still interested.