Open source my OIOIC, a completely new object-oriented mechanism for the C.

[pervise.zhao]

I intend to originate a fully cross-platform, based entirely OIOIC, window graphical interface library project. Here is a first draft ( To download: Downloads - oic-wgi - Google Code ).

Project Name: WGI, (W)indow (G)raphical (I)nterface.

The diagram of Window Frame
Any window has an optional Window Frame. The Window Frame is composed of Icon, Caption, Title bar, Minimize button, Maximize button, Close, button, Vertical scroll, Horizontal scroll, Borderline. The following diagram:
http://a.cvimg.cn/UploadFile/UserFil...205b3ac93d.jpg


WGI Hierarchy Chart
1. CI：(C)haracter (I)nterface.
2. Chinterface：(Ch)aracter (interface).
3. GI：(G)raphical (I)nterface.
4. Grinterface：(Gr)aphical (interface).
5. WGI：(W)indow (G)raphical (I)nterface.
6. WGrinterface：(W)indow (Grinterface).
http://a.cvimg.cn/UploadFile/UserFil...8667d55762.jpg

[WingedPanther]

Have you ever used GTK?

[pervise.zhao]

Have you ever used GTK?

I have not used GTK.

[pervise.zhao]

Have you created any more complicated programs with it?

Let me try explaining my concerns in a more concrete way while I'm at it. Let's say I work for a company that has five programmers who are working on a suite of programs. Because of the type of work they do, and their specialties, the result is that three of the programmers work on specialized areas, and two work on general stuff. The result might be something as follows:
Programmer1 develops and maintains mathutils.c and mathutils.h
Programmer2 develops and maintains sqlutils.c and sqlutils.h
Programmer3 develops and maintains guiutils.c and guiutils.h

These three sets of files exist independently of each other, and the three programmers have essentially no awareness of what the other two are doing. Furthermore, programmers 4 & 5 have no awareness of the details of the above .c files, nor do they care. They work on:
Programmer4: service1.c, service2.c, service3.c, service4.c
Programmer5: app1.c, app2.c, app3.c, app4.c

The question becomes: if these programmers are using OIOIC, do they have to maintain a common OIOIC file for everything? If so, then won't service2.c get polluted with logic from service1.c, especially if service2.c doesn't use mathutils but service1 does?

If they are using seperate OIOIC files, one for each product, doesn't that suggest that Programmers1-3 need to update the OIOIC files for the products whenever they make a change to one of their utilities that affects OIOIC? Wouldn't that require them to be overly aware of what programmers4-5 are doing and potentially have to maintain each OIOIC file differently because of changes that have been made?

What if Programmer5 isn't interested in using OIOIC? How much awareness of it will be forced on him in order to use the utilities that are developed using it?

The reason I bring all these issues up is that I work for a company that has a similar structure of files (in Delphi). When one utility is updated, there is generally NO impact on the files that rely on it. Similarly, the above scenario in C++ would allow developers to have minimal awareness of what the others were doing. Anything that entails developers dealing with shared files is a potential issue. It represents a burden on the development process, and increased potential for people to damage other people's code.

How does OIOIC handle this?

It can be imagined that each OS has its own OIOIC files, on which all OIOIC softwares in the OS are based.

[WingedPanther]

I'm not worried about multiple OSs, but multiple applications. I envision something like the following to compile each program:
gcc service1.c mathutils.c -o service1.exe
gcc service2.c sqlutils.c -o service2.exe
gcc service3.c mathutils.c sqlutils.c -o service3.exe
gcc service4.c -o service4.exe
gcc app1.c guiutils.c mathutils.c -o app1.exe
gcc app2.c guiutils.c sqlutils.c -o app2.exe
gcc app3.c guiutils.c mathutils.c sqlutils.c -o app3.exe
gcc app4.c guiutils.c -o app4.exe

[pervise.zhao]

I'm not worried about multiple OSs, but multiple applications. I envision something like the following to compile each program:
gcc service1.c mathutils.c -o service1.exe
gcc service2.c sqlutils.c -o service2.exe
gcc service3.c mathutils.c sqlutils.c -o service3.exe
gcc service4.c -o service4.exe
gcc app1.c guiutils.c mathutils.c -o app1.exe
gcc app2.c guiutils.c sqlutils.c -o app2.exe
gcc app3.c guiutils.c mathutils.c sqlutils.c -o app3.exe
gcc app4.c guiutils.c -o app4.exe

