| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The methods solveMin() and solveMax() had similar implementation, except
by a "-1" multiplier. This commit includes a new private method called
solver that is called by both solveMin() and solveMax().
A new enum 'solverFactor' was added admiting 2 values - Maximum (+1)
and Minimum (-1).
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
|
|
|
|
| |
Some whitespace cleanup.
|
|
|
|
|
|
|
|
|
|
| |
Currently, the code is not in effect for the simplex solver kicks in
(it crashes), but it is in effect for each layout to check that
simplification and restoring the simplification back again works.
This is currently done in calculateGraphs()
Parts of the code does not read well, especially the detection of the
sequential chunks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding "fillWidth()", "fillHeight()" and "fill()". These convenience
methods simplify the creation of anchor setups where some items
are meant to use the full width and/or height of the layout.
For instance, instead of creating four anchors (bottom, top, left, right)
between an item and the layout, to make it use the full layout area, the
user can call layout->fill(item).
It is also possible to make an item assume the same width or height of
another item, calling layout->fill(firstItem, secondItem).
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
|
| |
Using QGraphicsLayoutPrivate methods for proper reparenting of
items. This makes it work in cases where nested layouts are used.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
| |
If two vertices are adjacent in the candidate list they should also be
adjacent in the graph. This means there should always be an edge
between candidates.at(n) and candidates.at(n + 1).
|
|
|
|
|
|
|
| |
See comment in simplifyGraph on how the overall approach is.
There are still outstanding issues:
1. Simplify parallel anchors
2. Use linear layout to distribute sequential anchors.
|
|
|
|
|
| |
The black arrow shows the principal direction based on the "origin"
member of AnchorData.
|
|
|
|
|
|
|
| |
We insert a special SequentialAnchorData. This anchor's min/pref/maxSize
will be the sum of the sizes of all the anchors it is replacing.
This should make the equation solver faster, and will enable us to
do distribution properly just like a linear layout would do.
|
|
|
|
| |
Keep it simple...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous dumper relied on traversal of the graph, which meant that
it would not output the nodes that were not connected to the "main"
graph. Due to this, we cannot rely on traversal, so instead we must
iterate through all the vertices of the graph. As an added bonus the
code gets simpler :-)
There was also a problem with the previous dumper, since it dumped
two "digraph" elements into one file. Graphwiz (win32) did not handle
that. Instead just dump all the nodes and all the connections, both
horizontal and vertical ones. The horizontal and vertical connections
are never connected anyway, so the result will be two separate graphs
when it is rendered by graphwiz.
Also renamed firstVertex to rootVertex and simplified it.
|
|
|
|
| |
Should hopefully be easier to test layouts now...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both QGraphicsAnchorLayoutPrivate::solveMinMax() and solvePreferred()
were deleting the linear programming contraints while QSimplex still
had them.
For solveMinMax(), move the creation of constraints out of that
method.
For solvePreferred(), create the simplex solver in the heap so it can
be deleted before the constraints are.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Reviewed-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
|
|
|
|
|
|
|
|
|
|
| |
Each time an item is added to the layout, center constraits are
created to ensure its internal anchors keep their size equal.
To avoid memory leaks, we must delete them when the item is
removed.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
| |
Removed an obsolete delete d_ptr, since it is not needed anymore.
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference count system used to delete AnchorVertex objects
stored in m_vertexList had an issue that prevented the count values
from being stored properly.
This is a tentative fix for the memory leaks in the layout, changes
were made to the m_vertexList access methods as well as those that
use them.
1) addInternalVertex()
After incrementing the ref count, store it in m_vertexList.
2) removeInternalVertex()
To make it symmetrical to addInternalVertex() we delete the anchor
vertex if its reach count reaches zero. From now on, the only
methods that create or delete vertices are these two. All other
methods should rely on add/removeInternalVertex.
Also made the method 'void'. This method is called to release
the associated object and may trigger a deletion of it, thus
any use of the object reference after that is unsafe. Other
methods can get a reference with internalVertex().
3) removeAnchor()
Follow above instructions. No longer relies on the reference
returned by removeInternalVertex(), instead, use the reference
first then release.
Note: In this particular case, we know that "removeEdge(v1, v2)"
will only access the contents of the pointers, not the
referenced object. Yet, the change probably pays itself
for the sake of clarity and safety.
4) removeAnchors()
Each tiime an anchor is created, the reference count of its
both vertices is incremented, thus we should decrement that
count every time we remove an anchor. (Instead of removing
v1 only once).
Also, leave the task of deleting v1 to removeInternalVertex()
as explained above.
Removing the constraints handling code. I understand that we
cannot leave constraints with dangling pointers inside of them,
however that raises an even worse problem.
Every time an item is added, we create an item center constraint,
thus we must be sure to delete those when the item is removed.
Once we do that, we won't have bad constraints laying around.
This issue remains open in this commit but will be solved soon.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
|
|
| |
In the public Qt::Orientation enum, Horizontal and Vertical mean
0x1 and 0x2 respectivelly, this was causing the internal data
structure to be accessed in positions 0 and 2 instead of 0 and 1.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
| |
Applying the patch sent by email.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the itemCenterConstraints that are created when an item
is added to the layout are never being deleted.
Ideally this should be done by the time the item is removed from
the layout, this requires some changes in the data structures used
though. As a temporary solution we keep all of them until the
layout is destroyed.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
|
| |
The internal layout anchors were leaking, now we delete them when
destroying the layout.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
| |
Delete objects from heap.
|
|
|
|
|
|
|
|
| |
Observe the "skipInPreferred" flag in AnchorEdges to avoid adding
the layout internal anchors to the preferred size calculation, what
was leading to non-optimal results.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
|
|
|
|
|
|
| |
We don't want the layout internal anchors to be used in the preferred
size calculation, therefore we must set this flag.
It was already being set for horizontal edges but for the vertical
ones this was missing.
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
|
|
|
|
| |
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
| |
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
|
|
|
| |
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a total re-written implementation of QGraphicsAnchorLayout using
a numerical approach. We use QGraph and QSimplex in order to achieve this.
This first commit gives us a just ready-to-use qgraphicslayout, but the
private class still need to inherit from qgraphicslayoutprivate. Optimizations
and documentation are all work in progress.
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation is based on the iterative algorithm presented in
http://en.wikibooks.org/wiki/Operations_Research/The_Simplex_Method.
It is capable of giving us the solution to any n variable LP model.
Although we focused on QGraphicsAnchorLayout, the solver is general
enough for being reused in any other Qt classes if needed.
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
|
|
|
|
|
|
| |
This file was originally included by Alexis Menard <alexis.menard@nokia.com>
but now it has been fully updated to the new QGraphicsAnchorLayout needs.
Signed-off-by: Anselmo Lacerda S. de Melo <anselmo.melo@openbossa.org>
Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
|
|
|
|
|
| |
When an extern function is declared in the scope of another function,
MSVC sometimes ignores the enclosing namespace {}.
|
|
|
|
| |
Whoops, don't do sigaction for (nonexistent) signal 0.
|
|
|
|
| |
the property is set, not what doesn't happen when the property is not set.
|
|
|
|
|
|
| |
Also add additional overload.
Reviewed-by: Andreas
|
| |
|
| |
|
|
|
|
|
|
|
| |
When premultiplying a color with the opacity, the color's alpha channel
was not set correcly.
Reviewed-by: Tom
|
|
|
|
|
|
|
| |
Texture filtering was set before binding the texture, so the gradient
spread was not set correctly.
Reviewed-by: Tom
|
|
|
|
| |
Reviewed-by: Tom
|
|
|
|
| |
Reviewed-by: Tom
|
|
|
|
| |
Reviewed-by: Tom
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added a QGLContextResource class which can be used internally in Qt
for sharing resources between contexts. The QGLContextResource is a
hash map where the context is used as 'key', and the resource is the
'value'. All the sharing contexts point to the same resource, and the
resource is automatically deleted when it is not referenced any more.
Now, the shader manager uses the QGLContextResource class.
I also added a pointer to a struct in the QGLContextPrivate class. The
struct is shared between all the sharing contexts and is deleted
automatically. Currently, the struct only contains the resolved OpenGL
function pointers.
The shared context register code has been simplified.
Reviewed-by: Tom
|
|
|
|
|
|
|
|
|
| |
Inheritence of fill attributes was implemented by copying attributes
from the parent node. This approach wouldn't work if the node is
referenced by a 'use' element. Now, only the fill attributes which have
been explicitly set are applied on the painter while drawing.
Reviewed-by: Tor Arne
|
| |
|
|
|
|
|
| |
This gives a 5% improvement in performance by avoiding iterating over
the contents more than once.
|
| |
|
|
|
|
|
|
| |
Avoid calling functions that may have other side effects, like
QString::utf16(). Use pointers whenever possible when iterating over
the string.
|
|
|
|
|
| |
Use qt_nameprep after all since it's extremely fast for ASCII only and
it does in-place replacement.
|
|
|
|
|
|
|
| |
Since we're going to do nameprepping anyways, avoid the lowercasing
step at the function entry (and thus, one extra temporary). The
nameprepping step is also faster than QString::toLower for the ASCII
case.
|
|
|
|
|
|
| |
Unfortunately, I can't do it all inline because the punycode encoding
and decoding requires reading the source several times. (Maybe the
decoding can be done with some effort in the future)
|
|
|
|
| |
This will allow to do less allocations in qt_ACE_do.
|