Marquee 3.0

[MarcelGarus]

I'm thinking about rewriting the Marquee widget to use a custom RenderObject (lower-level Flutter API) so that it cannot only scroll text, but arbitrary widgets. That would also fix #7, #9 and #14.

[MarcelGarus]

Hi, everyone! As you may have noticed, it's been some time since I focused on this package. There have been lots of other projects for me to focus on, but in the next few weeks, I plan to focus on this one a little more.

Dart's NNBD requires a rewrite of this package – Marquee 2.0. That's a breaking change, so I'll also use the opportunity to revise the API to make the package more customizable. The logic of this widget is quite low-level, so it makes sense for it to be implemented as a RenderObject rather than only a composition of other widgets. This would be more efficient because the children only need to be laid out once. It would also allow arbitrary widgets as children. I'll try to get a prototype of this up and running.

Here's the plan so far:

• Split the widget up into a MarqueeController and the widget itself. Planned features for the controller:
  • More comprehensive planning of how the widget will scroll.
  • Manually starting and stopping it.
• Plans for the Marquee widget:
  • Horizontal and vertical scrolling.
  • Support LTR and RTL.

[msarkrish]

@marcelgarus waiting for the support of using other type of widgets with marquee.

[sambitraze]

Urgently need the scroll controller support so that marquee can be paused and played by user

[MarcelGarus]

If you're wondering what has been happening so far: Not so much. Some other things came up, so I put off working on this again. I did some thinking about the future of this package, and to be honest, I'm not totally sure about it.

I'm currently not using this package in any of my projects, nor am I planning to in the near future. I'm sorry to all people who depend on this package for their production apps, but in the end, this project was developed by me in my free time and I don't enjoy working on this project in my free time as much as I enjoy working on other stuff, like creating a new document format or programming language.

Looking forward, I think it's best to change this project from being developed by an individual (me) to being developed by the community. First of all, I'm looking for contributors. If you're interested in working on this, just write a comment here and I'll be happy to add you as a collaborator. Although above I made it sound like working on this package is boring, the new architecture is actually a great opportunity to dive into the internals of Flutter and get your hands dirty with RenderObjects.

In the meantime, version 2.0 is published, which adds null-safety to the current architecture. Thanks a lot to @Konrad97 for this contribution.

[konradrvl]

Hey everyone, hey @marcelgarus,

first of all, thank you for this awesome package, I have been using it in an app i built for about a year now.

Im using open source software everyday and have been thinking about contributing more to open projects like this one. I think this would be a great fit for my first long term relationship with an open source project.

I would be happy to join as a collaborator and (when time allows it) work on the project.

[MarcelGarus]

Glad to hear that! I invited you to the repo. If you want to, feel free to tinker around with a new API on a new branch.

[aytunch]

@marcelgarus thanks for this package and your transparency on the future of the package. I loved the marquee 3.0 roadmap. This package allowed us to make our UI feel "Alive". However when we navigate to another page, the marquee's kept on animating thus creating jank. We need the controller for this. Also sometimes as you have suggested we need other widgets than String's to animate.

Have you found any contributors willing to work on marquee 3.0? This would be awesome if implemented as designed above.

A question: Would using RenderObjects make the package more performant? We use marquees over the videos in our app.

[MarcelGarus]

Hi @aytunch,

sadly, I haven't found any contributors that are willing to invest the time and effort into rewriting this package. If you really need this functionality, I would of course gladly accept your contribution. 😊

Using RenderObjects would indeed make the widget more performant – currently, it calculates how often the text will be seen at most and then simply uses a Column to put multiple texts in the Marquee. If you have a small text, this means that many Text widgets are created. If we would have a RenderObject, we could only render one text and then copy the drawing instructions / pixels until it fills the space.

[rasitayaz]

any plans on implementing this feature (custom widgets inside marquee) in the near future? i would be interested in contribution.

[MarcelGarus]

Oh, nice! Feel free to fork the project and code up a prototype. After we merged it, I can also add you as a contributor so you can maintain the code.