greebo

The focused elements are not necessarily from the same single group, right now any selection can be focused on. When cloning or creating objects adding it to a group might not be what's intended. Of course, selecting just a single group would make that desirable, not sure if the logic determining that would be a nightmare or not. This would be a separate feature request. It's similar to the reparent primitives or merge entities commands. There'll be need for some conventions when having more than one group selected. I see the point, and yes, it's possible to disable drag-selection for cam views. Separate feature request of course.

D'oh, sorry yes, of course I meant Ctrl-Tab. I'll wait a bit before doing anything, but I think it's desirable. Since the whole point of entering focus is to manipulate it in the orthoview, it makes sense to align the view to that area.

Probably not, but a couple of people around here have. I can upload it to my google drive if people don't want to create a Github account. That is something I need to look into, probably the user-defined input.xml is interfering, I have to check out how to properly override that without disrupting all the user bindings. I also thought about adding a button to the top toolbar next to the selection modes. As a workaround I can suggest pressing Alt-Tab since that will re-focus the ortho views to the selection OR the focus area if nothing is selected. So hitting Ctrl-F and then Alt-Tab should bring the ortho view into place. What about aligning the ortho view automatically to the focus once activated? Is that always desirable? I also have to make the involved colours configurable and come up with usable default colours for every colour scheme DR is shipping. I'm using the Maya/LW colour scheme since forever, and that's probably why I didn't notice it being less than helpful in Super Mal.

I got a feature in the works, allowing to select and manipulate only "focused" items, which should hopefully be useful for manipulating grouped items without having to disband the group. There's a demo video here: https://www.darkradiant.net/images/videos/selection_focus.mp4 It works like this: You select some items in the map. It doesn't matter what it is, it can be a group or many groups or just two unrelated brushes. Hit Ctrl-F to enter focus mode (the command is called "ToggleSelectionFocus" if you want to bind your own shortcut) Your actions will be restricted to just that selection You cannot select other items that are not in the group (unless you use Layer or Filter selections, or Invert selection) You'll get a visual indication about the focused items in the ortho view Grouping information is ignored while in focus, you can select single parts of any group You can select, move, rotate, delete, edit vertices etc. Hit Ctrl-F again to exit, or (maybe more intuitively) hit ESC until you left the focus The previous selection (before entering focus) is now active again, you can proceed manipulating that I'd appreciate if you folks could have a go and try it and then give feedback about it. There's no release yet, but you can grab a portable release from Github: https://github.com/codereader/DarkRadiant/actions/runs/3403010325

I would have assumed that the assertion wouldn't fire if existingIndex == -1 since that is also < tab count. At any rate, if existingIndex == -1 at this point in the code either the addControl or findControlIndexByName seem to have failed. Can you step through it and figure out what goes wrong? Is addControl failing?

That's a more specific stacktrace, I'd be interested in the message that g_log_structured_array() is receiving, can you see it somewhere in the local variable/stack? It seems to originate from gtk_scrolled_window, but maybe that's only used somewhere internally. Can you also try to run the application with an environment variable set, maybe it prints something: G_MESSAGES_DEBUG=all ./path/to/darkradiant

You can try PropertyNotebook::undockSelectedTab() - that's in radiant/ui/mainframe/PropertyNotebook.cpp

I think this exception is nothing unusual, these are all caught in the cmd::Argument class. (Not that this design is particularly good, but it should not cause a problem, let alone a shutdown). Is there anything else following this part? Any messages in the .log file?

The DR log file is all there is to see, I'm afraid. In case of crashes it will attempt to write some trace lines to the file, so maybe it contains something. DR doesn't have any log verbosity to configure like TDM. Otherwise it's just gdb and you, if there's no SIGSEGV or something recorded by gdb, then it's not a regular crash, maybe it's an exception - in which case there should be some log output in darkradiant.log too.

Can you get hold of a backtrace of that crash?

Ok, please report that (along with the distro you're using), I'll try to look into it. (Sorry if I'm seemingly asking all the time about your Linux configs, I just can't keep track who's using what combination).

Can anybody of the other folks running Linux confirm this troublesome rendering issue?

@AluminumHaste@SeriousToni This should be fixed in source now. The automated build is running on Github, you can grab a portable package when the build is done (scroll down to the Artifacts section): https://github.com/codereader/DarkRadiant/actions/runs/3358810112

Wow this looks like any openGL rendering is broken altogether. Which distro/window manager configuration is that?

I have doubts about whether everybody would like that. I myself would find the 2D view more important than the camera, most of the time I'm working on 2D. But I'm open to hear other people's preferences. Though it's possible to add some entries to the main menu, assign default shortcuts, or add an entry to the 2D view's context menu. To make it easier to find the "make camera main" option.

One can hold down the Ctrl or the Alt key to prevent docking of a floating window while dragging it, but that's of course not the full solution. If you report the issue on the tracker, I'll see to it that the property panel can be closed again. A shortcut bringing up a control that is docked as a property panel tab should then make the window appear again (or close it if it's visible).

You want the property panel completely closed? I think that might be one of the things that are not possible with the new layout, I have to add support for that.

See the first post, the various controls are listed in the "Window" menu now. With the new docking capabilities any of the removed layouts should be achievable in DR 3.5.0.

Specify incorrect, how does it look like?

Confirmed, I'll look into that for the next release. https://bugs.thedarkmod.com/view.php?id=6143 edit: fixed in source.

It's a limitation of the wxWidgets AUI framework that there is one "center" or "main" pane that cannot be removed or undocked or moved around. But you can swap out the main view with another one with a shortcut, have a look at the Edit > Keyboard shortcuts and look for the ones starting with ToggleMainControl. You should find one with ToggleMainControl_Camera - this one will replace the main orthoview with a camera view. By repeatedly pressing the shortcut you will keep changing between ortho and camera.

There's not much difference between the installer and the portable version. The installer just puts it into your Program Files folder and registers DR in the "Programs and Features" list for uninstallation. When uninstalling the data in the AppData\Roaming\DarkRadiant folder should and will not get touched, they stick around. If you plan on going ahead with the portable versions, just uninstall the old 2.x version and keep using the portable one.

A file has been missing in CMakeLists.txt, can you try again using latest master, please?

Linux, I suppose?

Some day, when my backlog has reached 100+ missions It might be a ghosting marathon, using a two-week supply of coke, peanuts and diapers.