Some interesting behaviors about stacked folders.

Some interesting behaviors about stacked folders.

1)

Add a folder to the desktop, and inside it add another folder and set its id to the same as the main one (aka a ‘folder inside itself’).

1a)

Set the folder to auto close.

When you open the folder from the desktop, clicking the folder inside the opened one closes the folder and reopens it.

However, when opening the folder again, it is not closed and they stack.

1b)

In the hierarchy screen, now you can open as many folders as you want (maybe this is unavoidable, the same with stacked panels) but it is a good way to discover that if the padding is big enough, the text disappear and you can only see a blank item. Maybe force a minimum text width?

2)

Add two folders on the desktop with the same id (both opens the same one).

2a)

Clicking one folder and then the other opens two instances of the folder. Not sure if this behavior is the good one. Should the folder close? Should it close/open? More discussion required.

Comments:

It seems as if the ‘windows’ remember from where they were opened, and they only share the container inside. Maybe this is a bit absurd but what if the window folder properties were attached to the shortcut instead of the container? This will allow to have the same folder but with two backgrounds, different sizes…but I’m sure it will cause a lot of problems too. Just a comment anyway.

]]>

One Commentto Some interesting behaviors about stacked folders.

  1. Anonymous says:

    < ![CDATA[

    Regarding 1b the issue is more or less the same with long names: the text cannot be read. Maybe the recursion level should be limited or the indent capped, but I am not sure that the issue is the blank item or more than 10 nested containers 😉



    1a), 2a) and your comments are linked to the same topic. In short: folders window parameters are stored in the opener item, not in the container itself. Thus allowing a single set of items to be displayed in distinct windows (or boxes in case of panels) with distinct background, borders, auto close option, etc.



    The thing is that the settings screen doesn’t allow this. At the moment, when editing a container, it tries to find the first opener folder item and assumes this is the one to use to store window options and other related settings. This was working in the past, but not anymore since there can be multiple openers. Also in v14a3 there are many issues with folder/panel distinction in menus, adding some confusion.



    Instead of displaying folder options in the container settings screen, these settings should now be displayed in the item properties box, just as the icon, text, etc. tabs. With the “custom” checkbox, which is by the way not visible currently, even if it should! However I fear that it will add one more tab to an already crowded property box.



    This explains why the second folder doesn’t auto close: it’s opener hasn’t be configured with this option even if the settings screen let you think yes, in reality it displays the settings for the other folder, the first one found. But changing properties through script will work 🙂



    I really want to allow two instances of the same folder. Ultimately, I would like to allow overriding of container and item properties from the folder (for instance set the number of columns).

    ]]>

Leave a Reply

Your email address will not be published. Required fields are marked *