CODEWITHSUNDEEP
cuser-interfacegtk
phcaze
phcaze

Reputation: 1777

GUI in C with GTK+, first steps

this is a general question about GUIs. I never wrote a program with GUI, and now I have to do it for the University. I found that the best solution programming in C is GTK+.

I see many examples, but I still can't understand one thing. My program is a server/client app, so it has to run in background also if there's a small GUI. How could it be realised? I see that to "start" the guy I have to use gtk_main() loop, and the application blocks inside this loop for all the time. Should I use fork() to do other tasks at the same time?

Thanks, sorry if it's a trivial question.

It's difficult to explain it in italian, in english is even worst :)

The program has to listen continously the network (LAN), to see if other users arrives and catch their UDP messages, and at the same time it has to communicate to a specific user if some conditions are verified (for example, if a file in a local folder changes, it has to send this file to the designated user. This could happen with multiple users at the same time). I have only one application that has to be server (sending files) and client (listening to the network) at the same time.

The idea of having a separate "client" which implements the GUI could be interesting.

I never developed a GUI, so I thought to write all my program, and then add the GUI at the end. It's possible?

Upvotes: 2

Views: 1359

Answers (2)

bta
bta

Reputation: 45057

Can you provide some details about what specifically your program is doing? Your current description is vague enough that it's hard to really understand what you are asking.

Here's some generic advice based on my interpretation of the original question.

You said that your program "is a server/client app, so it has to run in background also if there's a small GUI". Note that servers typically don't have integrated GUIs; they're usually designed to run silently and invisibly in the background. It's not uncommon to have a graphical interface for configuring or checking the status of the server, but it's traditionally implemented as a separate, standalone application (a client of sorts) that merely connects to the server to retrieve status information and send configuration commands. You won't have the GUI running the entire time that the server is running, so you don't want the server to be burdened with the additional overhead.

As far as your client goes, GUIs are typically implemented using callbacks. When a UI widget is created, it is given a pointer to a function that will be called whenever the widget is clicked, modified, or otherwise acted upon. Sometimes that callback function will simply update another UI widget and return, and sometimes it may require a new thread to be spawned for the purpose of doing something more complex. Again, this will largely depend on exactly what your GUI and application are trying to do.

Upvotes: 0

Havoc P
Havoc P

Reputation: 8467

You would run other tasks by asking the main loop to run them for you. This is handled automatically if you do IO with GIO (see http://developer.gnome.org/gio/stable/). But in the general case you would use functions such as g_idle_add(), g_timeout_add(), etc. as described here: http://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html and perhaps g_io_add_watch() here: http://developer.gnome.org/glib/stable/glib-IO-Channels.html

If you need to do blocking IO (something like read()/fread() calls) then you have to spawn a thread and have that thread communicate back to the GUI loop by adding an idle handler. This is tricky to understand if you're new to main loops or threads, so using GIO is a superior option since it does this for you.

You can also use fork() to spawn a process to do your IO, but then you need to use IO to communicate with your process, so you can't really avoid having to do IO in the UI process.

Upvotes: 2

Related Questions