Mailing List lswitcher-dev@2rosenthals.com Archived Message #181 previous message next message back to list

From: "Alfredo Fernández Díaz" <lswitcher-dev@2rosenthals.com> Full Headers
Undecoded message
Subject: lSwitcher-2-93-0-RC_4.wpi (was [...] RC_3)
Date: Wed, 16 Dec 2020 00:32:10 +0100
To: lSwitcher Developers Mailing List <lswitcher-dev@2rosenthals.com>

Hi again ^^

On 20/12/13 20:42, Gregg Young wrote:
Hi Alfred

Now that I think of it... if the lSwitcher widget lists XCenters, why
won't it let offer Close at least for *the other one* from its context
menu n the widget? You could rightfully argue that closing "this"
XCenter is not a necessary option on the widget because the whole
XCenter area already has it in its popup menu, but that's not true for
"the other" one.

It has always been this way. I will need to figure out if there is a reason for that.

My guess is when considering "close" lSwitcher leaves XCenters out altogether, when I see no reason why it ought to. If it is necessary to think this from the ground up, please bear with me:

The XCenters have a "Close" entry in their popup menus, which I take to mean the authors expected them to be closed from time to time, and are OK with someone closing them. Indeed, XCenters close OK (can be reopened with no obvious side effects). So, I think it is also logical that XCenters have "Close" on their popup menu in the Window list, and indeed they can be closed OK, too, from there. lSwitcher simply does not offer this possibility.

Now, you re-enabled the "C" popup hotkey (but not the hint) so I could close again the Desktop when Alt+F4-for-Desktop is enabled in XWP (thank you again!). But apparently you left it enabled for other windows, too, so it turns out that I can "C" XCenters from the popup, for example, and they seem to close just fine. So it seems to me there was really no reason.

(I never tested this thoroughly before, because it is useless for me to switch to XCenters with the keyboard, as they don't respond to kb input, so I normally keep my solitary one filtered away.)

I do understand things may get hairy --and you certainly want to be careful-- when "independent" code that lets you close something is somehow linked to / embedded into it (widget closing its "parent" XCenter). As I said, regarding the widget, I think not offering to close "this" XCenter is perhaps OK -- it is unnecessary anyway. From the perspective of that same widget, though, "the other" XCenter should be a completely separate, object, and thus closable IMO.

Finally, I don't see why the popup should not offer to close XCenters in general (although 'closing parent' code caveats may still apply).

[...]
Nope. At 800x600, the text is clipped so it looks like "Ctrl+Alt-"
and the square seems to be gone, but on a bigger screen the dialog is
readjusted and the square is still clearly there.

This is fixed

It is not. I see you changed the font by the entryfield (why? I thought you said the square was caused by debug code gone astray). This makes the square move under the entryfield at 800×600 (and also makes "Ctrl+Alt+" clip), but it is clearly visible at a higher resolution, see attached screenshots lSw293rc4@800×600.png, lSw293rc4@1280.png for comparison.

I also tried to improve some of
the dialog spacing (centered the hot key in its entry field, etc).

I confirm that's centered.

On a different note, on the same (both) screenshots above you can see the entryfield for the hotkey is blank. This is not saved now (while it was in rc3), nor is it read from a 2.92 INI file when updating.

...
On screenshot one, you can see (1) Times Roman or some other serif
font is still used on the Run dialog, and

This is fixed.

Yes, it is.

(2) some font is used for
the taskbar popup menus (up right), that is changed to a bolder one
on screenshot two. AFAICT, the bolder one is the normal font for such
menus in the rest of the system, but in lsw 2.93 I need to play with
the language dropdown for the menu to use that font (switch, and switch
back, check -- you don't even need to use the Save button in between).

This is true -- the settings change immediately. Save writes them to the ini file.

Yes, but we went off a tangent there. The point was, the taskbar menu should not change fonts by itself -- see composite lSw293rc4_menu_fntchg.png if you're not sure what I mean.

Whether this is related to the widget menu font being inconsistent between the main menu and the submenu (see lSw293rc4_wdgt_fonts.png), I don't know. Both fonts, though, seem to be the same ones as above.

On the other hand, drawing the dialogs with Times New Roman is still
ridiculously slow,

I see no difference in speed here.

What can I say? "Sluggish" would mean speedy by comparison.

Have a look at lSw293rc4_font_CPU.png. The big spike and plateau at the end of the pulse appeared exactly when I switched languages, then brought up the popup menu to open the settings menu. That system was a fresh AOS 5.0.6.04 install, doing absolutely nothing besides preparing to capture this Russian screenshot.

The second time around it seems a bit better, so maybe it's fonts getting cached or something. Will keep checking.

Since the only font shipped with Warp 4
in all languages that has all the glyphs needed is New Times Roman MT 30 I
am stuck with it. I could pick a better font if I limited support to ArcaOS
(perhaps eCS don't know what extra fonts they included) This is meant for
someone who wants to have lSwitcher in their language when the system isn't.
While they probably have better fonts installed I have no way of knowing
what they might be.

lSwitcher won't work on Warp 4, I just tried. It ends with a SYS3175 when calling DOSCALL1.DLL. Warp 4 didn't have any kind of Unicode support back in 1996, so I assume this should not really be considered.

Now, I also installed a plain vanilla (no "international" fonts, no "Russian" fonts, no nothing installed on top) Spanish MCP2 system from 2001 for further testing -- lSwitcher 2.92 (which didn't do the settings font switch) displays its Russian notebook just fine on that with the default font (System Proportional IIRC). I tried all the fonts that pop up in the font palette by default (Tms Rmn, Courier, Helv) and the Russian notebook displays just fine, letting aside the clipping at 640×480. I am not a specialist in Czech or Polish, but they look readable to me as well, and certainly there are no squares nor "house" characters.
Just see the lSw292@MCP2 screenshots series.

So I'd say we're pretty safe without all of that font stuff in 2.93 -- I had to really dig around before I found the first font which did lack glyphs: windows Arial. I don't think you will find many systems you want to support that are more bare bones than MCP2, and I don't think language support can get much more exotic for us.

<snip>
ArcaOS currently doesn't ship Russian or any of the other languages
(except English). This is meant for someone who wants an English system
in Russian to the greatest extent possible. If I am going to make the
language select able they need to render properly independent of the language
of the underlying system.

They did already.

There is no need to make the language select able if the only goal is to have
lSwitcher in the system language. The language can easily be set in the code
for this case.

I am now wondering if I should suppress this code for a system that is in
Russian (or PL or CZ). Off to get the RU ArcaOS beta to see.

I would say there is no need for either, but even better if you check.

<snip>
Case in point: I have an older Spanish work system where naturally
Spanish non-ASCII characters are displayed correctly all the time. I
expect this may not be the case for the Global tab (CP1207),

The only reason this wouldn't work is if the system predates the use
of uconv.dll or if it doesn't have the Warp Sans and/or Helv fonts
installed. None of which is likely.

Actually, I was right, and I can show you on the test MCP2/es system again. The only thing that did not render properly in 2.92 in it, was the "Global" page with the multi-language drop-down: not even "Español", whereas the other pages do Spanish, Russian, etc. flawlessly. The good news is that page is already fixed in 2.93 without using the Times New Roman, either. Have a look at the "Unicode_" pair of screenshots.

On to the undo stuff in a jiffy, hopefully.

Cheers,
AFD.
 Attached File:  lSw293rc4@800×600.png (14277 bytes)
Attached File:  lSw293rc4@1280.png (4095 bytes)
Attached File:  lSw293rc4_menu_fntchg.png (2823 bytes)
Attached File:  lSw293rc4_wdgt_fonts.png (29022 bytes)
Attached File:  lSw293rc4_font_CPU.png (129909 bytes)
Attached File:  lSw292@MCP2es_1_RU_Default.png (49512 bytes)
Attached File:  lSw292@MCP2es_2_RU_TmsRmn.png (44988 bytes)
Attached File:  lSw292@MCP2es_3_RU_Helv.png (42465 bytes)
Attached File:  lSw292@MCP2es_4_RU_Courier.png (43794 bytes)
Attached File:  lSw292@MCP2es_5_CZ.png (49992 bytes)
Attached File:  lSw292@MCP2es_6_PL.png (48468 bytes)
Attached File:  Unicode_292@MCP2es.png (48723 bytes)
Attached File:  Unicode_293rc4@MCP2es.png (48363 bytes)

Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster