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 1 of 3  [1] 2 3  Next page →

#121206 — 'Graphics' of libwy

I had headache whenevr I think about graphics in C++. Why C++ does not provide
a graphics library (lots complaint about this), not even a simplest one for 
demonstrating its 'power' of C++ itself? Then, I suddenly realized that the 
minimal answer is already there because the resolution of modern text screen 
(emulator) is barely enough (width can be >320).
        
---------- t_txtwind.cpp
#include <Wy.stdio.h>
#include <Wy.math.h>
#include <Wy.signal.h>
#include <CSCall/Array2D.h>
#include <CSCall/ioctl.h>

using namespace Wy;

typedef float FuncValue;
constexpr FuncValue FMinX=-5;
constexpr FuncValue FMaxX= 5;

FuncValue func(FuncValue x) {  // function to plot
 return ::sin(x);
};

//---------------------------------------------
typedef char Pixel;
Array2D<Pixel> txtwin;

// [Syn] Plot func(FuncValue) in current terminal (text window) 
//       (window size can change)
//
void plot() {
 constexpr Pixel BgChar=' ';
 constexpr Pixel FgChar='x';
 Errno r;
 WinSize ws;

 if((r=getwinsize(cout,ws))!=Ok) {
   WY_THROW(r);
 }

 Array<FuncValue> varr;
 FuncValue dx= (FMaxX-FMinX)/ws.col();
 FuncValue ymin= Limits<FuncValue>::Max;
 FuncValue ymax= Limits<FuncValue>::Min;
 for(FuncValue x=FMinX; x<=FMaxX; x+=dx) {
   FuncValue v= func(x);
   if(v>ymax) {
     ymax=v;
   }
   if(v<ymin) {
     ymin=v;
   }
   varr << func(x);
 }

 if((r=txtwin.reset(ws.col(),ws.row()))!=Ok) {
   WY_THROW(r);
 }
 ::memset(txtwin.header()._data(),BgChar,txtwin.size());
 
 for(size_t x=0; x<varr.size(); ++x) {
   unsigned int y=((varr[x]-ymin)/(ymax-ymin))*(txtwin.height()-1);
   txtwin.header().write_point(x,y,FgChar);
 }
 for(size_t y=0; y<txtwin.height(); ++y) {
   cout << StrSeg(&txtwin.header().at(0,y), txtwin.header().width()) << WY_ENDL;
 }
};

void winch_handler(int, ::siginfo_t*, void*) {
 SignaledContext sigcontext;
 plot();
};

int main(int argc, const char* argv[])
try {
 Errno r;
 if((r=sig_setact(SIGWINCH, SigAct(winch_handler) ))!=Ok) {
   WY_THROW(r);
 }

 plot();
 for(int wcnt=0; wcnt<100; ++wcnt) { // wait for 100 win changes or Cntl-C
   ::pause();
 }
 cout << "OK" 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;
};
-------------------------

[]$ g++ t_txtwind.cpp -lwy
[]$ ./a.out              
                         xxxxxx                                            xxxxx
                        x      x                                          x
                       x        x                                        x
                      x          x                                      x
                     x            x                                    x
                    x
                                   x                                  x
                   x                x                                x
                  x           
                                     x                              x      
                 x                    x                  
                                                                   x
                x                      x                          x
   
               x                        x                        x
                              
              x                          x                      x
             x                                           
                                          x                    x
            x                              x
                                                              x   
           x                                x                x
          x                                  x
                                                            x
         x                                    x            x
        x                                      x          x
       x                                        x        x
      x                                          x      x
xx xxx                                            xxxxxx
  x                           

[toc] | [next] | [standalone]

#121208

Am 15.12.2024 um 11:04 schrieb wij:
> I had headache whenevr I think about graphics in C++. Why C++ does not provide
> a graphics library (lots complaint about this), not even a simplest one for
> demonstrating its 'power' of C++ itself? Then, I suddenly realized that the
> minimal answer is already there because the resolution of modern text screen
> (emulator) is barely enough (width can be >320).

