-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
Modular architecture with support for different layouts #17
Comments
Hello, i've testing your library to use on my app (salon booking app), the one of the missing features in many calendar libraries is the swimlane or resource time grid like in fullcalendar (https://fullcalendar.io/). Soon as possible i want study the code to help you on something. |
Thanks for your feedback! That really looks like an interesting feature I'll keep my eye on. I've added the timeline layout to the issue description. Resources themselves could be natively supported by all layouts. Depending on the final modular architecture, this can probably be achieved in a backward-compatible way, so it'll probably be implemented afterward. |
[ STACKING EVENTS ] I see 2 options here:
|
@JulianKowalczuk If an event starts less than 15 min after another event, both events are shown next to each other. If the difference is 15 min or more, timetable overlaps the later event over the earlier event. If that behavior doesn't work in your app, please open an issue, preferably with a screenshot. Regarding option 1: I've created #31 with a suggestion of two additional theme properties for better customization of the stacking/overlap behavior. Would that solve your problem? If not, please comment on that issue. Regarding option 2: You can already achieve that behavior by collapsing overlapping events into a single, special event, and have your |
Ok, I found in "minStackOverlap" variable in date_events.dart and I guess that's the variable You mentioned. |
@JulianKowalczuk Please see #31, the property |
How is this going? I'd love to support you to enable modular layouts. How ever this seems quite challenging without in depth knowledge of the library. Is there anyway to support this by tackling a part of the overall solution? |
I'm sorry for the long delay. Exams at my university are now over for this semester and only a few days of seminars left, but I just started a new job. I really hope the coming weeks won't be so full and I (finally!) started working on this issue. @raLaaaa I'll first have to write the underlying structure for the new design, but when the first layout is working, you could contribute other layouts or have a look at implicit animations between them (where I'm not sure how they'll be implemented). |
Glad to hear things are going well! Completly makes sense! Let me know if you see a possibility how I could support you. |
any update on this? would love to have support for the timetable to show only a single day as opposed to a whole week. |
Sorry for the delay and for not keeping this up-to-date. I've recently started this rewrite, and as part of that, also migrated to null-safety and dropped the time_machine and dartx dependencies (which wasn't migrated at the time). This rewrite isn't done yet, but I've already managed to overcome the major blockers (visible as layout overflows in the old app). |
Nice to hear! Will the rewrite be downwards compatible? Since you were talking about removing time_machine this sounds like some changes might be required if you want to upgrade to the newest version? |
This will be a breaking change, but I hope it's worth it by offering much more control over the design and supporting more (or custom) layouts. |
First of all: Thanks for letting all of us know about the upcoming change! :) However, I have one question: Are we somehow able to track the progress of the rewrite? I am looking forward to the null-safe update and it would be very nice to see how things are going. Maybe the community might contribute at some point as well, so it might be a nice thing to see the source code in either in another branch in this repo or in a separate one :D |
I've pushed the new changes to the The The former To provide events, you only have to supply a Hours theming / overlays are also in progress, addressing #26 and inspired by TatsuUkraine#3 (though adapted to work similar to how events are now supplied). I'm currently planning to also address #46, #63, and #64, and look into #21 and #36. Globalization is already working, hopefully simplifying #23. As mentioned in a previous comment, this new version no longer depends on time_machine but rather uses the built-in If you want to try out the new version, have a look at the included example app which is kept up-to-date, but keep in mind that the new API is not yet stable. Also, the documentation is currently out-of-date. Please let me know if you have any feedback :) |
Update: In addition to the previous post, I now have a working solution for the combination of Hours theming / overlays as requested in #26 is/are also working. #46 is also done. I don't yet have a good solution for #63, and would like to address/enable #64 (which is harder to achieve with the new architecture) and look into #21 and #36. Also, styling properties still have to be exposed from most widgets in a unified way. I'll try to get the API stable and release a new version very soon. |
@JonasWanke you going to use inherited widget for this or like params in timetable widget? |
@TatsuUkraine I've removed the The styling is, however, split into different classes for the individual components instead of having all properties in a single, huge class. |
@JonasWanke I see. Was thinking that inherited widget could be quite useful in terms of global styling or scoped styling. So you could define default theme somewhere on MaterialApp level to keep it as close as possible to all your theme variables. And in the same time - give ability to override only needed stylings on usage level. Also might be much easier to use if you have some sort of user settings that can affect time table styling |
I think it could be quite handy to have both (and props and inherited widget) like flutter team has for most of they're widgets that have styles |
@TatsuUkraine Okay, that makes sense. One inherited widget for every component would probably be too much (there are currently 16 of them), but maybe one per layout or a single, global theme with properties applying to multiple layouts would be good 👍 |
@JonasWanke agreed, flutter team has 1 main built-in inherited widget for all in most cases at least - |
First of all, thank you for all effort you put into this library it is pretty awesome! I have one question: will it be possible to build some sort of "recurrent event layout" with this refactoring? Like having the current week fixed (disable horizontal scroll) and list a particular event set. Pretty much like in this image: |
I can try to make this possible (something similar has already been requested before in #36), and that might even work with pure styling and no extra widgets. Since my last update above, #21 is working, and I've also added a separate widget for month-based navigation (like the one the Google Calendar app for Android shows when you tap the month in the app bar) that can work together with the main widget. Remaining steps until the release are:
|
Time for another update: Theming/styling is implemented, and a recurring layout (as requested above and in #36) is now supported as well. I've also been able to address #64, though there are currently two small bugs that will be fixed when using a Flutter version with Default Scrollbars on Desktop. I also did a bit of cleanup and started writing documentation. I'll probably postpone fixing #63 to after the release, so all that's left is some more cleanup and writing documentation! |
@JonasWanke is your current branch with updated package more or less stable? |
I'm asking, because if it's stable, and has just a few bugs (maybe you can share what are they) I can try to install new version in my project to start using it, and report about any problems that I find |
More or less stable ;) I hope that the current architecture is final for the release, but during cleanup or creating the documentation, I might still find some places where I'll have to do minor breaking changes. Bugs: When zooming in/out in a day, the scrollbar is only updated when that zooming also contains a change in the scroll offset. Also, two scrollbars are displayed when scrolling – on in the events area, and one on the left over the time indicators: I've created a draft PR containing all changes: #69. Feel free to report any issues you find directly over there. I also just pushed the current documentation updates. The README already has most parts done, though some are still marked as todo or outdated. (And links don't work yet because the online API docs are only generated when the package is published on pub.dev.) But be careful with documentation comments, as those may be outdated. |
Initial documentation is now available and some remaining bugs were fixed. The new version is now published: v1.0.0-alpha.0. This version should be mostly stable, but I'd prefer to wait for a bit before publishing this as a stable |
Hi Jonas, |
@renatoufsm No, unfortunately, and I don't think I'll have the time to add them anytime soon. I'm open to contributions, however :) |
I plan to revise the layout and theming possibilities of this package, mainly with the following goals in mind:
My idea is to implement the layouts mentioned above as separate, stateful widgets so they can e.g. manage their scroll position on their own. They will have more parameters, e.g. a customizable date header widget builder in the multi-date widget. (Currently you can change the pattern, decoration and text style of the day-of-week/-month indicators individually, but not their padding or disable one of them.
The currently used subcomponents like
WeekIndicator
,MultiDateBackgroundPainter
, etc. should get a stable API and be exported.Implicit animations are inspired from material's
ShapeBorder
in that each layout can provide alerpTo
orlerpFrom
for layouts it supports animating to/from.Feel free to add a comment if you have ideas for different layouts, wishes for exposed properties/widgets, or feedback for anything else :)
The text was updated successfully, but these errors were encountered: