Hi,
> > so it would be very helpfull
> > if you could tell us the step by step procedure of installing packages
> > or reffer us some website where we could find it.
the easiest way to do this is described here:
http://www.gtkforums.com/viewtopic.php?t=89
Hi,
I need to create a "canvas" within a window. 2D square.
On this canvas I want to be able to place objects - circles, squares (possibly
small jpeg files).
I also want to be able to select these objects with a standard mouse selection
method (multiple objects at once).
What's the best way to d
> One suspicious feature is that his test
> case for GMutex starts a thread using the windows API rather than glib's
> API.
This is not a problem because glib's API is in this case only a wrapper around
Win API.
> That is not of itself an error, but it invites the question
> whether, for exampl
Hi,
I'm using glib mutexes on Windows and I think they don't work.
I tried to use WIN API mutexes instead and they did work.
Short sample program:
I initialize the WIN API mutex, then create two threads using WIN API with this
simple code:
DWORD WINAPI MyThreadFunction( LPVOID lpParam )
{
i
> > If I may ask, what is the main technical problem (deeper explanation) with
> using GTK+ from multiple threads?
>
> On Windows, the problem is that Windows GDI, being a local windowing
> system with a quite tight coupling to the client code executing on the
> same machine, is very much thread-a
> > So GIMP is a single threaded software?
>
> No, but...
>
> > There's never GTK+ multithreaded activity?
>
> Indeed.
>
If I may ask, what is the main technical problem (deeper explanation) with
using GTK+ from multiple threads?
It is probably very application specific. For instance, in m
> Od: Tor Lillqvist
> Predmet: Re: gtk 2 or 3
> Dátum: 28.10.2010 11:26:08
>
> > It's impressive to see someone promoting tech from "the other camp" :-)
>
> Why not? It isn't like it would have any impact on my personal
> happiness/income/status/reputation
Hi,
thank you all for input.
>
> Le 10/06/2010, Shawn Bakhtiar a écrit :
> > 2.2) There is probably a memory leak somewhere. Where the structure of
> > the application (the compiled code) puts that pointer outside the
> > reach of the overflow so when you re-wrote it, it magically worked
> > (vo
Hi,
>
> Hello, this all looks like utter voodoo.
Yes it does. I tried 10 other ways and they didn't work. This one works
perfectly (so far).
> You have probably a trivial
> bug somewhere (elsewhere) in your code, maybe some
> extern/static/initialization confusion?
All initialization was sho
In case anyone's interested I solved the problem with a little hack.
I create the progress bar this way:
progBar = gtk_progress_bar_new();
gtk_box_pack_start (GTK_BOX (vboxGr), GTK_PROGRESS_BAR(progBar), FALSE, FALSE,
0);
gtk_widget_show (progBar));
progressBarHack(progBar);
the function progr
Hi,
I have a problem, when I try to access the GTK progress bar out of the
function it was created in.
I have a global variable
GtkWidget *progressBar;
so that I can access the progress bar from all the functions and different
files in the project.
When I initilize the bar and call functions to
11 matches
Mail list logo