When BSocket::Read() returns 0, it was treated as
a finished transfer. This is OK when we don't know
the content length, but when we do, there is no reason
not to bubble up the error. Return B_IO_ERROR in this
case.
Change-Id: I68801dbbb85bcfd2e7aa68fd6a9ded6304e82b19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3621
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Somehow B_CANCELED doesn't seem to convey the correct
meaning. Using B_IO_ERROR will also fit to the recent
changes in the Package Kit and will trigger a re-try of
package downloads.
Change-Id: I58c4d4faa705e6519e0ff9ec7c4654a6151e5486
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3635
Reviewed-by: Adrien Destugues <[email protected]>
Package files to be committed may already exist in the packages folder,
there is no good reason to fail the transaction. These may be packages
which are not activated, or there may be other reasons. While I have
not investigated how this situation may form, I don't see a good reason
to spend the time. Simply compare the contents of the existing file
with the file from the transaction, only fail if they are different.
Change-Id: I2a574df38385c8dead8bac2beace94436d43760a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3597
Reviewed-by: Adrien Destugues <[email protected]>
Since BeOS had no anti-aliased drawing except for text, it didn't
matter whether drawing diagonal lines (for example) in B_OP_COPY
or B_OP_OVER. Applying the meaning of B_OP_COPY strictly to everything
else would have broken pretty much every existing BeOS, resulting
in broken drawing for anything but straight lines and rectangles.
The solution was to treat B_OP_COPY just like B_OP_OVER *except*
for text rendering, where we could be compatible with the BeOS
behavior. Nevertheless, one can sometimes observe apps using B_OP_COPY
where they /should/ be using B_OP_OVER for rendering text, resulting
in white edges around the glyphs where the actual LowColor() does not
match the current background on which the text is rendered.
There is however a problem when glyphs in a string overlap. Some
fonts have overlapping glyphs by default (handwriting, etc). With
the LCD sub-pixel filtering, this problem is visible even in fonts
where glyphs don't overlap normally, for example 'lt'. The leftmost
pixel of the 't' is smeared due to the filtering and produces an
almost transparent pixel which is rendered (using the low color as
the background) on top of the 'l'. To fix this, one would have to
render the string into an alpha mask buffer first, and then blend it
all at once using B_OP_COPY. This however defeats the point of
B_OP_COPY, which is to be a performance optimization. So instead, I
opted for the solution that is already in place for everything else,
which is to make B_OP_COPY behave like B_OP_OVER. For the case that
this would have produced a difference, i.e. rendering with the solid
high color, one needs to clear the background using the low color,
before rendering text, or it would have looked broken. So in practice,
there cannot be a difference.
Change-Id: I4348902ae754507f1429e0a9575f03d8ecbce333
Reviewed-on: https://review.haiku-os.org/c/877
Reviewed-by: Adrien Destugues <[email protected]>
The test app currently shows a number of problems in text rendering
* Above a certain font-size, there is no glyph caching, which
also means there is no sub-pixel filtering. It is actually
the same problem right now for all vector-drawing. It uses the
sub-pixel rendering pipeline, but without any filtering.
* This test feels very sluggish. Something is going on which seems
to be very unoptimized. To be observed when resizing the window
and causing redraws.
* Overlapping glyphs are handled wrongly in B_OP_COPY mode. The
problem is that glyphs are drawn one at a time, but B_OP_COPY
also draws the background color. In case some pixels already
drawn with the text color by one glyph are drawn again by the
next glyph, but with the background color, then it looks like
gaps in the text. This problem has always existed. With the
double filtering that was recently fixed, it was just especially
visible, since, due to the smearing, it was much more likely that
there were extra background pixels at the left side of glyphs.
(Right side, too, but without visual effect.) Of course not
completely transparent pixels, those are not drawn, but almost
transparent pixels.
Change-Id: If590a4c93983c5a3ff0772c19074c408be8e1e74
Reviewed-on: https://review.haiku-os.org/c/871
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The currently included version of libfreetype already has the LCD
subpixel filter turned on by default. With the switch from my
"averaging filter" back to Adrej Spielmann's filtering, there was now
another filtering being done on top of what Freetype already does.
There also seemed to be a problem with the left edge of cached
glyph bitmaps, which I didn't bother to look into. The visual result
of this change is that text looks much crisper, and the display
bugs at touching glyphs is gone.
On the other hand, LCD sub-pixel rendering is still turned on
globally, i.e. for all vector drawing, and for uncached rotated
text. The Freetype filtering is not applied there. This problem did
not exist in my "average filter", since it happened at the scanline
rendering level, not only for cached glyph bitmaps. It is however
not a regression introduced by this commit. It needs to be fixed
separately.
Change-Id: If93c2b85ed479670e6679227984fd8d9f77c11f6
Reviewed-on: https://review.haiku-os.org/c/855
Reviewed-by: Stefano Ceccherini <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().
Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <[email protected]>
When recording into a BPicture (ServerPicture, actually), one cannot
simply record the commands only, when the drawing itself would modify
state. This affects all drawing commands that change the pen location.
Therefore it is necessary to have a way to "dry-run" drawing a string
in order to know the pen location that would result. This is what
these two new methods help achieve.
Change-Id: Ic399a5513f18c12c16c0ab10a55e768c1b30e4e0
Reviewed-on: https://review.haiku-os.org/816
Reviewed-by: Rene Gollent <[email protected]>
When changing the font state, a uin16 mask at the beginning of the
commands encodes which font parameters are transmitted in the link
data. Return this mask, so that one can know what parameters have
changed in the DrawState's ServerFont.
Change-Id: I52a9a665aac8eb0e6505193eba32c4b137846c78
Reviewed-on: https://review.haiku-os.org/814
Reviewed-by: waddlesplash <[email protected]>
In preparation for implementing Undo/Redo support, we need _Insert() to
take a TextDocument instead of a BString, CharacterStyle and ParagraphStyle.
When a chunk of the TextDocument has been removed, we need to be able to
Insert() that as part of the Undo operation. Not well tested, but typing
still works.
Added TODO about which data the TextChangedEvent should have in order to
know how to respond in the TextDocumentLayout. For now, update all paragraphs
in the layout, add new ones as necessary, and remove the ones we have in
excess by using Invalidate().
Make sure that the caret starts blinking half a second after it last moved.
The previous solution using Pulse() had a number of problems:
* The caret could be hidden during moving it or during typing. It would then
be shown again very soon after, i.e. when typing the next character or
when moving it to the next offset. But it looks bad anyway.
* When the caret stopped moving, it started blinking a random amount of
time afterwards, getting back into the rhythm of Pulse() messages.
However, starting to blink a constant time after the caret last moved,
looks much more satisfying.
... and invalidate based on TextChangedEvents. I am not yet sure whether
TextChangeEvent needs separate counts for removed and changed paragraphs.
It is most likely not yet correct and may either update too many paragraph
layouts or miss updating some at the end.
TextDocument:
* Moved implementation of Remove() and Insert() into private methods.
* Reimplement all public Insert() methods and Remove() on top of Replace().
* In Replace(), send a TextChangedEvent. Added TODO for sending a
TextChangingEvent, although at this point, I am not sure if it will be
needed at all.
Basically synced the code with what I did for WIP WonderBrush rewrite.
* Converted to use layouting
* Removed unused liblayout MView cruft
* Removed need for rendering in separate threads in favor of
rendering lazily. The original Colors! rendering was insanely slow
and inefficient, hence the separate rendering threads.
* Some style fixes along the way.
* Some minor bug fixes, too, but these were not actually triggered.
* Renamed selected_color_mode.h to SelectedColorMode.h
Generate bitmap in Draw() lazily. Removed liblayout stuff. Support for
Haiku layout methods. Fixed some bugs with selecting red/green/blue
as fixed values (ticket #10574).
* The name is the static package name. The title is either that name,
or a translated pretty version of the name.
* Adjust package info retrieval to server API changes. Unbreaks package
translations.
This is all work in progress. The plan is to move the code that does any
actual changes to the TextDocument into UndoableEdit implementations, then
emit these edits to interesed listeners. They can then store them to
implement the edit history. If there are not listeners, the edits will
simply be released after they've done their work.
Implemented so far is only the support for storing the edit listeners.
No, not updating packages via HaikuDepot, but a light-weight synchronization
between the system package manager list and the HaikuDepot model. After
installing or removing a package, HaikuDepot performed a very costly update
of all information by basically throwing everything away and reloading it.
Implements #11786.
... in PackageInfoView::SetPackage() and Clear(). The sub-views reference
stuff from the previous PackageInfo instance. If we release the reference
before adopting the new package, the sub-views may still access stuff from
the previous package. For example the PackageActionView tries to avoid
rebuilding the button list and compares previous package actions to the
new actions. Particularily after the package list has been rebuild, we have
only new PackageInfo instances and the PackageInfoView may hold on to a
PackageInfo that is not still referenced anywhere else. Would be a good
explanation for #11785.
Since the package information is refreshed asynchronously, some packages
may fit the current filter parameters. Check for this situation more
generically in the MSG_PACKAGE_CHANGED notification. Before, it was only
done for prominent packages to make them appear in the Featured packages
view. The problem was visible by for example selecting a category and then
refreshing packages. Many of the previously shown packages would be missing
and magically appear when changing filter parameters slightly and back
to what they were.
When trying to find a matching parent item, we cannot rely on cached
pointers to BPackageEntries, since those are re-used per entry level
from the BPackageReader. Instead, we build the package entry path as
a string and store that with the list item.
Removed debug output.
Most changes were in the PackageContentOutliner and its HandleEntry() method
to make it work correctly. The parent entry of a visited entry may not be
the last parent entry, but some other previously added entry. We need a
PackageEntryItem class to also store the BPackageEntry together with the
list item.
Other small fixes.
Let Model::PopulatePackage() have a mode where it forces the update on a
package that has already been populated. Trigger populating from success
code path in RatePackageWindow. Fixes#11638.
If the visible packages list does not contain the currently showing package
anymore after filter parameters have changed, clear the package info area.
This also means that when installed packages are turned off, which means
a package will disappear from the list after being installed, the package
will no longer keep showing in the info area. This situation is less likely
with the change that installed packages will now show by default and the
user has to explicitly turn them off.
Since the fVisiblePackages list in MainWindow is now also filtered by
featured packages, and since the "featured" status of packages is collected
asynchronously, the list needs to be updated in the package changed
notification. Also, the package should only be added to the featured packages
view if it is now in the visible list. Other filter criteria would not be
taken into account otherwise. Fixes#11663
* Renamed the "Option" menu to "Show", removed the now redundant "Show" from
the items in that menu.
* Add an "Only featured packages" item in the Show menu. This item is disabled
as soon as the user types something in the search terms field. Othetwise,
this setting is respected, i.e. one can combine the featured setting with
other settings, i.e. show all featured packages of a certain depot and in a
certain category.
* Added PackageInfo::IsProminent() and removed the respective method from
the MainWindow (which only considered a package prominent if it was not
yet installed).
* "Show -> Installed packages" now defaults to on. There have been complaints
on Trac and I guess rightfully so. The use-cases in which one starts
HaikuDepot and wants to know about installed packages are just as likely
as the use-case where one wants to install new software.
The packages count view centers its label. It therefore needs a full update
on resize. Also optimize SetItemCount() by trying to avoid unneccessary
layout invalidations.
Clicking the thumbnail in the package info area will now open a
window where the full-size screenshot is downloaded and shown. There can
only be one such screenshot window open. Navigating between multiple
screenshots of a package is not yet implemented. Also, no caching, but
this may be OK as it is, since one usually looks at these only once and
doesn't want the harddrive filling up with screenshots.
Show the summary instead of the version. The layout still sucks, but I will
have to implement some kind of row/flow BLayout to get what I initially had
in mind. Another TODO is to highlight the clicked item somehow.
* Rework existing package listener mechanism to report any interesting
changes. Listen for prominence changes in addition to package state.
* Add featured packages to the FeaturedPackagesView when their prominence
is retrived, and also in _AdoptModel().
* In _AdoptModel(), show the featured packages view when no search filters
are active and installed packages are not shown either. Otherwise show
the list of all packages matching the current filtering.
...into MessagePackageListener and OnePackageMessagePackageListener.
The first one doesn't know which package(s) it's listening to. But it
can filter the change notifications now and only react to certain changes.
The second one knows which package it's listening to.
Not yet visible. But the package list area in the main window has a card
layout now and a second (hidden) page for featured packages. Which packages
are visible there will depend on the prominence value from the web-app
and other parameters later (suggestions based on packages already installed
and user-ratings). At the moment, there is no mechanism for updating the
package list when package info is retrieved asynchronously, even from the
cache. Also, the view should switch to the list when searching and perhaps
in other situations as well, like selecting a category or when no packages
would be featured. And clicking featured packages does not yet select them in
the info area...
Currently a vertically scrollable container for views which are similar
to the title area in the package info view (and share most code, but it
will diverge later on). Untested and not yet used.
Package contents are scanned to find deskbar links. If a package has less
than four links, they will be offered in separate "Open <link name>" buttons
in the package info area. Usually, this results in one button to open the
main application from the package. If the heuristic proves to be not good
enough, this could be improved of course.
Stephan Aßmus