B_DIRECT_MODIFY with, for example, B_CLIPPING_MODIFIED. This was ignored,
though. Now we combine this notification with the next ones, so that
on B_DIRECT_START, the client is informed of all the things which have
changed. Chart was relying on receiving the B_CLIPPING_MODIFIED notification
to exclude some stars from being erased, in case the window went offscreen.
Anyway, the net result is that Chart doesn't crash now, and we follow
more closely the original BDirectWindow protocol. Fixed ticket #1939.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32392 a95241bf-73f2-0310-859d-f6bbb57e9c96
and assigned the usual shortcut keys (Cmd-[Shift-]G).
* Changed the behavior so that "Find Next" continues looking in the search
direction. I'm somewhat undecided whether this is confusing, since the default
(and usually desired) search direction is backward.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32386 a95241bf-73f2-0310-859d-f6bbb57e9c96
instead of using the user buffer. This frees the VFS and FS implementations
from handling user buffers.
* Adjusted fix_dirent() accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32384 a95241bf-73f2-0310-859d-f6bbb57e9c96
in safe mode.
* Removed the Terminal from the Bootscript.
* Ordered the servers alphabetically in HaikuImage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32379 a95241bf-73f2-0310-859d-f6bbb57e9c96
one in the American keymap (instead of following those in the US-International
keymap). This closes ticket #3756.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32378 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fix ZETA build as yes, I still test stuff in ZETA :p
Thanks Rene for noticing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32377 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed direct_window_data to DirectWindowData and turned it into a
class.
Encapsulated some functionality inside the DirectWindowData class.
No functional change (yet).
More to come.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32374 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now, if the user attempt to enter an invalid IPv4 address in a field, when he clicks apply :
* the focus goes back to the invalid field
* it displays an error message into the window, at the bottom
* it beeps
* it doesn't save the change, of course
DNS #2 is consider optional. The check is made with a regex.
This should take care of ticket #4205.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32370 a95241bf-73f2-0310-859d-f6bbb57e9c96
device is not compatible, after all.
* No longer accept color changes if the mode is not an 8 bit one. I think that
BWindowScreen does that after changing the mode, so that is messes up the
colors, at least that's the theory, will test on real iron now.
* Use VGA as a fallback if setting the palette via VBE failed. This brings back
the colors for ParticlesII in Qemu (but not in VirtualBox, which seems to be
completely broken in this regard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32359 a95241bf-73f2-0310-859d-f6bbb57e9c96
Start of framebuffer initialization for the Verdex board.
For now it points to the data section as framebuffer for testing and shows an RGB pattern.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32352 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added hint of right-click navigating saved queries.
* Mentioning queries besides files/folders for configuring the Deskbar Menu.
* A few cosmetic changes here and there.
* Added Installer documentation. Corrections welcome, esp. concerning the
"Write Boot Sector" button.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32346 a95241bf-73f2-0310-859d-f6bbb57e9c96
a shortcut for fullscreen, but I guess the view was processing it first. So I
just removed B_ENTER as an option for next image. Also Shift plus primary mouse
was already working for moving the image.
Also I know it was discussed at length but I still wonder if all these options
for next and previous image are overkill. Now there is no way to scroll with
the keyboard. And there isn't an easy way to go to the next image with the
mouse (menus are a pain.) So I still think some more UI tweaking is needed to
avoid constant shifting between mouse and keyboard.
Finally I also added Command-1 as a shortcut for Original Size, but it does not
work. Anyone know why?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32343 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Add underscore to private methods.
- Use class member initializer syntax.
- Make sure all class members are initialized, use same order as headers.
- Header reordering.
- A few other small things.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32342 a95241bf-73f2-0310-859d-f6bbb57e9c96
Don't forget the ELF header else we end up loading at 0x7fff8000...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32341 a95241bf-73f2-0310-859d-f6bbb57e9c96
Use the same trick as for m68k (r26536) to get separate text & data segments for the kernel, though this should really not be needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32340 a95241bf-73f2-0310-859d-f6bbb57e9c96
