[racket] racket/gui: changing the background color

From: David Nelson (davidcnelson at gmail.com)
Date: Fri Aug 22 17:28:50 EDT 2014

I ended up going the canvas% route. To reduce the amount of screen space
that had to be redrawn when updating the progress bar or changing the
status text, I created my own message% and gauge% classes based on canvas%.
The final arrangement was a custom panel% that stretched its children out
to the full width/height as the parent. Its children were a canvas% to fill
the background, and a vertical-pane% to layout the custom message and gauge
classes. To change the background color, I had to tell each part to change
the background color, but that could be automated with a method to walk the
children to find my custom classes.

Why don't pane% and panel% honor the stretchable-width and
stretchable-height properties of their children. Every other pane/panel
class does. It seems like this would be a reasonable thing to do. I have
two specific use cases:

1) A tab-less tabbed panel where I want to display different content pages,
but size the whole area is based on the largest width and height from the
children. All but one of the children was told (send child show #f). In my
case, this is a page with the controls to prepare and start an operation.
Once the operation is started, it flips to a status page. There is a button
to stop the operation and return back to the first page.

2) I want to arrange a canvas as a background behind other objects. After
playing with this, the only other things that seem to  reliably work in the
foreground are other canvases so I understand this would not be a typical

Setting the minimum width and height the same for all children is OK as a
starting point, but if the window grows and you want that space to grow
too, the children are not currently stretched out. I ended up creating a
custom pane% that overrides place-children, but it seems the default
implementation could do this.

-- David

On Fri, Aug 22, 2014 at 2:36 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> There's currently no way to set the background color for `message%`
> objects, and I'd still use a `canvas%`.
> At Tue, 5 Aug 2014 10:47:37 -0500, David Nelson wrote:
> > I am working on a manufacturing system to asynchronously program and test
> > 16 USB devices. The main display is a grid of "slot" displays. Each slot
> > display currently is a group box with the slot number in big digits, a
> > status message in normal sized text, and a guage to display the progress.
> > I'd like to change the background color of the group box for each slot
> > depending on the status. E.g. red for a problem, green for success,
> yellow
> > - in progress, etc..
> >
> > The problem is that setting a background color only seems to be possible
> > with a canvas%. I seem to have two options:
> > 1) Use a canvas for the slot and draw all of the contents.
> > 2) Create a subclass of panel% that can position a canvas behind the rest
> > of the children.
> >
> > In the previous implementation option #1 was used because I needed to
> work
> > around another issue. We used a collection of BeagleBones with small LCD
> > displays to drive the slots, one computer per slot. I had to roll my own
> > classes to deal with the display physically rotated 90 degrees from
> normal.
> > (The X server did not support rotating the display.) I used a canvas
> > filling the top-level frame, and then my rotated-text% and progress-bar%
> > classes used absolute positioning and sizing. The draw operation on the
> > canvas filled the background, applied a rotation transformation to the dc
> > and then for each child it applied the appropriate translation to the
> > position of the child and told the child object to draw with the rotated
> &
> > translated device context.
> >
> > Comments or suggestions?
> >
> > -- David
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140822/4116a3d3/attachment-0001.html>

Posted on the users mailing list.