Re: How do I get lost windows back?
On Sunday March 03 2024 12:52:33 hw wrote: > Modernity is totally besides the >point here. Sadly no, in my book. But I'm not going to get into a shouting match about this.
Re: How do I get lost windows back?
On Sat, 2024-03-02 at 22:43 +0100, René J.V. Bertin wrote: > On Saturday March 02 2024 17:11:48 hw wrote: > > > This is bad interface design. I guess whoever designed it knew what > > they wanted and it escaped them that someone who doesn't know what > > they were trying to accomplish is only being confused by this. > > Oh, you mean *modern* interface design? I wish that were a joke btw... No, I mean bad interface design. Modernity is totally besides the point here. Why is it that people always try to make it so as if I had said something I didn't say or as if I meant something I didn't mean? Even signing my messages doesn't help. signature.asc Description: This is a digitally signed message part
Re: How do I get lost windows back?
On Saturday March 02 2024 17:11:48 hw wrote: >This is bad interface design. I guess whoever designed it knew what >they wanted and it escaped them that someone who doesn't know what >they were trying to accomplish is only being confused by this. Oh, you mean *modern* interface design? I wish that were a joke btw...
Re: How do I get lost windows back?
No. You can easily drag windows to the top left or right edge. The labeling is confusing. Above it, you have a graphic with the top left corner marked by default which makes it even more confusing. If there are multiple different things involved, they either shouldn't be shown together, or it should be made clear that they are different things. If they are somehow related to each other, it needs to be shown/explained in which way they are related. This is bad interface design. I guess whoever designed it knew what they wanted and it escaped them that someone who doesn't know what they were trying to accomplish is only being confused by this. On Sat, 2024-03-02 at 06:37 +, Duncan wrote: > hw posted on Wed, 21 Feb 2024 14:20:58 +0100 as excerpted: > > > > I believe you're misunderstanding the configuration. It does make > > > sense, > > > and here's how: > > > > Ok that's a really long explanation, and it's not what I'm talking > > about. I hope I can attach a screenshot. > > > > What I'm talking about is having both the checkboxes enabled for > > Maximize and Tile at the same time. Both of them are for when dragging > > windows. That doesn't make sense: The windows that are being dragged > > can only be maximized or tiled, not both at the same time. > > They are both for dragging windows, yes, but one is for dragging to top, > while the other is for dragging to side, and while a window can't be both > maximized and tiled at the same time, you can't drag it to both the top > and the side at the same time either (at least not without dragging to a > corner, which would again be different than dragging to top or side), so > it makes sense because both the triggers and the triggered actions are > different. > > Further, some people might want to have the flexibility of having both > actions available so they can choose which action they trigger by which > edge they drag too, while others might only need one or the other and they > can disable the one they won't use as unneeded, and still others might use > neither and they can disable both, so it makes sense to have each as a > separate checkbox so people can control them separately, which is exactly > the situation we see and exactly how they are labeled. > signature.asc Description: This is a digitally signed message part
Re: How do I get lost windows back?
hw posted on Wed, 21 Feb 2024 14:20:58 +0100 as excerpted: >> I believe you're misunderstanding the configuration. It does make >> sense, >> and here's how: > > Ok that's a really long explanation, and it's not what I'm talking > about. I hope I can attach a screenshot. > > What I'm talking about is having both the checkboxes enabled for > Maximize and Tile at the same time. Both of them are for when dragging > windows. That doesn't make sense: The windows that are being dragged > can only be maximized or tiled, not both at the same time. They are both for dragging windows, yes, but one is for dragging to top, while the other is for dragging to side, and while a window can't be both maximized and tiled at the same time, you can't drag it to both the top and the side at the same time either (at least not without dragging to a corner, which would again be different than dragging to top or side), so it makes sense because both the triggers and the triggered actions are different. Further, some people might want to have the flexibility of having both actions available so they can choose which action they trigger by which edge they drag too, while others might only need one or the other and they can disable the one they won't use as unneeded, and still others might use neither and they can disable both, so it makes sense to have each as a separate checkbox so people can control them separately, which is exactly the situation we see and exactly how they are labeled. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: How do I get lost windows back?
On Fri, Mar 1, 2024 at 2:59 PM hw wrote: > On Wed, 2024-02-21 at 07:58 +, Duncan wrote: > > hw posted on Tue, 20 Feb 2024 17:54:27 +0100 as excerpted: > > > Why does this happen[1], how can I prevent it from happening, and how > do > > > I get the lost window back? > > > > It looks like you already got an answer to this so I'll skip it. (The > > post is long enough...) > > I still don't know why it happened. After some doing I managed to get > the window back, but that windows get arbitrarily get moved off the > display shouldn't happen at all. > > > > [1]: I think I moved it into the top left corner to see if it would be > > > maximised and/or get tiled and then it somehow disappeared. In System > > > Settings-->Workspace Behaviour-->Screen Edges, > > > > FWIW, different path in plasma6. (plasma) system settings > input & > output > > > mouse & touchpad > screen edges. > > It says KDE Plasma Version 5.27.10 in the settings. > > > > both options were enabled > > > at the same time by default. That doesn't seem to make sense, > > > and I turned the Maximizing off. > > > > I believe you're misunderstanding the configuration. It does make > sense, > > and here's how: > > Ok that's a really long explanation, and it's not what I'm talking > about. I hope I can attach a screenshot. > > What I'm talking about is having both the checkboxes enabled for > Maximize and Tile at the same time. Both of them are for when > dragging windows. That doesn't make sense: The windows that are being > dragged can only be maximized or tiled, not both at the same time. > > And I still don't know what the Behaviour thing is about. That whole > thing needs quite a lot of work before it might become understandable > by users. > > Hi all, I wanted to request that we move this topic to the specific channel for it. Given this relates to UI/US, please come to the VDG channel located here: https://go.kde.org/matrix/#/#visualdesigngroup:kde.org kde@mail.kde.org is more of a general inbox and sends messages to a very wide audience. Let's work with your specific request through the VDG team. Thank you. -- Andy (anditosan)
Re: How do I get lost windows back?
On Wed, 2024-02-21 at 07:58 +, Duncan wrote: > hw posted on Tue, 20 Feb 2024 17:54:27 +0100 as excerpted: > > Why does this happen[1], how can I prevent it from happening, and how do > > I get the lost window back? > > It looks like you already got an answer to this so I'll skip it. (The > post is long enough...) I still don't know why it happened. After some doing I managed to get the window back, but that windows get arbitrarily get moved off the display shouldn't happen at all. > > [1]: I think I moved it into the top left corner to see if it would be > > maximised and/or get tiled and then it somehow disappeared. In System > > Settings-->Workspace Behaviour-->Screen Edges, > > FWIW, different path in plasma6. (plasma) system settings > input & output > > mouse & touchpad > screen edges. It says KDE Plasma Version 5.27.10 in the settings. > > both options were enabled > > at the same time by default. That doesn't seem to make sense, > > and I turned the Maximizing off. > > I believe you're misunderstanding the configuration. It does make sense, > and here's how: Ok that's a really long explanation, and it's not what I'm talking about. I hope I can attach a screenshot. What I'm talking about is having both the checkboxes enabled for Maximize and Tile at the same time. Both of them are for when dragging windows. That doesn't make sense: The windows that are being dragged can only be maximized or tiled, not both at the same time. And I still don't know what the Behaviour thing is about. That whole thing needs quite a lot of work before it might become understandable by users.
Re: How do I get lost windows back?
Duncan posted on Sat, 24 Feb 2024 13:57:28 - (UTC) as excerpted: > xwinprop: Much like xwininfo this lists certain window info, but info > that's useful in different contexts. s/xwinprop/xprop/g (I use it in a couple scripts mostly so haven't actually typed the command name in a while, and got off-tracked by the xwininfo discussed above it.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: How do I get lost windows back?
René J.V. Bertin posted on Fri, 23 Feb 2024 15:16:20 +0100 as excerpted:
> On Thursday February 22 2024 17:56:17 Richard Troy wrote:
>
> Hi,
>
>>I got it that to unmap I'd need to write a C program using Xlib and call
>>XUnmapSubwindows(Display *display, Window w); Not having written an
>>Xlib-using program before - or at least not in maybe 30 years! - and not
>>feeling a need to get deep into it, is / are there a presumption(s) of
>>which window / display is/are the target if they're directly associated
>>with the code that's running the unmap call? Same goes for calling
>>XMapWindow?
>
> Sorry, I don't get your question?
>
> I'm having difficulties recalling in which context I have encountered
> unmap actions in existing applications. Most likely in a window manager
> I used or tested at some point, but which...
>
> Either way, with X you need to open the correct display first (a priori
> just using the value of the DISPLAY env. variable). For the window
> things can get a bit tricky because the window manager and/or the
> xwininfo command can (apparently) hide the fact that the actual window
> you're interested in has been reparented by the window manager. You can
> see that easily by using xwininfo without arguments (and click on a
> window of interest to see what data that returns) and then look up the
> returned window id in the output of `xwininfo -root -tree -all`.
>
> On my system, I'm seeing something like if 0x6800026 is my window of
> interest:
>
> xwininfo: Window id: 0xf6 (the root window) (has no name)
> Root window id: 0xf6 (the root window) (has no name)
> Parent window id: 0x0 (none)
> 209 children:
> SNIP
> 0x2200054 (has no name): () 832x768+0+0 +0+0
> 1 child:
> 0x2200055 (has no name): () 832x742+0+26 +0+26
>1 child:
>0x6800026 "XXX — Konsole": ("konsole" "konsole") 832x742+0+0
> +0+26
>
> As you can see my konsole window has a grandparent that's just a bit
> higher: this is the window that includes the titlebar. The intermediate
> (parent) is probably there to allow for kwin's fancy rendering through
> the compositor but that's just a guess.
>
> I am also guessing that you are thinking of writing a utility that works
> more or less like xkill, except that it does an unmap? If so, I'd get
> the source for xkill, make those changes and then see what the effect
> is. In principle the window manager should react appropriately to
> unmap/iconify/etc actions on the client window because the client could
> invoke those actions itself.
For X there's actually a number of comandline utilities that allow one to
see and/or change various window properties, show/hide/move/resize/switch-
desktop/etc a window around, etc. I routinely used them in various
scripts I have, and while I now use wayland with its tighter security such
that only the compositor normally has the window information and control
now, I still use these tools and X (via xwayland) in a more limited scope
for some things and on my remaining X apps.
Note that while the functionality of some of these tools overlap (many
tools can be used to find and close a specific window, for instance), each
one has unique functionality and/or is easier to work with in some
contexts so I use them all.
Among these tools:
xwininfo: As RJVB mentioned, this can be used to find certain information
about a window. Tho the info this exposes I don't tend to use so much so
I don't use this one that much.
xwinprop: Much like xwininfo this lists certain window info, but info
that's useful in different contexts. I'm actually more familiar with this
than xwininfo as it gives me easier access to window class, role and
title, which are very useful to match against when trying to find specific
windows (maybe an app has multiple windows and you only want to deal with
say the main window, or only certain dialog windows, or you want to be
sure and match all firefox windows but not the text editor window where
you're editing a firefox.txt file, so it happens to have firefox in the
title).
xrandr: Useful for scripted changes to the desktop and/or individual
screen sizes and positioning.
wmctrl: Often used to manage specific window sizes, mapping/unmapping
(showing/hiding), sending windows to different desktops, etc. Typically
one would write a script that finds windows matching specific properties
using xprop, then moves/sizes/shows/hides/kills/sends-to-another-desktop
those windows.
xdotool: Similar to wmctrl in some ways but handles things a bit
differently and can be more useful in different contexts. In particular,
I tend to use it to fake keyboard events and thus "type" into windows. (I
run an old '90s-era DOS game in DOSBox, and have a script that will send a
particular key sequence 50 times, thus automating a game restore, advance
a turn and try to get a 1% chance event to happen, if it doesn't try
again... sequence.)
xshkd: "X simple
Re: How do I get lost windows back?
On Fri, 23 Feb 2024, René J.V. Bertin wrote: Sorry, I don't get your question? Actually, you got it fine, René! That's all I can think of to help at this time. Actually, that was exactly what I was thinking and pointing me at a utility that does something sort of similar is a big help! Thanks! ...I've alrady tried a few things based on your suggestions and this is a "maybe I'll actually get this done" kind of thing that's on my "nice to do" list. Regards, Richard
Re: How do I get lost windows back?
On Thursday February 22 2024 17:56:17 Richard Troy wrote:
Hi,
>I got it that to unmap I'd need to write a C program using Xlib and call
>XUnmapSubwindows(Display *display, Window w); Not having written an
>Xlib-using program before - or at least not in maybe 30 years! - and not
>feeling a need to get deep into it, is / are there a presumption(s) of
>which window / display is/are the target if they're directly associated
>with the code that's running the unmap call? Same goes for calling
>XMapWindow?
Sorry, I don't get your question?
I'm having difficulties recalling in which context I have encountered unmap
actions in existing applications. Most likely in a window manager I used or
tested at some point, but which...
Either way, with X you need to open the correct display first (a priori just
using the value of the DISPLAY env. variable). For the window things can get a
bit tricky because the window manager and/or the xwininfo command can
(apparently) hide the fact that the actual window you're interested in has been
reparented by the window manager. You can see that easily by using xwininfo
without arguments (and click on a window of interest to see what data that
returns) and then look up the returned window id in the output of `xwininfo
-root -tree -all`.
On my system, I'm seeing something like if 0x6800026 is my window of interest:
xwininfo: Window id: 0xf6 (the root window) (has no name)
Root window id: 0xf6 (the root window) (has no name)
Parent window id: 0x0 (none)
209 children:
SNIP
0x2200054 (has no name): () 832x768+0+0 +0+0
1 child:
0x2200055 (has no name): () 832x742+0+26 +0+26
1 child:
0x6800026 "XXX — Konsole": ("konsole" "konsole") 832x742+0+0 +0+26
As you can see my konsole window has a grandparent that's just a bit higher:
this is the window that includes the titlebar. The intermediate (parent) is
probably there to allow for kwin's fancy rendering through the compositor but
that's just a guess.
I am also guessing that you are thinking of writing a utility that works more
or less like xkill, except that it does an unmap? If so, I'd get the source for
xkill, make those changes and then see what the effect is. In principle the
window manager should react appropriately to unmap/iconify/etc actions on the
client window because the client could invoke those actions itself.
That's all I can think of to help at this time.
R.
Re: How do I get lost windows back?
On Fri, 23 Feb 2024, René J.V. Bertin wrote: Under X11 you will normally run a window manager which will "reparent" every window that it is supposed to manage. IOW, every visible window is usually a child, yes. I just brought up the remote possibility that you *might* have managed to unmap your terminal window, somehow. In which case it can be tricky to get it back because the basic purpose of that function is to make a window "disappear". It turns out you probably didn't do this so let's not go deeper down this rabbithole. R. René I for one am glad you brought it up and if you'd indulge a simple question, I'd like to explore this just a little further... Some of us, like me, might find utility in such an ability, and I was unaware of it but am now thinking about it... BTW, even though I use Fedora (for now anyway!) Wayland doesn't work for my 6-head display card, so I use x11. I got it that to unmap I'd need to write a C program using Xlib and call XUnmapSubwindows(Display *display, Window w); Not having written an Xlib-using program before - or at least not in maybe 30 years! - and not feeling a need to get deep into it, is / are there a presumption(s) of which window / display is/are the target if they're directly associated with the code that's running the unmap call? Same goes for calling XMapWindow? I'm contemplating a simple utility that would have a window disappear but monitor the world and if / when conditions change would remap itself. If this gets "deep in the weeds," I'll likely not bother but if the code is simple enough, I might go for it! Thanks René, Richard
Re: How do I get lost windows back?
On Thursday February 22 2024 13:20:40 hw wrote: >Is the konsole window always a child window, and why would it be Under X11 you will normally run a window manager which will "reparent" every window that it is supposed to manage. IOW, every visible window is usually a child, yes. I just brought up the remote possibility that you *might* have managed to unmap your terminal window, somehow. In which case it can be tricky to get it back because the basic purpose of that function is to make a window "disappear". It turns out you probably didn't do this so let's not go deeper down this rabbithole. R.
Re: How do I get lost windows back?
On Wed, 2024-02-21 at 21:06 +0100, René J.V. Bertin wrote: > On Wednesday February 21 2024 14:31:16 hw wrote: > > > Unmapped? > > One of the X11 ways to make a window disappear without destroying it: > > https://linux.die.net/man/3/xunmapwindow That seems to indicate that it can be used to make child windows invisible and to generate BadWindow errors. Is the konsole window always a child window, and why would it be unmapped? And how did it become visible again, and why did was it moved outside the display?
Re: How do I get lost windows back?
On Wednesday February 21 2024 14:31:16 hw wrote: >Unmapped? One of the X11 ways to make a window disappear without destroying it: https://linux.die.net/man/3/xunmapwindow R
Re: How do I get lost windows back?
On Wed, 2024-02-21 at 13:20 +0100, René J.V. Bertin wrote: > [...] > Anyway, I hope the OP didn't somehow get his window unmapped because > that might mean it disappeared from the panel too. Unmapped? It somehow showed up when pressing Alt+Tab in the list that displays, and I had to configure two keybard shutcuts, one to set the mouse to the focused window and another one to move a window, to finally get it back. That way, I was able to move the window back onto the display by first focusing it through Alt+Tab, setting the pointer to it and then moving it. We really shouldn't need to do anything like that. Of course, I didn't move it off the display area in the first place. That's probably not even possible since I can not move the mouse pointer off the display area so that I could move a window into the nirvana (or whatever there is) that's around the display area.
Re: How do I get lost windows back?
On Wednesday February 21 2024 07:58:14 Duncan wrote: >But some people will find it annoying, particularly if they drag windows >around a lot, as if they drag it too close to the top of the screen they Definitely, one of my gripes with Win11! Al(most al)l power to my keyboard for maximising, raising/lowering/iconifying windows and moving them across desktops! The latter works great on Mac (grab a titlebar with the cursor and hit the shortcut to go to the desired desktop) but sometimes kwin's menu to just send a window off is more practical. Anyway, I hope the OP didn't somehow get his window unmapped because that might mean it disappeared from the panel too.
Re: How do I get lost windows back?
hw posted on Tue, 20 Feb 2024 17:54:27 +0100 as excerpted: > Why does this happen[1], how can I prevent it from happening, and how do > I get the lost window back? It looks like you already got an answer to this so I'll skip it. (The post is long enough...) > [1]: I think I moved it into the top left corner to see if it would be > maximised and/or get tiled and then it somehow disappeared. In System > Settings-->Workspace Behaviour-->Screen Edges, FWIW, different path in plasma6. (plasma) system settings > input & output > mouse & touchpad > screen edges. > both options were enabled > at the same time by default. That doesn't seem to make sense, > and I turned the Maximizing off. I believe you're misunderstanding the configuration. It does make sense, and here's how: The screen edges configuration consists of several different areas with settings that are conceptually separate: At the top there's an image of a monitor with eight different dots, each of which corresponds to a corner or edge, with each one of the eight available to set separately. Edges/corners that have an action assigned have their dot filled in, while those with no action assigned have their dot empty. If you click on one of the eight dots it should give you a list of the actions you can choose to enable for that edge/corner. Here, you are correct -- only one can be enabled at once, tho there's a list of many actions to choose (including "none", thus disabling action triggers for that corner/edge). Below that are three checkboxes with the choices that seem to be causing the confusion here. The fact that checkboxes (as opposed to radio- buttons) are used here indicates that the options are independently togglable and that it DOES make sense to have more than one turned on at a time. Specifically the three, maybe described a bit more clearly here (6.x version) than it 5.x?: * Maximize: [checkbox] Windows dragged to the top edge Keep in mind that this is a separate behavior from the top edge dot in the first section. The dot is the behavior when the pointer bashes the top edge when *NOT* dragging a window. This checkbox would be the behavior when dragging a window. Basically, if checked, it just gives you another way to maximize a window, that some people find easier/faster/more-natural than clicking the maximize button in the titlebar, choosing it from the window/system actions menu, hitting the maximize hotkey you may have assigned, or... But some people will find it annoying, particularly if they drag windows around a lot, as if they drag it too close to the top of the screen they might trigger maximize accidentally, when they just wanted to reposition their window (or take it to a different desktop, see below). So it's an option. * Tile: [checkbox] Windows dragged to the left or right edge Again, this behavior is separate from the left/right edge trigger configurable from the appropriate dot above. Again, that would be when not dragging a window, while this checkbox controls what happens if you're dragging a window when you bash that left or right edge. And just as top is not side, this checkbox toggles tiling, not maximizing. And again, some people will find this annoying and that it triggers accidentally for them when they were just trying to reposition a window (or trying to drag the window to a different desktop, see below). And just to stress by repetition. Yes, it does make sense to have drag- to-top-to-maximize and drag-to-side-to-tile as separate independently togglable actions, since people might want one or both or none, and they're to entirely different edges. Thus the checkboxes, indicating independently configurable toggles. * Behavior: [checkbox] Remain active when windows are fullscreen This one we'll discuss below your question about it, quoted below... > BTW, what is the behavior 'Remain active when windows are fullscreen' > supposed to do? Deactivating windows once they're fullscreen doesn't > make sense. What is remaining active, or does not remain active? If > it's a behaviour that remains active or not, then I can only say that > activating or deactivating an unknown behaviour isn't exactly helpful. What this checkbox does is toggle whether the EDGE TRIGGERS remain active, not the WINDOWS. If this is disabled bashing the pointer against the edge (or corner) when a full-screen window is active will do nothing. If it's enabled the configured action will still occur when you bash the pointer against the edge/corner. Might as well complete the discussion, describing the four remaining settings, below the three checkboxes. * Trigger quarter-tiling in: [spinbox %] of the screen This controls how big the "center edge" zone is when dragging-to-tile to the left or right, in which the tiling is half-max, vs. the upper and lower quarter-max zones. So (I think) it's only effective when the tile checkbox is checked. * Switch desktop on
Re: How do I get lost windows back?
On Tuesday, 20 February 2024 17:54:27 CET hw wrote: > Hi, > > my konsole window has disappeared or has become invisible or is > somewhere outside of the display (if that is possible). > > It doesn't show up when pressing Alt+Tab and not in the overview of > all windows. According to 'ps xca | grep kons', konsole is still > running. When I open another konsole, the new window is titled > 'Konsole <2>'. > > Why does this happen[1], how can I prevent it from happening, and how > do I get the lost window back? I can answer this. See the icon of your app in the taskbar at the bottom of your screen? Right click on that and, from the pop menu, pick "Move". Drag the window to wherever you want it and then left-click where you want to drop it. Cheers Paul -- Promotion & Communication www: https://kde.org Mastodon: https://floss.social/@kde Facebook: https://www.facebook.com/kde/ Twitter: https://twitter.com/kdecommunity LinkedIn: https://www.linkedin.com/company/kde
