Allow to easily access the alert icons and anything that's added to app_server
resources.
Fixes#10887.
Convert BAlert, Debugger AlertWithCheckbox and Keymap ModifierKeysWindow
to make use of it, removing the duplicate code to locate app_server
resources.
The resources are initialized only once (per application), so there is no need
to reload them for every access to the icons.
In the ticket there is discussion about putting this in BControlLook,
but I think this should in fact be moved fully into app_server with
special drawing commands for well-known icons. That would avoid loading
and rendering the icon on the application side to then send it to
app_server (especially in remote_app_server case)?
In any case, this simple API can serve as a base for applications to
use, and we can change how it is implemented later on.
Change-Id: Id370526ae5cf165cfb8bc277bc8a7f46c26f542d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6463
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Update \since to BeOS R4. This method definitely predates Haiku,
it has existed since at least R4.5 despite not being documented.
Document B_NAME_TOO_LONG return value.
Change-Id: I0816e4e89ae2710f6123e10ee41145a83fdca66f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6363
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Clarify what information BWindow::WorkspacesChanged provides
* Clarify when BWindow::WorkspaceActivated is called
Change-Id: Ifcb041bcf67db1ee5c1c514a2b97baa49f8c4dcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6257
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Following some IRC discussions, it seems useful to have this written
down somewhere.
Change-Id: Ic02686948d989bff2fa671a3831ba5aed1515d25
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6085
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Separate the "interface specification" into multiple individual, shorter
pages. Also update some outdated parts and replace references to
OpenBeOS with Haiku.
Change-Id: I86baa9a78c5f7a8a3c4c7aa3ac2992714afecae6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6084
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The table of content of the top level will include everything that's up
to 2 levels down. Currently this results in a lot of pages and no clear
organization.
Extra index pages allow for more intermediate levels, resulting in less
things being listed in the main page. This way the organization is a bit
clearer, even if this is still not great due to many missing pages and
sections in the documentation currently.
Change-Id: I5bbdd96b3c2ff3334b9ad1b86fd9e7fb00fd63a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6008
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There's currently no way for an application to convert between view and
drawing coordinates with a drawing states stack without keeping track of
all the transformations itself, which is not very convenient for helper
or library functions.
Handle other spaces too, for good measure.
Change-Id: Ic8404a1c111e273fff1eebf2f9f59f58246b796c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5775
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The overall design does not deviate much from my proof of concept [2] and that still makes a good read to
understanding the overall architecture. If you want to get a sense of how it is built up, the API comes with
full doxygen documentation for the public API [3], and I have also done a PoC change for HaikuDepot which is
useful as an illustration on what the impact for the user of the new library is. [4] There is also a test suite
that may give some insight into the day to day ergonomics of the API [5].
The current state is that I am fairly confident that many HTTP requests will actually work, but I do expect
rough edges with a protocol with this many diverse implementations. There is also a list of features yet to be
implemented on Trac [6]. Additionally, I still want/need to do performance testing.
The goal of merging the kit right now is to start making it available for more uses, and through that also give
a chance to shape its future. There are also some design decisions that need review, most notably I expect some
discussion around the uses of C++ 17 idioms (like std::optional and std::string_view) and around the use of
exceptions for error handling.
The impact of merging right now should be near zero: the netservices2 kit lives in its own header space, and
builds into its own static library (libnetservices2.a). It is not yet used in any of the apps in our
repository.
The branch does remove the deprecated services kit from the libnetapi.so library, though it leaves
libnetservices.a intact. After our previous announcement to remove it after beta 3, this should be expected.
[2] https://github.com/nielx/haiku-netservices-rfc/tree/exceptions
[3] https://git.haiku-os.org/haiku/tree/docs/user/netservices?h=dev/netservices
[4] https://review.haiku-os.org/c/haiku/+/5692
[5] https://git.haiku-os.org/haiku/tree/src/tests/kits/net/netservices2?h=dev/netservices
[6] https://dev.haiku-os.org/wiki/Development/NetServices2
Change-Id: I5d0b7e2619699f39a2506588417b57391f0f5cc2
These were not maintained here, merely mirrored from the Userguide Translator,
and rather infrequently at that. But as they were built with Haiku,
that meant new versions of these packages were built every hrev,
which meant a lot of wasted space and bandwith for updates.
Now there is a separate "userguide" repository which will collect the
files exported from the Translator, and recipes at HaikuPorts to build
the packages, instead, so we can delete these files from this repo.
This smart pointer is designed to help with putting some explicitness and
safety around the case where someone will use their own object that implements
the BDataIO interface to store the body of a network request. By default,
BDataIO objects do not require or enforce thread safety. Since accessing these
unsynchronized objects between two threads is undefined behavior, it should be
explicitly discouraged.
The BExclusiveBorrow/BBorrow smart pointer helper helps solve that by enforcing
the limitations on using an unsynchronized object in two threads. When used
correctly, there is a runtime check on incorrect use by the developer. This
should help write better code.
The design is based on shared_ptr, including having an admin block akin the
control block, that manages the internal object. This type-erased admin block
has the advantage that it allows the owner to have a different type than the
borrower. It also handles cases where the lifetime of the borrower is longer
than the owner: the borrower can continue to use the object until they want to
return it, after which it will be cleaned up. This will make it possible to do
some fire and forget pattern in the network services kit, where someone may
just wants to create a file and borrow it to the network request, and care
about further processing the file in the future.
Change-Id: Ie9b7e7472c868b60f663b4db4fa449d421e447eb
These allow for additional messages about the progress/status of the request.
For now, the messages are sent unconditionally, though it may be reasonable to
in the future switch to sending them only when enabled.
Change-Id: Ic45a0055037af02c689494fa5ce0acd03592ad7e
This fixes a bug in the HttpAuthTest, and in general, moves responsibility of determining
the shape and size of the content to the right place.
Still to do is to fix the case where there really is a variable length content. This will
now probably error out as a connection closed error.
Change-Id: I13c20028e834cc9af8c7bc1d7d7613bf60838e64
This change allows the user to control how many concurrent request can be done
per session. This is going to be helpful to running the tests as well; they were
all fired up in parallel, which sometimes leads to our test server refusing a
connection.
Change-Id: I4f1f40b28b8e0199ea5589b36cd8d00ecd849a63
The corresponding Trac wiki page can be deleted once this is merged.
Some of this information is a little out of date, help is welcome on
updating it.
Change-Id: I9157b140bcb5de3fed3c95d994745b5a1cbee1f6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5477
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The integration PostTest has a basic test that the expected messages are sent and
have the expected data fields. The gist is documented in book.dox.
To do are the messages around SSL. However, that functionality is also not
implemented yet, so there is nothing to send.
Change-Id: Ib8f36ed32f9854d643d8256338b71af7067059f0
In the old service kit, the Accept header was automatically set. However, it is
not a required header. This removes the default value and the protection against
setting it manually.
Required to make HaikuDepot work.
Change-Id: Ic589bfc5829db25915b67f2a13b6c2436c053e25
* This has been floating around on trac forever. We should formalize
these steps to help future Haiku releases to be successful.
Change-Id: I5881e27a23e66a18539d04c5977593a827f8fcef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5441
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit introduces a simple thread-safe ring buffer implementation
based on top of BDataIO. The main use case for this class will be to
implement shared buffers between threads for the upcoming refactoring
of Services Kit.
Change-Id: I526bc044b28c91496ad996fabebe538e75647f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2966
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
