[cdesktopenv-devel] CDE on Raspberry Pi 4 (64-bit OS) possible tweaks?

[Richard L. Hamilton]

Context: my CDE experience is on Solaris 10 and earlier, almost entirely. On 
there, I've read, scrounged, and done enough to be able to tweak it quite a bit 
- like a command line tool that can send f. commands to dtwm, so things like 
restarting dtwm after editing a dtwmrc file can be scripted. But that was a 
long time ago. :-) I had some years ago built with mixed results CDE for 
Solaris 11 (SPARC).
 
I just installed CDE on a Raspberry Pi 4 (current and regularly updated 64-bit 
Bullseye for the Raspberry Pi, with some 32-bit packages installed as well to 
support ExpressVPN client which is only 32-bit).

https://sourceforge.net/p/cdesktopenv/wiki/CDE%20on%20the%20Raspberry%20Pi/ 
 
clearly needs updating, because it describes the older build procedure without 
automake and ./configure.

Some extra packages were needed (automake was obvious, plus a couple more, one 
I forget), the least obvious of which being opensp, since the package name 
isn't obvious from the onsgmls binary needed. I wish I'd taken notes, but I'm 
not likely to have another Raspberry to do this on, so I didn't think of it at 
the time.

Late in the build, I had to switch to doing it from an ssh connection, to 
finishing from a terminal window in a desktop session, because the build wanted 
to communicate with the X server or something present in a desktop session. 
Fortunately an interrupted make will tend to pick up where it left off.

Other than those points (some of which are addressed by the README.md file), 
there were a few compiler warnings but no failures in building.

I can e.g. run dtpad from a command, although it takes a long time to start, 
since ttdbserverd and/or ttesssion are not running.

How can I:

* start those while still using the native (lightdm) windown and session 
management?

* add a session to those CDE knows about (e.g. on Solaris, one could from the 
CDE login choose not only a CDE session, but others, such as GNOME or on older 
Solaris, OpenLook, or add some, even as wild as OpenStep if one had it (I have 
the Sun build of that for SPARC Solaris), or lightweight like fvwm or plain mwm 
or twm. In particular, I want a way to have dtlogin be able to start a login 
session functionally equivalent as much as possible to the native one. I 
remember /etc/dt/config/Xsession.* files for this, but it's been about 15 year 
(from the timestamps) since I added a session, so I've forgotten more about CDE 
than I know about lightdm. :-)

The point would be to have a choice of either lighdtm (if it can handle user 
choice of sessions at login time) or CDE login screen lead to either desktop 
with the tools of both other than the window manager (and those requiring it) 
being fully available. I want nostalgia and familiarity without breaking too 
much new stuff. :-) And preferably with some idea what configuration files I 
have to back up lest a package update clobber them.

And what has changed since CDE went open source to the extent that something 
might be replaced with something else not natively CDE, or might otherwise be 
unfamiliar?

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

Re: [cdesktopenv-devel] MS style alt tabbing

[Richard L. Hamilton]

CDE window manager AFAIK is _not_ mwm but still dtwm, a derivative of mwm but 
with additional actions that can appear in configuration files (or be sent to 
it if you know how*) and maybe other CDE specific functionality.

If the functionality of emwm would not clash with the dtwm specific features, 
maybe it would be interesting to have something that combined them.

* I reverse engineered that back before CDE was open source and created a 
utility that will send f. commands to dtwm, although not all such are useful! 
That dtstyle could restart dtwm, but a script to edit .Xdefaults or some such 
could not, got me curious how that worked.


> On Dec 29, 2022, at 7:21 PM, cyrus torros  wrote:
> 
> Hello,  I am wondering if anyone has devised any hacks to have MS style alt 
> tabbing in CDE?
> 
> also, I am wondering if it is possible to use enhanced motif window manager 
> with it instead of mwm
> 
> It is an enhanced fork of MWM that has support for hints and other cool stuff 
> (can be found here https://fastestcode.org/emwm.html 
> ) (site does not require javascript)
> 
> I was going to try a drop in replacement soon, so assuming no one else has 
> tried, will report back.. assuming CDE compiles successfully, thats always 
> kind of a gamble.
> ___
> 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] Announcement of dtpower: a powermonitoring dockapp for the CDE frontpanel

[Richard L. Hamilton]

Good to see new apps!

I would note that Solaris (10 and earlier) had its own "dtpower", meant to show 
and control various power management functions, but without an active front 
panel icon. Hopefully the same name won't cause confusion.

Here's something I downloaded in the mid '90's (not having much luck finding it 
on the web anymore), that would put a volume control on the front panel. It 
assumed Solaris audio APIs, which means as-is, it wouldn't work on anything 
else, but it might be a starting point.



audioutil-1.0.tar.gz
Description: GNU Zip compressed data


> On Feb 23, 2021, at 12:16, Jürgen Mayerhofer via cdesktopenv-devel 
>  wrote:
> 
> 
> Hi,
> 
> 
> today I want to announce my first opensource-project on sourceforge:
> 
> 
>https://sourceforge.net/projects/dtpower/
> 
> 
> dtpower is designed to be used as an app in CDE's frontpanel. dtpower calls
> "acpi -a" to get the state (power plugged in or not) of the power adapter.
> The icon changes according to the state.
> Then "acpi -b" is called to set a tooltip with the current load of the 
> battery.
> 
> Feel free to use it and have fun.
> 
> Suggestions for improvement are welcome. Send them to
> 
>juergen_mayerho...@yahoo.de
> 
> Best regards,
>   Juergen.
> 
> 
> 
> 
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> 



smime.p7s
Description: S/MIME cryptographic signature
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] scripting CDE actions or f. commands, was Re: [PATCH] dtksh: allow parallel building

[Richard L. Hamilton]

For what you want to do, you don't actually need to send an f. command at all; 
you should be able to execute an action more directly with

dtaction ExitSession

You have may have to do something to keep your script from getting killed after 
exiting the session but before issuing the shutdown command. Maybe

nohup sh -c 'dtaction ExitSession;sleep 5;exec sudo shutdown -h now' >/dev/null 
2>&1

or something like that (the exact way to issue the shutdown command with needed 
privileges and options will vary by OS and other considerations).

If in some other circumstance, dtaction isn't good enough and you actually DO 
need to script f. commands, I wrote something years ago to do that.

The attached file dtwmcmd.c, when compiled, should allow sending arbitrary f. 
commands to dtwm. (something similar might work with the smaller set of 
commands for mwm, I don't recall whether I tried)

See the comments for examples of compiling it, although on anything other than 
Solaris, you probably want /usr/X11/include and /usr/X11/lib rather than 
/usr/openwin/include and /usr/openwin/lib; evidently on some systems you don't 
even need the options to find those. At any rate, they should at least identify 
the -l options needed.

This is something like what libDtSvc does for a few functions that change the 
backdrop or initiate a dtwm restart, but the have the particular command 
hard-coded. And I reverse-engineered it long before CDE went open-source, by 
using xscope to see what was being passed around; it annoyed me that some 
command (dtstyle?) could trigger a dtwm restart when needed, but a provided 
script could only prompt the user to do the restart themselves.

And being extra stubborn, here's a list of f. commands I dug both out of man 
pages and out of binaries (with strings command). The references are all to 
Solaris 9 man pages (Sun's version of CDE); the sdt* were commands peculiar to 
theirs (they had some of the TriTeal like stuff, such as a graphical workspace 
tool, although that wasn't among those referenced in my list).

In practice, a lot of the commands are not terribly useful from a script 
(especially if they take some sort of implied window context), although one 
person wanted to cycle through workspaces in a loop with a sleep between, 
because they were driving a projection display to show multiple system 
monitoring screens repeatedly, one after another.

The following are the man page references to dtwm "f." commands in Solaris
9.  Primary description is dtwmrc(4), others may be incidental
references.

f.action dtwmrc(4), dticonfile(4), sdtdir2dtwmrc(1), sdthotkey(1)
f.beep dtwmrc(4)
f.circle_down dtwmrc(4)
f.circle_up dtwmrc(4)
f.create_workspace dtwmrc(4), sdthotkey(1)
f.delete_workspace dtwmrc(4), sdthotkey(1)
f.exec dtwmrc(4), dtwm(1), sdthotkey(1)
f.focus_color dtwmrc(4)
f.focus_key dtwmrc(4)
f.focus_key_raise dtwmrc(4)
f.goto_workspace dtwmrc(4), sdthotkey(1)
f.help dtwmrc(4)
f.help_mode dtwmrc(4)
f.ignore dtwmrc(4)
f.kill dtwmrc(4), dtwm(1), VendorShell(3x)
f.lower dtwmrc(4), dtwm(1)
f.marquee_selection dtwmrc(4)
f.maximize dtwmrc(4), dtwm(1), VendorShell(3x)
f.menu dtwmrc(4), sdtdir2dtwmrc(1)
f.minimize dtwmrc(4), dtwm(1), VendorShell(3x)
f.move dtwmrc(4), dtwm(1), VendorShell(3x)
f.next_cmap dtwmrc(4)
f.next_key dtwmrc(4)
f.next_workspace dtwmrc(4), sdthotkey(1)
f.nop dtwmrc(4)
f.normalize dtwmrc(4)
f.normalize_and_raise dtwmrc(4), dtwm(1)
f.occupy_all dtwmrc(4)
f.pack_icons dtwmrc(4), sdthotkey(1)
f.pass_keys dtwmrc(4), sdthotkey(1)
f.post_wmenu dtwmrc(4)
f.prev_cmap dtwmrc(4)
f.prev_key dtwmrc(4)
f.prev_workspace dtwmrc(4), sdthotkey(1)
f.quit_mwm dtwmrc(4)
f.raise dtwmrc(4), dtwm(1)
f.raise_lower dtwmrc(4), dtwm(1)
f.refresh dtwmrc(4), dtwm(1), sdthotkey(1)
f.refresh_win dtwmrc(4), dtwm(1)
f.remove dtwmrc(4)
f.resize dtwmrc(4), dtwm(1), VendorShell(3x)
f.restart dtwmrc(4)
f.restore dtwmrc(4)
f.restore_and_raise dtwmrc(4), dtwm(1)
f.screen dtwmrc(4), sdthotkey(1)
f.send_msg dtwmrc(4), XmDeactivateProtocol(3x)
f.separator dtwmrc(4)
f.set_behavior dtwmrc(4)
f.title dtwmrc(4), sdtdir2dtwmrc(1)
f.toggle_frontpanel dtwmrc(4), sdthotkey(1)
f.version dtwmrc(4)
f.workspace_presence dtwmrc(4)

Undocumented:
f.change_backdrop (used somewhere in libDtSvc)
 usage: f.change_backdrop BackDropName HexPixmapIDNoLeading0x 0 (i.e.
 sender creates and loads pixmap, etc.); not sure whether final 0 arg
 could be anything else

f.set_context (no known reference outside of dtwm)
 usage: unknown; incorrect (or perhaps any) usage may result in dtwm
 and/or X server crash






dtwmcmd.c
Description: Binary data





> On Feb 15, 2021, at 13:14, cyrus torros  wrote:
> 
> Does anyone know how I can use  f.action ExitSession
> in a script? I am trying to chain that together with shut down because
> its the only thing that saves my session properly.
> 
> On 2/13/21, Jon Trulson  wrote:
>> On 2/12/21 9:08 AM, Chase via cdesktopenv-devel wrote:
>>> This patch allows dtksh to be built 

Re: [cdesktopenv-devel] Setting custom wallpaper on other workspaces

[Richard L. Hamilton]

JPG and PNG will work now? (if Motif is built appropriately); that helps.

The other thing that would help is a way to specify that specific backdrops 
should be centered or scaled rather than tiled; with that, it'd be fairly 
complete (except when one wants some animated program to provide a backdrop; I 
suppose there's a way to find the window ID of the backdrop, but that's a bit 
much; and not necessarily all such programs take an arbitrary window ID).

> On Feb 10, 2021, at 07:08, Chase via cdesktopenv-devel 
>  wrote:
> 
> Hello,
> Please take a look at the wiki article for backdrops: 
> https://sourceforge.net/p/cdesktopenv/wiki/Setting%20Your%20Own%20Backdrop/
> 
> 
> Thank you for your time,
> -Chase
> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, February 10, 2021 4:02 AM, cyrus torros 
>  wrote:
> 
>> I am looking for a way to set a custom backdrop on workspaces 2, 3,
>> and 4. Tools like nitrogen don't seem to be capable of it? Is it not
>> possible/
>> 
>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Setting custom wallpaper on other workspaces

[Richard L. Hamilton]

CDE backdrops are managed normally by using dtstyle. They're slightly unusual 
XPM files (potentially with some colors mapped to the current "palette"). The 
usual CDE backdrops are NOT on the actual X11 root window, they're on a window 
overlaid on it, so tools that set the X11 root window contents will NOT produce 
a visible result on them.

There is one exception: NoBackdrop; set that for the backdrop if you want the 
X11 root window (only one of those exists, so all workspaces set to NoBackdrop 
will show the same thing) to be visible in a workspace, and then familiar tools 
to set the X11 root window contents will work. That also applies to animated 
ones, like xearth with the appropriate options.

If you want another backdrop, I think if you have NoBackdrop selected (applies 
to the current workspace unless you checked "Use this backdrop for all 
workspaces"), you can use usual tools that set the X11 root window. 

It is not impossible to convert a JPG or GIF (sized exactly to your screen 
size, otherwise it will tile to fill!) to an XPM, and add that to the 
backdrops. But the file size will be huge; it's really not a nice thing to do 
to your system.

There is no existing mechanism to e.g. detect switching workspace and 
automatically set the root window to particular contents. That would have been 
very slow once upon a time, and they wanted workspace switching to be fast, 
which is probably why they had overlay windows for the normal CDE backdrops; 
that way it's at least already loaded into the X11 server.


> On Feb 10, 2021, at 05:02, cyrus torros  wrote:
> 
> I am looking for a way to set a custom backdrop on workspaces 2, 3,
> and 4. Tools like nitrogen don't seem to be capable of it? Is it not
> possible/
> 
> 
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> 



smime.p7s
Description: S/MIME cryptographic signature
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Fedora Build repaired (sort of)

[Richard L. Hamilton]

I can get a stair stepping easily enough on most terminal emulators (this was 
Solaris 10 CDE dtterm):
$ stty -onlcr
$ 
  $ 
$ 
  $ stty sane
 $ 
$ 
$ 
So maybe for some reason, it was bringing up the pseudo-terminal with the wrong 
tty modes. :-)
> On Nov 24, 2020, at 16:39, Antonis Tsolomitis  
> wrote:
> 
> 
> You are right. I got confused with Ubuntu in which installation of a service 
> enables it and runs it as well.
> In Arch it needs to me explicitly enabled, and I forgot this. 
> 
> So, everything is fine on Arch and Manjaro the only additional step is to 
> install rpcsvc-proto.
> 
> On Debian testing I still have to learn why dtterm stair-steps the prompts 
> until it is reset.
> (this problem does not appear on Arch).
> 
> Thanks for all the help,
> 
> Antonis.
> 
> 
> 
> On 11/24/20 6:56 PM, Danilo Pecher wrote:
>> That error means you don't have the rpcbind service running
>> 
>> On Tue, 24 Nov 2020 at 17:54, Antonis Tsolomitis 
>> mailto:antonis.tsolomi...@gmail.com>> wrote:
>> 
>> 
>> True. So the package 
>> 
>> rpcsvc-proto
>> 
>> needs to be installed on Arch/Manjaro. This information is missing from 
>> 
>> https://sourceforge.net/p/cdesktopenv/wiki/Archlinux_Build/#install-packages 
>> 
>> 
>> Can it be added?
>> 
>> Now libcsa has been compiled and installed. The problem however persists on 
>> Manjaro.
>> ttsession (although build and installed):
>> 
>> "The desktop messaging system could not be started"
>> 1. Click OK etc etc
>> 
>> On another window:
>> "A ToolTalk connection could not be established.. no ttsession 
>> process is running".
>> 
>> These are typical errors for CDE from the past. So what to look for should 
>> be known to
>> experts of the CDE code. So, any idea how to debug?
>> 
>> Antonis.
>> 
>> 
>> On 11/24/20 3:25 PM, Danilo Pecher wrote:
>>> If libcsa isn't built, you're most likely missing rpcgen on your system
>>> 
>>> On Tue, 24 Nov 2020 at 14:20, Antonis Tsolomitis 
>>> mailto:antonis.tsolomi...@gmail.com>> wrote:
>>> On 11/24/20 7:57 AM, Peter Howkins wrote:
 
 I've pushed a series of patches to master that should resolve the GCC 10 
 build issues. Hopefully that will be enough to get the Fedora build 
 working, but I've only tested it on Debian.
 
 Peter
 
 -- 
 Peter Howkins
 peter.howk...@marutan.net 
 https://www.marutan.net/ 
 
>>> 
>>> 
>>> 
>>> Yes it compiles on Debian testing. However there are some problems in 
>>> dtterm shown in attached screenshot.
>>> I remember this is an old problem but I forgot its solution. At the 
>>> beggining of the screenshot I enabled Return and Line feed
>>> so no stairs get priduced. But then I can not use mv -i as I get the prompt 
>>> immediately after the overwrite question.
>>> 
>>> On ManjaroLinux/Arch it compiles but libcsa does not get produced.
>>> The make log for Manjaro is located here
>>> https://myria.math.aegean.gr/~atsol/tmp/make.log 
>>> 
>>> 
>>> Moreover, the desktop does not start on Manjaro/Arch... it complains about 
>>> /etc/hosts and the messaging system that does not get started.
>>> I do not know if this is related to libcsa.
>>> 
>>> Antonis.
>>> ___
>>> 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] CDE 2.3.2 has been released

[Richard L. Hamilton]

> 
> Also, what was the deal back in the OpenSolaris days before Oracle killed it? 
> Did that codebase have CDE? I also wonder about Illumos. Do they still have a 
> CDE codebase, too? I'm guessing Sun just didn't release it with the rest of 
> the code.

Sun didn't have the rights to release CDE at that time, so presumably didn't 
see the point in releasing their related code. Some things like the graphical 
workspace manager, seem to have been either licensed from or inspired by other 
CDE variants (Triteal is the one  that particularly resembles, if memory 
serves).

During the Solaris 10 to Solaris 11 days including OpenSolaris, there were 
releases called Solaris SXCE that still had CDE in them but had the evolving 
Solaris 11 environment underneath; the components unique to those were not 
open-sourced, and I think the license was limited to non-production use and 
perhaps to a limited timespan, although nothing actually enforced that (I think 
I have an x86 SXCE VM image still, and it works passably well last I tried; I 
may also have some  of the opencsw stuff on there, which is still updatable, 
although the OS itself is not).

I think I once compiled a non-recent version of open-source CDE for Solaris 11 
(SPARC), and it mostly worked, although dtmail was definitely unusable.



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

Re: [cdesktopenv-devel] sdtedit freely available ?

[Richard L. Hamilton]

Feel free; my preference is along the lines of modified BSD, something that 
presents no barrier to anyone.  No guarantees of anything, of course.  
Something with version control and notification of changes would be best, I 
think.  I have sourceforge and GitHub accounts, but have never used them except 
to fetch existing content.

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).

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.

  f.action
  f.beep
  f.change_backdrop (undocumented)  appears to require 
pathname of pixmap file as an argument
  f.circle_down
  f.circle_up
  f.create_workspace
  f.delete_workspace
  f.exec
  f.focus_color
  f.focus_key
  f.focus_key_raise
  f.goto_workspace
  f.help
  f.help_mode
  f.ignore
  f.kill
  f.lower
  f.marquee_selection
  f.maximize
  f.menu
  f.minimize
  f.move
  f.next_cmap
  f.next_key
  f.next_key transient
  f.next_workspace
  f.nop
  f.normalize
  f.normalize_and_raise
  f.occupy_all
  f.pack_icons
  f.pass_keys
  f.post_wmenu
  f.prev_cmap
  f.prev_key
  f.prev_key transient
  f.prev_workspace
  f.quit_mwm(documented as f.quit_dtwm)
  f.raise
  f.raise_lower
  f.refresh
  f.refresh_win
  f.remove
  f.resize
  f.restart
  f.restore
  f.restore_and_raise
  f.screen
  f.send_msg
  f.separator
  f.set_behavior
  f.set_context (undocumented)  appears to require one numeric 
argument, probably a window number (as shown by xlswins or xwininfo -tree -root)
WARNING: has been observed to 
crash dtwm when given without valid argument
  f.title
  f.toggle_frontpanel
  f.version
  f.workspace_presence


> On Jul 1, 2019, at 06:02, Andrey ``Bass'' Shcheglov  
> wrote:
> 
> 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 ?

[Richard L. Hamilton]

I have Solaris 9 and 10 systems running.  If you have the choice, look at 
Solaris 9 rather than 10.  ldd /usr/dt/sdthotkeys shows a bunch
more libraries on Solaris 10, that from the look of the names, have to do with 
optionally supporting Trusted Solaris (uses zones as isolation areas for
information of different sensitivity levels, plus a few other odds and ends in 
the interface).  Should be easier to figure out how it does what it does
without additional complications.  You may be able to use xscope to catch some 
of any X-based communication between processes - that's how
I figured out how dtstyle (I think it was) can restart dtwm; I have a command 
that will send f. commands to dtwm using that mechanism, although
you can figure out a neater way if you look at one of the CDE internal 
libraries, I suppose; libdtSvc, I think it was; that was back before source
availability, so I had to do it the hard way.  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.

Oh, here's what might be a hint as to where it keeps it.  From the Solaris 9 
versions, reasons as above.

$ strings /usr/dt/bin/sdthotkey|grep dtwmrc
$HOME/.dt/$LANG/dtwmrc
$HOME/.dt/dtwmrc
/etc/dt/config/$LANG/sys.dtwmrc
/etc/dt/config/sys.dtwmrc
/usr/dt/config/$LANG/sys.dtwmrc
/usr/dt/config/sys.dtwmrc
$HOME/.dt/sdthotkey.dtwmrc
$HOME/.dt/sdthotkey.dtwmrc.tmp
$HOME/.dt/sdthotkey.dtwmrc.old

$ strings /usr/dt/bin/dtwm|grep sdthotkey.dtwmrc
/.dt/sdthotkey.dtwmrc

In other words, it probably looks at the places above (except the ones ending 
in tmp and old), and according to that input plus user input
builds or replaces (with perhaps the one ending in tmp as output pending 
completion, followed by any existing file renamed to .old suffix,
and the new file renamed without the .tmp suffix?) $HOME/.dt/sdthotkey.dtwmrc.  
And perhaps tells dtwm to do an f.restart -noconfirm when it's done that.

And of course dtwm itself was modified to read the additional optional 
$HOME/sdthotkey.dtwmrc file and merge it into its internal idea of the hotkeys
(obtained at startup or restart from the other dtwmrc files that it reads).

All of which implies it may have to be able to parse existing dtwmrc files to 
determine existing hotkey settings.

nm on /usr/dt/bin/sdthotkey definitely suggests it was written at least partly 
in C++, given the mangled names.

There is a man page (on either Solaris 9 or 10) for sdthotkey. It also mentions 
that what it sets is stored in $HOME/.dt/sdthotkey.dtwmrc,
and also contains a warning (and thus presumably either sdthotkey or dtwm 
contains enforcement) that I think means you won't be allowed
to redefine keys already defined elsewhere, although you should read it for 
yourself, because that's not exactly what it says.

All I have for now.  That may be as far as I go with it; I'm more interested in 
if recent versions still build on Solaris 11 and especially whether anyone has 
made some reasonable progress on building for macOS. Not that it wouldn't be 
nice to have the IMAP in dtmail (primitive as it is) actually work, too. :-)



