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
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.
Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)
TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96
example. One could also design them to be 3D icons like regular icons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28099 a95241bf-73f2-0310-859d-f6bbb57e9c96
16 x 16 to 64 x 64).
* Changed the layout code to have dynamic padding depending on main icon size.
* Fixed a problem with the "Auto Raise" feature where, when the pad was along
the bottom, you had to tip the top of the screen with the mouse for the pad
to raise...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28096 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When the consumer does not want to consume a glyph, make
sure the advance values are being reset before breaking out of the
loop. These are used one more time after the loop.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28083 a95241bf-73f2-0310-859d-f6bbb57e9c96
Reimplemented the drag message over the team entries dragging. The previous
implementation used the menu bar tracking by faking a B_MOUSE_DOWN event. The
problem was that in Haiku menus are always sticky and therefor the tracking
thread was not exited when the user released the mouse (which was supposed to
trigger the drop event in the Deskbar). The new implementation follows the
drag in the asynchronous mouse hooks and uses it's own selection state in
TTeamMenuItem to highlight the eventual drop targets.
Fixes#2771.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28063 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed a problem with dispatching B_MOUSE_MOVED messages to views which need
the transit event:
* If the app_server decided to send a B_MOUSE_MOVED to the previous mouse
containing window, it forgot to add the _feed_focus flag, which was a problem
if the message actually happened to contain tokens (views that registered
for events.) On the client side, only those views would receive the message,
while the regular last mouse moved view would not be notified at all.
* On the client side, never change fLastMouseMovedView if the message is not
targeted at the preferred handler. In the above situation, any "registered
for events views" would receive the message first, but viewUnderMouse would
be NULL and then when the regular last mouse moved view received it, it
resulted in the wrong transit (B_OUTSIDE_VIEW instead of B_EXITED_VIEW).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28059 a95241bf-73f2-0310-859d-f6bbb57e9c96
shows a bug in the app_server event dispatching which is going to be fixed
next.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28058 a95241bf-73f2-0310-859d-f6bbb57e9c96
made a new icon which should incorporate the best stuff from both icons. Thanks
a lot to both of you! The Mandelbrot_2 icon shows the fractal with the initial
color palette that the real Mandelbrot demo will use, but I like zuMi's colors
better. Just adding it for reference.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28043 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added the missing Team Monitor intro.
* Fixed navigation in the preceeding and following files.
Changes by myself:
* Removed the bottom navigation in the Twitcher intro, since the file is so
short anyways.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28027 a95241bf-73f2-0310-859d-f6bbb57e9c96
"Playlist->Save As...".
* Fixed loading of playlists. Sorting the list after loading it is
not the idea of restoring a manually sorted playlist.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28006 a95241bf-73f2-0310-859d-f6bbb57e9c96
of stealing (not anymore) mouse messages that are important for maintaining
the correct transit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28003 a95241bf-73f2-0310-859d-f6bbb57e9c96
* In _StealMouseMessage(), don't maintain fLastMouseMovedView, instead,
prevent B_MOUSE_MOVED message from being stolen that are important for
detecting transit changes. The point is that some apps (like Tracker) are
shooting themselves in the foot because they steal mouse messages via
GetMouse() in one place, but then rely on sane transit values in another
place. The way it works now, the view in question may get notified of the
same mouse moved coordinate twice, once via GetMouse() and once via
MouseMoved().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28002 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Improved Tracker and Deskbar introductions.
* Updated and improved a few graphics and added some more.
(Humdinger: The Teammonitor intro was missing from your patch.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27995 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Exit the function early in case of error, instead of maintaining the error
until the end.
* Separate more clearly the condition that a file type is available at all
versus not. This removes a redundancy when falling back to the generic
file icon.
* Add retrieving the icon from the super type. Even check if there is a
preferred app for the super type that supplies an icon before using the
icon of the super type itself.
Hopefully I didn't introduce new errors, but that the super type icon was not
used was the main problem I tried to fix.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27990 a95241bf-73f2-0310-859d-f6bbb57e9c96
if the user cancled the file panel. Some improvements to the SettingsMessage
and some more helpful comments here and there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27986 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The window names are now drawn.
* The window scaling is improved to avoid wobbly placement
when windows move slightly.
* The tab rect is scaled to size, not a single line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27976 a95241bf-73f2-0310-859d-f6bbb57e9c96
now maintained by the application. (So that the last used folder is more
consistently remembered.)
* Added a message protocol for using the file panels from other loopers.
* Implemented playlist saving and loading for the binary (BMessage-based)
format. There were some beginnings for supporting a m3u-like text-based format
as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27955 a95241bf-73f2-0310-859d-f6bbb57e9c96
magic four bytes to recognize native (BMessage-based) icons. The file
recognition rule didn't work in the end.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27951 a95241bf-73f2-0310-859d-f6bbb57e9c96
the logo area is very simple now, as well as the navigation area. Tweaked
the looks to remind a little of the Haiku website look.
* Incorporated patch by Humdinger (better "Open With..." menu screen shot,
added "Open With Preferred" screen shot and text.)
* Some minor fixes here and there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27929 a95241bf-73f2-0310-859d-f6bbb57e9c96
(for better silhouettes), but I think it's pretty cool as is! Thanks a lot!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27915 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added "black on white - normal" size.
* Added the website logo area designs.
* Added the variation of the website logo that I did for the welcome
introduction.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27911 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added Jamfile icon and two icons I will use in Pe. (I keep them here, since
for now, this is the one place with all HVIF icons.)
* Added helper icons for one of the boxes from the generic app icon, may be
useful for integrating in other icons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27908 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Changed the design of the logo area and worked on the document margins
and overall layout.
* Added a navigation infrastructure.
* Worked on the text on the Welcome page - Added an actual welcome paragraph
and unified the bug sections. Slightly changed the paragraph ordering.
* Fixed some typos, added small bits of text to the Tracker topic.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27907 a95241bf-73f2-0310-859d-f6bbb57e9c96
copied to /boot/beos/documetation/welcome and a link to welcome.html
is placed on the Desktop. The mime_update.sh script makes sure that
the mime type of the html files is set. However, Firefox has a problem
when it is launched for the first time via double clicking an HTML
file. Apparently, it initializes some settings and relaunches itself,
which in turn makes it forget to open the file. A second problem is
annoying as well: When launching Firefox to display a local file,
it will always open a second window with the default web location.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27868 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus