Re: [cdesktopenv-devel] russian locale?

[Andrey ``Bass'' Shcheglov]

> Xm_FONT_IS_FONT via libXft
There's a typo here. Of course I was referring to Xm_FONT_IS_XFT.



signature.asc
Description: OpenPGP digital signature
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] russian locale?

[Andrey ``Bass'' Shcheglov]

Hello All,

Just my two cents here.

CDE pre-configures font and locale-specific settings for Motif
applications (dtterm included) not only via the standard LC_*
environment variables (particularly, LC_CTYPE for non-ASCII input), but
also via Motif-specific X resources.

Motif itself (as of version 2.2, if I'm not mistaken) supports not only
server-side /Core X fonts/ (Xm_FONT_IS_FONT and Xm_FONT_IS_FONTSET), but
also client-side fonts (Xm_FONT_IS_FONT via libXft, just like other
modern GUI toolkits).

The problem is, CDE 2.0 was released long before the 2.2 release of
Motif, so it's only aware of the (older) server side fonts.

Basically, when CDE is installed, it generates /Core X font aliases/
(-dt-application-* and -dt-system-*) for various locales it supports.
Later on, when a user chooses the locale (in DtLogin prompt), CDE just
sets Motif-specific X resources (via xrdb) and adds the locale-specific
aliases to the /X font path/ of the running X11 server (for example, for
ru_RU.KOI8-R locale, these aliases might look like
-dt-application-*-koi8-r and -dt-system-*-koi8-r; for en_US.UTF-8 and
ru_RU.UTF-8 -- -dt-*-iso10646-1, and so on).

If the user wants a bigger or a smaller font, they can select those via
DtStyle.

If the user wants a different font face (e. g.: -*-times-* instead of
-adobe-helvetica-*), this can no longer be configured via DtStyle, but
rather X font aliases need to be rewritten (either globally or on a
per-user basis).

So the first problem I see here is that, while CDE in commercial Unices
supported a wide range of locales, the open-source version ships only
with 4 locales (en_US, de_DE, fr_FR and es_ES, all of them using
ISO-8859-1 rather than UTF-8). Correct me if I'm wrong -- I haven't been
following the UTF-8 conversion during the last couple of years. Having
said the above, the 1st thing required in order for various ru_RU.*
locales to be fully supported are the corresponding *X font aliases*.

This has nothing to do with L10N -- but in order to localize CDE, font
aliases need to exist first. Then we can take a look at commercial
Unices -- at least, CDE 1.x in Solaris had excellent Russian translation.

Yet another problem with server-side X fonts is that modern Linux
distributions have stopped shipping XFS, the X Font Server, and whenever
a user installs additional TrueType fonts, those no longer get added to
the X font path. So if one wants to use, e.g., Monotype fonts in CDE
(Courier New, Arial, Tahoma, etc.), the font path needs to be set
manually, and font aliases re-generated (again, manually, as described
above).

Thus, the 2nd problem is that the UI of DtStyle is very limited, and
needs to be enhanced. And, unlike GTK+ and Qt, Motif still doesn't have
any font chooser widget.

And there's also an approach mentioned by Vladimir Nikishkin --
client-side fonts:

> *renderTable: rt
> *rt*fontType: FONT_IS_XFT
> *rt*fontName: Micro Hei
> *rt*fontSize: 10

Unfortunately, this requires Motif 2.2+ (does CDE still support Motif
2.1.30?) and is currently completely orthogonal to whatever CDE offers
in terms of font selection (meaning that X resources need to be set
manually an on a per widget class basis -- no-one would want to see
proportional fonts in DtTerm and vice versa -- fixed-width fonts on
buttons and labels).

I would summarize that CDE can be relatively easily "hacked" to support
non-ASCII locales, but plenty of manpower is required in order to
provide the complete solution.

Regards,
Andrey.


On 05.12.2019 12:01, Marcin Cieslak wrote:
> On Thu, 5 Dec 2019, Vladimir Nikishkin wrote:
> 
>> Which distribution are you using? ALTlinux?
>>
>> I may try to submit a package with MicroHei for it.
>>
> 
> I am using FreeBSD. I have tried ru_RU.UTF-8, ru_RU.ISO8859-5 and
> ru_RU.KOI8-R locales
> and none of them work.
> 
> For the 8-bit ones the characters do not appear.
> 
> For ru_RU.UTF-8 things are broken as attached - I think this is not only
> font selection/motif
> issue, but also dtterm has problems with it.
> 
> There is an rxvt unicode window as a comparison, I have also tried to
> change
> the workspace name.
> 
> Marcin



signature.asc
Description: OpenPGP digital signature
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] sdtedit freely available ?

