Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-08

[RE: [GTK Z order & fixed frame]]

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michal Bukovjan

"Samuel Liddicott" wrote:
...

Show quoted text 9 lines
> > Next problem is that in windows, each "window" is er... a > normal window and > > can actually have child controls. > > A button or a list box can have child controls (I've done this in some > > applications...). > > > > Can GTK list boxes have child controls? > > Yes. In fact, the GtkList is only a container containing GktItems

(provide

Show quoted text 8 lines
> white background behind the text), which in turn may contain a > GtkLabel, which > is then what you see. But theoretically, the list may contain anything, > pictures, buttons, any other container containing yet another controls, > anything you like. Does this imply that any gtkWidget may contain other gtkWidgets?

No. GtkWidget cannot have child controls. The GtkContainer can, and most widgets and derived from GtkContainer.

...

> This OwnerDraw stuff as I see it now is the most likely candidate to be > incompatible with WinDelphi. We can make it work! We may have to do a ReCreateWnd and make a generic

GTK

window if it is ownerdraw and then err.... draw by hand. No probs!

(Except

of course TListBoxStrings will be implemented slightly differently to cope for the fact when there is no gtkListBox)

I thought about that, and will try that approach in near future. I have to test Shane's implementation of TCanvas first, and few other things, because in OnDraw event (OnOwnerDraw ?), you pass not the TCanvas, but TWinControl, and a rectangle. Unlike Win32 listbox, which has one big canvas for all of its lines, the GtkListBox approach (which I find cool :-) is that for each line (item) it contains another container, GtkItem, and this another container (descendant of GtkContainer, GtkBin - designed to hold just one child), may or may not hold a GtkLabel (which provides Canvas). The label holds and paints the text.
This OwnerDrawing would require to create an arbitrary control on the fly, and put it instead of the GtkLabel, which is not a problem. The problem is in the structure of the OwnerDraw event, which would point to different rectangles, but that need not be a problem, too.

Your approach, to create one big control with one canvas might also be a solution, but then a complete selection and focus management would have to be reprogrammed for TListBox :-(

Show quoted text 5 lines
It seems that the only things which may affect how things work then, are: Z order stetting Can any gtk widget be a parent widget

No, only GtkContainer, which is a descendant of GtkWidget.

Michal Bukovjan

____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

Reply by email

Samuel Liddicott
to Michal Bukovjan
Show quoted text 22 lines
-----Original Message----- From: Michal Bukovjan Sent: 30 August 1999 06:49 PM To: Subject: Re: [RE: [[lazarus] GTK Z order & fixed frame]] rectangle. Unlike Win32 listbox, which has one big canvas for all of its lines, the GtkListBox approach (which I find cool :-) is that for each line (item) it contains another container, GtkItem, and this another container (descendant of GtkContainer, GtkBin - designed to hold just one child), may or may not hold a GtkLabel (which provides Canvas). The label holds and paints the text. This OwnerDrawing would require to create an arbitrary control on the fly, and put it instead of the GtkLabel, which is not a problem. The problem is in the structure of the OwnerDraw event, which would point to different rectangles, but that need not be a problem, too.

Yes. The OwnerDraw handler for a list box is called once for each visible item, and passes a rect but not a canvas. Shame.
Perhaps we could switch in a different canvas just while that function is called. Hmmm.

Your approach, to create one big control with one canvas might also be a solution, but then a complete selection and focus management would have to be reprogrammed for TListBox :-(

Yeah. How about a meta-canvas which takes a set of canvases and regions and breaks down the drawing into sets of operations on the various impinged canvases.

Hey... this is what metafile printing does....

Anyway, just daydreaming here...

> It seems that the only things which may affect how things work then, are: > > Z order stetting

Can a control be hidden and shown without removing from the gtk parent-child structures?

Sam

Reply by email