Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Alex Taylor

Pages: [1] 2 3 ... 22
1
Hardware / Re: USX keyboard layout
« on: March 26, 2023, 03:29:47 pm »
To follow up on your last question: my main concern wasn't being able to use the UX keyboard under codepage 932. It was the inability to use it at all (even for 850) when specifying it as the keyboard layout in CONFIG.SYS.

However, it does look as if using the WPS keyboard object lets me select it subsequently, even though I get a warning popup.

Trying to use UX specific key combinations in a command prompt after doing this seems to work under codepage 850. Under codepage 932, I just get garbage glyphs in place of any non-ASCII character (as I normally get for double-byte characters, given this is not a DBCS system). 

If KEYBOARD.DCP were to be modified for UX+932, I would probably suggest replacing any unsupported character with ? or similar.  I'm not really sure it's needed at this point, though.

2
Hardware / Re: USX keyboard layout
« on: March 25, 2023, 02:31:26 pm »
Thanks.

To answer your previous question: codepage 932 is an implementation of the Shift_JIS encoding with a few IBM extensions that probably don't need to concern us here.
Note that on OS/2, contrary to what the above pages say, codepage 932 is an alias for codepage 943 (not 942), meaning it's compatible with the JIS X 0208:1983 standard.  (However, this also means it does not include the single-byte tilde, backslash or logical-not characters like codepage 942 does.)

Have to run; I'll answer your latter question later.

3
Hardware / Re: USX keyboard layout
« on: March 24, 2023, 11:45:06 pm »
I know the US International keyboard layout refuses to load on my system because I use codepage 932 (Japanese) as my secondary codepage.

That's strange -- what is your system with CP932 as the secondary codepage?

Not sure what you mean. My CODEPAGE statement is 850,932 if that's what you're asking.

Quote
Quote
I wonder if a modified DCP would allow that...
I am pretty sure it would (here, anyway) so a new DCP can be built. The question, though, is what could be put in there? I mean, other than the ¥, which does work already, what other special characters of USX are present in CP932?

Looking through CP932, there seems to be a dozen or so, including most of the combining accents and a few other symbols. However, they're all encoded as double byte characters. I don't know if it's possible to handle that.

4
Hardware / Re: USX keyboard layout
« on: March 24, 2023, 03:56:25 am »
I know the US International keyboard layout refuses to load on my system because I use codepage 932 (Japanese) as my secondary codepage.  I wonder if a modified DCP would allow that... 

5
Utilities / Re: DUMPFS setup
« on: March 05, 2023, 03:35:24 pm »
OK, thanks Dave and Lars... I was afraid it might be the NVMe drive. If ArcaOS 5.1 is ever actually released I was planning on running exclusively on NVMe, so guess I should try to set up with a RAM drive.

  Do either of you know if this is something that could be added to the NVMe driver, or is it a kernel limitation? I could raise an issue at the Arca bug tracker...

I suggest you open an issue on the bug tracker, yes (and include a testlog).  That's generally the best way to get a problem addressed.

6
Applications / Re: ANPM - YUM error. [Errno 256] No more mirrors to try
« on: February 18, 2023, 05:42:35 am »
Thank you for the answers. Here is the Debug Log:

----------[ ANPM 1.1 (202212271) started in debug mode: 17 Feb 2023 10:49:54 ]----------
[InitSpecialProcessing] Setting globals.!proclist_uri = "http://repos.arcanoae.com/anpm/pkgproc_url 2"
[InitSpecialProcessing] Setting globals.!needsboot = "libc libcx libgcc1 libgcc freetype fontconfig"
[InitSpecialProcessing] Setting globals.!priority1 = "libc libcx libgcc1 libgcc python2-rpm"
[InitSpecialProcessing] Setting globals.!priority2 = "python"
[InitSpecialProcessing] Setting globals.!priority3 = "rpm yum"
[InitSpecialProcessing] Setting globals.!priority4 = "os2-base"
[InitSpecialProcessing] Setting globals.!priority5 = "os2-mpts"

The same problem occurs with a fresh installation of ArcaOS 5.0.7.

Whatever is triggering this error, it doesn't seem to be coming from within ANPM. I can only surmise something is wrong on your system, but it's hard to say what. I suggest you open a ticket with Arca Noae, and include both the ANPM debug log, and (as per standard procedure) a TestLog of your system.

