Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse events and multiple documents #288

Open
rickyviking opened this issue Aug 3, 2016 · 10 comments
Open

Mouse events and multiple documents #288

rickyviking opened this issue Aug 3, 2016 · 10 comments

Comments

@rickyviking
Copy link

Hi all,

in my application the GUI is split in several RML documents, each of them containing a logical part of the GUI and not overlapping with each other.
Now it may happen that several of these parts are shown simultaneously and should be all "responsive".
Visually the documents are shown correctly, but only the "latest" one (in showing order) receives mouse events, because the "body" element of the latest document hides the widgets belonging to other documents.
I'd like to receive the mouse events on all of my widget, disregarding the document they belong to.
Is there a way to get such behavior?

@dwimsey
Copy link
Member

dwimsey commented Aug 3, 2016

Off the top of my head, I feel like if they aren’t being processed and swallowed by the document, then they should pass to the next item in the Z-Order.

Are you creating one large document for each RML that covers the whole view port, or are these documents never overlapping their outer bounds?

Can you enable outlines in the debugger and send a screenshot of your layout?

Based on what you’re saying, that doesn’t sound like the expected behavior but I want to make sure I understand the issue you’re having fully.

On Aug 3, 2016, at 1:17 PM, Riccardo Corsi notifications@github.com wrote:

Hi all,

in my application the GUI is split in several RML documents, each of them containing a logical part of the GUI and not overlapping with each other.
Now it may happen that several of these parts are shown simultaneously and should be all "responsive".
Visually the documents are shown correctly, but only the "latest" one (in showing order) receives mouse events, because the "body" element of the latest document hides the widgets belonging to other documents.
I'd like to receive the mouse events on all of my widget, disregarding the document they belong to.
Is there a way to get such behavior?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #288, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqFysQZia6--svAtohdWQR251WObaRsks5qcM0ugaJpZM4Jb2Pe.

@rickyviking
Copy link
Author

Hi @dwimsey , the setup is exactly as you describe: each of the separate RML doc is taking the whole viewport, but their contained widgets do not actually overlap.

I'm attaching a few screenshots showing 2 documents: one for some object info (top of the viewport) and one with actions (bottom). Each of the doc has a body which covers the whole viewport (see the shots).
If I load first the actions doc and then the info, object info "steals" all of the mouse events, and they never get to the actions widgets, and the other way around.

I also would expect that the mouse events would traverse the different docs in their z order, I think the relevant code is here:
https://github.com/libRocket/libRocket/blob/master/Source/Core/Context.cpp#L1042
but I wasn't able to understand the whole picture.

object info shown as last, main div outlines
image

object info shown as last, body outlines: actions widgets never receive mouse events
image

actions doc shown as last: object info never gets the mouse events
image

@rickyviking
Copy link
Author

@dwimsey did you get a chance to riproduce the issue?

@thewolfwillcome
Copy link

thewolfwillcome commented Aug 10, 2016

@rickyviking how do you show the documents?
@dwimsey I can reproduce the problem too.
Even hover events doesn't gets properly handled.

Following test case:

  • Two RML Documents with body filling the whole screen
  • The first document has some elements with an hover effect applied.
  • The second document has only one element with an text in it. But its z-order value is set to 100

When both are shown the hovering works. But when i click on the element with the text of the second document then the elements on the first document doesn't get any inputs anymore (even hover effects are not applied)
It seems that an focused element (focused via click on it) kind of blocks any events to travel to other documents.

@rickyviking
Copy link
Author

@thewolfwillcome I have a demo application on which I can load several RML documents. Each document is loaded and then ElementDocument::Show() is called on it.
I've tried the different focus flags when calling Show(), but the behaviour is the same.
In my case the hover effect (if present in the document that I show first) doesn't work since the beginning, as if any document which is simply loaded+shown after the first blocks the events as you are explaining.

@rickyviking
Copy link
Author

rickyviking commented Aug 23, 2016

@dwimsey @thewolfwillcome did you guys have the time to take a look to the code that should forward the events to the different docs? As I said before, the relevant bits should be in this method
https://github.com/libRocket/libRocket/blob/master/Source/Core/Context.cpp#L1042
but I wasn't able to get the whole design a test a patch.
Any help is welcome as I'm kind of stuck here, thx!

