Discussion:
Some plans and some questions
(too old to reply)
Danilo Schöneberg
2016-04-28 18:09:27 UTC
Permalink
Moin,

There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).

I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So I
was thinking about some ideas:

1) A CDE-based Live-CD
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)

What would be the preferred option from the team point of view? This also
brings up another question. What is the long-term goal? Do we try to keep
CDE running as it is or are there plans to actively develop it into a next
generation? For instance, I would love to see some more applications
developed (like a really good ftp client, image viewer, perhaps adding some
HTML support to the mail client (either via XmHTML or maybe even webkit).
All based on Motif of course. It has all a UI needs. It may look a bit
dated, but I love it, much more than all the new-fangled stuff that blinks,
beeps and dances, but gobbles up resources.

One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE, LXQT)
look positively bloated and sluggish. It could really be an alternative on
low-end systems.

Cheers,
Hippo
Martin Etteldorf
2016-04-28 18:56:44 UTC
Permalink
Hi,

On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg
Post by Danilo Schöneberg
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
If you do this, please keep in mind that the "C" in CDE stands for
"Common". At least udev is a Linux-only thing as far as I remember,
and we don't want to end up with yet another LDE, do we? In regards of
automounting, personally I prefer to stick with the solutions provided
by the OS, i.e. autofs on Solaris and amd on FreeBSD. Linux probably
has something similar. I don't see a big advantage in integrating it
on the CDE layer. The functionality provided by the OS is working well
enough for me. YMMV.


Kind regards,

Martin Etteldorf
Antonis Tsolomitis
2016-04-28 19:47:34 UTC
Permalink
------------------------------------------------------------------------------
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
Danilo Schöneberg
2016-04-29 04:00:51 UTC
Permalink
Hi Antonis,

I think there was never anything wrong with X11 font support, until people
started asking for Comic Sans. You have to be careful what you include or
you'll end up with a huge behemoth that has hundreds of dependencies
because every beep needs to have its own library these days. In the end
people run out of names and name their library libcaca (which phenetically
mean libPoo in German btw). Back in the day Xfree built from source in
about three hours on a Pentium II. I built the latest XOrg on NetBSD last
week and it took a whooping eight hours,

Without git CDE and its dependencies still build in under two hours, even
on a low-range system, and I think that should stay that way. That is, if
you have Xorg already. I think the main selling point for CDE is its low
requirements in terms of resources. With a few moderate modernizations it
could carve out its own niche.
How about modern font support?
Antonis.
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So I
1) A CDE-based Live-CD
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)
What would be the preferred option from the team point of view? This also
brings up another question. What is the long-term goal? Do we try to keep
CDE running as it is or are there plans to actively develop it into a next
generation? For instance, I would love to see some more applications
developed (like a really good ftp client, image viewer, perhaps adding some
HTML support to the mail client (either via XmHTML or maybe even webkit).
All based on Motif of course. It has all a UI needs. It may look a bit
dated, but I love it, much more than all the new-fangled stuff that blinks,
beeps and dances, but gobbles up resources.
One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE, LXQT)
look positively bloated and sluggish. It could really be an alternative on
low-end systems.
Cheers,
Hippo
------------------------------------------------------------------------------
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
_______________________________________________
Peter Howkins
2016-04-29 17:11:31 UTC
Permalink
Openmotif, from version 2.3 onwards has xft font support built in without
any extra dependancies, that CDE can use pretty much directly.

I last had a go at making this work during the porting effort to Linux
before the open source release. This was before I had the regular CDE font
specifiers working.

Loading Image...
Loading Image...

All standard Motif widgets work out of the box, but it would still need
extra work for dtwm titlebars and menus, dtfile text under icons,
workspace names etc.

IMO this does look considerably better than the current font rendering
but this would need to be optional code, both at compile time (for older
motif with without xft), and runtime, for users that prefer trad x font
rendering.

I'll have a bit of a play and see if I can remember how to test this a bit
more.

Peter
Post by Danilo Schöneberg
Hi Antonis,
I think there was never anything wrong with X11 font support, until people
started asking for Comic Sans. You have to be careful what you include or
you'll end up with a huge behemoth that has hundreds of dependencies
because every beep needs to have its own library these days. In the end
people run out of names and name their library libcaca (which phenetically
mean libPoo in German btw). Back in the day Xfree built from source in
about three hours on a Pentium II. I built the latest XOrg on NetBSD last
week and it took a whooping eight hours, 
Without git CDE and its dependencies still build in under two hours, even
on a low-range system, and I think that should stay that way. That is, if
you have Xorg already. I think the main selling point for CDE is its low
requirements in terms of resources. With a few moderate modernizations it
could carve out its own niche. 
On 28 April 2016 at 21:47, Antonis Tsolomitis
How about modern font support?
Antonis.
Moin, 
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet). 
I have ten days of vacation coming up,  I was thinking about what to
do. I'm completely useless at sitting around idly for more than two
1) A CDE-based Live-CD
2) researching integration of some modern technologies (like automount
of devices, udev, sound systems) 
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)
What would be the preferred option from the team point of view? This
also brings up another question. What is the long-term goal? Do we try
to keep CDE running as it is or are there plans to actively develop it
into a next generation? For instance, I would love to see some more
applications developed (like a really good ftp client, image viewer,
perhaps adding some HTML support to the mail client (either via XmHTML
or maybe even webkit). All based on Motif of course. It has all a UI
needs. It may look a bit dated, but I love it, much more than all the
new-fangled stuff that blinks, beeps and dances, but gobbles up
resources. 
One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE,
LXQT) look positively bloated and sluggish. It could really be an
alternative on low-end systems. 
Cheers,
Hippo
------------------------------------------------------------------------------
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!
[2]https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
cdesktopenv-devel mailing list
[4]https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
References
Visible links
2. https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
4. https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
--
Peter Howkins
***@marutan.net
Antonis Tsolomitis
2016-05-04 20:57:38 UTC
Permalink
It is not a problem to have something optional. The problem is that
font handling is so difficult.

Moreover it is not that I want Comic Sans (as someone else wrote)
but look: you buy a quality font, say Lucida Grande (remember that Lucida
was always shipped with CDE at least on Solaris) and you can not use it.
And even if
you manage to use it, it will look ugly because the designers
have no reason to embed hinted bitmap fonts in modern fonts
as they did the old days. And all this should go together with utf-8
support.

Anyway...,

Antonis.
Post by Peter Howkins
Openmotif, from version 2.3 onwards has xft font support built in without
any extra dependancies, that CDE can use pretty much directly.
I last had a go at making this work during the porting effort to Linux
before the open source release. This was before I had the regular CDE font
specifiers working.
http://www.marutan.net/pics/CDE-20120329.png
http://www.marutan.net/pics/CDE-20120629.png
All standard Motif widgets work out of the box, but it would still need
extra work for dtwm titlebars and menus, dtfile text under icons,
workspace names etc.
IMO this does look considerably better than the current font rendering
but this would need to be optional code, both at compile time (for older
motif with without xft), and runtime, for users that prefer trad x font
rendering.
I'll have a bit of a play and see if I can remember how to test this a bit
more.
Peter
Post by Danilo Schöneberg
Hi Antonis,
I think there was never anything wrong with X11 font support, until people
started asking for Comic Sans. You have to be careful what you include or
you'll end up with a huge behemoth that has hundreds of dependencies
because every beep needs to have its own library these days. In the end
people run out of names and name their library libcaca (which phenetically
mean libPoo in German btw). Back in the day Xfree built from source in
about three hours on a Pentium II. I built the latest XOrg on NetBSD last
week and it took a whooping eight hours,
Without git CDE and its dependencies still build in under two hours, even
on a low-range system, and I think that should stay that way. That is, if
you have Xorg already. I think the main selling point for CDE is its low
requirements in terms of resources. With a few moderate modernizations it
could carve out its own niche.
On 28 April 2016 at 21:47, Antonis Tsolomitis
How about modern font support?
Antonis.
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to
do. I'm completely useless at sitting around idly for more than two
1) A CDE-based Live-CD
2) researching integration of some modern technologies (like automount
of devices, udev, sound systems)
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)
What would be the preferred option from the team point of view? This
also brings up another question. What is the long-term goal? Do we try
to keep CDE running as it is or are there plans to actively develop it
into a next generation? For instance, I would love to see some more
applications developed (like a really good ftp client, image viewer,
perhaps adding some HTML support to the mail client (either via XmHTML
or maybe even webkit). All based on Motif of course. It has all a UI
needs. It may look a bit dated, but I love it, much more than all the
new-fangled stuff that blinks, beeps and dances, but gobbles up
resources.
One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE,
LXQT) look positively bloated and sluggish. It could really be an
alternative on low-end systems.
Cheers,
Hippo
------------------------------------------------------------------------------
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!
[2]https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
cdesktopenv-devel mailing list
[4]https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
References
Visible links
2. https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
4. https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Jon Trulson
2016-05-05 01:50:11 UTC
Permalink
Post by Antonis Tsolomitis
It is not a problem to have something optional. The problem is that
font handling is so difficult.
Moreover it is not that I want Comic Sans (as someone else wrote)
but look: you buy a quality font, say Lucida Grande (remember that Lucida
was always shipped with CDE at least on Solaris) and you can not use it.
And even if
you manage to use it, it will look ugly because the designers
have no reason to embed hinted bitmap fonts in modern fonts
as they did the old days. And all this should go together with utf-8
support.
Anyway...,
For my own two cents, I agree. Modern font handling and proper UTF8
supoort would be a big win for CDE.
-jon

[...]
--
Jon Trulson

"If we can hit that bull's-eye, the rest of the dominoes will fall
like a house of cards... Checkmate."
-- Zapp Brannigan
Antonis Tsolomitis
2016-05-05 11:22:07 UTC
Permalink
Post by Jon Trulson
Post by Antonis Tsolomitis
It is not a problem to have something optional. The problem is that
font handling is so difficult.
Moreover it is not that I want Comic Sans (as someone else wrote)
but look: you buy a quality font, say Lucida Grande (remember that Lucida
was always shipped with CDE at least on Solaris) and you can not use it.
And even if
you manage to use it, it will look ugly because the designers
have no reason to embed hinted bitmap fonts in modern fonts
as they did the old days. And all this should go together with utf-8
support.
Anyway...,
For my own two cents, I agree. Modern font handling and proper UTF8
supoort would be a big win for CDE.
-jon
[...]
I am happy I am not alone in this :-)

I do not know about improvements from the developer point of view, but
from the user point of view
I think some things must be clear:

1. Modern font handling with full unicode support (now based on old xorg
mechanism)
2. A mixer with volume control docked in the panel
(now one may use pavucontrol. This is also absolutely necessary
because it is not trivial without some tool,
such as pavucontrol, to
select microphone for communications (eg Skype); modern hardware
has typically two
microphones, one next to camera and a mic-in)
3. An easy way to easily select/modify/display keyboard state (now one
may use XXkb).
4. An easy way to theme gtk2 and gtk3 apps to match CDE themes (this
includes major apps such as
firefox, thunderbird, LibreOffice, inkscape etc) (this can be extra
independent code). Number 2 above
can be partly bypassed if one manages to theme pavucontrol; but the
docked volume control is needed.

Antonis.
alx
2016-05-05 13:53:48 UTC
Permalink
Post by Antonis Tsolomitis
Number 2 above
can be partly bypassed if one manages to theme pavucontrol; but the
docked volume control is needed.
Perhaps the front panel's ability to capture X clients may be of help
here (provided there is a standalone systray applet for pulseaudio). You
can put any X window into the front panel by adding a "client" control
type to your dtwm.fp. The CDE administrator's guide describes it in
detail, but basically it's:

CONTROL <name>
{
TYPE client
CONTAINER_NAME <parent BOX>
CONTAINER_TYPE BOX
CLIENT_NAME <class name (WM_CLASS) of the client (must be launched)>
CLIENT_GEOMETRY <WxH>
}
Antonis Tsolomitis
2016-05-05 14:12:22 UTC
Permalink
Post by alx
Post by Antonis Tsolomitis
Number 2 above
can be partly bypassed if one manages to theme pavucontrol; but the
docked volume control is needed.
Perhaps the front panel's ability to capture X clients may be of help
here (provided there is a standalone systray applet for pulseaudio).
You can put any X window into the front panel by adding a "client"
control type to your dtwm.fp. The CDE administrator's guide describes
CONTROL <name>
{
TYPE client
CONTAINER_NAME <parent BOX>
CONTAINER_TYPE BOX
CLIENT_NAME <class name (WM_CLASS) of the client (must be launched)>
CLIENT_GEOMETRY <WxH>
}
Yes, it is true. But it does not work with known to me volume controls
or I never found how to make it work.
And it definitely will not match in appearance with the panel. Solaris
CDE had such a CDE-style applet in the panel.

But maybe I miss something. What do you mean by "must be launched"?

Antonis.
alx
2016-05-05 14:36:28 UTC
Permalink
Post by Antonis Tsolomitis
But maybe I miss something. What do you mean by "must be launched"?
The client must be launched at startup (e.g. from
~/.dt/sessions/sessionetc), since dtwm only takes care of reparenting
the window.
Antonis Tsolomitis
2016-05-05 19:18:08 UTC
Permalink
Post by alx
Post by Antonis Tsolomitis
But maybe I miss something. What do you mean by "must be launched"?
The client must be launched at startup (e.g. from
~/.dt/sessions/sessionetc), since dtwm only takes care of reparenting
the window.
Aha, then I have to retry with some volume control applet. Nice
experiment, although the look will not match.

Antonis.
Antonis Tsolomitis
2016-05-08 13:19:55 UTC
Permalink
Post by alx
Post by Antonis Tsolomitis
Number 2 above
can be partly bypassed if one manages to theme pavucontrol; but the
docked volume control is needed.
Perhaps the front panel's ability to capture X clients may be of help
here (provided there is a standalone systray applet for pulseaudio).
You can put any X window into the front panel by adding a "client"
control type to your dtwm.fp. The CDE administrator's guide describes
CONTROL <name>
{
TYPE client
CONTAINER_NAME <parent BOX>
CONTAINER_TYPE BOX
CLIENT_NAME <class name (WM_CLASS) of the client (must be launched)>
CLIENT_GEOMETRY <WxH>
}
Either I have hit a bug or I am doing something wrong:
cp /usr/dt/appconfig/types/el_GR.UTF-8/dtwm.fp ~/.dt/types/

Modify ~/.dt/types/dtwm.fp
CONTROL Blank
{
TYPE blank
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
POSITION_HINTS 3
ICON FpblnkS
HELP_TOPIC FPOnItemSwitch
HELP_VOLUME FPanel
}

TO

CONTROL VolCtrl
{
TYPE client
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
POSITION_HINTS 3
CLIENT_NAME mate-volume-control-applet
CLIENT_GEOMETRY 22x22
}

(The CONTAINER_TYPE BOX you wrote above can not be correct)

Now if I start the Work Space Manager the Switch turns to what you see
in the screenshot.

I see at least one bug here: the panel thinks that there are 3 rows
instead of 2 and the position
of the buttons lock, exit and busy are erratically positioned.

Even so, if I now start mate-volume-control-applet nothing happens
(it was expected that the volume applet will appear in the reserved
position on Switch).

Any comments please?

Antonis.
Antonis Tsolomitis
2016-05-08 13:27:36 UTC
Permalink
Post by Antonis Tsolomitis
Post by alx
Post by Antonis Tsolomitis
Number 2 above
can be partly bypassed if one manages to theme pavucontrol; but the
docked volume control is needed.
Perhaps the front panel's ability to capture X clients may be of help
here (provided there is a standalone systray applet for pulseaudio).
You can put any X window into the front panel by adding a "client"
control type to your dtwm.fp. The CDE administrator's guide describes
CONTROL <name>
{
TYPE client
CONTAINER_NAME <parent BOX>
CONTAINER_TYPE BOX
CLIENT_NAME <class name (WM_CLASS) of the client (must be launched)>
CLIENT_GEOMETRY <WxH>
}
cp /usr/dt/appconfig/types/el_GR.UTF-8/dtwm.fp ~/.dt/types/
Modify ~/.dt/types/dtwm.fp
CONTROL Blank
{
TYPE blank
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
POSITION_HINTS 3
ICON FpblnkS
HELP_TOPIC FPOnItemSwitch
HELP_VOLUME FPanel
}
TO
CONTROL VolCtrl
{
TYPE client
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
POSITION_HINTS 3
CLIENT_NAME mate-volume-control-applet
CLIENT_GEOMETRY 22x22
}
(The CONTAINER_TYPE BOX you wrote above can not be correct)
Now if I start the Work Space Manager the Switch turns to what you see
in the screenshot.
I see at least one bug here: the panel thinks that there are 3 rows
instead of 2 and the position
of the buttons lock, exit and busy are erratically positioned.
Even so, if I now start mate-volume-control-applet nothing happens
(it was expected that the volume applet will appear in the reserved
position on Switch).
Any comments please?
Antonis.
I forgot to add that it does the same with 16x16 geometry.

Antonis.
alx
2016-05-08 16:48:28 UTC
Permalink
Hi, I just tested it on FreeBSD (don't have a Linux VM), but that
shouldn't make much difference in this case.

Make sure you're getting the right client name with:
$ xprop | grep WM_CLASS

The output for the chosen window should be something like:
WM_CLASS(STRING) = "xclock", "XClock"
The quoted string on the left is the one you want.

I used these entries in my dtwm.fp to make xload appear in the workspace
switch, and xclock among the drawers:

CONTROL clock
{
TYPE client
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
CLIENT_NAME xclock
CLIENT_GEOMETRY 24x24
}

CONTROL load
{
TYPE client
CONTAINER_NAME Top
CONTAINER_TYPE BOX
CLIENT_NAME xload
CLIENT_GEOMETRY 48x48
}


Hope this helps.

Alex
Antonis Tsolomitis
2016-05-08 20:35:30 UTC
Permalink
Post by alx
Hi, I just tested it on FreeBSD (don't have a Linux VM), but that
shouldn't make much difference in this case.
$ xprop | grep WM_CLASS
WM_CLASS(STRING) = "xclock", "XClock"
The quoted string on the left is the one you want.
I used these entries in my dtwm.fp to make xload appear in the
CONTROL clock
{
TYPE client
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
CLIENT_NAME xclock
CLIENT_GEOMETRY 24x24
}
CONTROL load
{
TYPE client
CONTAINER_NAME Top
CONTAINER_TYPE BOX
CLIENT_NAME xload
CLIENT_GEOMETRY 48x48
}
Hope this helps.
Alex
Yes it works with apps like xload, xclock etc (although I am not sure
that the position hints work and
I think there is a bug there in the CDE code or the administrator guide
for CDE is not clear enough)
but it does not work with applets. And what the panel needs with respect
to sound is an applet.

Your suggestion was to use the above mechanism to solve this issue. But
I can not make it work.
For example, such an applet is

mate-volume-control-applet

This command starts volume control on mate panel. If I run xprop | grep
WM_CLASS
and click on the volume control, I naturally get "mate-panel". And this
can not be correct.
Even if I try this, embedding in CDE panel does not work.

Maybe there is another way to learn the correct WM_CLASS of an applet.
It does not work
with xprop.

Thanks,

Antonis.
Antonis Tsolomitis
2016-05-08 20:39:47 UTC
Permalink
Post by alx
Hi, I just tested it on FreeBSD (don't have a Linux VM), but that
shouldn't make much difference in this case.
$ xprop | grep WM_CLASS
WM_CLASS(STRING) = "xclock", "XClock"
The quoted string on the left is the one you want.
I used these entries in my dtwm.fp to make xload appear in the
CONTROL clock
{
TYPE client
CONTAINER_NAME Switch
CONTAINER_TYPE SWITCH
CLIENT_NAME xclock
CLIENT_GEOMETRY 24x24
}
CONTROL load
{
TYPE client
CONTAINER_NAME Top
CONTAINER_TYPE BOX
CLIENT_NAME xload
CLIENT_GEOMETRY 48x48
}
Hope this helps.
Alex
xprop -name mate-volume-control-applet | grep WM_CLASS

gives

WM_CLASS(STRING) = "mate-volume-control-applet",
"Mate-volume-control-applet"

But still using mate-volume-control-applet embedding in CDE panel does
not work.

Antonis.

Chris Wareham
2016-04-29 08:41:47 UTC
Permalink
Post by Danilo Schöneberg
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So I
1) A CDE-based Live-CD
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)
What would be the preferred option from the team point of view? This also
brings up another question. What is the long-term goal? Do we try to keep
CDE running as it is or are there plans to actively develop it into a next
generation? For instance, I would love to see some more applications
developed (like a really good ftp client, image viewer, perhaps adding some
HTML support to the mail client (either via XmHTML or maybe even webkit).
All based on Motif of course. It has all a UI needs. It may look a bit
dated, but I love it, much more than all the new-fangled stuff that blinks,
beeps and dances, but gobbles up resources.
One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE, LXQT)
look positively bloated and sluggish. It could really be an alternative on
low-end systems.
Cheers,
Hippo
My opinion, for what it's worth, is that I'd like to see the priority on code
cleanups with new features only added at this stage if they can be done in a
"clean" way. For example, where there are well defined boundaries in the code
that would allow something like XmHTML to be integrated into the mail client
with minimal hooks into the mail client code itself.

There's still a lot of inelegant code in CDE that could do with clean up and
encapsulating. For example, I tried to turn the ISAM code into a well
encapsulated library with a clear API. I spent roughly twenty to thirty hours on
it, but ran out of time and junked my progress. I would have liked to have
completed this and added some tests that would amount to a unit test suite. It
was hard work, since there is quite a lot of dependencies between code across
the whole of CDE that should be much more independent.

Adding some kind of automated support for Coverity would be a cool addition as
well. It's provided excellent information for projects like NetBSD. Ultimately
though, this is an open source project and I'm sure any well written changes
will be gratefully received, regardless of whether they are cleanups or new
features :-)

Chris
Edmond Orignac
2016-04-29 17:32:42 UTC
Permalink
Post by Danilo Schöneberg
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So
1) A CDE-based Live-CD
There was a Debian based Linux distribution called CDebian. I am unsure
whether it has kept current with CDE. There is a github page at
https://github.com/andarazoroflove/CDE-Projects
Post by Danilo Schöneberg
2) researching integration of some modern technologies (like automount
of devices, udev, sound systems)
It is better to leave out sound systems. On Linux alone, one would
have to support ALSA, OSS, Jackd and PulseAudio.
Post by Danilo Schöneberg
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
4) code cleanup (warnings)
What would be the preferred option from the team point of view? This
also brings up another question. What is the long-term goal? Do we try
to keep CDE running as it is or are there plans to actively develop it
into a next generation? For instance, I would love to see some more
applications developed (like a really good ftp client, image viewer,
perhaps adding some HTML support to the mail client (either via XmHTML
or maybe even webkit).
There was a LGPL licensed ftp client called AxyFTP using Motif and
DtWidget library
http://hpux.connect.org.uk/hppd/hpux/Networking/FTP/axyftp-0.5.1/
There has been some messages in that mailing list about the Ida Motif
image viewer and its integration into CDE.
All based on Motif of course. It has all a UI
Post by Danilo Schöneberg
needs. It may look a bit dated, but I love it, much more than all the
new-fangled stuff that blinks, beeps and dances, but gobbles up resources.
One thing I noticed on my old Compaq nx8220, running NetBSD: CDE makes
other DE's that were deliberately designed to be lightweight (LXDE,
LXQT) look positively bloated and sluggish. It could really be an
alternative on low-end systems.
There are some comparison of RAM usage of the different DEs (on Linux).
https://eerielinux.wordpress.com/tag/opencde/
LXDE and Razor-Qt use 10 to 40 MB more than CDE. That could contribute
to their slowness on an old machine.
Post by Danilo Schöneberg
Cheers,
Hippo
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Isaac Dunham
2016-04-30 05:13:15 UTC
Permalink
Post by Danilo Schöneberg
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So I
1) A CDE-based Live-CD
Look at CDEbian; I think it's not active any more, but it should be
helpful.
On this note, work on making the install scripts more suitable for
packagers would be very helpful.
Post by Danilo Schöneberg
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
As far as automount goes, it would seem that if you have a panel in dtfile
that lists block devices, you could create an action for block devices
that would call your automounter/open dtfile at the mount point.

As far as sound support goes, there's a whole lot of APIs under *nix.
I'd suggest that the best approach would be
-get a separate mixer program working
-make sure it can be embedded in the dtwm front panel
The first place I found is "CDE frontpanel embeds sdtperfmeter-but how?":
http://www.verycomputer.com/168_b0cb70320892a5a3_1.htm
xmmixer is the first program that comes to mind, but there are a couple
others; I'm not aware of any work towards embedding these.