For example, an application is divided into many modules. Each module needs OIOIC files. Each module is solely developed and compiled. Finally, link all modules to generate the application.

You are worried about:
In the development, if the programmer(s) of a module modified its OIOIC files, the application will be running in confusion?

My answer is:
If the OBJECT structure is changed, certainly in confusion. The most logical approach is: If a module developers have a good idea to optimize OIOIC files, MUST DO NOT monopolize it! It is wise to share it with other modules to ensure that all modules use the same and the best OIOIC files.

Therefore, to continue reasoning, all applications in an OS must use the OS's built-in OIOIC files. To continue reasoning, if OIOIC will be popular in the future, it should be a standard of the C at that time.

[WingedPanther]

Unfortunately, that means using OIOIC would be almost impossible in many situations.

Frequently, on module is developed completely independently of another module. Now, suppose I am developing mathutils as a third-party module, developed with OIOIC. I am probably NOT going to distribute the source code, just the compiled object files as a library and the necessary header files. The result would be my library contains a compiled version of OIOIC.c as part of the library.

If I distribute this to another developer that happens to also be using OIOIC, then there will be immediate problems using my library. The result is that, as a library developer, I could never use OIOIC because of the potential risk of incompatibilities.

[pervise.zhao]

Unfortunately, that means using OIOIC would be almost impossible in many situations.

Frequently, on module is developed completely independently of another module. Now, suppose I am developing mathutils as a third-party module, developed with OIOIC. I am probably NOT going to distribute the source code, just the compiled object files as a library and the necessary header files. The result would be my library contains a compiled version of OIOIC.c as part of the library.

If I distribute this to another developer that happens to also be using OIOIC, then there will be immediate problems using my library. The result is that, as a library developer, I could never use OIOIC because of the potential risk of incompatibilities.

You certainly do not have to distribute the source code of your module, and only distribute the module library and the necessary header file(s).

NO potential risk of incompatibilities! Another developer, who uses your module, must use the same version of OIOIC with your module.

Therefore, it is necessary to establish a specialized organization to maintain OIOIC. If you are interested in OIOIC, we can cooperate together to maintain OIOIC's growth.

[WingedPanther]

Unfortunately, I think C++ does a better job of modeling OOP programming, and has fewer potential problems with the issues I raised. Because C++ is very mature (30+ years old) and has huge amounts of practical coding behind it, the resources exist to handle whatever issues I may encounter.

C++ offers things like namespaces to allow me to write modules with essentially no chance of collisions with other people's code. C++ requires far less code to do what OIOIC offers. C++ has far fewer problems with cross-platform compilation.

All of this causes me to view C++ as a much better investment of my time than OIOIC. Finally, C++ was designed to be linkable to regular C code. That means that I can take something like GTK (written in C) and use it as part of a C++ program. Similarly, I can write a module in C++ that can be used by someone else's C program. C, C++, and Assembler can be intermixed to result in independent pieces of code that accomplish what is needed in the most practical way possible.

[pervise.zhao]

Unfortunately, I think C++ does a better job of modeling OOP programming, and has fewer potential problems with the issues I raised. Because C++ is very mature (30+ years old) and has huge amounts of practical coding behind it, the resources exist to handle whatever issues I may encounter.

C++ offers things like namespaces to allow me to write modules with essentially no chance of collisions with other people's code. C++ requires far less code to do what OIOIC offers. C++ has far fewer problems with cross-platform compilation.

All of this causes me to view C++ as a much better investment of my time than OIOIC. Finally, C++ was designed to be linkable to regular C code. That means that I can take something like GTK (written in C) and use it as part of a C++ program. Similarly, I can write a module in C++ that can be used by someone else's C program. C, C++, and Assembler can be intermixed to result in independent pieces of code that accomplish what is needed in the most practical way possible.

Your all worries are not in OIOIC, but many in C++.
The reason that I created OIOIC, is because I was TOO disappointed in the C++!
We will have to SLOWLY comprehend the beauty of OIOIC, as it appears.