After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 317531 - use gnome-fs-directory-accept for "unrolled"/open folders
use gnome-fs-directory-accept for "unrolled"/open folders
Status: RESOLVED WONTFIX
Product: nautilus
Classification: Core
Component: Views: List View
2.12.x
Other All
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-29 15:14 UTC by Jakub Steiner
Modified: 2005-09-30 15:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Proposed patch (1.90 KB, patch)
2005-09-29 21:49 UTC, Christian Neumair
none Details | Review

Description Jakub Steiner 2005-09-29 15:14:05 UTC
The new and lovely nested list view uses closed forlder icons even for folders
with the disclosure triangle reveling the content. I am thinking it should show
an open state intead. the -visiting state implies the folder is opened elsewhere
so I'm guessing -accept is more appropriate.

Other information:
Comment 1 Christian Neumair 2005-09-29 21:00:04 UTC
That sounds very reasonable and shouldn't be too hard.
Comment 2 Christian Neumair 2005-09-29 21:49:22 UTC
Created attachment 52830 [details] [review]
Proposed patch

I've also submitted this patch to the nautilus mailing list [1].

While I agree with you that the default icon them "accept" icon is more
appropriate, I fear that 3rd party teams only assumed that it's used for
dragging purposes when they created it, which may imply that these are not very
appropriate for this particular use case. We might want to have 3 icon states:
"visiting", "accept" and "visiting-shaded" (formerly: "visiting").

If you are sure that at least 75% of the icon themes out there have an "accept"
modifier appropriate for expanded nodes, I'm also willing to use "accept"
instead.

[1] http://mail.gnome.org/archives/nautilus-list/2005-September/msg00210.html
Comment 3 Christian Neumair 2005-09-29 21:50:23 UTC
Oh, I forgot to explicitly state that I used the "visiting" modifier for now,
although that should be quiet obvious from my line of argumentation :).
Comment 4 Jakub Steiner 2005-09-30 11:40:21 UTC
I agree with you on the poor naming. A state for accepting a drag and open
folder _may_ be confusing. On the other hand, a drag target is also highlighted.
Ideally (and with the new naming standard) the names should be more humane and a
lot of states could be done programatically:

- normal
  - open (also used for drag accept, but drag accept could 
          additionaly light up or something)
  - visiting (for the spatial mode when a folder has a 
          window open somewhere) 
- hidden (simply have alpha 0.5 for all states)
Comment 5 Alexander Larsson 2005-09-30 13:52:59 UTC
I don't like the way the patch handles this. Visited icons mean a very specific
thing, namely that there is an open spatial window for the location. The patch
even makes the use of the visiting icon inconsistent, as if you expand a folder
that folder doesn't show as visiting if its parent is visible in another folder.

Furthermore I think using an open icon for the folder when the row is expanded
is a bad idea, since that means you can't see whether its a drag target or not.
Comment 6 Jakub Steiner 2005-09-30 15:09:23 UTC
I'd rather have the drag accept state be done programatically (brighten?) out of
the open folder state than creating an additional icon state as we already have
way too many folder states.

Maybe we just need a folder icon consisting of two 3d panes and have the drag
accept and open states be animated in GL :)
Comment 7 Jakub Steiner 2005-09-30 15:10:58 UTC
But to be honest, at a price of adding yet another state to the folder icon, I'm
applying stop energy.