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

[Chase via cdesktopenv-devel]

Have you emailed that guy back since then? He may've put something together but 
forgot about it.

If imake could get any deader, I was just emailed saying upstream wouldn't even 
merge our changes due to our imake being lgplv2+ licensed, so my vote is 
officially migrating to autotools after this release.


​Thank you for your time,

-Chase​

‐‐‐ Original Message ‐‐‐

On June 21, 2018 2:43 PM, Jon Trulson  wrote:

> ​​
> 
> On 06/20/2018 06:46 PM, Matthew R. Trower wrote:
> 
> > > As for dtudc*, why? Who needs it?
> > > 
> > > If you really want it, there is no reason it could not just be
> > > 
> > > maintained outside of CDE as a separate project -- just requiring a
> > > 
> > > X11/Motif/CDE dev environment to build.
> > > 
> > > Is there some strong reason we need to kill it? I understand why there
> > > 
> > > might not be priority for others to fix it, but if I were willing to
> > > 
> > > repair it, can it stay? I don't know anything about this component
> > > 
> > > personally, but I'd like to see the traditional CDE toolkit and
> > > 
> > > application base stay intact where at all possible.
> 
> Yes. It is pure evil. It cannot be allowed to exist.
> 
> Ok, the reason I killed it is because:
> 
> 1.  I had never heard of it before, it was never in any version CDE I
> 
> ever maintained (starting around 1997 or so).
> 
> 2.  It generates tons of compiler and coverity warnings. It seems to
> 
> actually duplicate some X11 headers (but renames them) for some evil
> 
> reason. Ok, I like to use the term 'evil' when looking at that code,
> 
> because it just sucks.
> 
> 3.  It does not serve any useful purpose that I can discern. I have a
> 
> feeling that this was some development tool, created in a hurry within
> 
> HP, IBM, whatever and it was just slapped in at the last moment without
> 
> any review.
> 
> If someone (you) wants to revive it, then please:
> 
> 4.  grab it from on older commit before it was removed
> 5.  work on it in your own personal repository
> 6.  Once it is in shape - cleaned up, builds, runs, does not spit out
> 
> tons of compiler warnings, etc, then submit a PR/patch re-introducing
> 
> it, and we can review.
> 
> 
> > Separate maintainership is one possiblity, but I have reservations
> > 
> > regarding splitting up the CDE codebase...
> > 
> > > TBH, I'd like to get rid of dtmail as well, unless someone wants to
> > > 
> > > drag it into the 21st century.
> > 
> > Okay, definitely I want dtmail to stay. Yes, it needs some help.
> > 
> > Completing the IMAP support would go a long ways. It's on my list of
> > 
> > items to attend to; I can try to bump it up in priority.
> 
> Well, my point is that dtmail isn't really safe to use on the Internet.
> 
> I'm only half-way joking when I say I want to kill it. But dtmail has
> 
> been around since the beginning of CDE, so I won't kill it - I will
> 
> advise not using though in it's current state.
> 
> I had briefly talked to one of the original developers of it (he emailed
> 
> me out of the blue one day), and he told me he had introduced a lot of
> 
> things like SSL support and the like that for some reason never made it
> 
> into the TOG code base.
> 
> He is retired now, and mentioned he might take up trying to fix it up
> 
> again, but that was 2-3 years ago and I haven't heard a peep from him
> 
> since. I don't blame him really :)
> 
> > > Besides, there are far better font editors out there, if that's your 
> > > thing.
> > 
> > Some people would undoubtedly argue that there are far better (more
> > 
> > capable, modern, etc) desktop environemnts out there. Obviously, some
> > 
> > of us still care about this one, undoubtedly for a variety of reasons.
> > 
> > So I guess this is a reasonable time to ask, what is your vision for the
> > 
> > CDE project? Do you want to maintain this legacy product as-is, keeping
> > 
> > it alive? Do you want to modernize it somehow? Do you want it mainly
> > 
> > to serve the purposes of the developer base here, and people who don't
> > 
> > want to let go of their old familiar environment? Do you want to stage
> > 
> > a coup and overthrow Gnome/KDE/Unity? =)
> > 
> > I know those are broad questions, I'm just wondering what you're
> > 
> > thinking in general; if there's a master plan, or what. This type of
> > 
> > question is important, I think, when considering things like platform
> > 
> > support, and which programs we want to maintain.
> 
> In short, I want CDE to go down in history as the desktop environment
> 
> that exposed the Universe to the spectacle of its own destruction!!
> 
> BWAHAHHAHAHAHAH!
> 
> Ok, with some seriousness - I want it to be reliable and useful. I want
> 
> it to work on modern systems, and using modern methods, libraries and
> 
> the like, while preserving that which makes CDE, well, CDE.
> 
> This includes UTF8 support, a more modern build system, a

Re: [cdesktopenv-devel] Proposing an official release in two weeks

[Chase via cdesktopenv-devel]

My vote is for a new release, however I have my reservations on waiting another 
1-2 years for the next release. I would like to get the debian package out as 
soon as reasonably possible, so could we switch to a release schedule of 
roughly 6 months from now on? That way people don't think we are a dead project.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On June 22, 2018 8:02 PM, Henry Bonath  wrote:

> Yes from me as well.
> Great work everyone!
>
> On Fri, Jun 22, 2018 at 9:00 PM, Christopher Turkel 
>  wrote:
>
>> I vote yes.
>>
>> On Fri, Jun 22, 2018 at 8:56 PM Matthew R. Trower  
>> wrote:
>>
>>> Affirmative.
>>>
>>> -mrt
>>>   Original Message
>>> From: Jon Trulson
>>> Sent: Friday, June 22, 2018 17:55
>>> To: cdesktopenv-devel@lists.sourceforge.net
>>> Subject: [cdesktopenv-devel] Proposing an official release in two weeks
>>>
>>> As the title says, I'd like to propose a "stable" release of CDE in two
>>> weeks.
>>>
>>> cde-next will be merged into master after release.
>>>
>>> Objections? Affirmations?
>>>
>>> --
>>> Jon Trulson
>>>
>>> "Fire all weapons and open a hailing frequency for my victory yodle."
>>>
>>> - Zapp Brannigan
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> cdesktopenv-devel mailing list
>>> cdesktopenv-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> cdesktopenv-devel mailing list
>>> cdesktopenv-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] Proposing an official release in two weeks

[Matthew R. Trower]

  I ‎would think we should cut new releases when we are ready to do so, rather than after an arbitrary amount of time. Some projects (ex. Debian, Firefox, much commercial software) that have very frequent commits benefit from a set release schedule.  CDE has considerably‎ less churn to it, so we should release when we have accumulated a certain degree of substance --- whenever that may be.Of course, I think we accumulated that substance long ago.We could perhaps consider more frequent dev releases between‎ stable releases? That would help show activity if necessary, without potentially reducing stable releases to vaporware.By the way, I don't know the packaging requirements for Debian... are you required to package a "stable" release?-mrtFrom: Chase via cdesktopenv-develSent: Saturday, June 23, 2018 16:48To: Henry BonathReply To: ChaseCc: CDE developmentSubject: Re: [cdesktopenv-devel] Proposing an official release in two weeksMy vote is for a new release, however I have my reservations on waiting another 1-2 years for the next release. I would like to get the debian package out as soon as reasonably possible, so could we switch to a release schedule of roughly 6 months from now on? That way people don't think we are a dead project.Thank you for your time,-Chase‐‐‐ Original Message ‐‐‐ On June 22, 2018 8:02 PM, Henry Bonath  wrote: Yes from me as well.Great work everyone!On Fri, Jun 22, 2018 at 9:00 PM, Christopher Turkel  wrote:I vote yes.On Fri, Jun 22, 2018 at 8:56 PM Matthew R. Trower  wrote:Affirmative.  -mrt   Original Message   From: Jon Trulson Sent: Friday, June 22, 2018 17:55 To: cdesktopenv-devel@lists.sourceforge.net Subject: [cdesktopenv-devel] Proposing an official release in two weeks  As the title says, I'd like to propose a "stable" release of CDE in two  weeks.  cde-next will be merged into master after release.  Objections? Affirmations?   --  Jon Trulson  "Fire all weapons and open a hailing frequency for my victory yodle."  - Zapp Brannigan  -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel  -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel 

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

Re: [cdesktopenv-devel] Proposing an official release in two weeks

[Chase via cdesktopenv-devel]

Not initially, from the debian wikipedia page:

Initially, an accepted package is only available in the unstable 
branch.[111](https://en.wikipedia.org/wiki/Debian#cite_note-distributions-111) 
For a package to become a candidate for the next release, it must migrate to 
the Testing branch by meeting the 
following:[223](https://en.wikipedia.org/wiki/Debian#cite_note-223)

- It has been in unstable for a certain length of time that depends on the 
urgency of the changes.
- It does not have "release-critical" bugs, except for the ones already present 
in Testing. Release-critical bugs are those considered serious enough that they 
make the package unsuitable for release.
- There are no outdated versions in unstable for any release ports.
- The migration does not break any packages in Testing.
- Its dependencies can be satisfied by packages already in Testing or by 
packages being migrated at the same time.
- The migration is not blocked by a freeze.

Once in testing, the debian devs will then determine when they want to release 
and then freeze testing and put it into the release.

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On June 23, 2018 5:57 PM, Matthew R. Trower  wrote:

> I ‎would think we should cut new releases when we are ready to do so, rather 
> than after an arbitrary amount of time. Some projects (ex. Debian, Firefox, 
> much commercial software) that have very frequent commits benefit from a set 
> release schedule.  CDE has considerably‎ less churn to it, so we should 
> release when we have accumulated a certain degree of substance --- whenever 
> that may be.
>
> Of course, I think we accumulated that substance long ago.
>
> We could perhaps consider more frequent dev releases between‎ stable 
> releases? That would help show activity if necessary, without potentially 
> reducing stable releases to vaporware.
>
> By the way, I don't know the packaging requirements for Debian... are you 
> required to package a "stable" release?
>
> -mrt
> From: Chase via cdesktopenv-devel
> Sent: Saturday, June 23, 2018 16:48
> To: Henry Bonath
> Reply To: Chase
> Cc: CDE development
> Subject: Re: [cdesktopenv-devel] Proposing an official release in two weeks
>
> My vote is for a new release, however I have my reservations on waiting 
> another 1-2 years for the next release. I would like to get the debian 
> package out as soon as reasonably possible, so could we switch to a release 
> schedule of roughly 6 months from now on? That way people don't think we are 
> a dead project.
>
> Thank you for your time,
> -Chase
>
> ‐‐‐ Original Message ‐‐‐
> On June 22, 2018 8:02 PM, Henry Bonath  wrote:
>
>> Yes from me as well.
>> Great work everyone!
>>
>> On Fri, Jun 22, 2018 at 9:00 PM, Christopher Turkel 
>>  wrote:
>>
>>> I vote yes.
>>>
>>> On Fri, Jun 22, 2018 at 8:56 PM Matthew R. Trower  
>>> wrote:
>>>
 Affirmative.

 -mrt
   Original Message
 From: Jon Trulson
 Sent: Friday, June 22, 2018 17:55
 To: cdesktopenv-devel@lists.sourceforge.net
 Subject: [cdesktopenv-devel] Proposing an official release in two weeks

 As the title says, I'd like to propose a "stable" release of CDE in two
 weeks.

 cde-next will be merged into master after release.

 Objections? Affirmations?

 --
 Jon Trulson

 "Fire all weapons and open a hailing frequency for my victory yodle."

 - Zapp Brannigan

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

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

Re: [cdesktopenv-devel] Proposing an official release in two weeks

[Matthew R. Trower]

  Ah, yes, I am quite familiar with Debian's packaging and release policies from a user's perspective.  ‎ I meant, do you need to package a stable release of the software in question? Example: Our stable release is 2.2.4; must you package that, or can you package 2.2.4a (or even master)?I don't think there are restrictions like that, but I wasn't sure.‎ The Debian folks have some interesting ideas about things sometimes.  =)I'm just trying to understand in what way the release schedule might impact your efforts at packaging for Debian, if any.-mrtFrom: ChaseSent: Saturday, June 23, 2018 18:47To: Matthew R. TrowerReply To: ChaseCc: Chase via cdesktopenv-develSubject: Re: [cdesktopenv-devel] Proposing an official release in two weeksNot initially, from the debian wikipedia page:Initially, an accepted package is only available in the unstable branch.[111] For a package to become a candidate for the next release, it must migrate to the Testing branch by meeting the following:[223]It has been in unstable for a certain length of time that depends on the urgency of the changes.It does not have "release-critical" bugs, except for the ones already present in Testing. Release-critical bugs are those considered serious enough that they make the package unsuitable for release.There are no outdated versions in unstable for any release ports.The migration does not break any packages in Testing.Its dependencies can be satisfied by packages already in Testing or by packages being migrated at the same time.The migration is not blocked by a freeze.Once in testing, the debian devs will then determine when they want to release and then freeze testing and put it into the release.Thank you for your time,-Chase‐‐‐ Original Message ‐‐‐ On June 23, 2018 5:57 PM, Matthew R. Trower  wrote: I ‎would think we should cut new releases when we are ready to do so, rather than after an arbitrary amount of time. Some projects (ex. Debian, Firefox, much commercial software) that have very frequent commits benefit from a set release schedule.  CDE has considerably‎ less churn to it, so we should release when we have accumulated a certain degree of substance --- whenever that may be.Of course, I think we accumulated that substance long ago.We could perhaps consider more frequent dev releases between‎ stable releases? That would help show activity if necessary, without potentially reducing stable releases to vaporware.By the way, I don't know the packaging requirements for Debian... are you required to package a "stable" release?-mrtFrom: Chase via cdesktopenv-develSent: Saturday, June 23, 2018 16:48To: Henry BonathReply To: ChaseCc: CDE developmentSubject: Re: [cdesktopenv-devel] Proposing an official release in two weeksMy vote is for a new release, however I have my reservations on waiting another 1-2 years for the next release. I would like to get the debian package out as soon as reasonably possible, so could we switch to a release schedule of roughly 6 months from now on? That way people don't think we are a dead project.Thank you for your time,-Chase‐‐‐ Original Message ‐‐‐On June 22, 2018 8:02 PM, Henry Bonath  wrote:Yes from me as well.Great work everyone!On Fri, Jun 22, 2018 at 9:00 PM, Christopher Turkel  wrote:I vote yes.On Fri, Jun 22, 2018 at 8:56 PM Matthew R. Trower  wrote:Affirmative.-mrt  Original Message  From: Jon TrulsonSent: Friday, June 22, 2018 17:55To: cdesktopenv-devel@lists.sourceforge.netSubject: [cdesktopenv-devel] Proposing an official release in two weeksAs the title says, I'd like to propose a "stable" release of CDE in two weeks.cde-next will be merged into master after release.Objections? Affirmations?-- Jon Trulson"Fire all weapons and open a hailing frequency for my victory yodle."- Zapp Brannigan--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___cdesktopenv-devel mailing listcdesktopenv-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.

Re: [cdesktopenv-devel] Proposing an official release in two weeks

[Jon Trulson]

On 06/23/2018 03:47 PM, Chase via cdesktopenv-devel wrote:
My vote is for a new release, however I have my reservations on waiting 
another 1-2 years for the next release. I would like to get the debian 
package out as soon as reasonably possible, so could we switch to a 
release schedule of roughly 6 months from now on? That way people don't 
think we are a dead project.


Well no, we can really commit to a release schedule.  There is no one 
that works on this full time.  We get contributions whenever people have 
the time and inclination to submit them.  We may go many months without 
a single patch, and have.


What we can do, is do more development releases (as long as there are 
actual changes to release)...


-jon




Thank you for your time,
-Chase


‐‐‐ Original Message ‐‐‐
On June 22, 2018 8:02 PM, Henry Bonath  wrote:


Yes from me as well.
Great work everyone!

On Fri, Jun 22, 2018 at 9:00 PM, Christopher Turkel 
mailto:turkel.christop...@gmail.com>> 
wrote:


I vote yes.

On Fri, Jun 22, 2018 at 8:56 PM Matthew R. Trower
mailto:d...@blackshard.net>> wrote:

Affirmative.

-mrt
  Original Message
From: Jon Trulson
Sent: Friday, June 22, 2018 17:55
To: cdesktopenv-devel@lists.sourceforge.net

Subject: [cdesktopenv-devel] Proposing an official release in
two weeks

As the title says, I'd like to propose a "stable" release of
CDE in two
weeks.

cde-next will be merged into master after release.

Objections? Affirmations?


-- 
Jon Trulson


"Fire all weapons and open a hailing frequency for my victory
yodle."

- Zapp Brannigan


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

https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel



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

https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel




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

https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



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



--
Jon Trulson

"Fire all weapons and open a hailing frequency for my victory yodle."

  - Zapp Brannigan

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

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

[Jon Trulson]

On 06/23/2018 03:45 PM, Chase wrote:

Have you emailed that guy back since then? He may've put something together but 
forgot about it.



I couldn't remember his name, but I believe he responded in this very 
thread (Doug Royer?).



If imake could get any deader, I was just emailed saying upstream wouldn't even 
merge our changes due to our imake being lgplv2+ licensed, so my vote is 
officially migrating to autotools after this release.



Yeah, that's one issue with GPL vs. MIT/X11 :)  But that's ok.  We might 
consider their imake binary and bootstrap which is probably way newer 
than ours, or just forget about it.  Keep ours usable, but move toward 
autotools.


-jon



​Thank you for your time,

-Chase​

‐‐‐ Original Message ‐‐‐

On June 21, 2018 2:43 PM, Jon Trulson  wrote:


​​

On 06/20/2018 06:46 PM, Matthew R. Trower wrote:


As for dtudc*, why? Who needs it?

If you really want it, there is no reason it could not just be

maintained outside of CDE as a separate project -- just requiring a

X11/Motif/CDE dev environment to build.

Is there some strong reason we need to kill it? I understand why there

might not be priority for others to fix it, but if I were willing to

repair it, can it stay? I don't know anything about this component

personally, but I'd like to see the traditional CDE toolkit and

application base stay intact where at all possible.


Yes. It is pure evil. It cannot be allowed to exist.

Ok, the reason I killed it is because:

1.  I had never heard of it before, it was never in any version CDE I
 
 ever maintained (starting around 1997 or so).
 
2.  It generates tons of compiler and coverity warnings. It seems to
 
 actually duplicate some X11 headers (but renames them) for some evil
 
 reason. Ok, I like to use the term 'evil' when looking at that code,
 
 because it just sucks.
 
3.  It does not serve any useful purpose that I can discern. I have a
 
 feeling that this was some development tool, created in a hurry within
 
 HP, IBM, whatever and it was just slapped in at the last moment without
 
 any review.
 
 If someone (you) wants to revive it, then please:
 
4.  grab it from on older commit before it was removed

5.  work on it in your own personal repository
6.  Once it is in shape - cleaned up, builds, runs, does not spit out
 
 tons of compiler warnings, etc, then submit a PR/patch re-introducing
 
 it, and we can review.
 


Separate maintainership is one possiblity, but I have reservations

regarding splitting up the CDE codebase...


TBH, I'd like to get rid of dtmail as well, unless someone wants to

drag it into the 21st century.


Okay, definitely I want dtmail to stay. Yes, it needs some help.

Completing the IMAP support would go a long ways. It's on my list of

items to attend to; I can try to bump it up in priority.


Well, my point is that dtmail isn't really safe to use on the Internet.

I'm only half-way joking when I say I want to kill it. But dtmail has

been around since the beginning of CDE, so I won't kill it - I will

advise not using though in it's current state.

I had briefly talked to one of the original developers of it (he emailed

me out of the blue one day), and he told me he had introduced a lot of

things like SSL support and the like that for some reason never made it

into the TOG code base.

He is retired now, and mentioned he might take up trying to fix it up

again, but that was 2-3 years ago and I haven't heard a peep from him

since. I don't blame him really :)


Besides, there are far better font editors out there, if that's your thing.


Some people would undoubtedly argue that there are far better (more

capable, modern, etc) desktop environemnts out there. Obviously, some

of us still care about this one, undoubtedly for a variety of reasons.

So I guess this is a reasonable time to ask, what is your vision for the

CDE project? Do you want to maintain this legacy product as-is, keeping

it alive? Do you want to modernize it somehow? Do you want it mainly

to serve the purposes of the developer base here, and people who don't

want to let go of their old familiar environment? Do you want to stage

a coup and overthrow Gnome/KDE/Unity? =)

