Well, if I wasn't clear before my layout is totally questionable. I
more generic question would be:
How you guys aproaches when the problem is showing applications
behavior on screen?
My backend logic is something like this:
- Start a new thread for each address passed in command line. Address
are 32bits numbers.
- At each thraed:
- While (true)
- Make the background yellow
- Send a message and wait for response (a blocking call)
- If timeout set background red
- else set background green
- showup the latency (how much time the "Send a message" taken)
- wait a second so that user can see other background color than yellow
- Start a new thread to receive events
- While (true)
- when some event arrive:
- instantiate a new label describing the event and show it onto
the screen
- reply the event (blocks till reply acknowledge)
- remove the event from the screen
Is there any monitoring software that reacts to outside world events
and show then in some GTK GUI? That would be a good inspiration :)
Best regards,
2016-09-12 13:19 GMT-03:00 Daniel. <danielhi...@gmail.com>:
> Hi thank you guys for the replies,
>
> Gergely, I can't really use FlowBox since I'm depending on gtk2, not
> 3. So the solution is really implementing my own widget as Joël said
> .. Joël in swing I usually use an event queue so that there is only
> one thread doing GUI modifications. Is that pattern used often in gtk?
> I think that this pattern is cleaner and more ellegant that
> synchronizing at every single thread, the problem is that I can't have
> lambda expressions in C :(. How would I apply this pattern to GTK?
>
> Best regards,
>
> 2016-09-12 12:56 GMT-03:00 Joël Krähemann <jkraehem...@gmail.com>:
>> Hi again
>>
>> Don't mess synchronized with a mutex. The closest thing to
>> synchronized would be ags_task_thread_append_task()
>> and run things exclusively
>>
>> http://git.savannah.gnu.org/cgit/gsequencer.git/tree/ags/thread/ags_task_thread.h?h=0.7.x
>>
>> bests,
>> Joël
>>
>>
>>
>> On Mon, Sep 12, 2016 at 5:50 PM, Joël Krähemann <jkraehem...@gmail.com>
>> wrote:
>>> Hi
>>>
>>> Since I know Javax/Swing I can tell you there is no synchronize
>>> keyword doing your magic.
>>>
>>> Please take a look at pthread_mutex_lock(), pthread_cond_wait(),
>>> pthread_cond_signal(), pthread_cond_broadcast()
>>> or pthread_barrier_wait().
>>>
>>> Bests,
>>> Joël
>>>
>>>
>>> On Mon, Sep 12, 2016 at 5:17 PM, Joël Krähemann <jkraehem...@gmail.com>
>>> wrote:
>>>> Hi
>>>>
>>>> You can't do that without implementing your own widget because of
>>>> thread-safety issues. To do your own
>>>> GtkFlowBox implement GtkWidget:size-allocate and
>>>> GtkWidget:size-request the rest is up to you.
>>>>
>>>> Don't forget doing mutices or use g_timeout_add() but this is single
>>>> threaded and is invoked by
>>>> g_main_context_iteration().
>>>>
>>>> For a simple example consider this:
>>>>
>>>> http://git.savannah.gnu.org/cgit/gsequencer.git/tree/ags/X/editor/ags_notebook.c?h=0.7.x#n167
>>>>
>>>> It is a scrolled window containing buttons doing a scrollable area.
>>>>
>>>> You have to use gdk_threads_enter() and gdk_threads_leave(). Might be
>>>> you have even to acquire
>>>> the GMainContext.
>>>>
>>>> Bests,
>>>> Joël
>>>>
>>>>
>>>>
>>>> On Mon, Sep 12, 2016 at 5:03 PM, Gergely Polonkai <gerg...@polonkai.eu>
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> I have no knowledge of Java/Swing, but based on your requirements I guess
>>>>> you need FlowBox[1].
>>>>>
>>>>> Best,
>>>>> Gergely
>>>>>
>>>>> [1] https://developer.gnome.org/gtk3/stable/GtkFlowBox.html
>>>>>
>>>>> On Mon, Sep 12, 2016, 16:35 Daniel. <danielhi...@gmail.com> wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> I have a library implementing some protocol. That library is
>>>>>> multithread and is responsible to delivery messages to remote nodes
>>>>>> and retrieve it's responses. I need to visualise the whole mess
>>>>>> running.
>>>>>>
>>>>>> To do this I wrote a simple application in Java/Swing where for each
>>>>>> remote node one thread is created. The thread will send a message and
>>>>>> wait for response in a closed loop. Each thread is represented at GUI
>>>>>> by a label on the screen. When it's idle the background of that label
>>>>>> becomes green, when is waiting for response it is yellow and if
>>>>>> timeouts it becomes red. All labels have the same information so that
>>>>>> they have exactly the same size.
>>>>>>
>>>>>> Beside the request/repsonse there is events that can arrive from the
>>>>>> nodes too. That events need to be replied as the messages. When an
>>>>>> event arrives it's showed up on screen as a new label. When it's reply
>>>>>> is acknowledge it's removed from the screen.
>>>>>>
>>>>>> In pratice there is a big container where the labels came and go and
>>>>>> change its background colors based on messages, replies and events
>>>>>> comming and going.
>>>>>>
>>>>>> I've been using FlowLayout as the "big container". The labels are
>>>>>> added and arrange horizontally by FlowLayout. When no room is avaible
>>>>>> at the current row, a new row is added. When the rows exceed the
>>>>>> window size a scrowbar appears.
>>>>>>
>>>>>> I'm looking for something silimar with GTK2 (I'll run in a embeeded
>>>>>> system that doesn't have GTK3).
>>>>>>
>>>>>> My questions are:
>>>>>>
>>>>>> 1) Is there some container with equivalent behavior to the Swing's
>>>>>> FlowLayout? If no I think I'll need to build one from hbox+vbox, what
>>>>>> would be the best aproach to it.
>>>>>> 2) How is the best way to change the background of a label?
>>>>>> 3) What is the better aproach when adding instantiating, adding,
>>>>>> showing, hiding removing and freeing widgets at runtime? What can get
>>>>>> wrong?
>>>>>>
>>>>>> References:
>>>>>> https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html#flow
>>>>>>
>>>>>> Best regards,
>>>>>> --
>>>>>> "Do or do not. There is no try"
>>>>>> Yoda Master
>>>>>> _______________________________________________
>>>>>> gtk-app-devel-list mailing list
>>>>>> gtk-app-devel-list@gnome.org
>>>>>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>>>>>
>>>>> _______________________________________________
>>>>> gtk-app-devel-list mailing list
>>>>> gtk-app-devel-list@gnome.org
>>>>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
>
> --
> "Do or do not. There is no try"
> Yoda Master
--
"Do or do not. There is no try"
Yoda Master
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
