Hi

If I want to use columns in a TreeView, what alternatives I have? Is there any such component used in Lazarus project itself?

I have used VirtualTreeView myself and it supports columns.

Juha

Juha,

Then why don't you use VitualTreeView in Lazarus? It is supported in Lazarus. I just install it the other day.

Get it here, Install the latest version. 4.8.6
http://sourceforge.net/projects/lazarus-ccr/files/

It needs the lclextensions0.30

Download lclextensions0.30 here
http://code.google.com/p/luipack/downloads/list

Noli

2010/7/13 Juha Manninen :

I don't mind the extra bytes in the executable, but I fear the amount of extra source code in the Lazarus svn tree. People might think that VirtualTreeView is maintained as part of the Lazarus sources too.

Vincent

Noli Sicad wrote

Then why don't you use VitualTreeView in Lazarus? It is supported in Lazarus. I just install it the other day.

Actually I would need it for the Lazarus code itself, for converter configuration.
VirtualTreeView is not very big but it adds some more kilobytes to Lazarus code. I hope it is OK for other developers.

Juha

Juha Manninen wrote

Now I remember, last time I checked VirtualTreeView for Lazarus it had x86 assembly code which is not portable obviously. Is that still the case?

Yes.

Luiz

Maybe you want to add a simple columned TreeView for package lazcontrols.

Mattias

Now I remember, last time I checked VirtualTreeView for Lazarus it had x86 assembly code which is not portable obviously.
Is that still the case?
VirtualTreeView cannot be used for Lazarus itself if it's not portable.

Juha

> VirtualTreeView cannot be used for Lazarus itself if it's not portable.

In the Object Inspector there is inspector tab, so it is up to developer /programmer what components he use in his program.

The 3 VTV components does not have restrictions in my lazarus installation - Windows, x86 Mac OS X and x86 Linux OS.

Yes. But there are other priorities like removing dependency of winapi specific code and improve theming.

Anyway anyone feel free to send patches (I already applied some for 64bit and carbon)

BTW: the license is not compatible with Lazarus/LCL

Luiz

Now the question was about the code-base of Lazarus itself, not about an application made by a developer / programmer using Lazarus.

Including VirtualTreeView into Lazarus code-base would make it compile on x86 architecture only and many people would be unhappy. I wouldn't be happy either if I forced such a limitation. (although I currently have only x86 machines myself.)

@Luiz: is there any plan to port the code? The easiest way is to make a pascal version of the code for all other architectures. If speed demands, it could be coded again in assembly for selected CPUs.

Juha

Juha Manninen wrote

If I want to use columns in a TreeView, what alternatives I have?

One alternative is to implement column support for TTreeView component. According to treeview.inc file this feature was in someone todo list.

Best regards,
Paul Ishenin.

When the converter is an installable package, it will burden only those users that need it.

DoDi

So we kick out synedit too ? :-)

License wise it is also not possible IIRC. (MPL)

Synedit is double licensed under GPL2.

Mattias

I was wrong, VST is dual licensed to LGPL even (but not with FPC exception)

Hi

When the converter is an installable package, it will burden only those users that need it.

Now thinking of it, the converter could well be a package. Many other features are in packages, too.

The only issue may be that the converter should be easy to find for people who come from Delphi and want to quickly test Lazarus with their Delphi prog. They will not find the converter from a long package list in the package configuration window.

Juha

Hi > When the converter is an installable package, it will burden only those > users that need it.

What burden?

It should be installed by default like todolist and others. What is the gain of making it a package?

Mattias

What burden?

The burden of installing VirtualTreeView I guess.
However I will not use VirtualTreeView for Lazarus now. Later it could be done especially because the assembly code seems not to be a problem and the license is OK, too.

It should be installed by default like todolist and others. What is the gain of making it a package?

I don't see any real gain if it is installed by default, but isn't it the same thing with other packages installed by default (like ToDoList)?

Juha

IMO the converter should be installed by default, because Delphians expect a converter from Lazarus. And if it is installed by default (as part of the IDE or bigIDE), then all needed things must be in the lazarus svn. And as Vincent wrote if it is in the lazarus svn it must be maintained.

I think you have several choices:
- use a grid and extend it
- use a TTreeView and extend it
- write an extension of TTreeView for lazcontrols with a simple column
- extend TTreeView for columns
- use VTV and put converter or parts of it as separate package in examples (it can not be used in bigIDE)
- use VTV and maintain it in the lazarus svn

