Author Topic: Window splitting and navigation issues with Beta 2  (Read 7195 times)

sndom

  • Community Member
  • Posts: 70
  • Hero Points: 1
Window splitting and navigation issues with Beta 2
« on: May 02, 2013, 11:23:28 am »
Using Beta2 64 bit on Windows 7

There are a number of bugs with the brief window splitting.
I have strict half splitting turned on and have keys bound as:

F1: change-window
F3: create-tile
F4: delete-tile

In the ascii art below, we start with a single window.  The window with cursor focus is marked with a *.

Example one

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F4 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

Now we can't use F1 right or left to move between the windows

Example one

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

F4 right

+---+---+
|   |   |
+---+ * +
|###|   |
+---+---+

The bottom left window is blank (it does not show the document).  Window navigation with F1 is broken.

What we should have ended up with is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Cheers

Dom

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #1 on: May 02, 2013, 01:25:23 pm »
Good catch! thanks

Jason.a

  • Community Member
  • Posts: 5
  • Hero Points: 0
Re: Window splitting and navigation issues with Beta 2
« Reply #2 on: May 02, 2013, 04:54:45 pm »
There also seems to be addition issues if you use F2 to move the panes around, then try to use F4 to delete panes.   Sometimes I hit F4 down arrow, and it actually deletes the pane off to the right, instead of the pane down below.

(capcha attempt 5)

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #3 on: May 02, 2013, 10:31:34 pm »
This will be fixed in the next beta. Both of these problems and probably some others is that the delete_tile is only supposed to delete the window you choose. It also resizes the window you started from causing it to be an incorrect size (correct for the previous releases implementation though). After that, things are in pretty bad shape.

sndom

  • Community Member
  • Posts: 70
  • Hero Points: 1
Re: Window splitting and navigation issues with Beta 2
« Reply #4 on: May 10, 2013, 09:33:39 am »
There is still an issue with the window splitting in Beta 3.

This example shows the wrong split being removed:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

Then after F4 right we end up with:

+---+---+
|   |   |
+---+ * +
|   |   |
+---+---+

But what we should have is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Dom

sndom

  • Community Member
  • Posts: 70
  • Hero Points: 1
Re: Window splitting and navigation issues with Beta 2
« Reply #5 on: May 10, 2013, 11:35:04 am »
And another.  Here the cursor ends up in the wrong window after the split:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

Then after F3 up, the split is correct, but the cursor is in the wrong window:

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

where it should be:

+---+---+
|   | * |
|   +---|
|   |   |
+---+---+


Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #6 on: May 10, 2013, 12:04:21 pm »
There is still an issue with the window splitting in Beta 3.

This example shows the wrong split being removed:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

Then after F4 right we end up with:

+---+---+
|   |   |
+---+ * +
|   |   |
+---+---+

But what we should have is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Dom

While the old tiling supported this, I don't expect the new splitting to support this. This implementation has nested areas which can only be unnested similar to how they were created in the first place. The old tiling implemented unnested tiles.

Sorry it's not the same as it was. This new layout code can eventually be used for our tool window docking.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #7 on: May 10, 2013, 12:05:40 pm »
And another.  Here the cursor ends up in the wrong window after the split:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

Then after F3 up, the split is correct, but the cursor is in the wrong window:

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

where it should be:

+---+---+
|   | * |
|   +---|
|   |   |
+---+---+


This looks like a bug. Thanks

jc44

  • Senior Community Member
  • Posts: 302
  • Hero Points: 19
Re: Window splitting and navigation issues with Beta 2
« Reply #8 on: May 10, 2013, 02:10:38 pm »
I think that we have moved from create/remove split to create/remove window and the window removal occurs without reference to where the request was issued.

Interestingly I don't get the cursor positioning issue

(b3 win 7 x64)

sndom

  • Community Member
  • Posts: 70
  • Hero Points: 1
Re: Window splitting and navigation issues with Beta 2
« Reply #9 on: May 10, 2013, 02:16:55 pm »
There is still an issue with the window splitting in Beta 3.

This example shows the wrong split being removed:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

Then after F4 right we end up with:

+---+---+
|   |   |
+---+ * +
|   |   |
+---+---+

But what we should have is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Dom

While the old tiling supported this, I don't expect the new splitting to support this. This implementation has nested areas which can only be unnested similar to how they were created in the first place. The old tiling implemented unnested tiles.

Sorry it's not the same as it was. This new layout code can eventually be used for our tool window docking.

That's disappointing.

Ok, I see what it is doing now (as jc44 points out).

My "brief" mental model has it deleting splits (reclaiming the space the other side of it) so having it delete the window from another branch of the split tree is very disorienting.  Wouldn't it make sense for (brief style) delete-tile to do nothing, i.e. not delete the "wrong" split, in this case.

Dom

jc44

  • Senior Community Member
  • Posts: 302
  • Hero Points: 19
