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.
* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.
Some changes to the API for notifications.
* Don't go through be_roster to send a notification, but use Notification->Send() instead.
* Rename App to Group to make the purpose clearer
And some changes to the notification code itself:
* Use the Notification class as the way to convey informations about a notification. Allows easier extension of this class
* Code cleanup
* Use of the layout kit for the notify window
Unfortunately, the latter part clashes quite a bit with the changes I already did to the notification window, so it's now quite broken. Working on that next, but I wanted to separate that work from the patch ...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43114 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixed size flag at once. Not sure if this can be merged into one of the
existing GetInfo() variants without breaking binary compatibility.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40374 a95241bf-73f2-0310-859d-f6bbb57e9c96
in BMessages. Also added type codes for them in TypeConstants.h. Closes ticket
#6302. Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37511 a95241bf-73f2-0310-859d-f6bbb57e9c96
unarchiving protocol to support archival of arbitrary object graphs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37431 a95241bf-73f2-0310-859d-f6bbb57e9c96
cosnt BString& instead of const char* could potentially save copying the string,
although in most use cases, it will probably ammount to the same thing. It may
provide more flexibility later on, like for example when BString knows its
encoding or something similar. Removed superfluous second version of
AddOnClickRef().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36958 a95241bf-73f2-0310-859d-f6bbb57e9c96
- No more manual memory management.
- Make it clear who keeps or releases ownership of arguments passed.
- Copy icon, arguments and entry_refs.
- Do not expose implementation details (What do the BLists contain?!).
- BRoster takes const BNotification& and bigtime_t timeout.
* BRoster::Notify():
- Proper error handling.
- Fixed documentation.
* Adjusted notify:
- Renamed fOk to fHasGoodArguments.
- The "const char*" members were really "char*" members (self-managed).
- free() is NULL-safe.
- fRefs contains BEntries, so passing void* to delete does no good.
- Adjustments to the changed API.
- Coding style fixes.
* notification_server:
- Adjustment to the new type for timeout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36952 a95241bf-73f2-0310-859d-f6bbb57e9c96
#1245. There are some TODOs outlined in the ticket, but they will be much
easier to review as individual patches against trunk, versus as a new version
of the huge patch.
I've messed a lot with src/servers/notification/NotificationsView.cpp in order
to resolve a crash I was getting when testing this thing (rewrote line
wrapping). I've also replaced the icons with the one that zuMi did long ago.
Thanks, plfiorini, for working on this code as much as you did!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36949 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Repurposed the FollowLink cursor as CreateLink cursor.
* Created a new FollowLink cursor based on a design by Justin Stressman, thanks!
It compiles and I proof-read the commit, otherwise I didn't test, yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35922 a95241bf-73f2-0310-859d-f6bbb57e9c96
takes such an id.
* Reused the existing mechanism to to have hardcoded tokens for the system
cursors, i.e. removed cursor_which enumeration from ServerProtocol.h and
used BCursorID where cursor_which was previously used.
* Reworked CursorManager.h and CursorSet.h accordingly and removed some methods
that where intended to replace system cursors with client cursors, since
those would break the reference counting and forget to maintain the cursor
list.
* Replaced the cursors in CursorData.h/cpp with the new ones I just designed.
* Removed HaikuSystemCursor.h and HaikuLogo.h from the source, as those are/were
no longer used.
I hope I will not get too much beating for this one... :-) I know the new
default cursor is slightly larger, but I believe the old one was just too small.
Also I noticed that the cursor may be slightly too dark, at least the old one
seems noticeably brighter when compared side by side (the new one has a slight
gradient). That is something I may correct at least. Otherwise I hope nothing
is broken, I've tested in QEMU and so far everything works as intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35782 a95241bf-73f2-0310-859d-f6bbb57e9c96
John Scipione