As you are the implementor it is your choice, but I guess many users will be disappointed if the converter is no longer preinstalled.

The todolist was made a package because it was hardly maintained and some users said they would write a better one and would like to replace it. So far I didn't see the better one, not even a start of it. Because the same guys now talk about splitting another IDE part, I tend to disagree.

Mattias

It could be added by default, or we could have various lists of installed packages (to be installed), for certain user groups.

DoDi

It should be installed by default like todolist and others. What is the gain of making it a package?

It can be removed when no more needed.

DoDi

Not that i think this is a big issue but, AFAIK, mixing licenses are not so straightforward even if is toward a more liberal.

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.

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.

In our previous episode, Luiz Americo Pereira Camara said:

(I seem to have failed to receive Adem's msg, so I might reply to him sometimes)

MPL is said to be GPL incompatible. VST is also LGPL (but without exception)

Creating classes is significantly more expensive than records, which can be mass cheaply allocated, cheaply initialized and their allocations are more tightly packed.

It would make it more troublesome for large scale users. (and yes, such things are still noticable)

-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.

I don't read that there? Sb suggests it, and half shoot it down, half not?

Not that i think this is a big issue but, AFAIK, mixing licenses are not so straightforward even if is toward a more liberal.

OK. We can always ask Mike about this. I am sure he wouldn't object to adding LPGL.

> 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

I have been away from Delphi for about 4 years. Hence, I didn't know.

API changes, radical ones at that, are bound to happen --especially if TObject-ifying is on the cards.

Maybe a better idea is to have 2 different branches; one for v4.x and another one for v5.x --and rename the v5.x component something else so that both can be present simultaneously (which is what I did, for my own internal use at the time).

I have code lying around here from 2007 (v4.3.1) when I refactored VT to use TVirtualNode = class(TPersistent); and everything else was also modified to be class/object based (as opposed to pointers/records). I also converted the Advanced Demo to run with it.

The only thing that needed to be done was to further refactor the code so that each TVirtualNode handles its own painting --rather than having the main tree do it, as it is currently done in the calssical VT. That would make deriving new node classes much more easy.

But, as you must have guessed, objectifying VT is a radical departure from the classical VT in that code using it will need re-examining.

Can't promise, but I might check what new bug-fixes there have been so far, and incorporate them in my version.

Of course, you, or anyone else is/are welcome to take a look --just drop me a line and I'll send a copy.

Cheers,

Adem

Marco van de Voort wrote

In our previous episode, Luiz Americo Pereira Camara said: (I seem to have failed to receive Adem's msg, so I might reply to him sometimes)

After being told off being off topic, I decided not to bother this list again; but even though my initial message on this subject was a private email, which --through nobody's fault-- wound up being replied to the list, hence I am replying to the list. Sorry.

> Not that i think this is a big issue but, AFAIK, mixing licenses are not > so straightforward even if is toward a more liberal. MPL is said to be GPL incompatible. VST is also LGPL (but without exception)

I don't agree with that. But, I have no intention of starting an endless discussion on it either.
All I'd be suggesting, at this point, is to ask Mike. I doubt if he would refuse the exception --whyever it is necessary, I have no idea.

> Agree. Just two points: Creating classes is significantly more expensive than records, which can be mass cheaply allocated, cheaply initialized and their allocations are more tightly packed.

That being so, IIRC, speed difference wasn't that significant when I did refactor VT to use pure objects.

Similarly, again IIRC, memory impact wasn't significan either --nodes were already large enough.

But, there are significant advantages --at least AFAIC: The first and most important one is the unintuitive nature of VT, as far as node addition etc. are concerned.

Secondly, deriving new node classes were major pain: You had to know and juggle far too many balls in the air. I am not saying it wasn't doable (even I have done a few myself), but for a casual developer VT is hell --IMO-- to use for different purposes.

It would make it more troublesome for large scale users. (and yes, such things are still noticable)

True.

For that, I would suggest keeping the classic version around both for speed/memory reasons and legacy code, but rename the new version something else so that they can both coexist in the same IDE.

AFAIT, they are at the initial stages of discussions --but, I haven't read any more than that link either.

Cheers,

Adem