Re: Translation domains
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 I set/change the translation domain? In the source file for the input method in question. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
key press events SUPR
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 happy my friend you push the supr keyboard button! end end are there MACROS to solves this problems??? Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: key press events SUPR
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 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 happy my friend you push the supr keyboard button! end end are there MACROS to solves this problems??? Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: key press events SUPR
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 @view_venta.signal_connect(key-press-event) do |widget,event| if event.keyval==Gdk::Keyval::GDK_Delete selection = @view_venta.selection borrar_l=[] selection.selected_each do |model, path, iter| borrar_l (Gtk::TreeRowReference.new(model,path)) #model.remove(iter) end borrar_l.each do |rowref| (path = rowref.path) and @list_store_venta.remove(@list_store_venta.get_iter(path)) end end end ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Height of text row in TreeView
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 way to achieve this so that we get correct cell height. Thanx for your time. Regards, Amol. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 答复: A question about GTK Scale
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 solved. Thanks!
But it is still a little strange that I have tried the
while(gtk_events_pending()) gtk_main_iteration(); before which didn't work.
But after I changed:
slider = gtk_vscale_new_with_range(0,1000,0.1);
to
GtkObject *adj1;
adj1 = gtk_adjustment_new (0.0, 0.0, 1001, 0.1, 1.0, 1.0);
slider = gtk_vscale_new (GTK_ADJUSTMENT (adj1));
it did work.
Any idea why?
-邮件原件-
发件人: Christopher Backhouse [mailto:[EMAIL PROTECTED]
发送时间: 2008年4月16日 9:40
收件人: Ke Jin
抄送: gtk-app-devel-list@gnome.org
主题: Re: A question about GTK Scale
Perhaps it takes 2 iterations of the main loop for the vscale to update.
What happens if you try
while(gtk_events_pending()) gtk_main_iteration();
instead?
Ke Jin wrote:
Dear All,
I have a VScale in my interface and I created button named Play that
once the button is clicked, the scale will move automatically.
Below is the function connected to the button. And it performed strangely.
The scale was not updated every iteration of the loop, which means the
value
of the scale changed from 0 to 2 then to 4 then 6and jumped over
1,3,5...
Does anyone have any idea why this happened?
void playClick(GtkWidget *widget, VScale *slider)
{
double interval = 1;
double currentTime = gtk_range_get_value((GtkRange*)(slider));
while(currentTime=20)
{
currentTime += interval;
usleep(100);
printf(current Time: %f\n,currentTime);
gtk_range_set_value((GtkRange*)(gtkE-slider),currentTime);
gtk_main_iteration();
}
}
Many Thanks,
Ke
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
DnD into a read-only textview
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. This makes sense generally as you don't want to drag text into something read-only. But anyway I would like to enable Drag and Drop for this widget because it would be just more convenient to drag into the much bigger textview area than into the small GtkEntry area. Is there any trick to get around the problem? Is there any way I can enable Drag and Drop for the GtkTextView even it is disabled for a sane default? Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Height of text row in TreeView
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 way to achieve this so that we get correct cell height. Thanx for your time. Regards, Amol. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 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 integrated widget would be much nicer. I fully agree with you. +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 through a cairo layer, I don't see why this would be so. Cairo should render the same content to screen as it does to a PS/PDF file. By explicit goal of the Cairo project, this _must work_. You could claim quite the reverse. If print preview does not go through App-Cairo-PDF-Cairo-Screen layers (would be only App-Cairo-Screen), then users will not catch PDF/PS generation bugs so soon, they only see the bugs appear on paper, and then it will be convoluted by printer driver bugs, etc. Anyway, +1 from me too. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 through a cairo layer, I don't see why this would be so. Cairo should render the same content to screen as it does to a PS/PDF file. By explicit goal of the Cairo project, this _must work_. Because as I said, There always will be bugs here and there. For example, pango keeps glyph extents in a 22.10 fixed format. Cairo keeps as double in device space. There will be rounding bugs here and there. They may add up and change your text layout. I do have plans to fix this properly. That has just not happened yet. You could claim quite the reverse. If print preview does not go through App-Cairo-PDF-Cairo-Screen layers (would be only App-Cairo-Screen), then users will not catch PDF/PS generation bugs so soon, they only see the bugs appear on paper, and then it will be convoluted by printer driver bugs, etc. That's what I meant. One way around it would be to print to a cairo PDF surface, then paint that surface to the actual widget surface. This would avoid the issues I mentioned above, at the cost of being heavier on memory and processor. Anyway, +1 from me too. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 here and there, you know... ... Because as I said, There always will be bugs here and there. I think the always in Behdad's there always will be bugs is much stronger than in his [using evince] is always going to be a more reliable preview. You could claim quite the reverse. If print preview does not go through App-Cairo-PDF-Cairo-Screen layers (would be only App-Cairo-Screen), then users will not catch PDF/PS generation bugs so soon, they only see the bugs appear on paper, and then it will be convoluted by printer driver bugs, etc. That's what I meant. Right. We do get to test more layers by doing the full round-trip. And I also agree that's a good thing. Interestingly, though, some of those layers can show bugs that are unique to this preview environment. So here's at least one concrete example where doing preview this way is actually less reliable. 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 And that's simply because there are bugs in poppler, which does the PDF-Cairo step, and poppler isn't actually involved in either the display-to-screen or print-to-pdf scenarios. That's not to single out poppler. There are certainly bugs in any of the stages, (App-Cairo, Cairo-Screen, or Cairo-PDF). And we definitely need to just use this full-round-trip process and make it as bomb-proof as possible. And we do do that kind of round-trip testing within cairo's test suite, and it does find poppler bugs in the PDF-Cairo stage. Here's our tracking bug that shows what issues we've found so far: Poppler does not yet handle everything in the cairo test suite https://bugs.freedesktop.org/show_bug.cgi?id=12143 Any help on fixing those will be greatly appreciated of course, (and will make any poppler-based print preview much more reliable). -Carl pgpOniaRfwYyG.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 And that's simply because there are bugs in poppler, which does the PDF-Cairo step, and poppler isn't actually involved in either the display-to-screen or print-to-pdf scenarios. Sure. But if you are printing to PDF and sending that PDF over to someone, there's advantage in the preview showing what your friend will be seeing when opening the PDF in evince... All these said, not sure what GTK-printing actually generates. If it's PS, it may be hitting a completely different set of bugs... -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 is totally broken: Print preview: App-Cairo-PDF-Cairo-Screen And that's simply because there are bugs in poppler, which does the PDF-Cairo step, and poppler isn't actually involved in either the display-to-screen or print-to-pdf scenarios. Sure. But if you are printing to PDF and sending that PDF over to someone, there's advantage in the preview showing what your friend will be seeing when opening the PDF in evince... All these said, not sure what GTK-printing actually generates. If it's PS, it may be hitting a completely different set of bugs... The problem with using an external application for print previews is, that you cannot embed it into your own UI, that you cannot remote control it. You absolutely need that features when integrating the print preview into some kind of work-flow, like order processing for instance. Using an external application really doesn't work here. The round trip testing argument is artificial. You use test suites for round trip management. For print preview there are situations were you want ultimate control over the preview canvas. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 another process to do this, and I think an integrated widget would be much nicer. Thoughts? +1 1) It allows user modification from within previewer - page re-ordering - inserting page breaks 2) It would help get preview working on win32, generating an emf is and using the viewer is not workable. 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. For a large or complex file (eg a spreadsheet with gridlines) that can get very large very quickly. An external backing store avoids that problem by pushing it off to the viewer, and assuming that it is efficient about loading only the required elements. A cross platform preview would be very nice, as long as it avoided that pitfall. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 to a cairo_t for the preview widget, drawing commands won't be recorded. If we do a PS/PDF/SVG then they are recorded inside cairo, and emitted when the page is done. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 does by default (if you are using the native build), see bug #518624. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
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 integrated widget would be much nicer. Thoughts? +million, for GTK+ to suck less (or rock more, whichever half glass you prefer). External preview was done because it could be implemented easily and nobody implemented internal preview, no? Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkLove/PatchTriaging
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 what I checked can be solved quickly since there are a lot of one-liners and nice useful patches. About 6 patches are available in docs section, and I think you can agree with me that they can be just downloaded, read, committed. Nice work! From my reading of README.commits[1], it seem to suggest that it is sometimes good to be bold. Please correct me if I am wrong though. E.g. this patch[2] is so trivial and completely harmless, that it is many times more work letting it rest and waiting for someone else to review it too, than just committing it yourself. 1: http://svn.gnome.org/viewvc/gtk%2B/trunk/README.commits?view=markup 2: http://bugzilla.gnome.org/show_bug.cgi?id=526575 -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkLove/PatchTriaging
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 live.gnome.org: http://live.gnome.org/GtkLove/PatchTriaging Most of what I checked can be solved quickly since there are a lot of one-liners and nice useful patches. About 6 patches are available in docs section, and I think you can agree with me that they can be just downloaded, read, committed. Nice work! From my reading of README.commits[1], it seem to suggest that it is sometimes good to be bold. Please correct me if I am wrong though. E.g. this patch[2] is so trivial and completely harmless, that it is many times more work letting it rest and waiting for someone else to review it too, than just committing it yourself. What I usually do when I find a trivial-to-fix bug in GTK+ or GLib is to file a bug with the fix and then nag the appropriate person in irc. If I'm not mistaken and the fix is actually as trivial as the one I found, I usually get positive responses for committing --way faster than waiting for others to review among tons of bug reports that arrive daily. So, I think you should do something similar if you want those patches committed and the bugs fixed. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
