Users need a full screen mode to maximize screen real estate in Dopus by eliminating the title bar (optionally and of course with a persistent setting that remembers and restores the preference on opening opus).
Here is a video with the 2019 Visual Studio IDE interface improvements. Full screen is the default, no empty windows 95 Title Bar.
Visual Studio 2019 removed useless chrome.
Greetings Gurus, may we please get a full screen option, title bars are obsolete these days, it's not windows 95 anymore...Make it optional for those who may want the option.
Titlebars are not obsolete. People use them to move windows around, including maximized windows.
That why I suggested it be implemented as an option, some users may use it, others won't.
I wouldn't mind an internal DOPUS toggle command to hide the title bar although I would vastly prefer an option to simply have tabs and the title bar merged, much like Chrome or firefox does it. At least with that, a majority of people could use it.
The problem with that concept in Opus is that the model doesn't really work. The tabs in Opus are attached to the file display, not the whole window, and there can be two file displays with separate tabs in each window.
If I may give a real-world example of the potential awkwardness of implementing this. In Chrome, when we go full screen (with F11), you are only viewing the current tab and the tabs are no longer visible. While you can still switch with CTRL-PageUp and CTRL-PageDown, you can't see the tabs themselves.
Firefox handles it a little differently in that they auto-hide the tab bar (along with the address bar).
I think trying to do a true full screen would be very challenging to handle in terms of the user interface.
For full screen, I would want to numb my auto-hide windows taskbar at the bottom, when using DO.
My lister status bar is down at the bottom and some other objects. So accidently opening the taskbar because the mouse cursor is moving in that area is the worst.
Play with AutoHotkey script.
#Requires AutoHotkey v2.0
F3::WinSetStyle "^0xC00000", "A" ; Toggle the active window's title bar
#HotIf winActive("ahk_class dopus.lister")
F4::
{
static toggle := false
toggle := !toggle
static w := 0
if (!w) {
winGetPos &x, &y, &w, &h, "A"
static x, y, w, h
}
toggle ? winMove(-8, 0, A_ScreenWidth+15, A_ScreenHeight+8, "A") && winMoveTop("A") : winMove(x, y, w, h, "A") ; Full screen or window mode
WinSetAlwaysOnTop -1, "A" ; Toggles the always-on-top status of the active window
}
#HotIf
2 Likes
Oh, I just realized that since I have Microsoft PowerToys, I can just always on-top DO while it's running.
But then I would have to toggle that when switching windows. That would be more work than it's worth. Ok, I will bookmark this thread for later. Struggling with basic things for now, thank you.
It is not necessary to keep the window on top. You can comment out this line.
;WinSetAlwaysOnTop -1, "A" ; Toggles the always-on-top status of the active window
Press F3 and then F4 to make the window full screen. If there is a title bar, you need to keep the window on top.
1 Like
If you make the lister on-top, other windows are going to end up opening behind it, making the program unusable unless they are also made on-top. I would not recommend it, outside of brief moments where you really need Opus and another program overlapping with Opus visible while the other program is active, and then turning it off again.
1 Like
Ok, always on top is a no go. I do use it for having winamp or whatever over fullscreen programs though.
I'm making some progress on this numbing the taskbar.
Trying out this Download Taskbar Hide 3.1.1 for Windows - Filehippo.com
Using iCue I can put a hotkey I never use on my left windows key. And customize the "taskbar hide" hotkeys. So now F24 toggles the windows taskbar between the vanilla auto-hide and disabled.
On my right windows key I put a macro sequence that sends the (F24) toggle, then (windows key + U) which shows the taskbar and focuses the tray arrow (dragged all icons onto the taskbar so there is no tray), then moves the mouse cursor over the first icon (to cancel the tooltip and selection), 10ms delay, them moves the mouse cursor over a blank spot on the taskbar.
So effectively now my left windows key is toggle on/off the taskbar, and my right windows key is show taskbar - no start menu.
The catch is now my windows + number keys shortcuts don't work when the taskbar is disabled. *Sigh. Of course they don't. I tested a macro sequence: F24, (Windows + 1), F24. It works, but I really don't like doing that to the taskbar over and over again, habitually.
A side note:
The windows + numbers hotkeys break when a program has more than one instance (process?)
It should just focus the most recent window, but ok.
So I am still working on this. I won't be attempting the AutoHotkey learning curve right now.
I got this Opus to tackle first.
I've enjoyed reading this thread. When I full screen DO, it appears to me that the title bar is very short, something like a nine point font. It is short to the point that eliminating it adds no significant, to me, space for effective use in DO. YMMV.
1 Like
+1 on an option to hide titlebar please.
Try this AutoHotkey script.
Automatically switch the taskbar and title bar via windows switching event.
#Requires AutoHotkey v2.0
Persistent
#Warn
#SingleInstance
WinShowHook(true)
F3::WinSetStyle "^0xC00000", "A" ; Toggle the active window's title bar
#HotIf winActive("ahk_class dopus.lister")
F4::
{
static toggle := false
toggle := !toggle
static w := 0
if (!w) {
winGetPos &x, &y, &w, &h, "A"
static x, y, w, h
}
if toggle ; Full screen or window mode
winMove(-8, 0, A_ScreenWidth+15, A_ScreenHeight+8, "A"), winHide("ahk_class Shell_TrayWnd")
else
winMove(x, y, w, h, "A"), winShow("ahk_class Shell_TrayWnd")
global hideTask := toggle
}
#HotIf
MyFunc(hwnd) {
if !hwnd
return
global hideTask
try { ; Hide the taskbar when DOpus is full screen, even if the title bar is shown.
if (winGetClass(hwnd) = "dopus.lister") {
WinSetStyle "-0xC00000", hwnd ; Hide the title bar of the active DOpus window
winGetPos ,, &w, &h, hwnd
if (w > A_ScreenWidth && h > A_ScreenHeight) {
winHide("ahk_class Shell_TrayWnd")
hideTask := 1
}
} else if hideTask
winShow("ahk_class Shell_TrayWnd")
}
}
HookProcedure(hWinEventHook, Event, hwnd, idObject, idChild, dwEventThread, dwmsEventTime) {
if Event = 3
SetTimer(MyFunc.Bind(hwnd), -10)
}
WinShowHook(doHook) {
static CBA := CallbackCreate(HookProcedure)
static hHook := 0
static EVENT_OBJECT_SHOW := 0x8002
if (doHook && hHook = 0) {
hHook := DllCall("SetWinEventHook", "UInt", 0x3, "UInt", 0x3, "Ptr", 0, "Ptr", CBA, "UInt", 0, "UInt", 0, "UInt", 0)
} else if (not doHook && hHook != 0) {
DllCall("UnhookWinEvent", "Ptr", hHook)
hHook := 0
}
}
There are some ways to make a window without title bar movable.
1 Like
Displaying the menu and/or commands is a trend in modern software.
This could be a good idea to merge the title bar with (one of) the tool bar(s). Maybe this is already possible; I discovered DO two weeks ago (I still cannot believe I missed this awesome software for so many years).
VS Code:
Affinity software family:
JetBrains software family:
Docker Desktop:
Visual Studio:
Microsoft Teams:
Microsoft Word:
A trend I personally dislike. It makes me hunt for the (sometimes tiny sliver of) space that lets me move the window, and requires thinking about how to move each individual application's window, as they're all different.
Even worse, many of them add/remove items up there as projects load in the background, so controls can dive under your mouse pointer just as you click to move the window after it opens.
(It also often coincides with another modern UI sin: Window frames that have little to no indication of active/inactive state, even when Windows is configured to use distinct colors for the two states, which they often ignore.)
Which is not to say we are completely against putting controls in the titlebar. We've done it for the Customize and Preferences buttons when they are open to edit toolbars or settings, and the window is wide enough to still allow plenty of space for moving it. But we're pretty conservative about when and how that space is used.
2 Likes
I couldn’t agree more that, sometimes, it is a little bit tricky to find that handle to move the window. I’m looking at you two, Firefox and Edge.
Maybe not making it as the default, but giving the possibility to move (one of) the toolbar(s) up there.
Anyway, thanks for your feedback (and this great piece of a software!)