Re: Can 'graphics' be a file descriptor?

On Wed, 2025-01-01 at 12:07 +0000, bart wrote:

On 01/01/2025 11:05, wij wrote:

On Wed, 2025-01-01 at 01:29 -0800, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

 
A file *descriptor* is a small integer referring to some file-like
entity, used with open/close/read/write.  There's no such thing in
standard C; it's a POSIX concept.
 
I don't think you're actually working with file descriptors, though it's
hard to tell.
 

   if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
     WY_THROW(r);
   }

 
popen() is a POSIX function.  It takes two arguments, not four.
 
The code you posted is C++.  Why are you posting it to comp.lang..c?
 
[...]

 
I would like to have opinions about the idea "graphics being a file descriptor".
The implement is irrevent for the discussion. Some imagination is required.
 

 
You'll need to explain what you mean by `graphics` or `'graphics`. What
is it now? What is it anyway?
 
Are you refering to the 'handles' that graphics libraries sometimes use
to refer to windows etc? If so what would be the advantages of having
them being file descriptors? Could those advantages be possible in any
other way?
 
How would it simplify your C++ code?

Yes, in MS-Windonw, file descriptor is probably still 'file handle' (as in DOS).
I am mainly referring to Linux (or systems that relies on file descriptor).
The usual graphics library, especially with GUI,... seriously interfere the
the 'normal' program. E.g. you are not expected to have a clean source program
that simply edits a picture file.

Some time ago, I had a scripting language where you could write:
 
    print #x, "hello"
 
With x being either 'con' (the default if omitted), an open file handle,
a string destination, a printer or plotter handle, or the handle to an
image, window or control (button etc).
 
So this allowed you write text into any of those, via the convenience of
'print' which stringified or serialised many kinds of data, and also
kept track of the current text position.
 
Is this one of the advantages?

Yes, looked like what I expect. But file descriptor is a stronger request (or
provision) than library codes. It will simply more and would standardize
'graphics' to some extent enough for 'normal programs' (commercial programs
alway seek breakthrough, you cannot expect to fully standardize it).

Are there any problem doing 'graphics' with your print script? I am mainly
looking for 'clean'/reusabe source code.

Actually I'm surprised that in Linux, everything isn't already a file
anyway.

??? to my knowledge, in Linux 'everything' is file descriptor.