Dual Pane Wishes

[TheQwerty]

Found a bug in this tab moving business or perhaps in the Pane.ini serialization.

Somehow my configuration of XY ended up with different separators defined/used in the [Tabs] section for each Pane (this could be from when DP was introduced in the first place).
Pane 1 is using: Separator=»
Pane 2 is using: Separator=»

The A# and M# keys use the correct separator for the pane but the difference (I believe) meant dragging tabs across panes never worked properly.


This eventually means moving the tab causes XY to consume the entire processor core and sit there hung until the process is killed. Sometimes you can move the tab a few times before XY goes belly up, but the new tab is given a random VF even if the old tab didn't have one. Typically the first time I dropped it would get a VF of 'Â' and the second time would be the last two tokens of the M# key.

Doing a simple Find/Replace from "»" to "»" seems to have fixed the problem for me but it still implies something is inherently wrong in XY.

[admin]

Found a bug in this tab moving business or perhaps in the Pane.ini serialization.

Somehow my configuration of XY ended up with different separators defined/used in the [Tabs] section for each Pane (this could be from when DP was introduced in the first place).
Pane 1 is using: Separator=»
Pane 2 is using: Separator=»

The A# and M# keys use the correct separator for the pane but the difference (I believe) meant dragging tabs across panes never worked properly.


This eventually means moving the tab causes XY to consume the entire processor core and sit there hung until the process is killed. Sometimes you can move the tab a few times before XY goes belly up, but the new tab is given a random VF even if the old tab didn't have one. Typically the first time I dropped it would get a VF of 'Â' and the second time would be the last two tokens of the M# key.

Doing a simple Find/Replace from "»" to "»" seems to have fixed the problem for me but it still implies something is inherently wrong in XY.

Damn, you are right. That was real stupidly done. I will have to write code to migrate all pane-wise separators (which never had any good reason to exist!) to a global hard-coded one, and I think TAB (ascii 9) is a good choice for the job!

[admin]

That should be fixed now.

[jacky]

Code: Select all

v8.20.0027 - 2009-08-28 12:49
    + Menu Panes: Added commands "Move Tab to Other Pane" and "Copy Tab
      to Other Pane". The tab is inserted before (left of) the currently
      selected tab, and becomes the selected tab itself.

May I ask why ("before (left of) the currently selected tab") ? Not that this is a feature I would use, but the logical choice to me would have been to add it as most-right tab, or to the right of the currently selected tab if option "Open new tab next to current" is enabled. Seems more expected/consistent to me... no?

[TheQwerty]

That should be fixed now.

Indeed that fixes it. However, I've found a few more...

The inactive pane bg color is not always applied, and it also sometimes does not show on starting XY. Unfortunately, I can't reproduce this with a fresh copy and don't have time to dig into my config until next week.

The list settings (at least view and selection) are not saved when the active tab (inactive pane) is replaced with a dropped one, so unless its settings were saved previously (by switching tabs for instance) they are lost.

For example open a fresh copy of XY and run this script:

Code: Select all

"Losing List Settings"
  #304; //Change from Details to List View
  Sel("a");
  #800; //Open Dual Pane
  Focus("PI");
  #340; //Open New Tab
  #805; //Move Tab to Other Pane
  #1019;  //Switch Tabs
  Echo("The current tab should be in List view with everything selected.");

It's coming along though - just being able to move the history, et al, makes it much better than the script version!

[admin]

Code: Select all

v8.20.0027 - 2009-08-28 12:49
    + Menu Panes: Added commands "Move Tab to Other Pane" and "Copy Tab
      to Other Pane". The tab is inserted before (left of) the currently
      selected tab, and becomes the selected tab itself.

May I ask why ("before (left of) the currently selected tab") ? Not that this is a feature I would use, but the logical choice to me would have been to add it as most-right tab, or to the right of the currently selected tab if option "Open new tab next to current" is enabled. Seems more expected/consistent to me... no?

It seemed natural to me. Let's hear what people say that actually used it.

[admin]

That should be fixed now.

Indeed that fixes it. However, I've found a few more...

The inactive pane bg color is not always applied, and it also sometimes does not show on starting XY. Unfortunately, I can't reproduce this with a fresh copy and don't have time to dig into my config until next week.

