[racket] Does Racket GUI scale?

Hello,

Thanks again everybody for the pointers.

Here it is, a stub for a very basic spreadsheet editor in 419 lines
of Racket code. http://pastebin.com/m6pCATsU

Screenshot: http://imgur.com/k0vygX8

For simplicity, I decided to create all the buttons for columns at once
(seems to be OK when that are not in a scrolled panel).
Buttons for rows are created ad-hoc.

The implementation may have its glitches, but it is usable enough
for my purposes.

I will list the things that I am not quite happy with, and I will
appreciate for any pointers to how to work them around.
In case it is not possible, I will take them the way they are,
though.

1. Lack of scroll bars that one can use independently from
canvas or panel. I currently use sliders instead of scroll bars,
but with slider, it is impossible to go up/down by exactly
one point.

2. No auto-scrolling of text in a (small, limited by size)
text snip when the user enters more text than can fit in
the snip.

3. Strange white border around the text (or text snip?),
is visible on the screenshot, where the grid lines break.

4. Is there a way to disable multiline input in a text%?
For now, I just hook the handling of the "Enter" key,
but the user still can copy-paste multi-line text etc.

5. (Probably my own problem) Implementation relies
on several global variables (text-snip, row-buttons etc)
that potentially can be accessed from multiple GUI
threads simultaneously. I really do not know how
to do a reliable thread-safe GUI, especially in Racket,
are there any manuals or examples?

Best regards,

Dmitry



On Sat, Jul 12, 2014 at 1:56 AM, Dmitry Pavlov <dpavlov at ipa.nw.ru> wrote:
> Greg,
>
> You are right, managing the scrolling bars manually and
> creating an in-place cell editor by demand seems
> the only way under given circumstances.
>
> I agree that other platforms have the same limitations
> with GUI performance as Racket has. However, other platforms
> may have a spreadsheet control included :)
> No complaints, though, I will use Racket for this.
>
> Regards,
>
> Dmitry
>
>
>
> On Fri, Jul 11, 2014 at 1:55 AM, Greg Hendershott
> <greghendershott at gmail.com> wrote:
>>> 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.
>>