I'm working on an application, and I keep getting messages from my
GtkEntry and GtkTextArea widgets Input method XXX should not use GTK'S
translation domain gtk20
What version of GTK+ are you using? What is XXX? Have you installed
some 3rd-party input method module for GTK+?
Where/How to
hi all:
I am working with gnome-ruby today and i have a question common in all GTK
APIS.
are they always the key codes the same in all platforms??
I want to catch the SUPR button
@window1.signal_connect(key-press-event) do |widget,event|
if event.keyval==65535
puts be
Hi, Martin.
From the GTK+ documentation for GdkEventKey:
guint keyval; the key that was pressed or released.
See the gdk/gdkkeysyms.h header file for a complete list of GDK key
codes.
On Thu, 2008-04-17 at 04:56 -0500, [EMAIL PROTECTED] wrote:
hi all:
I am working with gnome-ruby today and
Alexander Semenov escribió:
Hi, Martin.
From the GTK+ documentation for GdkEventKey:
guint keyval; the key that was pressed or released.
See the gdk/gdkkeysyms.h header file for a complete list of GDK key
codes.
Thanks:
puts Gdk::Keyval::GDK_Delete
Hi
I have a TreeView with two columns one pixbuf and one text.
when i have large text in text column the height of text column never
increase beyond height of pixbuf.
If there is no pixbuf rendered height never increases beyond one line.
Is this issue with GtkCellRendererText?
Is there any simple
Hi,
No, you should not use closed loop for GTK application when you expect
responses.
Use gtk timeout mechanism instead of the dead while loop with sleep.
Try that, I am quite sure that would help.
Yours faithfully,
Alvis Koon
On 16/04/2008, Ke Jin [EMAIL PROTECTED] wrote:
The problem is
Hi,
in a dictionary application I have a GtkEntry to enter some text and a
GtkTextView to display any results.
The GtkTextView is read-only (gtk_text_view_set_editable(textview,
FALSE)) because it's only used to display search results.
And therefore it can't be used as a target for Drag and Drop.
Hi
I have a TreeView with two columns one pixbuf and one text.
when i have large text in text column the height of text column never
increase beyond height of pixbuf.
If there is no pixbuf rendered height never increases beyond one line.
Is this issue with GtkCellRendererText?
Is there any simple
On Wed, 2008-04-16 at 14:02 -0400, Behdad Esfahbod wrote:
On Wed, 2008-04-16 at 19:54 +0200, Mathias Hasselmann wrote:
Am Mittwoch, den 16.04.2008, 12:46 -0500 schrieb Cody Russell:
I was thinking that it would be nice if there was an integrated print
preview widget in GTK+, that would be
On Thu, 2008-04-17 at 18:07 +0100, Gustavo J. A. M. Carneiro wrote:
+1 too. Though opening the actual generated PDF in evince is always
going to be a more reliable preview than rendering to a widget. There
always will be bugs here and there, you know...
_If_ gtk+ printing has to go
On Thu, 17 Apr 2008 13:15:42 -0400, Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 18:07 +0100, Gustavo J. A. M. Carneiro wrote:
+1 too. Though opening the actual generated PDF in evince is always
going to be a more reliable preview than rendering to a widget. There
always will be bugs
On Thu, 2008-04-17 at 11:14 -0700, Carl Worth wrote:
I can write a program where both of these are correct:
Display to screen: App-Cairo-Screen
Print to PDF: App-Cairo-PDF
But the following is totally broken:
Print preview: App-Cairo-PDF-Cairo-Screen
Am Donnerstag, den 17.04.2008, 14:20 -0400 schrieb Behdad Esfahbod:
On Thu, 2008-04-17 at 11:14 -0700, Carl Worth wrote:
I can write a program where both of these are correct:
Display to screen: App-Cairo-Screen
Print to PDF: App-Cairo-PDF
But the following
On Wed, Apr 16, 2008 at 12:46:22PM -0500, Cody Russell wrote:
I was thinking that it would be nice if there was an integrated print
preview widget in GTK+, that would be available cross-platform and
wanted to check with people here before I commit much time to this.
Right now we're spawning
On Thu, 2008-04-17 at 17:10 -0400, Jody Goldberg wrote:
The main upside to the current approach is that it avoids the
unacceptably vast memory footprint from libgnomeprintui's preview.
It would record a stream of drawing cmds _in memory_ and replay them
for the preview.
If we print straight
Hi,
On Wed, 2008-04-16 at 11:23 -0700, Brian J. Tarricone wrote:
Hooking this up on MacOS X would be easy -- all apps I've used there
that have a print preview just generate a pdf (or ps?) and open it with
Preview.app.
Which is exactly what the current GTK+ Print preview code on Mac OS X
Cody Russell wrote:
I was thinking that it would be nice if there was an integrated print
preview widget in GTK+, that would be available cross-platform and
wanted to check with people here before I commit much time to this.
Right now we're spawning another process to do this, and I think an
On Wed, Apr 16, 2008 at 7:19 AM, Diego Escalante Urrelo
[EMAIL PROTECTED] wrote:
Hey!
I took some minutes to try a bunch of the patches in the bottomless
pit of GTK+ bugzilla, I put the results of my triaging in
live.gnome.org:
http://live.gnome.org/GtkLove/PatchTriaging
Most of
El jue, 17-04-2008 a las 23:08 +, BJörn Lindqvist escribió:
On Wed, Apr 16, 2008 at 7:19 AM, Diego Escalante Urrelo
[EMAIL PROTECTED] wrote:
Hey!
I took some minutes to try a bunch of the patches in the bottomless
pit of GTK+ bugzilla, I put the results of my triaging in
19 matches
Mail list logo
