#119 GUI elements depth error

v0.40.2
open
nobody
puredata (322)
5
2007-03-11
2007-03-11
sistisette
No

When two gui elements (for example sliders) overlap, and you try to "click" on them (i.e. move the slider) within the overlapping region, the correct behaviour would be that the front-most element "receive" the mouse click, since that is the one you're visibly "clicking on". However, the opposite happens: the gui element which is behind is the one that you move.
This happens both in editmode and not.

At least on Windows XP.

Discussion

  • bipll

    bipll - 2007-03-14

    Logged In: YES
    user_id=1493916
    Originator: NO

    > However, the opposite happens: the gui element which is behind is the one that you move.

    Isn't it intended to let access GUI elements which are on the bottom of stack, thus taking them to the top (in rotation)? Because if

    > the correct behaviour was that the front-most element "receive" the mouse click

    then the front-most element would be the only one that receives while the others stayed intact.

     
  • sistisette

    sistisette - 2007-03-14
     
  • sistisette

    sistisette - 2007-03-14

    Logged In: YES
    user_id=1709568
    Originator: YES

    > Isn't it intended to let access GUI elements which are on the bottom of
    > stack, thus taking them to the top (in rotation)? Because if

    The bottom element is not taken to the top. It remains on the bottom, and it keeps receiving the events; the front-most element never receives the event.
    Furthermore, I am concerned especially about non-edit mode, and I don't think that anything should rotate when not editing.

    Have a look at the attached patch (depth_bug.pd).
    By the way, sorry for not attaching an example before.

    It just makes no sense that you are clicking on what is hidden rather than on what is visible.
    File Added: depth_bug.pd

     
  • Luke Iannini

    Luke Iannini - 2007-07-01

    Logged In: YES
    user_id=1541432
    Originator: NO

    Hi, I tried tried to make a slider-based virtual clavier and this bug kept all of the black keys from working. The workaround would have been to surround the black keys with 3 white sliders of various sizes, then cover discontinuities with a 1-pixel white canvas, all to ensure a single-layer of GUI elements. I definitely said the hell with it. So I agree it's terribly annoying! Maybe I'll have a look at the source sometime, but it would be a miracle if I found it.

     
  • IOhannes m zmölnig

    Logged In: YES
    user_id=564396
    Originator: NO

    as ed kelly has demonstrated so beautifully at the pd~con07, this is really a feature and not a bug:
    it gives you the possibility to add hidden guiobjects that control the behaviour of the visible ones.
    e.g. you can create a symbol-box where you can select the symbols by click-n-drag (just like you are used to do it with numberboxes)

    see attached patch for examples
    File Added: backguis-rule.pd

     
  • IOhannes m zmölnig

    this is a feature not a bug

     


Anonymous

Cancel  Add attachments