Not sure if this is a bug or not, but using gtk+ 3.6 on Windows I have a
"missing icon" icon in the search bar of the GtkFontChooserDialog. I would
guess it should display the usual magnifying glass search icon. The other gtk+
custom dialogs - GtkColorChooserDialog and GtkFileChooserDialog both
Is there a way to re-define the RGB values of built-in color names in GTK?
Perhaps using .gtkrc? Ideally I don't want to compile a custom binary...
Background, for those interested:
I use Vim, both the commandline version (vim) and GUI vesrion (gvim).
The gui version is built on GTK.
In my color
hi;
On 30.01.2015 19:53, John W wrote:
> Is there a way to re-define the RGB values of built-in color names in GTK?
no.
> So back to the point: is there any way to change GTK's mapping for color
> names?
> Or perhaps have GTK use X11 color names?
>
GTK+ parses CSS-like color strings like 'rgb
Den 2015-02-03 16:23, Emmanuele Bassi skrev:
> hi;
>
> On 2 February 2015 at 22:07, G Hasse wrote:
>> Den 2015-02-02 22:57, Gulshan Singh skrev:
>>
>> I strongly advice designing an application in this way. Every window in an
>> application should be a separate process. Between processes you s
On Thu, 2015-02-05 at 13:26 +0100, Göran Hasse wrote:
>
> Den 2015-02-03 16:23, Emmanuele Bassi skrev:
> > hi;
> >
> > On 2 February 2015 at 22:07, G Hasse wrote:
> >> Den 2015-02-02 22:57, Gulshan Singh skrev:
> >>
> >> I strongly advice designing an application in this way. Every window in an
On Thu, Feb 5, 2015 at 7:40 AM, Tristan Van Berkom wrote:
Everything Tristan said is precisely correct. But in addition ...
>
> You seem to be going off on a tangent here, your claim was that:
>
> "every window in an application should be in a separate process"
>
I have a hunch about where y
Hello,
Den 2015-02-05 16:13, Paul Davis skrev:
>
>
> On Thu, Feb 5, 2015 at 7:40 AM, Tristan Van Berkom
> mailto:tris...@upstairslabs.com>> wrote:
>
> Everything Tristan said is precisely correct. But in addition ...
>
Exept that threads application ofthen hangs...
>
> You seem to be going
On Thu, Feb 5, 2015 at 12:19 PM, Göran Hasse wrote:
>
>
>
> Sorry... I have NOT done mutch MS-Window programming. This since I
> for about 20 odd years ago noticed that sockets (file descriptors)
> is the ONLY safe way to do communications by. (select, poll or
> kernel-queue etc).
>
this is fals
On Thu, Feb 5, 2015 at 12:34 PM, David Nečas wrote:
> On Thu, Feb 05, 2015 at 12:28:02PM -0500, Paul Davis wrote:
> > threads can use all the same mechanisms as processes, but don't have to
> use
> > OS provided APIs to share address spaces. that's really the only
> > difference.
>
> This is fals
You can still deadlock with two different processes (getting your protocol
marshalling into a state where both processes are waiting for an RPC reply
from the other), and we've seen it with DBus interfaces before.
Really, the ability to not hang relies on careful engineering and
understanding the
On Thu, Feb 05, 2015 at 12:28:02PM -0500, Paul Davis wrote:
> threads can use all the same mechanisms as processes, but don't have to use
> OS provided APIs to share address spaces. that's really the only
> difference.
This is false. Threads within one process share much more properties
and state
Den 2015-02-05 18:46, Jasper St. Pierre skrev:
> You can still deadlock with two different processes (getting your
> protocol marshalling into a state where both processes are waiting
> for an RPC reply from the other), and we've seen it with DBus
> interfaces before.
Yes. You have to have a go
On Thu, Feb 5, 2015 at 1:27 PM, Göran Hasse wrote:
>
> Yes. You have to make a a good design.
>
case closed.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
13 matches
Mail list logo
