Script Kiddy (f965b661) at 29 Mar 01:20
GIT_SILENT Sync po/docbooks with svn
See line 64 in toolbarlayout.cpp, the default is actually AlignLeft and not AlignRight as the docs claim.
See line 64 in toolbarlayout.cpp, the default is actually AlignLeft and not AlignRight as the docs claim.
Joshua Goins (cdb94dab) at 28 Mar 21:28
Clarify that the default alignment for ActionToolbar is AlignLeft
The if statement was written wrong, the check if the navigation button flag was set to NoNavigationButtons was a part of the OR it really should be a separate AND.
Joshua Goins (007dd8b4) at 28 Mar 20:54
Fix the back button appearing even when we request it to be gone
Script Kiddy (83832b8e) at 28 Mar 01:27
GIT_SILENT Sync po/docbooks with svn
Ultimately what seems to happen isn't so much that the node list is wrong,
but that the software renderer "forgets" that those nodes are part of a certain QQuickItem, resulting in it placing the nodes at global 0,0 instead of item 0,0.
If the node list is fine, how does this patch change anything?
So in software mode if we push 2 nodes we can't guarantee the order being retained in the order we pushed?
Addition is fine, it's removal that messes up something.
I've tried to figure out where the software renderer goes wrong but that code is hard to follow. I did notice one thing the renderer does is basically create a shadow tree of different nodes based on the main scene graph nodes.
Ultimately what seems to happen isn't so much that the node list is wrong, but that the software renderer "forgets" that those nodes are part of a certain QQuickItem, resulting in it placing the nodes at global 0,0 instead of item 0,0.
It does not lie:
QSGNode *QSGNode::childAtIndex(int i) const
{
QSGNode *n = m_firstChild;
while (i && n) {
--i;
n = n->m_nextSibling;
}
return n;
}
and if the bug is at a QSG level it doesn't make sense that we have an issue in only one renderer.
I do not want to see this merged until we have a better explanation. Bugs can be fixed, complex codebases cannot.
may well lie... let's see what they say on https://bugreports.qt.io/browse/QTBUG-123799
When using the software rendering backend for the scene graph, we may end up in a state where we have added the nodes for animation but the bottom-most node isn't the most transparent one. Removing the bottom-most node then ends up confusing the state handling leading to misplaced icons.
Arjen Hiemstra (b6a3225f) at 27 Mar 11:29
icon: Remove the node with lowest opacity when animation end
Script Kiddy (c13c6300) at 27 Mar 10:44
GIT_SILENT Sync po/docbooks with svn
Script Kiddy (e92cf3fb) at 27 Mar 09:51
GIT_SILENT Sync po/docbooks with svn
Docs imply we can:
QSGNode *QSGNode::childAtIndex(int i) const
Returns the child at index i.
Children are stored internally as a linked list, so iterating over the children via the index is suboptimal.
if they're stored as a linked list that can't change on a per-render backend basis
Script Kiddy (64966330) at 27 Mar 01:20
GIT_SILENT Sync po/docbooks with svn
So in software mode if we push 2 nodes we can't guarantee the order being retained in the order we pushed?
When using the software rendering backend for the scene graph, we may end up in a state where we have added the nodes for animation but the bottom-most node isn't the most transparent one. Removing the bottom-most node then ends up confusing the state handling leading to misplaced icons.