2023-10-08 18:00:08 Hmmm. I'm tinkering with SDL2 via g++ today. For some reason it doesn't seem to register my touch pad, as a touch device. Mouse motions report fine, as do actuall clicks. Two-finger motions trigger mouse wheel events. 2023-10-08 18:00:37 But no other activity at all from the touch pad. Tapping it, double tabbing, pinch / zoom type gestures, etc. - no events at all. 2023-10-08 18:03:06 Possibly a Linux implementation quirk 2023-10-08 18:03:13 Maybe ask in SDL IRC 2023-10-08 18:03:23 I'm assuming they have one anyway 2023-10-08 18:04:14 I'm reporting "unrecognized" events, so it's not as simple as just not knowing what event types to expect. 2023-10-08 18:05:02 Also, resizing windows in SDL2 seems a bit... "manual." From what I can tell so far you put the window into a "resizing mode," and while it's in that mode mouse icons change and so on - it's prepped to register your mouse motions resizing the window. 2023-10-08 18:05:19 I assume I have to collect the resizing info that way and then perhaps call a function to do the actual re-size. 2023-10-08 18:05:31 At least moving the window around seems to be a "fully automated" thing. 2023-10-08 18:05:37 games probably don't resize windows much? 2023-10-08 18:07:38 i think theres a flag to allow resizing the window you can set when creating it 2023-10-08 18:08:42 SDL_WINDOW_RESIZABLE 2023-10-08 18:10:21 Yes, actually I think you just make a call to do the actual resizing - I think that flag mostly "re-interprets" incoming events in the context of a resizing operation. Changes the mouse icon, etc. But I think if I want the window size to change dynamically while I'm making the motion, I have to set the size to the new values over and over, and probably call the update screen function too> not sure yet, 2023-10-08 18:10:22 though. 2023-10-08 18:25:19 Anyway, yes - further experiments seem to confirm it's modal. If I set the resizable bit at start up, then the window comes up with the mouse icon reflecting "resize mode," and the usual mouse motion / mouse wheel events appear to be filtered out. 2023-10-08 18:41:57 Also, the window appears to have an unpainted "boundary layer." 2023-10-08 18:42:19 If I move the mouse slowly toward the window, an event type 3 will fire before I actually reach the window. 2023-10-08 18:42:57 Mouse motion events are not registered while I'm in that zone though (they're also not registered when I completely outside the window). 2023-10-08 18:43:15 If I continue then a different event fires when enter the literal window area, and a different one when I leave. 2023-10-08 18:43:42 These are all of type SDL_WINDOWEVENT; there's data within that distinguishes entering the window from leaving it. 2023-10-08 22:08:29 I notice one other little quirk with this too. When my window first appears, there is a noticeable difference between the titlebar color (dark gray) and my console background (black). But as soon as I make the first call to SDL_UpdateWindowSurface() (which you must do to get your changes actually on-screen) then the titlebar turns pure black. The title is still there, but the background color changes. 2023-10-08 22:08:54 As far as I can tell so far SDL2 doesn't offer control over titlebar color. 2023-10-08 22:30:15 that could be something your window manager is doing 2023-10-08 22:33:32 Well, it will let me have no titlebar at all, which is likely my perference. THEN the anomaly is that it initially draws the window up in the top left of my screen, and then moves it to some centered-ish position on the first screen update. 2023-10-08 22:33:56 Suppressing the titlebar does seem to eliminate those "extra zones" that surrounded the window otherwise. 2023-10-08 22:36:41 What got me to pecking around with this was that website I linked yesterday that had the interactive microprocessor simulators. 2023-10-08 22:37:18 Like this one: 2023-10-08 22:37:20 https://floooh.github.io/visual6502remix/ 2023-10-08 22:37:39 Made me think about the stuff I've read re: Chuck's cad system. 2023-10-08 22:39:19 If I recall correctly, he had five or six layers and each layer was just a 6000x6000 or so grid. Each layer represented a different material, and he had a "character set" that let him draw his designs by just setting each cell of each layer to one of those characters. It was all very much "font like" - he couldn't draw arbitrary lines, but I guess he felt he didn't need to. 2023-10-08 22:39:55 I think he had his system set up so that the mousewheel would revolve the tile under the cursor through all of its possible "character" settings. 2023-10-08 22:41:01 And if you had words to set tiles, relative to where the cursor is now, then I can see easy enough how you could write a definition to drop a particular transistor geometry somewhere, and then definition that used that to make gates, then that to make an adder, and so on. It's easy to see how you would factor that work. 2023-10-08 22:41:29 Thos images on that website are very much what I think his screen would have looked like. 2023-10-08 22:42:49 That website is neat - I think it will actually simulate the designs. At least if you click on a trace, everything connected to that lights up, all across the design. 2023-10-08 22:48:33 Ah, yeah - there's a "play" button, and off it goes, running through all of its states. 2023-10-08 22:48:51 MrMobius - I gotta think you'll like that. 2023-10-08 23:43:07 You know, thinking about what I just said about Chuck's CAD system, and how he used pre-defined tiles like characters to pave the screen. Wouldn't that mean he'd have to have more than just one basic tile set in order to support different zoom levels? In fact, I'm having trouble seeing how it would be done, because you know you could zoom out until whole transistors fit in individual tiles. 2023-10-08 23:43:19 Obviously he couldn't show that detail, but what WOULD he show?