I vote for this one also. Would make it easier to manage and use. I frequently maximise windows and this would make life easier.

Also it might provide and opertunity to make the interface a bit easier to modify.

Also it might provide and opertunity to make the interface a bit easier to modify.

It won't. For that matter the UI code will become more complex if/when this lands.

No! Haven't you heard of dual/multiple monitors?!

@ruevs No one is going to remove the two-window UI completely, if it's implemented it will just be an option. Like in GIMP.

These are the kind of pointless options that just cause boat.

If you don't see a need for it, that doesn't mean it's pointless. For example, SolveSpace is currently rather inconvenient to use with my window manager, i3, because, although it is tiling, there's no good way to tell it to lay out the graphics and text windows as they should be.

+1

Throwing my 2 cents in - worthless, I guess - I just installed and tried out SolveSpace last night, and I really like it. I went thru the first tutorial, and it was fairly intuitive and easy to use. I didn't find having two windows an issue, as I am a fan of that style (gimp, etc); in fact, I would love if the tool window inside the view was also separate.

But my main gripe - unless there's a way I haven't found (I was more interested in how to use the software than other things - so I only spent a very brief time looking for a solution) - was the fact that the tool icons and other text was so darn small on my 4k monitor. The menus and such were all fine, of course, because they are controlled by the system. But the icons, tooltips, etc - it's really tiny. Not impossible to use, but it would be nice if it could be changed.

I know that isn't a part of this particular issue - but I think it is something that should be considered for the future, if it hasn't already (I haven't explored the issue space for future changes or whatnot - maybe it already exists).

I just installed and tried out SolveSpace last night, and I really like it.

Which version? 2.x does not have HiDPI support, the master branch does, and should scale the icons appropriately for the rest.

@whitequark It was 2.x - installed from the Ubuntu 18.04 LTS repo; I'll have to look into compiling from source (and building an install package or something), then, I guess. Unless someone already has a .deb I can install from. Thanks for letting me know (and I'm looking forward to this new batch of updates).

Long story short - I don't like installs from source (ie, make, etc) because there isn't any record in the system to keep things from being messed up royally. My last system I did that and nursed things along for years and then I tried to update to a later rev and it all fell apart (fortunately, I was able to recover easily thanks to keeping my system and home on separate partitions and drives - and upgrade in the process).

So if I do compile from source (and don't create a package to install from), it's either got to run out of the directory its compiled in, or I have to come up with some other system to keep it well isolated (vm, container, or some other method).

@andrew-ayers You can run it from the build directory directly, without installing anything.

Unless someone already has a .deb I can install from.

@andrew-ayers You could install latest nightly build of SolveSpace 3.x from third-party PPA for Debian/Ubuntu Linux:

• https://notesalexp.org
• https://launchpad.net/~alex-p (notesalexp.org mirror)

Or just directly download latest DEB (solvespace_3.0.0~git*-2_amd64.deb) for Ubuntu 18.04 LTS

• https://notesalexp.org/packages/en/bionic/amd64/solvespace/download.html

@whitequark @Symbian9 Well - thank you both for this info - right now I'm compiling on my Ubuntu 18.04 LTS from the git repo - so we'll see how that goes; though I might still try one of those mentioned debs...thanks again!

@whitequark Ok - got 3.0 compiled and running, looks nice - but no larger icons? Is there a special flag I need to pass to switch to HiDPI mode, or some other setting somewhere? Thank you...

No, it uses your system settings, like any other GTK application.

@whitequark I found the setting (Gdk/WindowScalingFactor) but setting it from "1" to "2" to affect the whole screen wasn't ideal.

According to this page, though:

https://wiki.gnome.org/HowDoI/HiDpi

...you can pass the setting to a single app - which worked great:

$ export GDK_SCALE=2;./bin/solvespace &

Perfect. Thank you!

@whitequark @Symbian9 I am possibly interested in trying to implement this as a precursor to a more grandiose idea of building an iPad GUI for solvespace. I looked at the emscripten branch for ideas as its UI is more or less what we want here, but it looked to me like maybe that was wired up in an undesirable way by just happening to map new windows into the right DOM elements by name rather than by creating some higher-level notion of layout that knows if the property browser is embedded or not.

On a possibly related note it may be desirable to remove the notion of scrollbars as a thing from solvespace.

To my mind the logical abstraction is to treat what are currently OS level windows as a new thing (call it a 'viewport') which is embedded in an OS level container (a 'window') that knows how to pan the viewport if allowed (scrolling) or resize it if not. Then the top level window can be given two viewports one for the main display and one for the property browser and lay them out and control them appropriately.

If that sounds reasonable, the next logical step would be to put the toolbar in its own viewport, and then call it 'done' for this issue.

If that sounds vaguely desirable I'd appreciate any further pointers on where to start. I haven't found any tests for solvespace and I don't plan to compile on more than one or two platforms at best.

I am possibly interested in trying to implement this as a precursor to a more grandiose idea of building an iPad GUI for solvespace.

Great!

To my mind the logical abstraction is to treat what are currently OS level windows as a new thing (call it a 'viewport') which is embedded in an OS level container (a 'window') that knows how to pan the viewport if allowed (scrolling) or resize it if not. Then the top level window can be given two viewports one for the main display and one for the property browser and lay them out and control them appropriately.

@anicolao, You just read my minds! In last few day I already think about possible ways to implement "single window mode" and there are few ways:

1. Draw "Property Browser" directly in main window as on-screen tabs (similar to how "Toolbar" actually works)
2. Add "Property Browser" it as sub-window (call it frame/dock widget or viewport)
   2.1 As sub task, add something like command line at the bottom behind main window & "Property Browser" (lets separate text input from OpenGL to native text input field)

So, I fully agree on "2" (sub-window) idea!

@anicolao Another interesting possibility is VR. Imagine the text window as some kind of window in a virtual world, but the model view is not in any window at all - you're sketching and manipulating in the same space the user is walking around in ;-) Just throwing this out there as a possible use-case as you consider changing the structure of the different things being shown.

https://github.com/solvespace/solvespace/tree/single-window

+1 Here.
It's a pain to use with tiling window manager (in my case, qtile).

I'm also looking for ability to dock Property browser inside main window. For one instance of Solvespace it is OK, but as soon as I need open another instance for reference, eg. when I'm working on multiple connected parts, it is quickly become mess. Switching of main window does not switch the corresponding Property browser as well.

I was trying to rebase https://github.com/solvespace/solvespace/tree/single-window over master.
Assuming that it worked in the first place, I did most of the rebasing but then there are a few parts where I'd actually need to understand the code. -_-