* ... and adjust all callers
* Remove NumberFormatImpl: we rely on ICU to provide this and it can be
fully wrapped into the C++ file. The class was a stub anyway.
* "Monetary" format is included in NumberFormat for now. There may be a
more generic solution to handle monetary and BTimeUnitFormat (and other
arbitrary units)
* Harmonize API for all B*Format to take an output BString by reference
as the first parameter,
* Move the FormatTime methods from BLocale to BTimeFormat
* Adjust all callers for BTimeFormat, BTimeUnitFormat and
BDurationFormat.
* Move relevant parts up into BFormat so other format classes can use
those
* Adjust BDurationFormat and BTimeUnitFormat for the changes
* Remove the "default" date format, it is better to keep only a default
locale and let applications create B*Formats from it as needed.
* Creating a B*Format without arguments to the constructor now
configures it for the default locale, which allows for easy use in
standard cases (formatting something with the current language and
format)
* Creating a B*Format is potentially an expansive operation, it is
advised to keep the instance around and reuse it whenever possible.
However it must be "refreshed" when the locale changes, for apps which
supports that, since it keeps a copy of the language and formatting
convention, rather than a pointer to the locale as it did before.
* MarkAsInvalid is used to enable or disable the mark
* The B_INVALID BControlLook flag is used
* invalid BTextControls are drawn with a red border.
* You ar encouraged to let the user know more precisely what's wrong, by
showing an helpful error message next to the control or in a tooltip.
* BDate setters don't perform any validation, use with caution.
* BCalendarView setters do perform validation checks, and will adjust
the day so it fits the requested month or year.
* Add tests for the BCalendarView setters.
* Add setters for the language and formatting conventions
* Add shortcut getter and setter for the date format
* Use those in the locale roster to make the BDateFormat actually use
the system preferred language and format.
* Applications can also use this to extract specific information from
the system format (eg. set date format to "LLLL" to extract month
names), or define specific formats more easily (eg. for parsing and
generating e-mail headers or HTTP cookies).
* Use a reference rather than a pointer for the output string, removing
the need for NULL checks (which were missing, anyway)
* Adjust callers to that change
* Add new Format variant taking a BDate argument
* There is a little code duplication. This will be moved to BFormat once
the time and datetime formatting is also moved out of BLocale
* The way to create a BDateFormat from a BLocale is still open for
discussion. I'm undecided between making BDateFormat a member of
BLocale, or adding a BDateFormat(const BLocale&) constructor.
* Adjust all users of the API.
* Move default context management to BUrlRequest since some code
(including the testsuite) bypass the BUrlProtocolRoster.
* Introduce proxy host and port in BUrlContext
* Have BHttpRequest use the proxy when making requests
This reverts commit 34dbbb65fd.
Instead, we can remove thos from HaikuBuildCompatibility and things will work fine, unless one try t build Haiku on BeOS (this isn't
supported anymore) or a very old Haiku which esdon't have those.
Pawel changed the implementation but I see no reason to make those available only from C++, so it must be an oversight.
Fixes building Haiku on Haiku which otherwise hits a mismatch in build compatibility headers.
If GCC knows what these functions are actually doing the resulting
code can be optimized better what is especially noticeable in case of
invocations of atomic_{or,and}() that ignore the result. Obviously,
everything is inlined what also improves performance.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
- This allows a BMediaDecoder (e.g. FFMPEG Plugin) to communicate back format
changes to its clients.
For a more thorough explanation and discussion see haiku-development mailing
list: http://www.freelists.org/post/haiku-development/Request-for-protest-Media-Kit-Extend-media-header-struct
- Backwards compatibility is taken into account and preserved by reducing the
relevant _reserved[] fields.
- Code changes that will actually make use of these extensions are due for the
following commits. As these structure extensions affect several Haiku
components (e.g. media_server, MediaPlayer, etc.) and third party apps (e.g.
StampTV, etc.) I refrain from committing them in one batch with this commit.
This should make it easier to track down bugs originating in this code
change.
(cherry picked from commit 806b6888d2dcf84b4934f8f137a48d3381864d1c)
* Remove unneeded field fOutputHeaders and convert it to a local for the
only method that uses it,
* Don't return EOVERFLOW when flushing data from ZLib (the ZLib
decompressor returns this, but zlib docs states that this is NOT an
error condition).
* Replace unneeded temporary BNetBuffer of fixed size with BStackOrHeapArray.
Double checked BeOS R5 & Haiku R1/A4 and BTextView should be 356
bytes, somewhere since then we've added 4 bytes. So, this commit
reduces the class size from 360 back to 356 by removing 1 reserved
int32 (instead of 2).
I believe the class size changed in hrev46798 as a result of adding
2 bools (1 byte each padded out to 4 bytes).
Sorry for the noise.
In hrev46796 I added two new private methods: _PreviousLineStart(),
and _NextLineEnd() which increased the size of the class breaking
binary compatability because I forgot to decrement the reserved array.
This commit decrements the reserved array restoring the class size
to the original size fixing the binary compat issue.
Thanks Axel for noticing.
The order is updated so the virtual methods appear in the same order
that they did in BeOS R5 with methods new to Haiku added to the bottom.
Perform() moves up, all other methods move below GetDragParameters(),
the last virtual method in BeOS R5's TextView.h.
* receiveEnd is set in a different place in case of chunked transfers,
which would cause the decompressor to never be flushed.
* In the case of chunked transfers, we call Flush() without any input
data (to flush only whatever is remaining in the decompression buffer).
This causes ZLib to return Z_BUF_ERROR which is translated to
B_BUFFER_OVERFLOW. This is a non-fatal error and is expected behavior in
that case. Don't handle this as an error, and do use the extracted data.
Fixes various cases of missing the last chunk of a page (pastie.org,
Google search results, and more).
Accidentally renamed these in the header, rename them back to
match the cpp file. These param names might not be very good but
they match the struct variable names. They are private methods
anyway. No functional change intended in either commit.
Besides that this is a nicer interface, it allows us to get a the HPKG
header as a side effect of initializing the reader, thus preventing
seeking backward in the file. This makes "package recompress - <file>"
work.
Until now we always declared in the HPKG header that the package file is
zlib compressed. For uncompressed files we would just store all
individual chunks uncompressed. Now we handle completely uncompressed
files slightly differently: We don't write the redundant chunk size
table anymore. The size savings are minor, but it makes the uncompressed
format read-streamable which may be handy.
* PackageFileHeap{Reader,Writer} as well as Package{Reader,Writer} and
their implementation and super classes do now internally use a
BPositionIO instead of a FD to access the package file. This provides
more flexibility needed for features to come.
* BPackageReader has already grown a new Init() version with a
BPositionIO* parameter.
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.
