Gui for c application

>Nifty. Several points though.

>correct me if I'm wrong, but isn't that C++?

Yes of course but the C++ class is just a wrapper for the C functions provided by the operating systems. You could do that in C also. The nice thing is that the class works on Unix like systems, Windows and OpenVMS.

>I guess the mutex is a good idea, but
>does that not create a chance of
>deadlock?
>What happens if a program
>terminates abnormally right on the
>memcpy line in write, thus not executing
>myunlock?

In theory yes. In practice no. If it would happen
it would happen first directly after program startup. Once the program is running i see no reason why these shared memory addresses should become invalid.

>it takes a pretty decent programmer with
>some experience to understand all the
>nuances of this.

The operating system functions that are used within the methods of rlSharedMemory are very old and hard to use. But the user does not need to care about this (He could review it for intrest)
instead he can use our simple and comfortable class.

Of course it would be nice to have a basic knowledge about parallel processes, mutex and semaphores.
 
Separate control and HMI applications is a very conventional approach. This is how most HMI systems work. The only question people here are debating is the best way to implement it.

As for the speed of a web interface, the HMI is separate from your control application so the speed of the HMI is not directly related to the speed of your control code.

If you are concerned about the speed of the graphics update, that will depend on how graphics intensive your HMI screens are. The standard demo HMI that I include with MBLogic takes about 3 percent CPU. The server load is approximately 0.5 percent for HMIServer (when handling just the HMI load). If you want to run continuous smooth graphical animations (as opposed to just changing when the data has changed), then the load will depend on whether you have hardware graphics acceleration. If that's a concern, then avoid the smooth animations (the only thing that uses smooth animations in the demo is the flashing light where the dot "grows" from the centre to fill the lens).

There are several points to keep in mind here. The first is that I'm not talking about simple static pages like you see on Control.com (or 99% of other web sites for that matter). That sort of web page creates the page on the server, and your browser just downloads and displays it until you load a new page.

The sort of web interface that I'm talking about runs a program which reads data from the control applications and uses the results to update the screen. It's the same principles as you would use for an HMI that was written in C, except you are writing it in Javascript and using HTML, CSS, and SVG for the screen design. The web page gets loaded *once*, and after that a Javascript library polls the server for data (not new web pages) and uses that data to update the display.

The second point is that if you happen to like the Javascript libraries, SVG widgets, web page templates, etc. that I wrote, but you don't want to use the MBLogic or HMIServer server programs, you can substitute your own server. The protocol that I used is fairly simple and fully documented. The HMI web pages won't care if you substitute your own server. You can build your own HMI server into your control program, or alternatively run a separate server as another process (with your control program as a client to that server). I don't know much about your application or the market you are addressing, so I can't say what the best approach is here.

The third point is that as well as an application specific HMI, you are going to want some sort of control and management interface that tells you if the system is up and running, what it's status is, whether you have any communication errors, etc. You will also want to be able to send commands to the control application to shut down, reload the configuration, etc. A web interface is very handy for this as well.

The fourth and final point is that this is not necessarily an either/or situation. You can use interface and control protocols that will work with either a web application or a conventional C client. As long as either type can use the same protocol, the control program itself won't care (or know) what is at the other end. You could start with an HMI written in C, and then add a web based client later. Your C HMI could open a plain socket with the control program server and just send JSON based messages back and forth. If you want to add a web interface later, you can use another socket to serve HTTP messages (these would have the same JSON payload, but would add the HTTP headers in front). Since the basic message format would be the same for each method, the change would have less impact on your control program.

I will re-iterate a point though. I don't know your application. I can't say for sure what the best method is. I can give you some pros and cons, but I'm not standing in your shoes so I can't say for sure what the best method is. However, you emphasized having the maximum flexibility and portability, and for an HMI application the best solution for that is a web interface. You're going to have to learn something about web pages and Javascript to really take advantage of that, but they're not that difficult.
 
J

James Ingraham

@Curt: "A database, this library, that library, Java, a whole scada system, a general class messaging system? The only thing not suggested was kitchen sink 2.1 :^)"

You know, that was sort of my point. It's easy to say "I'm gonna write a quick C program!" and then you find out that the problem requires Kitchen Sink version 4.3 (release 12). A typical palletizing application for us takes between 600-800 lines of code. But I've got 20,000 lines worth of libraries and daemons to back that up, which is already on top of a full-blown OS with a message passing framework. I'm not counting the GUI here. Granted, that 20,000 lines has a LOT of stuff that you won't need on every project. Bottom line remains; this isn't as easy at it looks.

"That implies sockets."

Here's a possibility of a naive implementation of using sockets to create a tag database. We want two applications, the control program and the GUI. So control listens, then waits for a connection from the GUI... and we're already fried, because we're WAITING. Which we don't want. So now we either have to learn about threads, or else we run a data server program. Let's say we run a data server program. The control program does a read() and gets the value of tag "x," which for argument's sake is 7. A user clicks a button on the HMI and sets x to 3. The control program adds one to "x" and writes it back. x is now 8, when it ought to be 3 (or conceivably 4). So now we have to learn about locking... and it just keeps snowballing.

"Of course, I'd use NCurses and Linux on both halves and less than 10 pages of code."

I realize that you're semi-joking. I am not devoid of humor. (That was a joke.) And I bet if YOU (specifically) did it it would turn out fine. But for someone just getting their toes wet in the realm of C and Inter-Process Communication (and threading and GUIs and ...) it's not going to go well.

Finally, I have to defend myself a little from the "Cray" snap. These days I don't think Linux (with X, window manger, etc.), APR, and GTK+ are particularly resource intensive. I also mentioned Redis; the download for Redis is ~500K, doesn't require SQL, and links natively to C. My total solution would run just fine on my phone.

I've never actually written a GTK+ program or used Redis. But coming from a *NIX background, I find it impossible to write even a "Hello, world!" app on Windows. So I use APR now all the time. It handles really simple stuff like "sleep" and really complicated stuff like atomic operations. Unless I was writing something for REALLY small hardware, and thus throwing portability out the window any way, I would ALWAYS use APR. In my opinion it should be taught alongside the C Standard Library.

-James Ingraham
Sage Automation, Inc.
 
C
> @Curt: "A database, this library, that library, Java, a whole scada system, a general class messaging system? The only thing not suggested was kitchen sink 2.1 :^)" <

> You know, that was sort of my point. It's easy to say "I'm gonna write a quick C program!" and then you find out that the problem requires Kitchen Sink version 4.3 (release 12). A typical palletizing application for us takes between 600-800 lines of code. But I've got 20,000 lines worth of libraries and daemons to back that up, which is already on top of a full-blown OS with a message passing framework. I'm not counting the GUI here. Granted, that 20,000 lines has a LOT of stuff that you won't need on every project. Bottom line remains; this isn't as easy at it looks. <

Actually, my point from the systems programmer view was more subtle than that. Linux and *NIX in general is extremely powerful for these kinds of tasks, _iff_ you do them the #NIX way. I will use Linux as the example because it is probably the most full featured and definitely the easiest, because you have source and you can, for instance, change a driver, or use busybox, or any of the hundreds of other things tailored for this type of work. If you are a C programmer, on Linux, the world is your oyster. If you are willing to work _with_ the OS and use what's already there, you can produce something that works with a tiny fraction of the work for other OSs or the somewhat mythical "portable application". Once I have a card and a driver, a page or two of code would do the actual work of reading the card and scaling the data, etc. Another page or two with NCurses would produce a local display for verification and well... local display. A pipe to a two page Python program would give you the simple GUI the OP mentioned. A cron script could read a status register (shm) and dial the modem and send the appropriate message. VNC would give you remote access to the GUI and ssh could give you a remote terminal for the NCurses display. I haven't bought anything or added anything and I've written very little code. Finding a suitable, ready to go, small webserver from the hundreds of embedded projects wouldn't be hard either and if you don't like the shm complexity, you could centralize the data on an ordinary file in ramdisk (for speed) because "everything is a file" in Linux. And making the system two way isn't much of a stretch.

