Sorry to but in, but I think I missed a step: if you cannot guarantee the order of the panels, how does this kind of thing work?
Robby On Fri, Feb 25, 2011 at 9:17 AM, Christophe Vandenberghe <[email protected]> wrote: > Well, if panels can be transparent then I could use one main panel and add a > canvas to draw the background and overlay it with the transparent panels (or > use a message% with a bitmap label instead of the canvas if it is a fixed > image). Then there is no need for the 'on-paint' for panels. > > -----Original Message----- > From: Matthew Flatt [mailto:[email protected]] > Sent: vrijdag 25 februari 2011 13:55 > To: Christophe Vandenberghe > Cc: [email protected] > Subject: RE: [racket] Graphical Toolkit change question > > Ok, but to be clear, you need both `on-paint' and transparency for > panels, right? Transparent panels can group and hide controls, but you > need `on-paint' to draw a background in the first place. > > It turns out that transparency more or less falls out of supporting > `on-paint' for panels, so I'll work on both. > > At Fri, 25 Feb 2011 08:30:44 +0100, "Christophe Vandenberghe" wrote: >> That is indeed my problem. I am using Win32 and panels take the same color as >> their parent. That is why I could never make something like a background >> panel >> with another panel on top that is the same size as the background and only >> contains for example one button centered in the middle (a.k.a a menu). This >> would make it easy to be able to hide that "menu" and show another one when >> the >> button is clicked. But since the panels take the same color as their parent >> (in >> this case the frame), the overlaying panel hides the background panel. >> >> The only workaround I have found is to use a container panel for each of >> these >> "menus" that on their own contain the background and then a pane (as panes do >> show transparent, but cannot be removed unless it's parent is removed) >> containing the menu. That way I can always show and hide the container panel >> and create a navigation between menus. The huge problem with this approach is >> that the background has to be loaded and inserted for each of the menus >> separately instead of just once in the main frame. >> >> -----Original Message----- >> From: Matthew Flatt [mailto:[email protected]] >> Sent: donderdag 24 februari 2011 15:11 >> To: Christophe Vandenberghe >> Cc: [email protected] >> Subject: RE: [racket] Graphical Toolkit change question >> >> At Thu, 24 Feb 2011 09:30:26 +0100, "Christophe Vandenberghe" wrote: >> > But then again like I said before. It would be easier to have >> > transparency for panels, as it would resolve the need for panes >> > inserted in panels to be able to hide or delete them when needed. >> > That would also solve the background problem. Would that be easy to >> > achieve with the new implementation? >> >> I'm not clear on the sense in which panels are currently opaque. >> >> Since siblings are not supposed to overlap, the only kind of window >> that can be behind a panel is another panel or eventually a frame. >> I'm relatively clear on what happens with Win32 and Cocoa: >> >> * Under Win32 (the way `racket/gui' currently uses it), all panels and >> frames are the same color, so you can't really tell whether panels >> are transparent (i.e., transparent and solid is all the same). >> >> * Under Cocoa, all panels are transparent, allowing a frame's texture >> (if any) to show through. >> >> Is there a Gtk theme where frame content and/or panels can be textured >> (as opposed to being all the same color), so that you can tell the >> difference between an opaque panel and a transparent one? Or are you >> talking about something else completely? > > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
