On Mon, 24 Feb 2020 at 7:06 pm, Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:
>
>
> So, does anyone know the historical reasoning here, or any good reason
> for not changing FocusScope just a normal property on Item?
>
> I don’t know the reason but if you just change it to
The short answer is some amount of platform adaptation will be required to
enable hardware acceleration on your board. Looking at the page you linked
to; that adaptation might be achieved by creating an implementation
of QGstBufferPoolPlugin (gstreamer 0.10 only) which exposes EGL surfaces
associa
ndow.cpp
>
> +++ b/src/quicktemplates2/qquickapplicationwindow.cpp
>
> @@ -424,6 +424,7 @@ QQuickItem
> *QQuickApplicationWindow::contentItem() const
>
> QQuickApplicationWindowPrivate *d =
> const_cast(d_func());
>
> if (!d->contentI
That's a very universal solution to a specific problem and one that's going
to have all kinds of unintended consequences. Without knowing why focus was
taken from an item and given to another and why that other object
relinquished focus it's impossible to know whether focus should be restored
to th
On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly
wrote:
>
> And there are the obvious runtime costs to building and maintaining a
> cache that is of little or no use to most people most of the time, which is
> I think a strong argument for it being an off by default feature if
> implemented.
>
>
>
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly
wrote:
>
>
> https://bugreports.qt.io/browse/QTBUG-50542
>
> The remove animation happens as a result of the
> QAbstractItemModel::rowsRemoved signal, so there is a 'tension' between the
> requirements:
>
>1. An attempt in the delegate to access
>
> Is creation expensive because of constructor code, making too many
> signal/slot connections, or something else?
>
First of all it's accumulative, any QML application is going to end up
constructing many items, hundreds, thousands even and costs, even small
ones add up. Secondly yes construct
On Sat, Jun 22, 2013 at 12:38 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Fri, Jun 21, 2013 at 2:24 PM, Jeremy Katz
> wrote:
> > On 06/21/2013 09:58 AM, Hausmann Simon wrote:
> >> Hi,
> >>
> >> I like this, but as a next step I think it would be good to get rid of
> the manual JS code for
> Perhaps an alternative approach would be to create a proxy model for
> exporting to QML. It could include all the methods you need, but it
> would not complicate QAIM itself. It seems to me that all the methods
> you need can be implemented in terms of the already existing
> functionality in QAIM