I know those are broad questions, I'm just wondering what you're

thinking in general; if there's a master plan, or what. This type of

question is important, I think, when considering things like platform

support, and which programs we want to maintain.


In short, I want CDE to go down in history as the desktop environment

that exposed the Universe to the spectacle of its own destruction!!

BWAHAHHAHAHAHAH!

Ok, with some seriousness - I want it to be reliable and useful. I want

it to work on modern systems, and using modern methods, libraries and

the like, while preserving that which makes CDE, well, CDE.

This includes UTF8 support, a more modern build system, and conforming

to mo

[cdesktopenv-devel] [PATCH] Remove ultrix support

[Chase via cdesktopenv-devel]

Third times the charm!

Posting some last minute patches before the release comes.

Thank you for your time,
-ChaseFrom 9733966cadd694507131c864baa7c19afd4d6f4e Mon Sep 17 00:00:00 2001
From: chase 
Date: Sat, 23 Jun 2018 21:48:44 -0500
Subject: [PATCH] Remove ultrix support

---
 cde/config/cf/Imake.cf|  17 +--
 cde/config/cf/Imakefile   |   1 -
 cde/config/cf/ultrix.cf   |  77 --
 cde/config/imake/imakemdep.h  |   5 +-
 cde/doc/util/dbtoman/instant/general.h|   5 -
 cde/lib/DtHelp/Helpos.c   |  35 +
 cde/lib/DtSvc/DtUtil2/DtosP.h |   4 +-
 cde/lib/DtTerm/TermPrim/TermPrimMessageCatI.h |   4 -
 cde/lib/tt/bin/dbck/prop.C|   5 +-
 cde/lib/tt/bin/dbck/spec.C|   3 -
 cde/lib/tt/bin/dbck/spec_repair.C |   3 -
 cde/lib/tt/bin/shell/mover.C  |   4 -
 cde/lib/tt/bin/shell/remover.C|   4 -
 cde/lib/tt/bin/tt_type_comp/mp_type_comp.C|   4 -
 cde/lib/tt/bin/ttdbserverd/dm_server.C|  20 +--
 cde/lib/tt/bin/tttar/tttar_file_utils.C   |   4 -
 cde/lib/tt/lib/api/c/api_xdr.h|   5 -
 cde/lib/tt/lib/mp/mp_desktop.h|  11 --
 cde/lib/tt/lib/mp/mp_rpc.h|   2 +-
 cde/lib/tt/lib/mp/mp_rpc_client.C |  11 --
 cde/lib/tt/lib/mp/mp_session.C|   2 +-
 cde/lib/tt/lib/mp/mp_stream_socket.C  |   4 -
 cde/lib/tt/lib/realpath.ultrix.c  | 144 --
 cde/lib/tt/lib/tt_options.h   |  11 --
 cde/lib/tt/lib/util/tt_int_rec.C  |   3 -
 cde/lib/tt/lib/util/tt_int_rec.h  |   3 -
 cde/lib/tt/lib/util/tt_new.h  |   4 -
 cde/lib/tt/lib/util/tt_new_ptr.h  |   4 -
 cde/lib/tt/lib/util/tt_object.h   |   3 -
 cde/lib/tt/lib/util/tt_object_list.h  |   4 -
 cde/lib/tt/lib/util/tt_string.C   |   3 -
 cde/lib/tt/lib/util/tt_string.h   |   3 -
 cde/lib/tt/lib/util/tt_xdr_utils.C|  13 +-
 cde/lib/tt/mini_isam/isalloc.c|   7 -
 cde/lib/tt/mini_isam/iserror.c|   3 -
 cde/lib/tt/mini_isam/strdup.ultrix.c  |  41 -
 cde/lib/tt/slib/mp_s_procid.C |   2 +-
 cde/lib/tt/slib/mp_s_session.C|  19 +--
 cde/lib/tt/slib/mp_typedb.C   |   5 -
 cde/lib/tt/slib/mp_typedb.h   |   3 -
 cde/programs/dtaction/Main.c  |   6 +-
 cde/programs/dtcalc/calctool.h|   6 +-
 cde/programs/dtdocbook/instant/general.h  |   5 -
 cde/programs/dtfile/FileManip.c   |  19 +--
 cde/programs/dtfile/FileMgr.c |   2 +-
 cde/programs/dtfile/Find.c|   4 +-
 cde/programs/dtfile/Main.h|   6 +-
 cde/programs/dtfile/dtcopy/dtcopy.h   |   6 +-
 cde/programs/dthelp/dthelpgen/helpgen.c   |   4 -
 cde/programs/dthelp/dthelpprint/PrintUtil.c   |   4 -
 cde/programs/dticon/main.h|   6 +-
 .../clients/dtinfo_start/dtinfo_start.h   |   6 +-
 .../dtksh/ksh93/src/cmd/ksh93/sh/init.c   |   4 -
 cde/programs/dtksh/msgs.h |   6 +-
 cde/programs/dtlogin/genauth.c|  20 +--
 cde/programs/dtpad/main.c |   6 +-
 cde/programs/dtsession/Sm.h   |   6 +-
 cde/programs/dtsession/Srv.h  |   6 +-
 cde/programs/dtudcexch/excutil.h  |   6 +-
 .../dtudcfonted/libfal/_falSetLocale.c|   8 +-
 cde/programs/dtudcfonted/libfal/_fallcint.h   |  12 --
 cde/programs/dtudcfonted/ufont.c  |   4 -
 cde/programs/dtwm/DataBaseLoad.h  |   6 +-
 cde/programs/dtwm/README  |   2 +-
 cde/programs/dtwm/WmGlobal.h  |   6 +-
 65 files changed, 36 insertions(+), 635 deletions(-)
 delete mode 100644 cde/config/cf/ultrix.cf
 delete mode 100644 cde/lib/tt/lib/realpath.ultrix.c
 delete mode 100644 cde/lib/tt/mini_isam/strdup.ultrix.c