dtwmcmd.c
Description: Binary data


> On Jun 27, 2019, at 10:38, Swift Griggs  wrote:
> 
> On Thu, 27 Jun 2019, Andrey ``Bass'' Shcheglov wrote:
>> Which files under `${HOME}/.dt` does `sdthotkey` modify?
> 
> Good question. I'll have to fire up a Solaris box and find out. As you point 
> out, it can't be rocket science to map out the hotkeys and there is likely 
> full documentation somewhere knowing CDE.
> 
>> Probably the same functionality can be implemented using some python or 
>> shell scripting, with `zenity` or `xdialog` (or even `dtksh`) as the 
>> front-end.
> 
> I've rarely actually seen a Python GUI work. I've seen a *lot* of tracebacks, 
> though. Python scripts with GUIs make PHP-GTK or Perl-GTK programs seem 
> rock-solid-stable. They only seem to work in screenshots, but hey at least 
> the code is well-indented, hehe.
> 
> Now zenity and xdialog are interesting. Those have at least as good a chance 
> at working as most shell scripts you find in the wild. However, they have no 
> MOTIF look and feel unless you do a bunch of theme jiggery pokery. The dtksh 
> idea is one I like, too. That works okay and keeps it in the family. I'm not 
> aware of any zenity-alike thing for MOTIF besides dtksh. Then again, I could 
> stop whining and just write it in C, too. It's just that I haven't done MOTIF 
> from soup to nuts in 15 years. I think I still could, given enough drive, 
> though.
> 
> I've had the same ideas, honestly. Now, if I just had the time to start. It'd 
> be a fun and useful little project. The main reason I don't use CDE more is 
> that I haven't found an easy way to customize the hotkeys. Perhaps now is 
> time to do it the hard way.
> 
> -Swift
> 
> 
> 
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> 

Re: [cdesktopenv-devel] Integration of Antonis Tsolomitis' desktop_approots tarball, with some changes

[Richard L. Hamilton]

If you're saying you want wrappers that for example use whichever of xv, 
ImageMagick's "display" command, or whatever is available to display a JPG, and 
then to define actions that used the wrappers, fine.  But once that's all done, 
you'd still just use dtaction Open _filename_  to open the file from the 
command line.  The wrappers would help by doing what the action system can't - 
decide which of various programs are available to handle the filetype (and 
hopefully, fall back to displaying an error message in a window if none of them 
are available).

Wrappers are ok I guess as a short-term solution; but I think identifying 
lightweight (don't need e.g. an entire Gnome or KDE stack!) tools for simpler 
common functions (not big stuff like an office suite or browser) and bundling 
them, would be better.

Might be worth getting ahold of this guy and seeing if he has any interest in 
seeing his never-release "miv" (Motif Image Viewer) get some TLC and get added 
to the CDE revival. :-)
https://www.muquit.com/muquit/software/miv/miv.html



> On Jul 19, 2018, at 23:41, Matthew R. Trower  wrote:
> 
> Well, that would be the built-in functionality I asked about.
> It would still be useful, I feel, to have a familiar convention which matches 
> other desktop environments; dtopen would provide this.
> 
> Moreover, Jon's wrapper provides dynamic defaults for a variety of systems.
> 
> Right now, CDE doesn't ship with actions that cover a large variety of 
> filetypes. This makes some sense I guess, since CDE does not ship an image 
> viewer, for example. But it makes programs like dtfile less usable out of the 
> box. We can't really just define a single default program, because who knows 
> what the user actually has on their system.
> 
> -mrt
>   Original Message
> From: Richard L. Hamilton
> Sent: Thursday, July 19, 2018 22:32
> To: Jon Trulson
> Cc: cdesktopenv-devel@lists.sourceforge.net
> Subject: Re: [cdesktopenv-devel] Integration of Antonis Tsolomitis' 
> desktop_approots tarball, with some changes
> 
> Maybe I'm missing something, but what's the need for it at all?
> 
> dtaction Open _filename_
> 
> should, if the appropriate actions have been defined, recognize the file by 
> its magic number and/or name suffix, and run the appropriate viewer, or 
> whatever. And dtfile among others will be able to make use of that.
> 
>> On Jul 19, 2018, at 22:25, Jon Trulson  wrote:
>> 
>> On 07/19/2018 08:15 PM, Matthew R. Trower wrote:
>>> Hi Jon,
>>> Do I understand correctly that dtapp is meant to function in the same vein 
>>> as open, xdg-open, gnome-open, etc?
>>> As in, I can type
>>> $ dtapp mypic.jpg
>>> And my picture will open up in some suitable image viewer? If so, might you 
>>> consider continuing this naming convention‎ by naming it dtopen? (or have I 
>>> misunderstood, and maybe it just returns a string?)
>>> It's not a critical point, but I thought I might mention it for 
>>> consideration before dtapp gets wired into everything and particularly 
>>> before people start using it/scripting with it =)
>> 
>> That's a good point. At XiG, I called it dthelper, but I didn't like that so 
>> I used dtapp for these commit(s). I don't really like that either. :)
>> 
>> Right now, dtapp is just a simple shell script that is symlinked to various 
>> per-type specific "aliases" - ie: for images it would be
>> 
>> dtapp_vimage "filename"
>> 
>> to call a list of programs in order to display it (xv, display, etc).
>> 
>> I didn't really like "dtapp" and "dtapp_vimage", etc though.
>> 
>> I like your idea a lot better. dtopen would be the "base", it's symlinked 
>> aliases would be something like dtopen_image, dtopen_video, etc.
>> 
>> Yes, I do like that name a lot better. I'll make the change.
>> 
>> In the future, we can certainly enhance/replace dtopen if/when we like. 
>> Thanks for the suggestion!
>> 
>> -jon
>> 
>>> ‎- mrt
>>> Original Message
>>> From: Jon Trulson
>>> Sent: Thursday, July 19, 2018 21:05
>>> To: Antonis Tsolomitis; cdesktopenv-devel@lists.sourceforge.net
>>> Subject: [cdesktopenv-devel] Integration of Antonis Tsolomitis' 
>>> desktop_approots tarball, with some changes
>>> Hi Antonis,
>>> I'm also CC'ing the CDE list for their information as well.
>>> I have finally managed to integrate much of the stuff you provided in
>>> your desktop_approots tarball. WRT the icons, I just put them all in.
>>> If someone has a problem and complains, they can just ask us to remove

Re: [cdesktopenv-devel] es_ES.UTF-8 localizing

[Richard L. Hamilton]

Are those message files compiled with gencat(1)?  Some platforms have a command 
that does the reverse, e.g. converts a compiled message catalog file back into 
the source form (or an alternative form for human consumption that can't be fed 
back into gencat - my human-readable output may be different from other 
platforms, as I had no example at the time to compare with).  Solaris didn't, 
so I wrote one from scratch some years ago - I guess I wanted to add a message 
to an existing catalog.  The command (both mine and on the platforms that 
already have it) is called "dspcat".  On Solaris, mine will work better because 
there's no interface for enumerating messages, but I take advantage of the 
internal structure of the message files.  On other OS's, it will still work, 
but with brute force (trying all possible message set and message numbers), so 
it'd definitely be slower, although unless a message file was quite large, one 
might not notice.  I just fixed a minor thing in it (missing include file) 
after trying it on my Mac (where I only found one actual .cat file, as opposed 
to something of that name), and the brute force used there wasn't slow enough 
to be bothered by.

Are there situations where that would be helpful?  If so, it's available at 
http://www.smart.net/~rlhamil/goodies/dspcat.tar.gz  I think I even included a 
man page. :-)

> On Jun 27, 2018, at 16:29, Edmond Orignac  wrote:
> 
> On the question of localizing, I have written some notes at:
> 
> http://edmond.orignac.pagesperso-orange.fr/localisation.en.html
> 
> By experimenting with an Occitan locale and a Latin locale on linux, I can 
> say that what matters is whether an underlying linux locale is already 
> present. In the case of Occitan it was the case, and simply translating the 
> messages and placing the *.cat file in /usr/dt/lib/nls/msg/oc_FR.ISO8859-1/ 
> directory and adding the line
> 
> export LANG=oc_FR.ISO8859-1
> 
> to .dtprofile was all that was needed to have window titles and menus in 
> Occitan. I would expect that simply applying iconv or GNU recode to the 
> es_ES.ISO8859-1 and compiling the resulting *.msg files with gencat would 
> work. For generating the app-defaults, the backdrops/palettes description, 
> you have to apply a program merge that is in the CDE source tree. For merge 
> to work correctly, you need to indicate a UTF8 locale  with merge -lang 
> es_ES.UTF8  desc.es_ES.UTF8.
> 
> With Latin, there was no locale on Linux, and things were more complicated. 
> In the archive:
> 
> http://edmond.orignac.pagesperso-orange.fr/la_FR.ISO8859-1.tgz
> 
> the file Installation explains the steps for installation. You need first to 
> install a locale for linux, then make X aware of the existence of the new 
> locale. After that, you can install the message catalogues
> app-defaults etc...
> 
> There are a few shell scripts that I have used to generate the locales 
> appdefgen.sh catgen.sh typegen.sh configen.sh in the different directories 
> that can be adapted for creating the files in es_ES.UTF8.
> 
> I'll try to create an fr_FR.UTF8 locale for CDE along the lines I have 
> sketched. Since the linux locale is already on my computer, this should be 
> simple unless either gencat of merge is unable to handle UTF8.
> 
> 
> 
> Le 26/06/2018 à 20:33, Jon Trulson a écrit :
>> Antonis Tsolomitis did this for the Greek UTF8 locale.  Unfortunately, we 
>> didn't have the foresight to document all of the steps required.
>> 
>> This would make a great wiki article, if you can figure it out. It would 
>> help others in the future who want to do translations.
>> 
>> Maybe Antonis can describe the details, if he remembers :) But it can be 
>> done.  In your case it might even be easier in some ways, as we already have 
>> a es_ES.ISO8859-1 locale, whereas Antonis had to do the translations 
>> directly as we had no support for any Greek locales.
>> 
>> Some experimenting shows that 'iconv' can be used to translate between 
>> es_ES.ISO8859-1 and a es_ES.UTF-8 message catalog easily. I just don't know 
>> if that's enough, or what other steps might be involved.
>> 
>> I know most of the work would probably be in programs/localized/, with some 
>> components having their own localization (mainly in the form of message 
>> catalogs).
>> 
>> -jon
>> 
>> On 06/24/2018 11:06 AM, José Carlos Carrión Plaza wrote:
>>> Hi co-listers:
>>> 
>>> I'm willing to begin CDE es_ES.UTF-8 localizing.
>>> 
>>> Are they a subproject like this?
>>> 
>>> Anyone working in this?
>>> 
>>> Any roadmap of such type of work?
>>> 
>>> Any ideas?
>>> 
>>> Thanks in advance.
>>> 
>> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> 

Re: [cdesktopenv-devel] Modernization and re-tooling

[Richard L. Hamilton]

I forgot - one other thing good about dtmail (esp. on someone running on a tiny 
system, like that Raspberry Pi, maybe) is that it's far less of a memory hog 
than e.g. Thunderbird.

> On Jun 26, 2018, at 22:15, Richard L. Hamilton  wrote:
> 
> Signed PGP part
> I suppose one could come up with a configuration file for Thunderbird that 
> used dtaction commands to have the CDE type handling mechanism deal with as 
> many as possible (and relatively safe, e.g. NOT shell scripts) attachment 
> types.  That would allow some degree of natural integration.  Add to that a 
> theme for Thunderbird that gave it a more Motif-like look (and maybe multiple 
> versions of it to match some of the CDE color scheme choices), and IMO it 
> wouldn't be too bad.  The theme part would take some work from someone that 
> knows how, but a lot less work probably than modernizing dtmail.
> 
> The only thing I really liked about dtmail (Sun's version, where the IMAP 
> actually worked, although not with TLS, as I recall) was that it could work 
> with either local mailboxes or IMAP; and if migrating to IMAP from local 
> mailboxes and one used an IMAP server that could handle the existing mailbox 
> format, it was fairly painless and one could always fall back.  The lack of 
> inline display for HTML or RTF definitely was not nice, although back then, I 
> didn't necessarily expect those anyway.
> 
>> On Jun 26, 2018, at 19:19, Jon Trulson  wrote:
>> 
>> On 06/26/2018 05:09 PM, Robert Pangrazio wrote:
>>> I’ll see if I can find my exact setup, but that doesn’t sound right. I 
>>> wasn’t deleting messages as I was able to see them from multiple devices.
>>> I have an AWS server I use for my own projects, including CDE where I had 
>>> it set up. And since I access it through a website, why not just access my 
>>> gmail in a different tab. It was more of a proof of concept and not really 
>>> something I use all the time.
>>> It was however, in my opinion, a bit of a hack. And if somebody wants to 
>>> put true modern email server support in that would be awesome.
>>> I’ve been investigating html rendering for a little bit. I’ve been trying 
>>> to find the best way to integrate it into the system. I’ve looked at 
>>> including html rendering widgets like xmhtml, using chromes rendering 
>>> engine, or even including code from mosaic.
>>> I do have a question though. I have been looking at some other email 
>>> clients and wondering if we don’t replace dtmail with them.  Redo the ui to 
>>> match dtmail, but keep everything underneath the same. Is this an approach 
>>> anybody would even entertain? I’m not sure I like it, but the thought had 
>>> occurred.
>> 
>> That sounds problematic in terms of licensing and work (maintenance)...
>> 
>> That's why I was thinking to just use thunderbird, just like we will use 
>> firefox/chrome/whatever for web browsing, rather than try to invent a CDE 
>> web browser.
>> 
>> That's what I use now with a dozen or so accounts, accessed securely, some 
>> using client certs even. :)
>> 
>> We could "deprecate" dtmail, and maybe eventually remove it.  I just don't 
>> see someone jumping in and giving it the love it needs to be comparable to a 
>> modern email client.  It might happen, but I wouldn't bet any money on it.
>> 
>> -jon
>> 
>>> Thanks
>>> Robert Pangrazio
>>> 
>>> *From:* Matthew R. Trower 
>>> *Sent:* Tuesday, June 26, 2018 5:27 PM
>>> *To:* cdesktopenv-devel@lists.sourceforge.net
>>> *Subject:* Re: [cdesktopenv-devel] Modernization and re-tooling
>>> Robert Pangrazio  writes:
>>>> Also, I have used dtmail with GMail/IMAP using a local relay via
>>>> procmail to sync it to the local mailbox. Sending was via a local
>>>> sendmail relay. Worked great. I think the bigger issue is the lack of
>>>> HTML support. I couldn't read a lot of my emails because of it.
>>> My experience was that when using fetchmail (or getmail, or dtmail's
>>> builtin IMAP), you cannot leave messages on the server. If you do, they
>>> will be repeatedly fetched, causing much duplication. Local deletion
>>> also does not propagate back to the server. This is not how IMAP was
>>> intended to work; it is glorified POP.
>>> Does this not match your experience?
>>> Ah, HTML... yeah, as much as I try to avoid such mail, I suppose
>>> something should be done for it...
>>> -mrt
>>> --

Re: [cdesktopenv-devel] Modernization and re-tooling

[Richard L. Hamilton]

I suppose one could come up with a configuration file for Thunderbird that used 
dtaction commands to have the CDE type handling mechanism deal with as many as 
possible (and relatively safe, e.g. NOT shell scripts) attachment types.  That 
would allow some degree of natural integration.  Add to that a theme for 
Thunderbird that gave it a more Motif-like look (and maybe multiple versions of 
it to match some of the CDE color scheme choices), and IMO it wouldn't be too 
bad.  The theme part would take some work from someone that knows how, but a 
lot less work probably than modernizing dtmail.

The only thing I really liked about dtmail (Sun's version, where the IMAP 
actually worked, although not with TLS, as I recall) was that it could work 
with either local mailboxes or IMAP; and if migrating to IMAP from local 
mailboxes and one used an IMAP server that could handle the existing mailbox 
format, it was fairly painless and one could always fall back.  The lack of 
inline display for HTML or RTF definitely was not nice, although back then, I 
didn't necessarily expect those anyway.

> On Jun 26, 2018, at 19:19, Jon Trulson  wrote:
> 
> On 06/26/2018 05:09 PM, Robert Pangrazio wrote:
>> I’ll see if I can find my exact setup, but that doesn’t sound right. I 
>> wasn’t deleting messages as I was able to see them from multiple devices.
>> I have an AWS server I use for my own projects, including CDE where I had it 
>> set up. And since I access it through a website, why not just access my 
>> gmail in a different tab. It was more of a proof of concept and not really 
>> something I use all the time.
>> It was however, in my opinion, a bit of a hack. And if somebody wants to put 
>> true modern email server support in that would be awesome.
>> I’ve been investigating html rendering for a little bit. I’ve been trying to 
>> find the best way to integrate it into the system. I’ve looked at including 
>> html rendering widgets like xmhtml, using chromes rendering engine, or even 
>> including code from mosaic.
>> I do have a question though. I have been looking at some other email clients 
>> and wondering if we don’t replace dtmail with them.  Redo the ui to match 
>> dtmail, but keep everything underneath the same. Is this an approach anybody 
>> would even entertain? I’m not sure I like it, but the thought had occurred.
> 
> That sounds problematic in terms of licensing and work (maintenance)...
> 
> That's why I was thinking to just use thunderbird, just like we will use 
> firefox/chrome/whatever for web browsing, rather than try to invent a CDE web 
> browser.
> 
> That's what I use now with a dozen or so accounts, accessed securely, some 
> using client certs even. :)
> 
> We could "deprecate" dtmail, and maybe eventually remove it.  I just don't 
> see someone jumping in and giving it the love it needs to be comparable to a 
> modern email client.  It might happen, but I wouldn't bet any money on it.
> 
> -jon
> 
>> Thanks
>> Robert Pangrazio
>> 
>> *From:* Matthew R. Trower 
>> *Sent:* Tuesday, June 26, 2018 5:27 PM
>> *To:* cdesktopenv-devel@lists.sourceforge.net
>> *Subject:* Re: [cdesktopenv-devel] Modernization and re-tooling
>> Robert Pangrazio  writes:
>> > Also, I have used dtmail with GMail/IMAP using a local relay via
>> > procmail to sync it to the local mailbox. Sending was via a local
>> > sendmail relay. Worked great. I think the bigger issue is the lack of
>> > HTML support. I couldn't read a lot of my emails because of it.
>> My experience was that when using fetchmail (or getmail, or dtmail's
>> builtin IMAP), you cannot leave messages on the server. If you do, they
>> will be repeatedly fetched, causing much duplication. Local deletion
>> also does not propagate back to the server. This is not how IMAP was
>> intended to work; it is glorified POP.
>> Does this not match your experience?
>> Ah, HTML... yeah, as much as I try to avoid such mail, I suppose
>> something should be done for it...
>> -mrt
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> 
> --
> Jon Trulson
> 
> "Fire all weapons and open a hailing frequency for my victory yodle."
> 
> 

Re: [cdesktopenv-devel] [PATCH] Remove apollo support

[Richard L. Hamilton]

The "mess" emulator can emulate an Apollo DN3500 reasonably well; I've got that 
running SR10.4 that I sometimes play with for nostalgia's sake.  Not like I 
ever had CDE on an Apollo, so I have no stake in it; but just so you know the 
lack of hardware doesn't preclude someone running them.

> On Jun 24, 2018, at 15:20, Chase via cdesktopenv-devel 
>  wrote:
> 
> For everything except mkprod. This will be irrelevant pretty soon as moving 
> to autotools should make the db tools obsolete.
> 
> Thank you for your time,
> -Chase
> 
> 
> <0003-Remove-apollo-support.patch>--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] Remove Apple unix support

[Richard L. Hamilton]

> On Jun 24, 2018, at 12:26, Ulrich Wilkens  wrote:
> 
> On 06/24/18 17:29, Richard L. Hamilton wrote:
>>> On Jun 24, 2018, at 11:00, Chase via cdesktopenv-devel 
>>>  wrote:
>>> 
>>> This patch also cleans up a file with ifdef mess
>>> 
>>> Thank you for your time,
>>> -Chase
>> Hmm, some of us would like to see CDE work on our Macs one day; will this 
>> make it more difficult?
> 
> Just for information:
> 
> I've been working on a macOS port since a longer time.
> Have it now working for Mavericks, Yosemite and El Capitan.
> Sierra and High Sierra still have minor problems.
> 
> All of them have two annoying issues which are based in XQuartz.
> At the moment I'm trying to find a workaround.
> 
> But this is all beta stage and needs more work, so nothing for next
> release. Maybe I'll post the patch some time after the release.
> 
> 
> -- 
> Ulrich Wilkens
> Email: m...@uwilkens.de

I've noticed some issues that may relate.  I used to be able to display back an 
entire CDE desktop from one of my Suns, using a copy of the XQuartz app bundle 
that passed some extra arguments to the X server (typically an alternative 
display number so I could run it at the same time, and -query 
_remote_host_name_  (whichever that was).  As of a few XQuartz updates back, 
that doesn't work any more.

(The only catch with displaying back an entire desktop - when it worked - is 
that if you want the windows to appear to be separate, you have to use 
NoBackdrop; and you have to use an  icon box for the window manager, because 
individual icons (or the menu on the background) may not show up.)



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] Remove Apple unix support

[Richard L. Hamilton]

Nope, current (or at any rate, running macOS, formerly known as OS X), not a 
museum piece.  Ok, if that's the case, no objection.

Gotta say, I'm hopeful when I read people talk about moving to 
autoconf/automake etc instead of imake, which is not even available by default 
on reasonably recent macOS (I have 1.0.7 from MacPorts, but never got far with 
it).

> On Jun 24, 2018, at 11:32, Matthew R. Trower  wrote:
> 
> Not unless your Macintosh was manufactured 1987-1990 and runs A/UX ;)
> 
> -mrt
>   Original Message
> From: Richard L. Hamilton
> Sent: Sunday, June 24, 2018 10:29
> To: Chase
> Cc: CDE development
> Subject: Re: [cdesktopenv-devel] [PATCH] Remove Apple unix support
> 
> 
> 
>> On Jun 24, 2018, at 11:00, Chase via cdesktopenv-devel 
>>  wrote:
>> 
>> This patch also cleans up a file with ifdef mess
>> 
>> Thank you for your time,
>> -Chase
> 
> 
> Hmm, some of us would like to see CDE work on our Macs one day; will this 
> make it more difficult?
> 


signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] [PATCH] Remove Apple unix support

[Richard L. Hamilton]

> On Jun 24, 2018, at 11:00, Chase via cdesktopenv-devel 
>  wrote:
> 
> This patch also cleans up a file with ifdef mess
> 
> Thank you for your time,
> -Chase


Hmm, some of us would like to see CDE work on our Macs one day; will this make 
it more difficult?




signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] The sorry state of imake

[Richard L. Hamilton]

> On Jun 20, 2018, at 20:28, Jon Trulson  wrote:
> 
[...]
>> Would switching to autotools also solve the rpath problem?
> 
> Possibly, as I understand libtool changed it's behavior WRT to rpath.
> 
> In CDE for linux, rpath is added via ExtraLoadFlags in 
> config/cf/lnxLib.rules.  You could probably just override that in hosts.def 
> yourself and see what happens.
> 
> According to https://wiki.debian.org/RpathIssue, there is this paragraph 
> which would seem to apply to CDE:
> 
> "While there's no policy dictating the accepted use of RPATH, it's been a 
> general consensus that RPATH use is discouraged, given the interactions 
> between the above reasons and Debian's way of dealing with libraries and 
> package dependencies.
> 
> Currently, the only generally accepted use of this feature in Debian is to 
> add non-standard library path (like /usr/lib/) to libraries that are 
> only intended to be used by the executables or other libraries within the 
> same source package. "
> 
> So... not a big deal it would appear..?
> 


Newer systems with ELF format ld.so dynamic linker support $ORIGIN, i.e. 
something like
-Wl,-rpath=$ORIGIN/../lib
for a binary in somewhere like /opt/cde/bin to find its package-private 
libraries in /opt/cde/lib, with the whole tree relocatable (assuming that other 
non-linker references also had their own way of doing something similar).  That 
or something like it should address packaging concerns for most platforms, I 
should think.

Mac's Mach-O format and dyld dynamic linker support something similar, 
@loader_path; doubtless if the day comes for a Mac port, there are differences 
in command line args needed, etc; but the principle remains, at least.

Some quite old ELF ld.so implementations may not support $ORIGIN; Solaris 9 
(and even before, if with some quirks) does.  I have no personal experience 
with the object formats and dynamic linker capabilities on CDE platforms other 
than Solaris and Linux, although I gather that HP-UX uses ELF rather than an 
earlier proprietary format for 64-bit, and at some point switched to ELF for 
32-bit executables, too; and it seems to have $ORIGIN or something like iT.  
OTOH, it appears AIX uses XCOFF format and does not have a similar facility, 
although that might be old info.



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] dtterm malfunction

[Richard L. Hamilton]

vi (or any clone, like vim) saves the tty modes when it starts before setting 
its own, and restores them on exit; so that doesn't necessarily tell you 
anything.

Knowing the tty name for each, one could (from another window) do e.g. stty 
 On Jun 18, 2018, at 08:50, Antonis Tsolomitis  
> wrote:
> 
> 
> The screenshot dtterm.png shows two dtterms runing vi (vim)
> The one on the left shows erratic behavior since it repeats the info line of 
> vi
> at several heights while the dtterm on the right is a freshly started one and 
> behaves correctly.
> When this happens with vi you have to stop and start a fresh dtterm since 
> what you
> see does not correspond to the truth. There are lines showing text and text 
> does not exist on these.
> 
> Then I exited vi from both of them and run stty -a. This is the content of 
> screenshot dtterm2 which shows
> that the output is identical.
> 
> The system is Ubuntu 14.04LTS. CDE is latest stable.
> 
> Antonis.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Moving to MIT license

[Richard L. Hamilton]

Specific graphics can relate to branding; if they didn't want to do that, I can 
understand it.

They did put a lot of work into clang/llvm and CUPS, and that's certainly 
benefited others.  They've open sourced some things they wrote themselves (or 
bought), like libdispatch and the Swift compiler front-end, and FoundationDB.

As to why they do some things and not others, why do most people or 
organizations do most things?  For advantage, or sometimes because their 
lawyers told them to.  Now not all advantage is to anyone else's disadvantage, 
nor necessarily measurable in single-quarter profit. But selfless virtue should 
not be expected of any organization. :-)

> On Jun 17, 2018, at 11:13, Antonis Tsolomitis  > wrote:
> 
> 
> Exactly. This is the problem. One says "allow me so I can improve the 
> project" and
> after you allow s/he says "I will not contribute back".
> 
> This was why I mentioned Apple. Is it true of false that Apple used BSD to 
> build
> their Os? Is it true or false that they made billions of dollars with the 
> help of it?
> Is it true or false that the BSD community asked Apple to donate a few icons
> for their desktop, as a "thank you", and Apple refused?
> 
> This is the information I read on sites such as linuxtoday.com 
>  at that time.
> If false, OK. I will not trust linuxtoday again and forget what follows.
> 
> For me what Apple did was OK with the license, but if they indeed refused
> to donate a few desktop icons back to the project then I find this
> a strongly unethical attitude allowed by the license.
> 
> I am not a developer of CDE. Developers will decide what they want to do
> in the future. I just express my opinion since Jon asked about opinions.
> 
> Antonis.
> 
> 
> 
> Στις 16/06/2018 10:20 μμ, ο Chase έγραψε:
>> I can see both sides of the argument, although I must say that permissive 
>> licenses rarely see corporate users contribute back their code, Andrew 
>> tanenbaum, creator of Minix, received a letter from an employee of intel 
>> stating how intel preferred permissively licensed software to copyleft 
>> software as they wouldn't have to give their contributions to their 
>> competitors, which meant they were able to use Minix in the intel management 
>> engine without contributing code back to Minix. Although, I also think that 
>> the market CDE was created for, workstations, is long dead and gone, and 
>> thus any meaningful corporate contributions to CDE with it. I say we simply 
>> stick with LGPL, motif hasn't moved yet, the xutils havent moved, so that is 
>> going to be a lot of work for what seems to be very little reward.
>> 
>> Also, as far as I can tell (I am not a lawyer), the EPL is only incompatible 
>> with the GPL, not the LGPL, so we could probably still see an updated 
>> kornshell in CDE. I would however like to see the assets bumped to 
>> CC-BY-SA-4.0 still.
>> 
>> Thank you for your time,
>> -Chase
>> 
>> 
>> ‐‐‐ Original Message ‐‐‐
>> On June 14, 2018 5:27 AM, Antonis Tsolomitis  
>>  wrote:
>> 
>>> 
>>> 
>>> On 14/06/2018 12:55 μμ, Matthew R. Trower wrote:
 You seem to hold developers in low regard. Please consider: what happens 
 to a project with no developers?
 
>>> 
>>> Of course not. I have developed many things in the TeX world and of course 
>>> I am grateful to
>>> Jon and others who worked hard to free CDE and make it work.
>>> 
>>> So on the contrary, I am grateful to developers. I am just afraid that a 
>>> wrong turn will
>>> hurt again CDE. That is all.
>>> 
>>> And what about users? I have proof for the other direction. I have paid for 
>>> CDE and
>>> as a user I was treated with disrespect.*
>>> 
>>> Someone must think of the users too. Not only the developers.
>>> 
>>> Antonis.
>>> 
>>> 
>>> *The only useful thing about that buy was the book it came with the CD 
>>> which I now use
>>> with the LGPL CDE.
>> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org ! 
> http://sdm.link/slashdot___ 
> 
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] 2 (possibly) simple wishes

[Richard L. Hamilton]

> On Jun 16, 2018, at 05:59, Antonis Tsolomitis  
> wrote:
> 
> 
> A right click for menu and a click on Open is again 2 clicks. The issue here 
> is to cut down the clicks
> to 50%. All other common desktops I know of, support one click to open.

Right press and hold, menu comes up (keep holding); move to "Open" and release. 
 One down, hold and move, and back up again.

Of course, holding may be as bad as clicking, in which case that won't help.


> Moreover CDE desktop supports(!) 1 click to restore a minimized application 
> because it can be configured
> to select the minimized icon on mouse-over. It is dtfile that does not 
> support this (or I do not know how to set it up).

Something like focus follows mouse, but within an application such as dtfile?  
I never even imagined such a thing; probably the dtfile developers, or even the 
Motif developers, may not have either.  Of course, the X server doesn't care; 
i.e. _massive_ rewrites starting from at least the Motif level on up might make 
that possible (or for all I know, there are some imaginative tricks that might 
let mere application level rewrites do the job), but there's not likely to be 
any way to configure that.

There are mice that are made to be easier, even easier for clicking as well as 
holding or moving. Some trackballs are easier.  And some touchpads can be set 
to use a light tap rather than a click. But fancy touchpads usually need 
drivers (the options are implemented in software, although the hardware has to 
report more than a basic mouse-replacement touchpad would), probably only 
available on Windows or (for Apple hardware) built-in to macOS.  Linux and 
xfree86 may have better support for that than historical commercial Unixes.  To 
work with an old toolkit, it would have to happen below that level, e.g. at the 
OS or X server level.  But there are better mice that don't need special 
drivers; some of those listed on the link
below may be among them:

https://www.grayingwithgrace.com/what-is-the-best-computer-mouse-for-arthritic-hands/
 


They do tend to be quite expensive (over US$100); make sure you can return them 
if they don't help.



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] 2 (possibly) simple wishes

[Richard L. Hamilton]

> On Jun 15, 2018, at 14:12, Antonis Tsolomitis  
> wrote:
> 
> 
> I write 2 possibly simple wishes that would be useful to be resolved at some 
> point.
> 
> (a) Scrolling with the mouse wheel works on most CDE apps (after proper setup 
> of the .Xdefaults)
> except the filemanager, where
> it only works when the pointer is on the vertical scrolling bar. What makes a 
> difference with, say, dtterm
> where it works fine?

Typically, scroll wheel steps are mapped to button 4 and 5 (for up and down, or 
maybe the other way around, I forget).

I recall some info on that was made to work with dtterm and a few other apps:
http://pdit.compendiumblog.com/alanc/wheel-mouse-support-for-solaris%3A-part-2%3A-using-it-with-applications
 


That sort of behavior with scroll bars rings a bell, but the details are not 
coming back to me, except that there were cases where there wasn't much I could 
do in terms of just tweaking configuration.

> (b) Some way to configure single click instead of double click on the file 
> manager.
> I am an old guy. My fingers hurt with the clicks. There is no reason to have 
> to use
> double the number of clicks.
> 
> Antonis.

A single click already has a meaning (select something).  You can press and 
hold down the right mouse button, and move the pointer to the "Open" item on 
the popup menu, as an alternative to double clicking the left mouse button.



signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] question about windows list

[Richard L. Hamilton]

Looks like those do _not_ work with focus follows mouse; note the sentence for 
f.next_key and f.prev_key that says:
This function is treated as f.nop if keyboardFocusPolicy is not explicit.

(IMO, that makes sense enough, since with keyboardFocusPolicy: pointer (i.e. 
focus follows mouse), all you have to do anyway is move the mouse.)

from dtwm(1):
keyboardFocusPolicy (class KeyboardFocusPolicy)
 If set to pointer, the keyboard focus policy is to
 have the keyboard focus set to the client window
 that contains the pointer (the pointer could also be
 in the client window decoration that dtwm adds).  If
 set to explicit, the policy is to have the keyboard
 focus set to a client window when the user presses
 button 1 with the pointer on the client window or
 any part of the associated dtwm decoration.  The
 default value for this resource is explicit.

from dtwmrc(4):

f.next_key [icon | window | transient]
   This  function  sets  the  keyboard  input
   focus  to  the next window/icon in the set
   of windows/icons managed by the  workspace
   manager (the ordering of this set is based
   on the stacking of windows on the screen).
   This  function is treated as f.nop if key-
   boardFocusPolicy  is  not  explicit.   The
   keyboard input focus is only moved to win-
   dows that do not have an associated secon-
   dary window that is application modal.  If
   the transient argument is specified,  then
   transient(secondary)windowsare
   traversed (otherwise, if  only  window  is
   specified,  traversal  is done only to the
   last focused window in a transient group).
   If an icon function argument is specified,
   then the function applies only  to  icons.
   If  a  window  function argument is speci-
   fied, then the function  applies  only  to
   windows.

f.prev_key [icon | window | transient]
   This  function  sets  the  keyboard  input
   focus  to  the previous window/icon in the
   set  of  windows/icons  managed   by   the
   workspace  manager  (the  ordering of this
   set is based on the stacking of windows on
   the  screen).  This function is treated as
   f.nop if keyboardFocusPolicy is not expli-
   cit.   The  keyboard  input  focus is only
   moved to windows that do not have an asso-
   ciated  secondary  window that is applica-
   tion modal.  If the transient argument  is
   specified, then transient (secondary) win-
   dows are  traversed  (otherwise,  if  only
   window  is  specified,  traversal  is done
   only to the last focused window in a tran-
   sient  group).   If an icon function argu-
   ment  is  specified  then   the   function
   applies only to icons.  If an window func-
   tion argument is specified then the  func-
   tion applies only to windows.


> On Jun 15, 2018, at 02:47, Antonis Tsolomitis  <mailto:antonis.tsolomi...@gmail.com>> wrote:
> 
> 
> No. Alt-Tab or Alt-Esc do not work on stable, although my dtwmrc contains:
> 
> AltTabroot|icon|windowf.next_key
> Alt ShiftTabroot|icon|windowf.prev_key
> AltEscaperoot|icon|windowf.next_key
> Alt ShiftEscaperoot|icon|windowf.prev_key
> 
>  I do not know if there is a conflict with other settings
> (for example I use "focus follows mouse")
> 
> However, Alt-Down and Alt-Up work where these are set as
> f.circle_down
> f.circle_up
> 
> and these rotate the windows.
> So this is not so bad, I will do my job.
> 
> However, I also think that a windows list either in a menu (middle click) or 
> in a tray
> similar to iconbox would be very useful since it will be faster to find the 
> window you need
> than rotate them.
> 
> Yes..., xmpager similar to Triteal CDE would be great too.
> 
> Thanks everyone,
> 
> Antonis.
> 
> 
> 
> 
> On 15/06/2018 01:33 πμ, Richard L. Hamilton wrote:
>> 
>>> On Jun 14, 2018, at 18:10, Matthew R. Trower  
>>> <mailto:d...@blackshard.net> wrote:

Re: [cdesktopenv-devel] question about windows list

[Richard L. Hamilton]

> On Jun 14, 2018, at 20:12, Christopher Turkel  
> wrote:
> 
> I'd like a window list option, maybe a middle mouse button click.

There isn't a graphical one in basic CDE.  And it would be a lot of work, 
probably.  TriTeal and later Sun CDE had graphic workspace management tools, 
and at least the latter had something that would give a textual list of windows 
and I think allow selecting them.

Similar to the latter is 
http://web.archive.org/web/20090210060252/http://levana.de/findwindow/find_window.shtml
 





signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] question about windows list

[Richard L. Hamilton]

> On Jun 14, 2018, at 18:10, Matthew R. Trower  wrote:
> 
> ‎However, even though I said that... neither alt-esc nor alt-tab are 
> curr‎ently working for me (though the underlying functionality works when 
> accessed from a menu, and other keybinds work fine as well). They have worked 
> in the past. This could be a result of my private tree, or of something 
> that's changed in master at some point. I haven't been able to bisect yet.
> 
> If it‎ is broken for Antonis, or anyone else, I'd very much like to know.
>   Original Message
> From: Jon Trulson
> Sent: Thursday, June 14, 2018 15:24
> To: cdesktopenv-devel@lists.sourceforge.net
> Subject: Re: [cdesktopenv-devel] question about windows list
> 
> Oh, good point. I didn't read the last sentence. ALT-TAB should work...
> -jon
> 
> On 06/14/2018 01:34 PM, Matthew R. Trower wrote:
>> ‎This functionality should be bound to either alt+tab or alt+esc by default. 
>> Do they not work for you?
>> 
>> Have a look through programs/dtwm/WmResource.c sometime for other 
>> interesting keybinds.
>>   Original Message
>> From: Antonis Tsolomitis
>> Sent: Thursday, June 14, 2018 05:31
>> To: cdesktopenv-devel@lists.sourceforge.net
>> Subject: [cdesktopenv-devel] question about windows list
>> 
>> 
>> Many times I find myself in a difficult situation where many windows are
>> open
>> covering each other and have trouble bringing forward the one I want.
>> 
>> CDE does not seem to have a utility for finding the window you want. Or
>> does it?
>> 
>> Is there any standalone maybe application for such a task ? Or any other
>> solution?
>> For example on more common desktops alt+tab rotates the windows and you
>> can choose.


Using grep on my dtwmrc file (Sun CDE, on Solaris 9, in this case), I find
AltTab root|icon|windowf.next_key
Alt ShiftTab   root|icon|windowf.prev_key
AltEscape  root|icon|windowf.next_key
Alt ShiftEscaperoot|icon|windowf.prev_key
AltF6  window  f.next_key transient
Alt ShiftF6window  f.prev_key transient
AltTab root|icon|windowf.next_key
Alt ShiftTab   root|icon|windowf.prev_key
AltEscape  root|icon|windowf.next_key
Alt ShiftEscaperoot|icon|windowf.prev_key
AltF6  window  f.next_key transient

In other words, it's ultimately variations on f.next_key and f.prev_key dtwm 
commands that do the job, and the keys used can be defined as one wishes 
(subject to possible  complications with some keyboards and X servers as to 
what constitutes Alt, etc).

A dtwmrc(4) man page (at least in Sun CDE) describes the various f. window 
manager command.  While normally they can only appear in a window manager 
configuration file (save that dtstyle sends a command to the window manager to 
restart it, when needed), there is a protocol for sending f. commands to dtwm, 
and I have a C program that uses my reverse engineering of it (via xscope, I 
think) that I wrote a long time ago.  Given the source of one of the shared 
libraries whose interfaces are not documented, it may be possible to rewrite 
the program to do it that way...but it does work, regardless.  Source for my 
program is at http://www.smart.net/~rlhamil/goodies/dtwmcmd.c

So one could step through windows, or workspaces even (there was once someone 
that wanted to do that, I gather for a system with various status displays in 
separate workstations, using a large display or projector) programatically.

My notes indicate at least two f. commands not documented in dtwmrc(4):
f.change_backdrop   appears to require pathname of pixmap file as
   an argument

f.set_context   appears to require one numeric argument,
probably a window number (as shown by xlswins
or xwininfo -tree -root) WARNING: has been
observed to crash dtwm when given without
valid argument




signature.asc
Description: Message signed with OpenPGP
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Some plans and some questions

[Richard L. Hamilton]

> On May 3, 2016, at 07:35, Chris Wareham  wrote:
> 
>> On 01 May 2016 at 11:29 Edmond Orignac  wrote:
>> 
>> 
>> You are completely right. I was mentioning xmmixer as an example of an 
>> OSS sound mixing Motif application that is usable on Linux Slackware (or 
>> Gentoo) but probably not Linux Ubuntu or Fedora. It is also unclear to 
>> me whether xmmixer would be usable with the BSDs or OpenIndiana.
>> So xmmixer should not be distributed with CDE. But someone could try
>> to modify xmmixer to improve CDE integration and make it available 
>> separately via GitHub or Sourceforge, just like dtwinlist or Xarm.
>> Also, if someone wants to make a Linux Live CD with CDE as the GUI,
>> xmmixer could be included as a sound mixer if the underlying Linux OS is 
>> using the ALSA sound driver.
>> 
> 
> Xmmixer works on NetBSD and is include in pkgsrc, the packaging system for 
> third
> party applications. The NetBSD kernel audio and MIDI APIs are very similar to
> OSS, and there is a wrapper that provides an OSS compatible version of the 
> API.
> I believe the APIs are similar in OpenBSD and FreeBSD. Xmcd by the same author
> as Xmmixer also works on NetBSD, as it uses simple ioctl() calls to interact
> with a CD-ROM drive.
> 
>> 
>> I was suggesting Motif applications that could be used with CDE, not 
>> applications that should be included in CDE. You are right that since 
>> network applications need to be constantly reviewed and patched for 
>> security, they have no place in the basic CDE distribution. My 
>> proposition of considering CDE/Motif applications has to do with being 
>> able to get rid of network applications that don't just require Qt or 
>> GTK but the full KDE or GNOME infrastructure.
>> 
> 
> There was also a Motif PostScript (and possibly PDF) viewer called MGv. The
> original author's web page for it has disappeared, but I think the last 
> version
> was 3.1.5 and that source can be found elsewhere on various FTP sites.
> 
> Chris

Since I'd like to also see CDE eventually build on a Mac, I favor code cleanup, 
portability fixes, and maybe build modernization, over new features.  Although 
IMAP support in vanilla dtmail seems unusable...

BTW, found mgv 3.1.5 source at 
http://fossies.org/linux/misc/old/mgv-3.1.5.tar.gz; it builds e.g. on Mac El 
Capitan, although incorrectly enables an alternative version of the putenv() 
declaration, so I had to change a couple of the Makefiles to HAVE_PUTENV=1 
instead of HAVE_PUTENV=0.  For some reason, the workaround declaration supplied 
with mgv declares the parameter as const char *, while the standard does not 
specify const.  Anyway, it built once that was done, and worked since I had gs 
via MacPorts.  It also builds and works on Solaris 11, assuming one has gs 
installed.  Looks like gs is in pkg:/print/filter/ghostscript (@some_version) 
for Solaris 11.



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] sans-serif fonts in CDE

[Richard L. Hamilton]

CDE differs from common X11 practice in a couple of ways:

1) iso10646-1 fonts are not used for full Unicode coverage; rather, font lists 
(multiple fonts each covering different locales or encodings) are used.  That 
may be a Motif limitation; at any rate, Motif seems to include a number of 
functions for working with font lists.

I see some of the font list definitions in places like
/usr/dt/config/en_US.UTF-8/sys.font
/usr/dt/config/en_US.UTF-8/sys.resources

although some of those have to be consistent with certain app-defaults files, 
too.  Those files will exist for each supported locale.


2) CDE expects the existance of fonts (or more likely font aliases) with X 
Logical Font Description (XLFD - 
https://en.wikipedia.org/wiki/X_logical_font_description) names with the 
foundry name "dt" and the family names "application", "interface system", and 
"interface user".  One might expect that the window manager (dtwm) in 
particular uses the "interface system" fonts.

Those names would match the patterns
-dt-application-*-*-*-*-*-*-*-*-*-*-*-*
-dt-interface system-*-*-*-*-*-*-*-*-*-*-*-*
-dt-interface user-*-*-*-*-*-*-*-*-*-*-*-*

On Solaris, for most iso8859-# fonts, these are aliases to appropriate Lucida 
Sans or Lucida Sans Typewriter fonts.

Most likely you'd have to install those fonts (if you didn't already have 
them), and find the aliases (fonts.alias files in various directories on the 
font path) and alter them to use the fonts you desired.  This is NOT going to 
be easy to get right, since whatevre is there has been picked to be more or 
less compatible among the members of a font list.  It's not likely to just be 
one magic toggle in other words, but a fair amount of work.

(The Lucida family of fonts were designed to be readable under less than ideal 
conditions, like small sizes or low resolutions.  The choice of them is just 
one of a number of ways in which Sun put quite a lot of work into CDE, 
generally making it better than the vanilla version.  For example, generic 
dtmail IMAP support does not appear to work, but it does work (with limitations 
perhaps) on Sun's version.)

IF you already have a system running Solaris 10 or earlier, you could do this a 
lot more easily, by making sure it was running the X font server, and having 
your other systems put first on their font path a reference to that X font 
server.  That's also the way to easily get display-back of applications to look 
right, without having to install all the fonts on the system to which one is 
displaying back.

> On Mar 20, 2016, at 21:11, jz78...@comcast.net wrote:
> 
> Hi, 
> 
> this is probably a n00b question, but I'm pretty short on knowledge of X font 
> naming.  Can anyone tell me what I should do if I want to change my build of 
> CDE to use sans-serif fonts in title bars, menus, etc. like the later 
> versions of Solaris?
> 
> thank you,
> Jim
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140___
> cdesktopenv-devel mailing list
> cdesktopenv-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] SPARC build: a little more progress

[Richard L. Hamilton]

Ok, this NOT work with Xvnc (yes, I know how to set that up with CDE - an 
appropriate line in /etc/dt/config/Xservers).  It would return back to the 
login prompt not long after logging in; presumably there’s a server reset or 
something that it didn’t deal gracefully with.  Maybe that can be turned off?  
Don’t know.  I think there’s at least something that reduces a server grab to a 
keyboard grab while typing the password, which allows one to do some creative 
things like run a program with a shutdown button on top of the dtlogin screen.  
(I had one of those once, don’t think I have it anymore.)

So this was the excuse to run the powered USB extension cables and the long 
video cable (since I have an XVR-300 video card in my T5240).  And, after 
stopping gdm, setting the eeprom to use the keyboard/monitor instead of the 
virtual-console, rebooting, logging in, and manually running
/usr/dt/bin/dtlogin -daemon…IT WORKS IT WORKS!  Haven’t tried everything yet, 
but the desktop looks right, although of course the control panel is a bit more 
bare compared to the Sun one.

I wonder if there are some mods for dropping out to a text console session, as 
one can using Sun’s version.  And of course sdtwinlst is missing, as is the 
graphical one (sdtgwm?) probably inspired by TriTeal’s version.  But it’s 
progress, and it shows that getting it running on SPARC and Solaris 11.2 is 
quite doable.

On Nov 29, 2014, at 1:53 PM, Richard L. Hamilton rlha...@smart.net wrote:

 Thanks.  Ran into another even after touching all those; at that point, I got 
 wholesale about getting them all, not wanting to start over each time (and 
 the make doesn’t just pick up where it left off, as one might hope a 
 well-written one would).
 
 find /opt/solarisstudio12.3/prod/include/CC -type f ! -name '*.*' -exec touch 
 {} +
 
 should get them all, I hope. :-)
 
 Yes, did a clean make World and it actually finished!  Just finished the 
 install too.  Where can I find SMF manifests, scripts, and packaging 
 instructions (for both motif built as you did and CDE)?  Note: I’m on Solaris 
 11.2 SPARC.
 
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
 cdesktopenv-devel mailing list
 cdesktopenv-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] SPARC build: a little more progress

[Richard L. Hamilton]

Checked a few things.  dtcm may not be talking to a non-local rpc.cmsd (it 
mentioned the right host).  The year view is blank.  And I don’t think the IMAP 
support for dtmail actually works - not that dtmail isn’t lame enough to avoid 
until getting some other serious TLC too (like at least the ability to render 
HTML in the message window, including the smarts to NOT load remote images 
without permission, etc).  Recompiled some of my scrounges, since the library 
arrangement isn’t compatible; haven’t tried it all yet.  Don’t have any sound 
hooked up yet - would need a really long extension cable and a USB audio dongle 
(I may have the latter), since I’m not inclined to attempt to identify a 
SPARC/Solaris 11 compatible PCIe audio card.

On Nov 30, 2014, at 4:54 PM, Richard L. Hamilton rlha...@smart.net wrote:

 Ok, this NOT work with Xvnc (yes, I know how to set that up with CDE - an 
 appropriate line in /etc/dt/config/Xservers).  It would return back to the 
 login prompt not long after logging in; presumably there’s a server reset or 
 something that it didn’t deal gracefully with.  Maybe that can be turned off? 
  Don’t know.  I think there’s at least something that reduces a server grab 
 to a keyboard grab while typing the password, which allows one to do some 
 creative things like run a program with a shutdown button on top of the 
 dtlogin screen.  (I had one of those once, don’t think I have it anymore.)
 
 So this was the excuse to run the powered USB extension cables and the long 
 video cable (since I have an XVR-300 video card in my T5240).  And, after 
 stopping gdm, setting the eeprom to use the keyboard/monitor instead of the 
 virtual-console, rebooting, logging in, and manually running
 /usr/dt/bin/dtlogin -daemon…IT WORKS IT WORKS!  Haven’t tried everything yet, 
 but the desktop looks right, although of course the control panel is a bit 
 more bare compared to the Sun one.
 
 I wonder if there are some mods for dropping out to a text console session, 
 as one can using Sun’s version.  And of course sdtwinlst is missing, as is 
 the graphical one (sdtgwm?) probably inspired by TriTeal’s version.  But it’s 
 progress, and it shows that getting it running on SPARC and Solaris 11.2 is 
 quite doable.
 
 On Nov 29, 2014, at 1:53 PM, Richard L. Hamilton rlha...@smart.net wrote:
 
 Thanks.  Ran into another even after touching all those; at that point, I 
 got wholesale about getting them all, not wanting to start over each time 
 (and the make doesn’t just pick up where it left off, as one might hope a 
 well-written one would).
 
 find /opt/solarisstudio12.3/prod/include/CC -type f ! -name '*.*' -exec 
 touch {} +
 
 should get them all, I hope. :-)
 
 Yes, did a clean make World and it actually finished!  Just finished the 
 install too.  Where can I find SMF manifests, scripts, and packaging 
 instructions (for both motif built as you did and CDE)?  Note: I’m on 
 Solaris 11.2 SPARC.
 
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
 cdesktopenv-devel mailing list
 cdesktopenv-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
 cdesktopenv-devel mailing list
 cdesktopenv-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] SPARC build: a little more progress

[Richard L. Hamilton]

Using the git code, the wiki Solaris build instructions (minus the /usr/bin/cc 
- /usr/bin/gcc link), and the following PATH
PATH=/usr/gnu/bin:/usr/xpg4/bin:/usr/bin:/opt/solarisstudio/bin
(which avoided the version of sed that was running wild), I got a lot further; 
until the error sequence below.  Most of the binaries built, and the ones I can 
test by just putting the libraries they need in their proper place appear to 
work (ugly without resource files, but usable, at least for those I tried, e.g. 
dtksh, dtcalc, dtterm - nothing that needs the CDE-specific ToolTalk or RPC 
services for instance, since I don’t have them running).

Any idea what to try next would be appreciated.  In the full build output, I 
did not see any mention of libtptregexp, which I would have expected  prior to 
referencing the library as -ltptregexp.

