Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Can 'graphics' be a file descriptor?
Date: Thu, 2 Jan 2025 11:28:32 +0000
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <vl5t90$3ae3h$1@dont-email.me>
References: <d0fcbe9e7b29ce6f9a0604058475b0aa9a23d5cb.camel@gmail.com>
 <87msgaubjj.fsf@nosuchdomain.example.com>
 <0bfa49a6d580546ab2db91aeac7627afb19e492d.camel@gmail.com>
 <vl3b5b$2ot7p$1@dont-email.me>
 <54e61867ce60b955e70510b0cb3433b910c87550.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 02 Jan 2025 12:28:32 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5302f7810926806663f26cab4eed79c2";
	logging-data="3487857"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197sSDE2rZDiZV3ypeX6Mda"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:HGEaYv9p7FX7PqBO8x/GM3icxOI=
In-Reply-To: <54e61867ce60b955e70510b0cb3433b910c87550.camel@gmail.com>
Content-Language: en-GB
Bytes: 5296

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.