When a translator is uninstalled, BTranslatorPrivate::_RemoveTranslators is
called. This method used to unload the image containing the translator after
calling Release() on it resulting in several problems:
- If the translator was still busy, e.g. translating something while being
installed, it crashed since the image was unloaded even though its refcount
was larger than 0.
- Applications using code from one of the translators (e.g. its config view)
would crash when the translator is uninstalled (this is bug #12005).
This problem is now fixed. The roster keeps track of all translators whose
image it manages (even if the translator was already removed from the roster).
It also keeps a refcount to all images. When a translator's refcount drops to
zero and it belonged to a roster at some point, it does not delete itself, but
notifies the roster that it is ready to destruct, which then removes it from
the roster if the translator is still in it, destroys the translator, decrements
the refcount of the image and if the new refcount is zero, unloads the image.
All of this is done in a message handler, since if the translator called
TranslatorDeleted like before, the unloaded image would be referenced when
the stack is walked up.
Finally, the DataTranslations preflet is required to Acquire() the translator
whose config view it is showing, because otherwise its refcount could be reduced
to 0 and the image unloaded. BTranslatorRoster now enables users to acquire a
translator by ID. By the time the translator has to be released, it might not
be part of the roster anymore though. Since BTranslatorRoster tries not to give
out raw pointers to the translators it manages, users who acquire a translator
through a roster now are given a BTranslatorReleaseDelegate, which allows for
releasing the BTranslator exactly once and then self-destructs.
Signed-off-by: Axel Dörfler <axeld@pinc-software.de>
* Allows you to view and delete cookies.
* The list of domains is hierarchized and collapsed to minimize the
number of empty entries
* All cookie parameters are shown for each domain: name, path, value,
expiration date, and known flags.
The cookie jar used to be locked whenever an iterator was instanciated.
This didn't work well when using several iterators in the same thread,
because the BLocker then allows all of them to access the list
concurrently.
Rework the locking code to use a more fine grained approach, where the
cookie jar is only locked temporarily by methods which require it. These
methods are the ones which get and put new domain-lists in the jar, as
well as acquiring the locks on the domain-lists.
Each domain-list in the jar is locked using a read/write lock as before.
This means there can be many requests getting cookies for the same
domain in paralel, but only one at a time is allowed to set new cookies.
The iterators keep domain lists they need to access read-locked, as long
as they iterate the cookies for that domain.
A limitation of this approach is that deleting a domain-list when it
becomes empty is difficult. We can live with this, however, the
iteration still works (it just skips empty lists), and the empty lists
will not be stored or restored when archiving the cookie jar.
* _SetLaunchStatus() doesn't allow to set the status to B_NO_INIT
(and rightly so).
* Therefore, we now reset it manually in Job::TeamDeleted(). This
fixes restarting things that once ran on demand.
* Also update the port message when the default port changes.
BMessageValueNode:
- When resolving a pointer field, look up the type by the fully qualified
name, as that's how it winds up being stored in the lookup map. Also,
due to gcc omitting the unspecified parent type on such pointers entirely,
looking them up by base type name this way won't work anyhow.
* Since the last change, the user launch_daemon would talk to the
registrar again.
* However, this also caused BRoster::Launch() to preregister the app,
which messed up our preallocated port.
* BRoster::Private::Launch() now allows to get the port that the
registrar created in such a case, and the launch_daemon will now just
use that one as default port.
* This lets us talk to the Deskbar again, and should fix #12455, as
well as #12454 (again).
Tested with a 5MB image, seems to work.
There seems to be an issue with too long names though, or possibly names with spaces.
Also, technically it supports FAT12,16 and 32, so it should probably be renamed
in the interface.
Didn't check how to declare support for more than 1 partition types either.
* These are the standard types used in HTML5 media, tell everyone that
we can handle them.
* A few more green items in html5test.com, no extra points since none of
the formats are mandatory however.
* When using a proxy, HTTPS connexion must still go directly to the
target website. The proxy can then act as a TCP stream relay and just
transmit the raw SSL stream between the client and website.
* For this, we ask the proxy sending an HTTP request with the CONNECT
method. If the proxy supports this, we can then send anything as the
payload and it will be forwarded.
* Untested, as the network here in Dusseldorf doesn't let me use a
proxy.
ticket : #10973
* BView::TranslateBy(), BView::ScaleBy() and BView::RotateBy()
allow to conveniently modify the current affine transformation.
This makes it unnecessary to first read the current transform,
modify it, and then set it again.
Uses the new Pre...() methods of BAffineTransform.
* Also, remove setting the transform "through" to the BView even
while recording a BPicture, as this now results in transforms
being applied more than once.
* The existing methods TranslateBy(), ScaleBy() and RotateBy()
transform the transformation. For a transform A, a point p,
and the temporary transform B (being applied by the methods),
this results in p' = B*(A*p) = (B*A)*p
This is not necessarily the desired result. Suppose A is a
translation and B a rotation, added by RotateBy(). Then B*A
means that the translation itself is rotated, so B moves the
coordinate origin itself, by rotating it around the original
origin of the coordinate system (top left view corner).
If we want to translate and then rotate around that *new* origin,
we need to multiply the transforms the other way around: A*B.
Three new methods PreTranslateBy(), PreScaleBy() and PreRotateBy()
implement this. They are later used as a base to add translatation/
scaling/rotation methods to BView which behave in the expected
ordering, similar to other graphic APIs.
* Add new clipping API for rectangles (ClipToRect, ClipToInverseRect)
and shapes (ClipToShape, ClipToInverseShape)
* Works with affine transforms and automatically switches from fast
region-based clipping to alpha-mask based clipping as necessary.
* Always self-intersecting, i.e. no state push required to further
narrow down the clipping region. All of the 4 new methods can be
mixed in any order.
* Add IsDilation() to BAffineTransform and Transformable which check
whether the transform is a dilation, i.e. consists of only
translation and/or scaling
Conflicts:
src/kits/interface/PicturePlayer.cpp
src/servers/app/ServerPicture.cpp
In addition, the following files were also adapted to master branch
BPicture changes during the merge:
src/kits/interface/PicturePlayer.h
src/servers/app/PictureBoundingBoxPlayer.cpp
- In some contexts, VariablesView doesn't have an associated thread
and stack frame, which would lead to a potential crash when resolving
expression nodes.
- Requesting expression evaluation from the top level menu now
invokes an expression eval window, rather than the past prompt.
ExpressionPromptWindow:
- Simplify, as it's now strictly used to add persistent expressions.
