XYplorer Beta Club

phatmankerr wrote:Probably just being impatient but has the development of new Favs functionality been put on the back burner. Or is it just so radical that Donald is spending more time developing it ?

Patience, it's in preparation...

j_c_hallgren wrote:Updated: I just now looked at XED sample...that tab idea would be GREAT!

Yes, I've been thinking of that old idea recently, too! Look here: http://www.xyplorer.com/xed/newfavs.htm
(Click the image to toggle views)

So, we have two possible architectures:

(a) tree above; catalog (favs) below [hideable]
(b) a tree tab and a catalog (favs) tab. [tab headers hideable; there will be shortcuts to switch]

I favor (b) at the moment. Why not?!

admin wrote: So, we have two possible architectures:

(a) tree above; catalog (favs) below [hideable]
(b) a tree tab and a catalog (favs) tab. [tab headers hideable; there will be shortcuts to switch]

I favor (b) at the moment. Why not?!

I too like the option (b), but would still like the tree/favs to be all the way down when info panel is ON.

I agree - option (b) but would be interested to see a mockup with multiple (file) tabs open as well (as we would in efffect then have two rows of tabs).

I think option (b) would be the most practicle and useful, but not sure how it would look

Phat

Having a chance to check in from Charlotte NC tonight...
1) Since XY can be run without installing it, which makes using it on a "foreign" PC possible; however, one may be prevented from altering the screen res there, thus having a design flexible enough for lower res systems may be needed for a power user operating on other than their own system.
2) Having the status bar closer to the file listing seems much more desirable to me, even if it looks a bit odd when full tree used...as the info there is often used in conjunction with the details listed so having to visually "go around" the Info panel is the downside...
3) I definitely like the tabs of Tree/Fav! (That is opt "b")

phatmankerr wrote:I agree - option (b) but would be interested to see a mockup with multiple (file) tabs open as well (as we would in efffect then have two rows of tabs).

Hm, very good point! Too many tabs indeed (I mocked it up in my head). Why not do it without interface then! There's the tree or the catalog, filling exactly the same space, and you toggle by shortcut, by menu command, context menu command, toolbar button. That's the coolest.

j_c_hallgren wrote:1) Since XY can be run without installing it, which makes using it on a "foreign" PC possible; however, one may be prevented from altering the screen res there, thus having a design flexible enough for lower res systems may be needed for a power user operating on other than their own system.

Definitely! The "full tree" will be optional only.

j_c_hallgren wrote:2) Having the status bar closer to the file listing seems much more desirable to me, even if it looks a bit odd when full tree used...as the info there is often used in conjunction with the details listed so having to visually "go around" the Info panel is the downside...

Same here! The XY status bar belongs to the list rather than to the app, so it should be close to the list. It's list status, not app status.

But unfortunately it does not work in conjunction with full tree. So, if I add optional full tree then I might auto-move down the status bar only if full tree is active.

The 'no interface' idea works, but for me that is a two click solution (rarely use keyboard shortcuts and don't have the toolbar showing).

This is sheer laziness on my part but what about allowing us to have another special tab (like search) that when selected changed the Tree view to Catalogue view (sorry English spelling - I actually prefer the US Catalog).

Don't worry if this is a programming nightmare (or whether the refresh of the tree / catalog would be too slow ?), just a suggestion to streamliine the interface.

Cheers

Phat

I was thinking about favorites as a part of the treepanel, not a seperate panel. In this way I can make a tab with the favorites tree root as home for that tab.
But thought some more about it and...mmwah.. maybe not that good after all. Well, I desided to share it anyway.

A picture:

CyGho wrote:I was thinking about favorites as a part of the treepanel, not a seperate panel. In this way I can make a tab with the favorites tree root as home for that tab.

Yes, I have about that, too, but opted against it for a number of reasons.

The interrelation between catalog and tabs raises interesting questions. Right now changing a tab will trigger a new tree location, which will trigger a new list location upon completion (arrival). The catalog, however, will work directly on the list without intermediate tree action (and thus be much faster). Interesting question: what happens to the catalog on tab change? I'd say: nothing at all. Or if (see next paragraph...) anything is selected in the catalog, then a tab change would simply unselect any catalog selection.

I'm not sure yet if the catalog will reflect a "current state" (show you where you are) at all. Difficult because: what e.g. if you move to a subfolder by dbl-clicking a folder in the list? Wouldn't it be irritating if the catalog lost its current selection by this action? On the other hand: if the catalog does not tell you whare you are, who does??? Only the window title bar? The address bar is optional, and the tab headers (optional, too!) are usually too truncated for this job. I personally refer to the tree when I want to make sure where I am... Without a tree I'm lost... hmmm... you see. This catalog thing is not really thought through yet. It will be the next revolution in browsing but it still has to ripen...

admin wrote:On the other hand: if the catalog does not tell you whare you are, who does???

This is an easy one to answer in my opinion. There is nothing to tell because the user who is clicking on the favorite knows where he/she is going after clicking. He created the favorite after all. It's an action and the user knows what the result will be. He isn't clicking on it for nothing isn't he? Its'not something like "oh yeah, suprise me, take me somewhere", nope, he wants to go there

Know it has been raised in another thread, and the program in question doesn't have an info panel, but the Groups function in ExplorerXP seems to be the best layout to me (seperate panel below the tree view) - which does show the location in the tree for a selected group (although obviously the tree view in ExplorerXP is not as cool (or as functional) as XYplorer's.

phatmankerr wrote:Know it has been raised in another thread, and the program in question doesn't have an info panel, but the Groups function in ExplorerXP seems to be the best layout to me (seperate panel below the tree view)...

That is definitely my preference, too. I used to use ExplorerXP quite a bit and it's tree/groups layout was great (perfect). Like you said you can see both the tree and catalog at the same time, and if you want more tree just hit the "hide catalog" hotkey or toolbar button.

admin wrote:I'm not sure yet if the catalog will reflect a "current state" (show you where you are) at all.

My vote for that is a definite no. In my mind the catalog shouldn't change selection based on where you are, that would be slightly goofy.

CyGho wrote:

admin wrote:On the other hand: if the catalog does not tell you whare you are, who does???

This is an easy one to answer in my opinion. There is nothing to tell because the user who is clicking on the favorite knows where he/she is going after clicking. He created the favorite after all. It's an action and the user knows what the result will be. He isn't clicking on it for nothing isn't he? Its'not something like "oh yeah, suprise me, take me somewhere", nope, he wants to go there

But
(a) you don't browse by catalog only, but also e.g. by tab change, or by clicking a folder link
(b) when you come back to XY after some hours on the beach, do you still know which favorite you clicked before?

JustinF wrote:

phatmankerr wrote:Know it has been raised in another thread, and the program in question doesn't have an info panel, but the Groups function in ExplorerXP seems to be the best layout to me (seperate panel below the tree view)...

That is definitely my preference, too. I used to use ExplorerXP quite a bit and it's tree/groups layout was great (perfect). Like you said you can see both the tree and catalog at the same time, and if you want more tree just hit the "hide catalog" hotkey or toolbar button.

Yes, definitely an option (option (c)). Although that would mean the tree has to do browse work as well. I still would prefer to bypass that.

BTW: I noted that ExplorerXP has a very fast tree. Reason: it does not verify the existence of subfolders of a node but simply assumes subfolders by putting a "plus"-symbol to every node. If the assumption proves wrong the "plus" vanishes on clicking it -- puff.