Refactoring VT?

[Vincent Parrett]

Any thoughts on refactoring VT so it's not one 38 K lines file? It would make it so much easier to work on, diffing changes faster/easer, make it possible to write unit tests etc. I know it's not an easy task, so much of the code makes use of friend access to private/protected properties, there are circular type references etc, but it can be done. 

I spent a day on it recently, I split it up to 23 files so far (it's not compiling yet, still refactoring, there will probably be more). Right now this is more of an exercise to see whether it's feasable and where the main problems will be. Is there any interest in this? 

[Joachim Marder]

Hi Vincent.

To be honest, not at the moment. I develop my projects in a different manner, but this is how it was when I adopted the project. It has some advantages though:

• Adding a VT control will always be sufficient to compile. No searching in which unit a certain type of an event parameter is defined.
• Easy switching between two versions
• It is a pain to add a new unit to all those Delphi and C++ Builder designtime and runtime package. This is a manual and very time consuming job.
• I learned that the users love backward compatibility and hate breaking changes. I will put new classes (like standard actions for VT) into new units, but I am reluctant to touch/move existing types.
  

I was and I am focusing on bugfixing (there have been a huge amount of bugs when I started and there are still many) and adding important new features. I have only a few hours per week I can spend on VT, and I want to maximize the positive effect of them for the users.

Best regards,

Joachim

2015-01-14 4:36 GMT+01:00 Vincent Parrett <vincent...@gmail.com>:

Any thoughts on refactoring VT so it's not one 38 K lines file? It would make it so much easier to work on, diffing changes faster/easer, make it possible to write unit tests etc. I know it's not an easy task, so much of the code makes use of friend access to private/protected properties, there are circular type references etc, but it can be done. 

I spent a day on it recently, I split it up to 23 files so far (it's not compiling yet, still refactoring, there will probably be more). Right now this is more of an exercise to see whether it's feasable and where the main problems will be. Is there any interest in this? 

--
You received this message because you are subscribed to the Google Groups "Virtual Treeview" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtual-treevi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vincent Parrett]

It's possible to still allow the use of a single file in the uses clause, I'm big fan of that in my own work (DUnitX and Delphi-Mock both have lots of units, but only one is needed in the uses  clause). They way I've been tackling this is to move anything that isn't intended for use by the user of the control out to separate units, and if I need to move something that is needed, like for example PVirtualNode, then I add an alias for it in VirtualTrees.pas. I'm keen not to break anything myself, I have a lot of code using VT, but I do think it's worth doing some housekeeping to make the project more maintainable. 

At the moment, it's not easy to see what has changed :

/branches/V5_stable/Source/VirtualTrees.pas   r810
/branches/V5_stable/Source/VirtualTrees.pas   r813
Files are too large to display a diff.

Any chance of moving the project to github? The whole process of taking contributions etc on github makes managing an open source project so much easier. 

[Joachim Marder]

DearVincent.

You are right, aliases are a way to go, it just means some extra work.

>it's worth doing some housekeeping to make the project more maintainable.

I agree, however, I have only limited time I can spend on the open source projects like VT and the Delphi Ribbon Framework, and I was trying to make most out of it for the users. I thought they would appreciate less bugs more than more units.

I think the biggest problem of Virtual TreeView isn't the single unit, but duplicate code as e.g described in issue #369 or in the area of InternalConnectNode() / AdjustTotalHeight (issue #362).

This is one reason why I was was avoiding big refactorings so far, you easily break functionality when doing larger changes.

> Any chance of moving the project to github?

I have so many projects all using SVN and a large tool chain (including Jenkins and scripts) which is all based on SVN. It would mean many days of work to change all this to Git(hub). Recently someone offered help if we would switch to Mercurial.

If someone really wants to get into charge for this project, I don't mind if he may switches to his favorite VCS. 


> At the moment, it's not easy to see what has changed

TortoiseSVN does this job for me. Please don't get me wrong, I don't want to put you off, I just want to avoid this extra work unless there is truly a benefit in it for me or for the project. I have family and children and a company to run, so my time for things like these Delphi open source projects is very limited.

Best regards,

Joachim