💥 Notifications got better.

[infinite-dev22]

Notifications package.
🔥 Notifications no longer create a custom separate stage for them to show rather use the parent application's stage.
🔥 No seperate windows created for notification system
✅ Top left corner nolonger blocked by notification stage window.

[palexdev]

@infinite-dev22 Almost ready to merge, there's just a little mistake that needs to be fixed, I left a comment

[infinite-dev22]

@palexdev Hope you are well, Sir. I didn't find the comment left on the mistake to be fixed. Thank you.

[palexdev]

@palexdev Hope you are well, Sir. I didn't find the comment left on the mistake to be fixed. Thank you.

Do you see it now?

[infinite-dev22]

Yes, good Sir

[palexdev]

@infinite-dev22 can you make the change by the end of the week, so I continue working/release?

[infinite-dev22]

Yes Sir, I can, Sorry for late response. Just a busy month for me. Let make the change

[infinite-dev22]

Though when I fetch the change seems to already exist

[infinite-dev22]

@palexdev, this has been resolved

[infinite-dev22]

Though a few questions about the change made, does the height have to be manually set. Can this be set to scale with the notifications.

[palexdev]

Though a few questions about the change made, does the height have to be manually set. Can this be set to scale with the notifications.

Long story short: no, it has to be done manually

More details: Maybe a solution could be found with bindings but the container for the notifications is a VirtualFlow, so every notification must have the same height. Not only that, since it uses the old VirtualFlow implementation, the size is not a property of the flow but must be hard coded into the cell class

[infinite-dev22]

More details: Maybe a solution could be found with bindings but the container for the notifications is a VirtualFlow, so every notification must have the same height.

I realized, I have tried setting the size automatically and the Notifications seemed to all be the same size as the first Notification displayed.
This then gets me to the next question, can the virtualflow be made(re written) to size according to its children dynamically with varying sizes just like HBox and VBox.

**Edit
I noticed this will be implemented in the future.

In the future I would also like to implement more complex Virtual Flows, one that doesn't care about cells sizes, one specifically for TreeViews and who knows what else.

[palexdev]

More details: Maybe a solution could be found with bindings but the container for the notifications is a VirtualFlow, so every notification must have the same height.

I realized, I have tried setting the size automatically and the Notifications seemed to all be the same size as the first Notification displayed.
This then gets me to the next question, can the virtualflow be made(re written) to size according to its children dynamically with varying sizes just like HBox and VBox.

**Edit
I noticed this will be implemented in the future.

In the future I would also like to implement more complex Virtual Flows, one that doesn't care about cells sizes, one specifically for TreeViews and who knows what else.

Yeah, easier said than done unfortunately.
There are several ways to implement it. It could rely on the 'infinite scroll' technique or it could use the 'cell size' property as the minimum size for each cell. The latter would allow us to use the same mechanism of the fixed one, with ranges and all, the layout and scroll would still be different.
There are also other ways that I can't remember now (it's 8AM here and I'm still sleepy) but none of them convince me at the moment either for performance reasons or feasibility reasons.
I guess there's only one way to find out, create a mock Node and test it interactively.
There's also another concern about the second solution I mentioned. Since we would use the 'cell size' as the minimum, which allows us to predict in the worst case scenario what the range of cells would be, it leaves me with the question "Would the user like this mechanism of minimum or is it too restrictive?"
It's also a bit of a performance hazard. What if the 'cell size' is set to be very small?

Long story short: VirtualizedFX things. are. complicated.