Qt · brlcad · Zulip Chat Archive

/me rediscovers alacritty and thinks it might be a viable embedded terminal solution!

starseeker (Sep 14 2020 at 22:01):

starseeker (Sep 14 2020 at 22:15):

/me debates between the dreary utility of trying to properly fix the WiX msi installer's startup dirs and diving back into the src/other superbuild thorn pile...

Sean (Sep 15 2020 at 14:01):

@starseeker thanks, that's interesting. do you have any indication that it actually works on Windows though? It looks like it uses libvterm which, I may be mistaken, doesn't appear to be for Windows. I looked at the source code and it doesn't look like libvterm uses pty, so that's promising, but still left wondering what it does.

Sean (Sep 15 2020 at 14:04):

Sean (Sep 15 2020 at 14:06):

that's what makes alacritty interesting. it has a similar virtual terminal interface, but is using an abstraction underneath to establish a pseudoterminal interface on windows.

Sean (Sep 15 2020 at 14:06):

I mean, it'd be quite a feat of engineering given it's another language stack, but it's one of only three possibilities I've found so far.

starseeker (Sep 15 2020 at 14:48):

Sean (Sep 15 2020 at 14:49):

it's used by emacs-vterm too, but the specifically say it doesn't work on windows

Sean (Sep 15 2020 at 14:51):

starseeker (Sep 15 2020 at 14:52):

I'd have to dig into what neovim is doing. It sure felt like they were terminal emulating when I last ran it...

Sean (Sep 15 2020 at 14:52):

only know of a handful of libs that extract an interface that includes windows support, two being in Node's ecosystem

starseeker (Sep 15 2020 at 14:52):

Sean (Sep 15 2020 at 14:52):

Sean (Sep 15 2020 at 14:53):

starseeker (Sep 15 2020 at 14:53):

No, that I didn't try - I was referring more to the look/feel of the neovim editing window and interactions.

Sean (Sep 15 2020 at 14:54):

starseeker (Sep 15 2020 at 14:55):

Fair enough - I seldom run external commands from an editor, so it's not something I would miss

Sean (Sep 15 2020 at 14:55):

there's even a separate module to kick off a command shell -- and something like that is always an option

starseeker (Sep 15 2020 at 14:55):

Sean (Sep 15 2020 at 14:55):

i.e., just maintain two separate interfaces -- I've seen a lot of projects do that. pty for non-windows and msys for windows

Sean (Sep 15 2020 at 14:57):

if libvterm abstracts the line interpreter (usually the pty bit coming from the system), then they could avoid needing a pty interface altogether. I've been hoping to find some solution like that as we don't actually need kernelspace interaction

Sean (Sep 15 2020 at 14:57):

starseeker (Sep 15 2020 at 14:58):

Sean (Sep 15 2020 at 14:58):

but that means interactive commands are no good. that's why mged does all it's "MORE_ARGS" funniness

starseeker (Sep 15 2020 at 14:58):

Sean (Sep 15 2020 at 14:58):

starseeker (Sep 15 2020 at 14:59):

I'm updating the git conversion right now, I'll flip OSes once that's done and try neovim on Windows. Anything specific I should try?

Sean (Sep 15 2020 at 15:00):

it's whether it's abstracted enough of the i/o interpretation for the tty driver

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:01):

starseeker (Sep 15 2020 at 15:11):

starseeker (Sep 15 2020 at 15:12):

starseeker (Sep 15 2020 at 15:37):

Sean (Sep 15 2020 at 17:31):

Cool, that's great to know too, and will undoubtedly be easier to maintain than alacritty then

Sean (Sep 15 2020 at 17:32):

Sean (Sep 15 2020 at 17:33):

Sean (Sep 15 2020 at 17:39):

Sean (Sep 15 2020 at 17:41):

cool, looks like conpty doesn't use msys or cygwin, so just need to find that code and extract it or find someone else that wraps them with unixpty, like these guys: https://github.com/kafeg/ptyqt

Sean (Sep 15 2020 at 17:42):

Sean (Sep 15 2020 at 17:43):

starseeker (Mar 17 2021 at 20:14):

/me ponders whether the libged subprocess mechanisms should be generalized to allow using QProcess, as well as libbu's subprocess...

Sean (Mar 18 2021 at 04:04):

That doesn't make a lot of sense to me. It's make more sense to make it an implementation option in libbu.

starseeker (Mar 18 2021 at 12:15):

I'll study it some more... I'm hoping QProcess might offer some advantages integrating the libged command I/O into Qt gui elements, but as far as I can tell you can't create a QProcess using an already-launched program, so I'm not sure how that would/could work with a libbu API...

Sean (Mar 18 2021 at 19:15):

I don't understand ... QProcess invokes a binary and sets up I/O handlers. That's pretty much the scope of what bu_process_exec() and the other API in process.c are doing too.

Sean (Mar 18 2021 at 19:19):

Making Qt a library requirement is a big architectural decision that really shouldn't be made lightly.

Sean (Mar 18 2021 at 19:20):

and an even bigger one if it's not encapsulated behind API... that would go against our current architecture as an antipattern

Sean (Mar 18 2021 at 19:24):

Getting it to work underneath bu_process_*() would likely expose a variety of limitations / assumptions in that code now. That would be very useful to eliminate from the API, a really good thing, and keep it encapsulated (== more maintainable).

starseeker (Mar 18 2021 at 19:34):

