[lazarus] GTK team: please specify!

Mattias Gaertner nc-gaertnma at netcologne.de
Sun Nov 2 08:51:18 EST 2003


On Sun, 02 Nov 2003 14:29:01 +0100
Micha Nelissen <M.Nelissen at student.tue.nl> wrote:

> Mattias Gaertner wrote:
> 
> > On Sat, 01 Nov 2003 21:39:49 +0100
> > Micha Nelissen <M.Nelissen at student.tue.nl> wrote:
> > 
> > 
> >>Mattias Gaertner wrote:
> >>
> >>
> >>>Much more clearer :)
> >>>I was a little bit confused by the term "derivative of TCustomForm".
> >>
> >>Well, I meant descendant I think, ie. a windowed control.
> >>
> >>
> >>>Ok, grabbers and icons can be replaced by special non LCL widgets (in
> >>>win32 slang: windows).
> >>>What about the rubberband, the selection marks and the guide/snap
> >lines?>
> >>Rubberband can be drawn on the screen itself. It's temporary, after all.
> >
> >>Is this possible in gtk too?
> > 
> > 
> > Yes. But I'm not sure, how to combine this with the LCL/IDE.
> 
> The WinAPI specifies that GetDC(GetDesktopWindow()) should return a 
> device context of the screen. We can use this DC to draw on.

Very funny. ;)
What has the winapi to do with the gtk?
We need the window DC without clipping and we need an event to know, when
the gtk has finished painting everything. And during moving we have to paint
as well.
When we got this, we can omit the paint on every message and we can omit the
designer widgets, because the rest is already implemented. This solution
would be very near to my initial wish in a former mail.
I will do some experiments... 


> >>Selection marks aren't the grabber handles?
> > 
> > 
> > No, I mean the multiselection marks (normally gray 4 rectangles at each
> > corner of each component). When the user selects 10 components, should
> > we then create 40 small widgets?
> 
> Hmm, no. These are drawn on the control, within control bounds. Black 
> ones are partially on control, partially on parent, but these gray ones 
> are completely on the control.

Then we still need the paint messages. Using widgets for the grabbers will
only be a small optimization.

 
> >>Guide/snap lines are the grid, the dots? 
> > 
> > 
> > No, this is the grid. I mean the green and blue lines showing the
> > alignment of the selection with other controls on the form. Maybe you
> > never saw them, because Delphi does not have them and the designer does
> > not yet work under win32.
> 
> Indeed, I have never seen them. I guess we can leave these for later?

We can leave the implementation for later, but IMO we must find a solution
for this. Otherwise we have to keep the DC hacks. And without making the
rest more simple, it does not make sense to add special widgets .

 
> >>These are not inter-control, 
> >>are they? Only things that require inter-control calculations should be 
> >>redone. Or is this too simply thought?
> >>
> >>We can try to implement things one by one, first the invisible 
> >>components, then the grabber handles, etc...Then dependencies will show 
> >>gradually. Or do you want a complete rewrite from scratch?
> > 
> > 
> > No, every item (grabbers, marks, snap lines, grid, icons) is already
> > splitted up. So, we can replace them one by one.
> > What we need are LCL widgets, that are not controls. Maybe we can call
> > them TDesignerWidget. (Not TDesignerControl, because they have nothing
> > to do with TControl, not even with TComponent). They should be as
> > separate from the normal LCL routines as possible. For example: No
> > messages.
> 
> Delphi recommends descending from TCustomControl in this case. From help:
> 
> "TCustomControl is one of two base classes for controls that draw their 
> own surfaces. Because TCustomControl is descended from from TWinControl, 
> instances of its descendents can receive the focus and serve as
> containers."

If we use any TControls, then we have to add code to various places in the
LCL to distinguish between "real" controls and "only designer" controls. IMO
this will become a mess.
If we want to implement a more clean solution, then we should create
separate widgets.


Mattias






More information about the Lazarus mailing list