https://www.cairographics.org/cairomm/

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

#121211

On Sun, 2024-12-15 at 13:43 +0100, Bonita Montero wrote:
> Am 15.12.2024 um 11:04 schrieb wij:
> > I had headache whenevr I think about graphics in C++. Why C++ does not provide
> > a graphics library (lots complaint about this), not even a simplest one for
> > demonstrating its 'power' of C++ itself? Then, I suddenly realized that the
> > minimal answer is already there because the resolution of modern text screen
> > (emulator) is barely enough (width can be >320).
> 
> https://www.cairographics.org/cairomm/

I managed to compile a tutorial program. I think I need a light-weight raster 
graphics library.

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

#121212

On 12/15/2024 02:57 PM, wij wrote:
> On Sun, 2024-12-15 at 13:43 +0100, Bonita Montero wrote:
>> Am 15.12.2024 um 11:04 schrieb wij:
>>> I had headache whenevr I think about graphics in C++. Why C++ does not provide
>>> a graphics library (lots complaint about this), not even a simplest one for
>>> demonstrating its 'power' of C++ itself? Then, I suddenly realized that the
>>> minimal answer is already there because the resolution of modern text screen
>>> (emulator) is barely enough (width can be >320).
>>
>> https://www.cairographics.org/cairomm/
>
> I managed to compile a tutorial program. I think I need a light-weight raster
> graphics library.
>
>

It reminds of a "light user interface" that all sorts
of I/O "input editors" and "renderers" have facilities
ranging from the tty terminal to small and large touchscreens,
vis-a-vis things like "windows" and panels and so on, the canvas,
with regards to defining "experiences" as they may be,
from the tty to "widgets", then as with regards to graphical
data, and rendering, usually enough raster imaging after
drawing "graphical user interface" widgets and having
input editors or buttons, as to building experiences
to a "light user interface" abstraction, then for
surfacing with regards to what's available,
like menuing in the tty, this kind of thing.

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

#121214

On 15/12/2024 11:04, wij wrote:
> I had headache whenevr I think about graphics in C++. Why C++ does not provide
> a graphics library (lots complaint about this), not even a simplest one for
> demonstrating its 'power' of C++ itself? 

There are 101 C++ graphics libraries, all with their pros and cons and 
different use-cases.  How could the C++ standard library pick just one 
of them?

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

#121219

On 12/16/2024 3:29 AM, David Brown wrote:
> On 15/12/2024 11:04, wij wrote:
>> I had headache whenevr I think about graphics in C++. Why C++ does not 
>> provide
>> a graphics library (lots complaint about this), not even a simplest 
>> one for
>> demonstrating its 'power' of C++ itself? 
> 
> There are 101 C++ graphics libraries, all with their pros and cons and 
> different use-cases.  How could the C++ standard library pick just one 
> of them?

Open Source and LGPL would be a good place to start.
    https://en.wikipedia.org/wiki/List_of_widget_toolkits

Thanks,
Lynn

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

#121222

On 17/12/2024 01:47, Lynn McGuire wrote:
> On 12/16/2024 3:29 AM, David Brown wrote:
>> On 15/12/2024 11:04, wij wrote:
>>> I had headache whenevr I think about graphics in C++. Why C++ does 
>>> not provide
>>> a graphics library (lots complaint about this), not even a simplest 
>>> one for
>>> demonstrating its 'power' of C++ itself? 
>>
>> There are 101 C++ graphics libraries, all with their pros and cons and 
>> different use-cases.  How could the C++ standard library pick just one 
>> of them?
> 
> Open Source and LGPL would be a good place to start.
>     https://en.wikipedia.org/wiki/List_of_widget_toolkits
> 

So that leaves - what - 20-odd different libraries from that page that 
are open source, cross-platform and suitable for C or C++ ?  And there's 
maybe an order of magnitude more that not on the Wikipedia page but are 
still established enough to be contenders.