@Sean My hope (although I don't know yet) is that QProcess will have signal/slot integrations with Qt's subsystems that offer advantages. I agree it shouldn't be exposed publicly in the APIs. My query was whether a Qt based application could somehow be set up to fire libged commands that are launched as subcommands (currently rt and friends, but eventually most or all of them) using QProcess, rather than the implementations currently underneath the libbu subprocess code. It could very well be that there aren't any advantages, or at least not compelling ones - I just don't know yet.

starseeker (Mar 18 2021 at 19:35):

It'll be a while before it comes up, anyway - currently I'm getting my tail kicked around the keyboard trying to figure out how to get OpenGL rendering to work in a QThread to not block the main app.

Sean (Mar 19 2021 at 02:56):

I wasn't referring to being publicly exposed in the API. That's a WHOLE other level of antipattern and wouldn't be compatible with libged public API anyways.

It's about it being encapsulated or not. If it's directly called by a library, then that becomes a coupling. If the coupling is in all call sites, then it's a tight coupling that is more costly to replace than if it were encapsulated (i.e., light coupling).

Sean (Mar 19 2021 at 03:00):

That said, there are a couple ways to avoid tight coupling and still use it in libged. There's putting it behind libbu API, or we could add a delegate mechanism where the calling application code passes in a handler that uses QProcess to invoke.

starseeker (Mar 28 2021 at 14:03):

Woo-hoo! Still in its rudimentary beginnings, but first correct display of a libdm generated wireframe in a Qt supplied OpenGL using the new libdm setup and qtgl backend: libdm_and_QOpenGLWidget.png

Sean (Mar 29 2021 at 03:58):

starseeker (Mar 30 2021 at 15:53):

Early beginnings of decoding MGED's mouse interactions (wow - modes upon modes upon modes. gnarly...)
Qt_libdm_mouse_rot.gif

starseeker (Mar 31 2021 at 00:18):

Sean (Mar 31 2021 at 12:10):

starseeker (Mar 31 2021 at 15:48):

Not yet - I'm still working on getting it to build on the Mac without manual hackery

starseeker (Mar 31 2021 at 15:49):

All the work we did to get our CMake logic to detect the X11 OpenGL is cutting against me now.

starseeker (Apr 02 2021 at 01:17):

starseeker (Apr 02 2021 at 01:28):

@Sean It's still pretty rudimentary, but I did get it to build on OSX if you wanted to give it a go. For Mac it needs both -DBRLCAD_ENABLE_QT=ON and -DQt5_DIR=/path/to/dir/with/cmake/config/file

Sumagna Das (Apr 02 2021 at 06:21):

starseeker (Apr 02 2021 at 12:29):

I'm developing with it on Linux, but it's still way too rudimentary for me to recommend trying it - it's just a testbed right now for figuring out what needs to be done to make libdm and Qt work together. I know of at least one major change I need to make, and likely more.

Sumagna Das (Apr 02 2021 at 12:59):

Oh
I would like to try it out when it is available
Ping me up after this is out of beta state:sweat_smile:

starseeker (Apr 03 2021 at 22:56):

@Sumagna Das out of beta state will be a long while. If you want to check it out it's located in src/isst/dmtest and will compile to produce the qdm executable with -DBRLCAD_ENABLE_QT=ON passed to CMake. Just remember it's an experiment in combining libdm and Qt at this point, so nothing much is going to work...

Sumagna Das (Apr 04 2021 at 06:18):

starseeker (Apr 07 2021 at 16:17):

starseeker (Apr 07 2021 at 19:25):

Sumagna Das (Apr 07 2021 at 21:03):

It might be helpful if you keep a list here or somewhere (atleast for me:sweat_smile:)

Sumagna Das (Apr 07 2021 at 21:03):

starseeker (Apr 07 2021 at 21:24):

So far, all I've got is basic view manipulation (rotate, translate, scale) and some of the faceplate elements (the last video). I've had pretty lousy luck with using a separate rendering thread (didn't work at all on the Mac, and even on Linux the faceplate matrices mess up the display - the fixes for that issue in the single threaded version didn't seem to work for the separate thread.)

starseeker (Apr 07 2021 at 21:27):

I'll be looking at some more of the Archer/libtclcad manipulations next - both view element manipulation and sketch editing are going to require more than just the current view operations, and I need to figure out how how that's going to work.

starseeker (Apr 07 2021 at 21:56):

I'm concerned the hashing trick I'm using to avoid having to list out which commands might alter the geometry won't scale - testing with the Stanford Lucy model is not encouraging. It works, but it's slow for all commands, not just view updates.

starseeker (Apr 07 2021 at 21:58):

starseeker (Apr 07 2021 at 22:46):

Growl. Yep, hash calculations for Lucy are too slow for this purpose. Time to invent plan B...

starseeker (Apr 08 2021 at 15:39):

starseeker (Apr 09 2021 at 20:07):

starseeker (Apr 13 2021 at 19:38):

starseeker (Apr 13 2021 at 23:46):

starseeker (Apr 14 2021 at 01:32):

starseeker (Apr 18 2021 at 03:55):

Bit of a detour: here's a demonstration of using bundled OSMesa software rendering to display the same OpenGL drawing calls used by the qtgl backend. My Linux box manifested some sort of OpenGL problem, which was annoying but also a perfect testing environment to get this working: Qt_with_software_rasterizer_fallback.gif

starseeker (Apr 18 2021 at 03:57):

The initial messages are the important ones - the first lines are the QOpenGLWidget failing to set up properly, and then our message indicating we're falling back on software rasterizing. The view axes show that we have not just the wireframes but also fontstash text rendering with this backend. In principle (unlike the X backend) this is a fully portable solution to fallback rendering. As an added bonus, most of the drawing code it uses is the same code as our other backends.

starseeker (Apr 18 2021 at 17:12):

OK. For anyone who may have tried the software backend, they probably saw the following if they resized the window: resize_problem.gif

starseeker (Apr 18 2021 at 17:13):

This turned out to be a mismatch between Qt's QImage and the OpenGL data. I've figured out a working path, so the resize behavior should now look like this: resize_fixed.gif

starseeker (Apr 18 2021 at 17:15):

(The software rendering can be explicitly triggered by launching with the "-s" option to qdm, for those that have working OpenGL.)

starseeker (Apr 19 2021 at 02:00):

For grins, here is gsh running swrast without any on-screen graphics at all but still supporting screengrab: swrast_command_line_only.gif

Sean (Apr 19 2021 at 16:14):

Thats awesome! Any metrics on the performance impact? There is a faceplate FPS meter you may be able to turn on to show what the rate is during rotation.

starseeker (Apr 19 2021 at 16:15):

starseeker (Apr 19 2021 at 18:30):

starseeker (Apr 19 2021 at 18:32):

starseeker (Apr 19 2021 at 18:36):

starseeker (Apr 19 2021 at 18:40):

starseeker (Apr 19 2021 at 18:42):

starseeker (Apr 19 2021 at 18:45):

For me this is acceptable (though certainly not ideal) since the intent of swrast is as a last-resort fallback rather than a primary operating mode. Under normal circumstances the expectation would be that the accelerated context is available.

starseeker (Apr 19 2021 at 18:48):

It may be possible to translate the X wireframe logic to a generic, platform agnostic equivalent of swrast, but it will still lack the shading capabilities (however slow) that swrast offers.

starseeker (Apr 19 2021 at 18:51):

A possible hybrid approach would be to treat such a platform agnostic X drawing routine the same way we look at the TIE raytracing - have it render to a buffer, then composite the buffer in OpenGL to produce the final drawing. For wireframe only drawing we could do that, and then fall back to the slower all-OpenGL mode for more complex scenes.

Sean (Apr 19 2021 at 18:52):

starseeker (Apr 19 2021 at 18:54):

Part of the issue is undoubtedly how old this OSMesa is - it is extracted from 7.0.4, which is the last version of the software rasterizer that didn't start depending on more complex substrates for better performance. I know the modern Mesa software rasterizers are way way faster, but they're also a lot more complex.

starseeker (Apr 19 2021 at 19:17):

starseeker (Apr 19 2021 at 19:19):

starseeker (Apr 19 2021 at 20:26):

Nevermind. Not 100% sure how fast an "extracted" X wireframe render would be anyway, since I'm not sure if X has some sort of graphics driver level routines its talking to...

starseeker (Apr 19 2021 at 22:04):

starseeker (Apr 20 2021 at 14:39):

Sean (Apr 20 2021 at 16:12):

@starseeker I think it does (otherwise Z-clipping wouldn't do anything)...but I don't know for sure.

starseeker (Apr 20 2021 at 18:38):

starseeker (Apr 22 2021 at 11:58):

starseeker (Apr 22 2021 at 21:13):

starseeker (Apr 23 2021 at 01:22):

starseeker (Apr 23 2021 at 12:20):

starseeker (Apr 23 2021 at 19:33):

starseeker (Apr 23 2021 at 22:02):

starseeker (Apr 25 2021 at 23:26):

starseeker (Apr 27 2021 at 14:00):

starseeker (Apr 29 2021 at 18:21):

This won't look like much to the casual eye, but it has both matrix application and correct colors using the new drawing setup (labels are just on for testing purposes): first_correct_colors_new_draw.png

starseeker (May 04 2021 at 23:37):

This is a side effect, but got hidden line mode working in MGED: hidden_line_mged.png

starseeker (May 05 2021 at 00:52):

No colors yet, but first shaded view of moss with new drawing setup: first_shaded_moss.png

starseeker (May 05 2021 at 03:23):

Sean (May 05 2021 at 04:33):

starseeker (May 05 2021 at 13:03):

starseeker (May 05 2021 at 20:01):

Sumagna Das (May 05 2021 at 20:03):

starseeker (May 05 2021 at 20:05):

Heh. rook makes a great example of the benefits of bigE mode - large subtractions and intersections

starseeker (May 05 2021 at 20:07):

The E command isn't working in MGED right now for some reason, but a quick look indicated the vlists were still being created (i.e. the problem is strictly on the display end) so it was worth refactoring the logic to work with draw2.

starseeker (May 05 2021 at 20:11):

Still got some more options to work through (transparency, subtraction suppression, etc. - I'm not adding the NMG debugging draw options, those belong elsewhere). Also need to look at the drawing outputs produced by nirt, rtcheck, gqa, etc.

starseeker (May 06 2021 at 00:22):

Can anyone test transparency (draw -m1 -x 0.7 all) on the share/db/faa/Generic_Twin.g example model? I can't get either latest main or the 7.30.10 release to draw with any sort of shading, and I'm wondering if my local OpenGL is messed up again...

starseeker (May 06 2021 at 01:30):

starseeker (May 06 2021 at 01:34):

starseeker (May 06 2021 at 01:47):

starseeker (May 06 2021 at 14:01):

Sean (May 06 2021 at 14:16):

It would be interesting to go half way. draw dashed subtractions, but clip to the positive bounding box so it doesn't distort the entire view.

starseeker (May 06 2021 at 15:52):

starseeker (May 07 2021 at 01:38):

Early stages yet, but working on getting the adaptive plotting up and running: adaptive_first_steps.png

starseeker (May 07 2021 at 16:35):

starseeker (May 07 2021 at 19:06):

starseeker (May 08 2021 at 22:54):

starseeker (May 09 2021 at 17:04):

Confirmed rect command can create the interactive rectangle: interactive_rect.png

starseeker (May 12 2021 at 17:18):

Mutter... still using the old pixel approach instead of a texture, but working qtgl framebuffer display: qtgl_fb_display.png

starseeker (May 12 2021 at 20:13):

starseeker (May 12 2021 at 23:58):

starseeker (May 13 2021 at 13:08):

starseeker (May 13 2021 at 18:49):

starseeker (May 14 2021 at 03:04):

starseeker (May 14 2021 at 16:31):

starseeker (May 16 2021 at 01:57):

starseeker (May 18 2021 at 19:46):

@Sean Do you know if libpkg can communicate using stdin/stdout between two processes, as well as TCP sockets?

Sean (May 18 2021 at 20:02):

@starseeker yes, the code for it is there for some platforms (and that is very much a platform-specific thing), but I'm not sure how much it's exercised or what tools even make use of it.

Sean (May 18 2021 at 20:03):

see all the references to un.h and UNIX domain sockets -- that's the IPC mechanism you're referring to for interprocess communication.

starseeker (May 18 2021 at 20:04):

Well... I was just thinking about launching a subprocess, sending pkg contents down stdin to the other program, and getting its responses back by listening to its stdout.

Sean (May 18 2021 at 20:04):

INET TCP sockets are what are more frequently created and utilized by calling apps like rt, but in theory it should chatter over a UNIX port.

starseeker (May 18 2021 at 20:05):

Sean (May 18 2021 at 20:05):

Sean (May 18 2021 at 20:06):

at least on linux
I'd expect windows would need some modifications because it probably assumes a tcp socket in some places .. but don't know, that's not something we've ever tested.

starseeker (May 18 2021 at 20:07):

/me nods. OK, mostly I'm just being lazy and hoping I could use the same mechanism I'm already using for the framebuffer I/O - but if it's not something that has been tried with the code I should probably just go with what's there.

Sean (May 18 2021 at 20:09):

starseeker (May 18 2021 at 20:10):

Bob fell back on Tcl channels for Windows, with a cryptic note that pkg_permserver "beget other mods" when trying to use it there. Maybe it's time to revisit that and see if it still applies - I know I fixed at least one issue in libpkg on Windows a while back.

Sean (May 18 2021 at 20:11):

Sean (May 18 2021 at 20:12):

permserver I think specifically kicks off a tcp listener. you'd be using the calls that come after that (I think).

starseeker (May 18 2021 at 20:12):

Not for stdin/stdout, true - I've been going through the fbserv code in libtclcad since the most "straightforward" path is to translate the Tcl listening logic into Qt terms.

starseeker (May 18 2021 at 20:12):

Unfortunately, so far at least, there's nothing straightforward about any of this... I suppose mostly because I have ziltch experience with async I/O between programs.

Sean (May 18 2021 at 20:16):

all the more reason to try a demo. implementing a chat program with a given interface is like towers of hanoi, a rite of passage in CS curricula.

starseeker (May 21 2021 at 20:35):

After a week, @starseeker finally gets an image to render (still in the wrong place) in the embedded fb via Qt's Tcp logic.

starseeker (May 21 2021 at 20:36):

/me is beginning to wonder how many straightjackets are typically necessary for this sort of programming... it's almost of a piece with the joys of standing up OpenGL rendering.

starseeker (May 21 2021 at 20:50):

starseeker (May 24 2021 at 20:35):

Sean (May 25 2021 at 02:21):

starseeker (May 25 2021 at 02:23):

Not too bad, once I found the right foo in the RtControl.tcl file and translated it to ert. The HARD parts were the Tcp+libpkg communication, signals/slots async updating, and getting all the OpenGL ducks in a row to draw correctly.

starseeker (May 25 2021 at 02:24):

I've still got some work to do for the swrast version, and will need to take a file to the rough edges in a number of places, but that's a pretty fundamental "yes this really can work" milestone.

starseeker (May 25 2021 at 15:48):

starseeker (May 26 2021 at 14:21):

starseeker (Jun 01 2021 at 17:43):

starseeker (Jun 02 2021 at 14:39):

starseeker (Jun 02 2021 at 19:52):

starseeker (Jun 03 2021 at 22:21):

Sean (Jun 04 2021 at 17:02):

Would be nice to provide some visual indication for which quad view currently has 'focus' for when running commands like autoview and such that apply to only one view. Maybe a hairline 1px highlight border.

starseeker (Jun 04 2021 at 17:59):

I was thinking either that or changing the background color in the non-selected views. Prefer the border if I can figure out how to get that to work (the spacers I'm currently using don't accept a color setting as far as I can tell, which would have been the easiest thing - means I'll have to get a little more custom.)

Sean (Jun 04 2021 at 19:08):

starseeker (Jun 05 2021 at 23:45):

starseeker (Jun 05 2021 at 23:46):

Daniel Rossberg (Jun 06 2021 at 16:32):

I got a compilation error with Qt 5.15.2 in file src/libqtcad/QtCADTree.cpp at line 1079: QString::SkipEmptyParts is deprecated. The new constant (since Qt 5.14) is Qt::SkipEmptyParts. I don't know, how usual Qt 5.14 or higher is. Debian buster (stable) uses Qt 5.11, but I have to modify the sorces for this version anyway because of Qt::ScrollMomentum, introduced in Qt 5.12.

starseeker (Jun 06 2021 at 18:28):

@Daniel Rossberg I'll defer to @Sean on whether we want to conditionalize the code for various version of Qt - I suppose the "correct" thing to do would be to configure time test for various features, but I've not yet tried setting up those sorts of checks in a configure step.

Sean (Jun 07 2021 at 14:48):

If something isn't working or is deprecated in the latest Qt 6, I think we'd be much better off fixing it as soon as possible instead of locking into an older Qt prematurely.

Sean (Jun 07 2021 at 14:49):

The only reason to ignore the deprecation warnings would be in code that we're potentially not going to use.

starseeker (Jun 08 2021 at 13:57):

Figures... in the end, my efforts on the Accordion widget weren't needed - if I rethink how I'm organizing the info/control widgets a bit, QDockWidget itself can do the job even better: docked_palettes.gif

Erik (Jun 08 2021 at 14:15):

looking very "right"! can the console be moved to a side? can the h-order be changed by the user? (ultrawide monitors kinda change the ... geometry of the situation.)

starseeker (Jun 08 2021 at 15:10):

Console can be detached, but it's bottom only at the moment. Not sure what you mean by h-order?

starseeker (Jun 08 2021 at 15:12):

The ordering in the column can be changed (attributes at top, view controls at bottom, etc.)

starseeker (Jun 08 2021 at 15:14):

If it makes sense to allow the console to be side docked that's an easy setting change in the code - trying to trade off flexibility vs. too much opportunity for users to do unexpected things.

Erik (Jun 08 2021 at 15:49):

h-order like moving the geometry window to the right side, or middle, or move the view window to the right, or ...

Erik (Jun 08 2021 at 15:49):

Erik (Jun 08 2021 at 15:51):

screens are getting wider faster than taller, top and bottom realestate are precious, so we end up with a bunch of columns

starseeker (Jun 09 2021 at 02:12):

starseeker (Jun 10 2021 at 00:03):

starseeker (Jun 10 2021 at 19:34):

Sumagna Das (Jun 10 2021 at 20:07):

is this going to be the new user interface of mged or archer after its complete?

starseeker (Jun 10 2021 at 20:20):

Sumagna Das (Jun 10 2021 at 20:22):

starseeker (Jun 10 2021 at 20:22):

starseeker (Jun 10 2021 at 20:24):

The plan is to eventually replace both - I may try making an MGED style interface using a toolkit other than Qt to make sure I'm not baking any Qt-isms in too deep, but there's not much point in that until the Qt pieces are in place.

Sumagna Das (Jun 10 2021 at 20:25):

starseeker (Jun 10 2021 at 20:26):

starseeker (Jun 11 2021 at 00:57):

starseeker (Jun 12 2021 at 04:15):

Well, my event filter trick for the tree is a problem, but leaving that aside for the moment here's GUI based on/off control for faceplate elements: qged_faceplate_ctrls.gif

starseeker (Jun 12 2021 at 15:02):

starseeker (Jun 14 2021 at 20:40):

starseeker (Jun 15 2021 at 01:03):

starseeker (Jun 16 2021 at 14:50):

starseeker (Jun 16 2021 at 19:39):

Erik (Jun 17 2021 at 12:59):

super awesome... so the 'csg' (poly bool ops, I guess) is applied immediately and the stored result is always explicit?

starseeker (Jun 17 2021 at 18:54):

Yes - it's the clipper boolean outputs, and they'll replace the original polygons.

Sean (Jun 19 2021 at 02:01):

Hey @starseeker ... any chance you can try to stash the result into a sketch object?? That could be the start of an outstanding replacement for the sketch editor, or even just as a debug facility to stash the results into the .g

starseeker (Jun 19 2021 at 16:30):

Yes, Bob had logic for that and I've got it integrated at lower levels. Not exposed in the GUI yet - need to get things like color and fill going first - but it's definitely on the list. (Once I have that working, I'll shift the tools from the view to the object edit palette.)

starseeker (Jun 19 2021 at 16:32):

To do a proper sketch editor with it, we'd have to associate non-polygon sketch segments with the polygon segments in such a way that they survive boolean ops, so we can turn around and use the resulting polygons to construct (say) an arc from a circle if the circle got chomped during the boolean.

starseeker (Jun 19 2021 at 16:32):

I think I saw something in the development version of clipper that might be useful for the bookkeeping part of that, but I've not tried it as I didn't want to toss an unfinished clipper into the mix at this stage.

starseeker (Jun 20 2021 at 15:36):

starseeker (Jun 21 2021 at 17:51):

Sean (Jun 21 2021 at 20:23):

Maybe, but even if it turned it into all polylines, I think that'd be just fine. I mean, that's worlds better than the current options.

Sean (Jun 21 2021 at 20:27):

The only question youd have to sort out for revolve and extrude, I think, is where the principal axis resides (e.g., always at [minX,minY]).

Sean (Jun 21 2021 at 20:28):

Would be interesting to figure out how to extend sketch with color attributes, so those can be stored in objects too.

Dashamir Hoxha (Jun 22 2021 at 06:53):

These animations are making me interested on your work. If you arrange a virtual meeting (with screenshare etc.) to present your work, I would be interested in joining.
However I am not sure whether this is a good idea, or whether other people would be interested in joining too.

Myself I am working on improving the documentation system, and I would like to make a presentation of my work by the end, when most of it is done. Assuming that people are interested in joining it.

starseeker (Jun 22 2021 at 18:32):

Thanks! It'll probably be a while before it's presented anywhere, but I appreciate the interest.

starseeker (Jun 22 2021 at 18:33):

Note in particular the appearance of the new sketches in the tree widget on the left as they are created, as well as the update due to renaming.

starseeker (Jun 22 2021 at 23:50):

starseeker (Jun 24 2021 at 15:46):

starseeker (Jun 25 2021 at 14:10):

Slightly more intuitive way to set vZ - specify a 3D point. Example showing adding a circle through the center of a torus:
qged_setting_vZ.gif

Sean (Jun 26 2021 at 05:55):

Er, terminology check -- is that actually a sketch?? Looks like a serialized view object, not a sketch object.

starseeker (Jun 26 2021 at 13:05):

It's a sketch object with metadata for colors and fill state stashed in attributes.

starseeker (Jun 26 2021 at 13:06):

What is being drawn is the view object generated from that metadata and sketch data. If you were to draw the t1 sketch in the scene, rather than importing it as a view polygon, you would see a red circle.

Sean (Jun 29 2021 at 04:54):

starseeker (Feb 14 2022 at 03:42):

Sean (Feb 14 2022 at 15:54):

How does it perform with 100k items and doing insertions/deletions in the middle? Responsive?

starseeker (Feb 14 2022 at 22:01):

Haven't stress tested yet - still working on getting it not to crash in weird places.

Sean (Feb 15 2022 at 00:36):

I'm seeing crashes after return from main() again... appears to be some corruption. Trying to catch it.

starseeker (Feb 15 2022 at 01:10):

starseeker (Feb 15 2022 at 02:27):

starseeker (Feb 16 2022 at 22:13):

starseeker (Feb 17 2022 at 16:28):

Sean (Feb 17 2022 at 21:10):

starseeker (Feb 18 2022 at 20:22):

Sean (Feb 24 2022 at 20:58):

@starseeker thinking of the recent PR, I'm wondering if we should keep track of who contributes to qged in AUTHORS or in a separate README/AUTHORS file that's qged-specific in case it moves

Sean (Feb 24 2022 at 21:05):

ddreeves70 was involved back in 2009 on the nurbs/brep ray tracing code ... wonder if he'd pick it up again to work on optimization

starseeker (Feb 25 2022 at 00:02):

@Sean I'm game to keep a separate README/AUTHORS going, although it's not my intent to split qged out from the main repo yet. (I'm deliberately molding the backend libraries and the GUI together to try and improve both - when things get closer to a working/finished state we can have that discussion.)

starseeker (Feb 25 2022 at 00:03):

starseeker (Feb 25 2022 at 00:13):

Sean (Feb 25 2022 at 06:02):

yeah, @David Reeves don't take my comment to imply a desire or priority or such, just a passing comment. you should work on whatever interests and motivates you!

Sean (Feb 25 2022 at 06:04):

David Reeves (Feb 25 2022 at 06:54):

Thanks Sean and Cliff for the kinds word. Hopefully I can make more of an impact here. I will for now continue working on the QGED. Cliff I was thinking of looking into the HUD stuff next but if you think there is something better for me to work I am fine with working on the other stuff. Also if you guys will point me to test cases and the goal of improvement I will work on the NURBS stuff if I need a break from QGED. Also on QGED is it ok if I commit directly to main or do you want me to continue with pull request. Also on QGED if you are ok I would not mind doing a little bit of refactoring some inconsistencies with the HACKING guide. It bugs my OCD nature. BTW if you are discussing Author credit stuff on QGED for my benefit don’t worry about it for now. If QGED gets released you can give me credit then

starseeker (Feb 25 2022 at 13:14):

starseeker (Feb 25 2022 at 13:16):

Please feel free to refactor to conform with HACKING - when working on QGED I've been trying to drive hard and fast towards functionality, and often times that means I end up committing something that works but doesn't satisfy all the style points. (Indeed, most of the spelling mistakes fixed in the recent pull request were my fault.)

David Reeves (Feb 25 2022 at 15:21):

@starseeker I apologize if it sounded like I was being critical that was not my intention. I am very inspired by what has been done so far. It is great work. The integration between dm fb and QT was no small feat

starseeker (Feb 25 2022 at 19:12):

starseeker (Feb 25 2022 at 19:13):

If you want to see me complaining, watch me try and debug some obscure interactive problem in the Archer Itcl/Itk code :-P

David Reeves (Feb 26 2022 at 05:14):

@starseeker I'm open qged with moss.g noting displayed and I select view model axes and getting a core dump. When I look at what is happening I'm getting an assert on line 3155 of libdm->fontstash->stb_truetype.h if I uncomment lines 3151 & 3152 that you commented out 5 months ago due to a clang static analyzer report, it passes the assert and the axes display as expected. I'm not really sure what is going on but this is the core dump I was talking about earlier but I just didn't have time to open up in gdb to find out where it was dumping at. I'm curious why my code is all the sudden triggering this failure. I remember before my latest round of changes axes display was working. Any thoughts?

starseeker (Feb 26 2022 at 18:30):

@David Reeves good catch. I'll re-run the analyzer on the previous commit to take another look at what the error was .

starseeker (Feb 26 2022 at 18:32):

My first thought was that something about the view initialization might be different between quad view and the single widget - if you look through the backtrace, at some stage the call that's getting into fontstash and stb_truetype is getting input values from our code. If the view is the same between the quad view single-window version and the previous single-widget approach, then something must be initialized differently in the data structures

starseeker (Feb 26 2022 at 18:33):

Or perhaps is uninitialized, which might explain why you're seeing it and I'm not - different random garbage can produce different results...

starseeker (Feb 26 2022 at 21:56):

@David Reeves OK, I was definitely too aggressive in my stb_truetype.h changes. I've committed an adjustment that will deal with the immediate functional issue for you.

starseeker (Feb 26 2022 at 21:57):

It's still an interesting question as to why quad and individual behaved differently, but a debugging session to ID what's different about the inputs to the font calls is probably the way to run that down.

starseeker (Feb 27 2022 at 02:41):

One thing I do notice - I don't get a crash, but if I bring up the model axes as you suggest the location of X changes from the lower left corner of the screen (1st drawing) to what I think is the proper position.

starseeker (Feb 27 2022 at 03:25):

@David Reeves So the bizarre values being fed to the text drawing routines for the initial passes (that are getting clamped by stb_truetype) are from dm-qtgl.cpp:342 - the glGetFloatv(GL_CURRENT_RASTER_POSITION, pos) call

starseeker (Feb 27 2022 at 03:26):

starseeker (Feb 27 2022 at 03:27):

Only on the third does it return something usable: {702.445312, 621.945312, 0.50012207, 1} in my case.

starseeker (Feb 27 2022 at 04:00):

@David Reeves Still not sure why the quad view triggers it, but looks like the odd text positioning behavior was a consequence of the glRasterPos being out of range in the first few draws - addressed by clamping the range.

starseeker (Feb 27 2022 at 04:08):

fwiw, I see the same behavior in the single view w/o quad widget involvement here. In no case so far have I seen a crash here, so it may be you're getting "lucky" in having something in the right memory location to wipe out w/ the quad mode + invalid behavior combo...

starseeker (Feb 27 2022 at 04:08):

David Reeves (Feb 27 2022 at 15:03):

@starseeker yes it appears to be working with the latest. Just to be clear my core dump was because I have debug compiled and I hit an assert which causes a core dump. I was not getting a core dump from a seg fault. The assert was because there was assert checking to make sure the delta x and y was greater than 0

I also could not figure out how what I had changed that would have triggered the functionality other than the axes display was close to the edge of the screen and in quad it went over the edge and triggered some functionality that caused the axes to be displayed differently than normal.

starseeker (Feb 27 2022 at 17:21):

No, it's in the right place now - I was seeing it in the wrong place in the first frame, which was a consequence of the attempt to draw text off screen not working correctly - stb_truetype was "correcting" the numbers, and that ended up with the labels in the lower left for me.

starseeker (Feb 27 2022 at 17:22):

It should be OK now - the only improvement would be to adjust the text drawing logic to support partial text drawing when the origin coordinates of the text label are offscreen, but part of the text would be visible coming in from the left. That would be ideal, but also a bit of a pain to get working so for me it's a lower priority.

starseeker (Feb 27 2022 at 19:07):

And of course staring at it the annoyance got to me, so I had to try and correct it... I think everything should now be behaving correctly.

starseeker (Feb 27 2022 at 19:11):

You can see the behavior in question if you drag the model axes to the left - previously you'd see the labels abruptly disappear as they reached the edge of the screen, now they should just be partially visible (as you would expect.)

David Reeves (Feb 27 2022 at 20:28):

Although I would like to position the view axis so that no mater how you rotate it does not go off screen. Are you ok if I make that adjustment?

David Reeves (Feb 27 2022 at 21:18):

Ok looking at util.c/bv_settings_init sets view axes.axes_os 0.85, -0.85, 0 then sets size to 0.2. That is why it will rotate off screen. I think I will adjust to 0.8, -0.8, 0. On my display I would be ok with adjust size to 0.15 but I think that will make it too small on other people's display

David Reeves (Feb 27 2022 at 21:25):

David Reeves (Feb 27 2022 at 21:37):

I will make the change in the fork and do a pull request with my next set of changes

starseeker (Feb 27 2022 at 21:40):

Hmm. I'll have to double check with @Sean on the commit permissions - still new enough to Github I'm not sure how that works

David Reeves (Feb 27 2022 at 21:41):

Not that big a deal having to work through forks just takes about 30 mins total to deal with and a little disruptive to the flow.

David Reeves (Feb 27 2022 at 21:44):

Now that I have already done it. I'm wondering if I have to delete the forked repository? I wonder if I can just commit to the fork then generate pull request whenever I'm ready for it to be merged into main?

David Reeves (Feb 27 2022 at 21:44):

if all i have to do is generate a pull request then may not even be 30 mins time

starseeker (Feb 27 2022 at 21:51):

On the (rare) occasions I've done pull requests, I make a branch in my repo to hold the commits related to the specific change, make the pull request from there, update my local copy once the PR is merged upstream, then make a new branch for the next request. Dunno if that's the "right" way or not...

starseeker (Feb 27 2022 at 21:51):

starseeker (Feb 27 2022 at 21:53):

David Reeves (Feb 28 2022 at 16:43):

pushed my changes to adjust defaults on the view settings. This will keep the view axes from rotating off screen

starseeker (Feb 28 2022 at 17:49):

Just FYA, it looks like your push undid a couple of changes in a prior commit. I typically do a "git pull --rebase" before doing a push to make sure I'm not overwriting any new commits.

David Reeves (Feb 28 2022 at 18:31):

starseeker (Feb 28 2022 at 19:34):

no problem - easy fix. So you're planning to dig into the primitive editing next?

David Reeves (Feb 28 2022 at 19:52):

Sean (Feb 28 2022 at 21:32):

You do now! We didn't automatically add everyone with commit access on Sourceforge like yourself that already earned commit rights. I probably should at least invite people where accounts exist.

Sean (Feb 28 2022 at 21:39):

@starseeker anyone that's in the dev group on sf should just be invited if they had access before
-- we don't presently have a use case for the restriction having outside collaborator introduces.

Sean (Feb 28 2022 at 21:40):

maybe someone with a professional temporary relationship, but even that would be a bit of a strange designation and all it does is prevent them from creating/seeing our teams, which is not a secret

starseeker (Feb 28 2022 at 22:09):

@Sean OK - I wasn't quite sure how all that interacted, but was trying to get @David Reeves up and running quickly. Hopefully I didn't make too much of a mess...

David Reeves (Mar 01 2022 at 03:12):

Thanks for the help. @starseeker are you having issues with your fb? I'm not seeing ert, maybe just a local issue but I don't think so. I think something has happened. Anyway let me know if you are seeing an issue in the mean time I will debug to see what is going on

starseeker (Mar 01 2022 at 04:15):

@David Reeves I just pushed a commit to have ert enable the fb if it's off - does that help?

David Reeves (Mar 01 2022 at 05:07):

starseeker (Mar 01 2022 at 14:10):

David Reeves (Mar 01 2022 at 19:03):

@starseeker so I took a quick look at mged. How do we want to approach this? Do we want to essentially copy functionality from mged to qged (libqtged)? Do we want to attempt to get this functionality in libged? I saw in your TODO that you didn't want to move edit functionality into libged, I'm sure I have missed some documentation somewhere but why? I'm just trying to catch up with what you have in mind I'm not attempting to push any particular approach. I'm fine with copying and editing into qged but want to make sure before I go that approach. Before it is done it will be several 1000 lines of code. Looking at edsol a lot of that will end up being needed in qged

Sean (Mar 01 2022 at 20:40):

I think it'd be awesome if libged had editing capability, but the interface for such a thing doesn't currently exist. That's why edsol and friends still live over in mged's folder -- they're kind of intertwined with a notion of an editing state, and libged is designed to be stateless.

Sean (Mar 01 2022 at 20:41):

same reason there's not a "sed" command or the "push" buttons interface (for programmatically clicking on the menu)

starseeker (Mar 01 2022 at 20:45):

@David Reeves So there are really multiple dimensions to primitive editing. There's Qt widgets for each primitive (similar to what archer does) paired with basic wireframe updates in the view as parameters are changed (where I was planning to start.) Then there's the in-scene menus of the faceplate editing. That's where some of our most sophisticated in-scene interactions take place (pipe editing, for example) but that code is also heavily tied to MGED's state. I was initially planning not to replicate the in-scene editing and instead make sure the combination of wireframe displays + Qt widgets could do everything we can currently do with the faceplate GUIs.

starseeker (Mar 01 2022 at 21:01):

My initial notion was to have the Qt widget create an rt_db_internal for the primitive in question (either a default primitive a.l.a. make if create a new one, or the current state of the existing specified object on disk if an existing solid's name is supplied) and then manipulate that internal with the editing operations, getting updated wireframes from the internal and using those to update a view object. Then, either when the editing has stopped for some period of time or the user explicitly requests a save, the rt_db_internal is written to disk.

starseeker (Mar 01 2022 at 21:03):

Especially for large primitives like bots we can't continually stream all incremental changes to disk as the mouse is dragged, but the wireframe will have to be continually adjusted as incremental parameter states are set - that was why I was working on adjusting the drawing logic to be able to create view objects .g object data that are independent of the on-disk object.

David Reeves (Mar 02 2022 at 04:20):

starseeker (Mar 02 2022 at 23:28):

@Erik If you're in the mood for a small OpenGL challenge, I had a heck of a time trying to get our standard librt raytracing output to properly display in a texture the way the ISST rendering does. All I could get was a pair of white triangles, despite making an attempt to follow what was done for ISST - consequently, the qtgl framebuffer implementation is still using the old school pixel method. I'm reasonably sure I was just doing something stupid, but I couldn't find it - feel like showing me up?

starseeker (Mar 02 2022 at 23:30):

It's not critical obviously in the sense that the current method does work, but I was hoping to get the texture based approach working for both adrt rendering and our normal fb output and then just make it a setting to switch between them.

David Reeves (Mar 07 2022 at 06:03):

@starseeker Just letting you know I'm still looking at the primitive stuff. It is alot to get my head wrapped around. I think I'm about to get there now. Hopefully I will have something prototype by the end of next week.

starseeker (Mar 07 2022 at 23:56):

@David Reeves No worries - I knew it would be a deep dive. If you're finding design challenges you want to discuss, feel free to bring them up.

David Reeves (Mar 08 2022 at 05:23):

Mainly right now I’m focused on getting something to work. Here are some things that I think are worth thinking about:

1) plugins should do all the work to connect themselves up to the application. For example there is code in main_window to connect signals and slots in the plugins. I realize this is probably a result of rapid prototyping but just something I noticed
2) I feel we need a layer of abstraction between components. For example the hierarchy and the other plugins should not directly connect. Signals from hierarchy should be connected to an abstract signal in the app. Interested plugins should connect their slots to the abstract signal.
3) I’m not a fan of the tabs for the primitive editing plugin unless there is multiple parts to the primitive. I don’t really feel like we should be editing multiple primitives at the same time.
4) thinking should add a filter field to the hierarchy component
5) need to be able to view from the hierarchy. Maybe use the eye icon everyone else is using. The plugins should give you multiple gui components. An editor for seeing details with a primitive but should be primitive specific toolbars, menubars, etc for that specific primitive. All that should come from the plug-in
6) long term would be good to have a undo history. Or even something like a revision history. Only for while editing

Anyway nothing huge For the most part I like the design pretty straightforward to understand. My struggle is more around libged, understanding what mged is doing, archer. Also have to understand the whole rt_db_internal stuff.I think I’m getting that now but working on the next step of implementing
something

Sean (Mar 08 2022 at 07:03):

The plan here is heavily sitting in a patch, but the original plan is that most if not all GUI operations end up going through the libged layer, and that layer would automatically handle event dispatch, transactions, and undo. It doesn't presently, but that was how it was envisioned.

So a GUI app would be able to tie an undo button to the libged undo/redo commands and the right things would happen. Someone did work on this just last year, but it's not yet integrated.

Sean (Mar 08 2022 at 07:07):

And I should caveat that those those are specific to "ged-using apps", just my opinion (others may vary), and that apps that go through the higher-level OO API in rt^3 (aka MOOSE) have different constructs to work with. Personally, I think MOOSE is the better architectural approach as it already encompasses in-memory editing of objects very well (much better than libged), and it has a hard boundary (it's strictly a C++ layer above the C libs, so there's no possibility for cheating and couplings like you noted). Alas, they're still separate codes solving related but different problems inefficiently..

Sean (Mar 08 2022 at 07:09):

On the other hand, replacing archer has a different set of challenges, and building modular widgets on top of libged should be reusable long term if they're not tightly coupled as you noted.

starseeker (Mar 08 2022 at 14:41):

Rapid prototyping and trying to figure out/remember on the fly what was possible and what makes sense - it's been a long time since my Qt training. I very much doubt what is there is what it should truly look like - my main focus was making sure that plugins could trigger view updates and view updates could trigger plugin updates without either knowing anything explicit about the other and without infinite loops. I'm quite sure there are other considerations beyond those, but unfortunately they've not gotten any attention yet.

That's one of those Qt questions I didn't/don't know the answer to - whether there are concerns stacking layers of signals and slots on top of each other. I suspect you're right and an "app bus" approach makes better sense, but I did have an initial wary reaction in that such an abstract approach might make it very difficult to sort out which specific signal is triggering a slot inappropriately while debugging. Whatever design we end up with, I think we're going to want a "beginning-to-end" example showing folks how to debug problems in the signal/slot connections.

Sorry, not following - do you mean the tool palette, or the editing panel below it? The tool palette was intended to allow a Gimp style selection between different primitives to allow users to easily create new objects of each type, and then to be automatically set to the correct button when they select a particular existing object to work on. In essence it would make the primitives graphically "discoverable" for users. I've not thought through the design on that in any detail though, so feel free to implement whatever makes sense.

Absolutely! The hierarchy widget also needs to be able to display attributes in columns and switch to a "flat" view (i.e. the ls command output) - I rather ran out of steam on it after (finally) getting it to respond to edits, but it will need at least one more round.

By "view from the hierarchy" do you mean adding or removing things from the scene, i.e. "draw" and "erase"? If so, definitely agree - the context menu and fixing the double-click behavior to draw and un-draw are also on the hierarchy to-do list.

@Sean already addressed this one, but even beyond editing undo I'd like to actually make the .g file what you might think of as a "git geometry archive" where you could check out earlier states of the geometry from the .g file itself. It's quite an interesting problem in many ways, but unfortunately it'll likely be a while before we can devote the necessary resources to designing and implementing that infrastructure.

rt_db_internal is basically the transition from "what we pulled off of disk" to "data we can work with in memory". I've not studied in detail what MGED and Archer do internally for their editing state management, so if you need assistance there let me know and I can do some digging. MGED's internal state is rather confusing and messy at times, so I'd suggest using it mostly as a guide on how to do specific individual operations and unpack/generate data - it does at least do many things in C. Archer tends to do most things in Tcl/Itcl, so the "translation to C/C++" problem is a bit more involved there.

starseeker (Mar 15 2022 at 10:03):

@David Reeves How are things looking? Need any help with the rt_db_internal concepts?

David Reeves (Mar 15 2022 at 14:52):

@starseeker It's going fine. Right now I'm good. I have been very distracted with a work project. I should be able to focus on this in the next couple of days. Thanks for asking.

David Reeves (Mar 16 2022 at 16:15):

Question: I'm reviewing all the code to get familiar with it. I'm wondering is it optional to use software graphics if it was compiled with opengl? It doesn't appear to be an option to select but seems to be code throughout to support it to be an option. Maybe the concept is there but for this pass it is being built to be determined at compile time but in the future you plan to make it optional?

David Reeves (Mar 16 2022 at 16:19):

Also what do you think about in the libqtcad if we get rid of the 'Q', 'Qt', 'Qg' prefixing and use namespace(s) instead?

Also I am seeing classes that is making attributes public. Do you have an issue if I refactor that stuff to be private and use inline accessor methods instead?

David Reeves (Mar 16 2022 at 16:24):

Are you ok if I rename CADQuad to be CADViewport now that we have modified it is always using that class as the central component vs either the QUAD or View.

David Reeves (Mar 16 2022 at 16:33):

On the software vs opengl I think unless we do a significant amount of restructuring it is not going to be something that is runtime selectable in the future. If that is the case do you mind if do a little refactoring to embrace the idea it is compile time selected. I think in places we can simplify the code. The more important issue is to get rid of the concept so we don't have to keep making these weird decisions about when to use the precompiler flags vs looking at type of graphics.

David Reeves (Mar 16 2022 at 16:35):

I'm going to get to the primitive stuff but I started looking around for the best place to inject it. In that process started noticing things that might make future growth easier and more consistent if we did a little clean up...

David Reeves (Mar 17 2022 at 07:09):

Hey I decided to create a branch to make the changes. If you don't agree with the changes we can always discard them.

David Reeves (Mar 17 2022 at 07:09):

starseeker (Mar 17 2022 at 10:42):

starseeker (Mar 17 2022 at 10:44):

Generally speaking I'm fine with refactoring and renaming - @Sean may have some thoughts, but I'm not strongly opinionated - what's there right now can usually be classed as "well, it had to be called something..." if I wrote it.

starseeker (Mar 17 2022 at 10:46):

@David Reeves I'd prefer to keep the runtime ability to use either software rasterizing or system opengl - there are usage scenarios where that ability is needed, and I did go to a lot of trouble to make sure we could do that.

starseeker (Mar 17 2022 at 10:53):

In fact, the swrast rendering is not only a user option but qged will also kick it in automatically if the system OpenGL fails to initialize at runtime.

David Reeves (Mar 17 2022 at 14:12):

Sean (Mar 18 2022 at 07:08):

@David Reeves I think your code cleanup ideas sound great to me. Definitely agree with scrubbing the technology branding. That typically makes for pretty suboptimal marketing, even when other devs are the audience (e.g., the sea of undifferentiated py* projects and rb*projects and *.js projects...). So if you're willing to put the thought into good naming, that should be a welcome improvement.

If the code for software rendering is spread all over the place, that would be an antipattern that might benefit from being abstracted/encapsulated better. The point of software rendering is that it just happens and application code is unaware, so if that's not presently the case, I'd think they're fair game to refactor. That said, as was mentioned, having a software rendering fallback is potentially a useful for a host of runtime environments where opengl isn't configured correctly, has a broken driver, isn't available outright, etc.

starseeker (Mar 18 2022 at 11:14):

Although I may not have properly succeeded, I attempted to keep the software rendering vs. system rendering hidden behind the QtCADView widget - the idea is to use that, and the specific details needed for system opengl and swrast are encapsulated in the QtGL and QtSW widgets, which the app shouldn't interact with directly.

David Reeves (Mar 19 2022 at 05:19):

I didn't mean to imply that it was all over. I just saw it as I was code reviewing. I was following a particular path through the code and it keep popping up. I was probably flipping back and forth in the same set of files. Besides the QtGL and QtSW classes I have not really seen it too much. I think it is only in 3 other classes CADView, main and main_window. Then mostly only in CADView. I think there probably is a way to abstract away from it. However, it is not that bad, my main issues is I did something silly and didn't realize it was a selectable attribute. Again I think you have done a fantastic job with what you have done so far. I think it is important to clean up now while the code base is still fairly manageable. The more it grows the more work it is to clean up. The code appears to be the result of a lot of prototyping. Which is normal early on. The work you did on integrating with DM and FB is probably something I would have struggled with. This integration is what has me excited to work on QGED. There still some integration challenges but you definitely have tackled the toughest one in my opinion. The rest I feel I can help on.

starseeker (Mar 22 2022 at 18:23):

@David Reeves One thing I could use some help on - I'm trying in event_filter.cpp to detect when my focus is on the display views, and then (and only then) trigger the N key binding to shoot nirt. Unfortunately I've not been able to successfully narrow the focus for that action - it either always triggers or never does (my function to detect if the active widget is a child of the widget of interest doesn't work - I suspect it may be because I'm not establishing proper parent/child relationships for the widget but am not sure.) Is this something you have experience with?

David Reeves (Mar 22 2022 at 20:16):

@starseeker when you get the focuswidget you need to use the main window. This method returns the last widget under that widget that had the focus. You are always checking from the c4 down instead of mainwindow down

static bool
widget_active(QWidget *w, QWidget *checkWidget)
{
bu_log("w: %p\n", (void *)w);
QWidget *fw = w->focusWidget();
bu_log("fw: %p\n", (void *)fw);
QWidget *cw = fw;
while (cw) {
if (cw == checkWidget) {
return true;
//return false; // Disable until parent/child relationships are fixed...
}
cw = (QWidget *)cw->parent();
bu_log("cw: %p\n", (void *)fw);
}
return false;
}

bool QGEDFilter::eventFilter(QObject *, QEvent *e)
{
CADApp *c = (CADApp *)qApp;
if (!c || !c->w)
return false;

// TODO - look into QShortcut, see if it might be a better way to manage this
if (e->type() == QEvent::KeyPress) {
// If we want to have key bindings that run GED commands, we will need
// application level information - the view widget doesn't know about
// the gedp.  To do this, we check if the central widget or one of its
// children has the focus, and check if the key event is one of our
// bound events.  If so, we may perform the bound action.
QKeyEvent *k = (QKeyEvent *)e;
if (k->modifiers().testFlag(Qt::ShiftModifier) == true && k->key() == 'N') {
    if (!widget_active(c->w, c->w->c4))
    return false;

David Reeves (Mar 22 2022 at 20:22):

@starseeker BTW you could have used application::focuswidget to return the widget with the current focus in the application

David Reeves (Mar 22 2022 at 20:24):

widget_active(QApplication *app, QWidget *checkWidget)
{
bu_log("w: %p\n", (void *)app);
QWidget *fw = app->focusWidget();
bu_log("fw: %p\n", (void *)fw);
QWidget *cw = fw;
while (cw) {
if (cw == checkWidget) {
return true;
//return false; // Disable until parent/child relationships are fixed...
}
cw = (QWidget *)cw->parent();
bu_log("cw: %p\n", (void *)fw);
}
return false;
}

starseeker (Mar 23 2022 at 02:53):

David Reeves (Mar 25 2022 at 18:05):

@starseeker Update on my refactoring. I'm still working on it. I decided to go a little deeper than just naming clean up. It will most likely be next week before I have something you can review

starseeker (Mar 26 2022 at 19:31):

@David Reeves No worries - I've got my head in another part of the display logic right now anyway, so it's a good time for what you're doing both tactically and strategically. The next big stab I take at qged will probably be to try and implement as much feature parity as possible with MGED/Archer, so we definitely want the foundation in place before all that extra code gets written/translated. There's probably still some backend work to be done moving things to libs (just to pick one example I know the fancy MGED pattern tool logic needs to move down at least to clone, and possibly deeper) but once editing support is in place it's going to be a matter of going through the GUIs, seeing what's missing, and making it happen :-)

starseeker (Apr 02 2022 at 22:17):

David Reeves (Apr 02 2022 at 22:27):

Progress is being made but I’m still in the middle part of the effort. I
was able to get some significant cycles today. But little slow last week.
Am I holding you up yet?

starseeker (Apr 03 2022 at 02:31):

@David Reeves nope, not yet - just checking to see how it was/is going. I'll probably be focused on display logic at least a couple more weeks, based on what I'm seeing so far.

starseeker (Apr 13 2022 at 02:29):

Very much prototype, but here's Level-of-Detail (LoD) in quad view, with each view showing a different level of zoom and detail. You can see the consequences of zooming out or in in the frames-per-second (FPS) meters in the lower left corners. lod_quad.png

David Reeves (Apr 13 2022 at 13:37):

I'm still at least a week or two from being done with what I'm working on. I finished what I was doing on the model stuff and I am working on the plugin stuff right now. Once I get that refactored I will have to update the existing plugins to follow the refactored approach. After that I'm going to refector the the whole GL/SW to use a base class so that we can get rid of all the #ifs. I pretty much think after that I'm done refactoring except I need to add all the standard comments at the end of files and document the classes and methods.

Question for you, I don't really understand what you are doing with what I think is, you are selecting multiple objects for editing? Is the concept that you can select multiple objects for editing then each object is highlighted in the tree and there is a button in the object editor dock?

starseeker (Apr 13 2022 at 19:57):

Awesome! Make sure with the plugins to test "both ways" - i.e., update the view from both the GUI and the command line and make sure the view info plugin gets the word, and make sure the view control plugin can update the scene without anything getting into signal loops. I had to add some debug printing early on to figure out when I was triggering signals incorrectly - presumably a better architected solution will help minimize those issues, but I'm still scarred from the early experiences so I'm paranoid ;-)

I've not hammered out the editing in substantial detail yet - are you referring to the highlighting? My concept is to select one primary instance for editing in the tree, with the highlighting indicating which other instances will also be impacted by the proposed edits. pinewood, for example, reuses the same objects in the hierarchy, so an edit to one instance of a solid in that hierarchy also has implications for the other instances. I wasn't planning to allow editing of multiple primitive solids or comb tree's simultaneously - just to visually indicate when that single object/hierarchy edit has non-local implications.

David Reeves (Apr 13 2022 at 22:40):

The highlights makes since. However, if the user has not drilled down then that path would not be highlighted? I hope the image comes through.. What I'm asking about is what is the function of the boxes I have underlined with the yellow line

starseeker (Apr 13 2022 at 23:42):

Ah, got it. The boxes are intended to select individual tools, a.l.a. the Gimp image editor. So in the case of the view mode, you could select a measurement tool that would put the mouse into a "click and drag" mode like Archer's that would measure distances in the scene. Another button would bring up controls for raytracing, similar to the raytrace control panel.

For the editors, my original thought for the object editing was that each primitive would have its own button and custom dialog. If an object is selected and the object edit panel is selected, the panel would then default to the button corresponding to the selected solid. If a different button is selected, or the highlighted selection is cleared, then the default would be to create a new object of the selected type.

The instance editing is more limited in scope, in that it would only be editing the properties applied to instances of objects in combs, and it may not make sense to have a button palette for that mode. That's the editing area I've given the least amount of thought to.

starseeker (Apr 13 2022 at 23:44):

The clone tool probably fits in there somewhere too - it would be really cool to be able to "preview" the results of clone commands before applying them. And there are surely others - longer term would like to make them all discoverable as "tools" to be selected from the palettes.

starseeker (Apr 13 2022 at 23:51):

There are other capabilities, sometimes exposed as "modes" in MGED, that we want to express in some fashion. The "pick" component is one example, where a mouse click shoots a ray into the view or otherwise checks for elements along that line and selects one or more of them. There's also nirt, the angle-distance cursor, and probably others I'm forgetting.

starseeker (Apr 21 2022 at 14:40):

@David Reeves did you have any thoughts on the GUI palette stuff? Is there a better way to go about that?

David Reeves (Apr 21 2022 at 15:23):

@starseeker Still working through this right now. However, my thinking is there are 2 types of plugins. One that provides core functionality. The other type is ones that provide more add on type of functionality. The core plugins are passed essentially a reference to the application that allows the plugin to add all types of components. The add on type of plugin works similar to your palette stuff but maybe slightly more prescriptive and restrictive. Prescriptive where you want the add on to go. Restrictive is instead of an open ended widget they specify using a property api that we provide from the platform. I'm working through what I think the component architecture should look like. I would like to provide a lot of flexibility but at the same time have a structure to how the components interact. If you have ever looked blender I like their whole editor approach to doing things. They have about 23 base editors that all the functionality is provided with. Then they have various layouts that the user can easily flip between depending on the primary function the user trying to perform. Anyway just trying to work through that design and how to connect the workspace/editors/tools/modes to be seamless and intuitive. Somewhat modeling after blender but more brlcad (CSG) functional. The idea is to get the concepts right from the start to allow easy extension of the platform. It is tough to balance between flexibility and complexity. Too flexible and it becomes to complex. However, a lack of the right amount of flexibility and it becomes too limiting. Anyway still baking on it I'm sure alot of the ideas I'm having right now I will just toss out in the interest of getting something done then later we can always do more refactoring to move the platform to more of what we are looking for.

David Reeves (Apr 21 2022 at 15:27):

@starseeker sorry long answer for a simple question. I'm still not sure about the core functionality coming from plugins. I'm concerned this will lead to alot of coupling between plugins.

David Reeves (Apr 21 2022 at 15:30):

starseeker (Apr 21 2022 at 18:27):

I've not looked at blender in detail (it's code is GPL, so that's a no-go, and I don't actually do much 3D modeling myself)

starseeker (Apr 21 2022 at 18:31):

My thinking, for what it's worth, was to implement as plugins so that if we do end up having to significantly rework the app architecture down the road, the plugins would (mostly) consist of self-contained widgets and signal connections that could be repurposed fairly easily to a new setup. I've pushed a fair number of things all the way down into libqtcad, and non-GUI functionality lower than that (for example, the polygon manipulation logic itself lives in low level C libraries now and the plugin's primary role is to define widgets and supply mouse events.)

David Reeves (Apr 21 2022 at 19:36):

I had no intention of even looking at the blender code just looking at from a design point of view. I like your approach my question is where is the line between platform and plug-in. If we are not careful we can create solution where one plugin needs to connect their slots to the signals of another plugin. Are we good with that? For example we could put the outline in a plugin

starseeker (Apr 21 2022 at 19:37):

Hmm. I think we definitely don't want plugins talking directly to other plugins.

starseeker (Apr 28 2022 at 23:57):

@David Reeves Oh, meant to ask - as you had mentioned wanting to work on how the interface layout is managed, should I dig in to the primitive editing?

David Reeves (Apr 29 2022 at 15:00):

starseeker (May 07 2022 at 00:43):

starseeker (May 24 2022 at 03:40):

starseeker (Jun 04 2022 at 03:24):

Specific instance drawing control from command line (and successful raytracing of partially drawn hierarchy). (For context, file behavior is first shown in MGED and Archer.) qged_instance_drawing_2022-06-03.mp4

starseeker (Jun 04 2022 at 03:31):

This one is a bit tricky, as the changes are invasive and will break MGED under certain circumstances.

starseeker (Jun 06 2022 at 14:43):

@David Reeves If you feel like hunting for a bug, I've got one - when I enable quad view, do an embedded raytrace, and then select a different quad view, I lose the raytraced image in the quad view that is no longer selected. Something specific to the framebuffer - the wireframe is OK.

starseeker (Jun 08 2022 at 01:45):

@David Reeves Possibly related - screengrab is grabbing the wrong image - it is getting part of the qged window??

David Reeves (Jun 08 2022 at 14:00):

starseeker (Jul 17 2022 at 14:31):

Sean (Sep 23 2022 at 15:28):

Sean (Sep 23 2022 at 15:33):

Overall, looking really good; the hierarchy and command line are fantastic. Did get some crashes and the fb seems to not be working quite right, but was able to navigate around easily enough for basic display.

Sean (Sep 23 2022 at 15:33):

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [31256]

VM Regions Near 0x8:
-->
    __TEXT                      105187000-1051fb000    [  464K] r-x/r-x SM=COW  /Users/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libged.20.0.1.dylib             0x0000000105589ff5 csg_wireframe_update(bv_scene_obj*, bview*, int) + 1125 (draw.cpp:140)
1   libdm.20.0.1.dylib              0x0000000105e47f84 draw_scene_obj + 100 (view.c:558)
2   libdm.20.0.1.dylib              0x0000000105e48018 draw_scene_obj + 248 (view.c:566)
3   libdm.20.0.1.dylib              0x0000000105e48018 draw_scene_obj + 248 (view.c:566)
4   libdm.20.0.1.dylib              0x0000000105e483c6 dm_draw_objs + 566 (view.c:749)
5   libqtcad.20.0.1.dylib           0x000000010539e767 QtGL::paintGL() + 791 (QtGL.cpp:156)
6   org.qt-project.QtOpenGLWidgets  0x0000000106a6635a QOpenGLWidgetPrivate::invokeUserPaint() + 234
7   org.qt-project.QtWidgets        0x000000010ac15491 QWidget::event(QEvent*) + 1999
8   org.qt-project.QtOpenGLWidgets  0x0000000106a6707e QOpenGLWidget::event(QEvent*) + 500
9   org.qt-project.QtWidgets        0x000000010abd7775 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 247
10  org.qt-project.QtWidgets        0x000000010abd8660 QApplication::notify(QObject*, QEvent*) + 532

Sean (Sep 23 2022 at 15:33):

starseeker (Sep 24 2022 at 00:49):

That looks like it might be related to the adaptive CSG wireframe drawing - that's in a funny state right now, I've got some work to do there

starseeker (Sep 24 2022 at 00:50):

starseeker (Sep 24 2022 at 00:52):

main may be a bit iffy behavior wise - I've been reengineering the drawing layer for scaling to large models in the draw_rework branch, so I've not checked the main behavior in a little while

starseeker (Sep 24 2022 at 00:54):

Once I'm done hammering on that I'll have to do another demo video, particularly for the selection bits

starseeker (Nov 16 2022 at 17:17):

@David Reeves were you still planning to take a look at the quad view issues above? I'll need to start digging into it fairly soon, but didn't want to duplicate effort if you're looking at it.

starseeker (Nov 16 2022 at 19:30):

Update - I think I have an inclining of what's going on, just not sure what to do about it yet. The mechanism being used to add an "active" border around the current quad window is also resizing the window, which triggers the resize callbacks. That in turn invalidates the old embedded framebuffer contents, since the fb size has changed along with the window size.

starseeker (Nov 16 2022 at 23:39):

OK, I think I may have found an approach - needs to be tested on more than just Linux to make sure it behaves

starseeker (Nov 17 2022 at 22:04):

Cute - looking into the screengrab problem, it is specific to the QtGL backend - the QtSW (software rasterizer) version works. The actual OpenGL version is pulling its image from the lower left corner of the app window. Probably means the whole window is being rendered with OpenGL and the naive glReadPixels is active for the whole Window, not just the QtGL widget.

starseeker (Nov 17 2022 at 22:53):

starseeker (Nov 17 2022 at 22:54):

@David Reeves if you get a chance, I'd be curious if you can test the draw_rework branch qged

David Reeves (Nov 21 2022 at 17:31):

I have been hammered for a while with my paying gig no relief in sight. Go
ahead if you need to

Stream: brlcad

Topic: Qt

Sean (Sep 14 2020 at 17:30):

Sean (Sep 14 2020 at 21:14):

starseeker (Sep 14 2020 at 22:01):

starseeker (Sep 14 2020 at 22:15):

Sean (Sep 15 2020 at 14:01):

Sean (Sep 15 2020 at 14:04):

Sean (Sep 15 2020 at 14:06):

Sean (Sep 15 2020 at 14:06):

starseeker (Sep 15 2020 at 14:48):

Sean (Sep 15 2020 at 14:49):

Sean (Sep 15 2020 at 14:51):

starseeker (Sep 15 2020 at 14:52):

Sean (Sep 15 2020 at 14:52):

starseeker (Sep 15 2020 at 14:52):

Sean (Sep 15 2020 at 14:52):

Sean (Sep 15 2020 at 14:53):

Sean (Sep 15 2020 at 14:53):

starseeker (Sep 15 2020 at 14:53):

Sean (Sep 15 2020 at 14:54):

Sean (Sep 15 2020 at 14:54):

starseeker (Sep 15 2020 at 14:55):

Sean (Sep 15 2020 at 14:55):

starseeker (Sep 15 2020 at 14:55):

Sean (Sep 15 2020 at 14:55):

Sean (Sep 15 2020 at 14:57):

Sean (Sep 15 2020 at 14:57):

starseeker (Sep 15 2020 at 14:58):

Sean (Sep 15 2020 at 14:58):

starseeker (Sep 15 2020 at 14:58):

Sean (Sep 15 2020 at 14:58):

starseeker (Sep 15 2020 at 14:59):

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:00):

Sean (Sep 15 2020 at 15:01):

starseeker (Sep 15 2020 at 15:11):

starseeker (Sep 15 2020 at 15:12):

starseeker (Sep 15 2020 at 15:37):

Sean (Sep 15 2020 at 17:31):

Sean (Sep 15 2020 at 17:32):

Sean (Sep 15 2020 at 17:32):

Sean (Sep 15 2020 at 17:33):

Sean (Sep 15 2020 at 17:39):

Sean (Sep 15 2020 at 17:41):

Sean (Sep 15 2020 at 17:42):

Sean (Sep 15 2020 at 17:42):

Sean (Sep 15 2020 at 17:43):

starseeker (Mar 17 2021 at 20:14):

Sean (Mar 18 2021 at 04:04):

starseeker (Mar 18 2021 at 12:15):

Sean (Mar 18 2021 at 19:15):

Sean (Mar 18 2021 at 19:19):

Sean (Mar 18 2021 at 19:20):

Sean (Mar 18 2021 at 19:24):

starseeker (Mar 18 2021 at 19:34):

starseeker (Mar 18 2021 at 19:35):

Sean (Mar 19 2021 at 02:56):

Sean (Mar 19 2021 at 03:00):

starseeker (Mar 28 2021 at 14:03):

Sean (Mar 29 2021 at 03:58):

starseeker (Mar 30 2021 at 15:53):

starseeker (Mar 31 2021 at 00:18):

Sean (Mar 31 2021 at 12:10):

starseeker (Mar 31 2021 at 15:48):

starseeker (Mar 31 2021 at 15:49):

starseeker (Apr 02 2021 at 01:17):

starseeker (Apr 02 2021 at 01:28):

Sumagna Das (Apr 02 2021 at 06:21):

starseeker (Apr 02 2021 at 12:29):

Sumagna Das (Apr 02 2021 at 12:59):

starseeker (Apr 03 2021 at 22:56):

Sumagna Das (Apr 04 2021 at 06:18):

starseeker (Apr 07 2021 at 16:17):

starseeker (Apr 07 2021 at 19:25):

Sumagna Das (Apr 07 2021 at 21:03):

Sumagna Das (Apr 07 2021 at 21:03):