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

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

'Graphics' of libwy

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

Contents

  'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-15 18:04 +0800
    Re: 'Graphics' of libwy Bonita Montero <Bonita.Montero@gmail.com> - 2024-12-15 13:43 +0100
      Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-16 06:57 +0800
        Re: 'Graphics' of libwy Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-15 15:12 -0800
    Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-16 10:29 +0100
      Re: 'Graphics' of libwy Lynn McGuire <lynnmcguire5@gmail.com> - 2024-12-16 18:47 -0600
        Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-17 08:49 +0100
          Re: 'Graphics' of libwy Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-12-17 11:54 -0500
            Re: 'Graphics' of libwy Michael S <already5chosen@yahoo.com> - 2024-12-17 22:52 +0200
            Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-18 08:34 +0100
    Re: 'Graphics' of libwy Lynn McGuire <lynnmcguire5@gmail.com> - 2024-12-16 18:41 -0600
      Re: 'Graphics' of libwy Paavo Helde <eesnimi@osa.pri.ee> - 2024-12-17 16:38 +0200
        Re: 'Graphics' of libwy scott@slp53.sl.home (Scott Lurndal) - 2024-12-17 15:34 +0000
        Re: 'Graphics' of libwy Muttley@DastardlyHQ.org - 2024-12-17 16:02 +0000
          Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-17 17:30 +0100
            Re: 'Graphics' of libwy Paavo Helde <eesnimi@osa.pri.ee> - 2024-12-17 18:53 +0200
              Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-18 08:38 +0100
            Re: 'Graphics' of libwy Muttley@DastardlyHQ.org - 2024-12-17 16:53 +0000
              Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-18 09:09 +0100
                Re: 'Graphics' of libwy Muttley@DastardlyHQ.org - 2024-12-18 09:16 +0000
                  Re: 'Graphics' of libwy David Brown <david.brown@hesbynett.no> - 2024-12-18 13:58 +0100
                    Re: 'Graphics' of libwy Muttley@DastardlyHQ.org - 2024-12-18 14:07 +0000
                  Re: 'Graphics' of libwy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-18 13:12 -0800
                    Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-19 10:08 +0800
                      Re: 'Graphics' of libwy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-18 18:29 -0800
                        Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-19 10:51 +0800
                          Re: 'Graphics' of libwy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-18 20:14 -0800
                            Re: 'Graphics' of libwy Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-19 16:21 -0800
                              Re: 'Graphics' of libwy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-19 17:07 -0800
                                Re: 'Graphics' of libwy Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-19 17:38 -0800
                                Re: 'Graphics' of libwy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-19 18:09 -0800
                                  Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-20 11:10 +0800
                                    Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-23 02:50 +0800
                                      Re: 'Graphics' of libwy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-22 15:26 -0800
                                        Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-23 14:32 +0800
                                          Re: 'Graphics' of libwy Muttley@dastardlyhq.com - 2024-12-23 09:59 +0000
                                            Re: 'Graphics' of libwy wij <wyniijj5@gmail.com> - 2024-12-25 23:51 +0800
                                  Re: 'Graphics' of libwy Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-19 19:53 -0800
                                    Re: 'Graphics' of libwy Lynn McGuire <lynnmcguire5@gmail.com> - 2024-12-19 21:57 -0600
                                      Re: 'Graphics' of libwy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-19 21:01 -0800
                                      Re: 'Graphics' of libwy Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-19 21:39 -0800
                                        Re: 'Graphics' of libwy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-19 21:48 -0800
            Re: 'Graphics' of libwy scott@slp53.sl.home (Scott Lurndal) - 2024-12-17 17:08 +0000
          Re: 'Graphics' of libwy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-17 12:32 -0800

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

#121251

On 18/12/2024 10:16, Muttley@DastardlyHQ.org wrote:
> On Wed, 18 Dec 2024 09:09:22 +0100
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 17/12/2024 17:53, Muttley@DastardlyHQ.org wrote:
>>> You don't want a library that only works with the latest bleeding edge
>> versions
>>> of C++. IMO C++ 2011 would be a reasonable oldest version.
>>>
>>
>> I'd much rather have one that takes advantage of relatively modern C++
>> features than one that re-invented these same features in their one
>> special ways - which is what you see with these older libraries.  I'd
> 
> A lot of companies systems don't have their compilers upgraded if consistency
> are whats required. A security company I worked at a few years ago only
> went up to C++14 because they didn't want any nasty security hole surprises
> if they upgraded the compiler and started using the new features (or even the
> older ones).

Sure.  There are many reasons for not upgrading tools, and/or not 
changing standards - some good reasons, some bad reasons.  I have never 
been a fan of upgrading just for the sake of upgrading.  But in the case 
of a gui toolkit, I think there is a lot to be gained from more modern C++.

> 
>> new, well-designed modern C++ gui library, I'd want to see concepts,
> 
> Ugh. Concepts and constraints are yet another syntatic soup solution to a
> problem almost no one has except in various academic ivory towers.
> 

Let's just call that a matter of opinion and move on.

>> But if the C++ committee were to make a standard C++ gui library as part
>> of the C++ standard, then it would by definition be part of a later C++
>> standard.  So if it was targeted for C++29, then of course it could rely
>> on all the language and library features of standard C++ up to and
>> including C++29.
> 
> Well they won't because sensibly they realise graphics capabilities are so
> variable - or non existent - between systems that there's absolutely no point
> trying to develop a standard library for it. 

Yes, that's what I have been saying.

> I was surprised they even
> included a threading library given on various embedded systems threading is
> not available. Plus its inconsistent - why multithreading but no multiprocess?
> 

Threading in C11 and C++11 was too little, too late.  And it doesn't 
take into account the significantly different threading systems used in 
different OS's.  For embedded systems, how is anyone supposed to use a 
threading library that doesn't handle priorities, stack size, and the like?

I am not surprised they /tried/ to have a standard thread library.  And 
some of it could, I am sure, be useful to some people.  But I expect 
most people use system-specific thread libraries in practice.

I think trying to standardise a C++ gui library would be like 
standardising threading, but orders of magnitude worse.

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

#121252

On Wed, 18 Dec 2024 13:58:02 +0100
David Brown <david.brown@hesbynett.no> wibbled:
>On 18/12/2024 10:16, Muttley@DastardlyHQ.org wrote:
>> I was surprised they even
>> included a threading library given on various embedded systems threading is
>> not available. Plus its inconsistent - why multithreading but no
>multiprocess?
>> 
>
>Threading in C11 and C++11 was too little, too late.  And it doesn't 
>take into account the significantly different threading systems used in 
>different OS's.  For embedded systems, how is anyone supposed to use a 
>threading library that doesn't handle priorities, stack size, and the like?

Until 2017 when shared_mutex came along it couldn't even do 3 level locking 
which would be a deal breaker for a lot of people. Certainly was for me.

>I think trying to standardise a C++ gui library would be like 
>standardising threading, but orders of magnitude worse.

Agreed.

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

#121257

Muttley@DastardlyHQ.org writes:
> On Wed, 18 Dec 2024 09:09:22 +0100
> David Brown <david.brown@hesbynett.no> wibbled:
>>On 17/12/2024 17:53, Muttley@DastardlyHQ.org wrote:
>>> You don't want a library that only works with the latest bleeding
>>> edge versions of C++. IMO C++ 2011 would be a reasonable oldest
>>> version.
>>
>>I'd much rather have one that takes advantage of relatively modern C++ 
>>features than one that re-invented these same features in their one 
>>special ways - which is what you see with these older libraries.  I'd 
>
> A lot of companies systems don't have their compilers upgraded if consistency
> are whats required. A security company I worked at a few years ago only 
> went up to C++14 because they didn't want any nasty security hole surprises
> if they upgraded the compiler and started using the new features (or even the
> older ones).

Recall that what's being proposed is adding a GUI library to a new C++
standard.  If you don't upgrade your C++ implementation, you don't get
the new C++ standard GUI library -- even if the standardized library is
designed to be compatible with an older C++ standard.

I personally don't think that a GUI library should be part of the C++
standard.  There are enough GUI libraries out there already,
cross-platform and otherwise.  But if such a library were added to the
C++ standard in, say, C++29, there's no reason it shouldn't take
advantage of C++29 features.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121258

On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
> Muttley@DastardlyHQ.org writes:
> > On Wed, 18 Dec 2024 09:09:22 +0100
> > David Brown <david.brown@hesbynett.no> wibbled:
> > > On 17/12/2024 17:53, Muttley@DastardlyHQ.org wrote:
> > > > You don't want a library that only works with the latest bleeding
> > > > edge versions of C++. IMO C++ 2011 would be a reasonable oldest
> > > > version.
> > > 
> > > I'd much rather have one that takes advantage of relatively modern C++ 
> > > features than one that re-invented these same features in their one 
> > > special ways - which is what you see with these older libraries.  I'd 
> > 
> > A lot of companies systems don't have their compilers upgraded if consistency
> > are whats required. A security company I worked at a few years ago only 
> > went up to C++14 because they didn't want any nasty security hole surprises
> > if they upgraded the compiler and started using the new features (or even the
> > older ones).
> 
> Recall that what's being proposed is adding a GUI library to a new C++
> standard.  If you don't upgrade your C++ implementation, you don't get
> the new C++ standard GUI library -- even if the standardized library is
> designed to be compatible with an older C++ standard.
> 
> I personally don't think that a GUI library should be part of the C++
> standard.  There are enough GUI libraries out there already,
> cross-platform and otherwise.  But if such a library were added to the
> C++ standard in, say, C++29, there's no reason it shouldn't take
> advantage of C++29 features.
> 
> [...]
> 

I think now the answer may lie at what the cout (terminal) is.
E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
a.out is now plotting on a 200x100 drawing board.

C++ can provide a graphics library, but not necessarily a GUI library.

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

#121259

wij <wyniijj5@gmail.com> writes:
> On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
[...]
> I think now the answer may lie at what the cout (terminal) is.
> E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
> a.out is now plotting on a 200x100 drawing board.
>
> C++ can provide a graphics library, but not necessarily a GUI library.

That's a text terminal.  Sure, you can do "graphics" in text mode, but I
don't think that's what anyone has been talking about.

ncurses already exists.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121261

On Wed, 2024-12-18 at 18:29 -0800, Keith Thompson wrote:
> wij <wyniijj5@gmail.com> writes:
> > On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
> [...]
> > I think now the answer may lie at what the cout (terminal) is.
> > E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
> > a.out is now plotting on a 200x100 drawing board.
> > 
> > C++ can provide a graphics library, but not necessarily a GUI library.
> 
> That's a text terminal.  Sure, you can do "graphics" in text mode, but I
> don't think that's what anyone has been talking about.

But, what is the true thing the program is dealing with? What is 'pixel'?
I think it is possible to handle and display a photo using 'cout'

There are various kind of video devices. It is impractical for c++
to think it can provide a 'standard' for all to accept, and also not the 
purpose of a language should be after (like std-library already done).

> ncurses already exists.
> 

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

#121262

wij <wyniijj5@gmail.com> writes:
> On Wed, 2024-12-18 at 18:29 -0800, Keith Thompson wrote:
>> wij <wyniijj5@gmail.com> writes:
>> > On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
>> [...]
>> > I think now the answer may lie at what the cout (terminal) is.
>> > E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
>> > a.out is now plotting on a 200x100 drawing board.
>> > 
>> > C++ can provide a graphics library, but not necessarily a GUI library.
>> 
>> That's a text terminal.  Sure, you can do "graphics" in text mode, but I
>> don't think that's what anyone has been talking about.
>
> But, what is the true thing the program is dealing with? What is 'pixel'?

Do you really not know what a pixel is?

> I think it is possible to handle and display a photo using 'cout'

Possible?  Sure.
Desirable?  Rarely.
Worth standardizing in the C++ standard?  Nope.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121268

On 12/18/2024 08:14 PM, Keith Thompson wrote:
> wij <wyniijj5@gmail.com> writes:
>> On Wed, 2024-12-18 at 18:29 -0800, Keith Thompson wrote:
>>> wij <wyniijj5@gmail.com> writes:
>>>> On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
>>> [...]
>>>> I think now the answer may lie at what the cout (terminal) is.
>>>> E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
>>>> a.out is now plotting on a 200x100 drawing board.
>>>>
>>>> C++ can provide a graphics library, but not necessarily a GUI library.
>>>
>>> That's a text terminal.  Sure, you can do "graphics" in text mode, but I
>>> don't think that's what anyone has been talking about.
>>
>> But, what is the true thing the program is dealing with? What is 'pixel'?
>
> Do you really not know what a pixel is?
>
>> I think it is possible to handle and display a photo using 'cout'
>
> Possible?  Sure.
> Desirable?  Rarely.
> Worth standardizing in the C++ standard?  Nope.
>
> [...]
>

Pixel = "picture element"
Voxel = "volume element"
Raster = "rake"
Vector = "Tempest"

CCITT = Comite Consultatif International Telephonique et Telegraphique
G3/G4 Fax format
ITU-T = International Telecommunications Union - Telephony

TIFF Tagged Image File Format
BMP Bitmap

stride <- width
stripe
striqe
stribe

edge case: edge case
corner case:  corner case

JPEG:  Joint Photographic Experts Group
MPEG:  Moving Picture Experts Groups

JBIG
PNG
JPEG-LS

GIF

Some monitors are round.

bit = binary digit
binit

grayscale = monochrome
Lab, YCbCr, RGB, CMY, ABC, XYZ <- CIE
8 color, 16 color, 8 bit color, 16 bit color, 24 bit color

Font files
Printer languages

CCD <-> LED

video memory


raster ops

drawing fonts

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

#121269

