Latest Bugs & Tasks
This is hrev47804.
Yes, closing as invalid. Please fix BeTeX.
#47788, real hardware
Under heavy load, media_addon_server freezes and eventually crashes. This slowdown causes Deskbar to freeze as well. Disabling sound replicant (that uses mediakit) avoids this problem.
Deskbar should have some protection for misbehaving replicants.
Deskbar freezing problem also happens with sound configuration problems (unresponsive mediakit/driver).
I don't have this machine anymore. I suppose it has been fixed anyway.
Currently the only way to draw a tiled bitmap is to use SetViewBitmap with the B_BITMAP_TILE option.
Some websites (eg http://amigaimpact.org) use 1x2 pixel bitmaps to draw line patterns in most of the webpage. Currently WebKit implements this using a loop calling DrawBitmapAsync(), but this is much slower than it needs to be.
We already have a DrawBitmap call taking an "options" parameter. Currently it's only used to set bilinear filtering. We could add support for B_TILED_BITMAP as a new option bit there.
WebKit also supports a "phase" (so the top-left of the source rect may not be drawn at the same position as the top-left of the destination rect), and an affine transform of the source before drawing (which needs special care to make the end result easily tileable). These two would probably need an extension of our API.
Web+ uses the BeOS/Haiku native bookmark format. This works well for native apps, but it would be nice to have some way to export and imnport bookmarks from/to other browsers on other systems.
The "netscape bookmark format" seems to be the de facto standard. Documented here for example: http://msdn.microsoft.com/en-us/library/aa753582(v=vs.85).aspx
Considering this fixed, as it's working for 2 persons and no news from the original reporter. Please reopen if it's still a problem.
There was a fix to our OpenSSL code which should fix this in hrev47789. Please reopen if you can reproduce the bug after this fix.
jstressman: while the image can be tiled once decoded, it's not really possible to decode only a part of a JPEG file. So this would need saving the decoded bitmap to disk as it is decoded, and then reading tiles from that decoded "cache".
While we could implement this OS-wide in the translator API, it wouldn't solve the problem for Web+, which uses libjpeg directly.
Closing this issue since we don't crash anymore. I don't think there is a reasonable way to handle this, and ShowImage can be used without problems.
Using OpenSUSE 13.1 on x64. It could not find <solv/pool.h>; it obviously uses the wrong header location. When I installed libsolv-devel, it would get a bit further, and would then not find <solv/repo_haiku.h>.
This is the compilation line:
cc -c "/home/axeld/develop/haiku/haiku/src/kits/package/solver/LibsolvSolver.cpp" -O2 -Wall -Wno-trigraphs -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -Wno-multichar -include BeOSBuildCompatibility.h -fPIC -DARCH_x86_64 -D_NO_INLINE_ASM -Dx86_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DSTDC_FORMAT_MACROS -DSTDC_LIMIT_MACROS -DHAIKU_HOST_USE_XATTR_REF -DHAIKU_HOST_PLATFORM_LINUX -DHAIKU_HOST_PLATFORM_64_BIT -DHAIKU_PACKAGING_ARCH=\"x86_gcc2\" -iquote /home/axeld/develop/haiku/haiku/build/user_config_headers -iquote /home/axeld/develop/haiku/haiku/build/config_headers -iquote src/build/libpackage/solver -iquote /home/axeld/develop/haiku/haiku/generated/objects/common/build/libpackage/solver -iquote /home/axeld/develop/haiku/haiku/generated/objects/linux/x86_64/common/build/libpackage/solver -iquote /home/axeld/develop/haiku/haiku/generated/objects/haiku/x86_gcc2/common/build/libpackage/solver -iquote /home/axeld/develop/haiku/haiku/src/kits/package/solver -iquote /home/axeld/develop/haiku/haiku/generated/build_packages/libsolv-0.3.0_haiku_2013_10_01-1-x86_gcc2/develop/headers/solv -I /home/axeld/develop/haiku/haiku/generated/build_packages/libsolv-0.3.0_haiku_2013_10_01-1-x86_gcc2/develop/headers -I /home/axeld/develop/haiku/haiku/headers/private/shared -I /home/axeld/develop/haiku/haiku/headers/build/host/linux -I /home/axeld/develop/haiku/haiku/headers/build -I /home/axeld/develop/haiku/haiku/headers/build/os -I /home/axeld/develop/haiku/haiku/headers/build/os/add-ons/registrar -I /home/axeld/develop/haiku/haiku/headers/build/os/app -I /home/axeld/develop/haiku/haiku/headers/build/os/drivers -I /home/axeld/develop/haiku/haiku/headers/build/os/kernel -I /home/axeld/develop/haiku/haiku/headers/build/os/interface -I /home/axeld/develop/haiku/haiku/headers/build/os/locale -I /home/axeld/develop/haiku/haiku/headers/build/os/storage -I /home/axeld/develop/haiku/haiku/headers/build/os/support -I /home/axeld/develop/haiku/haiku/headers/build/private -o "/home/axeld/develop/haiku/haiku/generated/objects/linux/x86_64/release/build/libpackage/solver/LibsolvSolver.o" ;
This is hrev47801.
When copying folders around, I get this alert when Tracker happens on a symlink:
Error copying file "libWebKit.so": No Error (14) Would you like to continue? [Cancel] [OK]
Choosing [OK], the file then isn't copied. If the file the link points to is among those that are copied, the link could then point to the copied file. Maybe that alert could be changed to giving the user the choice to
a) point the link to the copied file (if the target is part of the copy job)
b) keep the link pointed to the original target,
c) let the user choose the new target with a file panel
d) continue without copying (the current behaviour.
I guess a) would be the default behaviour.
I'm not sure if this a bug, if Tracker always behaved like this or if it's an enhancement.
Will be fixed in the next haikuwebkit release.
I don't think this is something we should do in the default browser. It may be done as an extension/add-on, when we support that.
Working ok now.