7
Applications / Re: ANPM - YUM error. [Errno 256] No more mirrors to try
« on: February 17, 2023, 01:06:43 am »
After updating to ANPM 1.1.0 the app crashes immediately. ANPM.err says:

Line 25 of NLSSetText in yumie.VRM:
+++                           Call VRSet control, property, text;
*** Error 40 Incorrect call to routine
Line 32 of ProgressUpdate in yumie.VRM:
+++                       Call NLSSetText 'DT_PROGRESS1', 'Caption', 190;
Line 25 of ProgressEvent in yumie.VRM:
+++           Call ProgressUpdate data;
Line 51 of Main in yumie.VRM:
+++       Call ProgressEvent;
Line 51 of Main in yumie.VRM:
+++     Interpret _VREEvent;

Anyone an idea?

I don't see any obvious reason for that crash. Are you, by any chance, running a non-default REXX interpreter (e.g. Object REXX), or a non-default system shell (e.g. 4OS/2)?

8
Storage / Re: LVM stopped working
« on: February 16, 2023, 05:32:13 am »
Quote
(FTR, MiniLVM doesn't use REXX at all.)
Thanks for clarification. Do you use standard PM windows programmed in C? With URE created resource files or manually edited text files? Just curious....

It's straight-up C and PM-OS/2 APIs. The resource files were originally created using dlgedit but are manually edited and maintained since.

I used a similar approach for LVMPM, although the main window is created programatically (and uses various custom controls): https://github.com/altsan/os2-lvmpm
(I really should get back to this program at some point, it currently lacks proper GPT support.)

9
Applications / Re: Firefox 45.9 XUL.DLL error
« on: February 11, 2023, 07:56:44 pm »
Since the exception is happening in the PSPRINT driver, I suggest you delete all PM printers (or at least all of those using PSPRINT). If that fixes it, you can then reinstall printer(s) one by one and make sure Firefox still runs.

(By delete, I mean fully delete the printer queue and the driver instance, which you can do using PM Printer Manager, or the old FaxWorks PRNDRV.EXE.)

10
Applications / Re: Start a program using utf-8 as system codepage
« on: February 11, 2023, 07:52:30 pm »
Use an editor that can display unicode such as Alex's qe.exe or featherpad. Or a browser.

How will PM123 display these audio metadatas ?

The CPPal technique might work here, but I doubt the results would be great. Ideally, PM123 should support it internally, I'm not sure if it has that logic or not (I don't generally use it myself). If not, it probably wouldn't be that difficult for a programmer to add.

11
Applications / Re: Start a program using utf-8 as system codepage
« on: February 11, 2023, 07:48:57 pm »
FYI: On the latest Warpstock Alex taught me how to use CpPal and I documented here to don't forget it: "Displaying an Application with Japanese Characters Correctly"

