Dual Pane - Formal Proposal Thread

[Mesh]

For those of you who have been following this thread: http://www.xyplorer.com/xyfc/viewtopic.php?t=1979

...Don has been kind enough and generous enough to agree to implement Dual Pane into XYplorer 8.0, providing that the users interested in DP can agree on a clear and simple concept.


I started this thread for the purpose of having a clean place to discuss this. This first post will contain the DP parameters that are currently on the table, and I will update them to reflect the results of our discussion.

I'll start this off with the initial list of requirements that I posted in the other thread, and update as needed.



Dual Pane Proposal - v1.22
Last updated - 2008-11-24


Main Features


Quick to turn on and quick to turn off

XY should be able to switch quickly and cleanly from single pane to dual pane and vice versa. It also needs to be able to do this via keyboard shortcuts.


Resizeable panes

Self explanatory, you should be able to drag the boundry where you need it, and have an easy way to reset it to the default halfway point (such as double-clicking the boundry point).


Seperate trees for each pane

Each pane needs to have it's own tree, for various reasons of efficiency (see original thread, referenced above).

However, as some people prefer a single shared tree, XY should give users the choice of single or seperate trees.


Last used Tabs for the second pane

There should be a general configuration option for XY to behave in one of two ways:

Option 1 - Restore the exact tabs that were last used with the second pane. If one of the directories doesn't exist, XY can behave as it currently does (just don't generate a dialog box error).

Option 2 - Always open the second pane with a single tab, and allow users to configure which directory this tab should always start in. If this directory can't be found, XY can behave as it currently does (just don't generate a dialog box error).


Methods of differentiating which pane is active

Even if you have a seperate tree for each pane, you still need to always have one pane set as the active pane. This is necessary to account for many actions that could be executed - KB shortcuts, for example. However, personally, I find it extremely annoying when the entire background of the pane changes color to indicate this. As I said in an earlier post, I feel like I'm about to have an epileptic seizure when I'm constantly switching from one pane to the other.

PowerDesk Pro has a good implementation of this - it has a single header bar for each pane which lists the path of the directory that's active in that pane. The active pane has that bar shaded in gray. This way, it's easy to tell which pane is active, but it's a subtle change when you switch from one to the other.

With XY's use of tabs, it may not be necessary to indicate which pane is active - only which Tab is active. If this approach is taken, one idea is to allow users to configure the color of the tab stripe of the active tab.

Some users would prefer to configure the background colors of the active and inactive panes. As XY already allows you to customize many of the colors, including the pane color, it should be easy to add both of these options.


Proper integration with the file manager's features

Simply put, anything you can do while in single pane mode, you should be able to do in dual pane mode - with respect to the active pane. This is how the Address Bar, Toolbar, etc... would work. The file manager should never need to be crippled when working in dual pane mode, and each pane should be treated seperately. Additional actions can be implemented that will affect both panes, but this should not take away the default actions that work on a per-pane basis.

For example: As it pertains to XY, Shift-/ closes all branches except the active one. If you're in dual pane mode, Shift-/ should only work on the active pane. If it's desired, an additional KB shortcut can be implemented that will do this in both panes simultaneously - but not at the expense of the default option of acting on only the active pane.


Synchronized Scrolling

