[haiku-bugs] Re: [Haiku] #3385: Open Disks Icon with Single Window Navigation = no draggable folder icon in upper right
- From: "dru_ed" <trac@xxxxxxxxxxxx>
- Date: Wed, 21 Jul 2010 22:02:34 -0000
#3385: Open Disks Icon with Single Window Navigation = no draggable folder icon
in
upper right
-----------------------------------+----------------------------------------
Reporter: mmadia | Owner: aldeck
Type: bug | Status: assigned
Priority: normal | Milestone: R1
Component: Applications/Tracker | Version: R1/pre-alpha1
Resolution: | Keywords:
Blocked By: | Has a Patch: 0
Platform: All | Blocking:
-----------------------------------+----------------------------------------
Comment (by dru_ed):
Thanks for the feedback. I'll look at the style issues you mentioned.
Generally, most changes are to address the specific case of starting or
moving into "Disks" (Root, "/") while in spatial mode and often the fix is
as "simple" as saying "user's in Root", treat it as a special case just
like "Trash."
Addressing these bugs was really about looking at the behavior in fine
detail and doing touchups in the right spots rather than large rewrites
although a rewrite/refactoring of Tracker may be highly desirable long
term.
Regarding the menu changes, I observed if you opened the "Disks" (Root,
"/") window, the "File" menu contents were different than if you traveled
up to Root ("/") from a child container.
Typical contents of the File menu are: Find…, Open, Get info, Edit name,
Duplicate, Move to Trash, Move to, Copy to, Create link, Cut, Copy, Paste,
Identify, Add-ons. Only a few of these make sense in context of Disks,
(Root, "/") and indeed when the opened at the Disks icon, the File menu
contents were more appropriate. Unfortunately, that wasn't always so
depending on how the user reached the location.
Investigating, I found difference in Disks' (Root, "/") File menu content,
depending on how you arrived (dbl-click icon or traveling up by
Navigator), was due to a conflict between the conceptual model of Spatial
& Single Window Mode. In existing code, even the order of the menu items
varied depending on how the user arrived at the same destination.
Spatial mode opened the Disks (Root, "/") window, as a subclass of
ContainerWindow, the VolumeWindow, while other containers used only the
parent class. I couldn't determine a safe or reliable method to
dynamically cast the the existing navigator Window from parent window type
to the child window type and vice versa as needed when traversing,
accordingly I moved the few lines of effected menu code from child to the
parent and added a few conditionals in the existing code. Appropriate
menus now display regardless of whether a user arrived by the icon on
Desktop or via the "Up" arrow on the Navigator toolbar.
The ticket item regarding a new window opening when the user travels to
parent in Single Window Mode was caused by sole reliance upon the "Open
Parent" Spatial code while missing a case where Single Window Mode expects
to reuse the same window. This was fixed by adding code to address use of
the "Open Parent" (ALT+up_arrow_key) menu item while also in Single Window
Mode by sending a BMessage to the window. It was not a bug with the "Up"
toolbar icon because it had not reused the "Open Parent" Spatial code.
Regarding the missing menu bar icons, the original code missed cases
specific to Root ("/") / Disks when in Navigator mode. The solution was
to delete the draggable icon in select cases like Trash & Root to match
desired behavior. The icon cache is used outside these cases for move
containers.
I hope this helps explain the hows and whys regarding my patch. Thanks
for the comments on style. With regards to commented out code, that was
an oversight. I should've removed it before diffing the patch. I look
forward to "porting" it to your updated code.
I should note there are still things to address including determining out
the "correct" or desired conceptual model for Trash and observed
inconsistent use of keyboard modifiers.
At present, as with the old code, Trash is shown as existing at
/boot/trash. This is, of course, not strictly true since it's really a
metafolder with contents from across each /{volume name}/trash
directories. At present a user can traverse "Up" from Trash which
currently means to /boot even though a user opened the Trash icon on the
Desktop and the Trash icon is not presented visually as a Symlink.
Questions arise: should Trash be treated as existing in "Trash" alone and
not offering a particular path, should a user be able to open the "parent"
of Trash and what would that be: /boot?, /{volume name}, ~/ Desktop, or
some other location ?
Regarding inconsistent use of keyboard modifiers, I observed use of Option
(Windows key) while clicking the "Up" arrow on the Navigator Toolbar
results in a different behavior than using Option + "Open Parent" menu
item (or its keyboard shortcut). Both open the Parent in a new window.
However, the Navigator Toolbar method keeps the child window open while
the conceptually equivalent menu item, "Open Parent" closes the child
window when used with the Option key modifier.
So far, I've charted the 36 cases: Single Window Mode (Icon vs. menu
item), Spatial (menu item) each for no modifier, ctrl, cmd (alt), option
(win) across these questions: opens the parent? opens a new window? keeps
the child window open?
Use of the menu item (and its keyboard shortcut) are largely consistent
between Spatial & Single Window Mode. It's the Navigator toolbar which
breaks the mold. The issue is still under investigation.
--
Ticket URL: <http://dev.haiku-os.org/ticket/3385#comment:4>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