Then you need to consider that the C++ world is not just *nix, MacOS and 
Windows - and that even for those, needs vary enormously (big, small, 
easy-to-use, wide selection of widgets, 2D, 3D, etc.).  The things /I/ 
want from a gui library for an embedded system are hugely different from 
what you would want on a PC.  And of course LGPL is useless for me.

No, that page is not really a good place to start - unless you are using 
it as a starting point for showing how meaningless it would be to try to 
pick a single gui library that is somehow "standard" for C++.


I don't know if that will stop the C++ committee from trying to pick or 
make a standard GUI library - after all, it's certainly an appealing 
idea.  But if the "success" of C++'s threading support is any judge, 
they have a hard road in front of them.

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

#121233

David Brown wrote this post while blinking in Morse code:

> <snip>
> I don't know if that will stop the C++ committee from trying to pick or 
> make a standard GUI library - after all, it's certainly an appealing 
> idea.  But if the "success" of C++'s threading support is any judge, 
> they have a hard road in front of them.

I was just going to say "imagine how long that would get tied up in the
standards committee."

Anyhoo, years ago I used Borland's OWL and it was decent for the time.

Years after that, Borland used VCL as it's C++ graphics library... written in
Object Pascal. Some weird shit went on in the debugger with that one.

-- 
Illiterate?  Write today, for free help!

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

#121238

On Tue, 17 Dec 2024 11:54:43 -0500
Chris Ahlstrom <OFeem1987@teleworm.us> wrote:

> David Brown wrote this post while blinking in Morse code:
> 
> > <snip>
> > I don't know if that will stop the C++ committee from trying to
> > pick or make a standard GUI library - after all, it's certainly an
> > appealing idea.  But if the "success" of C++'s threading support is
> > any judge, they have a hard road in front of them.  
> 
> I was just going to say "imagine how long that would get tied up in
> the standards committee."
> 
> Anyhoo, years ago I used Borland's OWL and it was decent for the time.
>
> Years after that, Borland used VCL as it's C++ graphics library...
> written in Object Pascal. Some weird shit went on in the debugger
> with that one.
> 

Should have been not many years.
Even Borland itself very quickly understood that OWL was crap.

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

#121242

On 17/12/2024 17:54, Chris Ahlstrom wrote:
> David Brown wrote this post while blinking in Morse code:
> 
>> <snip>
>> I don't know if that will stop the C++ committee from trying to pick or
>> make a standard GUI library - after all, it's certainly an appealing
>> idea.  But if the "success" of C++'s threading support is any judge,
>> they have a hard road in front of them.
> 
> I was just going to say "imagine how long that would get tied up in the
> standards committee."
> 
> Anyhoo, years ago I used Borland's OWL and it was decent for the time.
> 
> Years after that, Borland used VCL as it's C++ graphics library... written in
> Object Pascal. Some weird shit went on in the debugger with that one.
> 

I only used Borland C++ Builder on a couple of small projects.  The 
thing that bugged me was the number of string types involved in doing 
anything much - you had C strings, Pascal strings (fixed length and 
dynamic), Windows strings, all with wide character variations.

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

#121218

On 12/15/2024 4:04 AM, wij wrote:
> I had headache whenevr I think about graphics in C++. Why C++ does not provide
> a graphics library (lots complaint about this), not even a simplest one for
> demonstrating its 'power' of C++ itself? Then, I suddenly realized that the
> minimal answer is already there because the resolution of modern text screen
> (emulator) is barely enough (width can be >320).
...

I totally agree that C++ should have a graphics library and a user 
interface library both.

Have you looked at
    https://wxwidgets.org/

"wxWidgets is a C++ library that lets developers create applications for 
Windows, macOS, Linux and other platforms with a single code base. It 
has popular language bindings for Python, Ruby, Lua, Perl and several 
other languages, and unlike other cross-platform toolkits, wxWidgets 
gives applications a truly native look and feel because it uses the 
platform's native API rather than emulating the GUI. It's also 
extensive, free, open-source and mature."

Lynn

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

#121226