So far, I see no reason to suppose that a SPARC build by someone who had 
previously succeed at an x86 build should run into any insurmountable problems. 
 Whether I do it (with someone else telling me in sufficient detail how they 
did their x86 build), or someone else with access to a modern enough SPARC to 
run Solaris 11 does it, I really think we ought to get it done somehow. :-)  
Once the build was straightforward, there’s no reason it couldn’t be done 
automatically on a regular basis, and given a test for successful completion, 
packaged up, and put in a test repository, assuming someone has the knowledge 
to create additional scripts to do that, and an idea for a version numbering 
convention that accommodates the idea of a snapshot as of X time (with manual 
intervention only needed when an official version number change is agreed-on.  
Builds agreed on as acceptably stable could be promoted from a test repo to a 
“stable” repo, etc.

Since I do have a T5240 that’s strictly my playtoy (albeit other LDOMs on there 
will be doing useful work for me that I don’t want disrupted), in principle I 
could run automated builds for awhile (not signing up to do that forever!!); 
but I will NOT host a repository or anything like that; so there would need to 
be a place that I could drop the results.


errors below:

LD_RUN_PATH=/usr/dt/lib:/usr/lib:/usr/X11/lib /opt/solarisstudio/bin/cc -o 
instant -O2 -Xa -L/usr/X11/lib -L../../../../exports/lib  
-L../../../../imports/motif/lib -L../../../../imports/x11/lib main.o util.o 
info.o translate.o traninit.o tranvar.o tables.o  browse.o 
-L../../../../programs/dtdocbook/lib/tptregexp -ltptregexp -L/usr/X11/lib 
-L/usr/lib   -lsocket -lnsl  
ld: fatal: library -ltptregexp: not found
*** Error code 2
make: Fatal error: Command failed for target `instant'
Current working directory 
/export/home/rlhamil_local/cde-git/cdesktopenv-code/cde/doc/util/dbtoman/instant
*** Error code 1
The following command caused the error:
for flag in -w ''; do \
case $flag in *=*) ;; *[ik]*) set +e;; esac; done; \
for i in instant ;\
do \
echo making all in doc/util/dbtoman/$i...; \
(cd $i  /usr/ccs/bin/make -w  all); \
done
make: Fatal error: Command failed for target `all'
Current working directory 
/export/home/rlhamil_local/cde-git/cdesktopenv-code/cde/doc/util/dbtoman
*** Error code 1
The following command caused the error:
for flag in -w ''; do \
case $flag in *=*) ;; *[ik]*) set +e;; esac; done; \
for i in dbtoman ;\
do \
echo making all in doc/util/$i...; \
(cd $i  /usr/ccs/bin/make -w  all); \
done
make: Fatal error: Command failed for target `all'
Current working directory 
/export/home/rlhamil_local/cde-git/cdesktopenv-code/cde/doc/util
*** Error code 1
The following command caused the error:
for flag in -w ''; do \
case $flag in *=*) ;; *[ik]*) set +e;; esac; done; \
for i in  util C de_DE.ISO8859-1 es_ES.ISO8859-1 fr_FR.ISO8859-1 
it_IT.ISO8859-1 ;\
do \
echo making all in doc/$i...; \
(cd $i  LANG=C /usr/ccs/bin/make -w  all);\
done
make: Fatal error: Command failed for target `all'
Current working directory 
/export/home/rlhamil_local/cde-git/cdesktopenv-code/cde/doc
make[1]: *** [all.doc] Error 1
make[1]: Leaving directory 
`/export/home/rlhamil_local/cde-git/cdesktopenv-code/cde'
make: *** [World] Error 2
09:36:08[13]monster:...cdesktopenv-code/cde 
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

[cdesktopenv-devel] see command doesn't finish in build

[Richard L. Hamilton]

Building on Solaris 11.2 SPARC, per the wiki (i.e. code from git), the 
following sed command never finishes; eventually it could run the disk out of 
space making parser.c arbitrarily large.  Off the top of my head, I’m not good 
enough with sed to see why.  Given the PATH I had set, it appears that 
/usr/xpg4/bin/sed was the version being used.

including in programs/dtcm/server...
/usr/ccs/bin/yacc -d  parser.y
sed -e s/yy/yyy/g -e \a# linea D y.tab.c  parser.c
^C

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] GDE, the GNU Desktop Environment (Was: Re: OS X and Autotools)

[Richard L. Hamilton]

On Nov 19, 2014, at 4:12 PM, Jon Trulson j...@radscan.com wrote:

 On Tue, 18 Nov 2014, Richard L. Hamilton wrote:
[…]
 My immediate interest is getting CDE on OS X and Solaris 11.  AFAIK,
 both of those either have automake/autoconf from the vendor, or
 have it in a reasonably well-supported packaging of free software
 (e.g. MacPorts for OS X).  So I would suppose porting to OS X
 (Solaris 11 supposedly more or less works, although I gather SPARC
 hasn’t been tried yet?) is if anything likelier with autotools than
 without.
 
 Probably not, but original CDE ran on sparc, so I don't see a huge
 issue there.  Mac on the otherhand -- I have no experience there.

FYI, I built Motif on Solaris 11.2 (current as of what’s available without a 
support contract, aside from adding a non-vendor fix for the bash 
vulnerability) easily enough.  I was pleased to see it didn’t clobber any 
vendor files I already had installed (and AFAIK I had a fairly complete install 
to start with).  I got a list of what it added by comparing a zfs snapshot 
before and after, which let me be sure it hadn’t clobbered anything (and gave 
me the option of rolling back if it had).  I haven’t really figured out the 
packaging mechanism new to Solaris 11 though, only know the SVR4 packaging 
(which still works, but is not repository based and is not preferred on Solaris 
11).  So haven’t made a package of it yet; and have enough going on for a few 
days that I probably won’t get further for awhile.

The Mac kernel is XNU - Mach + FreeBSD more or less; but the userspace, include 
files etc are not occasionally without surprises.  automake, autoconf, and 
libtool don’t appear to be included, but can be added using the free MacPorts 
infrastructure (which is how IMO it would be nice to eventually have CDE 
packaged for Mac, as whatever additional build files and patches etc as that 
might require, and that could also offer its own binary package).  The current 
(unbundled, but easily installable) X.org build for Macs AFAIK has no imake 
support, and while that also can be found in MacPorts, I don’t know where to 
start to find out if it will do me any good. Maybe I can look at the FreeBSD 
build instructions sometime and see whether anything can be done starting with 
them.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] GDE, the GNU Desktop Environment (Was: Re: OS X and Autotools)

[Richard L. Hamilton]

Hmm…if you have a writeup of what you did to build Motif and then CDE, I can 
certainly take a shot at replicating it on my T5240, although it may be next 
week before I can get much done; didn’t realize the scarcity of modern SPARC in 
hands free to use it as they wished.  :-)  (I’ve way too many Suns in the 
house, only three (SunBlade 100, SunBlade 2000, T5240) of which run anymore, 
and only one of which can run Solaris 11)

On Nov 20, 2014, at 1:12 AM, Murray Blakeman murr...@solarismultimedia.com 
wrote:

 
 On 20/11/2014 13:53, Richard L. Hamilton wrote:
 You’re quite right, I didn’t have that package installed.  It quite 
 surprises me that a full desktop install didn’t include even the motif lib 
 and headers anymore. :-/
 
 Do we know whether a build of CDE should work with the vendor Motif libs?
 See 
 http://sourceforge.net/p/cdesktopenv/discussion/general/thread/04877048/#e39c/9c69
 
 I didn't even try to build with the vendor version of motif but, 
 surpisingly, when I was first trying to build CDE I noticed it was 
 linking (successfully) with vendor motif rather than my installed 
 openmotif libraries.  Includes were from openmotif though.
 
 I've since fixed this.
 
 And are either of those packages available for SPARC?  (I have a T5240, but 
 only VMs on my Mac for Solaris x86, which I’m not likely to leave running 
 given the memory and performance hit)
 
 Unfortunately i don't have a SPARC system to build/test on so only x86.  
 Sorry.
 
 Regards
 
 Murray
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 cdesktopenv-devel mailing list
 cdesktopenv-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
 


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] GDE, the GNU Desktop Environment (Was: Re: OS X and Autotools)

[Richard L. Hamilton]

Copyleft vs permissive license arguments get in the way of making good 
technical decisions IMO - except when the distinction is needed for 
NON-ideological arguments.

Backwards compatibility has a couple of points to commend it:
* not alienating existing base in the hopes of pursuing a new base
* although it’s more work, the discipline involved CAN result in cleaner code 
in the long run.

IMO if X.org dumped imake, that’s a good reason to think about doing the same; 
HOWEVER, _if_ some of the platforms that the hardcore copyleft advocates would 
ignore cannot reasonably support autotools, then IMO that _is_ a reason to 
accept the complexity of dual build systems.  To those who think that code has 
some natural right to be open source, backwards compatibility is merely a 
compromise with the lack of that; but to those who simply want to USE something 
and leave the ideology behind, it’s _necessary_.  I’ve got Macs (Mac Mini 2007 
and 2011) and Suns (the most modern being a T5240) at home, and while from time 
to time I run a Linux VM on one of the Macs, it’s not what I use on a daily 
basis, but simply something for re-creating situations others might encounter.

My immediate interest is getting CDE on OS X and Solaris 11.  AFAIK, both of 
those either have automake/autoconf from the vendor, or have it in a reasonably 
well-supported packaging of free software (e.g. MacPorts for OS X).  So I would 
suppose porting to OS X (Solaris 11 supposedly more or less works, although I 
gather SPARC hasn’t been tried yet?) is if anything likelier with autotools 
than without.

On Nov 18, 2014, at 6:43 AM, Bruno Félix Rezende Ribeiro oitofe...@gnu.org 
wrote:

 Hello Steven!
 
 Em Mon, 17 Nov 2014 23:54:43 -0800
 Steven Edwards winehac...@gmail.com escreveu:
 
 I couldn't find any information on if anyone else is working on
 either of these but I've started hacking on it in my local tree and
 am making pretty good progress.
 
 I sent a message a few days ago to this very mailing list
 expressing my desire of migrating CDE's build system to GNU
 Autotools[0].  Unfortunately, CDE developers don't seem very receptive
 to this idea.
 
 I'm not the first one looking for this, however.  Oleksiy has
 contributed a significant amount of code for this end long before I
 came to the scene[1].  His lengthy patch and the discussion around it
 was just plainly ignored to the death of his helpful initiative.  
 
 On Sourceforge there are 8 forks of CDE's VCS code, but none of them
 implements Oleksiy changes, or any other in the direction of GNU
 Autotools.  Even if a patch for this end was accepted by the main
 developers, they would still require Imake build system to be working
 in parallel (imagine the mess), dragging the development of a efficient,
 stable and standard build system.  Furthermore, they require any
 contribution to be under a permissive license, and I don't feel
 comfortable with that, because to me copyleft is an achievement we
 should not give up without a very compelling reason, for the benefit of
 user's freedom.  Therefore, I'm afraid there is no other reasonable way
 of getting the build system migrated seamlessly if not by a fork. 
 
 I'm very interested in this and I'm considering the possibility of
 making a fork of CDE for the GNU project, so it can be one of the
 official desktops of the GNU's project distribution of the GNU
 system[3] that, coincidently, had a release today.  I'm thinking about
 naming it GDE, which stands for GNU Desktop Environment.
 
 The first step is to migrate CDE's code to GNU Savannah[4].  Then we
 can say good bye to the bloated and awful Sourceforge web interface and
 its commercial appeal[5].
 
 CDE's original project could still fill the niche of supporting ancient
 proprietary unices, with its ancient build system and worries about
 retro-compatibility for an undefined amount of time, eventually and
 deliberately letting some self-interested people or corporation take
 away CDE's users freedom; the freedom that take so much time and
 efforts to achieve!
 
 We just doesn't have to follow that path!  We can do better: the GNU
 way! :-)
 
 What do you think?  Don't you want to contribute to this effort even
 further?
 
 
 Footnotes:
 [0] http://sourceforge.net/p/cdesktopenv/mailman/message/33045815/
 [1] http://sourceforge.net/p/cdesktopenv/mailman/message/30437899/ 
 [3] http://www.gnu.org/software/guix
 [4] http://savannah.gnu.org/
 [5] If you have received this mail through the mailing list look at its
 footer: comercial advertising!  How can developers tolerate this
 behavior in every corner of their development facilities?
 
 -- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 ((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
 \_/  All software must be free as in freedom;
 
 --
 Download BIRT iHub F-Type - The