Adem escreveu:
On 2010-07-14 15:36, Juha Manninen wrote:
Hi Juha,
Yes, it makes sense to use ListView now; as VT is under development
for adaption to Lazarus by Luiz.
BTW, it was asked/commented in Lazarus list that VT isn't compatible
with Lazarus since VT isn't licensed under LGPL.
I don't think it is a valid issue, since VT is licensed under MPL and
GPL; MPL makes it even more liberally licensed than LGPL.
Not that i think this is a big issue but, AFAIK, mixing licenses are not
so straightforward even if is toward a more liberal.
see here for license info: http://code.google.com/p/virtual-treeview/
Luiz,
I am glad that you're working on VT, but wouldn't it be better if you
started off with v5.x instead of v4.8.6?
Maybe you dont know but i started more than 3 years ago:
http://lazarusroad.blogspot.com/2007/02/ports-of-delphi-components.html
Aside that point, i already split the svn to prepare to merge the 5x
changes. I just did not yet (and it's easy) because there are API
breaking changes in 5x and this will break some code out there,
including mine. Also the code is not wild tested so can be some bugs.
This can lead to some confusion: the bug is from the LCL port or from 5x
version changes?
The idea is: fix the remaining issues with 4.8.6 and wait for a 5x
version be released in Delphi side so the merge can be more safe.
http://code.google.com/p/virtual-treeview/source/browse/#svn/trunk/Source
One more thing:
While 'TVirtualNode = record' was a good decision at the time, I am
not sure it still is.
For one thing, it makes the component too complex for casual users,
and hard to maintain and/or expand.
Refactoring it as 'TVirtualNode = class(TPersistent)' solves many of
those problems (not least of which is the issues with TWorkerThread
which becomes totally redundant) and paves the way for future expansion.
Agree. Just two points:
- The main philosophy behind the port is to keep the original code
where possible. So the node handling/logic is almost identical from
Delphi, i just changed parts related to painting that was impossible to
implement as in the original, like the header (that uses non client
area) or the painting of checkboxes (that was not working cross platform).
-This is a feature to be implemented in version 5x:
http://code.google.com/p/virtual-treeview/issues/detail?id=3 . The LCL
port will take advantage as soon is implemented (and released) there.
Now that you're moving VT to a new platform, wouldn't you like to
consider making it properly object oriented?
Thanks for checking Adem. I added the component's maintainer Luiz as CC.
I will not push VirtualTreeView for Lazarus code-base, at least not now,
because of some other issues.
The component is under development (removing dependency of winapi
specific code and improve theming).
And, including it in Lazarus source raises questions about its
maintenance.
I will solve the converter UI with ListView, adding a category column
which I
planned to be a top level tree node.
Later I can return to VirtualTreeView. I also have some components built
around it which I plan to make public.
Juha
Adem wrote:
There are only 2 routines that are x86 assembler.
One is already pascalized.
The other one checks whether MMX is available in that platform.
As far as I know, only x86 has has MMX; so that piece of code can be
surrounded by a compiler directive --or pascalized if checking for MMX
is possible in native FPC.
In short, VTV is already fully portable.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
