Fixes BCursor tests. Thanks Karvjorm! And sorry for the delay.
I also re-enabled the tests in the Jamfile (cf. r41788)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42955 a95241bf-73f2-0310-859d-f6bbb57e9c96
new asynchronous mouse tracking. Sorry for the delay. Up to now it was needing
mouse moves to autoscroll, it now behaves as before.
* Removed check that was disabling regular drag'n'drop auto-scrolling when
inactive. I don't see an obvious reason why that was done, as it's just handy
and is consistent with the other behaviors when inactive.
Note, i gotta love those comments that do anything but help, good example of
how not to comment :) i.e don't comment about what will happen when the
adjacent code won't be executed (especially in a case that can't happen).
My brain almost exploded a second time trying to explain that!
// selection scrolling will also work if the window is inactive
Should read:
// disable drag'n'drop auto scrolling when window is inactive
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42447 a95241bf-73f2-0310-859d-f6bbb57e9c96
This especially avoid bringing tracker windows up to front when staying idle
over a tracker window while holding down a button. This could happen when
hovering while still holding a scroll thumb of another overlapping window.
Fixes regression #7829 introduced in r41892
* Also properly reinitialise the cached dragMessage on B_EXITED_VIEW,
otherwise it would still think it is dragging and thus still pass through my
above fix.
I'd like to cleanup the drag message caching mechanism as it's not
pretty in my opinion. Possibly even adding it to BView.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42441 a95241bf-73f2-0310-859d-f6bbb57e9c96
would never get a chance be visible again.
When instanciated from an archive, a BDragger restores its
BView::fShowLevel and thus can already be hidden if archived while hidden.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42137 a95241bf-73f2-0310-859d-f6bbb57e9c96
or long click happened between the initial mouse down and the present mouse up.
Tried to avoid this solution by other means but wasn't working in a corner case,
at least it's clear what's the code is doing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41934 a95241bf-73f2-0310-859d-f6bbb57e9c96
used to work before, i.e right mouse button dragging works and the context
menu shows on mouse up if not dragged. I guess that at some point we'll rethink
all the mouse gestures we support and maybe simplify a bit, like dropping
long click support (as an emulated right button), and possibly
separating some features via user settings if needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41929 a95241bf-73f2-0310-859d-f6bbb57e9c96
The new asynchronous tracking doesn't lock the view and makes desktop
replicants happy while clicking and dragging around. Fixes#880, #7241
and certainly other tickets, that i will revisit, about refresh locks
on the desktop or mouse related bugs. Based on a reusable MessageFilter and the
recent B_MOUSE_IDLE message. Some parts are ported from the old code
and could use further simplification.
There should be no intentional user fonctional change, except:
- slightly bigger threshold radius, shorter duration thresholds
(= 1.0 x the system-wide doubleclick setting)
- not reimplemented: quickening threshold when holding shift while dragging
a pose over a destination pose.
Some parts are ported from the old code and could use further simplification.
There is one known minor regression with autoscrolling while
rect-selecting but that will be better fixed with some changes to the
autoscroll code. Will address that ASAP. As for the unknown regressions,
please test :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41892 a95241bf-73f2-0310-859d-f6bbb57e9c96
Slight modifications to the patch:
Put back passing the view names (eventhough it seem useless atm).
One or two small indenting issues.
Implemented your todo (listview width adapts to the longest item).
Thanks a lot.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37978 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've found more occurences but i will solve it differently since they are about finding messageless submenus.
Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37974 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Functional modifications:
Reworked InfoWindow file size localization, the patch removed number formating (size in bytes) and was too complicated to my taste.
Replaced the uses of sprintf with the safer snprintf.
Changed signature to x-vnd.Haiku-libtracker instead of x-vnd.Haiku-libTracker (to be consistent with the binary name)
* Style modifications:
Reworked lots of 80 char indenting (probably due to the now shorter line lengths since your previous patch that wasn't using the macros)
Lots of missing brackets when "if's" becomes multiline.
Other minor fixes.
Noticed a few uses of FindItem on translated names that might become problematic someday. Added some TODO's regarding localization of file sizes. Localization might still be
optimized a bit regarding the produced en.catkeys
Note to translators: .catkeys files should be placed in haikusource/data/catalogs/kits/tracker though beware as the base en.catkeys might change
slightly in the next days.
Note to users: As with any other app you need to restart Tracker (or any aother app using libtracker's filepanels) for it to pick the locale setting. E.g: use 'quit an
application' and 'restart Tracker' from process controller.
Thanks a lot T.Murai
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37492 a95241bf-73f2-0310-859d-f6bbb57e9c96
I took the conservative approach and the penalty is really minimal if even not at all perceptible as i've measured. I decided to go this way as PoseView code is very fragile and depends on many of those "loose assertions" to be valid. This conservative approach also allows to confidently include the fix in alpha2:
+alphabranch
Besides those "wise" reasons, the thing is that i've wasted too many hours already this week and in the past due that VSPoseList/PoseList syncing fragility. I'm not willing to fix the optimisation of a broken design that i've already experimentally rewriten two times already, and that i (or any mentally sane person) will finally ditch sooner or later :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36592 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've been investigating the issue in depth, it's there since the first opentracker revision, so i even installed R5 and built/debugged opentracker to confirm it was indeed needed on R5. That would be another case of undocumented (misdocumented) workaround for an R5 bug, ie: BMenu would steal the drop message although the mouse isn't over it anymore (Stefano idea?). Heh if only i could reach the original Tracker devs :-D
I don't like when i don't understand a problem up to the last bit, but it should be reasonably safe for alpha2 +alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36516 a95241bf-73f2-0310-859d-f6bbb57e9c96
When using find_directory(B_TRASH_DIRECTORY... to check if an entry is in the trash one should always pass the entry's volume otherwise you might be checking in the wrong trash.
Might happen elsewhere in the tree, will have an opengrok look.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35826 a95241bf-73f2-0310-859d-f6bbb57e9c96
* took the opportunity to do the same for all occurences as reported by OpenGrok
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35600 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use \w instead of [a-zA-Z0-9] in some regex's
* Add switch to the "space after control statement" rule
* Added pointer/reference style rule
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33921 a95241bf-73f2-0310-859d-f6bbb57e9c96
origin. Yes.. shame on me, i had even imported their non unix line endings :)
Will make them BCitizens soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33890 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refined some rules to not include the new-line
* Added 'windows line ending' rule
* Enhanced the html output, not an expert there though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33889 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added an html report output with highlights and tooltips
* Still a few false positives and rules missing. Some regex could be reworked
* TODO: ignore some rules when in comments, multifile support
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33856 a95241bf-73f2-0310-859d-f6bbb57e9c96
renamed files. After more investigation i found out that the problem was
caused by a non usual use of the zombie list in r31307. In the conditions
to reproduce #4130 it would call AttrChanged() or StatChanged() on zombie
poses which by convention should always be invalid models, ie: null node.
The logic would potentially create other problems too as it wasn't only
adding refFiltered models to the zombies.
I reverted part of r31307, clarified the logic and updated the comments.
I'd prefer another implementation for this as reusing the zombie list
here is only calling for future mysterious problems. #4131, #4271, #4610
and #4831 are still closed, but i'm reopening #1717 which is more of an
enhancement btw.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33769 a95241bf-73f2-0310-859d-f6bbb57e9c96
busy processing other things, the file could be gone by the time we processed
the fs notification message of the entry creation. This case wasn't handled
properly and would cause #4130 and most certainly duplicate #4831, #4610 and
also possibly #4271.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33744 a95241bf-73f2-0310-859d-f6bbb57e9c96
define the app_flags in the rdef, case that isn't well handled apparently
when creating a BMessenger targeting the app.
Thanks to Michael and Rene for helping! Fixes#4712
* Removed unneeded and faulty App::MessageReceived and a strange (probably
copy pasted then forgotten) MainWindow::QuitRequested.
* Minor changes. Made App destructor virtual, moved init into ReadyToRun,
fixed a few style violations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33474 a95241bf-73f2-0310-859d-f6bbb57e9c96
* A test app for it. I added a src/test/kits/shared folder as i found it was the
most logical place for it. Shake it up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32602 a95241bf-73f2-0310-859d-f6bbb57e9c96
making the check fail when Pose::Draw was called with a non zero offset.
Fixes#4289
* Fixed an x/y typo (that had no really visible effect, the fade effect might
need some more indepth review)
* Removed dead code, and replaced an inlined intersection check with
BRect::Intersect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32538 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't depend on the 'node flavor' of the parent filepanel.
Fixes#3624
* Minor style fix
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32530 a95241bf-73f2-0310-859d-f6bbb57e9c96
and is based on the pose selection time, not on click time. It is more
robust and since the selection might have been by click, keyboard or
selection rect, it makes the behavior very pleasant (in my opinion) for
multiselections. Try and tell me!
* Disabled the modifiers (first click editing). Too many of them, and
conflicting with other usages, i'd like your opinions/preferences.
* Removed old, hackish and now unused DelayedEdit/SetDelayedEdit stuff.
Fixes#3617
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32529 a95241bf-73f2-0310-859d-f6bbb57e9c96
couldn't find a quick solution that wouldn't need the layouting rewrite
(currently in redesign phase in my branch)
* In the mean time i've added desktop element avoidance in Cleanup so one
can easily recover hidden icons without advanced shortcuts. Before that, it
would need a CleanupAll aka shift-alt-k (which would relayout everything btw).
Doesn't fix#4241 but at least provides a way to see your icons again easily.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32523 a95241bf-73f2-0310-859d-f6bbb57e9c96
icons. Haven't looked into R5 backward compat.
* Minor style fixes, more in the next commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32269 a95241bf-73f2-0310-859d-f6bbb57e9c96
future 3d demos i have in mind and the missing ones (ie: 3dmov and 3dmix).
Makes for a nice Haiku sample code too, without legacy.
Not in the image yet, waiting for the green light. Enjoy!
ps: Will commit the Blender object files and export script later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32027 a95241bf-73f2-0310-859d-f6bbb57e9c96
I use this to cleanly switch between my dev Tracker and the trunk one. I need
to wait until it has really quit before overwriting and running another
version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31852 a95241bf-73f2-0310-859d-f6bbb57e9c96
fViewState didn't change, fTitleView wouldn't be reset and updated to the new column set. (unfortunately the column
state is managed separately from the rest of the view state). That would cause crashes for example when switching
to a directory with fewer columns and triggering a redraw of a column that shouldn't be there anymore.
Fixes#3710.
* TitleView::Reset didn't invalidate the view and would leave the old columns there until a redraw was
triggered externally.
* Minor cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31378 a95241bf-73f2-0310-859d-f6bbb57e9c96
endpoints names would be broken and "Save Nodes" would create a broken file.
Open/Save nodes now works (again?) and endpoint names display correctly in info
windows/views.
That detail is fixed but it's the design of Cortex that's broken here really :)
To be continued... some day
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30539 a95241bf-73f2-0310-859d-f6bbb57e9c96
kits/shared since i plan to use it in other places like Tracker. Animated replicants like
ActivityMonitor wont stall anymore when initiating the drag. (On the desktop, Tracker's mouse
tracking still busy loops sometimes, that's next on my list).
I had asynchronous long click detection (one button mouse support) in it but decided to get rid of
it, it adds unneeded complexity in the code and is even getting in your way sometimes (ex: now you can
take your time to drag the dragger, you wont be interrupted). If we want to reimplement that
someday it should be done system wide anyway (only Tracker and replicants have that 'feature'
AFAIK).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29972 a95241bf-73f2-0310-859d-f6bbb57e9c96
custom provided one. Incidentally makes #1775 (that i'll reopen in a moment, see r29947) a
lot less likely to happen for most users since it can now only happen with those
customized popups.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29949 a95241bf-73f2-0310-859d-f6bbb57e9c96
the popup's window, in this case the window just closed, so we go on with archiving then.
There's still a (rarely occuring) problem with the unlocking though, probably due to some
BMenu funkyness, will investigate, left a TODO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29947 a95241bf-73f2-0310-859d-f6bbb57e9c96
already identified files and change the menu item label accordingly so that the 'feature' is
not hidden anymore.
The identification mechanism will probably be automated in the future, forcing
identification would then become the only use of this menu item.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29940 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made the drag detection less sensitive as most simple clicks would initiate an unwanted drag.
* Don't show the dragger's popup from its original parent window (not a shelf) for all buttons, as in R5.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29727 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved new statics to the cpp file as it seems we don't usually expose such internals in our public headers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29443 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't delete fStream if we don't own it, would crash ShelfTest on quit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29439 a95241bf-73f2-0310-859d-f6bbb57e9c96
each addition, which is o(n). It's already refreshed lazily on read, only rarely when ContainerWindow updates
his menu.
Now there's only one recalc when finished adding poses, 9ms for 20K files here.
Pose adding is almost linear now for the first thousand files, but it gets worse after that due to
another known problem. Now doing 35s instead of 80s on a 20K files folder here, more to come :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28891 a95241bf-73f2-0310-859d-f6bbb57e9c96
reaching the file descriptor limit. For some still unknown reason, this was causing GetNextDirents to stop returning new
entries. The result was that, on populated folders, Tracker wouldn't load all poses and stop at a random amount.
We now take a more conservative approach and close the files before sending, reopening them on reception.
Now the AddPoses thread is a bit too aggressive, especially on second runs, i needed to add some snoozing otherwise it
would stall Tracker for several seconds. (testing on a 20000 files folder).
This fixes#3054
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28872 a95241bf-73f2-0310-859d-f6bbb57e9c96
DrawViewCommon(), simply invalidate since the logic is simplified now,
see below.
* Reworked the way TimeAttributeText was updated when date format is
changed. Got rid of the recalculatText flag propagation, it was broken
since forever anyway (was here on r5 max4.1): It was only updating
visible poses and wasn't robust in certain cases. Besides, it was
cluttering the code on several layers upfront only for date format changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28402 a95241bf-73f2-0310-859d-f6bbb57e9c96
tracker prefs via the preferences menu using a one line script: 'hey Tracker DO
Preferences'. Not sure how to set the icon of the script with the build system, feel
free to do it. See enhancement #2365
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use a derived text view that filters the tab key to avoid interupting tab
navigation while in focus/editing. Closes#2321
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28328 a95241bf-73f2-0310-859d-f6bbb57e9c96
rethought and reimplemented with the layout system and my keymap management patch, but
the intent was to make it more usable in the mean time.
* Don't change the focus on keydown so that we can naviguate the list with the
keyboard.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28314 a95241bf-73f2-0310-859d-f6bbb57e9c96
things could be rewritten in a cleaner way but i'd rather finish my keymap
management patch as i rewrote the preflet for it anyway. For example the '(Current)'
item shouldn't be needed anymore but is still there in case the keymap:name attribute
read fails or if the original keymap file doesn't exist anymore (for example, applying
a user keymap, quiting the preflet, deleting the keymap file, and reloading the
preflet)
* Revert/apply data wasn't correctly loaded when the first load was on a system
keymap. This would allow revert/apply right after starting the preflet. That was the
cause of #2659.
* fCurrentMapName wasn't updated after a Revert or Apply
* Select the active keymap in the lists after reverting.
Quick cosmetical fix follows.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28313 a95241bf-73f2-0310-859d-f6bbb57e9c96
This was the cause of #2571 and duplicate #2888 although the bug wasn't
triggered anymore since r28205.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28274 a95241bf-73f2-0310-859d-f6bbb57e9c96
would scroll to (0, 0), and screw the now always-in-sync fViewState.
After testing every possible mode transition, there seem to be no side
effect as the comment would suggest. Stippi, do you remember why it
was necessary? See r18699.
* This enabled me to do my previously added TODO's.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28231 a95241bf-73f2-0310-859d-f6bbb57e9c96
The method was called after _sending_ all the messages, not after receiving
them all. This fixes the scroll validity check in AddPosesCompleted in list
mode (bug mentioned in my last commit).
We can now close#2441, tracker windows should now be completely persistant
with regard to scrolling now, in all modes (spatial mode, single window
mode in list or icon mode). \o/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28210 a95241bf-73f2-0310-859d-f6bbb57e9c96
list mode) or switching dir in single window navigation. Fixes the other half of the problem in #2441. Left some
todos.
I discovered an other bug that can add a random offset after finishing adding poses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28205 a95241bf-73f2-0310-859d-f6bbb57e9c96
successfully loading the saved state. Reworked the logic to make that work properly (this also needed checking if the state read succeeded). This
fixes part of #2441. There is still an issue when sometimes the view state is not saved properly, more tomorrow!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28158 a95241bf-73f2-0310-859d-f6bbb57e9c96
Alexandre Deckner