Re: Window splitting and navigation issues with Beta 2
« Reply #10 on: May 10, 2013, 02:31:13 pm »
For what it is worth, I agree with you.  I prefer the old behaviour too - it seems a little more obvious to me and gives a level of control that the new scheme doesn't. Though I must admit that it probably won't affect me much as I rarely have more than two panes open.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #11 on: May 10, 2013, 03:22:50 pm »
And another.  Here the cursor ends up in the wrong window after the split:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

Then after F3 up, the split is correct, but the cursor is in the wrong window:

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

where it should be:

+---+---+
|   | * |
|   +---|
|   |   |
+---+---+


This bug has been fixed. Thanks for finding it. It only happens when smart next window is on.

Jason.a

  • Community Member
  • Posts: 5
  • Hero Points: 0
Re: Window splitting and navigation issues with Beta 2/3
« Reply #12 on: May 16, 2013, 02:23:17 pm »
There is still an issue with the window splitting in Beta 3.

This example shows the wrong split being removed:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

Then after F4 right we end up with:

+---+---+
|   |   |
+---+ * +
|   |   |
+---+---+

But what we should have is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Dom

While the old tiling supported this, I don't expect the new splitting to support this. This implementation has nested areas which can only be unnested similar to how they were created in the first place. The old tiling implemented unnested tiles.

Sorry it's not the same as it was. This new layout code can eventually be used for our tool window docking.

Hi, if I'm to understand you correctly.  You are saying that you can't make it work like it used too, because on the new implementation, you've picked a data structure, that makes it challenging to make the windows behave that way they should.   I'm calling shenanigans on the idea that it can't work the way it used too.   All the data is available to the app.  Assuming the nested windows are in some kind of tree type structure.... You still have all the data available...    Even if for some reason you decided to not keep parent data, you have a way to render the stuff, so you have a way to crawl the structure and build a list of rectangles.    This list of rectangles can be used to drive the logic, and if you have too, you can generate an entirely new structure of windows that appears and behaves correctly.

It doesn't leave a warm fuzzy feeling in me to know that the reason this is broken, is because of a design choice made internally at your company.   And frankly it makes me upset when someone uses the technical mumbo-jumbo as an excuse for why they can't do it.    It may be a pain in your ass, but it can be fixed.

I have been a slickedit customer for over 10 years ... I pay yearly support.  I'm personally responsible for dozens of licenses being sold to other customers.   (check my account).   The absolute #1 reason I use slickedit, is because it has the best Brief Emulation.    If the window splitting doesn't work like Brief, then it's not Brief emulation.   Period.

If you release v18 for real, and there are problem with this feature.  I will send in support tickets until you fix it.

With that said, I love the new MDI (aside from the pane splitting manipulation issues I'm encountering) ...

I think you should be aware that most of your customers are programmers, who spend most of their day, inside your product.   Some of us are passionate about how it works.   When I'm using Brief Emulation in slickedit, I have muscle memory ... everything happens without any real thought ...    I do make use of splitting / unsplitting / moving panes frequently while I work.

Please, please, please, please, fix it.

Regards,
Jason Andersen


Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5962
  • Hero Points: 467
Re: Window splitting and navigation issues with Beta 2
« Reply #13 on: May 16, 2013, 02:25:24 pm »
Sorry we can't implement every feature everyone wants as soon as it's wanted. We try hard though.

sndom

  • Community Member
  • Posts: 70
  • Hero Points: 1
Re: Window splitting and navigation issues with Beta 2
« Reply #14 on: May 17, 2013, 02:43:22 pm »
There is still an issue with the window splitting in Beta 3.

This example shows the wrong split being removed:

Code: [Select]
+-------+
|       |
|   *   |
|       |
+-------+

F3 right

+---+---+
|   |   |
|   | * |
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
|   +---|
|   | * |
+---+---+

F1 left

+---+---+
|   |   |
| * +---|
|   |   |
+---+---+

F3 down

+---+---+
|   |   |
+---+---+
| * |   |
+---+---+

Then after F4 right we end up with:

+---+---+
|   |   |
+---+ * +
|   |   |
+---+---+

But what we should have is:

+---+---+
|   |   |
+---+---+
|   *   |
+-------+

Dom

While the old tiling supported this, I don't expect the new splitting to support this. This implementation has nested areas which can only be unnested similar to how they were created in the first place. The old tiling implemented unnested tiles.

Sorry it's not the same as it was. This new layout code can eventually be used for our tool window docking.

Having lived with the new behaviour for a while (and trying to understand/love it) I'm finding that delete-split does the "wrong thing" so often that it is really annoying.

Consider the common case that I have the window split into three equal panes:

Code: [Select]
+---+---+---+
|   |   |   |
|   |   |   |
|   |   |   |
+---+---+---+

To get here I have done two splits in strict halving mode and resized the windows.

There is now essentially a 50% chance that it will do the "wrong thing" with the window sizes, depending on how I created the splits, when I use delete-tile.

As someone who has used brief tiling for many years this is driving me insane.

I understand the convenience of the hierarchical split tree from an implementation point of view, but can we not have delete-tile do the "right thing" when it would be possible to do so, and do nothing when it isn't?
The way the new implementation model is leaking out is incredibly painful.

Please.

Dom