> [snip observations that the web widget is catching mouse events > outside the thumb but inside the scrollbar]
I wrote: > Unfortunately, this isn't really how things work. Either a > widget asks to capture input, in which case it can get events > outside its boundaries, or it doesn't. > If a widget does ask to capture events outside its boundaries, it then > needs to have some idea about what to do with them. > And that's hard (and each group will implement it differently, but > poorly).... Kalle wrote: > I don't understand this, why would the browser widget be interested in > events that happen on the scrollbar widget? Pictures required: Browser Widget +---------------------------------------+ |This is a web page. It's a bit wide..|^| |This is web content, it isn't interes| | |Sometimes there might be /^%$TRER^Y\ | | |Other times you might HSDfkjl435H |X| |have a <link> or <button>DSFGDFGDR$T | | |there are other objects SDFDSFDSFDS | | |but most people forget SDFDSFSDFSD | | |about them. sDFSDFDSFDS | | |_____________________________________/v| |<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >x| +---------------------------------------+ We have two thumbs (labeled X and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX for vertical and horizontal scrolling in their respective tracks). If you click on X, and then drag over the button or link, or any other part of the page, then X gets the events and has to decide what that means. If you happen to reach all the way to the <link> in my picture, something has /probably/ gone wrong. That said, the exact algorithm that Gtk uses is to my knowledge not exposed (unlike Gtk Widget theming which is exposed). The windows algorithm seems to involve the thumb halting movement when the distance from the track is >~60px, offhand, I don't believe there's an API available to find out this information either. +---------------------------------------+ | |^| | | | | | | | 1 |2| | | | | | | | | | | | | |_____________________________________/v| |< 3 >4| +---------------------------------------+ 1 - browser content 2 - browser widget emulating vertical scrollbar 3 - browser widget emulating horizontal scrollbar 4 - browser unhappy More detailed pictures are of course available, but usually the interesting ones involve much more complicated pages. For example, pages that are 200,000 pixels tall (historically some widgets especially related to X toolkits had issues with 16bit limits). if you think that your toolkit can really handle such widgets correctly, I have a number of crashing bugs involving X and images that are e.g. 1x200,000 in dimension [you're of course welcome to volunteer to fix them]. You will not find a properly functioning css3 capable web browser which actually uses native widgets. They *all* synthesize them (some do more synthesis, and some less, but all widgets are synthetic). > That's what happens > anyway, I start a drag over the scrollbar outside the thumb and the > page is panned as if I dragged on the page. > > Unless of course (and I guess this is the case) it's not really two > widgets but one widget doing funny things. It's not not two widgets, but it isn't a browser widget and a gtk scrollbar widget. It's a browser content area and a browser scrollbar widget emulating a gtk scrollbar widget, both inside a browser widget. I'm glad you figured out the general problem. > I don't see this with any > other application, the scrollbar will "jump" to the direction of the > stylus as expected if I start a drag outside the thumb. > So I suppose this particular bug can and should be fixed in the > browser UI / browser engine... Lots of things can be done in lots of places, some things can't be done correctly in any one place. Some things shouldn't be done. And some things might never be done. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers