3 ms·

The zooming reminds me of Prezi, except that Prezi is in 3D... (maybe Oberon is where they got their original idea from?). As interesting as it sounds and look

by haspok 4y ago

The zooming reminds me of Prezi, except that Prezi is in 3D... (maybe Oberon is where they got their original idea from?). As interesting as it sounds and looks, I cannot imagine constantly zooming in and out (or panning) just to switch windows. Maybe I am so indoctrinated with the standard Windows task switcher concept that I don't want it to work in any other way. I was also completely lost when I tried to create a Prezi presentation instead of Powerpoint. On the other hand it is great to see something different in the UI world. I remember only one such other concept that didn't make it into mainstream: the UI where you just move the mouse, but don't need to click...

galaxyLogic 4y ago
Instead of zooming I think a better approach is Windows-within-Windows. Or is that the same thing? You don't need to "zoom" so much as "enter" into a sub-desktop. Which is different than multiple desktops side-by-side. Smalltalk had/has this feature. You create a new "project-window". You can then "enter" it and within it you can open any number of windows including project-windows. This works really well with programming where you are performing a task which requires a set of windows to be open, a class-browser, method-browser, change-list-window, debugger etc. As you are programming you soon discover you will need to do something else "first", perhaps fix a bug. You open a new project-window and "enter into it" to do that. Your current context of whatever you were doing remains as is in the parent window. Perhaps you leave an open debugger there halted at a given stack-frame, so you can continue that debugging later. Maybe even tomorrow. When your bug is fixed you close its sub-project-window and come back up to what you were doing before. If you can't fix the bug immediately you can leave its project window in place but exit into the parent-project and do something else there while keeping the bug-fix project open, and visible as a window-icon in its parent project-window. The same approach could be adopted by the whole OS, and in a sense Smalltalk is an OS. So I'm waiting for MS or Linux or Mac come up with something similar. Not "multiple desktops" but "nested desktops". Or is there something like that already (outside of Smalltalk)?
- 4bpp 4y ago
  Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm https://documentation.help/Win32/MDI%20Frames.htm) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the anti-MDI Bildersturm since its inception, and Qt's implementation (https://doc.qt.io/qt-6/qmdiarea.html https://doc.qt.io/qt-6/qmdiarea.html) already suffered from bit rot when I checked it out some 10 years ago.
  - galaxyLogic 4y ago
    I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself? But Smalltalk "project windows" was and is truly simple. I think you can still check them out in Pharo and/or Squeak. They are not of much use to casual computer user I think. Their benefit comes when the computer is used to perform complex multi-level tasks like producing software.
    - 4bpp 4y ago
      > I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself? It's true that MDI generally existed at a different level of abstraction (the "toolkit" that draws widgets rather than the "windowing system" that assigns screen regions to applications and lets them draw to those regions, while giving the user control over which application gives what region), but in contexts where the OS also provided a canonical platform GUI toolkit (such as Windows, see the documentation I linked above), the MDI implementation would naturally also come from the same vendor. I'm aware that a common argument of the anti-MDI push was in fact that the OS window manager should be able to handle management of (sub)windows better and more natively than an application vendor's own low-resource proprietary implementation in the context of subwindows, but this superiority of platform window management never actually materialised and in 2022 I'm still occasionally finding myself trying to chase down all the different subwindows of multi-window applications that wound up on separate workspaces. Pre-single-window GIMP was a particularly egregious offender in this regard.

by haspok 4y ago

galaxyLogic 4y ago

Instead of zooming I think a better approach is Windows-within-Windows. Or is that the same thing? You don't need to "zoom" so much as "enter" into a sub-desktop. Which is different than multiple desktops side-by-side. Smalltalk had/has this feature. You create a new "project-window". You can then "enter" it and within it you can open any number of windows including project-windows. This works really well with programming where you are performing a task which requires a set of windows to be open, a class-browser, method-browser, change-list-window, debugger etc. As you are programming you soon discover you will need to do something else "first", perhaps fix a bug. You open a new project-window and "enter into it" to do that. Your current context of whatever you were doing remains as is in the parent window. Perhaps you leave an open debugger there halted at a given stack-frame, so you can continue that debugging later. Maybe even tomorrow. When your bug is fixed you close its sub-project-window and come back up to what you were doing before. If you can't fix the bug immediately you can leave its project window in place but exit into the parent-project and do something else there while keeping the bug-fix project open, and visible as a window-icon in its parent project-window. The same approach could be adopted by the whole OS, and in a sense Smalltalk is an OS. So I'm waiting for MS or Linux or Mac come up with something similar. Not "multiple desktops" but "nested desktops". Or is there something like that already (outside of Smalltalk)?

4bpp 4y ago
Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm https://documentation.help/Win32/MDI%20Frames.htm) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the anti-MDI Bildersturm since its inception, and Qt's implementation (https://doc.qt.io/qt-6/qmdiarea.html https://doc.qt.io/qt-6/qmdiarea.html) already suffered from bit rot when I checked it out some 10 years ago.
- galaxyLogic 4y ago
  I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself? But Smalltalk "project windows" was and is truly simple. I think you can still check them out in Pharo and/or Squeak. They are not of much use to casual computer user I think. Their benefit comes when the computer is used to perform complex multi-level tasks like producing software.
  - 4bpp 4y ago
    > I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself? It's true that MDI generally existed at a different level of abstraction (the "toolkit" that draws widgets rather than the "windowing system" that assigns screen regions to applications and lets them draw to those regions, while giving the user control over which application gives what region), but in contexts where the OS also provided a canonical platform GUI toolkit (such as Windows, see the documentation I linked above), the MDI implementation would naturally also come from the same vendor. I'm aware that a common argument of the anti-MDI push was in fact that the OS window manager should be able to handle management of (sub)windows better and more natively than an application vendor's own low-resource proprietary implementation in the context of subwindows, but this superiority of platform window management never actually materialised and in 2022 I'm still occasionally finding myself trying to chase down all the different subwindows of multi-window applications that wound up on separate workspaces. Pre-single-window GIMP was a particularly egregious offender in this regard.