when drawing the following controls:
* SliderBar
* ActiveTab
* MenuField
This is a followup commit based on the change made for buttons in
hrev44708 in response to bug #8700. It is good practice to always preserve
the parent view's clipping constraints.
Stippi and Axel can you you at this commit and make sure this is kosher?
+alpha4
* Depends on ff09527e4f (which is +alpha4 *not* +alpha3) :)
* As per commit ML
* Do a direct AddItem vs using an item variable which
breaks program flow.
* A better long term solution may be to enable the debug server
to recover 'system' applications that fail. #9039
* Matches "Restart Tracker" option in Deskbar
* Only shows up when 0 Deskbar processes exist
* Don't dereference fFileMenu if RepopulateMenus called
on desktop (no menu bar)
* Regenerate desktop menu on each click
* Resolves#9039
- BNavMenu now keeps its own copy of the cached types list that's passed to it.
In some circumstances it could happen that the container window would
delete the list and consequently the nav menu would wind up with a pointer
to an invalid object. Probably a regression from the async mouse tracking
rewrites.
* Selected bg uses B_MENU_SELECTED_BACKGROUND_COLOR
* Selected text uses B_MENU_SELECTED_ITEM_TEXT_COLOR
* Unselected text uses B_MENU_ITEM_TEXT_COLOR
Update BStringItem, but also the custom Listitem code in the
Appearance and Locale preflets.
Before its name was a lie, since nothing was cached.
Another boolean was added because getting the localized name could fail, and we
don't want to pointlessly try again, so relying on fHasLocalizedName won't work
for that.
Since in my tests this was getting called up to 4 times per application when
opening the Deskbar Application menu, this caching should speed that up a bit,
at least when this file name translation feature is turned on.
Now that we use the actual selected menu item ui_color, this tinting is not
needed. In fact it makes the selected item too dark.
Thanks diver for noticing.
Double-click check was redoing what is essentially already done in input_server.
The way we were doing it, right clicking (or pressing a different button for the second click,
for that matter) wasn't clearing the fields remembered and thus not breaking the sequence.
So a third click returning to the correct sequence (in a short time) would get recognized
as a valid second click. So a quick left-right-left would be seen by that method as left-left.
Also, clean up a previous fix I committed. Removed the introduced Origin() method as it
is the LeftTop() method I was interested in and it is already existing.
Fix#8714
This also matches the client_window_info.show_hide_level field used in Deskbar
and other applications.
While doing this, keep fShowLevel fully in sync between BWindow and app_server,
use one message type for both hiding and showing, and make the decision to show
and hide the window in the app_server.
Lastly make minimize behave as described in the Be Book: hidden windows cannot
be minimized, and minimized windows which get hidden become unminimized.
Replaced remaining "Preferences" and "Options" with "Settings" as
that is generally used for app settings instead of the system
preferences found in the preference panels.
Renamed Tracker's "Preferences" to "Tracker preferences" to be
similar to the entries in the Deskbar and e.g. the Media replicant
in the Deskbar tray.
TextWidget tried to detect if the editing box would span outside the PoseView,
but it was using an hardcoded value of 1 for the minimum left value. But in Icon mode,
negative values can occur. Change to use the view's origin (top left corner of the view).
Due to clipping of a rect to match the view bounds, there was a confusion
as to whether the rect was at the top of the view bounds, or above the view
bounds as both met the condition.
Fixes#8876.
Implementing the window_info.show_hide_level in terms of this solves the
problem of minimized windows also being considered hidden, when really they are
just hidden in the app_server.
window_info.show_hide_level is still defined backwards with a comment making
that clear.
Also removed sending fShowLevel in the minimize request since it is now
maintained in the app_server.
Fixes#4127.
- When an Identify/Force Identify request is made in Tracker, if the target
is a link, resolve it to its destination first. Fixes#8858.
- Have mime_update.sh explicitly mimeset the welcome/user guide scripts.
Since the position of the widget was registered at the first click,
it likely changed and its causing drawing afterfacts (it's editing at
its old location).
Make the PoseView stop watching a TextWidget if it's being deleted.
Could happen in race conditions for example, if you click to edit
the name widget of a pose while the pose is being deleted soon after.
Don't wait for a potential second click (and then trigger Widget editing) when:
1. a click occurs on a different pose, on a 'pose-less' area or when right clicking
2. when you start dragging something.
Make the "second click of a double-click" detection waiting time async. In other words
(hopefully clearer), when the TextWidget gets a click, it register itself, recording the time,
and it will get the editing order later as a callback from PoseView when the delay without any
further click expires.
Fixes#8818 and maybe others.
The type of BRegion::fCount is long, and ServerLink sends/receives it
with sizeof(long), but LinkReceiver was using sizeof(int32). Due to
long being 64 bit this was resulting in a mismatch. This fixes the
drawing problems on x86_64.
In rare cases such as described in #7955 BTextView happens to calculate the
width of a tab close to zero (e.g. 0.000031). This patch adds a fallback to the
default tab width in that case.
Signed-off-by: Ryan Leavengood <leavengood@gmail.com>
Due to a previous change in the incrementation of models in AddPosesTask,
PoseView containing large number of poses were prone to crash in ClearPoses().
Gaps in PoseList or other invalid memory area were introduced.
Thanks to x-ist for precious assistance in spotting those issues!
Again, a regression fix. Under some circumstance, fFiltering was wrongly
set. Also, the node wasn't open before checking the BRefFilter and some
filters expected that to be.
Regression of hrev44493, file panel crashed when changing dir and
filtering being disabled (sorry!)
Also fix the widget editing when filtering is activated. Now renaming
a file/folder and causing it to 'fall off' the filter does work.
Following hrev44493, the way ShouldShowPose was used changed a bit,
to harmonize with type ahead filtering.
This updates OpenWithWindow to use a BRefFilter to do its
filtering rather than overloading ShouldShowPose.
1. A BRefFilter-ed PoseView wouldn't keep monitoring files after its opening
thus not picking up files that happen to fit the filter thereafter (mime attr
updated, etc..)
2. A filtered PoseView wouldn't get updated when:
a) a column was added or removed
b) a file was renamed
c) a file was moved
3. Harmonize the way BRefFiltering and Type-ahead filtering are working. Both
can be used together.
4. The handler for AttributeChanged() wasn't working properly if link(s) of a
changed model was/were its siblings.
5. Broken links weren't detected/updated (it nows monitor the lost target
parent directory, and wait for the target creation to show the link fixed)
This is a big change (even more considering the 'critical-ness' of the component)
Testing is MUCH welcome!
Should fix#4254, #5381, #1717 (and maybe others)
There were two problems with the last commit:
* the list needed to be outside of the top-level loop.
* BList was just broken for sorting translation_format pointers.
I fixed this by moving the loop outside and converting the translation_formats
to translator_info, which has the translator_id, since that is needed to create
the menu item, and would otherwise be unavailable outside the loop.
I tried to get this working with BList, but the sorting was completely broken,
and converting to BObjectList made the code much, much better and worked great.
Screw BList and casting, hurray templated BObjectList.
Really fixes#6782.
This is used by ShowImage and CodyCam to create a list of image formats which a
file can be saved as. Tracker sorts the image MIME types used in the Find
window by name, so this makes these Save As menus match that (minus the icons
which I think are superfluous.)
Fixes#6782.
If the use of BList is no longer recommended, I welcome better suggestions
for sorting which will work in both GCC2 and GCC4. But this works ;)
Should not be a functional change. It is not in the Haiku Coding Guidelines but
I feel like 'if (object != NULL)' is generally preferred to 'if (object)', plus
in this case of be_control_look that is the more common style.
Added SetFlags(B_CLOSE_ON_ESCAPE) or SetShortcut(index, B_ESCAPE) to BAlerts
depending if the result gets used later in the code, or if it's a one-button
BAlert.
With this commit, app_server now compiles and runs at boot! Nothing
particularly interesting happens, just the blue background and a mouse
pointer. Remote backends are broken and not compiled in, see #8834.
Note that it won't be possible to build this quite yet, need to get
the FreeType package uploaded.
An off-by-one error (> instead of >= really) was causing truncation when it
wasn't needed. But for some reason this only showed up when the main font size
was increased. I may or may not look into that, but this fixes the issue.
Maybe one of the faster bug logged to bug fixed times in Haiku history? ;)
No functional change.
* Surround email addresses in angle brackets.
* Add myself to ExpressionParser.cpp and .h
* Remove myself from ExpressionTextView.cpp and .h
* Alphatetize authors by last name.
Thanks Ingo and Axel.
Figured out by Stephan originally and only hacked in WebPositive, I knew
something about WebPositive was different because it did not flicker when
everything else did.
Since we fully draw the menus there is no need to have app_server fill in the
background with the view color. That is what was causing the flickering.
Should fix#484, #532 and #4335. Thanks diver for confirming the patch against
those tickets.
The ellipsis character (...) after a menu item means that
the command needs more information from the user before
the operation executes.
The ellipsis character doesn’t simply mean that a dialog
box or window will appear.
The window appearing completes the command and doesn’t
require additional input from the user before it executes.
The current behaviour of aligning to the maximum value of p_align seen
is problematic for x86_64, as the default segment alignment is 2MB.
This causes all x86_64 binaries to be padded to at least 2MB when
resources are added to them. There is no need to align to p_align in
the file itself (it's only an in-memory requirement), therefore
instead just align up to an 8-byte boundary. The current behaviour is
retained for ELF32, so this won't cause any compatibility problems
(there are no existing ELF64 BeOS/Haiku binaries to worry about).
Default is radian mode, You set the option in the right click menu
like the other options.
Note: degree mode does not affect hyperbolic trigonometric functions.
This is how Mac Calculator, Windows Calculator, and Google Calculator
work.
Fixed the usual issues - printf format strings, uint32 instead of
addr_t, etc. One thing that isn't so nice is several places where
BList is used to store (u)int32, these require a double cast to addr_t
then void* to silence a warning on x86_64.
The cookie is used to store the base address of the area that was just
visited. On 64-bit systems, int32 is not sufficient. Therefore, changed
to ssize_t which retains compatibility on x86 while expanding to a
sufficient size on x86_64.
Right clicking on a Pose to get the contextual menu would quite often
trigger a rename action of that pose. Don't allow to rename a pose
by releasing the secondary mouse button.
When restored, an overlap was wrongly detected in offsets for
failure to take into account the width of the border line.
This was causing the horizontal scrollbar to show unnecessarily.
A crash of Tracker was triggered when accessing AddOn menu (by
shortcut or context-menu) for Pose on Desktop, because of it's
incapacity to read the mime type list (that wasn't built in
those cases).
