monitoring file changes in a sysfs filesystem
Hi! I'm trying to monitor the changes in a file from /sys (as you know, it's a sysfs filesystem), but setting a file monitor with g_file_monitor_file doesn't work. No matter what I do, I can't receive the changed signal from the file monitor. Is there any other way I could do this? (of course, I could manually poll the file, but I would like to avoid that if possible) Thanks in advance! -- Miguel Gomez [EMAIL PROTECTED] Igalia - http://www.igalia.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to modify the GnomeDbDataWidgetInfo?
May be could be usefull to modify the code at GnomeDbDataWidgetInfo in order to add properties that allows to hide this objects, in order to share this functionality. 2008/9/17 Vivien Malerba [EMAIL PROTECTED] 2008/9/17 paragasu [EMAIL PROTECTED]: by default, gnome_db_form/gnome_db_grid widget create a set of control (GnomeDbDataWidgetInfo). To add or manipulate data. For my application, i only need the update button, i do not need the insert, add or the next record button. How to remove all button except the update button? Or how i can create my update button to do function exactly like the one used in the GnomeDbDataWidgetInfo update button. Hidding buttons is not supported by the GnomeDbDataWidgetInfo widget. However, there are several things you can do: 1) copy the source of GnomeDbDataWidgetInfo (rename it to be one of your widgets) and remove the unnecessary code, then pack together a GnomeDbRawGrid/Form with your new widget 2) pack a GnomeDbRawGrid/Form with a button of your own for which the callback function will call gnome_db_data_widget_perform_action(rawform/grid, GNOME_DB_ACTION_WRITE_MODIFIED_DATA) 3) use gnome_db_data_widget_set_write_mode(rawform/grid, GNOME_DB_DATA_WIDGET_WRITE_ON_VALUE_ACTIVATED) for example, in which case you don't need any button at all In any case you'll have to create a GnomeDbRawForm/Grid widget first. Hope this will help you, Vivien BTW: please use the Gnome-DB mailing list for questions related to libgda/libgnomedb. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (en trámite, pero para los cuates: LIBRE) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key handling problems
Thank you very much
I have a question:
Why I check GDK_MOD1_MASK and not another mask?
I want the control+j but not the lock caps+control+j neither
num lock+control+j etc.
Regards,
Perriman
El Wed, 17 Sep 2008 21:50:08 -0400 (EDT)
Allin Cottrell [EMAIL PROTECTED] escribió:
On Thu, 18 Sep 2008, Perriman wrote:
I'm trying to check if a user press some keys. I want to
check If the user press control+j. I'm having problems with it. I
paste my code:
guint key = self-priv-key;
if ((event-state self-priv-mod) == self-priv-mod
event-keyval == key)
{
x
}
Currently this code do:
1.- If the user has NumLk enabled works fine
2.- If the user has lock caps enable it doesn't work because the j
is not j is J (upper)
3.- The control check works fine
4.- If I press contro+alt+j works (It may fail because I want to
check control+j not control+alt+j)
5.- If I press contro+shift+j doesn't work because the j is not J
but the state check sais true
I have tried 1000 ways to do it, I have see a lot of code but I have
not luck
Can you help me? I'm desperated :(
If you're attaching to the key_press_event on some widget, you
can do something like this in your callback:
gboolean
catch_ctrl_j (GtkWidget *w, GdkEventKey *key, gpointer p)
{
GdkModifierType mods;
gdk_window_get_pointer(w-window, NULL, NULL, mods);
/* make the j/J case insensitive? */
if (gdk_keyval_to_upper(key-keyval) == GDK_J) {
if (mods GDK_CONTROL_MASK) {
printf(Got ctrl-j);
if (mods GDK_MOD1_MASK) {
printf(Got ctrl-alt-j);
}
}
}
return FALSE;
}
If you'e handling the keystroke and don't want the default handler
invoked, then return TRUE instead.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Key handling problems
On Fri, 19 Sep 2008, Perriman wrote: Thank you very much I have a question: Why I check GDK_MOD1_MASK and not another mask? I want the control+j but not the lock caps+control+j neither num lock+control+j etc. GDK_MOD1_MASK (usually) gives you the alt key, in case you want to screen that out (I thought you said something to that effect). As for the rest, check out the Gdk documentation, e.g. http://library.gnome.org/devel/gdk/stable/gdk-Windows.html Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib-2.81 /live-g-file/test_copy_move failed
make check results : /live-g-file/test_copy_move: do_copy_move: 'dir1/subdir' -- 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir1/subdir' -- 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir2' -- 'dir-target' do_copy_move: 'dir-target' -- 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir-target' -- 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'target-file' -- 'dir-target' do_copy_move: 'target-file' -- '.' res = 0, error code 2 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file': File exists do_copy_move: 'target-file' -- 'target-file' res = 0, error code 4 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file/target-file': Not a directory do_copy_move: 'target-file' -- 'not_exists' res = 0, error code 1 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/not_exists/target-file': No such file or directory do_copy_move: 'target-file' -- 'dir_no-access' ** ERROR:live-g-file.c:702:do_copy_move: assertion failed (res == FALSE): (1 == 0) FAIL Any idea what went wrong? Possibly on my side. -- Klaus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-2.81 /live-g-file/test_copy_move failed
Can you please let us know more? I.e. what operating system you run and which filesystem are the glib sources on. And in order to track this issue, can you please file a bug at http://bugzilla.gnome.org/ Also, the live-g-file test is a standalone executable with several options (posix tests, ...), you might want to experiment a little bit. -- Tomas Bzatek [EMAIL PROTECTED] On Thu, 2008-09-18 at 12:56 +0200, Klaus Dittrich wrote: make check results : /live-g-file/test_copy_move: do_copy_move: 'dir1/subdir' -- 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir1/subdir' -- 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir1/subdir' -- 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir2' -- 'dir-target' do_copy_move: 'dir-target' -- 'dir-target' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- '.' res = 0, error code 2 = Target file exists do_copy_move: 'dir-target' -- 'target-file' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'not_exists' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'dir_no-access' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'dir-target' -- 'dir_no-write' res = 0, error code 25 = Can't recursively copy directory do_copy_move: 'target-file' -- 'dir-target' do_copy_move: 'target-file' -- '.' res = 0, error code 2 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file': File exists do_copy_move: 'target-file' -- 'target-file' res = 0, error code 4 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/target-file/target-file': Not a directory do_copy_move: 'target-file' -- 'not_exists' res = 0, error code 1 = Error opening file '/mnt/md0/sources/glib-2.18.1/gio/tests/testdir_live-g-file/not_exists/target-file': No such file or directory do_copy_move: 'target-file' -- 'dir_no-access' ** ERROR:live-g-file.c:702:do_copy_move: assertion failed (res == FALSE): (1 == 0) FAIL Any idea what went wrong? Possibly on my side. -- Klaus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib has been branched
I have just created a glib-2-18 branch. Further stable 2.18.x releases will be made from that branch, while trunk receives new development towards 2.20. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ has been branched
I have just created a gtk-2-14 branch. Further stable 2.14.x releases will be made from that branch, while trunk receives new development towards 2.16/2.90. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-2.81 /live-g-file/test_copy_move failed
Tomas Bzatek wrote: Can you please let us know more? I.e. what operating system you run and which filesystem are the glib sources on. And in order to track this issue, can you please file a bug at http://bugzilla.gnome.org/ Also, the live-g-file test is a standalone executable with several options (posix tests, ...), you might want to experiment a little bit. Linux 2.6.26.5 #1 SMP PREEMPT Tue Sep 9 11:07:57 CEST 2008 x86_64 GNU/Linux current glibc gcc version 4.3.3 20080911 ext2 on raid-1 (mirror) make check was run as root, LC_ALL=C I will try to file a bug to this bugzilla monster. -- Klaus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Thu, Sep 18, 2008 at 4:36 AM, Sebastien Bacher [EMAIL PROTECTED] wrote: Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I've put this on the agenda for the next gtk team meeting on Sept 23. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
