Skip to content
  • 0 Votes
    2 Posts
    258 Views
    A

    Dug around other similar topics and found a solution, posting it here in case anyone has a similar problem to mine. The solution is in this thread

    It seems this is a 'problem' with high DPI displays in particular. I changed the way the program gets the X and Y coordinates from the mouse by taking into account the devicePixelRatio() as outlined in the linked thread, which solved the offsetting.

  • 0 Votes
    2 Posts
    268 Views
    bibasmallB

    As I understand it, the child should receive the event before the parent, but in my case, the child is deaf. I thought maybe the problem was the size of the child, so I set it equal to the parent size, but it didn't help. I can call mousePressEvent(e) directly for the child in the parent's overload, but it looks like a very bad design.

    UPD: currentPrimitive_->setKeepMouseGrab(true); allows to pass the event to the child without ugly direct call of mousePressEvent(e) .

  • 0 Votes
    3 Posts
    260 Views
    S

    @Pl45m4 Worked like a charm, thank you very much. :)

  • 0 Votes
    1 Posts
    183 Views
    No one has replied
  • 0 Votes
    10 Posts
    668 Views
    G

    @mpergand Thanks I figured it out from that one. For now it seems to work just fine.
    @JonB Thanks for the reply I toughed about that too but I'll try the eventfilter first.

  • 0 Votes
    1 Posts
    537 Views
    No one has replied
  • 0 Votes
    5 Posts
    1k Views
    T

    Tab problem is solved !

    I don't think it is a Shortcut Event as StandardKey of QKeySequence does not map Tab key. I don't realy know how it is done inside Qt, I might search later.

    I actualy just overrode QLineEdit::focusNextPreviousChild to do a validation check:

    bool LineEdit::focusNextPrevChild(bool next) { if (hasAcceptableInput() == false) { FixInput(); return true; // To prevent searching for other widgets } return QLineEdit::focusNextPrevChild(next); }

    As a result, if input is invalid when the user press Tab the tooltip is shown but if the input is valid the next widget gain focus
    Error2.png

    Apparently I still need to have better accuracy for the position of the tooltip though
    EDIT: QWidget::mapToGlobal already include the position of the widget (should have been obvious) So I just changed mapToGlobal(pos()); to mapToGlobal(s_zero); with static const QPoint s_zero = QPoint(0, 0)

  • 0 Votes
    6 Posts
    3k Views
    N

    This is what I've done right now.
    Using the same code for painting and widget, I'm able to use a custom widget as usual; moreover, for listview I'm able to render the same widget correctly (because calling render method of widget, the widget is able to read .qss stylesheet)

    Here is the example:

    this is a single widget
    0_1562332451778_widget.png

    and this is the rendered widget inside the listview
    0_1562332527764_listview-render.png

    in listview, as you can see, I'm able to render widget correctly and, in case of focus, I can change focus style using a custom property

    this is the code:

    void AlertItemDelegate::paint(QPainter* painter, const QStyleOptionViewItem& option, const QModelIndex& index) const { QVariant data = index.data(); if (data.canConvert<Error>()) { auto&& styleOption = QStyleOptionViewItem(option); ErrorItemWidget widget; if (styleOption.state & QStyle::State_HasFocus) widget.setProperty("Test", true); // <-- custom focus property else widget.setProperty("Test", QVariant::Invalid); // <-- remove property for normal state widget.resize(option.rect.width(), option.rect.height()); widget.setError(qvariant_cast<Error>(data)); painter->save(); painter->translate(option.rect.topLeft()); widget.render(painter); painter->restore(); } else { QStyledItemDelegate::paint(painter, option, index); } }

    The drawback of this solution is that I need to create a widget for each model item (however, I've render 2000 elements and I don't see any performance hit)
    The other drawback is that the height of each item is hardly code inside size-hint method, that is:

    QSize AlertItemDelegate::sizeHint(const QStyleOptionViewItem& option, const QModelIndex& index) const { int width = option.rect.width(); int height = 48; // <--- if I can get this from stylesheet, I'll be happy :) return QSize(width, height); }

    The good thing is that I can change widget stylesheet using .qss file; inside C++ code there isn't any style detail.

    Any suggestion to get height value from stylesheet?

    Thanks all!
    Nicola

  • 0 Votes
    5 Posts
    1k Views
    SGaistS

    Then add a signal to your dialog that you will emit when needed from your mouse move event.

  • 0 Votes
    5 Posts
    21k Views
    M

    @jsulm Ok! I will make sure to read all the links you've given me. Thanks for the help!

  • 0 Votes
    1 Posts
    977 Views
    No one has replied
  • 0 Votes
    10 Posts
    3k Views
    mrjjM

    @L-Koziarz
    Yep its sounds somewhat convoluted
    but never the less - exciting approach .
    I wish it had worked as prof of concept but it seems there are issues.

  • 0 Votes
    2 Posts
    3k Views
    Chris KawaC

    It would be nice to say what self and event are. I'm guessing a QGraphicsItem and a parameter of QGraphicsSceneMouseEvent? Is that right?

    If so then event.pos() and event.scenePos() are not exchangeable. The first one is cursor position in item's coordinates and the second one cursor position in scene coordinates. They are the same only when item is placed at (0,0). If item is moved they will differ. It's important to note that these values are what they were at the time the event took place, which might be different from the "current" values for item (this is a good thing). For example if you move your mouse fast and there are a lot of events generated the cursor position in these events will be a little behind the actual current position of the cursor before they "catch up".

    As for self.scenePos() - this is the position of the item in the scene. This is the point relative to which the event.pos() is calculated. It is not necessary the top left of the bounding rect. It can be placed anywhere using 'setTransformOriginPoint()'. It is often set to the center of the item. For example if you have a bunch of draggable circles a center is probably more convenient than a top left corner. For vertical bars on a chart the origin might be placed at the middle bottom of a bar etc.

  • 1 Votes
    7 Posts
    4k Views
    R

    As I now understand it there is no easy way to recognize gestures inside the c++ part of a Qt Quick 'QQuickPaintedItem' inherited class, is that correct?

    I need both pan and pinch in my c++ class so if i dont want to write my own recognition code should I then inherit my class from both 'QQuickPaintedItem', PinchArea and Flickable? that doesn't seem right? (besides that they are declared in private header files like qquickpincharea_p.h)

    found the same request (also without an statisfying answer here:
    https://forum.qt.io/topic/61108/recognize-arbitrary-gestures-in-qt5-like-gesturearea-in-qt4 )

  • 0 Votes
    5 Posts
    2k Views
    JianJianJ

    @hvoigt got the same issue

  • 0 Votes
    6 Posts
    2k Views
    mrjjM

    @Joel-Bodenmann

    Well actually its not super weird. If you active
    accessibility settings in windows, (on some pads)
    you can get this for drag & drop to help
    people where is hard to hold down mouse. :)