Will it win any software awards? No, but I know it will work because I have all kinds of stuff like this running. Witness my two page PLC. Is it mass marketable and will it make me a million dollars? No, but I solved _this_ problem fast and easy. What more esoteric programmers tend to forget, is that we are in the _one off problem solving_ business. You've done enough *NIX work to judge that, yes I can, very likely, do it this way and it will work, even just being a Bonehead C (tm.) programmer. People don't understand why I'm so high on Linux in automation, this is it. Small, fast, easy, extremely cost effective and robust solutions. All you have to do is be a C hacker and _use what the system offers_. Now, compare this to the other proposals and you'll see why I think they're kinda overkill:^) And the amazing part, even to me, is that it stands a very good chance of being cross platform as long as the bottom end runs on Linux. That's why I applaud the OP's decision to learn C and not get sucked into the huge bloated vortex of today's software. Hence the contrast between the systems programmer approach and the applications programmer approach. My approach is nothing special, it's just what Linux programmers do on Linux because that's what all that stuff is there for.

> "That implies sockets."

> Here's a possibility of a naive implementation of using sockets to create a tag database. We want two applications, the control program and the GUI. So control listens, then waits for a connection from the GUI... and we're already fried, because we're WAITING. Which we don't want. So now we either have to learn about threads, or else we run a data server program. Let's say we run a data server program. The control program does a read() and gets the value of tag "x," which for argument's sake is 7. A user clicks a button on the HMI and sets x to 3. The control program adds one to "x" and writes it back. x is now 8, when it ought to be 3 (or conceivably 4). So now we have to learn about locking... and it just keeps snowballing. <

> "Of course, I'd use NCurses and Linux on both halves and less than 10 pages of code." <

> I realize that you're semi-joking. I am not devoid of humor. (That was a joke.) And I bet if YOU (specifically) did it it would turn out fine. But for someone just getting their toes wet in the realm of C and Inter-Process Communication (and threading and GUIs and ...) it's not going to go well. <

But, only semi-joking:^).

> Finally, I have to defend myself a little from the "Cray" snap. These days I don't think Linux (with X, window manger, etc.), APR, and GTK+ are particularly resource intensive. I also mentioned Redis; the download for Redis is ~500K, doesn't require SQL, and links natively to C. My total solution would run just fine on my phone. <

Actually, an embedded type board would probably be an excellent way of doing this. Many have the needed analog and digital I/O on board and the drivers in the tree. But a PC would be much easier for the first pass.

> I've never actually written a GTK+ program or used Redis. But coming from a *NIX background, I find it impossible to write even a "Hello, world!" app on Windows. So I use APR now all the time. It handles really simple stuff like "sleep" and really complicated stuff like atomic operations. Unless I was writing something for REALLY small hardware, and thus throwing portability out the window any way, I would ALWAYS use APR. In my opinion it should be taught alongside the C Standard Library. <

Me neither on the GTK+ or Redis, but again, those are more at the application side.

Regards
cww
 
>I also
>mentioned Redis; the download for Redis
>is ~500K, doesn't require SQL, and links
>natively to C. My total solution would
>run just fine on my phone.

I haven't used Redis either, but I understand it to be more or less similar to Memcached but also has disk based journalled persistence. Since you wouldn't need (or want) that for this sort of application, it might be easier to just use Memcached rather than using Redis and then figuring out how to turn off the journalling. Both Redis and Memcached are in the Debian (and Ubuntu) repositories, so installation should be very simple if you're using Linux.

On another note, I'm not going to state that either this project or your (James Ingraham's) own applications are suitable applications for Python (perhaps they are, perhaps they aren't), but if you have an application that you would like to use Python for, then you should have a close look at Twisted (http://twistedmatrix.com/trac/). The initial learning curve is a bit steep, but it's an application framework that makes otherwise difficult things possible without herds of threads, processes, locks, etc. I'm using it for MBLogic and I'm doing the following with it all in one program:

1) A Modbus/TCP server.
2) Multiple (unlimited) Modbus/TCP clients.
3) A web based HMI protocol server.
4) Another HMI protocol server with read-only access.
5) An ERP protocol server.
6) A soft logic system (executes a PLC program on a regular scan).
7) A web based status and management system that lets you do live monitoring, management, configuration editing, etc.
8) A database to log alarms and events (SQLite in this case).
9) Alarm and event history query.
10) RSS feed server (for monitoring events).
11) A web server for user generated documentation.
12) Etc.

