Re: Multi-threaded UI Freezes on GDK Call
On Tue, 18 Dec 2007 22:52:23 +0100 G Hasse [EMAIL PROTECTED] wrote: The wrong thing is trying to do threads! Why Why Why are all people doing this thread programing! I am convinced that with a propper design of your application, maybe in several processe, you don't need threads and your problem will go away... No, threads are not the problem. Not keeping ALL GUI-related things in ONE thread is the problem. I may have been missing the point, but it seems that this is the core of the OP's troubles. The problem with threads is that few beginners understand what they actually are. --D. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 20:37 -0500, Michael McCann wrote: Yes, I've already tried that, to no avail. My code basically only consists of: gdk_screen_get_default(): Get the default screen gdk_screen_get_root_window(): Get the root window gdk_pixbuf_get_from_drawable(): Get a pixbuf from the entire screen gdk_pixbuf_save_to_bufferv(): Save the pixbuf to a buffer. taking a screenshot of the root window takes a considerable amount of time, depending on the size of the screen and the amount of windows on it. gnome-screenshot forks in the background to avoid blocking the UI; since GDK cannot be called from multiple threads, forking is the only option you have. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Button Callbacks
Vroni wrote: Hi guys, I have this really dumb problem, but I can´t get my head around it. My program should do the following: - When a button is pressed, a specific playlist[m3u]-file should be opened in the media player. Sure, the first part is to add a callback for the buttons, but how do I open the file (and with it the media player. It should do the same as a double click on the file would)? Is it even possible to do do it this way? In a terminal, you'd do: $ xdg-open /path/to/playlist.m3u In your callback you'd probably want to use system() or g_spawn_async(), see the man pages and http://www.gtk.org/api/2.6/glib/glib-Spawning-Processes.html tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: App blueprint, advice please!
Patrick wrote: Lets say a customer had a detector and a pump to pump a sample through it. We could write a Bash script that works something like this: -icon launches Bash script -sends variable 2 to pump command to pump 2 ml per minute -pump command sends signal to serial port or GPIB bus, etc -bash sends variable 230 to set the detector to wavelength 230 nm -bash autozeros detector -launches plot command -after that launches data process command -then launches database storage command - emails whoever, turns your coffee maker on or whateveretc..etc Seems to me that the lingua franca of this kind of scientific instrument control and data collection is LabView. Most institutions already have site license for this software. LabView is ideal for several reasons: - Works with most GPIB cards, indeed most interface cards come with labview drivers - Easy graphical environment. Lets you chain things together (in a similar manner to bash, actually), but it's all within the program, rather than kludging together non-integrated programs. Plus it's all in-process. No external spawning things needed, which is expensive. - Royalty free code. You can sell you vi programs or give them away, or whatever. They aren't compiled, but can be obfuscated, or not. So you could sell labview code that people could modify. On the other hand, there's no reason why you couldn't use GTK and, say, Python to do similar things provided that you have drivers for the GPIB boards, and have a well-defined interface that you can use to easily build modules that you can string together. Certainly I don't believe C is the appropriate language to do any gluing. I would recommend python. Data collection modules that need to be close to the hardware can be done in C, but the rest could easily be done in python. If you defined a protocol for modules to communicate with each other, then you can very easily string modules together, hooking data out buses on one module (object) with the data in on another module. The GTK signals and slots mechanism would make this quite easy to do, all in-process. Michael It's a terrible over simplification but hopefully illustrates the idea. I only have a few hundred dollars to put towards this now but hopefully by the later half of 2008 it will be a few thousand. Please feedback with any thoughts you might have on this whole process. Thanks-Patrick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Michael Torrie Assistant CSR, System Administrator Chemistry and Biochemistry Department Brigham Young University Provo, UT 84602 +1.801.422.5771 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problems to compile gtk with jhbuild + imendio patchs
Hi guys, Sorry if is the wrong place to post this, but im having problems in compile Gtk with Quartz support through imendio patchs using jhbuild, All packages compiles very well, but when i try compile gtk i have this error: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../modules/other -I../../../gdk -I../../../gdk -I../../../gtk -I../../../gtk -DGTK_VERSION=\ 2.15.0\ -I/opt/gtk/include -D_REENTRANT -I/opt/gtk/include/glib-2.0-I/opt/gtk/lib/glib- 2.0/include -I/opt/gtk/include/pango-1.0 -I/opt/gtk/include/cairo -I/opt/gtk/include/libpng12 -I/opt/gtk/include/atk-1.0 -DG_ENABLE_DEBUG -DG_ERRORCHECK_MUTEXES -DG_DISABLE_DEPRECATED -O -gstabs+3 -std=gnu89 -Wall -MT libgail_la-gailwindow.lo -MD -MP -MF .deps/libgail_la-gailwindow.Tpo -c gailwindow.c -fno-common -DPIC -o .libs/libgail_la-gailwindow.o gailwindow.c: In function 'gail_window_get_name': gailwindow.c:349: warning: passing argument 1 of 'gtk_container_get_children' from incompatible pointer type gailwindow.c:1093:2: error: #error Port to this GDK backend make[5]: *** [libgail_la-gailwindow.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I try find something in google but no success. If i remove the #if GDK_WINDOWING_WIN32 things, compiles but then when i try link others librarys ldconfig throws a error. Any idea whats wrong ? Cheers -- A fé remove montanhas, mas eu prefiro a dinamite ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 00:58 -0500, David Zeuthen wrote: Hi, Here's a new set of patches http://people.freedesktop.org/~david/gio-4.patch http://people.freedesktop.org/~david/gvfs-4.patch http://people.freedesktop.org/~david/nautilus-4.patch There's a description in ChangeLog and comments below I commited this with some small changes: Renamed fuse_name to stable_name Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor. OK, I've fixed this. Was simply a typo where the value was used instead of the key in g_hash_table_remove(). Sweet. I don't see an obvious easy solution. It requires some work. The ideal thing to match with is an GMountSpec (which is basically the set of key-value pairs that define a gvfs mount). For a GDaemonMount this is availible in the GMountInfo object. Thats a gvfs-specific object though, so we can't make that availible in the base GVolume apis. What if we add some new vtable calls in GVolumeMonitor like find_volume_for_new_mount() and find_mount_for_new_volume() which we have GUnionVolumeMonitor call on the installed backends when new, unowned volume/mounts are added. I think I've come up with a pretty nice solution; see the new function g_volume_monitor_adopt_orphan_volume() in the gio patch. I'm thinking this can also be used for the favorite servers like we have today in gnome-vfs; e.g. we just implement a volume monitor that creates GVolume objects that matches a list in gconf. Then when the mount is actually created the volume monitor adopts the DaemonMount in it's adopt_orphan_mount() function. So, can there never be a situation where the GMount gets created before the corresponding GVolume object is? And in that case, how does the GVolume locate the mount? Other thoughts / questions about the API - Busy mounts. Right now the cdda:// backend refuses to unmount if there are open files on it. I think that's probably the right thing to do for any backend. Probably means we need to add flags to the unmount() calls; the flags used in Linux, e.g. - force unmount - lazy unmount comes to mind. While I can sort of see the usecases for these, aren't we sort of overcomplicating the API here? Is this really required? When and how would the user force unmount or lazy unmount something? (Or the reverse, if there is a case for one of these when should we not do it.) - Further, if a mount can't be unmounted because it's busy (and we can't avoid that since we support mounts backed by kernel drivers), we probably want something like lsof(8) that Nautilus and other stuff can use to put up a dialog showing what apps is blocking the unmount. How about a list_open_files() method on GMount() that returns an array of - process id (is that portable? maybe need an abstraction) - icon - name - etc. Would need backend support for this too. Now we're getting into really lowlevel bizarro things. I don't think we should really expose this in a generic API. Can't this just be reported in the error message for the G_IO_ERROR_BUSY error when unmounting. I.E. the error dialog would say Cannot unmount, because firefox (pid 35) is keeping files open on the volume, or Cannot unmount, because 13 applications are keeping open files on the volume.. Maybe in the last case we should at least give the name (and pid?) of one application so that you can make progress on unmount by killing that. - Mount options. Do we need this? At least for std file systems such as vfat and ntfs people still use it at least judging from bug reports. There's actually (very horrible) UI in gnome-mount for this crap http://people.freedesktop.org/~david/gm-prop/gm-prop2.png I don't know; maybe that's specific to each gvfs backend and the hal volume monitor. Ideally I want to ditch gnome-mount and just make the hal volume monitor call directly into HAL. I do believe we want some form of mount options. For instance, a very common request is to be able to specify the filename encoding of e.g. a ftp share. However, I don't think the right place for this is as API arguments for the mount call. Instead i think these are more like preferences for each mount point, that we can store somewhere and that gvfs automatically picks up each time you mount that particular share. I haven't sat down and worked out all the details about this though. - g_file_read() and g_file_read_async() probably needs to take a GFileReadFlags value. See my other mail about the cdda:// backend in this thread. pasted here: - have an operation on GInputFileStream to set/clear flags. Am unsure whether there should be a dedicated SKIP_SCRATCHED_AREA flag or whether it should overload a standard one. We should probably also default to !SKIP_SCRATCHED_AREA. Now, common sense dictates that it's probably not alright to add such public API to gio with the cdda:// backend
Re: g_format_file_size_for_display()
The practical use of such a function is to give the user a general idea of the size. Hence a 2.4% (k), 4.9% (m), or 7.4% (g) difference will not change the picture. However, something people need the full story. Therefore, the friendly application using such a function should probably consider having a tooltip telling the full story. That would be a good time to show things like read-only too. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkFileChooser and GVFS backend
On Dec 19, 2007 4:00 AM, Alexander Larsson [EMAIL PROTECTED] wrote: Yes, both of these are part of the long-term plan. However, we need to have the GtkFileSystem module for the next gnome module, as that will have the new glib, but not a new Gtk+. Talking about that... we need a plan for how to handle the gvfs filechooser backend for 2.22. I think it will be best to put it in libgnomeui, next to (or replacing) the gnome-vfs backend thats already there. After 2.22 we can look at moving it over to gtk itself, or doing something better. Does that sound reasonable ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Draw on a GtkFixed Widget with Cario and place some widgets inside?
Hi out there :) i have few questions i have to write a new tool for my work its something like a node based node editor so the nodes must be connect via splines and as content the node must have a tree view for the properties. So my first thought was to use GtkFixed get the drawable and draw something with cario on it and then place some treeviews widgets inside so do guys think it is possible? Concrete: 1) Can i draw on a GtkFixed with cario 2) Can i control the draw order from treeviews that the will draw after cario on the widget. I mean can i handle this with the realize signal and propagate it manual to the childs? without perm flushing? -- View this message in context: http://www.nabble.com/Draw-on-a-GtkFixed-Widget-with-Cario-and-place-some-widgets-inside--tp14421717p14421717.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
Re: Draw on a GtkFixed Widget with Cario and place some widgets inside?
On Dec 19, 2007 6:36 PM, Wolfman [EMAIL PROTECTED] wrote: i have few questions i have to write a new tool for my work its something like a node based node editor so the nodes must be connect via splines and as content the node must have a tree view for the properties. So my first thought was to use GtkFixed get the drawable and draw something with cario on it and then place some treeviews widgets inside so do guys think it is possible? Have you looked at GooCanvas? http://sourceforge.net/projects/goocanvas It's a Cairo canvas widget. I believe you can embed GTK+ widgets inside it. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Draw on a GtkFixed Widget with Cario and place some widgets inside?
jcupitt wrote: Have you looked at GooCanvas? ... I took a quick looks nice i could give try but that doesnt answer my question :) Cause if the things i mentioned above are possible i could make something smaller and leaner. -- View this message in context: http://www.nabble.com/Draw-on-a-GtkFixed-Widget-with-Cario-and-place-some-widgets-inside--tp14421717p14424216.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
Re: [gfvs] cdda backend
Hi again, Almost more questions than answers this time, sorry. Also no patch either since I wanted to hear your thoughts before doing the work. On Wed, 2007-12-19 at 11:43 +0100, Alexander Larsson wrote: I commited this with some small changes: Renamed fuse_name to stable_name Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor. Great, thanks! I'm thinking this can also be used for the favorite servers like we have today in gnome-vfs; e.g. we just implement a volume monitor that creates GVolume objects that matches a list in gconf. Then when the mount is actually created the volume monitor adopts the DaemonMount in it's adopt_orphan_mount() function. Btw, is this how we should implement it? Or did you have anything else in mind? I really miss my public_html @ p.fd.o link that comes up automatically - I use it a lot when doing screen shots to share. I think if we do the feature this way (a gvfs module that links in gconf) it can be written in a day or less. So, can there never be a situation where the GMount gets created before the corresponding GVolume object is? And in that case, how does the GVolume locate the mount? That's a good question; it's not supported in the API yet because that situation can never happen for the use I wrote it for (cdda:// backend). How about a another vtable entry in the GVolumeMonitor gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter, GMount *orphan); that each implementation can implement? Alternatively we can put this method on the GMount interface but that seems wrong since it's only something volume monitors would ever want to do. Other thoughts / questions about the API - Busy mounts. Right now the cdda:// backend refuses to unmount if there are open files on it. I think that's probably the right thing to do for any backend. Btw, what are you thoughts about this? I feel strongly this is the right thing to do .. otherwise you can lose data. I'd even go as far and say that the GVfsBackend base class should automatically return G_IO_ERROR_BUSY on unmount() when there are pending jobs. At least that would be the default unmount() operation unless you override it. Probably means we need to add flags to the unmount() calls; the flags used in Linux, e.g. - force unmount - lazy unmount comes to mind. While I can sort of see the usecases for these, aren't we sort of overcomplicating the API here? Is this really required? When and how would the user force unmount or lazy unmount something? (Or the reverse, if there is a case for one of these when should we not do it.) - Further, if a mount can't be unmounted because it's busy (and we can't avoid that since we support mounts backed by kernel drivers), we probably want something like lsof(8) that Nautilus and other stuff can use to put up a dialog showing what apps is blocking the unmount. How about a list_open_files() method on GMount() that returns an array of - process id (is that portable? maybe need an abstraction) - icon - name - etc. Would need backend support for this too. Now we're getting into really lowlevel bizarro things. I don't think we should really expose this in a generic API. Can't this just be reported in the error message for the G_IO_ERROR_BUSY error when unmounting. I.E. the error dialog would say Cannot unmount, because firefox (pid 35) is keeping files open on the volume, or Cannot unmount, because 13 applications are keeping open files on the volume.. Maybe in the last case we should at least give the name (and pid?) of one application so that you can make progress on unmount by killing that. Right, I definitely think we want the dialog to look something like this +---+ | Cannot unmount public_html @ p.fd.o, the following | | applications are still using it | | | | [icon] GEdit - Secret Stuff.txt[kill] | | [icon] GEdit - My Diary.txt[kill] | | [icon] Tomboy [kill] | | [icon] /bin/cat[kill] | | | | [Cancel] | +---+ (dunno what icon / wording to use for [kill] though. Maybe there could also be a [switch to] button that dismisses the dialog (or not?) and takes you to the application) Stuffing all these details into the GError doesn't seem at all reasonable. So I think a simple g_mount_list_open_files() function is what we need (need an async function too). Anyway, In fact, I think we want such a dialog in the next gtk+ release: GtkWidget *gtk_io_unmount_busy_dialog_new
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote:
Another thought: we probably need a way to learn more about the GDrive,
GVolume and GMount objects than just their names and icons. First, cf.
the network applet use, we need to know if the mount is networked or not
and if it is, what hostname is it using. Simple proposal
Attached are some unfinished patches that illustrate this idea; notes
- flags are replaced by textual strings (notice the resemblance to mime
types?)
- content sniffing happens in a thread when done async
- no actual sniffing is done; should be trivial to add though
- needs work in the drive classification bits.
- There's some other stuff I wanted to propose regardless of this
- get_id() on GDrive,Volume,Mount: needed to pass these around
- model,vendor on GDrive; some apps (notably the cd burner ones) will
need this for user selection when having multiple drives
Anyway, with this patch it should be simple to abuse the .desktop file
format and add something x-content/video to e.g. Totem's and mplayer's
desktop files. Then we can easily add machinery to the Preferred
Applications capplet for choosing the default video player and we can
finally get rid of this ugly entry boxes
http://people.freedesktop.org/~david/g-v-m-prefs.png
Ditto for the other x-content/* formats. This is a problem we haven't
been able to solve for three years...
If you like this idea, here are the next steps I'm going to do
- Finish the patch
- Propose x-content/* and x-drive/* types as a fd.o spec on xdg-list
- Make the directory sniffing code plug-in based
(I expect we want to update this code rather frequently, it's a
bit like shared-mime-info)
Anyway, the whole idea may be crack (I don't think so though), but you
can't accuse me of not thinking in a user document centric way with
this :-)
David
Index: gunixmount.c
===
--- gunixmount.c (revision 6163)
+++ gunixmount.c (working copy)
@@ -178,6 +178,14 @@
}
static char *
+g_unix_mount_get_id (GMount *mount)
+{
+ GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
+
+ return g_strdup (unix_mount-mount_path);
+}
+
+static char *
g_unix_mount_get_name (GMount *mount)
{
GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
@@ -393,6 +401,7 @@
{
iface-get_root = g_unix_mount_get_root;
iface-get_name = g_unix_mount_get_name;
+ iface-get_id = g_unix_mount_get_id;
iface-get_icon = g_unix_mount_get_icon;
iface-get_uuid = g_unix_mount_get_uuid;
iface-get_drive = g_unix_mount_get_drive;
Index: gdrive.c
===
--- gdrive.c (revision 6163)
+++ gdrive.c (working copy)
@@ -146,13 +146,35 @@
}
/**
+ * g_drive_get_id:
+ * @drive: a #GDrive.
+ *
+ * Get an opaque textual identifier that can be used to pass a
+ * reference to @drive between processes.
+ *
+ * Returns: a string containing @drive's id. The returned string
+ * should be freed when no longer needed.
+ **/
+char *
+g_drive_get_id (GDrive *drive)
+{
+ GDriveIface *iface;
+
+ g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+ iface = G_DRIVE_GET_IFACE (drive);
+
+ return (* iface-get_id) (drive);
+}
+
+/**
* g_drive_get_name:
* @drive: a #GDrive.
*
* Gets the name of @drive.
*
- * Returns: a string containing @drive's name. The returned
- * string should be freed when no longer needed.
+ * Returns: a string containing @drive's name. The returned string
+ * should be freed when no longer needed.
**/
char *
g_drive_get_name (GDrive *drive)
@@ -167,6 +189,50 @@
}
/**
+ * g_drive_get_vendor:
+ * @drive: a #GDrive.
+ *
+ * Gets the vendor of @drive.
+ *
+ * Returns: a string containing @drive's vendor or %NULL if no such
+ * name could be found. The returned string should be freed when no
+ * longer needed.
+ **/
+char *
+g_drive_get_vendor (GDrive *drive)
+{
+ GDriveIface *iface;
+
+ g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+ iface = G_DRIVE_GET_IFACE (drive);
+
+ return (* iface-get_vendor) (drive);
+}
+
+/**
+ * g_drive_get_model:
+ * @drive: a #GDrive.
+ *
+ * Gets the model of @drive.
+ *
+ * Returns: a string containing @drive's model or %NULL if no such
+ * name could be found. The returned string should be freed when no
+ * longer needed.
+ **/
+char *
+g_drive_get_model (GDrive *drive)
+{
+ GDriveIface *iface;
+
+ g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+ iface = G_DRIVE_GET_IFACE (drive);
+
+ return (* iface-get_model) (drive);
+}
+
+/**
* g_drive_get_icon:
* @drive: a #GDrive.
*
@@ -468,5 +534,65 @@
return (* iface-poll_for_media_finish) (drive, result, error);
}
+/**
+ * g_drive_get_classification:
+ * @drive: a #GDrive.
+ *
+ * A #GDrive is an abstraction of a storage device connected to the
+ * system. As many popular consumer electronic devices, such as
+ * phones, music and video players, GPS devices and so on appear to
+ * the operating
Re: On CJK font selection (was Re: [Fwd: Re: Request for review and advice on wqy-bitmap-fonts fontconfig settings])
Hi, My reply is followed below, inline... On Dec 17, 2007 7:22 AM, Behdad Esfahbod [EMAIL PROTECTED] wrote: [..tons of quasi-maths ...] Secondly, you said that contextual font selection is a cool feature, I am wondering what languages are beneficial from this feature? (I believe there are, but just want to know). Pretty much every non-Latin script. In some situations even the Latin script. Take the Unicode character U+002E FULL STOP, aka ASCII period. It is used in more than just Latin, in Arabic for example, in Hebrew, possibly in Indic and many other scripts. If it was not grouped with neighboring characters for font selection purposes all those people would have got their Arabic/Hebrew/... text assigned an Arabic/Hebrew/... font while the periods in at the end of sentences assigned a different (default Latin for example) font. The same happens for Latin under a document tagged as non-Latin. It's not a luxury thing. It's just how things are supposed to work. That means, font change depending on context is actually preferrred in some fonts or some langauges, is it? If that's true, then this would be a per-language preference, some want it, some don't. So does pango support toggling this behavior yet? (I guess not?) And if not, would it be planned in future release? The main font issue though, is that Chinese (Simplified, Traditional), Korean, and Japanese share some Unicode code points, but they require slightly different renderings. Now if you don't tell Pango which version is preferred, how can it know which font to choose? It explicitly doesn't prefer any one over the others to avoid cultural problems. The symptoms of this problem are multiple fonts used in the same line. Solution is: Either run under a CJK locale, or give hints to Pango about your preferred CJK locale using the env var PANGO_LANGUAGE. Note that theoretically Pango can do text analysis to come up with a best guess, but doing that would then introduce another bug with symptoms changes font when typing a few characters on the same line. Let me set the record straight here. Most people seeing this problem is not exactly complaining about the font changing, but about the font changing TO SOME BAD LATIN GLYPH THEY DON'T LIKE. It is understood that font changing is almost not avoidable, since typing just a few characters may not provide enough information on what kind of font should be picked, and typing more gives more info. So far it is determined per sentence, or per what? If this behavior can be toggled on a per-language basis, CJK users would not complain _THAT_ much. And note that this problem describes mixing CJK text with latin text. Move on. The second one: multiple fonts used in the same line. Exactly because pango doesn't heuristically determine the font, so everything is handed off to fontconfig. And fontconfig sets up a ladder, and whatever font on the highest position that fits for certain glyph is picked. This is my understanding so far, please correct me if I'm wrong. Sadly this way absolutely won't satisfy everybody -- one party only. And in particular, the font picked is determined per glyph, causing a sentence to be intermixed by multiple CJK fonts as described. What if the font determination is not chopped glyph by glyph, but also determined heuristically with context? If my guess is correct this would work most of the cases, even among language variants (think zh_CN and zh_TW). Except in one situation: when text from multiple language are used within single sentence (like introduction of foreign language), in which one font is chosen for the largest chunk of text fitting one single language, and another font for another language. Solutions don't necessarily contradict with each other: one is talking about mixing CJK text with latin text, and another is talking about intermixing of CJK text among themselves. Another symptom, digits change font after typing character is in fact a very cool Pango feature, just badmouthed by the above problem. Fix the problem. When a solution is not universal enough to be accepted by everybody, and caused more trouble then its worth for specific people, it would be badmouthed no matter what. Or not? I don't know the rule here. Abel As you see from the bug lists, this problem has existed for many years, and I am pretty sure that it will come back again and again, as long as the expected rendering is not achieved. If the current pango formatting logic is not sufficient to handle the CJK preferences as said above, I think to refine the logic to take it into consideration is better than stick with a fixed but incomplete logic. I consider patches improving Pango's font selection algorithm, but none that I've seen so far had been an improvement (from my point of view). If it has words like CJK or special case, I'm most probably not
Can I port gtk for BlackFin processor?
Hi everybody! Can I port gtk for BlackFin processor? How can I do that? I didn't find any document.Please help me. Thx! ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
About private elements on gtkcalendar
Hi, I was taking a look to the accessibility implementation for gtkcalendar: http://bugzilla.gnome.org/show_bug.cgi?id=321123 I have asked some questions there and on gnome-accessibility list, but as it is related to a gtk widget I will ask for help on this list too. I model each element (ie: days, day names, week numbers, ...) as individual cells (flyweight objects, new atk objects). My current problem is implement the complete AtkComponent interface. The calendar has some gdkwindows to draw itself, and each indivual element is drawed internally. Finally I was able to identify each internal gdk window using some positioning heuristic, but the problem is that I don't have access to the private position variables used to draw each element. For example, this code computes the day with: priv-day_width = (priv-min_day_width * ((allocation-width - (xthickness + INNER_BORDER) * 2 - (CALENDAR_MARGIN * 2) - (DAY_XSEP * 6) - CALENDAR_XSEP * 2)) / (7 * priv-min_day_width + priv-max_week_char_width * 2)); I suppose that I could replicate this formulaes on gailcalendar, but basically I'm talking about a copypaste, and this can envolve sync problems. There are a lot of formulaes and constants, so any change on gtkcalendar can outdate gailcalendar. And... well, I don't like the idea to have exactly the same code in different places ;) But in fact, probably this data has sense to be private, as it is used in very concrete points. Any idea, thought, opinion or hint about it? Thanks PD: at this moment Im using an aproximation, supposing that the cell have the same size and cover the whole gdkwindow. But it isn't a good idea anyway. -- API [EMAIL PROTECTED] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.12.3 (win32) and locales - not working
Thanks for the reply. I think I got closer to solving the problem. The thing is, the only things I upgraded when switching from 2.12.1 to 2.12.3 are gtk and glib dlls and gettext's intl.dll (from http://www.gimp.org/~tml/gimp/win32/downloads.html, gettext-runtime-0.17.zip). Now I took a clean 2.12.1 with working translations and only updated intl.dll (I was using gettext-0.14.5 previously). The translations stopped working. This was on a win2kpro (sp4 I think) machine. Then I moved the whole thing to winxp, and everything started working. So, to summarize, it seems to be the intl.dll / win2k problem. Tried running 2.12.3 with old intl.dll, but it complains about missing symbol (no surprise here). Thanks, Alexander ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Reg:Key event handling
Hi, I am developing an mobile application using GTK+ C programming,now I have an issue that there is no response for the key event handle for all the applications that I run.I am not able to handle the left and right keys and nor any keys. Please let me know how to resolve the issue Thanks in advance ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Reg:Key Event Handle
Am Mittwoch, den 19.12.2007, 10:15 +0530 schrieb [EMAIL PROTECTED]: Hi, I am developing an mobile application using GTK+ C programming,now I have an issue that there is no response for the key event handle for all the applications that I run.I am not able to handle the left and right keys and nor any keys. Please let me know how to resolve the issue Thanks in advance Hard to help you with that few information. As a wild guess: Did you call gtk_widget_add_events with the relevant flags on your widgets? Also notice, that you widget has its own GdkWindow associated to receive any X11 events. Did you consider using GtkEventBox? Hope this hints help you. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Can I port gtk for BlackFin processor?
Am Mittwoch, den 19.12.2007, 16:39 +0800 schrieb NalaGinrut: Hi everybody! Can I port gtk for BlackFin processor? How can I do that? I didn't find any document.Please help me. Not that I can confirm, that GTK+ runs on BlackFin processors, but once you got for instance Linux with X11 or DirectFB running, you should be able to compile GTK+ and applications for that platform. Google suggests that a BlackFin Linux Project exists: http://blackfin.uclinux.org/gf/ Or does your question target specific problems? 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkImageView
On 19/12/2007, muppet [EMAIL PROTECTED] wrote: If that still doesn't work, give us the url of an svn branch that has the current code. I understand what you say, but I can't find a prototype for SvDrawSettings (or for SvGtkStockItem in Gtk2/xs/GtkStock.xs). I've committed what I have to SVN at http://trac.bjourne.webfactional.com/browser/plgtkimageview/ Sorry for my continued stupidity. Jeff ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GtkImageView
On Dec 19, 2007, at 4:13 PM, Jeffrey Ratcliffe wrote: On 19/12/2007, muppet [EMAIL PROTECTED] wrote: If that still doesn't work, give us the url of an svn branch that has the current code. I understand what you say, but I can't find a prototype for SvDrawSettings (or for SvGtkStockItem in Gtk2/xs/GtkStock.xs). I should stop writing emails with toddlers around. ;-) A C function definition doubles as a prototype. I should've said signature rather than prototype. Sorry for the confusion. I've committed what I have to SVN at http://trac.bjourne.webfactional.com/browser/plgtkimageview/ I don't have a release version of gtkimageview handy, so this patch will build fine against the svn HEAD version of gtkimageview. It replaces all the occurrences of DrawSettings with GdkPixbufDrawOpts; adds the new rect parameter to gtk_iimage_tool_pixbuf_changed(); adds the file gtkimageview.typemap instead of creating build/perl.typemap in Makefile.PL (don't forget to svn add it); and, the important bit, adds a cast to this line: if (svp) settings-zoom_rect = * (GdkRectangle *) SvGdkRectangle (*svp); to fix the dereferencing `void *' pointer. You'll also want to hush the unused variable `class' warning by not including the line SV * class in the argument listing of gtk_image_view_new(). I think the secondary void value not ignored as it should be warning was just fallout from the compiler being confused about the void* pointer dereference. (And, yes, i think we ought to change Glib::CodeGen to fix this upstream.) plgtkimageview-svn.patch Description: Binary data -- One, two, free, four, five, six, sebben, eight, nine, ten, elebben, twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen, fiffeen, elebbenteen! -- Zella, aged three, counting to twenty. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
