In daily Linux dbgutil bibisect version 2016-04-25, I see that View >
"Freeze Cells" offers three options ...
    ( ) Freeze Rows and Columns
    ( ) Freeze First Column
    ( ) Freeze First column
Each seems to work thusly:
  - If nothing is frozen, freeze as the option says.
  - Otherwise unfreeze.

It took me a minute to see what is happening, but the behaviour seems
somehwat logical.  And the bold "freeze lines" are visible in the
background around the menu and submenu, providing feedback about what
the program is doing.

But I am unusual in preferring to work with the keyboard.  The
spacebar invokes the highlighted submenu option and leaves the submenu
open, while clicking on the submenu option closes the view menu.  If
you are just clicking, it is a nuisance to go through the menus twice
to switch freezing from First Column to First Row.

On balance, I think it would be better to add a fourth submenu option,
"Unfreeze", so that each submenu option simply makes the state as the
words describe.  This makes all the functionality available with
fewer mouse clicks or with roughly the same number of keystrokes.
More importantly, the proposed behaviour is easier to describe.

How this would impact the toolbar button contemplated by bug 91013 I
do not know.  I am adding Yousuf (Jay) Phillips to cc.

I've mentioned this same issue in bug 91013 comment 16, but either Gulsah or Maxim replied to it.

*** Bug 103338 has been marked as a duplicate of this bug. ***

I disagree about a part of the behaviour that change https://gerrit.libreoffice.org/39399 wants to introduce and the original poster claimed.

I do *not* expect to have a (first) frozen column unfrozen if I freeze the first row and vice versa. I expect the frozen column to stay and additionally freeze the first row.

I also expect that if one row or column is already frozen and "Freeze Rows and Columns" has a check mark then selecting that menu option unfreezes the row or column instead of changing the freeze to the current cursor position.

