jonri

Is not quite that, but more likely because wx uses native Windows controls there and gtk only on Linux. It does a pretty good job of abstracting away the differences but there are always corner cases where a subtle difference turns out to be important.

I'm honestly not sure, it's a race condition maybe? I found and fixed 2 different segfaults (PR is here), one relating to threading and the other one relating to a variable being referenced after it was cleared out. This stops the skin editor from crashing, but it seems there are still a lot of usability issues. I'm not sure if they are all Linux only, but here's what I found: The rename operation happens every time you type a character, which is a little laggy. It would be better to rename it when you are done typing and the field loses focus Typing new characters while renaming works as expected, but deleting characters causes the box to highlight so you have to reset the cursor before deleting another one. On the Material Replacements tab, click to edit is not working for me. I spent a lot of time on this, I can get a box to show up if I replace the editbox+button with a simple edit box. I think it's related to the compound control not being able to have focus. The skin name is showing up on top of the Close button This will require more wxWidget-fu than I have time to do right now.

Looking at the backtrace and the code, I think the culprit is here: https://github.com/codereader/DarkRadiant/blob/fa4c266a6776516b59740f78f57b849097d97618/radiant/ui/skin/SkinEditorTreeView.cpp#L44 The ThreadedDeclarationTreePopulator is created on the stack and thus deallocated at the end of the function. The EnsureStopped() function is called on deletion (https://github.com/codereader/DarkRadiant/blob/master/libs/wxutil/dataview/ThreadedResourceTreePopulator.cpp#L108) but this doesn't appear to actually wait for the deletion to finish. By the time the deletion request is processed, the object itself is no longer valid. Other usages I see put the object in a shared pointer instead of on the stack. I'll have a chance to look at this properly on Sunday and figure out the best way to fix it.

I think the devs just haven't had much time to put into it the past year (myself included). I took care of the mouse issue finally, since it became a 100% showstopper for me to use DarkRadiant at all on Linux. I've only ever made my skins using a text editor, but I tried reproducing the issue and it crashes with a backtrace for me too. This means debugging it should be straightforward, I'll look at it this weekend.

I've made a PR with some fixes required to release the Flatpak version, including a fix for the version number in CMakeLists.txt. I've pushed the updates to flathub, so the new version should show up there once their scripts pick it up.

I'm in, using this as motivation to continue the work I had previously started on my series. Probably not a whole lot in the way of horror, but I think I have some creative elements in the pipeline...

In case anyone decides to pursue this further, here are a couple more references: https://discourse.gnome.org/t/pointer-warping-on-wayland/9197 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158 Seems like this feature is also common in PCB design software. The "correct" solution would be to use Wayland's pointer locking interface and relative mouse events, which is essentially what the FreezePointer class accomplishes by continuously warping the pointer back to its original location. The complication is that the way it works now all goes through wxwidgets which then goes through gtk3 on Linux. To fully implement this, I think someone would have to: Create a platform-specific alternative to the cross-platform FreezePointer that we have now Make sure it's only called on Wayland, and only if the pointer locking API is available Work your way through the wxwidgets / gtk3 layers to get hold of the native wayland surface and pointer handles Reconcile the Wayland mouse events with the mouse events received by wxwidgets If someone was motivated enough to pick this up, it might make sense to try to build this in at the wxwidgets level and try to get it accepted there. It would help keep platform-specific code in the right place and also make a couple other projects happy.

It doesn't matter if you want to warp the pointer every frame or only once, in both cases GTK3 chose not to support it on Wayland. Here's the hack that Blender came up with: https://projects.blender.org/blender/blender/issues/77311 They found they had no choice but to render the cursor internally to get the intended behavior. Probably easier to do when you built your own widget toolkit like they did, rather than having to go through wxwidgets and GTK.

