Issue-#175 Display StdLink command in status line

[Robert]

1. it was possible even in BB 1.6 to open the link dialog of a link in a Browser mode document by using the "Properties" menu item.

Ok, but can you in Mask mode; eg the Help->Contents Map?

2. you can copy a link from a Browser mode document into your own document indeed.

Do you mean the blue link (eg Roadmap), or the link text taken from the Dialog (eg "StdCmds.OpenBrowser('Docu/BB-Road', 'Roadmap')). I meant the latter.

[Josef Templ]

Mouse button usage has been refined for read-only documents.
There is no configuration required.

See diffs at https://redmine.blackboxframework.org/p ... 39ecd38fe0.

mouse-right in read-only documents (mask or browser mode) now opens the link as in version 1.6 and 1.7.
Ctrl + mouse-right opens the link dialog. This combination is available because revealing the link inside the
text is not possible in a read-only document anyway.

I think this is a good compromise.

- Josef

[Robert]

Ctrl + mouse-right opens the link dialog

As does Ctrl + mouse-left; is this intentional?

This combination is available because revealing the link inside the
text is not possible in a read-only document anyway.

Don't understand. I think (I am writing this in a hurry!) that it was possible in 1.6 for Browser docs, but not for Mask docs.

We (Ivan & I) were asking for less access to the link; this proposal gives more.

[Robert]

1 - The whole purpose of this issue was to make it easy to read the command text behind a link (in any document).
This is a convenience for a developer.

2 - Ivan points out that one may want to hide this implementation detail, in a Mask or Browser document, in a deployed application.

(3 - My observation is the relatively minor point that it is mildly frustrating, for a developer, to be able to read the read this command text, but not to be able to conveniently copy and paste it to another place. Lets put this comment aside for now.)

Points 1 & 2 seem to be fundamentally incompatible, but we must choose between them before finalising the details of any implementation.

Currently I think I support point 2 because point 1 is a conveniece that can be worked around, whereas point 2 has no work around.

[Josef Templ]

Ctrl + mouse-right opens the link dialog

As does Ctrl + mouse-left; is this intentional?

This combination is available because revealing the link inside the
text is not possible in a read-only document anyway.

Don't understand. I think (I am writing this in a hurry!) that it was possible in 1.6 for Browser docs, but not for Mask docs.

We (Ivan & I) were asking for less access to the link; this proposal gives more.

I intentionally didn't list all possible mouse combinations because this leaves some room for future refinements.
The same holds for various other mouse actions.

Revealing the link "inside" the text (using the special link syntax) is not possible for browser and mask mode because such a text is read-only.
A user will not accidentally use Ctrl-mouse-right on a link and be surprised that it behaves differently than in 1.6.

The big difference is that mouse-right in read-only documents is not showing the link dialog any longer.
This is less access compared to the previous state of this issue, isn't it?

- Josef

[Josef Templ]

(3 - My observation is the relatively minor point that it is mildly frustrating, for a developer, to be able to read the read this command text, but not to be able to conveniently copy and paste it to another place. Lets put this comment aside for now.)

This is a fundamental limitation of all read-only text fields in BlackBox.
I would prefer to be able to select and copy the contents of a read-only text field but unfortunately it is
(currently) not possible.

A possible approach for the link dialog would be to not use read-only mode for the text field.
This would allow selection and copying of the text inside it.
The command buttons would still be disabled for read-only texts.

After checking the details it turned out to be trivial to change and that it actually reverts the change of the 'CmdGuard' to the state of BB 1.6.

See diffs at https://redmine.blackboxframework.org/p ... ype=inline.

For testing use http://blackboxframework.org/unstable/i ... c1.989.zip.

- Josef

[Robert]

A possible approach for the link dialog would be to not use read-only mode for the text field.
This would allow selection and copying of the text inside it.
The command buttons would still be disabled for read-only texts.

I think this is a desirable refinement.

Does anyone else have an opinion regarding the "fundamentally incompatibity". Do we want/need to be able to hide this implementation detail, in a Mask or Browser document, in a deployed application?

[Robert]

Mouse button usage has been refined for read-only documents.
There is no configuration required.

I don't like this!

It is reasonable that some actions are disabled in read-only documents, but I don't like that some actions (eg <Ctrl> mouse-left or <Ctrl> mouse-right) do different things depending on the read-only status of the document.

This is just a reaction; I haven't thought through what I do like!

[Josef Templ]

Mouse button usage has been refined for read-only documents.
There is no configuration required.

I don't like this!

It is reasonable that some actions are disabled in read-only documents, but I don't like that some actions (eg <Ctrl> mouse-left or <Ctrl> mouse-right) do different things depending on the read-only status of the document.

This is just a reaction; I haven't thought through what I do like!

Robert, I do agree that the behavior should not be
different if that can be achieved with reasonable effort.
(I was not looking at this property so far because if you press Ctrl + mouse-left, for example,
you also get a different behavior in editable and read-only texts.
This was never a problem so far, but it is not very nice indeed.)

The deal here would be to add additional conditions for the various actions.
Not much effort but additional complications in the coding.
Ctrl + mouse-left could be ignored in read-only texts by that.
Similarly, Ctrl + mouse-right could always open the dialog.

(Ctrl + mouse-left in my opinion is mainly for backwards compatibility.
It is a leftover of a historic situation where there was no dialog.
Otherwise its existence doesn't give sense (to me).)

By looking at the details, it turned out that the situation can be simplified a lot by giving up mouse-right on a link completely.
The result is then a nice symmetry, same behavior in all modes, and no special cases for editable, browser, mask.
Ctrl + mouse left -> reveal cmd inside text
Ctrl + mouse right -> open link dialog

See the diffs at https://redmine.blackboxframework.org/p ... 5f607b8ed9.

Plus: an off-by-one error fixed in isHot for the right-sided link view.
Docu updated accordingly.

For testing use http://blackboxframework.org/unstable/i ... c1.990.zip.

- Josef

[Robert]

I have briefly tested this, and, for developers, I think it is better now. It is also more consistent with StdStamps; for both you can view the hidden part by <Ctrl> right-click.

But we have not addressed the requirement to be able to deploy applications which do not give access to this developer information.
One possibility I can think of is to have a global flag (in StdLinks) that needs to be set (maybe by a Menu item) before one can see the contents of Browser & Mask mode documents.

A related topic (bug ?) is that one can use the StdStamps dialog to add & change entries in Browser mode documents.