Alternating row colors

[effelsberg]

I'm a longtime user of the original Tomboy and found this small and up-to-date new version. It's great so far but alternating row colors (yes, the original had them, but that's not the point) are nice to look at.

I found this recipe on page 5.

Simply set the event for OnCustomDrawItem and fill it accordingly:

procedure TSearchForm.ListViewNotesCustomDrawItem(Sender: TCustomListView;
  Item: TListItem; State: TCustomDrawState; var DefaultDraw: Boolean);
begin
  if Odd(Item.Index) then
      ListViewNotes.Canvas.Brush.Color := $eeeeee
  else
      ListViewNotes.Canvas.Brush.Color := clWindow;
end;

I leave the proper shading color to the implementor, perhaps there are also some concerns about dark mode.

Note: I found this to work on Windows 10 but ... alas ... not on my Linux (Ubuntu 18.04) system.

[davidbannon]

Er, I was just about to post when I realized I might be misunderstanding you request. Where do you want the alternating colours applied ? To the note window it self or one (or all) of the various lists ? ie in Search window ?

This answer, probably irrelevant, applies o the main note edit window -

That could be a bit of a challenge effelsberg, the text in tomboy-ng is displayed in a kmemo widget, not a ListView. Now, kmemo does have a lines property but each 'line' would not have its own background colour property, I am almost certain. So, to achieve what you want, I would need to alter the colour of the text, line by line. And because the text auto wraps (eg when you add/remove text or alter the window size ) that would have to be constantly updated. I suspect it would would introduce a significant CPU load, one most users with larger notes would find unacceptable.

Thanks for the idea, next time I am playing down in that code, I will think about it but at this stage, I don't think its very likely.

Davo

[effelsberg]

I'd like to see alternating colours in the list of search results, that's what 'ListViewNotes' is, right? Like in this screenshot Accessing Your Notes.

Windows rendering is fine, I really think it's a rendering problem for my specific Linux machine, i.e. driver and graphics card. I tried to do some funny things like ListViewNotes.Canvas.FillRect(0, 0, 1000, 1000); . This gives me a completely grey area, but if I move the mouse around the repair drawings properly draw alternating colours.

Maybe I will update my Linux in the near future (but it's an LTS release, I like it ... to some extend) or I will try a Linux in a VM under Windows.

-- Stephan

[davidbannon]

I initially implemented those lists of notes with a stringgrid, it has a setting that turns on alternating colours, very easy. But I have gradularly removed all stringgrids, they had some other problems that I did not like.

It may be worth looking at underlying code.

Davo

[davidbannon]

Yes, just tried the approach you mention. It appears that TListView' owner draw is not working as it should, apparently its a know issue on GTK2 and Cocoa. And, also apparently (because I have not tested it myself) it only works in this mode on 'some' windows systems too.

The recommended solution (until someone dives down into TListView's code) is to use TStringGrid. I initially setup tomboy-ng using TStringGrid for these jobs but recently (ie several releases ago) changed them all to TListView because of the need to override the controls default colours on windows to cater for users with Dark Themes. Its almost impossible (or so I find) to set appropriate dark theme colours on windows in a TStringGrid.

I think it comes down to choosing between getting the dark theme colours right or having alternating coloured rows and I feel there are more people out ther wanting that (ugly) dark theme I am afraid.

Davo

[the-Arioch]

I wonder if such a feature better be moved upstream (i mean TListView component)

....about decade ago i tried to made a patch for TVirtualTreeView to highlight row and or column the mouse is hovering at. But it did not fly and there was no github back then to fork :-D

As another sidenote, Did you see ZColorGrid ? This component is somewhat bound to spreadsheet component ZEXMLSS which i used in our commrical Windows/Delphi app. It unexpectedly ended in main developer moving to github :-) I don't know if ZCG can be unbound from Windows GDI, but the original author is more FPC-guy than Delphi-guy. I used to do some hacking on JediVCL grids and those are definitely GDI-only...

[davidbannon]

I get the impression that here, locally in FPC land, they agree that TListView should perhaps respond the the hack effelsberg suggested but no one wants to try and make it do so because, if you need that level of functionality, you should be using TStringGrid. And I originally did just that, TStringGrid worked fine in every respect except some parts of it has fixed colors inherited from the OS that cannot be changed at my level. And, because Windows has an incomplete Dark Theme implementation, I need to change colors from within tomboy-ng.

While it would be possible to use different components between Linux/Mac and Windows, I really don't want to add such a complication, especially as it seems Windows is trying to solve this problem, at some point I may be able to revert back to TStringGrid

Hmm, thats strange. I am sure last time I looked at this issue, I could turn on grid lines between items in TListView. Was going to post an image and ask if that helped. But I cannot get it to work either. Further research is indicated ....

the-Arioch - I find the Lazarus people pretty welcoming with working patches, maybe things have improved. Bug fixes particularly welcome, new features maybe require a bit of cost/benifit discussion !

The only ref I can find to ZColorGrid is in a language I cannot read, dated 2013, seems to mention Delphi. Do you have a link ?

If I get some time, maybe I will delve a bit deeper. One thing I could do (I think) is to highlight the row under the mouse. Much as happens now but with out the need for a single click. I am not sure if that would be a good thing or not ....

Davo

[davidbannon]

OK, I can make effelsberg's original suggestion work, it just needs to be told how to do the writing. Not sure yet about Windows/Mac. (In fact, I find it surprising effelsberg model works on Windows ??). My initial problem was due to a bug in the trunk version of Lazarus (I develop with trunk to pick up bugs like this, release with a production version). Logged https://bugs.freepascal.org/view.php?id=38062 Davo

    if Odd(AItem.Index) then
        aColor := $EEEEFF;
    ListView1.Canvas.Brush.Color := aColor;
    ListView1.Canvas.FillRect(ARect);
    ListView1.Canvas.TextRect(ARect, 2, ARect.Top+2, ListView1.Items[AItem.Index].Caption); 

Will need to sort out suitable colours, especially so for the dark themes (I walk in the light).

[the-Arioch]

=== Offtopic ===

I am mostly Delphi XE2 guy, i don't even have working linux installation at home novadays :-) I also did not look into ZColorGrid yet, for my interest was export into Excel/OpenCalc You may see some old and stalled lib in my repo, and then the author moved to GH too, but he started afresh, dislinking from me. Well, that is indeed Delphi-only, what was expected... See readme at https://github.com/Avemey/zexmlss/tree/master/zcolorstringgrid/package/lazarus

---

Delphi TStringGrid is severly limited in all-or-nothing fashion. It either makes a VERY dumb and non-customizable rendering, or lets you go full-scale OwnerDraw - ceasing being different from TDrawGrid. Personally i prefer JediVCL's enhanced StringGrid, which does not force my hand to render, but exposes TCanvas in before drawing events to let me customize fonts and colors.

I wonder if some of JVCL features were ported into LCL.

Another option for me would be using the monster TVirtualTreeView in so-called ReportMode, though it is more about ListView than StringGrid. Yet again, VTW is one tour de force, but it is very optimized towards particularly VCL and GDI and manual heap memory management (as opposeed to GC and managed languages). It is a very powerful component, but perhaps totalyl missed from crossplatform LCL. Stock TTreeView in Windows+VCL is really bad, maybe it is much better in LCL, dunno.

---

Re welcoming of FPC crew, it is questionable. Looking at PilotLogic, then at NewPascal (or was it NextPascal)... By observing forum the rifts can go very real. I also remember mORMot guys once wanted to migrate to FPC but found FPC was severly short on features crucial for them, maybe it changed later. But it is a shallow overlook of a passer-by.

I also feel lack for binary packages (BPLs, Shared Objects preserving Pascal types and classes), it seems no one even tried it for FPC (which of course could had been be more complex, than initially Win32-only Delphi'1997)

And my more immediate interest is to have in-office shared knowledge for small office team, and without diving deep TiddlyWiki+TiddlyMap looks promising. TomBoy was devised as personal tool and with much less extensibility. It is just different niche, lean and mean and strictly personal.

BTW, since the initial TB/C# went to greener pastures i wonder if trying to replicate old sync protocol verbatim should be a priority. Maybe implementing new clean something should be done instead. Conceptually similar to Fossil/git, perhaps, but with aggressive garbage-collection and root commit moving forward.

[davidbannon]

So, I can do the alternating colours quite easily. Turns out that in the trunk version of Lazarus, a bug had been introduced a month or so ago. I tracked that down, reported it, all fixed in three days. I reckon that is a pretty reasonable response. The first patch I ever submitted to Lazarus has some serious problems, instead of a bucketing, I was coached very gently in the right direction.

I came in just as the NextPascal (newPascal ?) was just settling down, I got the impression that a number of people were unhappy with another number of people, that happens ! Overall, its a very welcoming and positive place. There are, of course, exceptions !

The shared object thing is an issue, personally, working with (making, using) C type libraries works OK and you have the added benefit of non pascal applications being able to link. I have recently had to re-do the bindings to the Hunspell C library (because of Debian licensing requirements) , a wrapper around that easily makes it look Object Pascal but it does lack some of the fool proof type checking that so attracts me to Pascal.

I have not tried to make a C library, it would be kind of cool to make a KControls or KMemo C library but really don't think its practicable given it has many hundreds of things sticking out of the interface. And I love the way you can browse into the code when you are statically linking.

I am experiencing an ugly issue with the alternating colours in TListView when using Qt5, for reasons I don't understand, doing ownerdraw reduces the size of the font and removes some of the vertical padding. Right now, I have it working by adding 4 points to the font when using Qt5. That worries me because I don't know if its system dependent, my working machine is quite high DPI. So, that will require a lot of testing, as will how it looks in these various dark theme models.

I have just made some (agonizingly slow) progress with getting into Debian, so will look at a new release in the near future, will be a longish testing cycle ....

[davidbannon]

OK, this is provided in the just released v0.31 Thanks for the report. Davo