enable to check whether a shutdown process is in progress.
Change-Id: I8efdddb3caa80e9fd188f202b6e92a888a7608e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Define a new message, B_KEY_MAP_LOADED, that is broadcast to applications by
the Input Server each time a key map is loaded. This allows apps that cache
key-map data to know when their copy has become stale.
Change InputServer::HandleGetSetKeyMap() so it returns an error in the event
loading even the system (fallback) key map fails.
Change-Id: Icc6c884f695ca59c687d83c680bb2fb467dd90cc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1741
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I need this to use loopers in WebKit, which spawns threads and expects
to be able to turn them into event loops later on.
This is the pattern already used in BApplication, we may as well make it
available elsewhere.
Change-Id: I5939ca89d33cb3bcc92567b302c2038d976af598
Reviewed-on: https://review.haiku-os.org/735
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Notifications preflet:
-Use sliders instead of text fields for width and timeout
-Remove icon size choice (mini icon looks horrible)
-Consolidate both "Enable" checkboxes into one
-Fix Revert button, remove Apply button, add Defaults button
-All changes to settings saved immediately
-Live example notification message shown when settings changes are made
-Add setting for individual apps to specify whether their notifications
should be muted
-Remove history list (to be implemented later)
BNotification class:
-BNotification records the signature and name of application that
created it
-New functions to get source application signature and name
Notification Server:
-Notification pop up view layout fixes and bold font size fix
-Remove notifications history from AppUsage class (will be saved in
cache instead)
-Remove vector of NotificationView objects which isn't needed
-Get source application info from notification object, not the received
message which is not reliable
The inseparable changes necessary to support live color updating across the
system in a sane, safe, and performant manner.
BView gains:
HasSystemColors()
HasDefaultColors()
AdoptSystemColors()
AdoptParentColors()
AdoptViewColor(BView*)
SetViewUIColor(color_which, float tint)
SetHighUIColor(...
SetLowUIColor(...
ViewUIColor(float* tint)
HighUIColor(...
LowUIColor(...
DelayedInvalidate()
BWindow gains a simple helper method:
IsOffscreenWindow()
BMessage gains:
AddColor()
FindColor()
GetColor()
HasColor() * allegedly this API is deprecated, but I implemented it anyway
ReplaceColor()
SetColor()
Previous private ColorTools methods are made public and moved into GraphicsDefs:
mix_color, blend_color, disable_color
These are fully compatible with BeOS dan0 R5.1 methods and are just code cleanup
of BeOS example code under the OpenTracker license.
In addition, four new colors are created:
B_LINK_TEXT_COLOR
B_LINK_HOVER_COLOR
B_LINK_ACTIVE_COLOR
B_LINK_VISITED_COLOR
These changes are documented in their proper user documentation files.
In addition, due to a history rewrite, B_FOLLOW_LEFT_TOP has been defined and
used in lieu of B_FOLLOW_TOP | B_FOLLOW_LEFT and is included in this commit.
On the app_server side, the following has changed:
Add DelayedMessage - a system by which messages can be sent at a scheduled time,
and can also be merged according to set rules. A single thread is used to service the
message queue and multiple recipients can be set for each message.
Desktop gains the ability to add message ports to a DelayedMessage so that
said messages can target either all applications or all windows, as needed.
Desktop maintains a BMessage which is used to queue up all pending color changes
and the delayed messaging system is used to enact these changes after a short
period of time has passed. This prevents abuse and allows the system to merge
repeated set_ui_color events into one event for client applications, improving
performance drastically.
In addition, B_COLORS_UPDATED is sent to the BApplication, which forwards the message
to each BWindow. This is done to improve performance over having the app_server
independently informing each window.
Decorator changes are live now, which required some reworking.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
* BApplication can now take the job to quit a BLooper at
the application quit. It's rejecting requests from windows too.
* BMediaRoster is using now this service in conjunction with the
MediaRosterUndertaker.
* The BeBook specify that we should have a valid BApplication
before to instantiate the BMediaRoster. While in theory we should
add a debugger call when this situation happens, in pratice this
might lead to more problems. For example libraries might use the
media_kit and create a BApplication object, but they aren't
applications, this is a design problem. So I decided to replace it
with a TRACE call for the moment.
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>
* 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).
It allows to launch the app, but keep its main thread suspended instead
of automatically resuming it.
Also add appThread argument which allows to retrieve the main thread of
the launched team.
* BRoster now allows settings a "no-registrar" mode that is currently
only honored in _LaunchApp(), though.
* Job::Launch() is now using this, which also allows launching
applications by signature (ie. if the job name matches the
signature, you can omit the "launch" option).
* This will be heavily inspired by Apple's launchd, as well as
systemd -- for now it really doesn't do a whole lot, though.
* What works so far: the configuration files are read, parsed, and
the jobs created.
* The jobs are even initialized, and their message ports created.
* BApplication now retrieves a previously created port from the
launch_daemon for use with BServer.
* Only the registrar actually uses this for now.
* Added an extra looperName argument to the private BApplication
constructor that BServer is using.
* This is now used to fix the ugliness that gave the registrar
a different looper name, and even saves a string comparison.
* Changed the way the attributes are written to make sure that everything
that can be written once is in fact written just once.
* The rename code in BMailProtocol::_ProcessFetchedHeader() was broken,
and caused the hang of the last commit.
* This was never implemented and no one noticed until now.
* A default value for a pointer doesn't make that much sense anyway, so
using the FindPointer method is fine.
Keep the brief description as a regular comment above each public method.
Leave the docs of private methods.
Some variable renaming mostly because of abbreviations.
Add documentation for all the public methods and app_info members and defines
that didn't have docs in the cpp file.
Can be requested/stopped via BPackageRoster::{Start,Stop}Watching().
The notification message has the what code B_PACKAGE_UPDATE and contains
fields "event", "location", and "change count".
No functional change intended.
Focused on documented classes only.
* Update copyright information.
* whitespace fixes.
* pointer style
* Rename some variables, msg => message, form => what
* Need consistent variable names to make documentation easier,
allows us to use \copydoc or \copydetails instead of repeating
ourselves over and over again.
* This is primarily a service method for ports of widget tool kits
that require single-threaded GUI. DispatchExternalMessage() calls
DispatchMessage(), but also sets fLastMessage, so that
[Detach]CurrentMessage() work correctly. This allows to detach a
message in DispatchMessage() when called from the window thread,
add it to a global queue, and later process the queued messages in
a different thread that calls DispatchExternalMessage().
* BLooper/BWindow: Make sure fLastMessage is accessed only when locked.
This allows to reuse BMessenger objects for different targets, or to
recheck validity after initial creation. With that one can use the same
BMessenger after launching an application that was previously not found
valid for example.
* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.
As there aren't any more generic meta data containers inside BKey,
there's no real way to distinguish different instances with the same
identifiers. This may be added later, for example the same index system
as used in BMessage could apply.
The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.
The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.
* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.
