Weird problems: C library programs crashing in combination with GTK UI
Hi all,
I am giving a UI for a library which has been developed in core ANSI C.
The library calls a function close to 1000 times and is highly voluminous
in terms of space and time. I want to call this function 1000 times from
my UI.
I have made a dll file out of the C library, and I am using glade for GTK
front end. I have written ANSI C code snippets to check if the library
functions are working, and they appear to be working very well without any
problems.
While I told that this function call from the library takes a lot of time,
I have a progress bar in my UI, and while runnning this library function,
my progress bar keeps updating the fraction of work done by that
library[the fraction is actually computed by the C library function,
written into a file, and the timeout function keeps reading fraction value
from the same file periodically and updates its fraction].
For this I have written a time out function which keeps updating fraction
regularly in the progress bar.
So, I call this time out function first, and immediately I call this C
library function, and then followed by:
while (gtk_events_pending ())
{
g_print([.]);
gtk_main_iteration ();
}
so that the timeout function doesnt have to blocked until this big
function is over, and it can keep updating fraction.
I am now facing really weird problems here.
1. My time out function is NOT BEING CALLED AT ALL. I am inserting a few
g_prints in the time out function, and I see nothing on the console.
Moreover, no updates are happening to progress bar fraction. Only after
fraction reaches 0.99, progress bar time out function is called.
2. My C library function crashes if I make changes to the timeout function
or the callback function. Windows is full of mysteries and I dont even
know why it crashed. When I include a g_print somewhere in the callback
function or timeout function, it starts working, and then suddenly stops
working
I am using windows MingGw-Msys-GTK2.0-glade combination for writing my
apps in windows.
Pseudo code for my call back function [for some button which will initiate
action] is as follows:
/***CALL BACK FUNCTION CODE SNIPPET ***/
g_timeout_add(1500,progress_timeout,progressbarwidget);
f1();//THE BIG FUNCTION WHICH WILL RUN CLOSE TO A FEW HOURS
while (gtk_events_pending ())
{
g_print([.]);
gtk_main_iteration ();
}//THIS SO THAT THE TIME OUT FUNCTION WILL BE ABLE TO CALL ITSELF
/END CALL BACK FUNCTION CODE SNIPPET**/
/TIME OUT FUNCTION */
static gboolean progress_timeout( gpointer pbar)
{
/*
1. Open file frac.v in read mode.
2. Read fraction.
3. Convert read fraction into double.
4. Update progress bar with fraction.
5. If fraction =0.99, then deem that work is complete, so return true
to
g_timeout_add.
*/
FILE *fp;
gchar *buffer;
gdouble fraction = 0.0;
//1. Open file frac.v in read mode.
fp = fopen(frac.v,r);
if(fp==NULL)
{
displayError(Unable to update Progress bar.\n);
return FALSE;//Stop updating
}//End if fp==NULL
/*
Buffer will hold the fraction read from file. Fraction is of precision
5,
and will be between 0 and 1. So, size = 1[0//1]+1['.']+5[precision 5]
+1[EOS] = 8
*/
buffer = (gchar *)g_malloc0(8*sizeof(gchar));
//2. Read first line into buffer
fgets(buffer,8,fp);
fclose(fp);
//Buffer contains fraction.
//3. Convert read fraction into double[until end of buffer].
fraction = strtod(buffer,NULL);
//4. Update progress bar with fraction.
gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (pbar), fraction);
//Free memory
g_free(buffer);
//5. If fraction =0.99, then deem that work is complete, so return true
to g_timeout_add.
if(fraction=0.99)//If work is complete.
{
return FALSE;//Stop updating.
}
else//If work is not complete.
{
g_print(Time out function called);
return TRUE;
}
}//End function progress_timeout
/**END TIME OUT FUNCTION */
1. Why should my C library function [which otherwise is doing very well]
crash just because I made some print changes in callback and time out ?
2. Since my timeout function has file I/O operations, is it that file I/Os
are still blocked even if I insert the gtk_main_iteration() call inside
while loop as I have indicated ?
*
DISCLAIMER
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
Any use,distribution,copying or
GtkComboBoxEntry Vs GtkComboBox
Hi All,
I have the following code that I copied from the hello world part of
the GTK+ tutorial. I used it to practice using GtkComboBoxEntry(s).
#include gtk/gtk.h
int main( int argc,
char *argv[] )
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *cboVocSource;
/* This is called in all GTK applications. Arguments are parsed
* from the command line and are returned to the application. */
gtk_init (argc, argv);
/* create a new window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
/* Sets the border width of the window. */
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
/* Creates a new combo box entry with the text Hello World */
cboVocSource = gtk_combo_box_entry_new_text ();
gtk_widget_set_name (cboVocSource, cboVocSource);
gtk_combo_box_append_text(cboVocSource, Hello World);
/* This packs the button into the window (a gtk container). */
gtk_container_add (GTK_CONTAINER (window), cboVocSource);
/* The final step is to display this newly created widget. */
gtk_widget_show (cboVocSource);
/* and the window */
gtk_widget_show (window);
/* All GTK applications must have a gtk_main(). Control ends here
* and waits for an event to occur (like a key press or
* mouse event). */
gtk_main ();
return 0;
}
I compile it with the following command:
$ gcc -Wall -g box.c -o box `pkg-config --cflags gtk+-2.0` `pkg-config
--libs gtk+-2.0`
And get this warning:
box.c: In function 'main':
box.c:23: warning: passing argument 1 of 'gtk_combo_box_append_text'
from incompatible pointer type
In the api it has the definition for gtk_combo_box_append_text as:
void gtk_combo_box_append_text(GtkComboBox *combo_box,
const gchar *text);
So I wondered if I needed to cast my GtkComboBoxEntry to a GtkComboBox
but wasn't sure how to do this so I tried:
gtk_combo_box_append_text(GTK_COMBO(cboVocSource), Hello World);
This however makes matters worse as I get the above warning still when
I compile it, but now when I run it I get:
$ ./box
(box:11338): GLib-GObject-WARNING **: invalid cast from
`GtkComboBoxEntry' to `GtkCombo'
Can someone please tell me what I'm doing wrong?
Many thanks,
Peter.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBoxEntry Vs GtkComboBox
El mar, 22-01-2008 a las 21:55 +1100, Peter E Dennis escribió: So I wondered if I needed to cast my GtkComboBoxEntry to a GtkComboBox but wasn't sure how to do this so I tried: gtk_combo_box_append_text(GTK_COMBO(cboVocSource), Hello World); This however makes matters worse as I get the above warning still when I compile it, but now when I run it I get: $ ./box (box:11338): GLib-GObject-WARNING **: invalid cast from `GtkComboBoxEntry' to `GtkCombo' Can someone please tell me what I'm doing wrong? You need to cast to a GtkComboBox, not to a GtkCombo. Use the GTK_COMBO_BOX macro. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Weird problems: C library programs crashing in combination with GTK UI
2008/1/22 [EMAIL PROTECTED]:
[...]
Pseudo code for my call back function [for some button which will initiate
action] is as follows:
/***CALL BACK FUNCTION CODE SNIPPET ***/
g_timeout_add(1500,progress_timeout,progressbarwidget);
f1();//THE BIG FUNCTION WHICH WILL RUN CLOSE TO A FEW HOURS
while (gtk_events_pending ())
{
g_print([.]);
gtk_main_iteration ();
}//THIS SO THAT THE TIME OUT FUNCTION WILL BE ABLE TO CALL ITSELF
/END CALL BACK FUNCTION CODE
SNIPPET**/
Gtk+ runs in a single thread, you must return to the mainloop that
you are running (in gtk_main()) in order for your callbacks to be called.
If you dont want to split up f1(); into iterations and run those short
iterations from a timeout function, then you might consider using GThread.
You can also use the old hack:
while (gtk_events_pending ())
gtk_main_iteration ();
to run the mainloop recursively so to speak, but if you never call
gtk_main_iteration() until you are finished f1(); then you are not
pushing progress bars.
Cheers,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLib 2.15.3 released
Hi All,
Iam using glib api's (g_convert)to convert the UTF-8 to ISO-8859-1..
but it displayed error as Coversion from UTF-8 to ISO-8859-1 is not supported
For me its working fine in linux, but when i port my code in embedded..this
g_convert fails and displays error..
Is anybody knows how to solve this problem..
Regards
Pavan Reddy.
On Tue, 22 Jan 2008 Matthias Clasen wrote :
GLib 2.15.3 is now available for download at:
http://ftp.gnome.org/pub/GNOME/sources/glib/2.15/
glib-2.15.3.tar.bz2 md5sum: 83aa09c6126e3111c9f371c1396324e7
glib-2.15.3.tar.gz md5sum: c6e6310e1a8d2eb85e043cc9408486c6
This is the fourth development release leading up to GLib 2.16.
Notes:
* This is unstable development release. While it has had
a bit of testing, there are certainly plenty of bugs
remaining to be found. This release should not be used
in production.
* Installing this version will overwrite your existing
copy of GLib 2.14. If you have problems, you'll need
to reinstall GLib 2.14.
* GLib 2.16 will be source and binary compatible with
the GLib 2.14 series. The new API in GLib should be
stable at this point; we are still expecting to do
some minor API additions in GIO, so there may be
incompatibilities between this release and the final
2.16 release.
* Bugs should be reported to http://bugzilla.gnome.org.
About GLib
==
GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.
More information about GLib is available at:
http://www.gtk.org/
An installation guide for the GTK+ libraries, including GLib, can
be found at:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html
Overview of Changes from GLib 2.15.2 to GLib 2.15.3
===
* GChecksum:
- g_checksum_update can accept nul-terminated strings
- The MD5 implementation works correctly on buffers
that are longer than 64 bytes
* GIO:
- Don't include a copy of the inotify headers, rely on system headers
- g_file_find_enclosing_mount has an async variant now
- Reduntant seek API on file streams has been removed
* Bugs fixed:
508602 gmemory{in|out}putstream.c: unknown pointer size
508771 There is no g_file_test/exists() for GFile
508773 g_uri_escape_string() documentation unclear.
509465 AM_PATH_GLIB_2_0 doesn't support gio
509626 async functions: Document allowed NULL callback?
509990 GSeekable documentation unclear
510448 No inotify support on ARM or SH5
510855 g_checksum_update(): Take -1 for length.
* Updated translations:
Basque (eu)
Marathi (mr)
Swedish (sv)
Ukrainian (uk)
A list of all fixed bugs can be found here:
http://bugzilla.gnome.org/buglist.cgi?bug_id=508773,509465,510855,508602,509626,508771,510448,509990
Thanks to all contributors
Dan Winship
Alexander Larsson
Murray Cumming
Tim Janik
Kazuki IWAMOTO
January 21, 2008
Matthias Clasen
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GLib 2.15.3 released
On 22 Jan 2008 16:45:10 -, Pavan Kumar Reddy [EMAIL PROTECTED] wrote: Hi All, Iam using glib api's (g_convert)to convert the UTF-8 to ISO-8859-1.. but it displayed error as Coversion from UTF-8 to ISO-8859-1 is not supported For me its working fine in linux, but when i port my code in embedded..this g_convert fails and displays error.. Is anybody knows how to solve this problem.. g_convert supports whatever the underlying iconv implementation supports. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBoxEntry Vs GtkComboBox
Thanks Claudio. I'm just wondering why do I use the GTK_COMBO_BOX macro and not the GTK_COMBO_BOX_ENTRY macro? Many thanks, Peter. On 23/01/2008, Claudio Saavedra [EMAIL PROTECTED] wrote: El mar, 22-01-2008 a las 21:55 +1100, Peter E Dennis escribió: So I wondered if I needed to cast my GtkComboBoxEntry to a GtkComboBox but wasn't sure how to do this so I tried: gtk_combo_box_append_text(GTK_COMBO(cboVocSource), Hello World); This however makes matters worse as I get the above warning still when I compile it, but now when I run it I get: $ ./box (box:11338): GLib-GObject-WARNING **: invalid cast from `GtkComboBoxEntry' to `GtkCombo' Can someone please tell me what I'm doing wrong? You need to cast to a GtkComboBox, not to a GtkCombo. Use the GTK_COMBO_BOX macro. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBoxEntry Vs GtkComboBox
El mié, 23-01-2008 a las 06:09 +1100, Peter E Dennis escribió: Thanks Claudio. I'm just wondering why do I use the GTK_COMBO_BOX macro and not the GTK_COMBO_BOX_ENTRY macro? Because gtk_combo_box_append_text () is a function that works on GtkComboBox objects, not GtkComboBoxEntry ones. As GtkComboBoxEntry inherites from GtkComboBox, you can use functions from the parent class in your GtkComboBoxEntry instance, but you need to cast it, given that C can't do it itself. A little pain of using GObject and C :-) Claudio Many thanks, Peter. On 23/01/2008, Claudio Saavedra [EMAIL PROTECTED] wrote: El mar, 22-01-2008 a las 21:55 +1100, Peter E Dennis escribió: So I wondered if I needed to cast my GtkComboBoxEntry to a GtkComboBox but wasn't sure how to do this so I tried: gtk_combo_box_append_text(GTK_COMBO(cboVocSource), Hello World); This however makes matters worse as I get the above warning still when I compile it, but now when I run it I get: $ ./box (box:11338): GLib-GObject-WARNING **: invalid cast from `GtkComboBoxEntry' to `GtkCombo' Can someone please tell me what I'm doing wrong? You need to cast to a GtkComboBox, not to a GtkCombo. Use the GTK_COMBO_BOX macro. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBoxEntry Vs GtkComboBox
Thanks again Claudio for taking the time to explain that to me. Much appreciated. On 23/01/2008, Claudio Saavedra [EMAIL PROTECTED] wrote: El mié, 23-01-2008 a las 06:09 +1100, Peter E Dennis escribió: Thanks Claudio. I'm just wondering why do I use the GTK_COMBO_BOX macro and not the GTK_COMBO_BOX_ENTRY macro? Because gtk_combo_box_append_text () is a function that works on GtkComboBox objects, not GtkComboBoxEntry ones. As GtkComboBoxEntry inherites from GtkComboBox, you can use functions from the parent class in your GtkComboBoxEntry instance, but you need to cast it, given that C can't do it itself. A little pain of using GObject and C :-) Claudio Many thanks, Peter. On 23/01/2008, Claudio Saavedra [EMAIL PROTECTED] wrote: El mar, 22-01-2008 a las 21:55 +1100, Peter E Dennis escribió: So I wondered if I needed to cast my GtkComboBoxEntry to a GtkComboBox but wasn't sure how to do this so I tried: gtk_combo_box_append_text(GTK_COMBO(cboVocSource), Hello World); This however makes matters worse as I get the above warning still when I compile it, but now when I run it I get: $ ./box (box:11338): GLib-GObject-WARNING **: invalid cast from `GtkComboBoxEntry' to `GtkCombo' Can someone please tell me what I'm doing wrong? You need to cast to a GtkComboBox, not to a GtkCombo. Use the GTK_COMBO_BOX macro. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Claudio Saavedra [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Weird problems: C library programs crashing in combination with GTK UI
Hi,
Alternatively, you can use the new gdk_threads_add_timeout() available
in GTK 2.12. It's a GDK thread safe drop-in-replacement for
g_timeout_add().
Thanks,
Michael
On 23/01/2008, Tristan Van Berkom [EMAIL PROTECTED] wrote:
2008/1/22 [EMAIL PROTECTED]:
[...]
Pseudo code for my call back function [for some button which will initiate
action] is as follows:
/***CALL BACK FUNCTION CODE SNIPPET ***/
g_timeout_add(1500,progress_timeout,progressbarwidget);
f1();//THE BIG FUNCTION WHICH WILL RUN CLOSE TO A FEW HOURS
while (gtk_events_pending ())
{
g_print([.]);
gtk_main_iteration ();
}//THIS SO THAT THE TIME OUT FUNCTION WILL BE ABLE TO CALL ITSELF
/END CALL BACK FUNCTION CODE
SNIPPET**/
Gtk+ runs in a single thread, you must return to the mainloop that
you are running (in gtk_main()) in order for your callbacks to be called.
If you dont want to split up f1(); into iterations and run those short
iterations from a timeout function, then you might consider using GThread.
You can also use the old hack:
while (gtk_events_pending ())
gtk_main_iteration ();
to run the mainloop recursively so to speak, but if you never call
gtk_main_iteration() until you are finished f1(); then you are not
pushing progress bars.
Cheers,
-Tristan
___
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
problems changing a GtkImage
I am attemping to make a basic image viewer in Linux, (app checks a hard coded directory, puts *.jpg file names in a GtkMenu object, displays the names in a GtkOptionMenu widget. Selecting a file name will display the image in a GtkImage widget. When I hardcode the specific file names, I can get the GtkOptionMenu to list the files. The default (top/first) file automatically displays in the GtkImage widget as expected. But, selecting a different image does not change the GtkImage, it remains static, stuck on the first image. What am I doing wrong? I tried using g_object_set_data to change the file parameter of the GtkImage object as part of my changed signal handler from the GtkOptionMenu, but this doesn't do anything, or causes weird crashes, or gives compile time errors. This is a very simple fancy hello world for me and I'm totally stuck.\ Thank you in advance for any help or suggestions with this simple but frustrating example. P.S. Is there a good GTK/Glib/Gobject tutorial other than those at gtk.org and in The Official GNOME 2.0 Developer's Guide? I could really use something as well written as Mastering Perl/Tk. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ recent manager and RTL issues
On Mon, 2008-01-21 at 18:51 -0500, Behdad Esfahbod wrote: I sure hope ebassi can be talked into adding the widget needed for those apps to GTK+... as I said, I'd gladly review an inline GtkRecentChooser implementation. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pango_layout_set_height()
Am Dienstag, den 22.01.2008, 05:14 -0500 schrieb Behdad Esfahbod: - Most of the time you have allocated height and that's positive. So this is relevant only in size_request(), not size_allocate(). In size_request() it's probably a very valid argument, but one may still use 2*font_metrics.height. Which one is more common (using actual text, or font metrics). Damn, you are more clever than me. Guess this would be sufficient for calendar details. 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: GTK+ recent manager and RTL issues
On Mon, 2008-01-21 at 18:51 -0500, Behdad Esfahbod wrote: D) Another fix, not easy to implement right now: ELIF +-+ |NEPO | +-+ |txt.OLLEH .1 | |hello.txt .2 | | hello world.txt .3 | |it was a dream... .4 | +-+ Case (D) is not easy to implement right now. It needs ones to render the number and the filename as separate fields. I plan to add pango attributes to make it easier, like in HTML for example. This is the tracker for that: http://bugzilla.gnome.org/show_bug.cgi?id=70399 Note that if you knew the direction of the subtext, you could get away with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral bid embedding character in Unicode. So needs to be implemented in markup. You could insert a tab, right? Unfortunately, then you'd get the space from a tab as well... - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Hosting Windows Binaries
Mohammed Sameer wrote: On Wed, Jan 09, 2008 at 09:44:01AM +, Martyn Russell wrote: Murray Cumming wrote: HTML is slightly more likely to be kept-up-to-date than DocBook. However, no FAQ is likely to be kept up to date unless it's very easy to edit/comment. Well, given the new site has proper CSS and HTML separation, editing the FAQ will be no harder to edit than the docbook SGML. Why not a CMS then ? No flame please. Just wondering... Well, that would probably be ideal and perhaps possible if the hardware was permitting but it isn't and as we found from this recent thread: http://mail.gnome.org/archives/gtk-devel-list/2008-January/msg00047.html no sysadmins seems to be stepping forward regarding this. As a result, this will have to wait. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Website Review - Listing Core Maintainers
Hi, I have been toying with the idea and asking people's opinions on keeping a list of core maintainers on the new GTK+ website (which will be up for final review this weekend hopefully). The idea here is to list people and their affiliation. On the current pages we list a handful of people which have been highly involved in some of today's core widgets. This list of contributors is slightly out of date and could do with some amendments. What are people's opinions on this? The plan would be to have something like (excuse the ASCII art): Core Maintainers | Affiliation -- Tim Yanik| Imendio AB Matthias Clasen | Red Hat ... I am willing to keep this list up to date being the maintainer for the GTK+ web pages, however, it would require some notification from the current core maintainers to know when we should add or remove people from that list. This is not likely to be often and any one could do it of course. This list should ideally be suggested and agreed upon by the core maintainers. I personally think this is a good idea. The tricky part of course, is deciding who is on that list. I am sure the core maintainers have a good idea of who should be included. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ recent manager and RTL issues
On Tue, 2008-01-22 at 08:30 -0500, Owen Taylor wrote: On Mon, 2008-01-21 at 18:51 -0500, Behdad Esfahbod wrote: D) Another fix, not easy to implement right now: ELIF +-+ |NEPO | +-+ |txt.OLLEH .1 | |hello.txt .2 | | hello world.txt .3 | |it was a dream... .4 | +-+ Case (D) is not easy to implement right now. It needs ones to render the number and the filename as separate fields. I plan to add pango attributes to make it easier, like in HTML for example. This is the tracker for that: http://bugzilla.gnome.org/show_bug.cgi?id=70399 Note that if you knew the direction of the subtext, you could get away with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral bid embedding character in Unicode. So needs to be implemented in markup. You could insert a tab, right? Unfortunately, then you'd get the space from a tab as well... Humm, that's very true. Setting tab stop on the layout does the trick then. Something like that should work. I probably go make negative tab stops count as number of spaces... Thanks for the idea! - Owen -- 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: GTK+ recent manager and RTL issues
On Tue, 2008-01-22 at 12:38 -0500, Behdad Esfahbod wrote: On Tue, 2008-01-22 at 08:30 -0500, Owen Taylor wrote: On Mon, 2008-01-21 at 18:51 -0500, Behdad Esfahbod wrote: D) Another fix, not easy to implement right now: ELIF +-+ |NEPO | +-+ |txt.OLLEH .1 | |hello.txt .2 | | hello world.txt .3 | |it was a dream... .4 | +-+ Case (D) is not easy to implement right now. It needs ones to render the number and the filename as separate fields. I plan to add pango attributes to make it easier, like in HTML for example. This is the tracker for that: http://bugzilla.gnome.org/show_bug.cgi?id=70399 Note that if you knew the direction of the subtext, you could get away with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral bid embedding character in Unicode. So needs to be implemented in markup. You could insert a tab, right? Unfortunately, then you'd get the space from a tab as well... Humm, that's very true. Setting tab stop on the layout does the trick then. Something like that should work. I probably go make negative tab stops count as number of spaces... Thanks for the idea! Actually thinking again and trying in fribidi, no. The fact that the number is on the right of the text means that base direction of the text is RTL. And that means the ellipsis goes on the left side of the text unless an LRM is inserted at the end. -- 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: GtkStatusbar and its GtkBox interface.
Xan wrote: ... It's probably possible to add yet another workaround to this, but I agree with you that a cleaner design would be much better. If you have any ideas feel free to re-open the bug and comment there or post some patch. Cheers! I have a hack in place for the moment, but I may be able to have a look at this a little later. I have been thinking though, you are welcome to think with me: On the one hand, we want GtkStatusbar to support the interface of GtkHBox. On the other hand we want the outer-most graphics to be drawn by GtkFrame. So you want to derive from GtkHBox for its interface, but you don't want it to be (isa) an hbox, rather a label. Are there other places in GTK+ where these multiple-inheritance questions pop up? What is the resolution? I think inheriting the right API is the most important, so let's keep it that way. I see two solutions then: 1) Have GtkStatusbar draw its own frame (code duplication) 2) Re-implement/override the virual functions and forward the calls to an hbox that lives inside the frame. I feel most for 2) but there will be a lot of functions with trivial contents. And what happens when sometime the parent API is extended and GtkStatusbar left untouched...? Regards, Bastiaan. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ recent manager and RTL issues
- One can argue that a better fix would be for LTR filenames to render LTR, but alinged to left margin. The fix for that one would be very easy too. I oppose this...It breaks the flow of the numbered list, that's the point of it after all (besides shortcuts). B) After your patch: ELIF +-+ |NEPO | +-+ |txt.OLLEH .1 | |hello.txt .2 | | hello world.txt .3 | |...it was a dream .4 | --- WRONG +-+ Good catch, I honestly haven't thought of this. However, I'm concerned about how many files have trailing dots after all. I don't wanna try find | grep \.\.\., but there is a low chance any file is going to turn up in my rather gigantic setup, or any file having neutral character ending at all. I can't think of any that are used. It's a valid pitfall, but should we compromise the look of every RTL app because of the potential of this (very) rare file ending? I know, I know, half solutions and hacks are bad, but what happens with RTL bugs is that they sit in a Paralysis by Analysis mode for way too long. The bug you linked below is there for literally 6 years. This is mainly due to lack of contributors with RTL knowledge and the time to fix these bugs. Those who do know them are already overwhelmed with stuff to do (like you) or not experienced enough (yet) to tackle them (like me) :) And after all, these patches will be completly overriden with new code once a new inline widget is in place, or bug #70399 is fixed. So: temporary solution at least. Case (D) is not easy to implement right now. It needs ones to render the number and the filename as separate fields. I plan to add pango attributes to make it easier, like in HTML for example. This is the tracker for that: http://bugzilla.gnome.org/show_bug.cgi?id=70399 Note that if you knew the direction of the subtext, you could get away with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral bid embedding character in Unicode. So needs to be implemented in markup. Just food for though: Another possibility is making the menu itself into two subwidgets, kind of how it is done now with : Open CTRL+N With directional span's, one would still need to sycle between RTL and LTR possibilities: an LTR interface with an RTL filename has the same problem (in the opposite direction). To use your illustration with CAPS as RTL characters. 1. file.txt MILAF.NAS .2 So one needs to account for that. Unless the span auto adjusts according to parent widget direction, is that your plan? I started fixing this by patching the applications directly, forcing them to make the menu item to be RTL by using RLM. Please CC me to all such bugs. We really, really, should keep RTL-specific code minimized and limited to as few modules as possible. Apps definitely should not have to deal with this particular bug for example. You know, I do have the same mentality. I wouldn't like to hack and patch every app with dirty RTL code while it could be fixed at the source higher level. I initially thought that me proposing a non standard widget to GTK+ is a near impossible and compilcated task . That's (obiously) false with Emmanuele's email. I'll open a bug for an inline recent menu list. Regards, Djihed ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ recent manager and RTL issues
On Tue, 2008-01-22 at 22:47 +, Djihed Afifi wrote: - One can argue that a better fix would be for LTR filenames to render LTR, but alinged to left margin. The fix for that one would be very easy too. I oppose this...It breaks the flow of the numbered list, that's the point of it after all (besides shortcuts). Shortcuts is a valid point, but other than that it's personal taste I guess. B) After your patch: ELIF +-+ |NEPO | +-+ |txt.OLLEH .1 | |hello.txt .2 | | hello world.txt .3 | |...it was a dream .4 | --- WRONG +-+ Good catch, I honestly haven't thought of this. However, I'm concerned about how many files have trailing dots after all. I don't wanna try find | grep \.\.\., but there is a low chance any file is going to turn up in my rather gigantic setup, or any file having neutral character ending at all. I can't think of any that are used. I regularly edit text files without any extension. Brackets are common as well. Anyway, I'm not a huge fan of exchanging one bug for another. It's a valid pitfall, but should we compromise the look of every RTL app because of the potential of this (very) rare file ending? No, who said we should compromise? Also, if you want to do that, a cleaner fix would be to just turn auto-dir off on menu items. That's probably a right thing to do anyway. if (gtk_widget_get_default_direction()) should remain to an absolute minimum. What's the point of automatic RTL layout support in GTK+ if every app has to do such things... I know, I know, half solutions and hacks are bad, but what happens with RTL bugs is that they sit in a Paralysis by Analysis mode for way too long. That's not true. We don't have any major RTL issues in our platform. That's where I really cared about. For apps, bugs have been easily fixed when someone cared enough to write a patch. The bug you linked below is there for literally 6 years. This is mainly due to lack of contributors with RTL knowledge and the time to fix these bugs. Those who do know them are already overwhelmed with stuff to do (like you) or not experienced enough (yet) to tackle them (like me) :) No, lack of interest mostly. I was theoretically interested in that bug, because I want to have Pango be feature-complete, but I never had concrete examples of where that support is useful except for the GAIM message dialog. Now I see more reason to fix it. Make sure you check out these slides of mine btw: http://behdad.org/download/Presentations/bidi-layouts/ What I'm trying to say is, when you have a bug, come ask for the right question first, only if it's not feasible think about workarounds. Any workaround is two days for your to come up with, but 5 years before someone finds about it and fixes it properly. Like someone said very appropriately, any such fix leaves a scar in the project. And after all, these patches will be completly overriden with new code once a new inline widget is in place, or bug #70399 is fixed. So: temporary solution at least. What if we never get there? When we want to properly fix it, we have to fix 10 places. If it was a perfect fix, I'd had no problem with it going in ten places. Ten hacks is ten times more than one hack though. Case (D) is not easy to implement right now. It needs ones to render the number and the filename as separate fields. I plan to add pango attributes to make it easier, like in HTML for example. This is the tracker for that: http://bugzilla.gnome.org/show_bug.cgi?id=70399 Note that if you knew the direction of the subtext, you could get away with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral bid embedding character in Unicode. So needs to be implemented in markup. Just food for though: Another possibility is making the menu itself into two subwidgets, kind of how it is done now with : Open CTRL+N With directional span's, one would still need to sycle between RTL and LTR possibilities: an LTR interface with an RTL filename has the same problem (in the opposite direction). To use your illustration with CAPS as RTL characters. 1. file.txt MILAF.NAS .2 So one needs to account for that. Unless the span auto adjusts according to parent widget direction, is that your plan? I don't have a concrete plan yet, but yes, whatever plan I come up with will both both cases. I started fixing this by patching the applications directly, forcing them to make the menu item to be RTL by using RLM. Please CC me to all such bugs. We really, really, should keep RTL-specific code minimized and limited to as few modules as possible. Apps definitely should not have to deal with this particular bug for example. You know, I do have
Seg Fault using offscreen patch
hi
i am trying to use the offscreen patch that is available at
http://bugzilla.gnome.org/show_bug.cgi?id=318807
http://bugzilla.gnome.org/show_bug.cgi?id=318807
some times i get segfault while pressing a button or checking a check box (i
have tried with these two widgets till now)
Actually i am trying to use a clutter-stage embedded in a GtkWindow and than
i take snapshot of the window and try to display it on clutter stage.
heres is the gdb o/p
Continuing.
Breakpoint 2, gdk_event_translate (display=0x3c, event=0x0,
xevent=0xbebb1c38, return_exposes=12582937) at gdkevents-x11.c:894
894 if (_gdk_default_filters)
(gdb) s
873 {
(gdb) n
894 if (_gdk_default_filters)
(gdb)
878 GdkWindowImplX11 *window_impl = NULL;
(gdb)
873 {
(gdb)
890 window = NULL;
(gdb)
894 if (_gdk_default_filters)
(gdb)
873 {
(gdb)
894 if (_gdk_default_filters)
(gdb)
887 return_val = FALSE;
(gdb)
873 {
(gdb)
883 GdkToplevelX11 *toplevel = NULL;
(gdb)
873 {
(gdb)
892 event-any.window = NULL;
(gdb)
881 GdkScreen *screen = NULL;
(gdb)
882 GdkScreenX11 *screen_x11 = NULL;
(gdb)
894 if (_gdk_default_filters)
(gdb)
763 if (event-type = KeyPress
(gdb)
811 for (tmp_list = display_x11-event_types;
(gdb)
759 {
(gdb)
811 for (tmp_list = display_x11-event_types;
(gdb)
763 if (event-type = KeyPress
(gdb)
766 *filter_window = event-xany.window;
(gdb)
767 switch (event-type)
(gdb)
766 *filter_window = event-xany.window;
(gdb)
767 switch (event-type)
(gdb)
803 *event_window = event-xany.window;
(gdb)
914 window = gdk_window_lookup_for_display (display, xwindow);
(gdb)
918 if (window !GDK_IS_WINDOW (window))
(gdb)
914 window = gdk_window_lookup_for_display (display, xwindow);
(gdb)
918 if (window !GDK_IS_WINDOW (window))
(gdb)
925 if (filter_xwindow == xwindow)
(gdb)
926 filter_window = window;
(gdb)
925 if (filter_xwindow == xwindow)
(gdb)
934 if (window)
(gdb)
936 screen = GDK_WINDOW_SCREEN (window);
(gdb)
938 toplevel = _gdk_x11_window_get_toplevel (window);
(gdb)
936 screen = GDK_WINDOW_SCREEN (window);
(gdb)
938 toplevel = _gdk_x11_window_get_toplevel (window);
(gdb)
944 if ((xevent-type == KeyPress ||
(gdb)
937 screen_x11 = GDK_SCREEN_X11 (screen);
(gdb)
944 if ((xevent-type == KeyPress ||
(gdb)
937 screen_x11 = GDK_SCREEN_X11 (screen);
(gdb)
944 if ((xevent-type == KeyPress ||
(gdb)
948 window_private = display_x11-keyboard_xgrab_window;
(gdb)
958 if (toplevel xwindow == toplevel-focus_window)
(gdb)
953 window_impl = GDK_WINDOW_IMPL_X11 (window_private-impl);
(gdb)
Program received signal SIGSEGV, Segmentation fault.
gdk_event_translate (display=0x310088, event=0x312240, xevent=0xbebb1c38,
return_exposes=0) at gdkevents-x11.c:953
953 window_impl = GDK_WINDOW_IMPL_X11 (window_private-impl);
(gdb) bt
#0 gdk_event_translate (display=0x310088, event=0x312240,
xevent=0xbebb1c38, return_exposes=0) at gdkevents-x11.c:953
#1 0x404b9d60 in _gdk_events_queue (display=0x310088) at
gdkevents-x11.c:2297
#2 0x404b9f58 in gdk_event_dispatch (source=0x3, callback=0xc00019,
user_data=0x313a20) at gdkevents-x11.c:2358
#3 0x4079b750 in IA__g_main_context_dispatch (context=0x305338) at
gmain.c:2061
#4 0x4079d4f4 in g_main_context_iterate (context=0x305338, block=1,
dispatch=1, self=0x3dfcd8) at gmain.c:2694
#5 0x4079d854 in IA__g_main_loop_run (loop=0x492c58) at gmain.c:2898
#6 0x4024b7e0 in IA__gtk_main () at gtkmain.c:1144
#7 0xa7b8 in main (argc=1, argv=0xbebb1e34) at theme_main.c:318
(gdb) p window_impl
$1 = (GdkWindowImplX11 *) 0x0
--
View this message in context:
http://www.nabble.com/Seg-Fault-using-offscreen-patch-tp15035647p15035647.html
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