That's all in one program sharing a common data table, with no locks or threads (other than any that are buried in system libraries) or IPC to deal with. You can also use GTK+ with Twisted, but I haven't tried that. I've tested the Modbus/TCP server with 100+ incoming client connections, and the Modbus/TCP clients with 100+ outgoing connections.

Twisted has lots of other features that I haven't used yet, including protocols for:
1) SSH.
2) SMTP, IMAP, POP3 (e-mail).
3) DNS.
4) Instant messaging (AIM, Jabber, XMPP, etc.).
5) Connectors for most popular databases.
6) NNTP.
7) FTP.
8) Straight sockets (this is how I'm implementing Modbus/TCP).
9) Lots more.
 
J

James Ingraham

@M Griffin "...it might be easier to just use Memcached..."

I KNEW somebody would argue about the database choice. :) I picked Redis more or less at random out of the choices of in-memory NoSQL databases. I did actually consider Memcached, but picked Redis since Memcached is targeted at distributed systems, and I figured we were working on a smaller scale. MonetDB I mentioned as a more traditional database, but for more real-time performance than the VASTLY more common MySQL.

"...if you have an application that you would like to use Python for..."

I have no problem with Python. However, I don't KNOW Python, so for me that's a barrier. We could debate the merits of various languages endlessly. (Actually, I'd enjoy that.) But the original question was about C, and I feel I can speak to that with some experience. So I'm glad you're here to bring up the Python points.

"...have a close look at Twisted (http://twistedmatrix.com/trac/)..."

I may do that one of these days. I'd also like to take a closer look at MBLogic. There's only so many hours in the day, though.

-James Ingraham
Sage Automation, Inc.
 
J

James Ingraham

@Curt: "Linux and *NIX in general is extremely powerful for these kinds of tasks, _iff_ you do them the #NIX way."

No argument here.

"...you can produce something that works with a tiny fraction of the work for other OSs or the somewhat mythical "portable application"..."

Here I'll only slightly disagree. Certainly, compared to Windows or a truly portable app, writing this type of program for Linux is a lot easier. But QNX is easier still. And VxWorks has some advantages, too. You can make Linux REALLY small, but doing so takes some knowledge and work. Installing Ubuntu is trivial, but now you've got a much bigger footprint than you theoretically need.

BTW, after chastising us for throwing everything but the kitchen sink at the problem, you've added NCurses, Python, VNC, and ssh. And by implication, Python is going to require some sort of GUI. So I don't see where your solution is any smaller or less complicated than mine.

"I haven't bought anything or added anything and I've written very little code."

I also proposed a no-cost solution. And the whole reason I mentioned certain libraries was to minimize the custom code.

"What more esoteric programmers tend to forget, is that we are in the _one off problem solving_ business."

This is a very good point. I have, indeed, been focused on creating a re-usable framework for solving applications. That would necessarily make my solutions larger and more complex. If you're only going to do this once, you really could strip it down to its most basic components.

"All you have to do is be a C hacker and _use what the system offers_."

This is where I think we most diverge. IMHO, having two processes talk is a very advanced C topic. Sure, sure, sockets are trivially easy to implement. But usually those trivial implementations are either to solve trivial problems, or they're talking to something that has been designed by someone who really knows what they're doing. Race conditions, deadlock, liveness, etc. require a very deep understanding. Witness all the articles recently about how hard it is to program modern multi-core chips in a way that is actually useful.

"Now, compare this to the other proposals and you'll see why I think they're kinda overkill"

Again, I don't see where your solution was any less "overkill" than mine. Heck, you even proposed a two-language solution!

I do think our arguments are pretty close in concept. Mainly, I'm a little more pessimistic.

-James Ingraham
Sage Automation, Inc.
 
Because
- sockets
- threads
- mutex
- semphore
- serial ports
- time
- shared memory
- mailbox
- PLC driver
...

are slightly different on different operating systems. i have written this library:
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.html

The library works on *NIX, Windows and OpenVMS

It encapsulates all these differences and makes me portable.
The GUI is also postable because of Qt.
Also databases are portable because of Qt.

As curt wuollet said:
> All you have to do is be a C hacker and _use what the system offers_
<snip>
> That's why I applaud the OP's decision to learn C and not get
> sucked into the huge bloated vortex of today's software.

You are completely right.
 
In reply to James Ingraham: I just installed and tested a quick benchmark with both Redis and Memcached. In each case I wrote a short Python program and then created 1000 key-value pairs in the database, and then timed how long it would take to read them back 100 times (in other words, read 100,000 key-value pairs one at a time).

The times were quite close, with Memcached being marginally faster, but when looking at "top", it was obvious that the Memcached server was taking a smaller proportion of the CPU time than Redis was. In both cases however, it was my client which was taking the majority of the CPU time (this was tested on a single core computer). I would say that overall, Memcached was faster than Redis (in this particular case), but not by a large margin.

Both databases have very similar interfaces. I was able to modify the Redis benchmark program to use Memcached by just changing the module import statement and the object initialisation statement.

On a fairly slow PC, I was reading approximately 10,000 key-value pairs per second. That's actually pretty good performance, considering that it's doing this one element at a time. A more efficient client could improve on that, but let's work with the 10,000 updates per second number. That's an average of 100 microseconds per transaction when running over localhost. That's when doing one key-value pair at a time.

Redis also has commands for reading and writing multiple key-value pairs at a time, so it may have an advantage over Memcached in some cases as I would expect that a transaction involving multiple key-value pairs would be much faster than doing an update using multiple single updates. I ran a slightly different test to check this by setting 2000 key-value pairs and then reading them back 2000 values at a time. In this case the performance was 25,000 key-value pairs per second, and the bottleneck here was clearly the (very simple) client, so the actual database is capable of going much faster than this (I used 2000 key-value pairs, as that happens to also be the maximum number of coils you can read with one command using Modbus).

At this point you're asking yourself why I'm going on about this. The discussion of Redis and Memcached set off a rather interesting train of thought for me which I will explain here. Let's call database 'keys' 'tags' and then consider the following:

1) We have an in-memory key-value (tag-value) database.

