Re: Can 'graphics' be a file descriptor?

On 01/01/2025 13:40, wij wrote:

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.

I don't know what that means. But an app that edits text files is going to be different from one that edits images.
As for a clean program, what you posted was in C++, a language not known for its clean, simple syntax. You might want to start there.

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.

My 'print #w' was specifically for text. There was a proper API for actual graphics content within a window, which was both pixel-based and model-based (using 2D/3D floating point data).
However, in early days, my dialog boxes were little more than text windows rendered in graphics, and GUI elements were created with text escape codes via 'print', IIRC. That was nearly 4 decades ago though.
I don't see a use for real graphics using a text or byte stream except when the connection to the display device is some serial link. But even then, at the user level I'd expect an API which hides those details:
    w := createwindow(....)
    draw_rectangle(w, x1, y1, x2, y2)
'w' is a handle; you don't care exactly what it is or how it works.

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

Perhaps I meant that everything can be accessed via a path within the file system.