(In reply to Eike Rathke from comment #4)
> I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> first row and vice versa. I expect the frozen column to stay and
> additionally freeze the first row.
> 

Of course this can be debated. As there was no debate yet, I supposed just going ahead is fine.

Another angle to this discussion: Do we care what Excel does? Do we want to copy it 1:1 or do we want to figure out something better?

For comparison, my workplace Excel 2013 has the same three options as we do, they work like:

- Freeze Panes: freezes at an arbitrary position. The button changes into "Unfreeze Panes" and removes all freezes when clicked.
Selecting "Freeze Top Row" or "Freeze First Column" changes the arbitrarily placed freeze into a top row / first column freeze.

- Freeze Top Row: Freezes the first row. Selecting it again does nothing. 
The Freeze Panes button becomes "Unfreeze Panes" and removes all freezes when clicked. 
Selecting "Freeze First Column" switches to first column freeze.
- Freeze First Column: Freezes the first column. Selecting it again does nothing. 
The Freeze Panes button becomes "Unfreeze Panes" and removes all freezes when clicked. 
Selecting "Freeze Top Row" switches to first row freeze.

(In reply to Eike Rathke from comment #4)
> I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> first row and vice versa. I expect the frozen column to stay and
> additionally freeze the first row.

The UNO commands were intended to be created in this fashion, without a checkbox/toggle type behaviour. If they did have a checkbox/toggle behaviour, then your expectation would make sense.

> I also expect that if one row or column is already frozen and "Freeze Rows
> and Columns" has a check mark then selecting that menu option unfreezes the
> row or column instead of changing the freeze to the current cursor position.

That is how it functions now and should be how it functions, or was someone trying to change it from this?

(In reply to Yousuf Philips (jay) from comment #6)
> > I also expect that if one row or column is already frozen and "Freeze Rows
> > and Columns" has a check mark then selecting that menu option unfreezes the
> > row or column instead of changing the freeze to the current cursor position.
> 
> That is how it functions now and should be how it functions, or was someone
> trying to change it from this?

Yes, me here: 
https://gerrit.libreoffice.org/#/c/39399/

Maybe not the perfect solution for this bug. Opinions are welcome :).

(In reply to Yousuf Philips (jay) from comment #6)
> (In reply to Eike Rathke from comment #4)
> > I do *not* expect to have a (first) frozen column unfrozen if I freeze the
> > first row and vice versa. I expect the frozen column to stay and
> > additionally freeze the first row.
> 
> The UNO commands were intended to be created in this fashion, without a
> checkbox/toggle type behaviour. If they did have a checkbox/toggle
> behaviour, then your expectation would make sense.
Enabling "Freeze First Column" or "Freeze First Row" they *do* check the "Freeze Rows and Columns" box, and giving the wording "Freeze ..." without any checkbox that's one more reason to expect that when selecting the other one the first one is not removed.

One can always remove any freeze with choosing the checked "Freeze Rows and Columns".

This is my stab at it: https://gerrit.libreoffice.org/41908

It's easy to remove an already existing column freeze if Freeze First Row is selected and vice versa if that is really wanted. It's odd for me, but.. if people want to mimic Excel.. I thought keeping the other freeze was easier for the inexperienced user. Just let's come to a conclusion.

So, any comments on this? Any real case except "Excel does it this way" for removing an existing freeze when selecting Freeze First, instead of preserving the other axis? If not, I'll just push the change.

(In reply to Eike Rathke from comment #10)
> It's easy to remove an already existing column freeze if Freeze First Row is
> selected and vice versa if that is really wanted. It's odd for me, but.. if
> people want to mimic Excel.. I thought keeping the other freeze was easier
> for the inexperienced user. Just let's come to a conclusion.

Yes this is the wanted behaviour.

This is the logic it should have and i think your gerrit patch summary says the same thing.

if [.uno:FreezePanesFirstColumn] then
   Disable existing freeze if any
   Enable freeze of first column

else if [.uno:FreezePanesFirstRow] then
   Disable existing freeze if any
   Enable freeze of first row

else if [.uno:FreezePanes] then
   if [any cells are frozen] then
      Disable existing freeze
   else
      Enable freeze based on cursor
   end if
end if

(In reply to Yousuf Philips (jay) from comment #12)
> This is the logic it should have and i think your gerrit patch summary says
> the same thing.
No, the current gerrit patch keeps an existing column freeze if Freeze First Row is chosen, and keeps an existing row freeze if Freeze First Column is chosen. Your flow removes any existing other freeze in these cases.

Hi

(In reply to Eike Rathke from comment #11)
> So, any comments on this? 

My comment is... I fully share your comments.

The menu command announces that it will freeze the first row (column). There is no indication that it will unfreeze a line/col that may be frozen. The result is totally unexpected.

Best regards
Pierre-Yves

(In reply to Eike Rathke from comment #13)
> No, the current gerrit patch keeps an existing column freeze if Freeze First
> Row is chosen, and keeps an existing row freeze if Freeze First Column is
> chosen. Your flow removes any existing other freeze in these cases.

Well my flow is the behaviour in Excel and makes it easy for beginners who dont easily get how .uno:FreezePanes works (this has happened to me many times) to easily get what they wanted.

http://www.online-tech-tips.com/wp-content/uploads/2010/06/ExcelFreezePanesButton_thumb.png

I'll push the mentioned commit that keeps an existing freeze on the other axis, maybe people can play with it in a daily build. As is, we seem to have two contradicting expectations how this feature should behave. As said it is easy to modify things to remove an existing freeze if that's really what we want.

Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea572a4fc616721b2d77baf6242c48a371fdc489

Resolves: tdf#99477 freeze first col/row always set a freeze

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

A polite ping to Eike Rathke: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks

Each of the command should set a freeze.

Personnaly I don't care if behavior is same as in Excel.

If it is, fine.

IMHO a Checkmark in the menu to reflect current state of freeze/unfreeze of 1st line and 1st column would be welcome.

Regards,
Eric

I would expect a toggle function, which also improves the menu. Like this

[x] First row
[ ] First col
-
[ ] From here (or another caption, but the terminology should make clear that "First row/col" are different)

If "[x] From here is checked", the other two will be unchecked and disabled. Clicking this item again, the selection unfreezes. 

"[ ] First row/col" toggles the first row/col independently (both can be on or off at the same time and do not depend on the other state).

(In reply to Heiko Tietze from comment #20)
> If "[x] From here is checked", the other two will be unchecked and disabled.
Doesn't make sense to me. Why should the user be forced to first unfreeze the current state before being able to freeze a first row or column?

As is, selecting Freeze First Row now automatically unfreezes a different row freeze if any.

> "[ ] First row/col" toggles the first row/col independently (both can be on
> or off at the same time and do not depend on the other state).

That we almost have, just that unfreezing independently is not possible now, unfreeze works only on the checked "Freeze Rows and Columns" entry. The behaviour actually matches the current presence of toggle boxes.

(In reply to Eike Rathke from comment #21)
> (In reply to Heiko Tietze from comment #20)
> > If "[x] From here is checked", the other two will be unchecked and disabled.
> Doesn't make sense to me. Why should the user be forced to first unfreeze
> the current state before being able to freeze a first row or column?

Freezing "From here" don't work together with a frozen first row/col and therefore these two are unchecked _automatically_. 

> As is, selecting Freeze First Row now automatically unfreezes a different
> row freeze if any.

The only difference, so far, is the proper feedback via unsetting the checkbox.

it does work in Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: nl-NL (en_US.UTF-8); UI: en-US
Calc: threaded

(In reply to Cor Nouws from comment #31)
> it does work in Version: 7.0.0.3

Confirmed on Windows & Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded

Closing as FIXED. this was fixed by 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea572a4fc616721b2d77baf6242c48a371fdc489 from comment 17