Ross Finlayson <ross.a.finlayson@gmail.com> writes:
> On 12/18/2024 08:14 PM, Keith Thompson wrote:
>> wij <wyniijj5@gmail.com> writes:
>>> On Wed, 2024-12-18 at 18:29 -0800, Keith Thompson wrote:
>>>> wij <wyniijj5@gmail.com> writes:
>>>>> On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
>>>> [...]
>>>>> I think now the answer may lie at what the cout (terminal) is.
>>>>> E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
>>>>> a.out is now plotting on a 200x100 drawing board.
>>>>>
>>>>> C++ can provide a graphics library, but not necessarily a GUI library.
>>>>
>>>> That's a text terminal.  Sure, you can do "graphics" in text mode, but I
>>>> don't think that's what anyone has been talking about.
>>>
>>> But, what is the true thing the program is dealing with? What is 'pixel'?
>>
>> Do you really not know what a pixel is?
>>
>>> I think it is possible to handle and display a photo using 'cout'
>>
>> Possible?  Sure.
>> Desirable?  Rarely.
>> Worth standardizing in the C++ standard?  Nope.
>>
>> [...]
>
> Pixel = "picture element"

You do know what a pixel is.  So why did you ask?

[Long list of definitions of terms deleted]

I don't know what point you're trying to make.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121270

On 12/19/2024 05:07 PM, Keith Thompson wrote:
> Ross Finlayson <ross.a.finlayson@gmail.com> writes:
>> On 12/18/2024 08:14 PM, Keith Thompson wrote:
>>> wij <wyniijj5@gmail.com> writes:
>>>> On Wed, 2024-12-18 at 18:29 -0800, Keith Thompson wrote:
>>>>> wij <wyniijj5@gmail.com> writes:
>>>>>> On Wed, 2024-12-18 at 13:12 -0800, Keith Thompson wrote:
>>>>> [...]
>>>>>> I think now the answer may lie at what the cout (terminal) is.
>>>>>> E.g. gnome-terminal --geometry=200x100 --zoom=0.5 -- ./a.out
>>>>>> a.out is now plotting on a 200x100 drawing board.
>>>>>>
>>>>>> C++ can provide a graphics library, but not necessarily a GUI library.
>>>>>
>>>>> That's a text terminal.  Sure, you can do "graphics" in text mode, but I
>>>>> don't think that's what anyone has been talking about.
>>>>
>>>> But, what is the true thing the program is dealing with? What is 'pixel'?
>>>
>>> Do you really not know what a pixel is?
>>>
>>>> I think it is possible to handle and display a photo using 'cout'
>>>
>>> Possible?  Sure.
>>> Desirable?  Rarely.
>>> Worth standardizing in the C++ standard?  Nope.
>>>
>>> [...]
>>
>> Pixel = "picture element"
>
> You do know what a pixel is.  So why did you ask?
>
> [Long list of definitions of terms deleted]
>
> I don't know what point you're trying to make.
>

It's a bit of the long-and-short of graphics and formats is all.

There's raster graphics and there's vector graphics,
there's procedural graphics, it results being to or
from raw or bitmaps, or according to box or drawing fonts,
a drawing context, say, the bpp and the ppi and the
color model, that for rendering fonts is a particular
sort of language itself combining bitmap and procedural
graphics and size hints in vector graphics, it's just
figured that a "graphics library" starts getting
involved with, for example, rendering fonts and bitmaps
on the screen, it was for the libwy guy.

The libwy guy's and excuse me if I get that wrong,
I've enjoyed his posts about portability and design
and these kinds of things, then for example the ideas
about language profiles, of C++, like when to use what
features, vis-a-vis "really vanilla C++", it's meant to amuse.

Dealing with graphics is like for a buffer, with the
"stride stripe striqe stribe" sort of result the usual
idea of a 2-D array in a 1-D array, then drawing primitives
is a key things, then, for text, is about rendering fonts.

Synthetic-natural hybrid coding?

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

#121271

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Ross Finlayson <ross.a.finlayson@gmail.com> writes:
>> On 12/18/2024 08:14 PM, Keith Thompson wrote:
>>> wij <wyniijj5@gmail.com> writes:
[...]
>>>> But, what is the true thing the program is dealing with? What is 'pixel'?
>>>
>>> Do you really not know what a pixel is?
[...]
>> Pixel = "picture element"
>
> You do know what a pixel is.  So why did you ask?

My apologies, I didn't pay enough attention to the attribution lines.
wij write "What is 'pixel'"; Ross wrote 'Pixel = "picture element"'.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121272

On Thu, 2024-12-19 at 18:09 -0800, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > Ross Finlayson <ross.a.finlayson@gmail.com> writes:
> > > On 12/18/2024 08:14 PM, Keith Thompson wrote:
> > > > wij <wyniijj5@gmail.com> writes:
> [...]
> > > > > But, what is the true thing the program is dealing with? What is 'pixel'?
> > > > 
> > > > Do you really not know what a pixel is?
> [...]
> > > Pixel = "picture element"
> > 
> > You do know what a pixel is.  So why did you ask?
> 
> My apologies, I didn't pay enough attention to the attribution lines.
> wij write "What is 'pixel'"; Ross wrote 'Pixel = "picture element"'.