[Andrey ``Bass'' Shcheglov]

Hello Richard et al.,

I've added the Autotools integration, set up CI and published
`dtwmcmd` (3-clause BSD):

 - GitHub: https://github.com/cdesktopenv/dtwmcmd
 - GitLab: https://gitlab.com/cdesktopenv/dtwmcmd
 - BitBucket: https://bitbucket.org/cdesktopenv/dtwmcmd

Feel free to collaborate =)

> There are some other odds floating around (not mine). If you have an 
> online record of what you've found of that sort, I can check it against what I
> recall seeing and/or may have a copy of (which may not be the latest nor have 
> straightforward means of finding the latest, if still available).

Indeed.
I also have a rather large collection of links to Motif resources, widgets, etc.
As time passes, more and more of them tend to migrate to
web.archive.org, e. g.:
.

> FYI, here's a list of f.commands I dug up when I was in a curious mood once 
> (probably using the "strings" command); a couple are noted as
> undocumented, and one as something that will crash dtwm if not used properly. 
>  Some of them have requirements like an implicit context, that
> might make them not very useful in a script or the like.

Thanks!
That's indeed a useful list, and I observe it slightly differs from
what the standard Mwm can offer.

P. S. I've also mirrored the CDE git repo at GitHub, GitLab and
BitBucket (for what it's worth, it increases the visibility of the
project) and I'm planning to keep it updated. If anyone would like
access -- please let me know, I will gladly share it.

Regards,
Andrey.


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] sdtedit freely available ?

[Andrey ``Bass'' Shcheglov]

Thank you for your response, Richard.

All the technical details you've sent make perfect sense.

On Thu, 27 Jun 2019 at 22:11, Richard L. Hamilton  wrote:
>
> My program (dtwmcmd - send f.commands to dtwm) may be floating around 
> somewhere; but my website
> no longer exists, so I've attached a copy.

May I ask you to put `dtwmcmd` on GutHub/GitLab/BitBucket/elsewhere (I
can do that on your behalf) and attach a license?
I'm worried all those CDE-related extras may get lost unless properly
published =)

Regards,
Andrey.


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] sdtedit freely available ?

[Andrey ``Bass'' Shcheglov]

Hello,

Which files under `${HOME}/.dt` does `sdthotkey` modify?

Probably the same functionality can be implemented using some python
or shell scripting, with `zenity` or `xdialog` (or even `dtksh`) as
the front-end.

Regards,
Andrey.

On Sat, 1 Jun 2019 at 01:02, Christopher Turkel
 wrote:
>
> Anything with "sd" at the beginning was unique to Solaris CDE and Sun has not 
> released any of their CDE sources.
>
> On Fri, May 31, 2019 at 5:09 PM Swift Griggs  wrote:
>>
>> On Fri, 31 May 2019, Swift Griggs wrote:
>> > There is a tool that comes with CDE on Solaris called 'sdtedit' which 
>> > allows
>>
>> sorry the tool is called "stdhotkey" not 'sdtedit' (which is some crap in
>> my head floating around from VMS, I think). Otherwise, the question is the
>> same.
>>
>> Thanks,
>>Swift
>>
>>
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel


___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] ArchLinux Build

[Andrey ``Bass'' Shcheglov]

Hello,

It may be not dtterm itself but either

- your shell (try bash/zsh/ksh/dash) or
- termcap/terminfo databases knowing nothing about dtterm (try to play with
stty or set your TERM variable to something different, e. g. xterm, rxvt,
linux-console, screen, vt100 or vt220).

Regards,
Andrey.

On Sunday, 24 March 2019, Antonis Tsolomitis 
wrote:

>
> I tried on ArchLinux (cde 2.3.0) and I have the following problem.
> Dtterm behaves strange after pressing Return (see screenshot).
>
> If I go to Terminal Options it says that Newline sequence is Return only.
>
> If I change this to Return/Linefeed the problem is corrected. However
> it applies only to the current terminal.
>
> So, is this a bug?
>
> How do I set this to the correct choice as a default for all dtterms ?
>
> Antonis.
>
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel