Re: [cdesktopenv-devel] Some plans and some questions
On 08/05/2016 07:48 μμ, alx wrote:
> 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
>
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.
--
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] Some plans and some questions
On 08/05/2016 07:48 μμ, alx wrote:
> 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
>
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.
--
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] Some plans and some questions
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
--
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] Some plans and some questions
On 08/05/2016 04:19 μμ, Antonis Tsolomitis wrote:
> On 05/05/2016 04:53 μμ, alx wrote:
>> On 05/05/16 13:22, Antonis Tsolomitis wrote:
>>> 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
>> {
>> TYPE client
>> CONTAINER_NAME
>> CONTAINER_TYPE BOX
>> CLIENT_NAME
>> CLIENT_GEOMETRY
>> }
>
> 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_NAMESwitch
> CONTAINER_TYPESWITCH
> POSITION_HINTS3
> ICON FpblnkS
> HELP_TOPICFPOnItemSwitch
> HELP_VOLUME FPanel
> }
>
> TO
>
> CONTROL VolCtrl
> {
> TYPE client
> CONTAINER_NAMESwitch
> CONTAINER_TYPESWITCH
> POSITION_HINTS3
> 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.
--
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] Some plans and some questions
On 05/05/2016 04:53 μμ, alx wrote:
On 05/05/16 13:22, Antonis Tsolomitis wrote:
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
{
TYPE client
CONTAINER_NAME
CONTAINER_TYPE BOX
CLIENT_NAME
CLIENT_GEOMETRY
}
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_NAMESwitch
CONTAINER_TYPESWITCH
POSITION_HINTS3
ICON FpblnkS
HELP_TOPICFPOnItemSwitch
HELP_VOLUME FPanel
}
TO
CONTROL VolCtrl
{
TYPE client
CONTAINER_NAMESwitch
CONTAINER_TYPESWITCH
POSITION_HINTS3
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.
--
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] Some plans and some questions
On 05/05/2016 05:36 μμ, alx wrote: > On 05/05/16 16:12, Antonis Tsolomitis wrote: >> 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. -- 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] Some plans and some questions
On 05/05/16 16:12, Antonis Tsolomitis wrote: > 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. -- 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] Some plans and some questions
On 05/05/2016 04:53 μμ, alx wrote:
> On 05/05/16 13:22, Antonis Tsolomitis wrote:
>> 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
> {
> TYPE client
> CONTAINER_NAME
> CONTAINER_TYPE BOX
> CLIENT_NAME
> CLIENT_GEOMETRY
> }
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.
--
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] Some plans and some questions
On 05/05/16 13:22, Antonis Tsolomitis wrote:
> 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
{
TYPE client
CONTAINER_NAME
CONTAINER_TYPE BOX
CLIENT_NAME
CLIENT_GEOMETRY
}
--
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] Some plans and some questions
On 05/05/2016 04:50 πμ, Jon Trulson wrote: > On Wed, 4 May 2016, Antonis Tsolomitis wrote: > >> >> 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. -- 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] Some plans and some questions
On Wed, 4 May 2016, Antonis Tsolomitis wrote: > > 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 -- 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] Some plans and some questions
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. On 03/05/2016 04:44 μμ, Richard L. Hamilton wrote: >> 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 -- 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] Some plans and some questions
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. On 29/04/2016 08:11 μμ, Peter Howkins wrote: > 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 > > On Fri, Apr 29, 2016 at 06:00:51AM +0200, Danilo Schöneberg wrote: >> 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 >> <[1]antonis.tsolomi...@gmail.com> wrote: >> >> How about modern font support? >> >> Antonis. >> >> On 28/04/2016 09:09 μμ, Danilo Schöneberg wrote: >> >> 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 >> >> >> -- >> 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 >> >
Re: [cdesktopenv-devel] Some plans and some questions
> 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] Some plans and some questions
> 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 -- 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] Some plans and some questions
On Tue, May 3, 2016 at 6:46 AM, Pascal Stumpf wrote: > 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 -- 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] Some plans and some questions
On Tue, 3 May 2016 06:08:43 +0200, Martin Etteldorf wrote: > On Mon, May 2, 2016 at 7:10 PM, Pascal Stumpf wrote: > > > 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. > 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 > cdesktopenv-devel@lists.sourceforge.net > 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 cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Some plans and some questions
On Mon, May 2, 2016 at 7:10 PM, Pascal Stumpf wrote: > 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 -- 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] Some plans and some questions
On Sun, 1 May 2016 13:15:33 +0200, Martin Etteldorf wrote: > Hi, > > On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg > wrote: > 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: > [...] > > 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. > 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 cdesktopenv-devel@lists.sourceforge.net > 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 cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Some plans and some questions
Hi, On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg wrote: > 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: > [...] 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 -- 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] Some plans and some questions
On 30/04/2016 17:30, Brent Busby wrote: > Edmond Orignac writes: > >> 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. > >> 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. > >> On Thu, Apr 28, 2016 at 08:09:27PM +0200, Danilo Schöneberg wrote: >>> 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. > >> 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. >>> 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 (, > ..."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. > -- 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
Re: [cdesktopenv-devel] Some plans and some questions
On Sat, 30 Apr 2016 12:44:47 +0200 Edmond Orignac wrote: > 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. -- 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] Some plans and some questions
Edmond Orignac writes: > 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. > 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. > On Thu, Apr 28, 2016 at 08:09:27PM +0200, Danilo Schöneberg wrote: >> 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. > 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. >> 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 (, ..."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 -- 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] Some plans and some questions
On 30/04/2016 07:13, Isaac Dunham wrote: > On Thu, Apr 28, 2016 at 08:09:27PM +0200, Danilo Schöneberg wrote: >> 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 > > 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. > >> 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. 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. > > 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".) > >> 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. > 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. > >> 4) code cleanup (warnings) > > This would be the best, I think. > >> 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 > >> 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. > > 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 >
Re: [cdesktopenv-devel] Some plans and some questions
On Thu, Apr 28, 2016 at 08:09:27PM +0200, Danilo Schöneberg wrote: > 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 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. > 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".) > 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. > 4) code cleanup (warnings) This would be the best, I think. > 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 > 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 decide
Re: [cdesktopenv-devel] Some plans and some questions
On 28/04/2016 20:09, Danilo Schöneberg wrote: > 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 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 > 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. > 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 > 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. > > 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 > cdesktopenv-devel@lists.sourceforge.net > 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 cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Some plans and some questions
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 On Fri, Apr 29, 2016 at 06:00:51AM +0200, Danilo Schöneberg wrote: >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 ><[1]antonis.tsolomi...@gmail.com> wrote: > > How about modern font support? > > Antonis. > > On 28/04/2016 09:09 μμ, Danilo Schöneberg wrote: > >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 > > > -- > 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 > [3]cdesktopenv-devel@lists.sourceforge.net > [4]https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > References > >Visible links >1. mailto:antonis.tsolomi...@gmail.com >2. https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >3. mailto:cdesktopenv-devel@lists.sourceforge.net >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 p
Re: [cdesktopenv-devel] Some plans and some questions
On 28 April 2016 at 19:09 Danilo Schöneberg wrote: > > 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 > 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 -- 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] Some plans and some questions
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 wrote: > > How about modern font support? > > Antonis. > > > > On 28/04/2016 09:09 μμ, Danilo Schöneberg wrote: > > 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 > > > -- > 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 > listcdesktopenv-devel@lists.sourceforge.nethttps://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 cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Some plans and some questions
How about modern font support? Antonis. On 28/04/2016 09:09 μμ, Danilo Schöneberg wrote: 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 -- 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 -- 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] Some plans and some questions
Hi, On Thu, Apr 28, 2016 at 8:09 PM, Danilo Schöneberg wrote: > 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 -- 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
[cdesktopenv-devel] Some plans and some questions
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 -- 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