On 17.12.2024 02:41, Lynn McGuire wrote:
> On 12/15/2024 4:04 AM, wij wrote:
>> I had headache whenevr I think about graphics in C++. Why C++ does not 
>> provide
>> a graphics library (lots complaint about this), not even a simplest 
>> one for
>> demonstrating its 'power' of C++ itself? Then, I suddenly realized 
>> that the
>> minimal answer is already there because the resolution of modern text 
>> screen
>> (emulator) is barely enough (width can be >320).
> ...
> 
> I totally agree that C++ should have a graphics library and a user 
> interface library both.
> 
> Have you looked at
>     https://wxwidgets.org/
> 
> "wxWidgets is a C++ library that lets developers create applications for 
> Windows, macOS, Linux and other platforms with a single code base. It 
> has popular language bindings for Python, Ruby, Lua, Perl and several 
> other languages, and unlike other cross-platform toolkits, wxWidgets 
> gives applications a truly native look and feel because it uses the 
> platform's native API rather than emulating the GUI. It's also 
> extensive, free, open-source and mature."

wxWidgets does work and is better than MFC, but not extremely so. Also, 
it is not exactly light-weight, a git checkout is 803 MB. Good luck for 
the standards committee to standardize anything like that.

Also, wxWidgets would be only part of the solution, it would still need 
a graphics back-end for actually drawing anything, plus some fonts for 
rendering texts. On some platforms the graphics back-end is built into 
the OS, on others it is not.

BTW, what has happened with Mr Flibble and his neoGFX library?

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

#121227

Paavo Helde <eesnimi@osa.pri.ee> writes:
>On 17.12.2024 02:41, Lynn McGuire wrote:
>> On 12/15/2024 4:04 AM, wij wrote:

>wxWidgets does work and is better than MFC, but not extremely so. Also, 
>it is not exactly light-weight, a git checkout is 803 MB. Good luck for 
>the standards committee to standardize anything like that.
>
>Also, wxWidgets would be only part of the solution, it would still need 
>a graphics back-end for actually drawing anything, plus some fonts for 
>rendering texts. On some platforms the graphics back-end is built into 
>the OS, on others it is not.
>
>BTW, what has happened with Mr Flibble and his neoGFX library?

neoGFx appears to still be actively maintained.

https://github.com/i42output/neoGFX

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

#121229

On Tue, 17 Dec 2024 16:38:49 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 17.12.2024 02:41, Lynn McGuire wrote:
>> On 12/15/2024 4:04 AM, wij wrote:
>>> I had headache whenevr I think about graphics in C++. Why C++ does not 
>>> provide
>>> a graphics library (lots complaint about this), not even a simplest 
>>> one for
>>> demonstrating its 'power' of C++ itself? Then, I suddenly realized 
>>> that the
>>> minimal answer is already there because the resolution of modern text 
>>> screen
>>> (emulator) is barely enough (width can be >320).
>> ...
>> 
>> I totally agree that C++ should have a graphics library and a user 
>> interface library both.
>> 
>> Have you looked at
>>     https://wxwidgets.org/
>> 
>> "wxWidgets is a C++ library that lets developers create applications for 
>> Windows, macOS, Linux and other platforms with a single code base. It 
>> has popular language bindings for Python, Ruby, Lua, Perl and several 
>> other languages, and unlike other cross-platform toolkits, wxWidgets 
>> gives applications a truly native look and feel because it uses the 
>> platform's native API rather than emulating the GUI. It's also 
>> extensive, free, open-source and mature."
>
>wxWidgets does work and is better than MFC, but not extremely so. Also, 
>it is not exactly light-weight, a git checkout is 803 MB. Good luck for 
>the standards committee to standardize anything like that.
>
>Also, wxWidgets would be only part of the solution, it would still need 
>a graphics back-end for actually drawing anything, plus some fonts for 
>rendering texts. On some platforms the graphics back-end is built into 
>the OS, on others it is not.

Does wx do 3D stuff? If not you'd need yet another library to do that too.

Personally I'd go with Qt. Its mature and cross platform and does what 99%
of most people need.

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

#121230

On 17/12/2024 17:02, Muttley@DastardlyHQ.org wrote:
> On Tue, 17 Dec 2024 16:38:49 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>> On 17.12.2024 02:41, Lynn McGuire wrote:
>>> On 12/15/2024 4:04 AM, wij wrote:
>>>> I had headache whenevr I think about graphics in C++. Why C++ does not
>>>> provide
>>>> a graphics library (lots complaint about this), not even a simplest
>>>> one for
>>>> demonstrating its 'power' of C++ itself? Then, I suddenly realized
>>>> that the
>>>> minimal answer is already there because the resolution of modern text
>>>> screen
>>>> (emulator) is barely enough (width can be >320).
>>> ...
>>>
>>> I totally agree that C++ should have a graphics library and a user
>>> interface library both.
>>>
>>> Have you looked at
>>>      https://wxwidgets.org/
>>>
>>> "wxWidgets is a C++ library that lets developers create applications for
>>> Windows, macOS, Linux and other platforms with a single code base. It
>>> has popular language bindings for Python, Ruby, Lua, Perl and several
>>> other languages, and unlike other cross-platform toolkits, wxWidgets
>>> gives applications a truly native look and feel because it uses the
>>> platform's native API rather than emulating the GUI. It's also
>>> extensive, free, open-source and mature."
>>
>> wxWidgets does work and is better than MFC, but not extremely so. Also,
>> it is not exactly light-weight, a git checkout is 803 MB. Good luck for
>> the standards committee to standardize anything like that.
>>
>> Also, wxWidgets would be only part of the solution, it would still need
>> a graphics back-end for actually drawing anything, plus some fonts for
>> rendering texts. On some platforms the graphics back-end is built into
>> the OS, on others it is not.
> 
> Does wx do 3D stuff? If not you'd need yet another library to do that too.
> 
> Personally I'd go with Qt. Its mature and cross platform and does what 99%
> of most people need.
> 

No, it doesn't come close to that.  It's a solid gui library with lots 
of extra tools, and is useful to many people - but it's nothing remotely 
like you suggest.

It has a license that is totally unsuitable for standardisation.  I'm 
not complaining about the license - the people that wrote the library 
get to pick the license.  But a standard C++ gui library, if such a 
thing is ever made, has to have a very liberal license - BSD/MIT at most.

And Qt is hardly a lightweight choice either.

The other big issue I see with wx and Qt are that they are /old/ - very 
old.  Maturity is not a benefit if there is to be a standard C++ gui 
library - it needs to be something that makes use of modern features of 
C++, not something that is grounded in C++98 and an API that is barely 
above a C-style library, with home-made classes for strings, lists, 
threads, and just about everything else.

I think if there is ever going to be a standard gui library for C++, it 
will be written specially for the purpose.  That has some big advantages 
- if the designers decide they need extra language features for signals 
and slots, for example, then those can be added to the language rather 
than using an external tool.

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

#121231

On 17.12.2024 18:30, David Brown wrote:
> 
> I think if there is ever going to be a standard gui library for C++, it 
> will be written specially for the purpose.  That has some big advantages 
> - if the designers decide they need extra language features for signals 
> and slots, for example, then those can be added to the language rather 
> than using an external tool.

For curiosity I looked at the https://neogfx.org page. Among other 
things it says: "C++ lambdas have made traditional signals and slots 
redundant".

It also promises "modern C++20 design" and "no reliance on macro-based 
code generation".

NeoGFX itself has a too restrictive license (GPL), but at least it 
suggests that C++ nowadays is expressive enough to actually allow for 
some kind of self-contained and concise GUI library.

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

#121243

On 17/12/2024 17:53, Paavo Helde wrote:
> On 17.12.2024 18:30, David Brown wrote:
>>
>> I think if there is ever going to be a standard gui library for C++, 
>> it will be written specially for the purpose.  That has some big 
>> advantages - if the designers decide they need extra language features 
>> for signals and slots, for example, then those can be added to the 
>> language rather than using an external tool.
> 
> For curiosity I looked at the https://neogfx.org page. Among other 
> things it says: "C++ lambdas have made traditional signals and slots 
> redundant".
> 
> It also promises "modern C++20 design" and "no reliance on macro-based 
> code generation".
> 
> NeoGFX itself has a too restrictive license (GPL), but at least it 
> suggests that C++ nowadays is expressive enough to actually allow for 
> some kind of self-contained and concise GUI library.
> 
> 

I haven't looked at NeoGFX in any detail - a one-person GPL'ed PC gui 
library is not something I would find useful for my work, for a good 
many reasons.  (But good luck to the developer anyway.)

Certainly lambdas can significantly simplify a lot of event-style 
programming.

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

#121232

On Tue, 17 Dec 2024 17:30:18 +0100
David Brown <david.brown@hesbynett.no> wibbled:
>On 17/12/2024 17:02, Muttley@DastardlyHQ.org wrote:
>> Personally I'd go with Qt. Its mature and cross platform and does what 99%
>> of most people need.
>> 
>
>No, it doesn't come close to that.  It's a solid gui library with lots 
>of extra tools, and is useful to many people - but it's nothing remotely 
>like you suggest.
>
>It has a license that is totally unsuitable for standardisation.  I'm 
>not complaining about the license - the people that wrote the library 
>get to pick the license.  But a standard C++ gui library, if such a 
>thing is ever made, has to have a very liberal license - BSD/MIT at most.
>
>And Qt is hardly a lightweight choice either.

None of them are. If you want lightweight don't use a cross platform library.

>I think if there is ever going to be a standard gui library for C++, it 
>will be written specially for the purpose.  That has some big advantages 
>- if the designers decide they need extra language features for signals 
>and slots, for example, then those can be added to the language rather 
>than using an external tool.

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.

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

#121244

On 17/12/2024 17:53, Muttley@DastardlyHQ.org wrote:
> On Tue, 17 Dec 2024 17:30:18 +0100
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 17/12/2024 17:02, Muttley@DastardlyHQ.org wrote:
>>> Personally I'd go with Qt. Its mature and cross platform and does what 99%
>>> of most people need.
>>>
>>
>> No, it doesn't come close to that.  It's a solid gui library with lots
>> of extra tools, and is useful to many people - but it's nothing remotely
>> like you suggest.
>>
>> It has a license that is totally unsuitable for standardisation.  I'm
>> not complaining about the license - the people that wrote the library
>> get to pick the license.  But a standard C++ gui library, if such a
>> thing is ever made, has to have a very liberal license - BSD/MIT at most.
>>
>> And Qt is hardly a lightweight choice either.
> 
> None of them are. If you want lightweight don't use a cross platform library.

That's not true - FLTK comes to mind.  (I have not used it.)

Sometimes you want a heavyweight toolkit with lots of features, 
sometimes you want a lightweight toolkit.  And sometimes you want 
something completely different, such as an immediate mode gui toolkit. 
This is why a /standard/ C++ gui library makes little sense.

Look at other languages - Python has a "standard" gui library based on 
Tkinter, but there are a dozen other popular gui toolkits used with 
Python.  One size does not come close to fitting all for gui toolkits.

> 
>> I think if there is ever going to be a standard gui library for C++, it
>> will be written specially for the purpose.  That has some big advantages
>> - if the designers decide they need extra language features for signals
>> and slots, for example, then those can be added to the language rather
>> than using an external tool.
> 
> 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 
put C++11 as a minimum stepping point - C++ post-C++11 is a very 
different language from that of pre-C++11.  But if I were looking for a 
new, well-designed modern C++ gui library, I'd want to see concepts, 
std::format, ranges, and that the whole thing was organised in modules. 
That all means C++20.  It's worth upgrading your tools for those for 
something like a gui library.

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.

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

#121245

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).

>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.

>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. 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?

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web