2) We can connect to it with large numbers of clients.

3) These clients can communicate with the database using the tag (key) names.

4) Each client can be a simple program running in it's own process.

5) A client can be anything that wants to read or write a 'tag'.

This sounds an awful lot like the core of a tag based soft logic or SCADA system. Let's imagine we have the following:

1) The Redis database could be initialised with a set of tag names.

2) A system management server would be started up.

3) The system management server would read in a set of configuration
files.

4) Based on the configuration, it would fork off a series of child processes.

5) Each child process would be passed it's configuration as part of its parameters.

6) Each child process would connect to the Redis server.

7) The child processes could be anything - a communications (e.g. Modbus/TCP) server, clients (e.g. Modbus/TCP), HMI server, soft logic execution servers, etc.

8) The child processes could be controlled from the management server via a separate command channel (possibly DBus) and made to stop, restart, report on progress etc.

9) Child processes could be written in virtually any language (the Redis web site lists client bindings for 22 different languages).

10) Each child could run on its own time schedule, possibly even taking advantage of real-time schedulers.

11) The system would be very, very, scalable, and able to take advantage of all the hardware you could throw at it. A four socket motherboard with quad core CPUs? If you need that, the system should be able to make use of it if you can split up the tasks. You could even distribute the processing over multiple computers.

12) The Redis memory persistence features database could be used to store tag values to disk so you can recover the program state after a restart.

13) Redis will do master-slave replication, so you can set it up for redundancy or distributed operation.

14) It's very expandable, in that you can add more child processes to support additional protocols or features.

