Plans to merge with the official one?

[MHumm]

Would it be possible to merge this somehow with the official one (or some other "teaming up" with the authors of the official one) and with this create a version which can be used for both: VCL and FMX? Or at least a version which can be side by side to the VCL one?

If you help the official authors I guess they'd help you/discuss etc. how to make it one single package for both frameworks,

[livius2]

Hi

i am more then interested, but it must be on both sides.
I have created pull request JAM-Software#839
Joachimmarder do some initial steps but stopped as he do not like ifdefs. I do not see any other way then ifdefs in such big unit.

I also have stopped to merge commits back to my port. I must see some plans to merge to do some more work.
Without this it is useless. I use my fork for my needs and it work i do not need more.
But to have it fully working with all VT features it must take more attention.

Hope that in the future it will be merged.

[joachimmarder]

I still think there FMX version of Virtual TreeView should be a fork. Doing this in a single source will be very challenging, all those necessary $ifdefs are a pain. Embarcadero created FMX for a reason and also did not try to do it in a single source together with VCL.

I can't simply accept some monster pull requests without reviewing them, as this may affect the overall stability of Virtual TreeView. But I currently can't invest more time in VTV beyond the maintenance of the VCL version.

[livius2]

I still think there FMX version of Virtual TreeView should be a fork

This is to big pain. Try to merge your commits to the fork then you will see that this is bad way to go.
Only merged single source code is possible to be maitained.

I can't simply accept some monster pull requests without reviewing them, as this may affect the overall stability of Virtual TreeView.

I understand this well. But previously i have take really long care to not breake/change the logic of VCL version as this was my priority first. Next steep is to fix FMX version to work as VCL with only minor acceptable differences.

[MHumm]

What about creating a git submodule containin all that code which is common to both and VCL and FMX version simply use or inherit (depending on what it is) that?

[joachimmarder]

This is to big pain.

I think the pain of a single source with tons of $ifdefs is too big.

What about creating a git submodule containin all that code which is common to both and VCL and FMX version simply use or inherit

I don't think this will work very well because Virtual TreeView wasn't designed very modular. But it's all open source, so you are free to start.

I will accept small and clear pull request that focus on a single task, like replacing the type Integer with the alias TDimension.

[livius2]

It take long time in replacing by TDimension in good way but maybe i can find some time..
But what next? It cannot be changed in simple parts but only as a whole to be compilable on FMX. And we will back to the work already done.

But even if i will try to do it in some parts i am not so experienced in github and i do not see a way to provide separate pull request when i have one not accepted and repository forked with work in progress.
Only second fork from most recent code have any sense if i will "start" from beginning like TDimension replacement.
But i see no way to create second fork on github..

[MHumm]

What would be needed to be done to make both instalable/active at the same time in the IDE as this currently seems not possible?

[livius2]

What would be needed to be done to make both instalable/active at the same time in the IDE as this currently seems not possible?

You can install it in the IDE but you cannot have both VCL and FMX installed simultanously.
If you need to install FMX version read description
helpfull can be also my answer to similar question here:
#7

summary from description:

To test FMX port of VT - you must add in the e.g. Delphi project->Options->Conditional defines VT_FMX. There is only package for Delphi Tokyo (but you can test it from the code). Remember to add also to uses clause unit VirtualTrees.FMX.

[joachimmarder]

It take long time in replacing by TDimension in good way

Sure, yet someone has to do it. Issues will occur because current code uses signed and usinged types. It would be easier in a fork.

But what next?

Everything that is specific to VCL or Windows need to be extracted in a virtual method.

It cannot be changed in simple parts but only as a whole to be compilable on FMX.

Yes, to avoid monster commits you need to gradually refactor the code towards platform independency. It will take a while until the code compiles under FMX. It will be faster in a fork.