Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #80666 > unrolled thread

Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september)

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) olcott <NoOne@NoWhere.com> - 2021-07-05 08:31 -0500
    Re: comp.lang.c blocked on Google Groups James Harris <james.harris.1@gmail.com> - 2021-07-05 16:26 +0100
      Re: comp.lang.c blocked on Google Groups Sam <sam@email-scan.com> - 2021-07-05 12:52 -0400
      Re: comp.lang.c blocked on Google Groups "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-05 12:55 -0700
    Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-07-05 18:39 +0200
      Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) olcott <NoOne@NoWhere.com> - 2021-07-05 11:50 -0500
      Re: comp.lang.c blocked on Google Groups https://www.usenetarchives.com/ olcott <NoOne@NoWhere.com> - 2021-07-05 11:56 -0500
      Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-05 14:13 -0700
        Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-05 15:32 -0700
          Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-05 15:34 -0700
        Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) David Brown <david.brown@hesbynett.no> - 2021-07-06 08:22 +0200
          Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-06 15:11 -0400
            Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) Real Troll <real.troll@trolls.com> - 2021-07-06 19:56 +0000
              Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) gazelle@shell.xmission.com (Kenny McCormack) - 2021-07-13 04:37 +0000
                Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) Real Troll <real.troll@trolls.com> - 2021-07-13 16:45 +0000
                  Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) scott@slp53.sl.home (Scott Lurndal) - 2021-07-13 17:44 +0000
                  Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird MrSpud_0wmge0me@1luxp5mj4a5obrr0ws.net - 2021-07-14 07:17 +0000
                    Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird scott@slp53.sl.home (Scott Lurndal) - 2021-07-14 15:07 +0000
                      Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird MrSpud_6q@rm5.biz - 2021-07-14 16:03 +0000
                        Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) gazelle@shell.xmission.com (Kenny McCormack) - 2021-07-14 19:08 +0000
                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) Manfred <noname@add.invalid> - 2021-07-14 21:11 +0200
                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-14 20:02 +0000
                            Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_0zkkxn6jj@uncf5cotva75ujdt.gov - 2021-07-15 08:27 +0000
                              Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups scott@slp53.sl.home (Scott Lurndal) - 2021-07-15 14:20 +0000
                                Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_6wa4@1h0c.net - 2021-07-15 14:34 +0000
                              Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-15 14:59 +0000
                                Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_8nnwe@ko9uz7rn4n552n6rutmfe.eu - 2021-07-16 09:33 +0000
                                  Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-16 15:33 +0000
                                    Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_Ccq3_3_r@atc_rakxp6.info - 2021-07-17 15:04 +0000
                                      Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-17 16:30 +0000
                                        Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_2fxg@cligh74ct.info - 2021-07-19 07:50 +0000
                                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-19 00:53 -0700
                                            Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_X19y3su@nl5uzoqa76.info - 2021-07-19 08:16 +0000
                                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-07-19 15:20 +0000
                                            Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups MrSpud_K_o53g2z@wl4yrs_t67fb214q.gov - 2021-07-19 15:31 +0000
                                      Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Manfred <invalid@add.invalid> - 2021-07-18 00:29 +0200
                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-14 20:11 +0000
                            Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) gazelle@shell.xmission.com (Kenny McCormack) - 2021-07-14 21:03 +0000
                              Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) Christian Gollwitzer <auriocus@gmx.de> - 2021-07-16 12:55 +0200
                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) Eli the Bearded <*@eli.users.panix.com> - 2021-07-14 20:32 +0000
                          Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird) MrSpud_Cyt@em8kceu_4l_721dw4ed0wc.biz - 2021-07-15 08:24 +0000
                    Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-07-16 19:59 +0300
                    Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird steve <steve@loft.i-did-not-set--mail-host-address--so-tickle-me> - 2021-07-17 22:11 -0400
    Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) Real Troll <real.troll@trolls.com> - 2021-07-05 17:00 +0000
      Re: comp.lang.c blocked on Google Groups Switch to free (Thunderbird and eternal-september) olcott <NoOne@NoWhere.com> - 2021-07-05 12:15 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#80706 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

On 7/14/2021 9:08 PM, Kenny McCormack wrote:
> In article <scn1sn$1bjk$1@gioia.aioe.org>,  <MrSpud_6q@rm5.biz> wrote:
>> On Wed, 14 Jul 2021 15:07:16 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>> MrSpud_0wmge0me@1luxp5mj4a5obrr0ws.net writes:
>>>> On Tue, 13 Jul 2021 16:45:00 +0000
>>>
>>>> Given how many apparent geniuses subscribe to comp.lang.c++ I'm amazed none
>>>> of them have written their own newsreader. NNTP is quite a simple protocol
>>>> after all. I did and I'm using it now. Ok, its command line, not GUI but it
>>>> does the job and I can make it do whatever I want.
>>>>
>>>
>>> What makes you think we haven't?
>>
>> Maybe some people have, but I get the impression most haven't.
>>
> 
> There's no need to.  Really, talk about wheel re-invention.  Hey, here's an
> idea, why not write a new OS?  Who needs Linux?  Who need z/OS?  (etc)
> 
> trn (and similar, such as "tin") does everything you need, so why not use
> it?  You'd spend a lot of time, just to get up to the level of
> functionality of trn.  Why go through the hassle?
> 

Don't forget how cool is the wheel :)

[toc] | [prev] | [next] | [standalone]

#80707 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

On Wed, 14 Jul 2021 19:08:22 +0000, Kenny McCormack wrote:

> In article <scn1sn$1bjk$1@gioia.aioe.org>,  <MrSpud_6q@rm5.biz> wrote:
>>On Wed, 14 Jul 2021 15:07:16 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>MrSpud_0wmge0me@1luxp5mj4a5obrr0ws.net writes:
>>>>On Tue, 13 Jul 2021 16:45:00 +0000
>>>
>>>>Given how many apparent geniuses subscribe to comp.lang.c++ I'm amazed none
>>>>of them have written their own newsreader. NNTP is quite a simple protocol
>>>>after all. I did and I'm using it now. Ok, its command line, not GUI but it
>>>>does the job and I can make it do whatever I want.
>>>>
>>>
>>>What makes you think we haven't?
>>
>>Maybe some people have, but I get the impression most haven't.
>>
> 
> There's no need to.  Really, talk about wheel re-invention.  Hey, here's an
> idea, why not write a new OS?  Who needs Linux?  Who need z/OS?  (etc)
> 
> trn (and similar, such as "tin") does everything you need, so why not use
> it?  You'd spend a lot of time, just to get up to the level of
> functionality of trn.  Why go through the hassle?

I can think of many possible reasons to (re)create an existing tool:
- the existing tools do not provide the functionality you require, or
- the existing tools do not provide the usability you require, or
- you wish to incorporate the tool's functionality into another tool, or
- the tool is unavailable on your platform, or
- you wish to learn how to write the tool, or
- you wish to attempt to improve the existing tools

FWIW, I'm attempting to write an X11 Display Manager using low-level Xlib calls,
not because there are no X11 Display Managers available, but because I wish to
learn about X11, and I would like a Display Manager that works the way /I/ want
it to work.

What's /your/ excuse, Kenny?
-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#80714 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Wed, 14 Jul 2021 20:02:08 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>FWIW, I'm attempting to write an X11 Display Manager using low-level Xlib
>calls,
>not because there are no X11 Display Managers available, but because I wish to
>learn about X11, and I would like a Display Manager that works the way /I/ want
>
>it to work.

Good luck with that (genuinely, I'm not being sarcastic). I wrote one about
20 years ago and it was a fun project to do but the problem was that even
the venerable O'Reilly XLib manuals didn't provide all the information
required as they're more geared towards developing user applications. In the
end I had to look through other code to see how stuff was done but even then
some things I never got working properly.

[toc] | [prev] | [next] | [standalone]

#80715 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

MrSpud_0zkkxn6jj@uncf5cotva75ujdt.gov writes:
>On Wed, 14 Jul 2021 20:02:08 -0000 (UTC)
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>FWIW, I'm attempting to write an X11 Display Manager using low-level Xlib
>>calls,
>>not because there are no X11 Display Managers available, but because I wish to
>>learn about X11, and I would like a Display Manager that works the way /I/ want
>>
>>it to work.
>
>Good luck with that (genuinely, I'm not being sarcastic). I wrote one about
>20 years ago and it was a fun project to do but the problem was that even
>the venerable O'Reilly XLib manuals didn't provide all the information
>required as they're more geared towards developing user applications. In the
>end I had to look through other code to see how stuff was done but even then
>some things I never got working properly.
>

Hm.. All the X11Rx code is open source; it's easy enough to use the
source of libX11, libXt, and libXaw as a reference.

[toc] | [prev] | [next] | [standalone]

#80716 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Thu, 15 Jul 2021 14:20:58 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>MrSpud_0zkkxn6jj@uncf5cotva75ujdt.gov writes:
>>On Wed, 14 Jul 2021 20:02:08 -0000 (UTC)
>>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>FWIW, I'm attempting to write an X11 Display Manager using low-level Xlib
>>>calls,
>>>not because there are no X11 Display Managers available, but because I wish
>to
>>>learn about X11, and I would like a Display Manager that works the way /I/
>want
>>>
>>>it to work.
>>
>>Good luck with that (genuinely, I'm not being sarcastic). I wrote one about
>>20 years ago and it was a fun project to do but the problem was that even
>>the venerable O'Reilly XLib manuals didn't provide all the information
>>required as they're more geared towards developing user applications. In the
>>end I had to look through other code to see how stuff was done but even then
>>some things I never got working properly.
>>
>
>Hm.. All the X11Rx code is open source; it's easy enough to use the
>source of libX11, libXt, and libXaw as a reference.

The source of another window manager would be a lot more useful IMO as
looking at the source of the above won't show you how to use the required
APIs without doing some reverse engineering nor will it show you what to
use when.

[toc] | [prev] | [next] | [standalone]

#80717 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Thu, 15 Jul 2021 08:27:41 +0000, MrSpud_0zkkxn6jj wrote:

> On Wed, 14 Jul 2021 20:02:08 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>FWIW, I'm attempting to write an X11 Display Manager using low-level Xlib
>>calls,
>>not because there are no X11 Display Managers available, but because I wish to
>>learn about X11, and I would like a Display Manager that works the way /I/ want
>>
>>it to work.
> 
> Good luck with that (genuinely, I'm not being sarcastic). I wrote one about
> 20 years ago and it was a fun project to do but the problem was that even
> the venerable O'Reilly XLib manuals didn't provide all the information
> required as they're more geared towards developing user applications. In the
> end I had to look through other code to see how stuff was done but even then
> some things I never got working properly.

Thanks for the best wishes.

Yah, I'm about 50 pages into the Xlib manual, and have completed (and played with)
the basicwin example. And then, I left the manual alone, except for the reference
information.

I quickly found that Xlib alone wasn't conducive to effective programming; I need
a widget set or toolkit. But, I haven't abandoned Xlib; I'm simply putting together,
from scratch, the sort of widgets I need to make things work.

I have a rudimentary edit widget, and a toggleswitch widget, and a way of abstracting
the event loop into widget/window event handlers, all cobbled together over the last
couple of weeks. I intend to build enough of a framework to familiarize myself with
the practice and pitfalls of Xlib, before I move on to other toolkits. The project
isn't really about building a DM; it's about learning Xlib. If I get a usable DM
from it, then "bonus", otherwise I will still have learned something.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#80718 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Thu, 15 Jul 2021 14:59:08 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>I quickly found that Xlib alone wasn't conducive to effective programming; I
>need
>a widget set or toolkit. But, I haven't abandoned Xlib; I'm simply putting
>together,
>from scratch, the sort of widgets I need to make things work.

It depends how much you want your WM to do. I did it in pure Xlib and 
implemented button and menu widgets (thats all thats really needed) from scratch
which frankly isn't too hard. But sure, if you want a WM thats actually useful
you'll need a proper toolkit.

[toc] | [prev] | [next] | [standalone]

#80720 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Fri, 16 Jul 2021 09:33:11 +0000, MrSpud_8nnwe wrote:

> On Thu, 15 Jul 2021 14:59:08 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>I quickly found that Xlib alone wasn't conducive to effective programming; I
>>need
>>a widget set or toolkit. But, I haven't abandoned Xlib; I'm simply putting
>>together,
>>from scratch, the sort of widgets I need to make things work.
> 
> It depends how much you want your WM to do.

Sorry, but I must make a correction here: I have no interest (at this time)
in writing a Window Manager (WM) client for X11. The O'Reilly X11 Xlib book
discusses WMs in detail, and includes the code for a rudementary WM implemented
in Xlib.

My interest lies elsewhere: specifically, in writing a Display Manager (DM)
client for X11 in Xlib. A DM  provides "a graphical login manager which starts
a login session on an X server from the same or another computer." For this,
I can find no basic example, nor any reasonably complete and simple "howto",
so it gives me a reasonable challenge to learn X11 Xlib programming with.

> I did it in pure Xlib and 
> implemented button and menu widgets (thats all thats really needed) from scratch
> which frankly isn't too hard. But sure, if you want a WM thats actually useful
> you'll need a proper toolkit.

True. And, as my skills grow, I will move up to X11 toolkits and other X11 clients.
I note, however, that most present-day toolkits present bindings in C++, and not
C, thus ruling them out as far as my development projects are concerned. This
leaves a very limited list of toolkits, with no middle ground. I could either code
for one of the heritage toolkits (Athena, Motif, etc.) and have a very, shall we
say, "antique" UI, or for one of the few modern toolkits that offer C bindings, 
and have an over-architected UI. ISTM that we've lost the middle ground, as far
as C bindings are concerned.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#80722 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Fri, 16 Jul 2021 15:33:23 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Fri, 16 Jul 2021 09:33:11 +0000, MrSpud_8nnwe wrote:
>
>> On Thu, 15 Jul 2021 14:59:08 -0000 (UTC)
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>I quickly found that Xlib alone wasn't conducive to effective programming; I
>>>need
>>>a widget set or toolkit. But, I haven't abandoned Xlib; I'm simply putting
>>>together,
>>>from scratch, the sort of widgets I need to make things work.
>> 
>> It depends how much you want your WM to do.
>
>Sorry, but I must make a correction here: I have no interest (at this time)
>in writing a Window Manager (WM) client for X11. The O'Reilly X11 Xlib book
>discusses WMs in detail, and includes the code for a rudementary WM implemented
>
>in Xlib.
>
>My interest lies elsewhere: specifically, in writing a Display Manager (DM)
>client for X11 in Xlib. A DM  provides "a graphical login manager which starts
>a login session on an X server from the same or another computer." For this,
>I can find no basic example, nor any reasonably complete and simple "howto",
>so it gives me a reasonable challenge to learn X11 Xlib programming with.

I should imagine most display managers are little more than a window that
accepts password credentials which does credential checking and if ok simply
exec's the required WM or enviroment.

>for one of the heritage toolkits (Athena, Motif, etc.) and have a very, shall
>we
>say, "antique" UI, or for one of the few modern toolkits that offer C
>bindings, 

Personally I'd go for Motif if you can still find libraries that'll work on
modern systems.

[toc] | [prev] | [next] | [standalone]

#80723 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Sat, 17 Jul 2021 15:04:16 +0000, MrSpud_Ccq3_3_r wrote:

> On Fri, 16 Jul 2021 15:33:23 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>On Fri, 16 Jul 2021 09:33:11 +0000, MrSpud_8nnwe wrote:
>>
>>> On Thu, 15 Jul 2021 14:59:08 -0000 (UTC)
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>I quickly found that Xlib alone wasn't conducive to effective programming; I
>>>>need
>>>>a widget set or toolkit. But, I haven't abandoned Xlib; I'm simply putting
>>>>together,
>>>>from scratch, the sort of widgets I need to make things work.
>>> 
>>> It depends how much you want your WM to do.
>>
>>Sorry, but I must make a correction here: I have no interest (at this time)
>>in writing a Window Manager (WM) client for X11. The O'Reilly X11 Xlib book
>>discusses WMs in detail, and includes the code for a rudementary WM implemented
>>
>>in Xlib.
>>
>>My interest lies elsewhere: specifically, in writing a Display Manager (DM)
>>client for X11 in Xlib. A DM  provides "a graphical login manager which starts
>>a login session on an X server from the same or another computer." For this,
>>I can find no basic example, nor any reasonably complete and simple "howto",
>>so it gives me a reasonable challenge to learn X11 Xlib programming with.
> 
> I should imagine most display managers are little more than a window that
> accepts password credentials which does credential checking and if ok simply
> exec's the required WM or enviroment.

Not really. To satisfy a purely local login, you need a minimum of two input
edit fields: a Username that echoes typed characters and a password that doesn't.
If you add XDMCP into the mix (which I intend to do), you need an additional
field that allows you to pick the host to connect to from a list of eligible
hostnames. These three fields may require just one window, but more likely
require more. In my experimentation, I have 7 windows just to handle this
(a window for the Hostname, a window for the ScrollUp button, a window for
the ScrollDown button, a window to frame the ScrollUp/Hostname/ScrollDown
set, a window for the Username, a window for the Password, and a window to
frame the whole set).

Add to this a window for a localtime clock, a window for a terminal identification,
and a window for a DM identifier, and all the miscellaneous windows
needed to frame these presentation windows, and you have quite a number
of windows to manage.

Then, of course, there's the actual activities that the windows themselves
present. I have a clock, so I must format and present the time and date.
I have two text inputs, so I must write text editing code. I have a scrollable
selection window, so I must write logic to update the selection, and to handle
the ScrollUp and ScrollDown buttons.

And, then there's other, non-window logic, such as the logic to start the X
server (if necessary), the logic to validate usernames and passwords (both
locally and remotely), and the logic to start the user's WM of choice.

All in all, this project will teach me a great deal about writing X11 Xlib
application code, and about X11 in general. And that's the primary goal.

>>for one of the heritage toolkits (Athena, Motif, etc.) and have a very, shall
>>we
>>say, "antique" UI, or for one of the few modern toolkits that offer C
>>bindings, 
> 
> Personally I'd go for Motif if you can still find libraries that'll work on
> modern systems.

Pish, tush.

I have, at my fingertips, the Athena widget set (both Xaw and Xaw3d), and Motif,
supplied as part of the Slackware Linux distribution I work in. I also have GTK+,
GTK+2, and GTK+3. Also QT and FLTK, should I want to work in C++.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#80726 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Sat, 17 Jul 2021 16:30:12 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Sat, 17 Jul 2021 15:04:16 +0000, MrSpud_Ccq3_3_r wrote:
>> I should imagine most display managers are little more than a window that
>> accepts password credentials which does credential checking and if ok simply
>> exec's the required WM or enviroment.
>
>Not really. To satisfy a purely local login, you need a minimum of two input
>edit fields: a Username that echoes typed characters and a password that
>doesn't.
>If you add XDMCP into the mix (which I intend to do), you need an additional
>field that allows you to pick the host to connect to from a list of eligible
>hostnames. These three fields may require just one window, but more likely
>require more. In my experimentation, I have 7 windows just to handle this
>(a window for the Hostname, a window for the ScrollUp button, a window for
>the ScrollDown button, a window to frame the ScrollUp/Hostname/ScrollDown
>set, a window for the Username, a window for the Password, and a window to
>frame the whole set).
>
>Add to this a window for a localtime clock, a window for a terminal
>identification,
>and a window for a DM identifier, and all the miscellaneous windows
>needed to frame these presentation windows, and you have quite a number
>of windows to manage.
>
>Then, of course, there's the actual activities that the windows themselves
>present. I have a clock, so I must format and present the time and date.
>I have two text inputs, so I must write text editing code. I have a scrollable
>selection window, so I must write logic to update the selection, and to handle
>the ScrollUp and ScrollDown buttons.

You can obviously add as many bells and whistles as you like, but ultimately
all you need for a basic login system is username and password - 1 window,
2 textboxes. For the other stuff you don't need a drop down, you could just
have them pre-listed which can then be clicked on, much simpler.

>And, then there's other, non-window logic, such as the logic to start the X
>server (if necessary), the logic to validate usernames and passwords (both
>locally and remotely), and the logic to start the user's WM of choice.

Basic *nix fork-exec stuff.

>> Personally I'd go for Motif if you can still find libraries that'll work on
>> modern systems.
>
>Pish, tush.
>
>I have, at my fingertips, the Athena widget set (both Xaw and Xaw3d), and
>Motif,
>supplied as part of the Slackware Linux distribution I work in. I also have

I do have a soft spot for slackware - mainly the lack of the god awful
systemd - but its hardly a standard distro these days and was last updated 5
years ago so obviously not much happening these days. I doubt any of the
common distros will have those libraries installed so if you want it to be
used by others....

[toc] | [prev] | [next] | [standalone]

#80727 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On 7/19/2021 12:50 AM, MrSpud_2fxg@cligh74ct.info wrote:
> On Sat, 17 Jul 2021 16:30:12 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Sat, 17 Jul 2021 15:04:16 +0000, MrSpud_Ccq3_3_r wrote:
>>> I should imagine most display managers are little more than a window that
>>> accepts password credentials which does credential checking and if ok simply
>>> exec's the required WM or enviroment.
>>
>> Not really. To satisfy a purely local login, you need a minimum of two input
>> edit fields: a Username that echoes typed characters and a password that
>> doesn't.
>> If you add XDMCP into the mix (which I intend to do), you need an additional
>> field that allows you to pick the host to connect to from a list of eligible
>> hostnames. These three fields may require just one window, but more likely
>> require more. In my experimentation, I have 7 windows just to handle this
>> (a window for the Hostname, a window for the ScrollUp button, a window for
>> the ScrollDown button, a window to frame the ScrollUp/Hostname/ScrollDown
>> set, a window for the Username, a window for the Password, and a window to
>> frame the whole set).
>>
>> Add to this a window for a localtime clock, a window for a terminal
>> identification,
>> and a window for a DM identifier, and all the miscellaneous windows
>> needed to frame these presentation windows, and you have quite a number
>> of windows to manage.
>>
>> Then, of course, there's the actual activities that the windows themselves
>> present. I have a clock, so I must format and present the time and date.
>> I have two text inputs, so I must write text editing code. I have a scrollable
>> selection window, so I must write logic to update the selection, and to handle
>> the ScrollUp and ScrollDown buttons.
> 
> You can obviously add as many bells and whistles as you like, but ultimately
> all you need for a basic login system is username and password - 1 window,
> 2 textboxes. For the other stuff you don't need a drop down, you could just
> have them pre-listed which can then be clicked on, much simpler.
[...]

Humm...

https://secure.login.gov/

;^)

[toc] | [prev] | [next] | [standalone]

#80728 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Mon, 19 Jul 2021 00:53:47 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>On 7/19/2021 12:50 AM, MrSpud_2fxg@cligh74ct.info wrote:
>> On Sat, 17 Jul 2021 16:30:12 -0000 (UTC)
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> On Sat, 17 Jul 2021 15:04:16 +0000, MrSpud_Ccq3_3_r wrote:
>>>> I should imagine most display managers are little more than a window that
>>>> accepts password credentials which does credential checking and if ok
>simply
>>>> exec's the required WM or enviroment.
>>>
>>> Not really. To satisfy a purely local login, you need a minimum of two input
>
>>> edit fields: a Username that echoes typed characters and a password that
>>> doesn't.
>>> If you add XDMCP into the mix (which I intend to do), you need an additional
>
>>> field that allows you to pick the host to connect to from a list of eligible
>
>>> hostnames. These three fields may require just one window, but more likely
>>> require more. In my experimentation, I have 7 windows just to handle this
>>> (a window for the Hostname, a window for the ScrollUp button, a window for
>>> the ScrollDown button, a window to frame the ScrollUp/Hostname/ScrollDown
>>> set, a window for the Username, a window for the Password, and a window to
>>> frame the whole set).
>>>
>>> Add to this a window for a localtime clock, a window for a terminal
>>> identification,
>>> and a window for a DM identifier, and all the miscellaneous windows
>>> needed to frame these presentation windows, and you have quite a number
>>> of windows to manage.
>>>
>>> Then, of course, there's the actual activities that the windows themselves
>>> present. I have a clock, so I must format and present the time and date.
>>> I have two text inputs, so I must write text editing code. I have a
>scrollable
>>> selection window, so I must write logic to update the selection, and to
>handle
>>> the ScrollUp and ScrollDown buttons.
>> 
>> You can obviously add as many bells and whistles as you like, but ultimately
>> all you need for a basic login system is username and password - 1 window,
>> 2 textboxes. For the other stuff you don't need a drop down, you could just
>> have them pre-listed which can then be clicked on, much simpler.
>[...]
>
>Humm...
>
>https://secure.login.gov/

Have a look at the MacOS login screen. 2 textboxs, nothing else (for normal
use), not even a window, just a background picture and a few buttons down
the bottom for reboot etc.

[toc] | [prev] | [next] | [standalone]

#80729 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Mon, 19 Jul 2021 07:50:50 +0000, MrSpud_2fxg wrote:

> On Sat, 17 Jul 2021 16:30:12 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>On Sat, 17 Jul 2021 15:04:16 +0000, MrSpud_Ccq3_3_r wrote:
>>> I should imagine most display managers are little more than a window that
>>> accepts password credentials which does credential checking and if ok simply
>>> exec's the required WM or enviroment.
>>
>>Not really. To satisfy a purely local login, you need a minimum of two input
>>edit fields: a Username that echoes typed characters and a password that
>>doesn't.
>>If you add XDMCP into the mix (which I intend to do), you need an additional
>>field that allows you to pick the host to connect to from a list of eligible
>>hostnames. These three fields may require just one window, but more likely
>>require more. In my experimentation, I have 7 windows just to handle this
>>(a window for the Hostname, a window for the ScrollUp button, a window for
>>the ScrollDown button, a window to frame the ScrollUp/Hostname/ScrollDown
>>set, a window for the Username, a window for the Password, and a window to
>>frame the whole set).
>>
>>Add to this a window for a localtime clock, a window for a terminal
>>identification,
>>and a window for a DM identifier, and all the miscellaneous windows
>>needed to frame these presentation windows, and you have quite a number
>>of windows to manage.
>>
>>Then, of course, there's the actual activities that the windows themselves
>>present. I have a clock, so I must format and present the time and date.
>>I have two text inputs, so I must write text editing code. I have a scrollable
>>selection window, so I must write logic to update the selection, and to handle
>>the ScrollUp and ScrollDown buttons.
> 
> You can obviously add as many bells and whistles as you like, but ultimately
> all you need for a basic login system is username and password - 1 window,
> 2 textboxes. For the other stuff you don't need a drop down, you could just
> have them pre-listed which can then be clicked on, much simpler.

You apparently misunderstand what I'm working with. X11 is a communications
protocol, with the "client" end implemented in Xlib and the server end implemented
in the X server.

X11 doesn't have "textboxes", and it's "windows" are simply rectangular regions
of the display that can be drawn on. Such a "window" can receive keystrokes and/or
mouse activity, if it chooses.  I'm working at a much lower level than you think
I am.

As for "all you need ... is username and password", that might be true in a single
system network, but in a multi-system network, using the facilities of X11, I
also need a "hostname" to connect to (it may be "localhost", but, then again, it
may also be "desktop_computer.my.lan" or "game_server.my.lan"). For me, this
becomes a scrollable selector with three windows (a next-selection downarrow
window, a previous-selection uparrow window, and a selection output window).

What you are describing is a simple, one-system display manager implemented with
one of the X11 widget sets (such as GTK+, or QT or Athena), and not the more
comprehensive multi-system display manager that I'm trying to build.

[snip]

HTH
-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#80730 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On Mon, 19 Jul 2021 15:20:43 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Mon, 19 Jul 2021 07:50:50 +0000, MrSpud_2fxg wrote:
>> You can obviously add as many bells and whistles as you like, but ultimately
>> all you need for a basic login system is username and password - 1 window,
>> 2 textboxes. For the other stuff you don't need a drop down, you could just
>> have them pre-listed which can then be clicked on, much simpler.
>
>You apparently misunderstand what I'm working with. X11 is a communications
>protocol, with the "client" end implemented in Xlib and the server end
>implemented
>in the X server.

Given I already told you I wrote my own window manager (along with half a
dozen games and more utilities than I can count in the last 25 years) I'm 
wondering why you think I need some patronising heads up on what constitutes 
X11 and Xlib?

>X11 doesn't have "textboxes", and it's "windows" are simply rectangular regions
>
>of the display that can be drawn on. Such a "window" can receive keystrokes
>and/or
>mouse activity, if it chooses.  I'm working at a much lower level than you
>think
>I am.

Writing your own buttons and textboxes in raw X11 is fairly trivial *IF* you
know the API well and arn't too fussed about pretty graphics.

>As for "all you need ... is username and password", that might be true in a
>single
>system network, but in a multi-system network, using the facilities of X11, I
>also need a "hostname" to connect to (it may be "localhost", but, then again,
>it
>may also be "desktop_computer.my.lan" or "game_server.my.lan"). For me, this
>becomes a scrollable selector with three windows (a next-selection downarrow
>window, a previous-selection uparrow window, and a selection output window).

Or you could have a textbox with intelligent autocomplete of hostnames since
presumably you'll have a list anyway if you're planning on having a pull down.

>What you are describing is a simple, one-system display manager implemented
>with
>one of the X11 widget sets (such as GTK+, or QT or Athena), and not the more
>comprehensive multi-system display manager that I'm trying to build.

No, I wasn't. But it doesn't matter, I was just trying to be helpful. You do
what you like.

[toc] | [prev] | [next] | [standalone]

#80724 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups

On 7/17/2021 5:04 PM, MrSpud_Ccq3_3_r@atc_rakxp6.info wrote:
>> for one of the heritage toolkits (Athena, Motif, etc.) and have a very, shall
>> we
>> say, "antique" UI, or for one of the few modern toolkits that offer C
>> bindings,
> Personally I'd go for Motif if you can still find libraries that'll work on
> modern systems.
> 
> 

Probably Lesstif, which, as far as I remember, is a FOSS clone of Motif.
But that was along time ago, so I may have missed some happening meanwhile.

[toc] | [prev] | [next] | [standalone]

#80708 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

On 2021-07-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> There's no need to.  Really, talk about wheel re-invention.  Hey, here's an
> idea, why not write a new OS?  Who needs Linux?  Who need z/OS?  (etc)

Someone is reinventing the literal wheel right now in the world of high
end bicycles, though.

[toc] | [prev] | [next] | [standalone]

#80710 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

In article <20210714131012.811@kylheku.com>,
Kaz Kylheku  <563-365-8930@kylheku.com> wrote:
>On 2021-07-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> There's no need to.  Really, talk about wheel re-invention.  Hey, here's an
>> idea, why not write a new OS?  Who needs Linux?  Who need z/OS?  (etc)
>
>Someone is reinventing the literal wheel right now in the world of high
>end bicycles, though.

I'd be interested to know more about that (as a cyclist myself).

Also, this whole sub-thread about re-inventing trn, makes me think of a
certain frequent poster who is always going on about how he's gonna
re-invent everything.  Haven't heard from him in quite a while, though
(thankfully).

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

[toc] | [prev] | [next] | [standalone]

#80719 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

Am 14.07.21 um 23:03 schrieb Kenny McCormack:
> Also, this whole sub-thread about re-inventing trn, makes me think of a
> certain frequent poster who is always going on about how he's gonna
> re-invent everything.  Haven't heard from him in quite a while, though
> (thankfully).
>

Oh he's quite busy to tell the people over at the Python group that 
their language is a bag of shite and slow as hell and that everything 
will change once he finished the frontend for his fancy compiler.

Needless to say that there isn't even remotely something like a working 
demo. The last checkin was few months ago.


	Christian

[toc] | [prev] | [next] | [standalone]

#80709 — Re: Wheel re-invention (Was: comp.lang.c blocked on Google Groups Switch to free (Thunderbird)

In comp.lang.c, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> There's no need to.  Really, talk about wheel re-invention.  Hey, here's an
> idea, why not write a new OS?  Who needs Linux?  Who need z/OS?  (etc)
> 
> trn (and similar, such as "tin") does everything you need, so why not use
> it?  You'd spend a lot of time, just to get up to the level of
> functionality of trn.  Why go through the hassle?

I get the impression from news.software.readers that when people post
about creating new newsreaders these days the are looking for features
you don't get in tin/trn. Things like working well with multiple news
servers (track reading by message ID instead of by sequential id in news
spool) or working better with local personal cached copies instead of
copies on a remote shared server.

I can see a bit of appeal there, but not enough to actually go through
the exercise myself.

Elijah
------
typically is satisfied with bending trn to his will

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web