diff --git a/cde/config/cf/Imake.cf b/cde/config/cf/Imake.cf
index f3a9226c..545b32dc 100644
--- a/cde/config/cf/Imake.cf
+++ b/cde/config/cf/Imake.cf
@@ -18,22 +18,7 @@ XCOMM $TOG: Imake.cf /main/30 1998/04/28 13:55:25 barstow $
  * 4.  Create a .cf file with the name given by MacroFile.
  */
 
-#ifdef ultrix
-# define MacroIncludeFile 
-# define MacroFile ultrix.cf
-# ifdef vax
-#  undef vax
-#  define VaxArchitecture
-# endif
-# ifdef mips
-#  undef mips
-#  define MipsArchitecture
-# endif
-# undef ultrix
-# define UltrixArchitecture
-#endif /* ultrix */
-
-#if defined(vax) && !defined(UltrixArchitecture)
+#if defined(vax)
 # define MacroIncludeFile 
 # define MacroFile bsd.cf
 # undef vax
diff --git a/cde/config/cf/Imakefile b/cde/config/cf/Imakefile
index d2650ab4..2db7451a 100644
--- a/cde/config/cf/Imakefile
+++ b/cde/config/cf/Imakefile

[cdesktopenv-devel] You guys are driving me nuts with ideas

[Pete Lancashire]

I'm sitting here with one of my beaglebone black boards a little high
performance single-board computer this current design uses a 9 in LCD panel.

It would make a perfect little CDE system
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Re: [cdesktopenv-devel] You guys are driving me nuts with ideas

[Chase via cdesktopenv-devel]

Sounds like a fun pet project, glad to see people being creative with CDE

Thank you for your time,
-Chase

‐‐‐ Original Message ‐‐‐
On June 23, 2018 9:58 PM, Pete Lancashire  wrote:

> I'm sitting here with one of my beaglebone black boards a little high 
> performance single-board computer this current design uses a 9 in LCD panel.
>
> It would make a perfect little CDE system--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel