* These methods now return the new point after centering.
* But more importantly CenterIn() does some new adjustments to keep the window
position inside the screen edge. If you pass the screen frame into CenterIn()
it skips these adjustments.
In sake of consistency with other Windows CP encodings:
* print_name is expanded to "Windows Central European (CP 1250)";
* B_MS_WINDOWS_1250_CONVERSION id looks like should be added into UTF8.h;
* mime_name set to NULL as other windows codepages have. That prevents
at least from duplicating too much 1250's in the Terminal, Mail and
StyledEdit encodings menus.
This address specification is actually not needed since PIC images can be
located anywhere. Only their size is restriced but that is the compiler and
linker concern. Thanks to Alex Smith for pointing that out.
Improve the unicode character processing and classifying routines by
wrapping up the UChar32 procedures from ICU. That fixes functional
regression introduced in hrev38017 and allows to fix East Asian Width
problems int the Temrinal.
This means the B_COLOR_WHICH_COUNT goes from being a public constant to a
private one. It sill looks like a public constant starting with a B_ though.
I hope that's not a big deal. Too bad we can't get the count of an enum.
This fixes a maintainance problem where you have to update this otherwise
unrelated file to keep it in sync whenever you add a color constant.
I've added a B_COLOR_WHICH_COUNT constant to the color_which enum which should
be updated to point to the newest color constants as new ones are added. I
reworked ServerReadOnlyMemory to use this constant instead of using to the
current largest color constant directly. If you use B_COLOR_WHICH_COUNT to
refer to a color in your code expect to get unpredictable and nonsensical
results. Most likely you'll get an undefined result which will return black
but don't depend on it.
The net effect of this is that ServerReadOnlyMemory doesn't need to be updated
anymore when new color constants are introduced but will continue to produce
correct results.
Eliminate kNumColors constant, replace it with B_COLOR_WHICH_COUNT
This allows you to change the scrollbar thumb color in Appearance preferences.
The default color is 216, 216, 216 so the scroll bar thumb looks the same by
default. Perhaps someday this can be updated to something a bit more colorful.
On some 64 bit architectures program and library images have to be mapped in
the lower 2 GB of the address space (due to instruction pointer relative
addressing). Address specification B_RANDOMIZED_IMAGE_ADDRESS ensures that
created area satisfies that requirement.
Randomized equivalent of B_ANY_ADDRESS. When a free space is found (as in
B_ANY_ADDRESS) the base adress is then randomized using _RandomizeAddress
pretty much like it is done in B_RANDOMIZED_BASE_ADDRESS.
B_RAND_BASE_ADDRESS is basically B_BASE_ADDRESS with non-deterministic created
area's base address.
Initial start address is randomized and then the algorithm looks for a large
enough free space in the interval [randomized start, end]. If it fails then
the search is repeated in the interval [original start, randomized start]. In
case it also fails the algorithm falls back to B_ANY_ADDRESS
(B_RANDOMIZED_ANY_ADDRESS when it is implemented) just like B_BASE_ADDRESS does.
Randomization range is limited by kMaxRandomize and kMaxInitialRandomize.
This allows to reuse BMessenger objects for different targets, or to
recheck validity after initial creation. With that one can use the same
BMessenger after launching an application that was previously not found
valid for example.
* Make pointer style consistent, const char* name instead of const char *name.
* Lots of parameter renaming.
* in parameters don't get anything special, just font, or length instead of
inFont, inLength.
* out parameters get a leading _ so *outWidth becomes *_width for example.
* We don't detail private function in the Haiku book and this class has a bunch
so keep the documentation in the file but use regular comments instead.
* Normalize the parameter names between cpp file and header.
* Some minor whitespace fixes.
No functional change intended.
* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.
As there aren't any more generic meta data containers inside BKey,
there's no real way to distinguish different instances with the same
identifiers. This may be added later, for example the same index system
as used in BMessage could apply.
The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.
The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.
* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.
* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.
With this commit every class in the storage kit is now documented
in the Haiku book!
Thanks to Ingo, Axel, Vincent Dominguez, Tyler Dauwalder, and
everyone who helped document these classes.
* Remove docs from Resources.cpp (leaving the brief description).
* Reformat Resources.h to style it like so many other header files.
* There is one not-entirely style based change. I renamed the outSize
parameter or the LoadResource method to _size as is our convention for out
parameters.
And clean it up a bit. Kept brief description in source.
* Also added Axel to authors in Path.dox and Path.cpp because his name
appears in git blame as working on the docs and code for the file.
I hope he doesn't mind.
* Delete the docs from NodeInfo.cpp and NodeInfo.h
* I snuck a couple of style fixes into NodeInfo.cpp
* I had to make a small modification to MimeType.dox to prevent it
from overriding the docs of one of the methods in NodeInfo.dox.
I made the following changes to the original patch:
* Add const to the cursor setting functions.
* Removed the legacy cursor copying code.
* Minor coding style cleanup.
* use only a single static object (MutableLocaleRoster) instead of
two, which avoids any problems if the order of static object
destruction would destroy RosterData before MutableLocaleRoster
* rename BPrivate::RosterData to BPrivate::LocaleRosterData and move
it into a header and implementation file of its own
This should hopefully fix problems encountered with a clang-compiled
Locale Kit.
After this change, low level cpuidle drivers load the generic cpuidle
module if they can support the underlying platform.
change the intel cpuidle driver accordingly, now it's loaded by acpi
bus manager during boot, although it doesn't depend on acpi
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
This module will load the various lowlevel cpuidle modules' implementations
during initialiation. If it finds one available module, it will change
the global gCpuIdleFunc as its own better one.
When idle, cpuidle module will select the best cstate and enter it by
calling the lowlevel module's implementation.
Signed-off-by: Yongcong Du <ycdu.vmcore@gmail.com>
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* We felt that me adding this didn't really
properly communicate the spirit of the
email approval. You really can't just
'change' a license from MIT without author
approval... so this is superfluous.
* A copy of the email approving this change is
in the LICENSE.txt file
* This clears up several concerns
* We now have permission to clean / update GLUT
code and redistrubute its binaries.
* We have to ensure all of Mark's work is *not*
GPL licensed as per his wishes.
* GCC 4.7 is more picky than GCC 4.6, so have to make changes accordingly
* Changes include addressing issues with scoping, redeclaration, etc.
Thanks Rene and Ingo for your input on these changes
Also gave the Up Arrow and Down Arrow a scroll arrow. The up arrow works
but the down arrow doesn't because the sibling menu is stealing the
MouseDown event."
instead of trying to make it follow fExpando just make it a fixed
size on creation. It is invisible and extends to the bottom of the
screen. fExpando grows inside it, and the window follows fExpando.
When the window grows taller than the screenframe the arrows are
added. You can scroll with the mouse wheel, but I haven't yet gotten
scrolling to work from clicking. Deskbar still crashes when going
from Mini mode to vertical expando mode. I have no idea why.
Rename ScrollMenu.cpp to MenuScrollView.cpp
Half step towards making this class work as part of Deskbar without
extending any other classes. Scrolling works both with mouse and
scroll wheel. Redraws on scroll, need to make that work better.
Also need to move classes out of the Interface Kit and into Deskbar.
Modify the ScrollMenu class to use the layout kit by adding a constructor that doesn't take a view.
Get the BScrollMenu class to follow the size of the BMenu it is a parent of. Adjust the scrollers to appear in the right places. This is a WIP but it works in Deskbar, next step is to integrate this directly into BMenu with the scrollers as children of the menu instead of as children of the BScroller class.
Rebase changes on top of master
Deskbar scrolling works for the most part, just need to fix the
bottom arrow and clean up a bit.
* Before, you had to have both, the text view layout item, and the label
layout item or else nothing would ever be visible.
* Now you can only create the text view item, and it will still work.
* Also, no matter the order you added the layout items, they would always
put the label on the left, and the control to the right.
* You can place the label and text view layout items anywhere now, although
you should keep in mind that the view spans over their frame unions; IOW
they should always adjacent to each other, but not necessarily horizontally
and left to right.
* No longer uses a fixed label spacing, but utilizes
BControlLook::DefaultLabelSpacing() instead.
* However, the spacing is always added to the right of the label, no matter
how you place it in the layout. Maybe one wants to add a SetLabelTextViewGap()
like method.
* Adjust BTextView to use B_COMMAND_KEY instead of B_CONTROL_KEY
for wordwise navigation and jumping to the top and bottom.
This requires a shortcut, which is only installed if there is
none already (for the groups B_LEFT_ARROW/B_RIGHT_ARROW and
B_HOME/B_END). As a result, wordwise navigation no longer works
in Mail, for instance.
