> Another alternative might be to make a visible grid of cells (using > table-panel, for example) and rather than scrolling the canvas they are on, > use the scroll bars to change what data is displayed in those cells. That > is, have the visible grid of cells be a window into the (potential much > larger) grid of cell contents.
That's a good idea, too. In that case I think you *might* want to make the table-panel be the full *potential* size of the window (i.e the desktop size). That way, when the user resizes the window interactively (e.g. dragging the window border) it will smoothly expose/hide the already-existing parts, like say Excel would. (I'm assuming recreating the table-panel on each tiny size change message would not be smooth, and, that having it be jerky would be undesirable. Or that having "blank" parts until the resize completes, would be undesirable.) Of course this might not work well if someone's desktop is enormous (multi monitor). And/or if its size changes dynamically (change res in OS display properties). In which case you might decide to manage the client area "from scratch", after all. It depends on how smooth and "professional" you want the GUI to be. In any case, the main point I intended to make is: These GUI design decisions are (I think) basically the same in C or Racket. In other words using many window controls would be OK (or bad) equally whether it's C or Racket or whatever. So Dmitry I wouldn't let that particular issue discourage you from using Racket for a GUI project. ____________________ Racket Users list: http://lists.racket-lang.org/users