class Pixel { /* Whatever suitable */ };
 
int main() { 
 Array2D<Pixel> img; 

 load_picture(img, "mydog.jpg");
 draw_circle(img, cx,cy, dim);

 // cout.set_graphics_mode(...);  // if necessary  
 // for(ssize_t y=img.height()-1; y>=0; --y) {
 //  cout << StrSeg(&img(0,y), img.width()) << WY_ENDL; 
 // }

 cout << img;  // the about can be simplified to one line
};

'Pixel' is just something you can write into Array2D

---------- a_rawkey.cpp
#include <Wy.stdio.h>
#include <Wy.string.h>

using namespace Wy;

int main(int, char* [])
try {
 const char usage[]="Type arrow keys (Up,Down,Left,Down) to move around, 'ESC' to exit." WY_ENDL;
 Errno r;

 cout << usage;
 constexpr WeeStr KeyESC("\33");
 constexpr WeeStr KeyUp("\33[A");
 constexpr WeeStr KeyDown("\33[B");
 constexpr WeeStr KeyRight("\33[C");
 constexpr WeeStr KeyLeft("\33[D");

 constexpr WeeStr CursorUp("\33[1A");
 constexpr WeeStr CursorDown("\33[1B");
 constexpr WeeStr CursorRight("\33[1C");
 constexpr WeeStr CursorLeft("\33[1D");

 WeeStr stroke;
 for(;;) {
   if((r=_get_rawkey(cin,stroke))!=Ok) {
     WY_THROW(r);
   }
   if(stroke==KeyESC) {
     break;
   }

   if(stroke==KeyUp) {
     cout << CursorUp;
   } else if(stroke==KeyLeft) {
     cout << CursorLeft;
   } else if(stroke==KeyDown) {
     cout << CursorDown;
   } else if(stroke==KeyRight) {
     cout << CursorRight;
   } else {};
 }
 return 0;
}
catch(const Errno& e) {
 cerr << wrd(e) << WY_ENDL;
 return e.c_errno();
}
catch(...) {
 cerr << "main caught(...)" WY_ENDL;
 throw;
};   
------------

If the key code from raw mode tty is defined (maybe, but I don't know), 
I think C++ writing vi like editor should be much simpler, no need for ncurses.
If back to 'graphics', Pixel can be CSI sequence in this case.

My purpose is a 'C++ graphics'. No need to consider various kinds of 
graphics accelerators or 'GUI', which cannot be standardized and would be
wrong goal.

What I now trying to experiment is separating graphics things to another 
process. By doing so, 'the C++ code' just plays with Array2D<Pixel>, no need 
to include those (mostly) heavy graphics library.

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

#121289

On Fri, 2024-12-20 at 11:10 +0800, wij wrote:
> On Thu, 2024-12-19 at 18:09 -0800, Keith Thompson wrote:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > > Ross Finlayson <ross.a.finlayson@gmail.com> writes:
> > > > On 12/18/2024 08:14 PM, Keith Thompson wrote:
> > > > > wij <wyniijj5@gmail.com> writes:
> > [...]
> > > > > > But, what is the true thing the program is dealing with? What is 'pixel'?
> > > > > 
> > > > > Do you really not know what a pixel is?
> > [...]
> > > > Pixel = "picture element"
> > > 
> > > You do know what a pixel is.  So why did you ask?
> > 
> > My apologies, I didn't pay enough attention to the attribution lines.
> > wij write "What is 'pixel'"; Ross wrote 'Pixel = "picture element"'.
> 
> class Pixel { /* Whatever suitable */ };
>  
> int main() { 
>  Array2D<Pixel> img; 
> 
>  load_picture(img, "mydog.jpg");
>  draw_circle(img, cx,cy, dim);
> 
>  // cout.set_graphics_mode(...);  // if necessary  
>  // for(ssize_t y=img.height()-1; y>=0; --y) {
>  //  cout << StrSeg(&img(0,y), img.width()) << WY_ENDL; 
>  // }
> 
>  cout << img;  // the about can be simplified to one line
> };
> 
> 'Pixel' is just something you can write into Array2D
> 
> ---------- a_rawkey.cpp
> #include <Wy.stdio.h>
> #include <Wy.string.h>
> 
> using namespace Wy;
> 
> int main(int, char* [])
> try {
>  const char usage[]="Type arrow keys (Up,Down,Left,Down) to move around, 'ESC' to exit." WY_ENDL;
>  Errno r;
> 
>  cout << usage;
>  constexpr WeeStr KeyESC("\33");
>  constexpr WeeStr KeyUp("\33[A");
>  constexpr WeeStr KeyDown("\33[B");
>  constexpr WeeStr KeyRight("\33[C");
>  constexpr WeeStr KeyLeft("\33[D");
> 
>  constexpr WeeStr CursorUp("\33[1A");
>  constexpr WeeStr CursorDown("\33[1B");
>  constexpr WeeStr CursorRight("\33[1C");
>  constexpr WeeStr CursorLeft("\33[1D");
> 
>  WeeStr stroke;
>  for(;;) {
>    if((r=_get_rawkey(cin,stroke))!=Ok) {
>      WY_THROW(r);
>    }
>    if(stroke==KeyESC) {
>      break;
>    }
> 
>    if(stroke==KeyUp) {
>      cout << CursorUp;
>    } else if(stroke==KeyLeft) {
>      cout << CursorLeft;
>    } else if(stroke==KeyDown) {
>      cout << CursorDown;
>    } else if(stroke==KeyRight) {
>      cout << CursorRight;
>    } else {};
>  }
>  return 0;
> }
> catch(const Errno& e) {
>  cerr << wrd(e) << WY_ENDL;
>  return e.c_errno();
> }
> catch(...) {
>  cerr << "main caught(...)" WY_ENDL;
>  throw;
> };   
> ------------
> 
> If the key code from raw mode tty is defined (maybe, but I don't know), 
> I think C++ writing vi like editor should be much simpler, no need for ncurses.
> If back to 'graphics', Pixel can be CSI sequence in this case.
> 
> My purpose is a 'C++ graphics'. No need to consider various kinds of 
> graphics accelerators or 'GUI', which cannot be standardized and would be
> wrong goal.
> 
> What I now trying to experiment is separating graphics things to another 
> process. By doing so, 'the C++ code' just plays with Array2D<Pixel>, no need 
> to include those (mostly) heavy graphics library.
> 

I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I thought.
It looks plausible using C++ to write graphic programs without using any
graphic library. Dream come true! 'C++ graphics' is possible and easy.

'face' just implemented basic capability of showing image. GUI has many 
graphics user interactions. From current result, I think simple GUI program
can be done easily.

face_svr.cpp has 140 lines, not shown.

------- face.h
/* Copyright is licensed by GNU LGPL, see file COPYING.       by I.J.Wang 2024
 
   <!!=ddd........>
   <RS=n w h pixtype>xxx    // n=size of next packet, pixtype=RGB32
*/
#ifndef WY__FACE_H__
#define WY__FACE_H__

#include <CSCall/Vect.h>
#include <CSCall/WeeStr.h>

constexpr Wy::WeeStr RGB32("RGB32");

typedef Wy::Vect<unsigned char,4> Pixel;

constexpr Pixel RGB32_White({255,255,255,0xff});  // blue,green,red
constexpr Pixel RGB32_Black({0,0,0,0xff});

#endif // WY__FACE_H__

------- face_cli.cpp
include <Wy.stdio.h>
#include <Wy.unistd.h>
#include <Wy.signal.h>
#include <CSCall/DrawPlane.h>
#include <CSCall/Array2D.h>
#include <CSCall/XnStream.h>
#include "face.h"
   
using namespace Wy;

// [Syn] Draw demo image
void draw_demo(Array2D<Pixel>& pic) {
 const unsigned int cx=pic.width()/2;
 const unsigned int cy=pic.height()/2;
   
 pic.fill(RGB32_Black);
     
 draw_solid_circle(pic.header(),cx,cy,30,RGB32_White);
     
 for(unsigned int rad=45; rad<=150; rad+=15) {
   draw_circle(pic.header(),cx,cy,rad,RGB32_White);
 }     
};     

// [Syn] Make RS packet (for sending image)
String mkpkt_RS(unsigned int w, unsigned h, WeeStr pixtype, size_t psize) {
 String str("<RS=");
 str << wrd(psize) << ' ' << wrd(w) << ' ' << wrd(h) << ' ' << pixtype.c_str() << '>';
 return str;
};     
       
// [Syn] Fork a process exec 'face' program and send $image for it to display
//       $cpid= pid of the 'face' program
//     
Errno face_set_image(const Array2D<Pixel>& image, ProcessID& cpid) try {
 Errno r;
 String rspkt;
         
 rspkt= mkpkt_RS(image.width(),image.height(),RGB32,image.size()*sizeof(Pixel));
       
 FifoFile ffrd,ffwr;
 char arg0[]="./face";
 char* argarr[]={arg0,NULL};
 if((r=popen(cpid,ffrd,ffwr,"./face",argarr))!=Ok) {
  WY_THROW(r);
 }   
       
 char buf[20];
 if(_write_sizepacket(buf,rspkt.size())==NULL) {
   WY_THROW( Errno(errno) );
 }       
          ffwr << StrSeg(buf,PktHeaderSize);
 ffwr << rspkt;
 ffwr << StrSeg(reinterpret_cast<const char*>(image._data()),
                image.size()*sizeof(Pixel));
 return Ok;
}
catch(const Errno& e) {
 return e;
};

int main(int argc, const char* argv[])
try {
 const unsigned int PicWidth=800;
 const unsigned int PicHeight=600;
 Errno r;
 Array2D<Pixel> pic(PicWidth,PicHeight);
 String rspkt;
 ProcessID cpid;

 draw_demo(pic);

 face_set_image(pic,cpid);   // two windows
 face_set_image(pic,cpid);

 WaitStat wstt;
 if((r=waitpid(cpid,&wstt,0))!=Ok) {
   WY_THROW(r);
 }
 cout << "Child exit " << wstt.exit_status() << WY_ENDL;

 return 0;
}
catch(const Errno& e) {
 cerr << wrd(e) << WY_ENDL;
 return -1;  // e.c_errno();
}
catch(...) {
 cerr << "main() caught(...)" WY_ENDL;
 throw;
};

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

#121291

On 12/22/2024 10:50 AM, wij wrote:
[...]
> I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I thought.
> It looks plausible using C++ to write graphic programs without using any
> graphic library. Dream come true! 'C++ graphics' is possible and easy.

Well, sure. PPM's are rather easy to create. :^)

Creating OBJ files in C/C++ is rather easy as well.

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

#121293

On Sun, 2024-12-22 at 15:26 -0800, Chris M. Thomasson wrote:
> On 12/22/2024 10:50 AM, wij wrote:
> [...]
> > I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I thought.
> > It looks plausible using C++ to write graphic programs without using any
> > graphic library. Dream come true! 'C++ graphics' is possible and easy.
> 
> Well, sure. PPM's are rather easy to create. :^)
> 
> Creating OBJ files in C/C++ is rather easy as well.

For simple GUI, e.g. drawing graph of math. functions, statistics, Mandelbrot
set,...) is no problem.

int main() {
 Array2D<Pixel> img;
 draw_mand(img);
 put_image("graphics_server", img);
 zoom_event_handler();
}

The solution of C++ graphics (or GUI) is no graphics in C++.

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

#121294

On Mon, 23 Dec 2024 14:32:38 +0800
wij <wyniijj5@gmail.com> gabbled:
>On Sun, 2024-12-22 at 15:26 -0800, Chris M. Thomasson wrote:
>> On 12/22/2024 10:50 AM, wij wrote:
>> [...]
>> > I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I th=
>ought.
>> > It looks plausible using C++ to write graphic programs without using an=
>y
>> > graphic library. Dream come true! 'C++ graphics' is possible and easy.
>>=20
>> Well, sure. PPM's are rather easy to create. :^)
>>=20
>> Creating OBJ files in C/C++ is rather easy as well.
>
>For simple GUI, e.g. drawing graph of math. functions, statistics, Mandelbr=
>ot
>set,...) is no problem.
>
>int main() {
> Array2D<Pixel> img;
> draw_mand(img);
> put_image("graphics_server", img);
> zoom_event_handler();
>}
>
>The solution of C++ graphics (or GUI) is no graphics in C++.

And that'll work with X windows will it? Where you are setting the display
IP and screen number or does it just always use the default?

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

#121300

On Mon, 2024-12-23 at 09:59 +0000, Muttley@dastardlyhq.com wrote:
> On Mon, 23 Dec 2024 14:32:38 +0800
> wij <wyniijj5@gmail.com> gabbled:
> > On Sun, 2024-12-22 at 15:26 -0800, Chris M. Thomasson wrote:
> > > On 12/22/2024 10:50 AM, wij wrote:
> > > [...]
> > > > I just wrote two program (face_svr.cpp, face_cli.cpp) to test what I th=
> > ought.
> > > > It looks plausible using C++ to write graphic programs without using an=
> > y
> > > > graphic library. Dream come true! 'C++ graphics' is possible and easy.
> > > =20
> > > Well, sure. PPM's are rather easy to create. :^)
> > > =20
> > > Creating OBJ files in C/C++ is rather easy as well.
> > 
> > For simple GUI, e.g. drawing graph of math. functions, statistics, Mandelbr=
> > ot
> > set,...) is no problem.
> > 
> > int main() {
> > Array2D<Pixel> img;
> > draw_mand(img);
> > put_image("graphics_server", img);
> > zoom_event_handler();
> > }
> > 
> > The solution of C++ graphics (or GUI) is no graphics in C++.
> 
> And that'll work with X windows will it? Where you are setting the display
> IP and screen number or does it just always use the default?
> 

What the graphics server is is not important, it is the client program.

I am more confident now that C++ graphics is easy, because I made a simple one that
just handles mouse event (server side 240 lines!), keyboard is just too many codes to do.

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

#121273

On 12/19/2024 06:09 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Ross Finlayson <ross.a.finlayson@gmail.com> writes:
>>> On 12/18/2024 08:14 PM, Keith Thompson wrote:
>>>> wij <wyniijj5@gmail.com> writes:
> [...]
>>>>> But, what is the true thing the program is dealing with? What is 'pixel'?
>>>>
>>>> Do you really not know what a pixel is?
> [...]
>>> Pixel = "picture element"
>>
>> You do know what a pixel is.  So why did you ask?
>
> My apologies, I didn't pay enough attention to the attribution lines.
> wij write "What is 'pixel'"; Ross wrote 'Pixel = "picture element"'.
>

(No harm / no foul)

Why that's gentlemanly of you.

It's mind-boggling that for hundreds of years at
least there were printed books, mass-printed or
since the invention of printing presses and movable
type, and that for at least 150 years there's been
photography, for where the graphical renditions
were painting or drawing, or statuary or what,
that since about 25 years ago there are small-screen
full-motion high-resolution displays, each different
yet all same, yet of course it is still in a sense
pixels, blits, drawing primitives, and sprites,
vis-a-vis the procedural and high-level procedural,
sadly an entire generation is myopic and reading has
suffered, I think screens should be banned for youth,
so they have to learn how to read to get their giggles,
though that's impractical, point being that somebody
needs to know the entire stack of the things at
least in gross detail that thusly the efforts of
"make a new one", while daunting, at least have
a total embarrassment of computing resources the
hardware, that if all the lately bloatware and
various other kinds of wares that are of no interest
to the user of the device, were gone, then implementors
of course can make astounding demos, and even simple
entire systems that are all quite bog-standard.

Warm regards


(Obligatory "in C++", ....)

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

#121274

On 12/19/2024 9:53 PM, Ross Finlayson wrote:
...
> It's mind-boggling that for hundreds of years at
> least there were printed books, mass-printed or
> since the invention of printing presses and movable
> type, and that for at least 150 years there's been
> photography, for where the graphical renditions
> were painting or drawing, or statuary or what,
> that since about 25 years ago there are small-screen
> full-motion high-resolution displays, each different
> yet all same, yet of course it is still in a sense
> pixels, blits, drawing primitives, and sprites,
> vis-a-vis the procedural and high-level procedural,
> sadly an entire generation is myopic and reading has
> suffered, I think screens should be banned for youth,
> so they have to learn how to read to get their giggles,
> though that's impractical, point being that somebody
> needs to know the entire stack of the things at
> least in gross detail that thusly the efforts of
> "make a new one", while daunting, at least have
> a total embarrassment of computing resources the
> hardware, that if all the lately bloatware and
> various other kinds of wares that are of no interest
> to the user of the device, were gone, then implementors
> of course can make astounding demos, and even simple
> entire systems that are all quite bog-standard.
...

That is all ONE sentence.  I am impressed !

Lynn

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

#121275

On 12/19/2024 7:57 PM, Lynn McGuire wrote:
> On 12/19/2024 9:53 PM, Ross Finlayson wrote:
> ...
>> It's mind-boggling that for hundreds of years at
>> least there were printed books, mass-printed or
>> since the invention of printing presses and movable
>> type, and that for at least 150 years there's been
>> photography, for where the graphical renditions
>> were painting or drawing, or statuary or what,
>> that since about 25 years ago there are small-screen
>> full-motion high-resolution displays, each different
>> yet all same, yet of course it is still in a sense
>> pixels, blits, drawing primitives, and sprites,
>> vis-a-vis the procedural and high-level procedural,
>> sadly an entire generation is myopic and reading has
>> suffered, I think screens should be banned for youth,
>> so they have to learn how to read to get their giggles,
>> though that's impractical, point being that somebody
>> needs to know the entire stack of the things at
>> least in gross detail that thusly the efforts of
>> "make a new one", while daunting, at least have
>> a total embarrassment of computing resources the
>> hardware, that if all the lately bloatware and
>> various other kinds of wares that are of no interest
>> to the user of the device, were gone, then implementors
>> of course can make astounding demos, and even simple
>> entire systems that are all quite bog-standard.
> ...
> 
> That is all ONE sentence.  I am impressed !

No shit! Ross knows how to express it! :^)

[...]

[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