[Lazarus] Improve message dialog

[Martin]

On 09/05/2012 15:32, Graeme Geldenhuys wrote:
> Hi,
>
> On 9 May 2012 15:35, Martin<lazarus at mfriebe.de>  wrote:
>> The inspect and watches have different purpose...
> Which are? Even from my delphi days I never used Inspect, only Watches
> - maybe I missed something all these years. :-)
Well the inspect, has the same purpose, as the treeview.

As you seem to have missed the treeview, there must be a different 
between the watches and the inspect/treeview.

>> So the questions are (if the grid is fixed):
>>
>> 1) what is the preferred display:
>> - treeview
>> - grid
> I would still go for the treeview as it could nicely display the
> hierarchy of properties (if supported).
Things like that need to be added to either.
- filter or sort by visibility (public, private, ..)
- filter or sort by class

There are many other nice features that can be added...

I don't know, if on the long term displaying the base classes as 
hierarchy is the best idea.
It would be easily get confusing, if other hierarchical stuff is added 
(e.g do what the object inspector does and allow expanding properties of 
Form.Font or other objects)

Right now, yes the treeview looks like it will offer more. But will it 
on the long term?

>   The Object Inspector grid in
> Lazarus proves the grid fails this point. A standard grid was not
> enough to display all property values, so the grid had to be extended
> to support a treeview-like node which you click to expand. Yes I know
> all Delphi and Lazarus developers should be used to this ideal, but it
> shows the grid analogy was not good enough to start with.
So, the inspect grid could have the same nodes in future?

for base classes, "header rows" that span all columns could be added...

Of course, that is very uncertain future. But the treeview does not 
offer any of that either. And the work will need to be done for the grid 
anyway, as it is used in the inspect window.


We could use the treeview now (with an option to replace it  once the 
grid actually has advanced).
But if the argument for the treeview is, it's potential to be expanded, 
then it raises the question: is it likely to happen. And is in worth the 
potential duplication of work.

Or does the treeview have advantages, as it is (without further additions)?


>> One thing, that I believe should be fixed (but does not have to be a hold
>> back) is that methods use many lines (http://imagebin.org/211658 )
>> FOnSubstitution uses 10 lines. Imho using 1 (scrollable) line in the grid is
>> much better.
> To be fair, Darius's "parsing" of the debug data was very rudimentary
That i s not an issue. It can be fixed. Parsed data is avail by the 
debugger (on request).

> (duping the data into a TStringList), but it kept the code simple and
> solved the [scrolling and clipping] problem at hand. Least amount of
> code to get a suitable solution to a problem. So this could easily be
> solved with slightly improved parsing of the debug data.

Scrolling and clipping can be solved on the grid too. (I already 
committed some changes to scrolling)

So please compare grid and treeview based on
- they both use good parsing
- scroll smooth
- auto expand


> [I guess this deserves a new message thread]
> Now on to another point I was going to raise, and your screenshot
> confirmed it for me. I know this is not your area of expertise.... But
> why is the toolbar buttons so butt ugly under GTK2, but pretty and
> anti-aliased under Windows?
> See attached screenshot of how the Watches window looks under GTK2.
Needs a new thread. Does it apply to all toolbars in lazarus? They are 
just toobuttons. So it's an entre different topic