Best GUI lib to use with Pelles?

[dizergin]

Nonsense. The whole Windows API is accessible to C, GUI-wise there is absolutely nothing you couldn't do in C. My personal editor's source is 16k lines, if that is possible in assembler, it certainly works also in C. Give me one example of a GUI feature that can't be implemented in C...

Nonsense that is what  you are making for me - "Give me one example of a GUI feature that can't be implemented in C..." - i told the another thing of! and very good example to illustrate my words  is... PellesC IDE itself.... as IDE it is not too complicated (by comparing with modern homemade ide's )... more over, the interface had not much of changings since v6... , but the last release still is shipped with  childish bugs.

[Bitbeisser]

And only once you got the gist on that one, then start programming for a GUI. That's a complete different issue all together, regardless of the OS. And regardless of what kind of library/framework you are using...

Ralf

Even so - C usage for GUI programming-POOR choice regardless any framework (exept some simple cases or very special requirements upon).

Well,...

Why are you then looking into programming with (Pelle's) C in the first place?
It's all a matter of what you are used to and what your goals/priorities are...

Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...

Ralf

[dizergin]

Why are you then looking into programming with (Pelle's) C in the first place?
It's all a matter of what you are used to and what your goals/priorities are...

Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...

Ralf

It is simple - Frankie   was the best at describing the situation:

If you want learn C just produce console programs.

I teach the first-year students  to basic algorithmisation (programming for beginners)

If you want learn Win programming use WinAPI, masking the more or less complex mechanisms that are behind using a surrogate is not effective: What you need to learn is how things works, how messages rotates, how they are handled, etc. 

So do my colleagies after me (the students  specialization is system programming).
More over...I long time worked at creation of the complex GUI apps.. though my interests shift into another topics at present ,i daresay know what i am talking about. Concerning  my comment adressed to you - I just state very obvious (for me) thing- ANY bundle consisted from LOW level language+framework   will concede (except some cases) to advanced one (consisted from HIGH level language +framework). It is due to the nature of the low level language (like C),   do not mention of the C's peculiar design issues yet.
 

[Cnoob]

Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...

Ralf

Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?

[Bitbeisser]

Windows GUI programming has been done for decades in C, so if that is/was a poor choice, it still got us where we are today. If you want to do native Windows, the using C and the standard Windows API is a valid choice. If you want to do cross-platform GUI development, the GTK+ is one of the choices. If that in each and every case is a better choice, that's up to everyone for him/her self...

Ralf

Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?

Popularity doesn't have anything to do with being useful. A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her. While at the bottom line, it doesn't really bring anything new to the table that is really providing a benefit...

Ralf

[frankie]

A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her.

Ralf

Ralf what''s really nice is that old and new languages are written in 'C' 
Yes Os's, languages, base utilities and everything that have to be fast and efficient are written in 'C' ! 
VB, C#, etc, that are very popular this days, are usefull because they lets you write your apps much faster, but not always more efficiently (please note the 'not always' before complain...).
Last the 'managed code' that has a lot of benefits (the intermediary language, the common language runtime, etc..,), has the biggest benefit of all: you cannot make thinks that are not allowed by the managed code platform: means that who created the platform can be lazy and simply block you before you get out of the path. But if a hole will ever be exposed ...

[dizergin]

Have to agree.
If it was completely wrong and outrageous to use C for GUI apps, then why the availability and popularity of things like GTK+ ?

You put the thing in your head for reason unknown for me... i tell another thing of

[dizergin]

Popularity doesn't have anything to do with being useful. A lot of projects (programming languages included) these days come to life and are being more or less promoted just because someone thinks (s)he can do things better than everyone before him/her. While at the bottom line, it doesn't really bring anything new to the table that is really providing a benefit...

Ralf

your notion about "benefit" looks rather onelegged and outdated.

[dizergin]

Ralf what''s really nice is that old and new languages are written in 'C' 
Yes Os's, languages, base utilities and everything that have to be fast and efficient are written in 'C' ! 
VB, C#, etc, that are very popular this days, are usefull because they lets you write your apps much faster, but not always more efficiently (please note the 'not always' before complain...).
Last the 'managed code' that has a lot of benefits (the intermediary language, the common language runtime, etc..,), has the biggest benefit of all: you cannot make thinks that are not allowed by the managed code platform: means that who created the platform can be lazy and simply block you before you get out of the path. But if a hole will ever be exposed ...

and what?      
My reasons are very simple - just try to bite them:
Even  if you use most advanced framework there will be some work connected with interactions between the interface elements (more complicated interfaces result in more works of the such kind). That works are HIGH LEVEL works. and C is not well suited for.... (weaker typization, poor compiler messages, missed calling by reference, side effects, akward syntax, poor modularity, poor  data  encapsulation...).
Does not mention of  the "efficiency" notion,  wich changed since the time where typical apps user computer  had 8mb RAM and 2gb HDD space ruled by 200 mhz CPU... ('twas just 20 years ago)

[frankie]

My reasons are very simple - just try to bite them:
Even  if you use most advanced framework there will be some work connected with interactions between the interface elements (more complicated interfaces result in more works of the such kind). That works are HIGH LEVEL works. and C is not well suited for.... (weaker typization, poor compiler messages, missed calling by reference, side effects, akward syntax, poor modularity, poor  data  encapsulation...).

No reason to bite. 
C exists to create such complex systems 

Does not mention of  the "efficiency" notion,  wich changed since the time where typical apps user computer  had 8mb RAM and 2gb HDD space ruled by 200 mhz CPU... ('twas just 20 years ago)

20 years ago, HDD were at most 400Mb, and Athlon CPU was running 220MHz the software was not less efficient than now.
Then they understood that a GB HDD and GHz CPU can produce a lot of ... sprites, images and special effects (Oh yes than was necessary to have GPU's for 3D Hw acceleration...).
 

[dizergin]

No reason to bite. 
C exists to create such complex systems 

  'twas 20 years before , now  just very simple-minded individuals will use C for end-user apps with rich interface without VERY serios reasons upon   
 The example of the such REALLY BAD decision  - Pelles C IDE. I wonder if there will be time when it will shrugg off its childish  bugs 
Frankie, we really speak about quite different things.. 

20 years ago, HDD were at most 400Mb, and Athlon CPU was running 220MHz the software was not less efficient than now.
Then they understood that a GB HDD and GHz CPU can produce a lot of ... sprites, images and special effects (Oh yes than was necessary to have GPU's for 3D Hw acceleration...).
 

  i spoke of typical  Pentium I (i had such), but you forget to say that at  present there is almost no need to use C for such tasks (exept some cases), moreover advanced frameworks itself prefer to make in high-level languages (Qt for example,and then make bindings to C)

[frankie]

was 20 years before , now  just very simple-minded individuals will use C for end-user apps with rich interface without VERY serios reasons upon   

Be able to make advanced engineered products using trivial tools require superior capabilities, this seems a little bit contraddicting 
But nobody is saying that could be more 'productive' (not 'efficient') to write end-user apps using other more appropriate GUI tools..

The example of the such REALLY BAD decision  - Pelles C IDE. I wonder if there will be time when it will shrugg off its childish  bugs 
Frankie, we really speak about quite different things.. 

Still can't understand why you waste your time about such a defective product... 
PellesC is a good non commercial product, so it is what it is... When Pelle has time he improve something...
You can like it or not, but it is so. 

i spoke of typical  Pentium I (i had such), but you forget to say that at  present there is almost no need to use C for such tasks (exept some cases), moreover advanced frameworks itself prefer to make in high-level languages (Qt for example,and then make bindings to C)

But we are incurably good old time lovers .... 

[dizergin]

Be able to make advanced engineered products using trivial tools require superior capabilities, this seems a little bit contraddicting 
But nobody is saying that could be more 'productive' (not 'efficient') to write end-user apps using other more appropriate GUI tools..

it may look  like an arguments  for cnoob...  but i were quite aware  that old Fortran (for the instance) was BOTH more efficient and productive for numerical calculations even 30 years ago. And even were aware of some reasons for  it . so let us leave such stories for a childs or newbies...

Still can't understand why you waste your time about such a defective product... 
PellesC is a good non commercial product, so it is what it is... When Pelle has time he improve something...
You can like it or not, but it is so. 

For it suits well for my student's EDUCATIONAL tasks (not of MINE) as I see them ... yet I deliberatory took into the account many factors (and trying competative ide's) before making the final decision... - wich is none of the obvious...
yet  I told of the bags in Pelles C IDE (childish ones, REAL ones) and still I'm wondering  what are you talking about... 

But we are incurably good old time lovers .... 

Agreed but I am still believing that the cnoob is worthу to get the just and impartial answer 

[frankie]

I am still believing that the cnoob is worthу to get the just and impartial answer 

I fully agree, I really didn't intended to influence anyone  , and this discussion for me was between serious and lazy, and, to be honest, maybe I would not even partecipate should I not have been mentioned. 
My opinion is that mentioned earlier (and that you quoted), and remain the same. 

[henrin]

For a SUDOKU solver, I once used Python with TK GUI. It worked well; the exe package was pretty fat but OK. This changed when I wanted to add a grid generator - ah! ah!

Performance was terrible. Some members think that performance and efficiency are no more a problem - it is true when you use a computer as a display or a low thtoughput device, but if you use it as a calculator, it may be very different.

For my grid generator, I had to add a C DLL to my Python...

And now, I agree with most members here. With C, we have a chance of plenty of powerfull libaries (Intel IPP, libharu,...) - and the windows API should be the right choice for the GUI, but it is not. The many reasons come from Microsoft. Everything is possible, but have you ever tried to use a blue button? Too much effort is required: Microsoft do not like developpers.

So, I decided to add to the Win32(64) API a simple layer with the following goals:
 - hide most of the stuff
 - provide a structured architecture (thanks to callback functions)
 - provide an object architecture (inheritance)
 - provide scalability (zooming)
 - do not manage the application data: let the application programmer do that
 - do not draw simple things: let the application programmer do that
 - keep everything possible

It is called SGL and within few weeks I hope it will be available.
An example is already posted here http://forum.pellesc.de/index.php?topic=6656.0 may 19th reply.