This feature is one that would be turned on or off as needed. The base function of this feature, when enabled, will allow the dual panes to scroll in synch. If the two panes have a different number of files, the scrolling on the inactive pane will be proportional (i.e. when you've scrolled to the halfway point of the active pane, the inactive pane will also be at the halfway point).

If you select a file/folder in one pane, and the same item exists in the other - the inactive pane will move the focus to the matching item, and automatically scrolls as necessary to put the matching item in view.

If you select multiple items, each matching item in the inactive pane will also be marked, and the inactive window will autoscroll to the most recently matched item.

If you subsequently click in the inactive pane, without cancelling your selection in the first, the inactive pane becomes active and all the marked items retain their selections so that you can act on those files.

Although items may be simultaneously selected in both panes, any actions taken (such as deleting files) will only affect the active pane, unless a special command is created specifically designed to work in both.


Visual Comparison Filter

This feature would let you select which criteria (or combination of criteria) to use as a comparison of the two panes, and you would have the following choices:

1. Show only matching items, based on the criteria selected.

2. Hide matching items, based on the criteria selected.


Criteria (Suggestions requested for other important criteria):

1. File name (Text box - entries of "*", "*.*", or leaving it blank will only match file names that are completely identical. However, this field should have the same functionality as the current "Set Visual Filter" feature, which means that pattern matching with wildcards and RegEx would also be supported.

2. Modification Dates

This is really just an extention and enhancement of the current "Set Visual Filter" feature. To be honest, it can use the exact same style dialog box, as long as support is added for the "AND" boolean, as well as extended items (i.e. Modification Dates, Attributes, etc...).


Keyboard Shortcut Actions

Adding appropriate actions that can be assignable to keyboard shortcuts, such as "Copy to other pane" and "Move to other pane". These commands would be based on files/folders selected in the active pane, and would copy/move to the inactive pane. However, if Don should be ambitious enough to add the ability to have three panes, good luck figuring out how these commands should be targeted. Also, the action of switching which pane is the active one.


Scripting Support

Appropriate support within scripting to reference specific panes, if desired.



Special Details


Status Bar

There are good arguments for both a shared or dual Status Bar. The dual Status Bar gives the most information, however, it takes up additional space when using DP in top-bottom mode, and the available width is halved in left-right mode. Therefore, this will need to be a user-configurable option.


Tab Implementation

Each pane would support tabs independently. Features such as Home Location, Locking, Iconify, etc... that are designed to work on a per-tab basis will continue to work in that way. The Default Tab feature has a limit of one tab - but it makes sense for this to be set independently for each pane. Search Result tabs could exist on either pane and would be based on the active pane at the time the search is run.


Catalog

For simplicity's sake, there will be only one Catalog (insofar as its contents), unless Don changes this in general for XY. For simplicity's sake, we can retain the current implementation of a single Catalog pane, which would work as it currently does, and act on whichever Tab is active (regardless of which pane it's in).

It will show up as it does now - as a docked pane that pops up at the bottom of the tree pane. In top-bottom DP, it would show up in the bottom of the bottom tree (if using seperate trees), and in left-right DP it would show up in the bottom of the left tree


Info Panel

There should be a user-configurable option for either a single shared Info Panel, or dual Info Panels, as there will be significant variation in people's preferences here.


Scroll Wheels

Currently, XY scrolls whichever pane the mouse cursor is hovering over (e.g. the file list pane or the tree). This behavior should remain consistent with the addition of the second pane, so that the cursor location determines which pane (or the tree) is scrolled when a scroll wheel is used.



----------------------------------------------------

Version History

1.0 - 2008-04-01 - Mesh's original list
1.1 - 2008-04-01 - Added sections on Status Bar and Tab Implementation. Edited Tab Implementation.
1.11 - 2008-04-01 - Modified and renamed "Last used directory for the second pane" to account for each pane supporting Tabs
1.12 - 2008-04-01 - Removed "Remembered configuration for the second pane" section - it was no longer necessary, given the new "Last used Tabs for the second pane" section.
1.13 - 2008-04-01 - Restructured proposal to seperate core features, and the details of how DP would integrate into XY's current UI and feature set. Added "Catalog" section. Modified "Methods of differentiating which pane is active" section.
1.14 - 2008-04-01 - Added "Info Panel" section.
1.15 - 2008-04-03 - Minor changes to "Methods of differentiating which pane is active" section.
1.16 - 2008-04-03 - Added sections - "Synchronized Scrolling" and "Visual Comparison Filter"
1.17 - 2008-04-03 - Minor changes to the "Visual Comparison Filter" section.
1.18 - 2008-04-08 - Minor changes to "Synchronized Scrolling" section, to make it clear that this feature can be toggled, and is not always on.
1.19 - 2008-04-14 - Changes made to "Last used Tabs for the second pane", "Status Bar", "Tab Implementation", "Catalog", and "Info Panel" sections.
1.20 - 2008-06-12 - Added section - "Scroll Wheels".
1.21 - 2008-11-23 - Added section - "Keyboard Shortcut Actions".
1.22 - 2008-11-24 - Added section - "Scripting Support". Modified "Keyboard Shortcut Actions" section.

[Mesh]

Copied here from the old thread:


Here are some mockups I did to show the general idea:

The full size versions are 1920 px wide. The reduced size versions are 1024 px wide. But because these were created at 1920, the reduced size versions are going to be fuzzy. I'd recommend the full size for people who don't mind panning.


---------------------------------------------
Full Size


Top Bottom




Left Right - No Tree




Left Right - Tree





---------------------------------------------
Reduced Size - 1024 px wide (Warning - Fuzzy)

XY - Top Bottom




XY - Left Right - No Tree




XY - Left Right - Tree

[Mesh]

I never really chimed in on this because it is not something that is a deal breaker for me. But, since it looks like this may happen I guess I can chime in This is just a couple thoughts from me and I am not a big dual pane user so keep that in mind when you compare my ideas to someone who really wants the interface because they may probably have a better idea what they need from a dual pane interface.

1 - I think it should be easy to toggle it on/off because 95% of the time I would prefer to be in the current interface but it would be nice on occasion to switch to it.

2 - For me to use it I would need two trees. One tree would frustrate me to no end while navigating.

3 - top/bottom, side/side. Considering that I want the tree available for both panes the top/bottom approach makes more sense to me but I think it may be easier for most people to compare items if they are structured left/right. But, with a dual tree interface it could be very cluttered unless the trees for each pane are located above/below the main windows.

4 - keep it simple. I see most dual pane implementations go wrong because they clutter things up too much.

5 - It would be nice to be able to select two tabs and then hit a key or right click to open them in dual pane mode. Possibly go back to two tabs when switching away from dual pane.

I gotta get running for now but I still have a bit more to say.

Steve

It looks like what you're looking for (with what you've stated so far) meshes quite nicely with my initial proposal. The only thing that's different is your last item.

Since we're supposed to be coming up with a simple proposal, in my opinion, item 5 on your list should qualify as one of those features we ask for *after* DP is put in. To me, it's one of those things that would be nice, but is most definitely not necessary. And remember, we don't want to scare Don away by having a startup list that's too complicated.

[TheQwerty]

I'm not asking these to get answers for myself, but I think these are all important questions that needed to be answered in the initial proposal, and I don't think they've really been addressed yet.


How's the address bar and tool bar going to tie into all of this?
Does each pane need one, do they only work for the active pane, or ...?

Does each pane now have its own tab bar?
Or is this a view that cannot be used with tabs?
Or is this all crammed into a new special tab, and thus you'll be able to have multiple dual pane tabs?

For the first two how's it going to work with Default and "Search Result" tabs?

If it's a new special tab:
What should be done when dropping items on the tab itself; do they go to the active pane?
Will the user be able to tell which pane is active for background dual pane tabs?
How will locking, iconify, and home work here?


Where will the catalog fit into all of this?

Does each pane have its own info pane or are they going to share that?
Same question for the status bar?

EDIT: Typos and unsubscribing.

[graham]

Not wishing to muddy the waters but before you get into design mode and specifications I think the user need requirements should first be identified. It may turn out that to satisfy most user needs the solution is very simple and easily integrated but the last 10% of requirements are always a problem.

I still think the solution is for DP in what ever shape to act like a plug in application that does just what you want (compare files etc) and no more. For it to make use of the tab and menu structure is adding complication that will kill it off! May I suggest you come up with the bare bones spec. which does the urgent things only and works separately from what is in place. Once you get past this milestone and he thing is implemented then additional goodies can incrementally be brought in.

So, what are the need requirements in one line descriptions?

May I also add, from a personal pov I would not use DP but that said if it is in XY then it will satisfy a lot more buyers and that can't be bad.

[Mesh]

I'm not asking these to get answers for myself, but I think these are all important questions that needed to be answered in the initial proposal, and I don't think they've really been addressed yet.


How's the address bar and tool bar going to tie into all of this?
Does each pane need one, do they only work for the active pane, or ...?

Does each pane now have its own tab bar?
Or is this a view that cannot be used with tabs?
Or is this all crammed into a new special tab, and thus you'll be able to have multiple dual pane tabs?

For the first two how's it going to work with Default and "Search Result" tabs?

If it's a new special tab:
What should be done when dropping items on the tab itself; do they go to the active pane?
Will the user be able to tell which pane is active for background dual pane tabs?
How will locking, iconify, and home work here?


Where will the catalog fit into all of this?

Does each pane have its own info pane or are they going to share that?
Same question for the status bar?

EDIT: Typos and unsubscribing.

Here's my personal take on your questions, based on what I'm thinking of for the implementation.

For most things that are in XY right now, such as the Address Bar, Toolbar, etc... - they would function as they currently do, but only for the active pane.


Multiple Tabs would probably be best supported within each pane - so each pane would have its own set of tabs. See my mockup images to get a visual idea of what this would look like.

Default Tab - this currently has a limit of one tab. This can be allowed independently on each pane, but we'll have to discuss whether it should or not.

Search Result Tabs - they would come up on whichever pane was active when you executed the search, and each pane could have its own Search Result Tabs

Tabs - Home, Lock, and Iconify - these are currently set up on a per tab basis, and there's no reason to change that for DP (assuming my idea of allowing each pane to have its own tabs).

Status Bar - I meant to add this to my initial proposal, but forgot - there are good arguments for having either a single Status Bar, or dual Status Bars (i.e. one per pane). Dual status bars would give more information at a glance, but the trade off is additional space being taken up if your using DP in top-bottom mode. Most likely, this should be a user configurable option.


I'll edit the Proposal to reflect these points.


EDIT - Changed my statements regarding the Default Tab.

[Mesh]

Not wishing to muddy the waters but before you get into design mode and specifications I think the user need requirements should first be identified. It may turn out that to satisfy most user needs the solution is very simple and easily integrated but the last 10% of requirements are always a problem.

I still think the solution is for DP in what ever shape to act like a plug in application that does just what you want (compare files etc) and no more. For it to make use of the tab and menu structure is adding complication that will kill it off!

The root needs were discussed quite clearly in the old thread - and if you read it, you saw that the requirements for DP cannot be met by a plug-in. It's not that it can't be met well, it's that it can't be met - period. There can be no automation in the types of comparisons and management tasks that DP is necessary for.

Therefore, what is needed is a genuine built-in dual pane that takes advantage of all of XY's features - which is what this proposal is about.

[j_c_hallgren]

I still think the solution is for DP in what ever shape to act like a plug in application that does just what you want (compare files etc) and no more. For it to make use of the tab and menu structure is adding complication that will kill it off! May I suggest you come up with the bare bones spec. which does the urgent things only and works separately from what is in place. Once you get past this milestone and he thing is implemented then additional goodies can incrementally be brought in.

I'm somewhat in agreement with graham here...in that, I think we need a minimum solution that can be implemented first, but with a design plan that then can be enhanced to add the other features...Graham said it should "act like a plug in", not that it would actually be one...

The aspect that I think needs to be really considered in any design is how well it works on lower res screens...as any design that works on a 1024x768 will normally work just fine on a 1280x, 1440x, 1680x, etc, but not the reverse! On one of my web sites, the most common screen res that my visitors have is 1024x768, followed by 800x600...now the 800x600 is quite small, but it seems to be the 2nd most common that I find on public computers also....so this needs to be factored in so that one wouldn't have to have a 1920x to be able to use DP, as us laptop'rs have little choice in this.

Mesh may find the background color switching annoying, but as long as the color can be user defined, I find it helpful to quickly spot which is active, at least based on my x2 usage...user defined colors is needed for any method as what I find best color, another user may find horrible, and vice-versa.

Update/Addendum: The catalog definitely needs to be brought into the mix as well, as it can often subsitute for the tree.

Addendum #2:
Also, on Mesh's mockups, I don't see much of an Info Panel showing...this is something that I have visible 95+% of the time...and when it's in max size, there are presently only two lines of list showing...so how this would work with either top/bottom or left/right panes needs to be addressed.

I'd see a shared IP as there just isn't sufficient screen width or height to have dual ones on my size screen.

[Mesh]

I'm somewhat in agreement with graham here...in that, I think we need a minimum solution that can be implemented first, but with a design plan that then can be enhanced to add the other features...Graham said it should "act like a plug in", not that it would actually be one...

In regards to the plug-in, I still disagree. If it's going to pop up a seperate window, how is that any better than opening up two instances of XY and tiling them? It adds unnecessary complexity, and dulls the feature set that could be used in a genuine DP environment. And remember that one of the reasons to ask for dual pane in XY is so that you have the full power of XY to do whatever you need done.

Also, don't make the mistake of associating word count with complexity. The current proposal in the first post may be lengthy, but it is still - at heart - a simple implementation. Just because I'm going into details doesn't mean that we're not still talking about a simple core concept.


If you have any experience with programming, especially in C++, you should know what I mean. If you want a terminal program that asks for a line of input and then spits it out on screen with an ASCII box drawn around it - that's an extremely simple concept. But that doesn't change the fact that there are a lot of details that go into executing that simple concept.

It's not as simple as:

Code: Select all

int main ()
{

	string FreakingText;

	cout << "Enter Text:";
	getline (cin, FreakingText);

	DrawBoxAround (FreakingText);


	return 0;

}

Talking about the details of how DP is to be implemented doesn't, by itself, add complexity. It only adds thoroughness.

Almost everything that's listed in the current version of the proposal involves XY's already existing features, and how they'll fit in.


We're not talking about adding a template system that doesn't currently exist, whereby users can create a text file that lists which tabs are loaded in each pane, where those tabs are initially set to, column configuration, color skinning, etc... *That* would add unnecessary complexity beyond the initial needs of this proposal.

But talking about how the tabs, KB shortcuts, and status bar would behave - that's not adding complexity, it's just being thorough.

The aspect that I think needs to be really considered in any design is how well it works on lower res screens...as any design that works on a 1024x768 will normally work just fine on a 1280x, 1440x, 1680x, etc, but not the reverse!

Well, we're already talking about making efficient use of space when using DP in left-right mode, with tree panes that are above the file panes and that can collapse or autohide, and being able to set a single shared status bar so that you don't have the information cut off if you don't have a wide enough monitor.

You're absolutely correct that we'll have to keep this in mind as we discuss this further, but by the same token, any app has certain minimum requirements for screen space that you can't really push past. There's no question that people don't want to be told that they need to change their resolution or get a new monitor - but if you want to use Photoshop, and your current monitor is set to (or is only capable of) 800x600, you're not editing anything but icons unless you upgrade your monitor resolution.

Mesh may find the background color switching annoying, but as long as the color can be user defined, I find it helpful to quickly spot which is active, at least based on my x2 usage...user defined colors is needed for any method as what I find best color, another user may find horrible, and vice-versa.

There's no way to compromise on a full background color switch, even if the colors are user selectable. If people really want this, the only compromise would be to have seperate color adjustability for both backgrounds as well as the active tab color (or active tab stripe color).

Personally, if I can adjust the active and non-active tab stripe colors, that would be sufficient for me to easily tell what's what. But I understand if some people prefer a less subtle approach. I'll edit the Proposal to account for this until and unless there is a consensus on one versus the other.

Update/Addendum: The catalog definitely needs to be brought into the mix as well, as it can often subsitute for the tree.

The Catalog would fall into the category of functioning on the Active Tab. So, functionally, there doesn't need to be any change whatsoever. The only question is where the Catalog shows up. Obviously, one ugly but functional approach would be to allow the Catalog to come up as a moveable window that always stays on top of XY (but that minimizes or goes to the background along with the main XY window). This would allow resizing and positioning anywhere - but it's a bit clunky.

Aside from that approach, another possibility is to have it work as it does now - as a docked pane that pops up at the bottom of the tree pane. The only question is whether the Catalog comes up only once, or if it comes up in each tree pane. If it comes up once, than in top-bottom DP, it would show up in the bottom of the bottom tree (if using seperate trees), and in left-right DP, it would show up in the bottom of the left tree. Alternately, I suppose it could squeeze between the two, temporarily resizing them as needed - but this is probably a lousy idea (I mention it for thoroughness, though).

[Mesh]

Addendum #2:
Also, on Mesh's mockups, I don't see much of an Info Panel showing...this is something that I have visible 95+% of the time...and when it's in max size, there are presently only two lines of list showing...so how this would work with either top/bottom or left/right panes needs to be addressed.

I'd see a shared IP as there just isn't sufficient screen width or height to have dual ones on my size screen.

Here again, we'll either have to have a consensus on single or dual, or it will be user-configurable for both. From what I can see, it would have to be shared in top-bottom mode, but it could work as a dual panel in left-right mode.

[j_c_hallgren]

The aspect that I think needs to be really considered in any design is how well it works on lower res screens...as any design that works on a 1024x768 will normally work just fine on a 1280x, 1440x, 1680x, etc, but not the reverse!

You're absolutely correct that we'll have to keep this in mind as we discuss this further, but by the same token, any app has certain minimum requirements for screen space that you can't really push past. There's no question that people don't want to be told that they need to change their resolution or get a new monitor

And in the case of a laptop, there are much more restrictions on what options are available easily...a new screen isn't possible and in many/most cases, the resolution is pretty much fixed at one standard setting...So as long as the concept works adequately (but maybe not ideally) on a 1024x768, I'll be happy...

My comparsion as of now is how Xplorer2 works/looks...For reference, (given that some don't use a dual pane managers), here's a screen shot from Xplorer2 lite as I use it when doing manual/auto sync'ing:



BTW, Mesh, from what I've seen, you've taken a rational, thoughtful and organized approach to DP in these threads, which may likely is what helped get this going...unlike some in past who've just complained but provided no solutions...so thanks for your efforts from a fellow user!

P.S.

If you have any experience with programming, especially in C++, you should know what I mean.

Not with C++, but I did mainframe COBOL and assembler for 25+ yrs, so I've been around computers for a while.

[Mesh]

And in the case of a laptop, there are much more restrictions on what options are available easily...a new screen isn't possible and in many/most cases, the resolution is pretty much fixed at one standard setting...So as long as the concept works adequately (but maybe not ideally) on a 1024x768, I'll be happy...

Well, there's very little in the current proposal that detracts from screen space in any significant way - once you consider the dual panes themselves, that is. Otherwise, we're looking at a pretty tight setup so far.

My comparsion as of now is how Xplorer2 works/looks...For reference, (given that some don't use a dual pane managers), here's a screen shot from Xplorer2 lite as I use it when doing manual/auto sync'ing:

For most people, if they're using DP in left-right mode, the biggest squeeze for space is horizontally. Given that, my suggestion of having the trees above the file panes maximize the dimension that needs the most breathing room. And if the tree panel has the option to be manually collapsed or autohidden, we're not even losing space vertically, either.

I can see that for people with widescreen monitors, they'd have the space to put the tree(s) on the left even in left-right mode - but there would certainly be a learning curve if we had two vertically stacked trees on the left for that mode. I'm not saying that it wouldn't have its advantages, but we sacrifice a bit of intuitiveness to the UI.

BTW, Mesh, from what I've seen, you've taken a rational, thoughtful and organized approach to DP in these threads, which may likely is what helped get this going...unlike some in past who've just complained but provided no solutions...so thanks for your efforts from a fellow user!

[graham]

mesh wrote in comment

The root needs were discussed quite clearly in the old thread - and if you read it, you saw that the requirements for DP cannot be met by a plug-in. It's not that it can't be met well, it's that it can't be met - period. There can be no automation in the types of comparisons and management tasks that DP is necessary for.

Therefore, what is needed is a genuine built-in dual pane that takes advantage of all of XY's features - which is what this proposal is about.

The root needs I read in the forum were primarily meeting your needs. JC also added his but that is only two out of?

Plug in is perhaps a mis-leading term as it implies an existing product but think of it as a new module that is called (plugs in) when DP is required. The thing here is that there is only one person (Don) who knows how to integrate DP so I see no point in detailed specifications.

The way I would do it is to concentrate on the basic requirements to meet the DP needs of the forum contributors to gain substantial support. Once Don is clear on the requirement to satisfy the DP campaigners then he alone can advise how it can be integrated, if it adopts existing functionality, how far he is prepared to go on this and more importantly how much effort is required.

I spent the best part of my career designing application systems for business users (mainframe) and the common lesson I learnt is that far too much time is spent on the detail rather than the basic fundamental user needs.

Good luck in your quest but I do think there has to be more than two or three supporters and a convincing prediction of marketing benefits related to XY sales and notability.

For the record, my take would be to introduce a basic DP facility only if it were very easy to develop. XY is rapidly moving into new territory with scripting and this implementation is a major differentiator in the FM market. I fear many existing DP users will make comparisons of XY DP implementation against their favourite DP program and highlight the bits missing and overlook the things that make XY a special file manager.

Sorry for long post - last of my contributions for this topic.

[Mesh]

The root needs I read in the forum were primarily meeting your needs. JC also added his but that is only two out of?

Begging your pardon, but if that's what you think, than you didn't interpret it correctly. When discussing the root needs for DP, I wasn't talking about my needs specifically - rather, I was giving an example of why DP has a legitimate purpose that cannot be fulfilled by a single pane approach. The root need for DP is the need to do file management as it pertains to working with two folders simultaneously - often, but not always, this involves complex comparisons of dissimilar file lists. If you think that is a minority reason for using dual pane, than perhaps you don't understand it very well.

Plug in is perhaps a mis-leading term as it implies an existing product but think of it as a new module that is called (plugs in) when DP is required. The thing here is that there is only one person (Don) who knows how to integrate DP so I see no point in detailed specifications.

Don put the project of coming up with a unified proposal in the hands of the users interested in DP. It's obvious that this proposal *does* involve detailed specifications, especially in light of the fact that Don specifically stated that the DP proposal needed to "fit into the overall feel of XY" and "satisfy the majority of DP enthusiasts".

If details weren't called for, then why would the users need to come up with anything other than "just put in dual pane"?

The way I would do it is to concentrate on the basic requirements to meet the DP needs of the forum contributors to gain substantial support. Once Don is clear on the requirement to satisfy the DP campaigners then he alone can advise how it can be integrated, if it adopts existing functionality, how far he is prepared to go on this and more importantly how much effort is required.

As I mentioned above, the users interested in DP are to come up with a proposal that *does* address some of the details.

Now, don't get me wrong - I'm not making the mistake of thinking that the users are in charge of the blueprint - there's no question that Don has the final say. But my understanding is that what he wants is for the users to provide him with a unified proposal of how we would like DP to be implemented and integrated into XY - and that if it meets his requirements, he'll do what he can to implement it in 8.0.

My current thinking is that we'll hash this out until we have a proposal that holds the consensus, and then run it past Don, who will provide feedback on whether each item in the proposal is feasable, whether any of them involve more coding than he's willing to do at the moment, and whether he approves of the general concept proposed - including the integration into XY's existing feature set and user interface. And that says nothing for any suggestions he might have to improve upon what we have listed.

I spent the best part of my career designing application systems for business users (mainframe) and the common lesson I learnt is that far too much time is spent on the detail rather than the basic fundamental user needs.

Personally, I would change that slightly to say that far too often, the basic fundamental needs are not given enough attention and care. However, lack of attention to detail yields a lousy, buggy, unpolished, and poorly integrated application. Perhaps you're mistaking attention to extras, which is not the same thing as attention to details.

[j_c_hallgren]

I spent the best part of my career designing application systems for business users (mainframe) and the common lesson I learnt is that far too much time is spent on the detail rather than the basic fundamental user needs.

Seems that Graham and I share some background in the big iron! I also spent a lot of wasted time designing and coding from specs based on perceived user needs instead of actual core requirements, so I'm trying to make sure as best I can that these two paths stay together here...

Good luck in your quest but I do think there has to be more than two or three supporters and a convincing prediction of marketing benefits related to XY sales and notability.

Based on the number of review/blog postings that I've seen in last 2+ yrs about XY not being DP, I definitely believe that there is enough market potential to make it worthwhile...

I fear many existing DP users will make comparisons of XY DP implementation against their favourite DP program and highlight the bits missing and overlook the things that make XY a special file manager.

True! They'll ignore the fact that XY can (odd analogy) stand on it's head and juggle 3 balls, but complain because it's not singing at the same time!

Sorry for long post - last of my contributions for this topic.

Don't bail out on us now! We need input from people like you to help keep this on track and going in the right direction!