Yes, I probably should have been more clear. This fixes everything when running on XWayland (which emulates X the best it can but must still ultimately play by Wayland's rules). Last time I checked, GTK3 was not planning to support mouse pointer warping at all on Wayland and left the function as a no-op in the Wayland version. It might be simplest for us to figure out an easy way to automatically force the x11 backend to be used. Wayland is increasingly becoming the default, but XWayland is not going away anytime soon.

I've figured it out! There are 2 parts: 1. The FreezePointer class has a mismatch, it blanks the cursor on the top-level window but does the pointer locking on whatever particular sub-window (i.e. the 2D view widget) calls for it. The cursor has to be explicitly blanked on the same widget that locks the pointer. 2. The clipper tool updates the cursor whenever the mouse moves, even if it's in the middle of dragging and should be hidden. It was easy enough to guard against changing the cursor while the mouse capture is active. This also fixes the same issue that was happening in the 3D view of the model viewer (but not on the main 3D view). I'll submit a PR shortly, @greebo or others will need to test this change on Windows to make sure it doesn't do any harm there. EDIT: The PR is here: https://github.com/codereader/DarkRadiant/pull/37

I revisited this issue and might have had a breakthrough. I noticed that when using the clipper my cursor wasn't changing, and afterwards when the cursor was no longer hidden when the dragging problem starts happening. If I take out the code that is supposed to change the mouse cursor when activating the clipper, the drag behavior remains correct during and after using the clipper tool. If I remember correctly from last time I went down this rabbit hole, Wayland has restrictions on pointer locking and I think it was only allowed while the pointer is hidden. I'm guessing something with changing the cursor is failing and then it doesn't get hidden before the pointer lock happens, causing Wayland to reject the pointer lock request. And when the pointer doesn't get locked, the math to calculate the drag amount goes all wonky. @MirceaKitsuneor others, if you'd like to try a quick and dirty workaround, find the void OrthoView::setCursorType(CursorType type) function and put a return statement on the first line so it doesn't actually change the cursor. I'll see if I can figure out what's actually going wrong when setting the cursors so we can make a proper fix.

I've been feeling the itch to start mapping again, and I'd like to pick up my stalled WIP for the next FM building off my first one. If we end up with lighter contest requirements I'd run with this for the fun of participating. If my FM doesn't end up meeting contest criteria I'll still keep the October timeframe as a goal though. A mild requirement like "include a nod to a classic Thief/TDM map somewhere in your mission" sounds like a nice way to keep participation up without going full free-for-all.

The problem comes when the mouse leaves the window. For example, if you start dragging the 3D view to turn left and your mouse gets all the way to the left side of the window, you won't be able to keep turning left. In order to turn left infinitely, the mouse pointer has to get snapped back to give you room to keep moving the cursor left.

I came across this bug report on wxwidgets: https://github.com/wxWidgets/wxWidgets/issues/23778 The short of it is that GTK decided not to support mouse pointer warping on wayland. There may be some sort of workarounds by making direct wayland calls, but I'm not sure yet if that's something we could even do from our layer, or if it would have to happen within wxwidgets.

I gave it a try, and mine crashed with the same segfault the first time I tried. I've attempted to reproduce it while running under GDB and haven't gotten it to crash again yet. Each time I started it it up the same way without moving. I did a little source code snooping and the only places I found that would print out that particular message "Getting threadname failed" would be where Sys_GetThreadName is called to print out some information when a mutex is busy, deadlocked, or not locked when it should be; or also when a thread is destroyed. If I manage to catch a backtrace I'll share it here or on the bug tracker.

It's not specific to the flatpak version, it happens in my dev build on Arch linux too.

Would you mind checking the other windows listed on https://bugs.thedarkmod.com/view.php?id=6165 to see if they cause crashes as well?

Is this still true now that 2.11 is out with this feature? I've been wondering about whether this might open up the possibility to use larger models for things other than terrain, for example modeling a building at a time in Blender and then assembling them into a street in DR. I'll probably at least test it out someday...

I doubt it's something on our end, as we just tell flatpak that we need OpenGL support and it's supposed to figure out the rest. I'll see if I can read up on it a little though. Flatpak has many advantages, but storage space efficiency is not one of them.

I just updated the flatpak, so it should hit flathub in a little bit.

I've been trying to finish off a handful of projects and experiments I had started a while ago, and remembered that I ran into a roadblock. I was trying to build some custom entities with slightly complex behavior and had wanted to access a def_attach'd entity from the script on its parent object. These script functions sounded pretty close: scriptEvent entity getAttachment(string attName); Get the attached entity with the given attachment name Will be NULL if the name is invalid or if the entity no longer exists Spawnclasses responding to this event: idActor scriptEvent entity getAttachmentInd(float index); Get the attached entity at the given index. Will be NULL if the index is invalid or the entity no longer exists index: starts at 0 Spawnclasses responding to this event: idActor scriptEvent float getNumAttachments(); Return the number of attachments on an AI. Used to iterate through the attachments if desired. Spawnclasses responding to this event: idActor But as you can see, they only apply to idActors. I dug into the source code and found that the code that handles all 3 of these functions just calls into the idEntity base class to retrieve the attachment, and there does not appear to be anything specific to idActor with those. As such, I'm fairly certain that these script events could be moved to idEntity without breaking any existing usages (assuming script event inheritance works as expected). Are there any downsides to doing this? I can create a bugtracker entry and/or provide a patch if there are no objections.

Looks like it didn't help this mystery issue for me

I wonder if this explains https://bugs.thedarkmod.com/view.php?id=6165 which I was never able to get anywhere with. When I get a chance I'll make a build with that fix and see what happens.

DR uses wxGTK on Linux, so I'd expect anything that works for other GTK applications would do the trick. I'm not set up to try it myself, but it looks like you might try setting the GDK_BACKEND=x11 environment variable.

Can you convince it to run under xwayland? A proper fix is preferred, of course, but this might make it usable in the meantime.