next »

[oahda]

One thing about the dangers of injection, tho... My program isn't going to have admin rights, so why go through the hassle of injecting into my program what they could just open up a terminal to type in manually? Is there something I'm missing?

[BorisTheBrave]

Is there something I'm missing?

Yes, the problem is that it becomes very easy for your code to see some data (i.e. a level file) and interprets part of that data as code (i.e. a shell script). If you ever have untrusted data (e.g. you downloaded a level from the internet), then now you have run untrusted code, which is far worse.

Of course, for a dev tool who cares, but if you were to let users design their own levels, that would be a problem as they would almost certainly want to share levels without granting the original level designer control over their computer.

Like jwki says, there are safer ways to do the same thing. Both fork/exec and CreateProcess *only* run the specified executable, they don't create a shell. Thus there's no chance that data will be interpreted as a shell script (they're also more efficient). The invoked program has to handle the data correctly, but that is always true. And system/popen can be used safely, it's just an easy foot-gun.

Again, this is all very hypothetical. I don't think it's a problem for your use case, but it does make it a bad library.

[oahda]

Thanks for clarifying.

So this seems to be the standard way on Mac:
https://developer.apple.com/reference/foundation/nstask

Or am I out on a limb?

Just to clarify: these command line tools are completely separate from any game and even the editor (and the code is not going into the engine, but is isolated to these tools) so that they can be used in isolation if necessary as well. The editor will run them, but the game will have nothing to do with them.

[JWki]

Yeah looks like that's about what CreateProcess is on windows.

[oahda]

This seems to be a cross-platform option:
http://www.highscore.de/boost/process/

Does it seem fine?

EDIT:
Apparently it's implemented in a POSIX fashion and does not use any Mac libraries for Mac, so maybe it's just using the functions you advised against in the background? Can't get it working on Mac anyway. Posted on this existing issue: https://github.com/klemens-morgenstern/boost-process/issues/16#issuecomment-291015854

EDIT 2:
Got it working with NSTask for now anyhow. Still got some use out of boost::process anyway because I needed the full path to the command line program I wanted to run, and there was a function for that in the lib that actually worked.

EDIT 3:
So, as the author pointed out to me on the issue, I was using an ancient version of boost::process somehow... Got the latest from the repo and now it's working perfectly.

[BorisTheBrave]

Basically, any api that takes the path to the executable and the arguments separately is probably fine, and anything that takes them together as a space separated string is probably asking for trouble.

[oahda]

Author anyway now confirms that the library uses "[p]ure posix, just a few workarounds for OSX".

[oahda]

Really considering Qt for the editor now. Docks. Code editor (not built in, but I easily added the web based Ace in a web view). Won't be having any Unicode issues. Cross-platform. I think I'm sold.

[InfiniteStateMachine]

Neat

I should check out Qt again.

I might make a more formal thread for discussion about this some day but I constantly think about the tradeoffs between using a higher level framework and language for tools then a translation mashalling layer vs using a C++ based gui toolkit and taking the hit on the decreased productivity when making the UI.

edit : sorry I forgot the mention, the tradeoff for using a higher level language/framework is maintaining the translation/marshalling layer.

[oahda]

Yeah, I considered that too. Decided to give it a go to see how I felt about it.

So far, I'm being much more productive with Qt than I was with SDL/ImGui tho, and it's nice and easy to use, and updated for modern C++ these days so that I can hook lambdas to events and so on! e: Decided to just use Qt Creator too (but I'm not doing anything visually—not my style; all code), so I got up and running with everything set up for me right away. Really nice.



Nothing's stopping me from slapping a couple of ImGui widgets into the game view as well if I want to, I guess!

I do have to say that the docking implementation is a bit weird, but I'm OK with it. Someone else might not be. The title bar is always there even if the dock is tabbed, and the dock can only be pulled by the title bar and not the tab (which is why it suddenly makes sense that the tabs are at the bottom and not at the top by default). Other than that, it's great. Docks can move around, tab and detach into separate windows. However, this implementation also has the unique option of making all views in a tab group detach together if dragged by the title, so they were definitely consciously choosing this way of doing things as that wouldn't have made sense with the usual approach to docks.

Decided that I want a single window approach for my editor tho, so while I allow docks to be moved around, I don't allow for them to detach. And then I added another tab bar at the top of the whole dockspace so that multiple workspaces for different things can be used.

Also worth noting is that tabs looked bad (non-native/deprecated) in Mac until an update just a month ago that was pushed into 5.9 which is currently the most recent version available through the installer (in beta) so if you want that fixed you need to go for the 5.9 beta when you install (I went for the stable 5.8 first). xp

[surt]

I do have to say that the docking implementation is a bit weird, but I'm OK with it. Someone else might not be. The title bar is always there even if the dock is tabbed, and the dock can only be pulled by the title bar and not the tab (which is why it suddenly makes sense that the tabs are at the bottom and not at the top by default). Other than that, it's great. Docks can move around, tab and detach into separate windows. However, this implementation also has the unique option of making all views in a tab group detach together if dragged by the title, so they were definitely consciously choosing this way of doing things as that wouldn't have made sense with the usual approach to docks.

ToolWindowManager provides a pretty nice alternative dock system for Qt.

[JWki]

Single window tools enfuriate me. Any specific reasons why you'd want that? Hate it when I can't distribute a tool across my multi monitor setup.

[oahda]

Single window tools enfuriate me. Any specific reasons why you'd want that? Hate it when I can't distribute a tool across my multi monitor setup.

Opposite reason, I guess; separate windows annoy me. It was a blessing once GIMP finally added its single window mode, and I haven't looked back since. I never ever detach docks in Unity even tho I can, either. I prefer tabs.

(and I do use multiple monitors)

Will take a look at surt's suggestion tho. Maybe I'll change my mind!

(but of course I understand why some people like it)

[oahda]

Well, I tried surt's suggestion and it's neat! Not too fond of the way the resize bars look, at least when there is no view in the widget, but it's not too bad when there is! c:



It plays nicely with detached windows too, so might as well keep the functionality in there now and just not use it myself. c;

[ferreiradaselva]

Peeps, did anybody here ever used that "Pipelines" feature of Bitbucket??? (https://blog.bitbucket.org/2016/11/14/game-development-bitbucket/)

It looks like I can build on other platforms. If that is what it is, then AWESOME! I use Linux, and I can cross-compile for Windows, but compile for Mac is impossible. Boi, if that is what it is,

[oahda]

Ooh, that's nice if it's the case. Tell us if you figure out more!

[cherry_monster]

Single window tools enfuriate me. Any specific reasons why you'd want that? Hate it when I can't distribute a tool across my multi monitor setup.

Opposite reason, I guess; separate windows annoy me. It was a blessing once GIMP finally added its single window mode, and I haven't looked back since. I never ever detach docks in Unity even tho I can, either. I prefer tabs.

(and I do use multiple monitors)

Will take a look at surt's suggestion tho. Maybe I'll change my mind!

(but of course I understand why some people like it)

I feel the same way! Gimp's separate panes were just a way for me to lose the thing I was trying to find.

[ferreiradaselva]

Single window tools enfuriate me. Any specific reasons why you'd want that? Hate it when I can't distribute a tool across my multi monitor setup.

Opposite reason, I guess; separate windows annoy me. It was a blessing once GIMP finally added its single window mode, and I haven't looked back since. I never ever detach docks in Unity even tho I can, either. I prefer tabs.

(and I do use multiple monitors)

Will take a look at surt's suggestion tho. Maybe I'll change my mind!

(but of course I understand why some people like it)

I feel the same way! Gimp's separate panes were just a way for me to lose the thing I was trying to find.

I agree with all that. With very rare exceptions I would think separate window is good.

[InfiniteStateMachine]

I wouldnt mind multi-window tools if alt-tab brought all an applications windows to the front. Rarely do I ever just want one window to come in focus.

As for me it depends on the program. Visual studio, maya and the unreal engine I can't imagine using without multiple windows.

A light text editor on the other hand. I prefer a single window with maybe some splitting hotkeys.

[oahda]

While I have had, and do have, multiple monitor setups both at home and at the office, most of the time I prefer just to go over to some comfier place with a laptop and its single monitor and then use virtual desktops instead, so maybe it has to do with that for me. That way I can still organise stuff. So that's kind of the idea with my workspace tabs.