[UPDATE]
I've also found a case when elements of the same doc hide each other.
Referring to the images below, the RML used to display them is as follows:

<div id="view-list" class="view-list">

      <div class="menu__item selected">Tab1</div>
      <div class="menu__item">Tab2</div>
      <div class="menu__item">Tab3</div>

         <div class="view-list__controller">
            <div class="view-list__control left-command">LB</div>
            <div class="view-list__control right-command">RB</div>
         </div>

   </div>

I'm able to hilight the outline only for the LB div element (first screenshot), if I try to pick any of the tab element (second screenshot), I get an hilight on the whole div which encloses the LB and RB elements.
So basically the container div is hiding the tab elements.

menu01

menu02

@thewolfwillcome
Copy link

thewolfwillcome commented Aug 23, 2016

@rickyviking: That in your second example the elements in the div with class "view-list__controller" hides the other elements (With text Tab1-Tab3) is clear why.
the "view-list__controller" div has a higher default z-order then the other elements because it is listed after the first three divs.

And this is the same behaviour as within an browser:
Here an example html document which resembles your example:

<!doctype html>
<html lang="de">
  <head>
    <meta charset="utf-8">
    <title>Titel</title>
    <style>
        div
        {
            display: block;
        }
        .menu__item
        {
            display: inline-block;
            width: 50px;
            border-top: 1px solid black;
            border-bottom: 1px solid black;
            border-left: 1px solid black;
            border-right: 1px solid black;
        }

        .menu__item:hover
        {
            background-color: red;
        }

        .left-command
        {
            float:left;
            width: 50px;
            border: 1px solid black;
        }

        .right-command
        {
            float:right;
            width: 50px;
            border: 1px solid black;
        }

        .view-list__controller
        {
            width: 350px;
            height: 50px;
            position: absolute;
            top: 0;
            left: -100px;
        }

       .test
       {
        position:relative;
        margin-left: 100px;
       }

    </style>

  </head>
  <body>
  <div class="test">
    <div class="menu__item selected">Tab1</div>
      <div class="menu__item">Tab2</div>
      <div class="menu__item">Tab3</div>

         <div class="view-list__controller">
            <div class="view-list__control left-command">LB</div>
            <div class="view-list__control right-command">RB</div>
         </div>
    </div>
  </body>
</html>

@thewolfwillcome
Copy link

thewolfwillcome commented Aug 23, 2016

@dwimsey: Are you still there?
I have modified the loaddocument sample to show the problem attached is the patch with the changes:
sample.patch.txt
Both bodies are spawning over the whole visible area of the context.
In this example only the hover effect for the "This is a sample2" element is applied when the mouse is hover that element.

The problem is really the method Context::GetElementAtPoint -> https://github.com/libRocket/libRocket/blob/master/Source/Core/Context.cpp#L1042
In the above example the check will return that the mouse position is inside the body element of second document (with title Demo2). And thus it will ignore any other document beneath the second document.

But if the method ignores element which are the owner document (aka the element with "body" as tag name) then both hover effects works.
But in this case any hover effects or click events at ElementDocument level only (When no child element of that document is under the cursor) would brake (But only when the document is not modal).

@rickyviking
Copy link
Author

@thewolfwillcome thank you for the html example, I thought in the web browser it was working differently - then I'll have to sort this out in a different way.
I hope instead you can find a solution for the multiple documents case with @dwimsey

rickyviking added a commit to rickyviking/libRocket that referenced this issue Mar 7, 2017
…(body) to allow lower indexed docs to receive events.

This fixes issue libRocket#288. Might need more settings/flags to allow either the old and new behavior.
Also factored out the recursive routine in a separate method to increase readability.
@rickyviking
Copy link
Author

Hi all,
I've created a PR which solves the issue I explained above.
@thewolfwillcome it is true that my fix brakes the cases in which somebody wants the events to be grabbed by the (first) document's body element.
I think we might add a setting on the context to chose which behavior one wants to enable.
Or maybe to return the body only if no "real" widget handles the event?
Which body in that case if multiple docs are overlapping? the lowest one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants