Thread: Easy GUI and OOP utility?

Hello! I'm considering a utility to add easy GUI and OOP to C by syntatic sugar form them...

It would allow a kind of:

Code:

void showMes(){
notice "Thanks for choosing Hello World!";
}

void winDeath(){
close mywin;
}

int main(int argc, char **argv){

create button "Click me!", 10, 10, 15, 25, showMes() as mywin.but;
create window "Hello World", 300, 250, 25, 25 as mywin;

pointend mywin, winDeath();

returnctr;
}

This and some OO like C++:

Code:

#include <stdio.h>

class myclass{

int add(int a, int b){
return a+b;
}

}myclass;

int main(){
myclass myob;
int x;
x = myob.add(5,6);

printf("%d is answer!",x);
}

This code would be translated to plain C + GTK(if you are using GUI) and then compiled(as per instructions).
Do this have any commercial future or I'm just gonna waste my time??
Your views on it...

(I wouldn't tell name/link of this so to avoid adverting....)

So, ignoring the horrendous C-like-but-not-really-C syntax, what exactly differs this from just, say, using GTK or QT or whatever directly? Isn't it just a nice preprocessor wrapper to make the same calls as you would have to if you did that, and thus something anyone could throw into a .h file as preprocessor macros, e.g:

Code:

#define create_button(x, y, w, h, caption)   gtk_button_new(.....

(which would actually be do-able whereas trying to make your own "translator" to plain C and then trying to tie that into an existing C program where, for example, the button height might be dependent on some internal variable and the calculation thereof in C, is probably just asking for trouble).

If so, I don't see the point. Personally, I'm infinitely more keen for there to just be more lightweight, C-only GUI library alternatives that take the minimum of dependencies and overhead to show a window, buttons, scrollbar, etc., have nice interfaces that don't require their own event loops, and manipulate it on any OS (and, hell, even one that can just render to a bitmap). There are some around but they all have horrendous syntax, or miss one or more of those properties, or look rubbish (e.g. like a Borland DOS program's buttons).

Chances are, most people who *want* a nice GUI have already done what you suggest for themselves. I certainly doubt you could sell it at all. With any half-decent programmer and GUI library, it's just a preprocessor header file to make the syntactic "sugar" work as intended. The bulk of the work still has to be done by the GUI library, of which there are pitifully few lightweight and good ones that are cross-platform, etc.

Originally Posted by ehitam

This can't be directly implemented by using preprocessor directives.

I beg to differ. You seem to be assuming that a preprocessor directive can only contain one line of code. However, even ignoring that, it's still just a few wrapper functions in C, at worst. I don't think being a full parser that generates C is anywhere near a sensible alternative to just using a C library that has a nice API and/or create wrapper functions/classes that encompass the library you want. It's re-inventing the wheel for little benefit.

If you want to make a programming language, you have to realise that is possibly the most underestimated project you can attempt. It *will* turn into an absolute nightmare. Hell, even Google haven't had much success supplanting other languages with Go and they're at full stability with gcc frontends. Especially if, as you suggest, you want to take all the "difficult" bits out and simplify them for users. C is one of the most succinct languages for expressiveness - it doesn't have lots of fancy constructs and libraries, just the essentials. Thus, I don't see what you would achieve except to make it *more* obscure. The university course I did on Compilers & Interpreters in the final year of my degree, many moons ago, was quite possibly the most horrendous course I've ever sat through in my life - there is just so much stuff in the way of parsing grammar to get right that it was really quite stressful even on simple examples. I suspect you will run into the same problems even with a translation to C rather than a full language parser.

Hell, I find your syntax almost unparseable with your "as <varname>" etc. and no indication of exactly where boundaries lie between statements, parameters, naming, etc. You are going to spend your life writing a parser to handle all that (and I do hope that somewhere you have a record of your formal syntax because that "language" looks worse to me than C).

It's ambitious, and complex, and I think you translate that as therefore being something that will save others work and will be needed. I don't think I can agree on that. My life was changed noticeably when I discovered Visual Basic 3 and its simplified GUI programming - it honestly was and I churned out more programs on that than I ever had previously, because it had a wonderfully simple syntax. VB4 took it downhill and VB5 destroyed it by trying to be too clever and complex. I haven't used it since VB4. This is far from elegant, though, and I fear you're starting off at a point where you actually create more complexity than you ever save.

Honestly, get a small formal description of all the "commands" you want available and then sit down and write a small dialog / example program using them. Doesn't have to be anything too fancy, you don't need to have a working parser, just on paper. Then do these two things: 1) Go and try to replicate that in a similar way on, say, QT or GTK directly. 2) Hand it to a "beginner" and see how long it takes them to replicate the example given just a screenshot and the language description. If the first is quicker, you have a problem. If the 2nd takes longer than it would just to teach them to use the QT library, or any programming language with a GUI, you have a problem.

You also face the uphill struggle that almost all GUI's now are not programmatically created. They are designed in a forms designer and rarely does anyone see or manipulate the raw code (hell, even Windows resource files are obscure to the point of horridness).

Putting a few buttons on the screen is a job that programmers have been doing since the DOS days (before even Windows had any form of controls you could manipulate). The area is well catered for in the number of libraries to do so. Each has its restrictions. But even the Windows resource format is just a parseable set of data that you load and instantiate in your code, not a programmatic description in itself.

I think you will struggle to market this, not because you don't do a good job, or you don't put in a lot of hard work. I think you would struggle to market this because it's unnecessarily complex, somewhat ill-defined, a 2-pass method rather than just direct use of a library (which will give debugging problems for programmers), a nightmare to parse reliably (which means your development time is going to be HUGE), and the end result will be something comparable to that achievable by any competent programmer who can knock up a few wrapper functions. Beginner programmers are also not the best target market in the world - they are notoriously stingy because they don't *know* if they can do something, and if they wanted results they'd actually buy one of the many graphical languages aimed at them directly which wouldn't require any "code" whatsoever.

I wish you luck, but I think your skills would be put to better use somewhere where they can get better results.