class/namespace. Renamed the B_GRADIENT_* types to TYPE_* as the context
is already given.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28564 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fStyleMap could be deleted more than once in certain situations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28563 a95241bf-73f2-0310-859d-f6bbb57e9c96
redownloading the package.
* Added link "vlc" to "VLC media player" in /boot/common/bin to make it
easier on people launching VLC from the command line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28558 a95241bf-73f2-0310-859d-f6bbb57e9c96
license was nowhere mentioned. I added an explaination to the copyrights section
and also mentioned that clicking a license name will open the respective
license for reading.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28557 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added docs and screenshots for preference panels:
Appearance, Backgrounds, DataTranslations, E-mail,
Filetypes, Fonts, Keyboard, Keymap, Menu, Mouse,
Network, Screen, Screensaver, Sounds, Time, VirtualMemory
Adapted some contents for E-mail preferences from
src/documentation/haiku_user_guide/HaikuUserGuide.txt
As I haven't succeeded to get email running in vmware, I'd appreciate if someone
can proof read what's written in E-mail preferences.
* Added preferences to the user guide contents.
* Various formatting details and inter-documents-links
Wow! Thanks a lot!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28555 a95241bf-73f2-0310-859d-f6bbb57e9c96
slightly strange redrawing, including scrolling the offscreen view
that it uses in "flicker free" mode (which is the default). Invalidation
does not work in offscreen windows, since the client thread is not running
and certainly won't redraw anything. But that will leave a non-drawable
region on the app_server side of things. Simply don't invalidate in
this case. From what I have seen, redrawing in NetPositive seems to
work fine now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28538 a95241bf-73f2-0310-859d-f6bbb57e9c96
for most messages, use debug_printf(), cleanup line breaks
* check return code of last link method in a lot more places
* changed some printf() and fprintf() into debug_printf()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28537 a95241bf-73f2-0310-859d-f6bbb57e9c96
in AutoMounter::InitialMountVisitor::Visit(), otherwise restoring
mount options, like read-only mounting, would never work. This
kind of mixes the options of the mount settings, since it partially
remembers the settings even if the option is not "only previously
mounted disks", but it should not hurt anyways. As a side effect,
this should also fix the mount notification sent to Tracker, as
the path should only have been correct for the "mount previous disks"
setting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28533 a95241bf-73f2-0310-859d-f6bbb57e9c96
gWidthBuffer.
* Tracker PoseView now uses BPrivate::gWidthBuffer instead of it's own
instance.
* TextView.h and PoseView.h are now a little cleaner.
* InterfaceDefs.cpp now deletes gWidthBuffer in _fini_interface_kit_().
* Added binary compatibility support for NetPositive in WidthBuffer.h and .cpp.
Obviously it kind of defeats the purpose of having WidthBuffer neatly tucked
away in the BPrivate namespace, but Haiku should run NetPositive, I guess.
Fixes#2879.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28532 a95241bf-73f2-0310-859d-f6bbb57e9c96
icon in the MediaPlayer Info window. I changed it a bit, so that the
icon retrieval only happens at the file change notification (quite
important, since the info window receives playback position notifications).
I also changed it to take the icon from the file first, if there is one.
Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28520 a95241bf-73f2-0310-859d-f6bbb57e9c96
license) and rebased the ExpressionParser from double on the MAPM data type.
Currently, the binary operators are not supported anymore, but the imprecise
calculations were getting on my nerves. I think a lot more neat functions
could now be supported, but I have not looked into it further. I also didn't
dare look closer at the C code of the library, but it seems to be well
tested. It's portable by all means, I guess even if the target platform has
8.3 char file names to hold the code... Luckily, the library inclused a C++
wrapper class for the data type (MAPM) which makes it fairly comfortable to
use and hides the ugly C stuff and messy memory management.
The result seems to be quite nice so far. Previously, I couldn't even calculate
my finances without eventually getting some rounding errors.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28506 a95241bf-73f2-0310-859d-f6bbb57e9c96
wrong check to see if the view was currently visible. This fixes the problem
that tool tips would popup for windows that are located on other workspaces.
* Removed commented out code that is no longer needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28498 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The function is not supposed to return hidden views.
* After iterating over the child views, the "view" variable was clobbered,
so it didn't work to return the current view if none of it's child views
were hit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28494 a95241bf-73f2-0310-859d-f6bbb57e9c96
window this fixes the tool tip size/layout in apps that use BubbleHelper
(Beam, WonderBrush, ...). Thanks to Rene and Stefano for sending me a test
application.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28489 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Firefox -> 2.0.0.17, includes new HVIF icon
* VLC -> renamed VLC to "VLC media player" which is what the official name is
* Pe -> updated to most recent version (called it RC2) which includes a few
fixes and new HVIF icons for most of it's supported document types. Renamed
the application folder to "Pe" and removed the "Drag lpe here to install"
link. Renamed the application itself to "Pe".
Hope these changes are alright with everyone.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28485 a95241bf-73f2-0310-859d-f6bbb57e9c96
SetMouseEventMask() from within it's mouse hooks. Among other things,
scroll bars won't stop scrolling in FFM mode now if you accidentally
leave the window with the mouse, something which is very likely.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28481 a95241bf-73f2-0310-859d-f6bbb57e9c96
both double buffering and single buffering, Invalidate() needs to be
virtual and ViewHWInterface needs to decide where to invalidate it's host
window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28480 a95241bf-73f2-0310-859d-f6bbb57e9c96
tool tips in WonderBrush. The reason was that the text rect is getting
smaller and smaller each time the tool tip is shown (even though there
is only one word), and the line break moves one char towards the beginning
each time. After four times, the busy loop would kick in reliably. I cannot
really say that I understand the code, though. But that's the spot anyways.
Stefano, could you have a look?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28471 a95241bf-73f2-0310-859d-f6bbb57e9c96
relative mouse movements. Removed the "history" and replaced it with a method
to accumulate the deltas. Very small deltas are somewhat suppressed, but still
accumulate. Overall, this improves the touchpad sensitivity for small movements
without introducing unwanted jitter. This also keeps the direction of slightly
"non-straight" movements better. I also changed the scale somewhat so that
the acceleration does not feel too little anymore.
These are the remaining problems I have:
* Tap-clicks are sometimes not recognized
* releasing the finger from the pad (which is pressure sensitive) sometimes
still injects unwanted mouse movement, which may be possible to be supressed
when looking at the pressure change and recognizing the release.
* scrolling has changed a bit due to my changes and feels a bit too sensitive
now
Please check it out if you like (ps2_dev.c:105) and tell me what you think.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28468 a95241bf-73f2-0310-859d-f6bbb57e9c96
worked, because the root scanning directory was declared without "/dev/".
This makes restarting the input_server work with the touchpad driver.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28464 a95241bf-73f2-0310-859d-f6bbb57e9c96
solution and replaced it by dumping output to the syslog. (Also
disabled debug output by default.)
* Fixed wrong header guard.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28463 a95241bf-73f2-0310-859d-f6bbb57e9c96
* ps2_dev.c - accidentally turned Synaptics support back on with my last commit. Sorry.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28460 a95241bf-73f2-0310-859d-f6bbb57e9c96
standard versus extended PS/2 mice by simplifying the naming
of the devices but forgetting to adapt this part of the code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28458 a95241bf-73f2-0310-859d-f6bbb57e9c96
in UpdateSettings() to avoid a crash when there is no TouchPad at all.
Changes by myself: Adapted coding style and added a comment to ConnectToTouchPad()
on why the loop is not exited as soon as the device is found.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28457 a95241bf-73f2-0310-859d-f6bbb57e9c96
I am also not happy with the acceleration yet and as reported
by others, there are problems with real mice as well (now wheel
support anymore). With the plain PS/2 driver, I can slide my
finger slowly over the touchpad and the cursor would react/follow
precisely the movement. In Synaptics mode however, there are
unexpected pauses in the movement of the cursor. In any case, the
patch is finally in and I or anyone else can continue to work
on it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28443 a95241bf-73f2-0310-859d-f6bbb57e9c96
patch wrongly. This should hopefully fix it. Only my coding style cleanup
history should be "lost" this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28426 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Hopefully fixed most of the coding style violations
* ps2_trackpoint.h had the wrong header guard
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28425 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Applied the changes that were done to MouseInputDevice:
- use BObjectList,
- take adventage of BPathMonitor node monitor message fieds
- remove the device in the polling thread upon ioctl() error
* Added TODOs about refactoring the code together with MouseInputDevice.
Untested, but the code is so similar, I am pretty confident it still works.
(famous last words... will test soon anyways)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28421 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added myself to Mouse and Keyboard add-ons for my recent work on them.
* Small cleanup in KeyboardInputDevice.h-
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28420 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented Synaptics touchpad support in the PS2 bus_manager by
refactoring/splitting the structure some and adding touchpad device
handling.
* Implemented Touchpad input_server device add-on
* Created Touchpad preflet for configuring advances Synaptics touchpad
options like scroll region (both horizontal and vertical) as well
as other neat stuff
Thanks a lot, Clemens!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28416 a95241bf-73f2-0310-859d-f6bbb57e9c96
problem in TextSearch. After the change, the scrollbar and child view layout
would be messed up there. The reason is that TextSearch calls
scrollview->ResizeToPreferred() prior to adding it to the window. In this
situation, the child views (scrollbars, target view) do not follow the parent
view. Before r28258, ResizeToPreferred() would not change the size of the
view (calling it in TextSearch is stupid anyways, since it is layouted later
in the code). I have thought about how to best fix this. I know 100% that there
is code out there that will mess with scrollbar layout. So it wouldn't be a
good option to refactor the layout out of BScrollView::DoLayout() and calling
that method from AttachedToWindow(), although that seems like the cleanest
option. Instead, I opted to simply reject resizing in ResizeToPreferred()
when the scroll view is not yet attached to a window. What do others think?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28409 a95241bf-73f2-0310-859d-f6bbb57e9c96
acquire_sem_etc(), but treat it as an error instead. This allows
to kill device polling threads in the input_server and prevents
a busy loop in the kernel then. Before the input_server was shutting
down devices upon quit (happens only when restarting it), this
busy loop could also be observed, since then polling threads would
be quit on exit of the team.
* Supply B_INFINITE_TIMEOUT for the MouseDevice instead of 0. Does not
change anything, but was probably not intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28407 a95241bf-73f2-0310-859d-f6bbb57e9c96
layouted incorrectly:
* Only remove the insets if there are any when no tabview is needed.
* Use Bounds() when creating the scrollbars, not Frame() (this probably
worked correctly only when the DynamicScrollView was the only child in a
window...)
* Simplify layouting the scrollbars and target view, always do so, since it
isn't clear if the host window uses the old style view follow modes, the
target view had no follow mode anyways, so we need to layout it for sure.
* Correct the "edged in" effect of the TitleView drawing.
This fixes the bad drawing artifacts in the Media preflet when scrollbars
are needed to embed a larger parameter web view.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28394 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Slightly improved the wording on the Welcome page
* Corrected some wrong HTML tags here and there
* Improvements on the Bug Reports page
* Added paragraph on file panels on the general GUI page
* Added Filesytem Layout page
* Added Boot Loader page (kernel boot options)
* Added Keyboard Shortcuts page (also moved the paragraph about default command
key there)
* Prepared index pages for Applications, Preferences, Demos and Desktop Applets
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28389 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The first problem was introduced by myself, when I added deleting the
transfer semaphore in HIDDevice::Close(). Obviously, I should (re)create it
in Open() then, or it won't work another time. (Open() is now the only place
where it's created.)
* The second problem was when transfers have already been scheduled the
last time the device was open, but never triggered yet. We need to reset the
fTransferUnprocessed flag, or we won't schedule another transfer but
wait on the transfer semaphore anyways in Control(). I also added
canceling the usb transfers with the stack in Close().
* The remaining problems were specific to the KeyboardDevice, the repeat
key stuff needs to be reset in Open(). I also added unsetting the repeat
key when the key release is detected, but this should have already worked,
because the semaphore timeout was reset to B_INFINITE_TIMEOUT.
One can now "/system/servers/input_server -q" and everything will be back
in working order. There may be some remaining problems in the Wacom driver
which I have not yet looked at.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28368 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made KeyboardInputDevice more similar to MouseInputDevice, the object to
track individual keyboards has become the class KeyboardDevice. Moved
much functionality that used to be in KeyboardInputDevice into
KeyboardDevice.
Functionally, it should still be the same, but there are two important
changes:
- Each KeyboardDevice now has it's own Keymap. At first, it is not
visible by the user, since all KeyboardDevices still adopt the keymap
if the user reconfigures it. But it will make it easier to assign
individual keymaps to each attached keyboard (and perhaps associate them
with a vendor/product or some other means). The more immediate side effect
is that there is no longer a confusion about the keyboard locks. If
you press NumLock on your external keyboard, it will no longer enable
NumLock on your notebooks internal keyboard.
- KeyboardDevice now has a Stop() method, which it will call in it's
destructor. This will make sure that the control thread is cleanly
exited and does not end up invoking methods on a deleted object.
* Rewrote the tracing implementation in MouseInputDevice.cpp. At least it
helped track me down the following problem:
* Both KeyboardDevice and MouseDevice now set fActive to "false" *before*
closing the device. Since the control threads run at high priority, chances
are high that rescheduling happens as soon as the device unblocks in
ioctl() and returns an error. In that case, the control threads would
check fActive and it would still be "true" and the whole idea of bailing
out because we're already in Stop() would not work, causing a double free
in the end.
All of this is nice and more correct, but input_server is still crashing
when restarting it via "input_server -q"... :-(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28352 a95241bf-73f2-0310-859d-f6bbb57e9c96
device returned B_OK.
* In the InputServer destructor, don't check the fAddOnManager pointer,
but check the success of calling Lock() on it instead, which should
be much safer.
* In StartStopDevices(), really start or stop all published devices for
the given BInputServerDevice, not only the first one found. Simplify
the check whether anything needs to be done.
* Change a bit the return codes of StartStopDevices(). Especially the
version that's supposed to start or stop all devices will still try
to do it for the rest of them.
* Removed no longer needed _FindInputDeviceListItem().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28351 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it are unblocked and get an error.
* Make fOpen volatile to prevent unwanted caching effects when checking it from
different threads. (?)
* Check IsOpen() in the KeyboardDevice class in more acquire_sem_etc() return
cases, analogous to the MouseDevice class.
I am still getting a problem when relaunching input_server with the input_server
add-on thread that ioctl()s on a USB keyboard fd, which should have never fired
because it's a fake device from a KVM. After the first input_server instance is
gone, this thread keeps on busy looping in acquire_sem_etc()->switch_sem() from
within the ioctl() of the KeyboardDevice usb_hid driver. Still on it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28350 a95241bf-73f2-0310-859d-f6bbb57e9c96
at 0. A single AddPath()+RemovePath() would therefore leave a not
anymore needed path_entry(), while a AddPath()+AddPath()+RemovePath()
would remove/delete the path_entry while it was actually still used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28349 a95241bf-73f2-0310-859d-f6bbb57e9c96
resulted in the keyboard not working (at least on my Lenovo/IBM T60).
The device control thread could become aware of a dead device
at the time another thread (for example the add-on manager thread)
is already waiting for it. Then it tried to remove the device and
got stuck on locks that the other thread already holds (InputDeviceItem
list lock). Now the control threads check the "active" flag before
trying to remove the devices themselves, which, when set, is a sure
sign that the devices are already being removed and they don't need
to take care of it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28342 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Various fixes and corrections
* Preparation for new sections
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28332 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When the device watcher/control thread encounteres an error when
read()ing or ioctl()ing the device, don't just quit the thread and
leave a stale device add-on hanging there, but instead trigger
_RemoveDevice() to exit this cleanly. This also takes care of calling
_RemoveDevice() only from one thread. However, it adds a race condition
should a mouse or keyboard be unplugged and plugged at the same time.
I need to think about how to fix that cleanly, although the situation
may be theoretical only... This fix seems to fix another problem with
hot-plugging USB mice, before this change, the first mouse entry in
/dev/input/mouse/usb/ was never gone and I got two entries after unplugging
and replugging.
* When using BObjectList configured to own the entries - don't delete the
entries! Also don't call RemoveItem() before still using the item. Took
me all day to find this one, because the code looked so... correct. :-}
* In _AddDevice() call _RemoveDevice() just for the sake of it. It is really
important that no device with the same name is published twice. The PS/2
driver behaves strange in that it publishes device more than once, if
I understand correctly, until it decides that there is no device.
* Only StartMonitoringDevice() /after/ having performed the initial device
scan! Or else we may get ourselves confused. I don't know if this was
an actual problem, but the code was like that before and it seems saner
to me. Seeing there is no locking in the device add-on itself, we may
already enter the code from the node monitor thread.
This should fix#2894.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28321 a95241bf-73f2-0310-859d-f6bbb57e9c96
device path, but instead pointing to memory owned by some device addon
instance.
* Added TODO in the AddOnManager init code about a possible race condition
which I have not varified yet.
* Check the return code of BList::RemoveItem() before deleting the item...
pure defensive programming.
* For the time being, print a warning into the syslog when a device name is
registered twice.
* When failing to Unflatten() an event, don't continue in the code after
deleting it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28319 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use new(nothrow) to allocate the MethodReplicant.
* fSignature needs to be free()d, not deleted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28318 a95241bf-73f2-0310-859d-f6bbb57e9c96
weird.
* Set fHandler to NULL in _UnregisterAddOns(), just in case it is called
twice (which it probably never is... but be defensive).
* If a B_NODE_MONITOR message does not contain all the necessary fields,
drop into the debugger when compiling in DEBUG mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28317 a95241bf-73f2-0310-859d-f6bbb57e9c96
devices that were removed. Should use the BPathMonitor anyways...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28315 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed unloading the add-on image twice in error case of failing to
add the add-on info to the list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28307 a95241bf-73f2-0310-859d-f6bbb57e9c96
updates during the vertical refresh, but it causes flickering again since
there is no guarantee that screen regions will stay clean from the time that
they were scheduled with the UpdateQueue until the UpdateQueue thread
transfers them. Therefor it is still disabled.
* Refactored a bit the distinction between Invalidate() and CopyToFront().
Invalidate() used to be virtual, but now CopyToFront() is. This was mainly
needed for the app_server test environment, because the host window needs
to call Invalidate() when the front buffer bitmap is clean. When the
UpdateQueue is used, this needs to be CopyToFront(). Now the separation is
cleaner in combination with the UpdateQueue.
* Fixed a problem in HWInterface::CopyToFront(): When separating the region
outside the cursor and the region with the cursor during a transfer, it
needs to hold the fFloatingOverlay lock to make sure the cursor is not
moved in the meantime. This fixes graphics glitches with remnants of the
cursor staying on screen. These could very rarely be observed, but much more
often with the accelerated double-buffer mode.
* Enabled the accelerated double buffered mode, since it works now very well.
I was able to test it with the nVidea driver on an nVideo 7300. It works by
allocating a frame buffer twice the height of the configured screen mode.
Then all drawing goes into the offscreen portion, including accelerated
driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration
to blit the clean regions in the offscreen portion of the frame buffer into
the visible part. Please tell me if there are problems, for example when
if there is too few video memory, or if a driver does not handle it correctly.
To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96
when the HWInterface was using acceleration and at the same time double
buffering.
* _CopyToFront() should always be used, since it calls a protected virtual that
derived classes of HWInterface depend on. This fixes some graphics glitches
in certain situations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28300 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes in my tree to make it compile on R5 still. I don't really want to
check this in, I'd rather adopt the buildsystem to make it run on Haiku
itself...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28298 a95241bf-73f2-0310-859d-f6bbb57e9c96
* moved flag slightly for better crispness
Hope you don't mind, nice work, Francois!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28266 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Slightly worked over the Image Editor icon to improve crispness at 16x16).
* The shadow of the pendrive could perhaps be improved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28265 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored a User Guide style documentation from the previous Welcome
documentation. The Welcome documentation links to the User Guide, the
biggest difference is that there is now a separate contents page.
* Improvements to the text.
* Added Tracker-Add-ons page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28211 a95241bf-73f2-0310-859d-f6bbb57e9c96
Save menu item accordingly and ask the user to save changes when he quits
the window and there are any changes.
Most changes are tracked in a robust way, only icons are tracked with a
more fuzzy method (the actual data is not compared). Whenever an icon
(of the app itself or one of its types) is changed, then the preflet is
convinced of the need to save, regardless of the icon is removed again or
is changed to the visually same icon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28182 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added an optional modification message that is triggered whenever the
view adopts a new icon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28178 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved the naming of the menu entry that removes a replicant from a shelf
to be less frightning.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28177 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a new class BAffineTransform, currently in the BPrivate namespace
and the inofficial "shared kit".
* Extended BPolygon to be transformable by a BAffineTransform.
Thanks a lot!
Minor fixes by myself:
* The class accidentally still derived from agg::trans_affine.
* Added then missing comparator operators.
* Swapped the BPoint* and count arguments of Apply(), since that seems
to be the more common order in the other Be API.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28176 a95241bf-73f2-0310-859d-f6bbb57e9c96
which call into Desktop methods which in turn grab the window
write lock are never supposed to hold this write lock themselves
already, since the Desktop code takes care to not hold the lock
when for example calling EventDispatcher methods, which would
cause a deadlock (as in this example).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28175 a95241bf-73f2-0310-859d-f6bbb57e9c96
it was quite sluggish. When opening larger mails, like a 1.14 MB mail for
example, it could take almost half a minute until it was displayed. It turned
out that the offending thread was in strstr().
This is an implementation taken from Wikipedia (declared as public domain
there), which makes the mails open instantly. This usecase may have represented
a worst-case scenario for the previous implementation. It may be beneficial to
take a look at more of these string functions, but I am happy for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28172 a95241bf-73f2-0310-859d-f6bbb57e9c96
dragging and dropping icons from one FileTypes window to another (in case
the dragged icon was a vector icon).
* Checked the other similar places, but all seems fine. Added a comment in
one place why no data is leaked, although it may seem to at first sight.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28159 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fix the calculation of the fTextRect member. The BeOS behavior (and also the
previous Haiku behavior) was to recalculate the "bottom" always. This was not
taken care of in SetTextRect() (needs to override the passed bottom).
* The insets are already tracked in fLayoutData, use this in
_UpdateScrollBars() to calculate the correct data width/height (an
improvement over the BeOS behavior it seems).
* Try to minimize the need to call _Refresh(), which reduces flickering a whole
lot.
* Fix several instances where fTextRect was recalculated based on Bounds() and
the saved insets, where it was broken when the BTextView was scrolled.
Fixes#2784.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28151 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Resolved TODO: The type of the gradient is no longer encoded twice in the
app_server link protocoll.
* Moved instantiation of the BGradient into the LinkReceiver::ReadGradient()
method.
* Check success for (at least) ReadGradient() in ServerWindow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28150 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reworded info_prepare() for clarity.
* info_get_package_version() and info_get_package_name() were returning
memory from a local variable. They return an error code now, possibly
from info_prepare().
installedpackages:
* Simplifications and refactoring.
* Improve the layout of the interface (using layout management).
* Fix coding style issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28145 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add the case where H.264 info needs to be extracted.
(Had this laying on my hard drive for a while, hope you have not worked
on it again, David...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28142 a95241bf-73f2-0310-859d-f6bbb57e9c96
in Haiku), but the binaries have appearantly changed slightly, probably of
some optimization that Icon-O-Matic is now doing. No functional or visual
changes should have taken place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28137 a95241bf-73f2-0310-859d-f6bbb57e9c96
from Wikipedia. I tried to fix any issues and approximate the original logo
as best as I could. (tqh, I can send you an .rdef if you need it.) The icon
size could be further reduced by re-using paths. I named a couple of paths
accordingly when I spotted duplicates.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28136 a95241bf-73f2-0310-859d-f6bbb57e9c96
* A new icon for NetSurf (although the original logo can and has been made
into a HFIV icon by Guiseppe, but I find the surfing monkey quite cool
and would prefer that if it's alright with the NetSurf crew.)
* A new icon for a Chat application, or perhaps the Chat Kit server? :-)
* A new icon for RSS Feeds. Either for a file/bookmark type or an app?
Nice work, zuMi, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28135 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus