Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2771 closed bug (fixed)

Opening files by dragging to Deskbar

Reported by: humdinger Owned by: zooey
Priority: high Milestone: R1/alpha1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All


This is on vmware, hrev27404.

Say, you have Pe running.

Drag&drop of a text file on its entry in the Deskbar should open the file in Pe. It doesn't.

Drag&drop the text file on Tracker's entry in the Deskbar should open the file in text/plain's preferred app (StyledEdit). It doesn't.

Oh, and with all the dragging action, there's still #1813.

But: Drag the text file on Tracker's entry in the Deskbar and then move on and drop it on the (Leaf) Deskbar Menu and it opens in text/plain's preferred app (StyledEdit).

Dragging it onto the Deskbar and navigating through the Deskbar menu to Applications to drop it on StyledEdit works.

Change History (10)

comment:1 by axeld, 12 years ago

Component: Applications/DeskbarKits/Interface Kit
Milestone: R1R1/alpha1
Owner: changed from axeld to jackburton
Priority: normalhigh

I've investigated a bit, and the feature works fine if the Deskbar is in compact mode. In the normal mode, menu tracking also doesn't stop when releasing the mouse button, instead it enters sticky mode (MenuBar.cpp, line 573).

Unfortunately, the menu code is nothing I would understand just by looking at it :-/

comment:2 by jackburton, 12 years ago

Are we sure it used to work on beos ? Because if it did, it's a bug in BMenuBar, otherwise it's a bug in Deskbar.

comment:3 by axeld, 12 years ago

It definitely works fine on BeOS.

comment:4 by axeld, 12 years ago

The investigation above should also clearly point to the bug: it just must not enter sticky mode when dragging stuff around, at least I can't see how this could ever be correct.

comment:5 by jackburton, 12 years ago

Well, the menu code has no concept of "dragging", anyway. The bug could have been exposed by the fact that our BMenuBar behave a bit differently than beos: it selects items not only when the mouse button is pressed, but also when it's released (this is only a speculation, I didn't dive into it very much).

comment:6 by jackburton, 12 years ago

I had a look. The problem is that BarView sets the _menu_info_ptr_->click_to_open flag to false. This flag is used in the beos implementation to check if a menu is sticky or not (there was a static BMenu::IsStickyPrefOn() method, which we removed since we decided that non-sticky menus didn't make sense). So our implementation doesn't check that flag at all. By the way, the fact that BarView uses that private variable isn't that nice, we should try to fix it in a different way, if possible.

in reply to:  6 comment:7 by jackburton, 12 years ago

Replying to jackburton:

I had a look. The problem is that BarView sets the _menu_info_ptr_->click_to_open flag to false.

In BarView::DragStart(), btw.

comment:8 by zooey, 12 years ago

Owner: changed from jackburton to zooey
Status: newassigned

comment:9 by stippi, 12 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev28063.

comment:10 by humdinger, 12 years ago

It's indeed fixed. Thanks. Looks like it also solved #1813.

Note: See TracTickets for help on using tickets.