Re: Compiling a GTK application on windows

[Lothar Scholz <llothar web de>]

Title: Re: Compiling a GTK application on windows

Hello richard,

Wednesday, June 1, 2011, 1:57:53 PM, you wrote:

multi-threading is primitive with GTK?  are you crazy?  if you refer to drawing with Pango, then yes, this must be done in the main thread (when using X11 backend), but locking all of GTK?  not true.  and anyway, how many different things can an application draw at the same time requiring multi-threadable drawing that will make all the difference?

So what the fuck do you think is "gdk_threads_enter();" amd "gdk_thread_leave" doing?
If you've never gone down to the X11 level you pretty sure don't have any clue. It's protecting the main loop. This means, yes it means it protects it all.

I can't stand uneducated folks like you anymore. The worst is that it seems that people at your uneducation level are even hired by companies like red hat do to programming. This lack of education and experience explains why GTK is so worse (performance and coding is just terrible in all means).

Cairo replaced Pango long ago and should be used in newly written code (imho).  if multi-threaded drawing makes a difference then this is the way to go, i.e., a solution exists, so why concentrate on the limitations of past implementations that are no longer recommended?

Total wrong. Pango or better Harf Buzz is the text layout engine and Font support in Cairo is for very good reasons considered just a "Toy API" and works usually just for ISO-8859 charsets. It has any fucking idea about all the unicode difficulties of non trivial ASCII text scripts.

as far as general multi-threading is concerned, you have no idea what you're talking about.  i make use of multi-threading in my GUI's extensively (querying the number of CPU's i have available at program startup, using this info throughout).  I have background threads that do all kinds of work, both not related to drawing, as well as drawing preparation.   for example, i have one screen of nine panels of by-hand drawings, each requiring its own data to be retrieved from a DB.  all calls to the DB are done in separate threads, executing simultaneously, i.e., in parallel.  all calls to my DB can be made synchronously or

So what does a DB interface has to do with the GUI? How do you update for example your list views?
You can either create your own list model and try to update this from the background and then swap it
or you have to lock out all other processing with "gdk_threads_enter".

>in another application, i'm using GIO to parse several I/O streams (stdout, stderr, more) 

GIO or GLib has nothing to do with GTK and the GUI too. Do you not understand?

Yes i'm an arrogant fuckhole - but at least i know how to program.