[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Disabling Oxygen's window dragging for specific QWidgets?
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2011-05-17 12:15:34
Message-ID: op.vvmkb8sn9bmiid () localhost ! localdomain
[Download RAW message or body]

Am 17.05.2011, 13:00 Uhr, schrieb Michael Jansen <info@michael-jansen.biz>:

>> > . As an example all dockwidget using applications (Kontact, Kmail,
>> > kdevelop, dolphin, konqueror ... ) where you drag the application
>> > instead of resizing the docks if you are just one pixel off.
> ...
> Her is the first list of applications oxygen breaks and a description  
> how.
> (For your comment below). When will they be fixed? They are broken since  
> ages.

Sorry, but this is ridiculous.
If you cannot point some UI element (for whatever reason) but have to rely  
on an input dead surrounding, so you can just try several times w/o  
causing any further effects, the "broken" thing is either your input  
device (configuration) or the UI element (too small)
The oxygen style /does/ provide feedback on hovering splitters, so this  
cannot be it.

Splitters do indeed suck, because most of the time they're just in the way  
and when they're needed they're fucking hard to hit - esp. for ppl. with  
any kind of a challenge (and i'd count a touchpad in there)
-> Splitters (KSplitter : public QSplitter) should have an overlay item  
popping up when you cross the central region, growing the hit area.
This would be helpful to everyone. Claiming "Oxygen is broken because i'm  
unable to hit a UI element" is delusion.

> Until  then you BREAK code which is something we do not do in kde. At  
> leats that was my understanding.
Heard that argument over and over again, but seen no proof at all (while i  
know about one issue, which -see below- was/is usercode bug.)
I've checked the oxygen code and it is pretty careful to not steal any  
input action.
If you can point to a case where oxygen breaks an application feature,  
please name it.
Otherwise, please stop claiming "oxygen breaks applications/code" because  
that is NOT the same as "oxygen causes -for a windows user- unexpected  
behavior which i don't like"
If you have pure usability concerns, name them. If this is a code thing:  
proof it!

> I have problems with understanding this sentence too. The 26  
> applications is a statement from todd.He got it out of bugzilla. Same  
> thread todd tme Friday as an answer to parker coates.
a) bugzilla sucks. I had trouble to find at least one entry regarding this  
:-(
b) rather do not operate with unbacked numbers.
c) a buglist would be nice to see whether those are bugreports or user  
opinions about usability (not less important though)
This would also allow everyone to get an at least halfwise informed  
opinion instead of this "yes - no - yes - no" shitstorm that spams my  
inbox for three days.

> Personal one man projects? Proprietary code? Not bad.
Why not - kde-devel is used to be helpful.
Also the issue (i mean: "real functional bug") should most likely be on  
the usercode side since the major issue with this stuff are widgets  
(kcolorchooser used to have one) which actuall interpret lmb clickdrags  
but let the input slip through to the parent. What is a usercode bug.


Cheers,
Thomas
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]