|
I know I am missing something really simple here, but all I am trying to do is display a image from a jpg file on a glade form statically w/o a file chooser, here is my code so far, any help would be great.
<pre>#include <gtk/gtk.h>
typedef struct {
GtkWidget *w_dlg_file_choose; GtkWidget *w_img_main; GtkWidget *image;
} app_widgets;
gchar *file_name = "image1.jpg";
int main(int argc, char *argv[]) {
GtkBuilder *builder;
GtkWidget *window;
app_widgets *widgets = g_slice_new(app_widgets);
gtk_init(&argc, &argv);
builder = gtk_builder_new_from_file("glade/window_main.glade");
window = GTK_WIDGET(gtk_builder_get_object(builder, "window_main"));
widgets->w_dlg_file_choose = GTK_WIDGET(gtk_builder_get_object(builder, "dlg_file_choose"));
widgets->w_img_main = GTK_WIDGET(gtk_builder_get_object(builder, "img_main"));
gtk_builder_connect_signals(builder, widgets);
g_object_unref(builder);
gtk_widget_show(window);
gtk_main();
g_slice_free(app_widgets, widgets);
return 0;
}
void on_info_btn_clicked() {
gtk_main_quit();
}
void on_window_main_destroy() {
gtk_main_quit();
}
|
|
|
|
|
Member 14851172 wrote: I know I am missing something really simple here
Yes, the details of your problem.
|
|
|
|
|
Here is the latest snag I am against.
Main part of my application is to WAIT to receive data.
In fancy techno talk - I have a server in "accept" state - waiting to receive data - hence processing is stopped.
The data received is processed and then passed to OpenGL - OpenGL is in similar waiting state "they" call glutMainLoop();
Obviously unworkable situation - cannot have two waiting state. .
Found "fork" which creates two processes , but they do not share variables.
Looking at socketpair to solve that "problem".
Now it looks as proverbial "long way around the barn"...
Any other "professional" suggestion ?
Not really sure how to debug such setup - jumping between processes , but willing to try it.
|
|
|
|
|
One word to read up on...
threads
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Multiple processes can happily share variables in global memory. They just need to use semaphores or mutexes to synchronise their access. Just about every application running on the web, on desktops, phones etc. uses these features.
|
|
|
|
|
fork() and signal() - that's what I used in the 1980's and 1990's before POSIX 4 (later POSIX 1a now pthreads and more recently, threads native to C11 and C++11) came into being. This includes sigwait(), sigpause(), sigsuspend(), etc. Some of these work with threads. It might be possible to emulate the functionality of all concurrency primitives with these elements alone.
You can look under the POSIX Standard for more information The Open Group Base Specifications Issue 7, 2018 edition[^]
There is already a multi-platform Pause-Resume thread framework on this site. That's what landed me on this web site. It's right here Data Processing Thread with the Pause/Resume Functionality[^]
|
|
|
|
|
|
I generally use KISS approach.
The task is to have two event "loops" , one monitoring the bluetooth input and the other processing and displaying results.
"fork" does the job.
Besides - as I continue to build the app it is not pure C++, such as OpenGL is "just" C.
|
|
|
|
|
KISS can be subjective.
In my opinion, fork is not more KISS than threads, because you have to go through IPC.
|
|
|
|
|
Follow the directions here:
man pthread_create
|
|
|
|
|
OK, I will open myself for ridicule...
I WIIL (eventually) display real calculated data on Smith chart.
Smith chart - Wikipedia[^]
I can handle the math, what I see as a small issue is the actual GUI implementation.
I have few MAJOR choices - OpenGL, GTK and Cairo.
I found very promising code written for GTK and apparently using Cairo too.
(Cairo being 2D graph tool is my initial take on it).
I am not so sure about basic "window / form /view " - I see OpenGL as the simplest.
( I wish the "industry" woudl come up with uniform desorption / definition of the thing which was called when I started "coding" "window" - no capital W !
The advise I am seeking is
Are there other , simple, 2D graphic tools ?
I do not need spinning cube , shading, license plate recognition etc,
Cheers
|
|
|
|
|
|
Thanks, nice reference.
I have already found another GTK application, so the "math" is covered.
PS
Me asking Mrs Google "linux smith chart" returned no useful info!
Must be my accent.
|
|
|
|
|
|
|
Edit
Since the server is in listen /accept waiting mode all I should worry about timeout.
I can set the socket to take care of that.
I just test client to send multiple single message - in 5 second interval and reinitialized the client socket each time. Works fine for my task.
It has been a challenge , but I finally have bluetooth connection passing simple text message from client to server.
My task is to be able to utilize such connection as necessary, hence not keeping it in any kinda-of synchronous loop.
At present the communication will always be from client to server , and started by client. .
Basically I am looking for a way to check "is server connected ? ".
I do not see any issues closing the client socket and reinitializing it when new communication is required.
I hope I can instruct server socket (timeout ?) to stay connected in "accept" function...
However, I have been reading up on "select"
<a href="http://man7.org/linux/man-pages/man2/select_tut.2.html">select_tut(2) - Linux manual page</a>[<a href="http://man7.org/linux/man-pages/man2/select_tut.2.html" target="_blank" title="New Window">^</a>]
and wondering if that woudl be "cleaner" way to run this asynchronously by monitoring the state of the connection when necessary.
Maybe I'll be over my head again using select...
Any commentaries (to the subject) or other suggestion will be appreciated.
modified 7-Mar-20 16:40pm.
|
|
|
|
|
This is NOT question, just asking - to whom do I trust ?
perror posts “operation now in progress “ which is great to know
BUT connect return “status “ is -1 .
To whom do I trust ?
This implies that "“operation now in progress “ is an error or checking return value is bogus.
Simple "connect" function description quoted from documentation:
"The normal return value from connect is 0. If an error occurs, connect returns -1. The following errno error conditions are defined for this function:"
Please notice how "errno" is used.
status = connect(s, (struct sockaddr*) &server_addr, sizeof(server_addr));
if (errno != 0 | status != 0) { // redundant and wrong
....
|
|
|
|
|
Both.
From the man page:
Quote: RETURN VALUE
If the connection or binding succeeds, zero is returned. On error, -1 is returned, and errno is set appropriately.
ERRORS
The following are general socket errors only. There may be other domain-specific error codes.
EACCES For UNIX domain sockets, which are identified by pathname: Write permission is denied on the socket file, or
search permission is denied for one of the directories in the path prefix. (See also path_resolution(7).)
EACCES, EPERM
The user tried to connect to a broadcast address without having the socket broadcast flag enabled or the connec‐
tion request failed because of a local firewall rule.
EADDRINUSE
Local address is already in use.
... etc ...
So you know that the call to connect() did not succeed, because it returned -1. There's a lot of reasons that connect() might fail, and you can examine errno to find out why. In many cases, depending on context, an unsuccessful connect might be expected, or recoverable (e.g. if you've run out of resources, you might be able to either wait for other connections to close, or be able to clean up/close old connections). In your case errno is EINPROGRESS "The socket is nonblocking and the connection cannot be completed immediately". See the man page for further information. If this is a bluetooth, then consult any relevant bluetooth docs to see if EINPROGRESS is mentioned and why you might get that error code.
Note that perror() will always print "operation now in progress" any time errno == EINPROGRESS. Some library calls might set EINPROGRESS to indicate a condition that does not directly translate to "operation now in progress", but the resource is temporarily busy, and you should try again later, and EAGAIN already is used for some other retry condition.
|
|
|
|
|
"So you know that the call to connect() did not succeed, because it returned -1. There's a lot of reasons that connect() might fail, and you can examine errno to find out why."
That is what I though I was doing - looking at status and expected 0 and then errno to get some more info.
I think the connect is failing due to remote end not responding in - for now unknown - time, but that is where the "in progress" is somewhat telling me that.
Also the actual response is delayed by this , yet unspecified time.
Interestingly - after first call fails with "in progress..." next call returns immediately with "device busy..".
Question is - which device ?
Must be the local which is busy - doing what ? It did not connect...
Remote ? If it did not "connect" in first place how it can be the remote which is busy?
( At present rebooting local sort of works, and I am working on something faster using code ...)
"Note that perror() will always print "operation now in progress" any time errno == EINPROGRESS"
I don't think there is an easy way to correlate actual message to its symbol.
I am sure I can find the source code , but why ?
In my view that woudl defeat the function of perror - translating the errno # to text without showing the symbols.
|
|
|
|
|
The "in progress" status is telling you that the local device is trying to complete some operation. If you then try to use it again it may well be returning "busy" because it is unable to accept your request.
The perror() function has been around for years and has always been fairly succinct in its output. The important information is the actual errno value. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).
What you really should do is get hold of the RFC documents for TCP/IP and Bluetooth, and study the protocol details. They should give you the exact sequence of events that are supposed to happen when the two endpoints try to communicate.
|
|
|
|
|
Richard MacCutchan wrote: The perror() function has been around for years and has always been fairly succinct in its output. The important information is the actual errno value. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).
Even old dogs learn something new occasionally. I was certain that perror() would be locale aware, but it seems not (which could be an issue if you are depending on exact text matches in your output). While researching that, I came across the GNU error() function, which might help the OP. See about half-way down this page: Error Messages (The GNU C Library)
|
|
|
|
|
Thanks, this is very good reference.
Error Messages (The GNU C Library)[^]
So far I am getting used to perror , it mostly gives good description of the state.
I am still unsure how to recover from some of those related to socket and bluetooth.
The moral of the story
check the return value first , then let perror describe the state.
perror does not always tells error, but state.
BTW the original error was due to my mistake not checking the remote bluetooth device address.
I was passing the device name and not the address!
Live and learn...
Cheers
|
|
|
|
|
Vaclav_ wrote: check the return value first , then let perror describe the state.
No, don't rely on perror alone. The most important piece of information is the actual error code. And, as I already suggested, you should study the RFC documents to get a thorough understanding of the protocols you are trying to use.
|
|
|
|
|
Quote: The important information is the actual errno value. It is a fairly simple matter to write your own function to display the value and the error message (see strerror(3) - Linux manual page[^]).
You don't need to, on GNU systems simply use '%m' in the printf format string. The '%m' is replaced with the actual error message in the language that the system is set to.
|
|
|
|
|
I think this question was well answered 9 months ago.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
