Basically, if the "determining mimetype" QMenu is shown, and then afterwards we
re-use this menu to show the possible actions, we clear it and then it just destroys
itself on exec() returning a null QAction, rather than waiting for the user to make
a selection. It doesn't matter when, as soon as the menu becomes empty, be it because
we call clear() or we remove the action before populating it. Hence, we just populate
the menu and then remove the first action which will be the "determining mimetype" placeholder.
CHANGELOG: Fix dropping files onto the desktop/panel not offering a selection of actions to take
REVIEW: 125939
-use splitRef when converting parts of qstring to ints to avoid redundant memory allocations
-warnings--: remove redundant ';'
CCMAIL: notmart@gmail.com
BypassWindowManagerHint is a flag which is X11 specific. Because of
that for example QtWayland doesn't create a real window for QWindows
with this flag.
Using such a window will eventually result in a freeze of the whole
application. If one renders with QtQuick to such a window, mesa will
request a frame callback from the compositor. Just the compositor
will never deliver the frame rendered callback as it doesn't know the
window exists in the first place and by that doesn't render it and
will never ever deliver the frame rendered callback.
If now one tries to render another frame, mesa notices that it hasn't
got the frame callback and will block the thread till that happens.
With the setup described: that's until eternity.
See Qt Bug: https://bugreports.qt.io/browse/QTBUG-49272
REVIEW: 125961
This makes IconItem try to load global icons from the theme
with Plasma::Svg as well, making it assign the colors from
the stylesheet if the breeze monochrome icons are treated,
that should be scriptable, from some attempts i did the
script seems to convert them correctly, without any
change in rendering.
This will automatically color monochrome breeze icons only
in plasmashell, and more specifically only those that use
IconItem, not QIconItem (iconitem should probably have an
animation-less mode to be able to be used in taskmanager
and stuff)
perhaps in the future we'll be able somehow to hook all
this stuff in QIconEngine to be able to use it in QWidget
applications, but since QIcon does have any idea where it is,
is not usable yet for things like the fullscreen fixed-dark
gwenview view.
Change-Id: I28e5fedabafbe8ed82a9df7614f8e2af18c6a24d
REVIEW:125657
Plasma's Button has an extra property "minimumWidth" which is an extra
hint not in QQC to say "what is the size to exactly fit the contents".
(it's a bit confusing, as we can perfectly handle a button below it's
"minmimum" size)
This should be based on the size the contents want to be (the
implicitWidth), not how small the contents can go (which with is pretty
meaningless when our button can elide)
It got broken at some point recently.
BUG: 353584
Change-Id: I637898c3abf98183bbae30d8f15c4d72801a3650
REVIEW: 125698
QtQuickControls already does this inside Button code. This hint is meant
to be "what's the default size for a panel to be".
Change-Id: I12fd084a3d3c35b172fbff9c7d3ab5c5565a82dc
appletCreated is different from appletAdded because it gets
emitted only when the user explicitly creates one, so not in
case of an applet migrating and not during restore
needed by https://git.reviewboard.kde.org/r/125562/
REVIEW:125569
Change-Id: I1db9286beb160391c13f1aca0ac48ed490495ea2
applying the flag on exposeEvent correctly hides the dialog
from the taskbar, while is still present if only applied
in ShowEvent
Change-Id: I289c36aff251e5cc6e41a493cbc0b2b5b1432a8d
This reverts commit 4e9b32d80d.
doesn't fix the problem and just introduces a memleak
(the crash is actually about a deleted containment,
so the problem is somewhere else)
CCMAIL:xiangzhai83@gmail.com
