Bug 480072

Thanks for the bug report! Unfortunately I'm having a hard time figuring out what bug is being reported here. Can you please read https://community.kde.org/Get_Involved/Issue_Reporting and submit a new bug report that describes a single discrete problem? If you read through that wiki page and don't feel like it's helped at all, I'd recommend posting a question at https://discuss.kde.org/c/help/6, and hopefully the people there can help you determine what the problem is and whether it's caused by a bug in any KDE software (for example it might be an issue in the Qt toolkit, or in any of those other platforms you mention). If something KDE controls is determined to be the cause, please don't hesitate to come back here, re-open this bug report, and describe what the problem was determined to be.

thanks for replying, Nate.

the bug being reported here is described by  the title of the bug report, namely :"cannot disable window drag on left click in window (kdenlive) bloody annoying"

to clarify, it's a behaviour that occurs in Xubuntu (i can't speak for Ubuntu), which occurs in the following situation:

ordinarily, to change the timeline zoom, or to move the timeline cursor, you click on the (zoom or cursor) icon, hold the mouse button down and slide the icon to where you want it.  but if you are clumsy like me, and/or your eyes aren't what they should be, you will miss your mouse target by a single pixel, and the software will fondly imagine you intended to miss the icon a pixel away and assume you intended to click on the background instead, which of course, nobody in their right mind would ever want to do, ever, right?!  grrr!.

unless you're Yehudi Menuhin or Stephan Grapelli, the older you get, the clumsier you get, and in my case i was clumsy when when young, so you can imagine what it's like now.  i've been using kdenlive for about 10 years, but don't remember how long it's been since it started doing this to me; i only remember that it didn't used to do it in the old days, but now it does and it drove me nuts, so nuts that i filed the bug report not expecting a response.  

i have studied in minute detail every single page on internet - and there's millions of them - and i can report with authority that (a) i'm not the only one, and (b) nobody knows what to do about it, except move to another planet.

the behaviour (the software's behaviour that is, not mine (mine is beyond help)) is strictly speaking more of a "design feature" bug in the head of the software designer rather than an implementation bug.

and, as it happens, since posting the bug report, i solved it but forgot to add a comment about that until i saw your own comment asking what the hell i am talking about.

so.. if you haven't clicked and dragged off already by now, here is the explanation and solution:

it turns out it's not a kdenlive bug after all, but a kde window manager one.  it seems some twonk had the great idea of enabling click and drag anywhere within a window background, not just on its top bar like normal people do.  kde users can switch this idiotic "feature" off, but xfce users can't because they don't get access to the different (to xfce's) window drawing suite controls that kde uses.

if you can identify the kde interface designer that designed it, i would be happy to go round to his place, haul him off to the Algerian desert, and bury him up to his neck in sand for the ants and vultures to peck at.

BUT... i solved it!  It tuns out that all you have to do is change the "Settings... Color theme" to "Fusion"  This applies to kdenlive 21.04.0 which i'm sticking with because 23.nn.n has all sort of other nasties that are even more intolerable and they are so bad i don't even want to start talking about them  - which is one good thing for customer service operators :)

Yes, the behavior comes from the default Breeze theme. Using Fusion works around it by not using Breeze.

It sounds like there really is an app bug here though. If the app has UI elements with drag areas that are very small and very close to the window background, then, yeah, a mis-drag will drag the window instead of the UI element and this could be very frustrating. It sounds like a solution could be to increase the size of the draggable UI elements, or the size of their invisible drag areas.

there is an app bug in the kde bug reporting user interface... because it takes up so much space with rhubarb it doesn't let a commenter see the last comment she is commenting on!

and this bug is a kde design concept bug, not a kdenlive implementation bug, because any icon is of necessity immediately adjacent to background - that's where the edge of the icon is.  Your suggestion of increasing the invisible drag area is a good workaround, but in my view, it's a Band-Aid solution to a problem that should never have been there in the first place, because background window drag is a completely unnecessary and idiotic idea.  Swiping might be good for flipping through photos of drag artists, but kde would have you dragging their whole photo album window around instead.  It's ridiculous!

Imagine if trombones were designed like that - every time you wanted to play a different pitch, the trombone would fly out of your hands and hit the first violinist on the back of her head!

i will leave it to you to decide what to tell kde cuckoo drag artist designers :)

You may not like the feature to drag a window from empty areas, but it's in fact an extremely popular feature overall, and whenever it breaks we get tons of bug reports. So removing it or disabling it by default is not on the menu. What we can do is make small UI elements in Kdenlive larger so that it doesn't cause as much of an issue for people without precise mousing skills.

on behalf of everyone who has dodgy eyesight, i implore you NOT to make the icons bigger.  even with myopia and astigmatism, i can see the icons just fine, and making them bigger would be making them bugger up display aesthetics, which are already pushing it in terms of having too many fiddly bits on screen all the time, many of which i have never needed in 10 years.  of course, one man's meat etc.... your previous idea of making the invisible selection area around an icon bigger is a good one.

having discovered fusion, i am happy with it just the way it is.  btw the only theme that works with fusion is 'default', all the other themes create some illegible icons.

but if you are open to new ideas, i do have one request: can we have an option to change the shade of background?  the light themes are a bit too bright for me, and the dark ones a bit too dark.  what i want to be able to do is focus on the video i am creating, not on the bells and whistles of kdenlive ui.

All colors are fully changeable via the KDE colorscheme (which only works when using the Breeze theme, not the Fusion theme). The UI for this is in KDE's System Settings though, as it's a systemwide thing not a per-app thing.

It's sounding more and more like you might have a better time using Kdenlive if you were running it on KDE Plasma too, so all these things were made fully customizable. :)

i considered switching to KDE a while back, and tried installing Neon alongside Xubunti, but i got a peculiar boot loader error i couldn't decipher.  i don't remember the details, but i do remember other people had had the same problem and no-one found a solution.

Right now i don't feel like fiddling around with tinkering, as the projects i am working on have higher priority for me (especially this one: https://lcipm.blogspot.com/2023/12/judicial-errors-in-unjust-trial-of.html ) .  Fusion has made kdenlive liveable, so that will do me for now. 

But if you're into non-KlunkyDesktopEnvironment design, here is my own design, called OUI (=ObviousUserInterface) which extends the concept of one-app windows to multi-app project rooms 
https://drive.google.com/file/d/1OT-5FFgZGKXxIdegUpTMQ-dLOKGYaWrz/view?usp=sharing
i came up with it yonks ago when thinking about usability in the context of kdenlive and one-laptop-per-child