The list settings (at least view and selection) are not saved when the active tab (inactive pane) is replaced with a dropped one, so unless its settings were saved previously (by switching tabs for instance) they are lost.

For example open a fresh copy of XY and run this script:

Code: Select all

"Losing List Settings"
  #304; //Change from Details to List View
  Sel("a");
  #800; //Open Dual Pane
  Focus("PI");
  #340; //Open New Tab
  #805; //Move Tab to Other Pane
  #1019;  //Switch Tabs
  Echo("The current tab should be in List view with everything selected.");

It's coming along though - just being able to move the history, et al, makes it much better than the script version!

Confirmed and fixed.

inactive pane bg color: did not see that yet

[TheQwerty]

It seemed natural to me. Let's hear what people say that actually used it.

I'd have to agree with jacky on this one. It should be treated the same as a new tab when using these commands.

inactive pane bg color: did not see that yet

Found it! "Apply box color to list" seems to take precedent over the inactive pane's background color.

[jjk]

I'd have to agree with jacky on this one. It should be treated the same as a new tab when using these commands

Yes, it seems to me also more natural to have it at thr right instead of the left.

[Stefan]

Code: Select all

v8.20.0027 - 2009-08-28 12:49
    + Menu Panes: Added commands "Move Tab to Other Pane" and "Copy Tab
      to Other Pane". The tab is inserted before (left of) the currently
      selected tab, and becomes the selected tab itself.

May I ask why ("before (left of) the currently selected tab") ? Not that this is a feature I would use, but the logical choice to me would have been to add it as most-right tab, or to the right of the currently selected tab if option "Open new tab next to current" is enabled. Seems more expected/consistent to me... no?

It seemed natural to me. Let's hear what people say that actually used it.

I think it's no matter if left or right, ... but features should give expected/consistent results, i agree.
But not as most-right tab, near the current working tab is better for direct access.

[Stefan]

1)
could there be an alias
for the scripting
focus "PI";
$OPanel = <curpath>;
focus "PI";

like <opanel> ?
or <oppath>

----

2)
using DP i like to use the "normal" copy/move/backup -dialogs... (...+F7)
...could there be an optional option to initially fill the path field of this c/m/b -dialog
with the current "other" panel path ?

[admin]

1)
could there be an alias
for the scripting
focus "PI";
$OPanel = <curpath>;
focus "PI";

like <opanel> ?
or <oppath>

----

2)
using DP i like to use the "normal" copy/move/backup -dialogs... (...+F7)
...could there be an optional option to initially fill the path field of this c/m/b -dialog
with the current "other" panel path ?

1) maybe <curpath_i> (inactive); but that would be useful for all <cur...> variables. Maybe there's a smarter way to do this than add a full second set of variables. Hmmm...

2) Why not simply use the commands under Panes menu?

[j_c_hallgren]

2) using DP i like to use the "normal" copy/move/backup -dialogs... (...+F7)
...could there be an optional option to initially fill the path field of this c/m/b -dialog
with the current "other" panel path ?

2) Why not simply use the commands under Panes menu?

They could, but I think Stefan may have a valid point, in that x2 doesn't have a Panes menu, but has "opposite pane" as one of 3 choices within the "copy to"/"move to" command so ppl who are converts from that product would find a common path to the c/m/b destination useful...and if one is used to +F7, not having to use a separate KS could be easier...

I wouldn't remove it from Panes, but add it as choice within c/m/b, maybe as new submenu opt "Opposite Pane Tabs" below "tabs" and above separator which would then show those.

That would eliminate the need to even popup the dialog box and be very quick to chose desired one.

[Stefan]

2) Why not simply use the commands under Panes menu?

Yes, they are fine options, but

a. they works silent, which is fine, but smt i like to use the dialog to see what happens
and maybe modify the target path and/or use the recent locations instead of the current target
b. saving shortcuts by not using to different dialogs
c. ability to use the backup mode too
d. having all the other current and future features of this c/m/b dialog

[Stefan]

1) maybe <curpath_i> (inactive); but that would be useful for all <cur...> variables. Maybe there's a smarter way to do this than add a full second set of variables. Hmmm...

maybe we can write smtg like <<curpath>>; <<curitem>>
or <icurpath>; <icuritem>

if we want to access the inactive panel

and your code can recognized this alternations?
IF start with two <<
IF starts with 'i'