15) The tags (keys) would be the native system tag names which each child would use, so there's no need to come up with a physical address to tag name mapping system. Each child would handle that as would be appropriate.

16) The values can be anything, so again, you're not restricted by data type (although the child processes would need to know how to handle them).

17) Each child process can be stopped and restarted independently, so as long as you are keeping the important parts of the state in the database, you can change, reconfigure, and upgrade the child processes while the system is running.

This is a very interesting idea. The key points would be:

a) The key-value store in-memory database as the centre of the system as a tag-based data store.

b) Small, simple, independent clients, with each one doing a single task.

c) Use a separate command channel (possibly DBus) to monitor and control the clients.

d) A system management server to start up and control the clients. This would use a web based control interface for user interaction.

I don't have time to pursue this at the moment, but it's a very interesting idea.
 
C
>> @Curt: "Linux and *NIX in general is extremely powerful for these kinds of tasks, _iff_ you do them the #NIX way." <<

> No argument here.

>> "...you can produce something that works with a tiny fraction of the work for other OSs or the somewhat mythical "portable application"..." <<

> Here I'll only slightly disagree. Certainly, compared to Windows or a truly portable app, writing this type of program for Linux is a lot easier. But QNX is easier still. And VxWorks has some advantages, too. You can make Linux REALLY small, but doing so takes some knowledge and work. Installing Ubuntu is trivial, but now you've got a much bigger footprint than you theoretically need. <

You don't have to know much to have a really small Linux. That's the beauty of it. The upside of having hundreds of distributions is that you can find one for nearly any purpose and embedded is where all the action is. Angstrom would be fine, but Ubuntu does fit on a BeagleBoard. I don't think you can self-host on there but I have seen it running.

> BTW, after chastising us for throwing everything but the kitchen sink at the problem, you've added NCurses, Python, VNC, and ssh. And by implication, Python is going to require some sort of GUI. So I don't see where your solution is any smaller or less complicated than mine. <

You _do_ recall that I said I'd do it with NCurses:^) That's not anything like A Java engine. Actually, I would probably do it without any display code on the bottom half. And yes, I am a little ashamed to defer to an interpreted language but overall Python might be smaller and better than some of the C solutions with all the dependencies. GUIs are simply hugely expensive, it's just a matter of degrees. Any GUI generally means a huge footprint relative to the task at hand.

>> "I haven't bought anything or added anything and I've written very little code." <<

> I also proposed a no-cost solution. And the whole reason I mentioned certain libraries was to minimize the custom code. <

>> "What more esoteric programmers tend to forget, is that we are in the _one off problem solving_ business." <<

> This is a very good point. I have, indeed, been focused on creating a re-usable framework for solving applications. That would necessarily make my solutions larger and more complex. If you're only going to do this once, you really could strip it down to its most basic components. <

That, I think, is the major difference in our viewpoints. Much of the difference relates to the difference between solving _this_ problem and a general class solution for problems like this. See below.


>> "All you have to do is be a C hacker and _use what the system offers_." <<

> This is where I think we most diverge. IMHO, having two processes talk is a very advanced C topic. Sure, sure, sockets are trivially easy to implement. But usually those trivial implementations are either to solve trivial problems, or they're talking to something that has been designed by someone who really knows what they're doing. Race conditions, deadlock, liveness, etc. require a very deep understanding. Witness all the articles recently about how hard it is to program modern multi-core chips in a way that is actually useful. <

Ah, but consider the difference between connecting two programs that you have written to communicate with each other, and the issues of serving multiple clients and the whole business of tagging your data and on and on. If you treat a socket or a pipe as a simple conduit, with the format understood, much of the oft discussed complexity falls away. It's really stylistic, using these mechanisms for what they are VS making them a generic messaging service.

>> "Now, compare this to the other proposals and you'll see why I think they're kinda overkill" <<

> Again, I don't see where your solution was any less "overkill" than mine. Heck, you even proposed a two-language solution! <

I suppose it's a matter of perspective. These are parts of nearly any Linux distribution except for Python which is on most distributions. Although, I suppose some will be omitting NCurses to discourage that nasty command line typing that seems to be the bane of GUI users.