If you're talking about 'sound theme'-type deals where you need to modify
CDE to play a sound when you click on a certain item, please don't.
(I, for one, don't like the modern stuff that "blinks, beeps, and dances".)
Post by Danilo Schöneberg
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
Modernizing dtmail to some extent sounds nice.
My own wishlist would be IMAP support, and perhaps xmhtml integration.

Don't touch Webkit; it's a security nightmare and a bottomless pit for
time.
One of the GTK webkit developers wrote about the security status of the
ports; it seems that gtkwebkit sporadically gets some security updates,
the others get none, and there's no channel or protocol for communicating
about vulnerabilities between ports. In essence, it's several projects
that happen to use a single tree.
Besides that, webkit regularly breaks API, requiring periodic rewrites.
Timewise, you might get a port ready in a few months.
Post by Danilo Schöneberg
4) code cleanup (warnings)
This would be the best, I think.
Post by Danilo Schöneberg
What would be the preferred option from the team point of view? This also
brings up another question. What is the long-term goal? Do we try to keep
CDE running as it is or are there plans to actively develop it into a next
generation?
As far as I can tell, the goal is
* clean it up
* make the parts conform to relevant standards underneath.
- there was talk about using libmagic for filetype detection
- there was talk about using *.desktop rather than *.dt actions
- dtwm needs EWMH for modern programs to act nicely
- tooltalk to dbus migration came up; dbus is apparently an incompatible
clone of tooltalk, so this might be relatively simple
Post by Danilo Schöneberg
For instance, I would love to see some more applications
developed (like a really good ftp client, image viewer, perhaps adding some
HTML support to the mail client (either via XmHTML or maybe even webkit).
All based on Motif of course. It has all a UI needs. It may look a bit
There were several Motif FTP clients in the past; I've never looked hard
enough to say if any/which were good.

For image viewers, Ida is quite good and the code is very clean, though
the image format support is pretty limited, and it can't set the desktop
background (that's a longstanding TODO item, so patches are quite likely
to be accepted).
When I asked about whether CDE integration would be welcome, the maintainer
was quite ready to accept patches. I don't think I got much feedback here,
though. (Then I ended up switching to a much-less-compatible distro,
where I've never tried building CDE. And now, I'm a week or so from going
offline for the summer.)

I already commented on XmHTML vs Webkit, and mentioned IMAP support for
dtmail.

Other roles where Motif programs are sorely lacking, IMHO:
- A video player (I'd start with ffmpeg or libav, rather than gstreamer.
But that's personal choice.)
- An audio player. (You don't really need a dedicated one, if your 'video
player' is properly set up.)
- Something like the "X printing panel", where you can essentially build
an 'lp' command line
- web browsers, but these are *big* projects.
(Daydreaming...I'd like to see the video player done as a widget, which
can be used for 'HTML5'-style video support in XmHTML, and then XmHTML
hooked up to libcurl to create a web browser. I realize that this would
not be a high-feature browser, having no JS/CSS, and only limited HTML,
but IMHO the main reasons to use something newer than MosaicCK are:
-a lack of any security support
-Mosaic's network code is old and slow
-it isn't possible to play video
Unfortunately, some knuckleheads have decided that a novel's worth of JS
and CSS is the only way to show webpages...)

Thanks,
Isaac Dunham
Edmond Orignac
2016-04-30 10:44:47 UTC
Permalink
Post by Isaac Dunham
Post by Danilo Schöneberg
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do.
I'm completely useless at sitting around idly for more than two days. So I
1) A CDE-based Live-CD
Look at CDEbian; I think it's not active any more, but it should be
helpful.
On this note, work on making the install scripts more suitable for
packagers would be very helpful.
Post by Danilo Schöneberg
2) researching integration of some modern technologies (like automount of
devices, udev, sound systems)
As far as automount goes, it would seem that if you have a panel in dtfile
that lists block devices, you could create an action for block devices
that would call your automounter/open dtfile at the mount point.
As far as sound support goes, there's a whole lot of APIs under *nix.
I'd suggest that the best approach would be
-get a separate mixer program working
-make sure it can be embedded in the dtwm front panel
http://www.verycomputer.com/168_b0cb70320892a5a3_1.htm
xmmixer is the first program that comes to mind, but there are a couple
others; I'm not aware of any work towards embedding these.
xmmixer was designed for use with OSS and is working at least on Linux
with ALSA and OSS emulation. However, except for Slackware, Linux
distributions have moved to PulseAudio, and I am unsure OSS
compatibility remains.
Post by Isaac Dunham
If you're talking about 'sound theme'-type deals where you need to modify
CDE to play a sound when you click on a certain item, please don't.
(I, for one, don't like the modern stuff that "blinks, beeps, and dances".)
Post by Danilo Schöneberg
3) "modernizing" some of the dt apps (mail, text editor, dtlogin)
Modernizing dtmail to some extent sounds nice.
My own wishlist would be IMAP support, and perhaps xmhtml integration.
On the IMAP access, dtmail has an option of using a custom retrieval
command in the "Mail Retrieval" menu. Could fetchmail(1) be used to
retrieve messages from an IMAP server for dtmail ? That would already
mitigate the current limitation.
Post by Isaac Dunham
Don't touch Webkit; it's a security nightmare and a bottomless pit for
time.
One of the GTK webkit developers wrote about the security status of the
ports; it seems that gtkwebkit sporadically gets some security updates,
the others get none, and there's no channel or protocol for communicating
about vulnerabilities between ports. In essence, it's several projects
that happen to use a single tree.
Besides that, webkit regularly breaks API, requiring periodic rewrites.
Timewise, you might get a port ready in a few months.
Post by Danilo Schöneberg
4) code cleanup (warnings)
This would be the best, I think.
Post by Danilo Schöneberg
What would be the preferred option from the team point of view? This also
brings up another question. What is the long-term goal? Do we try to keep
CDE running as it is or are there plans to actively develop it into a next
generation?
As far as I can tell, the goal is
* clean it up
* make the parts conform to relevant standards underneath.
- there was talk about using libmagic for filetype detection
- there was talk about using *.desktop rather than *.dt actions
- dtwm needs EWMH for modern programs to act nicely
- tooltalk to dbus migration came up; dbus is apparently an incompatible
clone of tooltalk, so this might be relatively simple
Post by Danilo Schöneberg
For instance, I would love to see some more applications
developed (like a really good ftp client, image viewer, perhaps adding some
HTML support to the mail client (either via XmHTML or maybe even webkit).
All based on Motif of course. It has all a UI needs. It may look a bit
There were several Motif FTP clients in the past; I've never looked hard
enough to say if any/which were good.
On the Motif FTP clients, besides AxyFTP [ftp.wxftp.seul.org/pub/wxftp/
]that I mentioned in a previous email, there is XmFTP
[http://viraj.org/old/xmftp/index.html] and XDIR
[https://computing.llnl.gov/resources/xdir/xdir.html].
There are two older clients, xgetftp and moxftp. Only the first one
seems to compile on a modern system, but it is unable to even list the
contents of a directory.

Concerning editors, NEdit, Ted and XEmacs already support Motif. XEmacs
21.4 can be compiled with support for CDE drag and drop. Ted
http://www.nllgg.nl/Ted/ allows to edit RTF files.
Post by Isaac Dunham
For image viewers, Ida is quite good and the code is very clean, though
the image format support is pretty limited, and it can't set the desktop
background (that's a longstanding TODO item, so patches are quite likely
to be accepted).
When I asked about whether CDE integration would be welcome, the maintainer
was quite ready to accept patches. I don't think I got much feedback here,
though. (Then I ended up switching to a much-less-compatible distro,
where I've never tried building CDE. And now, I'm a week or so from going
offline for the summer.)
I already commented on XmHTML vs Webkit, and mentioned IMAP support for
dtmail.
- A video player (I'd start with ffmpeg or libav, rather than gstreamer.
But that's personal choice.)
- An audio player. (You don't really need a dedicated one, if your 'video
player' is properly set up.)
- Something like the "X printing panel", where you can essentially build
an 'lp' command line
- web browsers, but these are *big* projects.
Concerning video players, MPlayer appears to be quite usable under CDE.
Maybe building a control panel in the style of gmplayer, but using the
Motif toolkit could be sufficient.
By contrast, xine crashes at startup under CDE with
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
while it does not crash in Windowmaker.

For network applications, besides FTP, email clients and Web browsers,
on could think of Motif IRC clients (Nebula is one, SmIRC is another one
but apparently cannot be compiled with a recent g++), Motif instant
messaging (https://github.com/gorais/gXipmsg) Motif RSS/Atom readers.

Something that could also be useful would be a graphical interface to
set up wireless communications by listing possible access points and
offering the possibility to run iwconfig/wpa_supplicant/dhclient to
connect to the selected access point. But this is perhaps feasible using
only dtksh scripting.
Post by Isaac Dunham
(Daydreaming...I'd like to see the video player done as a widget, which
can be used for 'HTML5'-style video support in XmHTML, and then XmHTML
hooked up to libcurl to create a web browser. I realize that this would
not be a high-feature browser, having no JS/CSS, and only limited HTML,
-a lack of any security support
-Mosaic's network code is old and slow
-it isn't possible to play video
There was a Web browser/HTML editor developed at INRIA called Amaya
ftp.vim.org/pub/ibiblio/apps/www/browsers/amaya/ that used an OSF/Motif
interface. I think the more recent versions use WxWidgets to hide
whether the underlying toolkit is GTK or Motif.
Post by Isaac Dunham
Unfortunately, some knuckleheads have decided that a novel's worth of JS
and CSS is the only way to show webpages...)
Thanks,
Isaac Dunham
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Brent Busby
2016-04-30 15:30:21 UTC
Permalink
Post by Edmond Orignac
xmmixer was designed for use with OSS and is working at least on Linux
with ALSA and OSS emulation.
Since it's a Motif program, it would seem to be the best choice if we're
needing a mixer for CDE. I don't think it's absolutely necessary for
CDE to have a mixer though. People tend to use whatever sound apps
appeal to them and their uses, and not necessarily the one provided by
the desktop manager.
Post by Edmond Orignac
However, except for Slackware, Linux
distributions have moved to PulseAudio, and I am unsure OSS
compatibility remains.
I'm running Gentoo, which lets you happily compile away all support and
requirements for PulseAudio. I also do a lot of recording and Midi work
on this machine, so it's a good thing that I can get rid of it, because
PulseAudio generally gets in the way of that sort of usage. I use Alsa
for regular desktop sound, and Jack for studio/recording apps.

Again, I think this whole subject is a black hole you could disappear
into. It's probably best if CDE doesn't even attempt to do sound.
Post by Edmond Orignac
Post by Isaac Dunham
Don't touch Webkit; it's a security nightmare and a bottomless pit for
time.
Amen! CDE should leave the web to the web browsers.
Post by Edmond Orignac
For network applications, besides FTP, email clients and Web browsers,
on could think of Motif IRC clients (Nebula is one, SmIRC is another one
but apparently cannot be compiled with a recent g++), Motif instant
messaging (https://github.com/gorais/gXipmsg) Motif RSS/Atom readers.
IRC clients can also be exploited. CDE shouldn't be trying to provide
Internet client software of any kind really. If someone wants to write
Motif-based Internet applications, fine. They can even be linked from
CDE's web page so users will know about them. But it's a really bad
idea for CDE itself to be getting into the network software business.
Post by Edmond Orignac
Post by Isaac Dunham
Unfortunately, some knuckleheads have decided that a novel's worth of JS
and CSS is the only way to show webpages...)
Oh, that's when they're being kind. Now we have AJAX sites (<cough>,
<cough>..."Web 2.0"), which make JavaScript and CSS look minimalistic
and spartan in comparison.

Anyway, I'm afraid of all this turning into bloat real fast if we're not
careful. To me, CDE doesn't need to do much more than what it does now,
but in a way that's compliant with modern UNIX systems. It doesn't need
Internet clients, video players, sound mixers, or a marching brass band.
It should just preserve the look and feel of the old 90's UNIX
workstations for people who still want that.

One feature that would be very nice though (since it affects the
usability of the desktop itself) would be the ability to gracefully
handle things like a video player (not provided by CDE itself) going to
fullscreen, or a game going fullscreen, or a screen reconfiguration
using RandR on a desktop with multiple displays. Back in the days of
SparcStations and HPPA machines, it might have seemed reasonable that
the X desktop geometry would never change during a login session, or
that no application would ever try to take the whole screen, but these
days, that's a basic usability issue for even the most minimal usage.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
Edmond Orignac
2016-05-01 10:29:16 UTC
Permalink
Post by Brent Busby
Post by Edmond Orignac
xmmixer was designed for use with OSS and is working at least on Linux
with ALSA and OSS emulation.
Since it's a Motif program, it would seem to be the best choice if we're
needing a mixer for CDE. I don't think it's absolutely necessary for
CDE to have a mixer though. People tend to use whatever sound apps
appeal to them and their uses, and not necessarily the one provided by
the desktop manager.
Post by Edmond Orignac
However, except for Slackware, Linux
distributions have moved to PulseAudio, and I am unsure OSS
compatibility remains.
I'm running Gentoo, which lets you happily compile away all support and
requirements for PulseAudio. I also do a lot of recording and Midi work
on this machine, so it's a good thing that I can get rid of it, because
PulseAudio generally gets in the way of that sort of usage. I use Alsa
for regular desktop sound, and Jack for studio/recording apps.
Again, I think this whole subject is a black hole you could disappear
into. It's probably best if CDE doesn't even attempt to do sound.
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.
Post by Brent Busby
Post by Edmond Orignac
Post by Isaac Dunham
Don't touch Webkit; it's a security nightmare and a bottomless pit for
time.
Amen! CDE should leave the web to the web browsers.
Post by Edmond Orignac
For network applications, besides FTP, email clients and Web browsers,
on could think of Motif IRC clients (Nebula is one, SmIRC is another one
but apparently cannot be compiled with a recent g++), Motif instant
messaging (https://github.com/gorais/gXipmsg) Motif RSS/Atom readers.
IRC clients can also be exploited. CDE shouldn't be trying to provide
Internet client software of any kind really. If someone wants to write
Motif-based Internet applications, fine. They can even be linked from
CDE's web page so users will know about them. But it's a really bad
idea for CDE itself to be getting into the network software business.
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.
Post by Brent Busby
Post by Edmond Orignac
Post by Isaac Dunham
Unfortunately, some knuckleheads have decided that a novel's worth of JS
and CSS is the only way to show webpages...)
Oh, that's when they're being kind. Now we have AJAX sites (<cough>,
<cough>..."Web 2.0"), which make JavaScript and CSS look minimalistic
and spartan in comparison.
Anyway, I'm afraid of all this turning into bloat real fast if we're not
careful. To me, CDE doesn't need to do much more than what it does now,
but in a way that's compliant with modern UNIX systems. It doesn't need
Internet clients, video players, sound mixers, or a marching brass band.
It should just preserve the look and feel of the old 90's UNIX
workstations for people who still want that.
One feature that would be very nice though (since it affects the
usability of the desktop itself) would be the ability to gracefully
handle things like a video player (not provided by CDE itself) going to
fullscreen, or a game going fullscreen, or a screen reconfiguration
using RandR on a desktop with multiple displays. Back in the days of
SparcStations and HPPA machines, it might have seemed reasonable that
the X desktop geometry would never change during a login session, or
that no application would ever try to take the whole screen, but these
days, that's a basic usability issue for even the most minimal usage.
Chris Wareham
2016-05-03 11:35:04 UTC
Permalink
Post by Edmond Orignac
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.
Post by Edmond Orignac
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
Richard L. Hamilton
2016-05-03 13:44:03 UTC
Permalink
Post by Chris Wareham
Post by Edmond Orignac
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.
Post by Edmond Orignac
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.
Antonis Tsolomitis
2016-05-04 21:02:23 UTC
Permalink
I would say that a mixer is needed only if it can be embedded in the
main panel.

Otherwise, pavucontrol does the job (at least with pulse).

Antonis.
Post by Richard L. Hamilton
Post by Chris Wareham
Post by Edmond Orignac
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.
Post by Edmond Orignac
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...
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Tomasz Konojacki
2016-05-01 10:31:32 UTC
Permalink
On Sat, 30 Apr 2016 12:44:47 +0200
Post by Edmond Orignac
xmmixer was designed for use with OSS and is working at least on Linux
with ALSA and OSS emulation. However, except for Slackware, Linux
distributions have moved to PulseAudio, and I am unsure OSS
compatibility remains.
Slackware 14.2 (not yet released) uses PulseAudio too.
Martin Etteldorf
2016-05-01 11:15:33 UTC
Permalink
Hi,

On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg
Post by Danilo Schöneberg
Moin,
There is one system left I'm checking out the build for - Linux From
Scratch. I'm building it right now (the system. Not CDE yet).
I have ten days of vacation coming up, I was thinking about what to do. I'm
completely useless at sitting around idly for more than two days. So I was
[...]
There is one thing that comes to my mind, which would greatly improve things:
- Overhaul the utmp implementation in dtterm and replace it by utmpx.
dtterm still tries to log sessions via utmp, but utmp has been
deprecated in FreeBSD and Solaris since quite a while by utmpx. Linux
also uses utmpx, as far as I see (albeit with log files named after
the old utmp scheme).


Kind regards,

Martin Etteldorf
Pascal Stumpf
2016-05-02 17:10:11 UTC
Permalink
Post by Martin Etteldorf
Hi,
On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg
system left I'm checking out the build for - Linux From > Scratch. I'm
building it right now (the system. Not CDE yet). > > I have ten days of
vacation coming up, I was thinking about what to do. I'm > completely
useless at sitting around idly for more than two days. So I was >
thinking about some ideas: > [...]
There is one thing that comes to my mind, which would greatly improve
things: - Overhaul the utmp implementation in dtterm and replace it by
utmpx. dtterm still tries to log sessions via utmp, but utmp has been
deprecated in FreeBSD and Solaris since quite a while by utmpx. Linux
also uses utmpx, as far as I see (albeit with log files named after the
old utmp scheme).
Objection. That would kill OpenBSD support.
Post by Martin Etteldorf
Kind regards,
Martin Etteldorf
------------------------------------------------------------------------
------ 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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Martin Etteldorf
2016-05-03 04:08:43 UTC
Permalink
Post by Pascal Stumpf
Objection. That would kill OpenBSD support.
I don't see a problem there, unless you are trying to tell me that
xterm doesn't work properly on OpenBSD either. xterm has been
rewritten with utmpx support ages ago and I haven't heard a single
voice complaining that it was broken on OpenBSD afterwards.


Kind regards,

Martin Etteldorf
Pascal Stumpf
2016-05-03 04:46:25 UTC
Permalink
Post by Martin Etteldorf
Post by Pascal Stumpf
Objection. That would kill OpenBSD support.
I don't see a problem there, unless you are trying to tell me that
xterm doesn't work properly on OpenBSD either. xterm has been
rewritten with utmpx support ages ago and I haven't heard a single
voice complaining that it was broken on OpenBSD afterwards.
xterm has not deleted support for utmp in favour of utmpx. It checks in
./configure.
Post by Martin Etteldorf
Kind regards,
Martin Etteldorf
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Martin Etteldorf
2016-05-03 06:44:55 UTC
Permalink
Post by Pascal Stumpf
xterm has not deleted support for utmp in favour of utmpx. It checks in
./configure.
What speaks against implementing it in a similar fashion in dtterm?
BTW: Is there a better reason than "It's evil because it comes from
SVR4" why utmpx hasn't been implemented in OpenBSD yet? I remember
back in 2010 this was the only argument(1) from the OpenBSD guys.


Kind regards,

Martin Etteldorf

(1): "It's SVR4 crap inherited when X/Open and POSIX were merged into
the same standard." -- Mark Kettenis on the openbsd-tech mailinglist
Loading...