search

Azaret / superputty

Automatically exported from code.google.com/p/superputty
MIT License
0 stars 0 forks source link

Embedded PuTTY frames can lose their visual tabs, leading to other erratic behavior (Method 2) #98

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Open any PuTTY connection.  Frame will be sized to entire window.
2. Repeat step (1).  Two visual tabs will represent the two connections
3. Drag one tab away from entire SuperPuTTY window.  That connection's frame 
will convert to a tabless "tool window"
4. Drag the other tab to the center of the tabless window from step (3)

What is the expected output?
EITHER
1. The independent window now shows tabs, showing that 2 PuTTY windows are 
occupying the same space
OR
2. The independent tabless window refuses to combine with other SuperPuTTY 
windows

What do you see instead?
A single "tool window" that presumably represents two PuTTY connections, 
however there is no indication that there are multiple PuTTY windows being 
represented.

What version of the product are you using? On what operating system?
v1.2.0.6 (latest beta)

Please provide any additional information below.
More visual artifacts can be created at this time by combining windows in 
various ways.

Original issue reported on code.google.com by drew.dor...@gmail.com on 10 May 2012 at 7:56

GoogleCodeExporter commented 9 years ago 
Actually when the main window is empty and two sessions are in their own 
isolated window I get tabs at the bottom of the isolated window.

I think that for both this and for Issue 97 the solution is just to disallow 
free floating windows.

Rob

Original comment by roblow...@gmail.com on 11 May 2012 at 4:36

GoogleCodeExporter commented 9 years ago 
And the two tabs at the bottom of the isolated window are visually different in 
style.

Hmm. In fact when you drag an isolated window back to the main window the 
presence or absence of tabs when it redocks depends on where you drop it. Drop 
it to the right of a PuTTY window and the tabs reappear. Drop a tab to the 
right of the window containing the treeview of sessions and there is no tab. 
Drag the tabless window back to one of the PuTTY sessions, hey presto, the 
tab's back.

And in fact you lose the tab when you drag a PuTTY session to the right of the 
treeview pane even if you don't isolate it beforehand.

Original comment by roblow...@gmail.com on 11 May 2012 at 5:01

GoogleCodeExporter commented 9 years ago 
I quickly found value in having free-floating windows.  Having virtual desktops 
and/or multiple display devices is probably a factor.

Since SuperPuTTY already supports multiple running instances, it sounds like 
these problems could also be solved if finalizing a free-floating window 
launched a new SuperPuTTY instance that contained the new window.  Or if it's 
easier, have the same instance open a new "main" window.

Original comment by drew.dor...@gmail.com on 12 May 2012 at 1:39

GoogleCodeExporter commented 9 years ago 
Assuming closed b/c #97 is closed as well.

Original comment by btatey...@gmail.com on 28 May 2012 at 5:10

GoogleCodeExporter commented 9 years ago 
Unlike issue #97, this issue still exists.

I can elaborate on the reproduction steps if necessary.  It only takes seconds 
to reproduce.

Original comment by drew.dor...@gmail.com on 28 May 2012 at 6:07

GoogleCodeExporter commented 9 years ago 
reopening...

Original comment by btatey...@gmail.com on 28 May 2012 at 10:01

GoogleCodeExporter commented 9 years ago 
can you reproduce this on 1.2.0.11?

I rolled back dockpanel to 2.4 to fix a similar issue.

Original comment by btatey...@gmail.com on 9 Jun 2012 at 11:03

GoogleCodeExporter commented 9 years ago 
I just tested this on 1.2.0.12.

The result is now what I described as Expected result #1: "The independent 
window now shows tabs, showing that 2 PuTTY windows are occupying the same 
space."

The tabs were at the bottom of the free-floating window, so I didn't notice 
them at first, but the good news is that this destructive behavior is now gone.

In my opinion, this issue may be closed.

Original comment by drew.dor...@gmail.com on 12 Jun 2012 at 12:36

GoogleCodeExporter commented 9 years ago

Original comment by btatey...@gmail.com on 16 Jun 2012 at 11:45