> I do think our arguments are pretty close in concept. Mainly, I'm a little more pessimistic. <

And I fail at describing the goodness and beauty of *NIX used as intended. The appreciation is, I suppose, anachronistic in a point and click world, but the power of stringing existing things together to solve the problem at hand is well suited for the ad hoc automation world. It's a little like using a prototyping package, only once you've got something to show, you're done.

Even those who hate the whole genre would become fans if they were to learn enough to solve a few problems with it. Even many of the Linux "greatest hits" go far because they stand on the shoulders of giants and are collections of existing utilities under the facade. And grasping the ethos is the key to awesome power. Too few venture there. Even many who use Linux don't get it. They try instead to use it like Windows. A pity.

Regards
cww
 
It should just be noted that the database approach for shared memory or "tags" is not portable to realtime systems unless you can live with your variable access at a lower priority than your machine control threads. (Unless said database was RTOS compatible....)

KEJR
 
J

James Ingraham

@M Griffin: I had a very similar thought process, although not quite as well-thought out as yours. Thanks for the hard numbers; they're quite interesting.

@KEJR: Well, like we've said before, there's real-time and then there's "real-time." An in-memory database designed for high-throughput will probably be pretty good in most cases. M Griffin is guessing 100us look-ups. Not bad. There are some apps that can't handle that, or can't handle whatever jitter might be in there, but it would be perfectly sufficient for a wide range of applications.

-James Ingraham
Sage Automation, Inc.
 
I have a program in c language, may I know the easier way to create GUI in quick? Thanks a lot ya..
I just a beginner in C language and have no knowledge on GUI.=(
 
J

James Ingraham

(a) This probably isn't the best place to ask this question. There are more appropriate forums with people who are more directly involved in such things.

(b) You haven't given us a lot of information, like what kind of operating system or hardware you're using.

(c) Having said all that, the obvious choice is GTK+, although it's a little tricky on Windows. You could also look at IUP, though I don't know much about it. There's even wxC, although that doesn't look like an easy option. For straight C, GTK+ is one of the only well-known, well-supported, well-documented, robust, multi-platform GUI libraries out there.

(d) http://en.wikipedia.org/wiki/List_of_widget_toolkits

Good luck.

-James Ingraham
Sage Automation, Inc.
 
K

Ken Emmons Jr.

These aren't all pure C, but the following recommendations are either C++ or C#.

GTK# using monodevelop is a good choice for cross compatibility apps. It's a little confusing because it wraps the GTK+ C libraries into .NET, but most of the time the problems are missing documentation. I've had good luck with this library on linux/windows cross compatibility projects. If you need high performance (i.e. not JIT compiled .NET apps) and cross compatibility I'd look at QT. I've not used QT but it seems to be a powerful well defined system.

If you just want to write some basic GUI and run on windows, I'd recommend windows forms with C#. It'll leverage some of your C experience.

I guess of all the above recommendations the QT approach is the purest to C. I didn't mention GTK+ for C because James Ingraham already did.

KEJR
 
C

Curt Wuollet

I write GTK+ stuff for living these days and it works well, especially with Glade which is the screen builder. Check out the screen builders because they save an enormous amount of time. Most of the code is just callbacks and treeview manipulation. It mixes well with straight C code so if you are adding a GUI to an existing C application I think GTK+ is one of the easier ways, Of course, I've never worried about whether it will run on Windows, That might add complexity to the job, But if you use something like Eclipse that handles the build, it should be much the same.

Regards
cww
 
Hi,
If you really want to know GUI programming in C. Then you have to know on how to handle mouse by C Programming first. kindly check my site
http://c-gui-thunderbolt.page.tl/Home.htm
you will have a software Thunder, which will create C GUI codes automatically based on the sketch what you draw with the tools available.

I have no knowledge in handling HMI & PLC by using C programming. If you can help me regarding the same, it will be better, i will also present a software for that too...request you to kindly ping me regarding the same.

Regards,
Carthik

 
Top