G'day,

Apologies if this is the wrong place to ask this question - the forum seems quiet on related questions I've asked there.

I've been playing with the GTK TListView code, and I'm happy I can solve most of the selection issues outstanding in Mantis, and a few more to boot. Problem is the solution for the TListView in Icon Mode is potentially quite expensive - currently looping linearly over an unsorted TStringList (ItemCache) of selected nodes every selection event (and there's one or two existing scenarios where this happens as well). Before I submit the patch I'd like to optimise this code using a sorted integer list or two (side by side with ItemCache). Someone on the forums pointed me to a syntax I was previously unfamiliar with, that I'd like to use.

uses
  fgl;
type
// for {$mode objfpc}
  TIntegerList = specialize TFPGList<Integer>;

My problem is that when I go into fgl it states this is prototype code - and to me that means either the interface or implementation is likely to change in the future.

My question is, are you guys happy if I go ahead and implement code inside gtk2wscustomlistview.inc that uses this functionality, or should I just stay on the safe side and implement a specific TIntegerList for this scenario?

The more I play with the gtk2 TListView, the more I realise what a superb, but extremely difficult, job other people have done making the gtk2 widget conform to the win32 api structure. I imagine similar difficulties were encountered in other widgetsets and my hat is off to all who have worked through this. Felipes suggestion of a custom drawn ListView looks more and more attractive to me :-)

(this will be my first time playing with the LCL code, and I'm fully expecting my patch to be rejected, or at least marked with red pen "must try harder" :-) - just saying don't panic that you've got a newbie playing in the LCL :-) )

Cheers

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/fac5fb53/attachment.html>

All the ComCtrls are tightly bound to the Win32 platform/widgetset, see my recent problems with TTabControl. I see two ways for overcoming such problems:
- full emulation, not using native widgets of other platforms, or
- portable replacement components with limited Delphi compatibility.

DoDi

I've been following various related discussions with interest. IMO What's been achieved already with the LCL has one huge advantage - and that's its compatibility with the VCL. Knowing two parts of nothing about Linux/gtk I was able to get up speed quite quickly simply because I already knew the existing framework. The people who worked on the LCL have done a superb job.

It certainly may be time to start discussions on a new component library (and I look at what Graeme has achieved with fpGUI and going down that path certainly has my vote) - but that is a decision with huge implications and will require a large amount of time allocated to it - time I simply don't have, I don't know about others... For now, I'm happy enough working within the current framework, getting the broken bits to work - always been happier as a code-monkey and not an architect :-)

My two bits :-)

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110807/a4f390c9/attachment.html>

2011/8/7 Michael Thompson

Good question. I have also though when we should start using generics in Lazarus and LCL code. Generics containers can eliminate many typecasts. I remember that 2 latest FPC versions should be supported by Lazarus trunk code. Currently it means FPC 2.4.2 and 2.4.4.
In FPC 2.4.2 generics work already quite well. They may have some performance problems still, don't know. In FPC 2.4.0 generics were broken.

It may still be safer to use a dedicated IntegerList now and start using generics after next Lazarus release & FPC 2.6.0 release. What do others say?

The generics TIntegerList doesn't support Sort or Find, they must be implemented if needed.
If you decide to go with a traditional (non-generics) integer list, you don't need to code a yet-another version of it yourself. For example I have one here:
https://github.com/JuhaManninen/Pascal/tree/master/IntList It is well optimised and has Sort (using QuickSort) and Find. It is strange that Lazarus code-base still doesn't have such a list. In many places pointer-lists are used for integers or even for chars with horrible typecasts.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110809/b64966ee/attachment.html>

inside

> gtk2wscustomlistview.inc that uses this functionality, or should I just

stay

Tested yielded good results with the generics (using TFPGMaps gave me the sort code I need for testing), but the IDE itself didn't like the generics (jump to implementation, and procedure list both failed in random ways including the entire IDE vanishing twice), so I'm thinking generics shouldn't be added to the LCL until the IDE fully supports them. On the TIntegerList front, I refactored the code several times over, and the current implementation doesn't use an thanks for
the feedback, and the link to your code...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110811/45e17e9f/attachment.html>

2011/8/11 Michael Thompson :

Can you test his with the current SVN version of Lazarus and create bug reports if it still causes crashes?

Vincent

Good call. None of the issues I experienced under 0.9.30 are reproducible under 0.9.31. Sorry 'bout that.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110811/19672f37/attachment.html>

2011/8/11 Vincent Snijders

Can you test his with the current SVN version of Lazarus and create bug reports if it still causes crashes?

Codetools generics support is still broken. This is a note from Alexander S. Klenin to issue #19931. I am lazy and don't want to write the same thing :

Issue 18373 and its duplicates are about a missing feature (CoteTools does not know about members of specialized classes).

Issue 19741 and its duplicates, including this issue, are about (more recent, and more serious) bug --
CodeTools fails to parse the code inside specializations, even if the code itself has nothing to do with generics. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110811/f0c1ab74/attachment.html>