issue-#83 Different window title for Mod, Rsrc, and Docu

[Josef Templ]

For the issue see http://redmine.blackboxframework.org/issues/83
For the changes see http://redmine.blackboxframework.org/pr ... 0484dfcf7d.

The changes are as proposed by Trurl in CPC 1.7 rc5 but with a different association of the bracket form:
Mod () //as in BB1.6; the most used document class should not be changed
Rsrc [] //symbolizes the rectangular shape of forms
Docu {}

This is a simple issue which definitely provides an advantage.
There may be a discussion on the association of the bracket forms, though.
In addition, the module uses CAP for converting characters to upper case. I am not sure if it
can create problems when using arbitrary Unicode names for subsystems.

- Josef

[Robert]

If I use the Menu -> Info -> Repository Tool I get Window titles ...

Sym -> StdStamps.osf
Code -> StdStamps.ocf
Mod -> StdStamps
Docu -> StdStamps
Rsrc -> (Std)Stamps.

If I select the module name and then Right-Click I get Window titles ...

Source -> (Std)Stamps
Interface -> StdStamps
Documentation -> Stamps.

If I do Menu -> Help -> Contents -> Framework -> Math the Window title is "Math Docu".

If I do Menu -> Help -> Contents -> Dev Subsystem -> DevCmds the Window title is "Docu DevCmds".

If I do Menu -> Help -> Contents -> Form Subsystem -> FormGen the Window title is "FormGen Docu".

Would this current proposal be better as part of a bigger exercise to make Window titles more consistent and less ambiguous everywhere?
With this proposal there are 6 different conventions for Docu files - maybe there are more?
I think this proposal, on its own, actually adds to the confusion as:

- There will still be ambiguities and inconsistencies in title formats
- It represents a change to what we are used to without really solving anything.

[Josef Templ]

> - It represents a change ... without really solving anything.

Well, it does solve the problem mentioned in the issue.
And this is what you use when developing software.

> I think this proposal, on its own, actually adds to the confusion as:

It does not introduce new inconsistencies. All the observed
different conventions for choosing the window title already existed in BB1.6.
The 'Repository' is intended for browsing only, not for development.
All the repository files are opened in read-only mode without an associated file path.
This is probably the reason for using a different window title.

> - It represents a change to what we are used to ...

I tried to keep the change to a minimum by using () for Mod as it was used in BB1.6.
I don't have any statistics but I have the feeling that I and probably most users
spend most of their time with Mod files. So keeping the appearance of Mod files
seemed natural to me.

> Would this current proposal be better as part of a bigger exercise to make Window titles more consistent and less ambiguous everywhere?

It would be a significant effort to change window titles everywhere and it is not clear
if it is possible and meaningful at all (see note on 'Repository' above).
So, I would prefer to solve the little issue with little effort now
and leave any bigger updates for later.

- Josef

[Zinn]

In addition, the module uses CAP for converting characters to upper case. I am not sure if it
can create problems when using arbitrary Unicode names for subsystems.

The result of CAP is compared with upper-case ASCII letters only. CAP is very efficient. So there is no reason to use the extended Unicode Upper function, because wrong translation of the Unicode part does not change the result of comparison here.

[Josef Templ]

That's right. We can ignore this.

- Josef

[Zinn]

In my opinion this topic is ready to vote

[Josef Templ]

I agree, go on with the voting.

- Josef

[Robert]

The 'Repository' is intended for browsing only, not for development.
All the repository files are opened in read-only mode without an associated file path.

I initially thought the phrase "read-only mode" meant "Browser mode", which is not true for interface files.

But the link calls "StdCmds.OpenBrowser" so one would have thought it should be in Browser mode; is this a related bug? The Docu for StdCmds.OpenBrowser says the contents are "not editable", but they are.
(I am using BBox 1.6, apologies if these issues have already been fixed.)

Another related observation is that "DevBrowser.ShowInterface" opens the interface in Edit mode; Browser mode would make more sense.


Another Docu style to add to the collection (this time also from the DevRepository page):
"System/Docu/Sys-Map"

I still think that, ultimately, the whole area would benefit from a cleanup.

Regards, Robert

[Josef Templ]

I don't know where this behavior (edit mode for Sym, Code) comes from.
StdApi.OpenBrowser explicitly sets read-only mode but for some reason it is ignored.

Anyway, I think it is not related to issue-#83.

- Josef

[Zinn]

Sorry, there is a misunderstanding.
Info -> Interface does not open a window in browser mode. It opens a window in aux mode.
Aux mode windows are editable, but this kind of windows are not saved during close. There are no warnings. All changes are lost.

I see no reason to change this kind of behavior.
Why should we not allow to edit the result and save them in another document?
The Log window is editable too and not saved during close. Would you like to have an annoying question about saving the Log window?

Please remember:
There are three kinds of windows: (1) normal mode, (2) browser mode and (3) aux mode.
And a document can be open in four different states: (1) edit mode, (2) layout mode, (3) browser mode and (4) mask mode.
Nobody would like to write a document for novice users and advanced users often forget elementary rules.
Where are the cook book? Can everybody explain all those differences?