Nice article, but it could benefit from some tweaks. If you've modified CONFIG.SYS to have 932 as secondary codepage, you really want to change the process codepage (which will work in this case).  So in CPPal you'd want to select "secondary codepage" before dragging. And, in fact, if you've got 932 as a secondary codepage you technically don't need CPPal at all, you can just run the program from a session which does 'chcp 932' before starting the program.  (The program object's Language tab also lets you do this.)

CPPal is really useful when you don't have the secondary codepage set, but in that case the results aren't great if you're changing from a single-byte to a double-byte codepage.

12
Applications / Re: Start a program using utf-8 as system codepage
« on: February 11, 2023, 04:13:08 am »
OS/2 doesn't support UTF-8 as a process codepage. 

It does support it as a PM message-queue codepage, but this has to be set after the program starts up and creates a message queue.  You can force a change to a running PM app's message-queue codepage using CPPal (https://hobbes.nmsu.edu/?detail=%2Fpub%2Fos2%2Futil%2Fwps%2FCpPal_0-30.zip) - in most cases this requires you to also reset the window font afterwards (e.g. using the Font Palette) to force a refresh.

However, this technique has limited usefulness, mainly because the standard PM controls aren't really designed to handle UTF-8. Static text controls may be semi-legible, but text fields will probably just show an unreadable overlapping mess.

UTF-8 (1208) is supported as a GPI direct-rendering codepage, but it's apparently poorly optimized because rendering speed is atrociously slow. Raw UCS-2 (1200) is much faster to render in GPI, so in most cases it's better to internally convert UTF-8 to UCS-2 and render it that way. I once started to write a MLE control that could support Unicode encoded text (the source, such as it is, is still somewhere on my Github site), but I eventually found it was easier to just use Qt.

In most cases, if you want to render UTF-8 text (or any Unicode encoded text, actually) it's almost always preferable to use an alternative rendering library based on FreeType, like Cairo or Pango, as Qt and the Mozilla apps do. 

13
Storage / Re: LVM stopped working
« on: February 10, 2023, 12:59:56 am »
Rich's suggestions are the likeliest ones.

You said you tried MiniLVM, but you didn't say what error it reported.  Unlike the command-line LVM, MiniLVM will normally give you an informative error message about what went wrong (and a help button pointing you to more information). I suggest you see what it says.

(FTR, MiniLVM doesn't use REXX at all.)

14
Applications / Re: Docker
« on: February 08, 2023, 02:04:17 am »
The only way to run Docker on OS/2 would be inside a VM.

Docker depends on very specific kernel and filesystem functionality in Linux which simply doesn't exist on OS/2.  (When running on Windows, it either runs inside Hyper-V, or inside the Windows Subsystem for Linux environment. I believe on MacOS it also runs inside a VM.)

15
Programming / Re: Qt6
« on: January 29, 2023, 07:02:11 pm »
Hey guys,

From the screenshots, it definitely looks like Qt6 is trying to draw the fonts at 96dpi, when they should be 120dpi.

Interesting - so it looks like the dpi setting is also used to scale fonts, as well as screen resolution. I'll dig into this some more - I still think this is a step forward - I'd rather small fonts/menus in the correct location, than larger fonts that are offset in position :)

Cheers,

Paul.

Edit: https://forum.qt.io/topic/125521/how-to-understand-logical-dpi-and-physical-dpi-in-qscreen/4 probably explains what's happening....


It sounds like you've figured out the conversion for window scaling, it's just font scaling that's off.

This stuff can be a bit hard to keep straight, even for someone like me who's studied it at length... I'll include some background info here because it makes it easier for me to articulate things.  It doesn't mean I assume you don't know much of this already.

A font's point size is a fixed unit of measure where 1 pt == 1/72 of an inch.  So when a font is 12pt, that means its "em height" (a measure which means the bounding height of unaccented characters) is 12 points (or 1/8 inch) high.

On a computers, we measure things in pixels instead of inches.  So font scaling is all about figuring out the conversion factor of points to pixels.  To do this, we use the DPI resolution of the output device (the screen or printer). 

OS/2 Presentation Manager supports two DPI settings: 96 (which is the default at 800x600 and below), and 120 (which is the default at 1024x768 and up). 

So when a font is rendered on screen, its em height is scaled down to a number of pixels equal to pts * (DPI / 72). For example, a 12-point font on a 120 DPI screen would be drawn at 12 * 1.666666 == 20 pixels high.

Conversely, if you have a specific pixel height and you want to know the correct point size that will fit it, you flip the equation: points = pixels / (DPI / 72).  So to render an unaccented character (without padding) in a 30-pixel high box at 120 DPI, you need 30 / 1.666666 == 18pt.  (To allow space for accents and line spacing, you'd normally pad this a bit, probably by querying some of the font-specific metrics like lMaxAscender.)

Things get a bit more complicated because some programs like the Mozilla apps (and probably also Qt), define their own DPI setting separately from what PM thinks it should be. 

I assume you need to adjust Qt's DPI to match the current PM value, or else apply a conversion factor between the two.  (I'm not sure how Qt represents this internally.  The documentation I found is not very informative.)

You can query the current PM DPI setting using DevQueryCaps. 

Code: [Select]
HDC hdc
LONG lCap, lDPI = 0;

hdc = WinOpenWindowDC( hwnd )
if ( DevQueryCaps( hdc, CAPS_VERTICAL_FONT_RES, 1, &lCap ))
    lDPI = lCap;
if ( !lDPI )
    lDPI = 120;

Pages: [1] 2 3 ... 22