Simple draw question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a situation where I need to highlight an eventbox when a user
enters it and unhighlight it when the users leaves. I'm using this code
but the color I'm drawing in the leave_button_callback is always wrong
and varies from run to run with the program. Any ideas what I am doing
wrong. I was looking for a XOR option or something but I don't see it.
gboolean enter_button_callback (GtkWidget *widget, GdkEventCrossing
*event, gpointer data)
{
GdkGC *gc;
gc = gdk_gc_new(widget-window);
gdk_draw_rectangle(widget-window, gc, FALSE, 0, 0,
widget-allocation.width-1,
widget-allocation.height-1);
gdk_gc_unref(gc);
return FALSE;
}
gboolean leave_button_callback (GtkWidget *widget, GdkEventCrossing
*event, gpointer data)
{
GdkGC *gc;
GdkGCValues v;
GdkColor color;
GdkColormap *map;
gc = gdk_gc_new(widget-window);
map = gdk_gc_get_colormap(gc);
gdk_gc_get_values(gc,v);
gdk_colormap_query_color(map,v.background.pixel,color);
gdk_gc_set_foreground(gc,color);
gdk_draw_rectangle(widget-window, gc, FALSE, 0, 0,
widget-allocation.width-1,
widget-allocation.height-1);
gdk_gc_unref(gc);
return FALSE;
}
- --
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7D0BD5D1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org
iD8DBQFGO7gy6w2kMH0L1dERAqmZAJ0UORbfl3tgr0wRdruDvk8yRNUrOwCbB/LQ
HwpMx+9hMb9iGwEX6WCr+KM=
=hEvS
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkImage problem
I have the following code, which comiles and displays the image yet I get the
following errors
Compile error
passing argument 1 of 'gtk_image_set_from_file' from incompatible pointer
type
Runtime errors
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: g_type_add_interface_static:
assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:12275): GLib-GObject-CRITICAL **: g_object_new: assertion
`G_TYPE_IS_OBJECT (object_type)' failed
(testreference:12275): Gtk-CRITICAL **: gtk_widget_show: assertion
`GTK_IS_WIDGET (widget)' failed
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include string.h
#include stdio.h
#include config.h
#include gtk/gtk.h
#include glade/glade.h
/*
* Standard gettext macros.
*/
#ifdef ENABLE_NLS
# include libintl.h
# undef _
# define _(String) dgettext (PACKAGE, String)
# ifdef gettext_noop
#define N_(String) gettext_noop (String)
# else
#define N_(String) (String)
# endif
#else
# define textdomain(String) (String)
# define gettext(String) (String)
# define dgettext(Domain,Message) (Message)
# define dcgettext(Domain,Message,Type) (Message)
# define bindtextdomain(Domain,Directory) (Domain)
# define _(String) (String)
# define N_(String) (String)
#endif
#include callbacks.h
/* For testing propose use the local (not installed) glade file */
/* #define GLADE_FILE
PACKAGE_DATA_DIR/testreference/glade/testreference.glade */
#define GLADE_FILE testreference.glade
void create_window (GtkWidget *window, GtkWidget *image)
{
GladeXML *gxml;
gxml = glade_xml_new (GLADE_FILE, NULL, NULL);
glade_xml_signal_autoconnect (gxml);
window = glade_xml_get_widget (gxml, window);
image = glade_xml_get_widget (gxml, image1);
}
void funcImage (GtkWidget *image)
{
gtk_image_set_from_file (image, /home/s/Pictures/space-05.jpg);
}
int
main (int argc, char *argv[])
{
GtkWidget *window = NULL;
GtkWidget *image = gtk_image_new();
#ifdef ENABLE_NLS
bindtextdomain (GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR);
bind_textdomain_codeset (GETTEXT_PACKAGE, UTF-8);
textdomain (GETTEXT_PACKAGE);
#endif
gtk_set_locale ();
gtk_init (argc, argv);
create_window (window,image);
gtk_widget_show (window);
funcImage(image);
gtk_main ();
return 0;
}
--
View this message in context:
http://www.nabble.com/GtkImage-problem-tf3694858.html#a10332372
Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: VFS integration with kernel mounts
On Thu, 2007-05-03 at 15:45 -0400, David Zeuthen wrote: On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote: The selection of whether to do local or remote i/o is done when instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile depending on the uri and the default GVfs instance loaded. However, the mapping from URI to what should be done with the file must be done by purely in-process non-blocking simple code. Anything complicated (and asking hal over dbus for a list of uuids and their paths is very complicated) will make the GFile API totally unsuitable for what applications normally do with it. (They will block all over the place in unexpected places and generally be very slow.) But instantiating a GFile itself surely can block? I mean, the application just don't know in advance what the URI is and if it's an URI to something that needs to be mounted it will block _anyway_ possibly asking the user for credentials. Oh, no. Instantiating a GFile is equivalent to parsing the URI. There is no i/o done in that. The value of GFile is that it abstracts the kind of stuff you do on pathnames and uris, so there is no need for the typical bug-ridden uri / pathname mangling wrt escaping, finding slashes etc. Blocking is only done when you dereference the GFile, such as when opening a file. If the media is available, we have the local mount point (e.g. /media/usbdisk) and use this for all the file operations. The aliasing problem aside, is there anything wrong with this approach? If using a uuid to address the files are so important, why can we not use the uuid as the mountpoint for the drive. Then we avoid aliasing and all applications gets the persistant-identifiers feature. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an uncontrollable guitar-strumming stage actor for the 21st century. She's a manipulative Buddhist bodyguard from a family of eight older brothers. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_object_get_property could return the GValue passed in, instead of void
Hi!
I don't know how much of an ABI break this would be, since all current
code ignores the non-existent return value of g_object_get_property.
OTOH, were we to have
GValue *g_object_get_property (GObject *object, const gchar
*property_name, GValue *value);
We could do nice things like
GValue val = {0, } ;
g_object_set (G_OBJECT (gtk_entry),
sensitive, g_value_get_boolean (
g_object_get_property (G_OBJECT (checkbox), active, val)),
NULL) ;
This expresses the relationship between the GtkEntry and the
GtkCheckButton quite clearly. In addition, if you were to switch to a
GtkToggleToolButton, for example, you wouldn't have to change the code
at all, because both have the active property.
Of course, it would be even nicer to just have a family of functions
g_object_get_type (object, property) similar to g_value_get_type,
because it would save us the GValue declaration.
Gabriel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Thu, 2007-05-03 at 15:18 -0400, David Zeuthen wrote: On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote: The way a normal application uses gvfs is by the gio apis. Essentially you hand over a uri, and this uri is parsed by custom uri-type specific code into a mount specification (info about a gvfs mountpoint) and a path into it. Each operation on this mount is sent to the right mount daemon for the particular mount, and if its not running it will just give a NOT_MOUNTED error. Thanks for the explanation. Do you expect apps using the gio API's to save the URI's (for e.g. recent files or a media database)? If so, they need to handle NOT_MOUNTED the next time they start up and load the URI from recent-files etc... Yes, URIs are still the best thing we have for user visible and persistent file identifiers, for all their ugliness. In the case when the media was not mounted one would get NOT_MOUNTED errors from gvfs. These errors are normally handled by the file manager or the file selector and Is there utility API so these apps (and both the file chooser and Nautilus) can use the same code [1]? The implementation of such (blocking) utility API should probably just be an D-Bus session bus service [2] (that would/could be activated on demand) under the hoods.. Yes, there will be a common utility class for handling all mount interaction. [2] : Since mounting/connecting the media might require asking for credentials you really want the code asking for this to be in a separate process... much like how gnome-keyring works ... in the future that helper process can be labeled with a trusted security context (or on non-SELinux you can look at exe paths) which means you can protect that window from input-event-stealing and even apply fancy WM decorations etc.. e.g. all the XACE work. On the contrary, you want the authentication to happen in the client that caused the authenticating i/o. That is because that client has to display things the right way depending on its state. For instance, you want dialogs to have the right parent, you want to handle modal dialogs opening authentication dialogs right, and you want the dialogs to be in the right window group. One of the big advantages with the mount model in gvfs (as opposed to gnome-vfs) is that we know when authentication will happed (at mounttime) and can handle it in a sane way in the app. In gnome-vfs authentication (including infinite blocking if the dialog appeared under your window, or lots of dialogs if e.g. listing various mountpoints) can happen at *any* i/o operation, which is not sanely handleable by the app. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a notorious Amish Green Beret who hides his scarred face behind a mask. She's a transdimensional motormouth schoolgirl looking for love in all the wrong places. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Thu, 2007-05-03 at 10:18 -0500, Jerry Haltom wrote: The selection of whether to do local or remote i/o is done when instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile depending on the uri and the default GVfs instance loaded. However, the mapping from URI to what should be done with the file must be done by purely in-process non-blocking simple code. Anything complicated (and asking hal over dbus for a list of uuids and their paths is very complicated) will make the GFile API totally unsuitable for what applications normally do with it. (They will block all over the place in unexpected places and generally be very slow.) If this is the case then you are saying that GFiles can simply refer to non existing resources, and only create IPC when the application attempts to use them? This seems reasonable. Sure, like a pathname or a uri can point to whatever. I guess there is a slight difference in that a GFile can't be not-well-formed. I.E. if you got a non-null GFile then it was a valid uri. There is also some level of uri canonicalization in the GFile (for instance wrt escaping). The implemenation of GFile is either GLocalFile: just a pathname or GDaemonFile: The uri is turned into a mount specification, selecting what gvfs mountpoint to use as root, plus a pathname to use relative to that mountpoint. The actual mapping of the mount specification to the entity on the dbus handling such mounts are done when the actual i/o operation happens. (And at that point you can get a not-mounted error.) At what stage is mounting considered? Translating a uri to a GFile doesn't mount anything, does it? I would say the HAL communication would occur when mounting the media path. Mounting seems like an explicitly blocking operation. Mounting is in almost all cases an explicit operation. I.E. you call some form of mount operation. There are a few cases where we do support automatic mounting on first i/o, like e.g. mounting computer://, but that should never happen if the mountpoint ever needs authentication, can fail, or if its costly, because applications don't really expect such behaviour. All mount operations in gvfs are explicitly async, so that they can do authentication nicely and integrate well with a gui like gtk+. The canonical example where automounting causes trouble is listing a bunch of remote locations in the nautilus sidebar. You don't want to open 20 authentication dialogs the first time you open the window because nautilus wanted to stat the locations in the sidebar to get the icon for them. [Although there are other problems too, see my old mail about the stateless of gnome-vfs being a problem.] This might sound a bit tricky for the apps to handle perhaps, but in practice almost all handling of mounting will be handled by the file manager and the file selector, similar to how unix mounts are mainly ignored by apps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a gun-slinging Catholic grifter fleeing from a secret government programme. She's a virginal French-Canadian research scientist from the wrong side of the tracks. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
What's about the efficiency of using c to OOP compare to the c++'s abstraction?
reference to the c++'s father's interview http://www.artima.com/intv/abstreffi.html fortran and c++ can achive good performance for they can abstract in higher level and their compiler can think in higher level to avoid the cache miss (like in the array vs vector )or to achive the no code The gtk hasn't the gtk'compiler to help at the high level Optimization Then ,what's the power of gobject vs c++ with the compiler's Intelligence in OOP? any input will be appreciated ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_get_property could return the GValue passed in, instead of void
On Fri, 4 May 2007, Gabriel Schulhof wrote:
Hi!
I don't know how much of an ABI break this would be, since all current
code ignores the non-existent return value of g_object_get_property.
OTOH, were we to have
GValue *g_object_get_property (GObject *object, const gchar
*property_name, GValue *value);
We could do nice things like
GValue val = {0, } ;
where's your g_value_init? you cannot pass an uninitialized GValue into
g_object_get_property().
g_object_set (G_OBJECT (gtk_entry),
sensitive, g_value_get_boolean (
g_object_get_property (G_OBJECT (checkbox), active, val)),
NULL) ;
This expresses the relationship between the GtkEntry and the
GtkCheckButton quite clearly. In addition, if you were to switch to a
GtkToggleToolButton, for example, you wouldn't have to change the code
at all, because both have the active property.
well, if you correctly outline the missing g_value_init/g_value_unset
calls, the example is not so simple anymore...
in any case, feel free to file a bugzilla bug containing an implementation
patch for your requested feature.
Of course, it would be even nicer to just have a family of functions
g_object_get_type (object, property) similar to g_value_get_type,
because it would save us the GValue declaration.
Gabriel
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Thu, 2007-05-03 at 11:11 +0200, Benjamin Otte wrote:
Hi,
I had an initial look at gvfs in particular the Inputstream and
Outputstream implementations, and some comments came to my mind, in
particular about the API. So I thought I'd post them as early as
possible.
These comments are about the code in
http://www.gnome.org/~alexl/git/gvfs.git from today - May 2nd.
I should also note that these ideas are probably heavily influenced by
where I'm coming from - namely GStreamer and Swfdec - which involve
handling low level byte streams possibly caring about low latency. In
this particular case I had been wondering about making the basic
input/output objects in Swfdec GInput/OutputStream.
1) I don't like GCancellable This is for several reasons:
1a) GCancellable is far too visible. It's present in every function
call, so it must be very important. Maybe exporting
g_push/pop_current_cancellable () would be a better API because it
decouples the cancelling from the actual operations?
There are two cases here. For async operations we clearly need to pass
the cancellable object to the operation, because we can't rely on a
thread-local storage setting over the lifetime of the async operations.
Now, for sync calls things are less obvious. At one time I had the
cancellable object as an implicit argument (via tls). However, I ran
into trouble with that and had to be explicit about it. I'm trying to
recall the details of that atm... I think the problem was that if your
implementation of an operation relies on other gio operations those
would always inherit the cancellable of the outer operation. This isn't
always what you want, as there are casese where you need to do a
non-cancellable i/o as part of a larger cancellable operation (an
example is that you don't want to send partial messages and mess up the
protocol state in the daemon backend, instead you want to send a cancel
request).
Maybe there were other reasons too, because it seems like this one would
be fixable if one allows to stack a NULL cancellable over a non-NULL
one.
1b) Cancelling operations from another thread doesn't look like good
design to me. I've learnt (both in theory and in practice) that
threads are supposed to be independant and not call into each other.
Eh? How else would you cancel a blocking i/o call? From within the
blocked thread? This is just bogus, cancellation is all about
cross-thread operations.
2) GVFS seems to avoid the glib main loop for asynchronous operations
in favour of relying on threads. I'm not sure this provides any
benefits besides making apps way harder to debug. Is there a reason
for that?
I wouldn't say it does. It gives you both sync (usefull if you do
threads) and async operations (useful it your typical gui app). Almost
all GUI apps are single threaded and async by desing, and integrating
glib-style async i/o into such apps is generally *much* easier than
manually mucking about with threads.
However, the default async operations are implemented using threads, so
in fact apps are often using threads already when using gvfs. Just in a
way that fits well with a mainloop based gui app. And when doing async
is *much* easier than using sync i/o we can avoid the thread cost by
having a custom async implementation. (For instance the gvfs daemon
protocol is very easy to do async without using threads.)
Of course, threads have their place too. For instance, a complicated set
of file operations like a recursive directory copy is imho best
implemented using sync calls in a single thread. And gvfs is set up to
handle this case well too.
3) The whole API seems to be built around the model of synchronous
operation. (I think so because of this code comment: /* Async ops:
(optional in derived classes) */) I always thought everyone agrees
that synchronous operation should be a thing of the past. and only be
supported as an add-on for lazy coders or really simple apps.
Almost everyone implements synchronous operations something like this:
void foo () { while (errno == EAGAIN) foo_async (); };
The kernel sure does.
There is a default implementation of async operations using the sync
operations and threads. I don't think that means the model is only sync
i/o. I think it gives equal width to both sync and async models.
I also thing you are naive if you think sync i/o is a thing of the past
and only for lazy coders. There are many cases where asynchronous i/o
is way to complicated and doesn't give any advantages over sync i/o.
(Like the above recursive copy operation, i dare you to implement
gnome_vfs_xfer using only asynchronous primitives!).
In fact, I agree with Linus (the syslet/threadlet thread on lkml is very
interesting wrt to this argument) that there are many operations that
just fit very badly with the asynchronous model, and things like
pathname lookup and complicated filename operations are examples of
that.
4) The asynchronous API seems to avoid the POSIX asynchronous model
Re: Tap and Hold API
On Tue, May 01, 2007 at 07:47:25PM -0500, Federico Mena Quintero wrote: I don't think having widget-specific tap-n-hold animations is a good idea; I would say that this is really a theme issue and it would be good if every tap-n-hold operation looks the same the to user. You have two tap-and-hold actions: pop up a menu and pop up a tooltip with extra info. Should those have the same I'm armed animations? Yes, I would say that for both of those actions the animations should be the same; for both of them the user is holding down the stylus and you want to show the same indication that the system is doing something with that action regardless of what will show up next. I think that depends on the way you want to implement it. For tooltips you can activate the show-help binding which will display the tooltip for the focussed widget immediately, without any delay. For tap-n-hold I was thinking of something similiar, a keyboard shortcut which will activate a binding -- this binding will trigger the tap-n-hold action immediately (iff the query succeeded of course). Oh, so this would be global? Sort of tap-and-hold-keysym = FunkyKey in your ~/.gtkrc? Yes, but probably with a default key combination in GTK+ modifiable via key themes. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Fri, 2007-05-04 at 11:40 +0200, Alexander Larsson wrote: 5) You seem to use void * in as the data pointers. All applications I know use guchar * (some use gchar *) to handle data. From my stream handling experience this is to encourage people to think about what they pass to such a function. This seems to encourage calling functions like this: write (mywidget, sizeof (MyWidget)) - with is a bad idea for multiple reasons, including but not limited to struct padding. MS formats seem to have done that a lot. I'm not partial to any format here. Do people thing that using a char type rather than a void type is better? I tend to use uint8_t * because I rely on stdint.h: this makes it totally unambiguous that you are dealing with bytes, IMHO. I like to avoid char * whenever I can because I have gotten more than once into portability problems due to the fact that the signedness of char is different on different platforms. If I remember correctly one of the embedded platforms I used to work on (ARM or MIPS, I cannot recall at the moment) was unsigned char while x86 is usually signed char. regards, Mathieu -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Fri, 2007-05-04 at 15:27 +0200, Mathieu Lacage wrote: 5) You seem to use void * in as the data pointers. All applications I know use guchar * (some use gchar *) to handle data. From my stream handling experience this is to encourage people to think about what they pass to such a function. This seems to encourage calling functions like this: write (mywidget, sizeof (MyWidget)) - with is a bad idea for multiple reasons, including but not limited to struct padding. MS formats seem to have done that a lot. I'm not partial to any format here. Do people thing that using a char type rather than a void type is better? I tend to use uint8_t * because I rely on stdint.h: this makes it totally unambiguous that you are dealing with bytes, IMHO. I like to avoid char * whenever I can because I have gotten more than once into portability problems due to the fact that the signedness of char is different on different platforms. If I remember correctly one of the embedded platforms I used to work on (ARM or MIPS, I cannot recall at the moment) was unsigned char while x86 is usually signed char. for unformatted blobs of data, the convention in GLib/GTK+ appears to be using guchar*, to avoid the signedness issue like you reported; see the GtkSelectionData and the drag and drop API in GTK+ and the base64 API in GLib for precedents of that. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: Some comments about GVFS
Hi, Carl Worth wrote: Anyway, I've learned a few new things, and found the discussion very useful. I hope you have as well. Certainly. By the way, is that a compile-time or a run-tim environment variable? And what measures do you take to advertise it? It's a run-time env variable. I think we don't advertise it at all, it's more of a defense against people who have strong views on the topic and prefer undefined behavior probably a crash to just exit ... How does your D-Bus unit testing arrange to test all the OOM code paths? I have a dbus_malloc wrapper and it can be told to fail the Nth malloc. The test suite runs once and counts mallocs, then it runs over and over and over failing mallocs 1, 2, 3, 4, 5... ;-) Brute force! When I first implemented this it found quite a few bugs, I then implemented something similar for part of libxml and also found a lot, so that's why my party line since has been that trying to handle OOM without testing the OOM codepaths is more hopeful fantasy than anything else. (it's just too hard to get right without testing - in some cases in dbus-daemon I had to implement fairly complex transactions that could be rolled back, in other cases I had to change the library API to allow e.g. callbacks to signal OOM) What we're doing in cairo, (only fairly recently, and thanks to Chris Wilson), is to run cairo's standard test suites but with a valgrind skin that Chris wrote to progressively inject malloc failures. The skin is quite general and is described here: http://lists.freedesktop.org/archives/cairo/2007-April/010343.html Very nice. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote: Why doesn't HAL use UUIDs? I'd say probably because up until now there was no abstraction to turn those UUIDs into usefully understandable paths for the user. If you plug in a USB disk and open Nautilus, you see the /media/usbdisk-1 path. They needed to make that look right and didn't want to write a next generation VFS system like you are doing. I could be wrong however. I don't understand this. Why not just use /media/5407588e-6835-4efd-b0e9-d41a9a450093 as the mountpoint? There is no need to use something like media://5407588e-6835-4efd-b0e9-d41a9a450093/ instead. They are just two different forms of the same thing, and one doesn't need any extra software support. I'd like to point out that I'm not advocating UUIDs at all, actually. I'm advocating an abstraction for mounting and browsing removable devices which correspond to kernel VFS paths. It just so happens UUIDs are the first thing that came to mind. The GVFS idea of explicitly mounting a resource offers us an extremely good place to add such UI hooks. We've never had these before. There was no real good way to auto mount kernel VFS paths, and allow the UI to request media, so it's never been possible. Ah, I guess the difference in the URI case is that its possible to intercept the access of a non-mounted location and do something. Are GFile instances extensible? Can a writer of a GVFS module cause custom URI prefixes to return custom GFile implementations? That is really the only thing standing in the way of such an idea being implemented by me or others. To test out my idea, I would need to return a GLocalAndDaemonFile instance which could return NOT_MOUNTED when it wasn't mounted. Can I implement both mounting and local file access through a single GFile subtype? Or do GDaemonFiles *only* support mounting (mounting requiring communication with a daemon of some sort?) I think this is the only area where GVFS design decisions could potentially effect implementing this. As long as you can have a GFile which does both local access and manages mounting, we're good. The default dbus implementation of GVfs doesn't allow anything like this (ATM at least), but another implementation of the GVfs api could generate any GFile they want in the g_vfs_get_file_for_uri() method. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's an otherworldly guerilla firefighter looking for a cure to the poison coursing through his veins. She's a sharp-shooting renegade former first lady with a knack for trouble. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote: Why doesn't HAL use UUIDs? Doesn't exactly make sense. Maybe you mean: Why does my mount points not use UUID?. Understand that HAL [1] is only a source of information + mechanism to allow g-v-m, KDE, gnome-mount, whatever to mount file systems from removable drives at a given location. It's obviously policy what mount point (and mount options) to use; so that needs to come from the desktop session. So gnome-mount stores this in gconf (see the gnome-mount man page) and if there is no settings stored for a given volume we use reasonable and tasteful defaults. And it's not reasonable to prefer /media/12345-83294230-4230423-323232 over /media/EOS_DIGITAL In addition some file systems don't have UUID's and some instances of a file systems leaves it unset (my EOS 5D leaves the UUID blank when formatting the CF card with FAT16). So you need to use the fs label which is not always unique... (again, my EOS 5D always chooses EOS_DIGITAL). I'd say probably because up until now there was no abstraction to turn those UUIDs into usefully understandable paths for the user. If you plug in a USB disk and open Nautilus, you see the /media/usbdisk-1 path. No, actually you don't... since file systems from most USB disks have file system labels and we use those instead. For the odd cases where this is not the case we use /media/usbdisk /media/disk or something. They needed to make that look right and didn't want to write a next generation VFS system like you are doing. I could be wrong however. HAL doesn't even try to solve those problems as HAL is system-wide and a VFS system for desktop apps obviously needs to be session-wide. It's worth noting that OS X doesn't mount with UUIDs either. They generate a session-unique value for the mount point, which looks resonable. They encapsulate access to this mount point in an API which understands the uniqueness of a device. I don't know what that means. For removable storage devices they simply use the label and mount in /Volumes/LABEL. David [1] : http://people.freedesktop.org/~david/hal-spec/hal-spec.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
I just had a chat with Alex on IRC. (I have attached the log if anyone wants to read it.) Some of my ideas have changed after this discussion, so I might contradict my previous mail now. Bear with me. I've come to understand now that Alex' and my idea for what a stream is and how it should work are very different because we have very different use cases. Alex comes from the File manager world. For him GVFS is primarily a way to interact with files all over the world, rename them, tag them, and access it's contents. For me it's all about getting a stream to/from somewhere and write/read data to/from it. I'm wondering is if there are use cases for an I/O library that are different from those 2 use cases. During the discussion the question of how to write an async version of g_file_get_contents came up. (That's the paste link in the log.) I have attached my quick'n'dirty showcase of how I'd imagine that would work here, too. The git repo from today contains an implementation from Alex. That one actually works. So here's some followup comments. I'd like to note that what I care most about, because that's important for a nice API is point 7 below. 1b) Cancelling operations from another thread doesn't look like good design to me. I've learnt (both in theory and in practice) that threads are supposed to be independant and not call into each other. Eh? How else would you cancel a blocking i/o call? From within the blocked thread? This is just bogus, cancellation is all about cross-thread operations. I'd argue that if you do a blocking call, you're aware that it's blocking and don't want to cancel it. Otherwise you'd use async I/O with proper cancellation mechanism such as g_main_context_wakeup(). You've told me that it's main use case are transactions like calling the equivalent of gnome_vfs_xfer_async () which you'd want to implement in a thread by calling lots of sync operations one after another. I can see the use case, but even though I still don't like it, I can't come up with a better model. 2) GVFS seems to avoid the glib main loop for asynchronous operations in favour of relying on threads. I'm not sure this provides any benefits besides making apps way harder to debug. Is there a reason for that? I wouldn't say it does. It gives you both sync (usefull if you do threads) and async operations (useful it your typical gui app). Almost all GUI apps are single threaded and async by desing, and integrating glib-style async i/o into such apps is generally *much* easier than manually mucking about with threads. However, the default async operations are implemented using threads, so in fact apps are often using threads already when using gvfs. Just in a way that fits well with a mainloop based gui app. And when doing async is *much* easier than using sync i/o we can avoid the thread cost by having a custom async implementation. (For instance the gvfs daemon protocol is very easy to do async without using threads.) Yeah, I missed those implementations as I was only grepping for GMainContext which you don't use. I think it's a good idea to make the main context customizable so gvfs can be used from other threads. There is a default implementation of async operations using the sync operations and threads. I don't think that means the model is only sync i/o. I think it gives equal width to both sync and async models. I'd love if GVFS would advocate the async model over the sync model but provide both. So g_input_stream_read would be async and g_input_stream_read_async would exist, too. The reason for this is that I think in most cases you want the async behaviour and it helps to tell lazy programmers that this is the right way to go. It's purely psychological. In fact, I agree with Linus (the syslet/threadlet thread on lkml is very interesting wrt to this argument) that there are many operations that just fit very badly with the asynchronous model, and things like pathname lookup and complicated filename operations are examples of that. The relevant email can be found at http://lkml.org/lkml/2007/2/25/177 - the followup and previous mails might be interesting, too. I need ot digest this before commenting on it though. There are two basic models when it comes to async i/o. I call them push and pull. The push model is when you initiate a transfer, and then you get a new event each time there is more data availible. The pull model is that you initiate each read and then get an even when data for that read is availible. The main difference for the two models are: * flow control The push model doesn't give you much flow control. If you're copying from a fast source to a slow destination you will fill up memory with the data while waiting for the destination to accept your first block of data. You might also not really want to read the whole file (in for instance filetype sniffing), and this gets more complicated with push. * pipelining The pull model means you have to initiate
Re: FileChooserButton API suggestion
On 5/3/07, Cezary Krzyzanowski [EMAIL PROTECTED] wrote: So first I propose to make some note in the documentation (and maybe in the FAQ), that the supplied dialog needs to have RESPONSE_ACCEPT as the positive result. The second thing is to stop GTKFileChooserButton from changing the title in the supplied dialog. Two good proposals, imo. Can you file a bug so that we don't forget about them ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Child window lost for modal in Win
Hi, First of all, excuse me if this is the wrong instance to report a gtk issue in windows. Just followed the link from GTK for Windows http://www.gimp.org/~tml/gimp/win32/ I've executed the following code in Python: http://www.dinko.cl/~dinko/test-py.html And performed the following actions as explained in http://www.dinko.cl/~dinko/test-py2.html: 1) Click on button Open Modal 2) Switch to any other app, clicking in the win taskbar 3) Switch back to the python app, clicking in the taskbar Diagnosis: When switching back to the python app (step 3), it only shows the parent window, insted of showing both windows with the child over its parent Already asked this in pygtk mailing list with no positive answers. And changing OS is not a n option (in Linux it works fine) -- Thanx a lot, Cro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Fri, 04 May 2007 10:27:34 -0400, Havoc Pennington wrote: It's a run-time env variable. I think we don't advertise it at all, it's more of a defense against people who have strong views on the topic and prefer undefined behavior probably a crash to just exit ... And one thing to note here is that cairo does provide an additional option: No behavior, will not crash which I think can form a good compromise between the camps that prefer each of the options you mention. (Though I'll agree that debugging would be easier if cairo _also_ provided a run-time mechanism to get the just exit along with an error message giving as much context as possible for the time of the error.) The point is, while it might not make sense to talk about error recovery from any single low-level library operation, (see your failed to draw a rectangle example), applications still will very much want to have high-level behavior of something has gone very wrong, let's save the user's important state before exiting. There are a few things a library could do that would defeat that almost entirely: 1. Exit 2. Start doing undefined things 3. Require error-checks on every call into the library to prevent it from doing undefined things You seem to be saying that it's impractical for a library to avoid 2 or 3, so there's no reason not to do 1. But I think with cairo we've got a practical approach for getting close enough to avoiding all three so that applications really can do high-level error recovery. And that seems useful. When I first implemented this it found quite a few bugs, I then implemented something similar for part of libxml and also found a lot, so that's why my party line since has been that trying to handle OOM without testing the OOM codepaths is more hopeful fantasy than anything else. I absolutely agree that testing is essential, and out-of-memory handling is doomed without it. And now that we've fixed so much in cairo, we really want to go fix underlying libraries like fontconfig and freetype or else it's really all in vain. (it's just too hard to get right without testing - in some cases in dbus-daemon I had to implement fairly complex transactions that could be rolled back, in other cases I had to change the library API to allow e.g. callbacks to signal OOM) When we started testing cairo, we found several mistakes, (though fewer than I had anticipated to tell the truth). But we've had nothing come even close to needing any API changes. Part of that is certainly due to cairo's problem domain where there aren't a lot of complex interactions between separate operations, (can anyone imagine transactions being useful when drawing?). But another part comes from just accepting support for OOM-error- handling as an upfront design constraint, rather than hoping to bolt it on later. -Carl pgpDjQ9MQtXgn.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why does gtk_text_buffer() normalize the cluster on backspace?
Thanks Behdad. This really sounds like the right solution. I also like the backspace as undo idea, that will solve the frustration of fixing typos. It won't help with IM chars though as they are composed in whole before inserted into the buffer, right? Thanks for the bug references. It appears that I have been somewhat slow to wake up. :-) Please let me know when you have something in svn, and I'll pull it over and try to get the right behavior for Hebrew. What's your testing system for calling the language modules without rendering (through gtk or something like paps)? Is there a test program in the pango tree? How do other systems deal with this issue, btw? Qt, M$, Swing, OSX? Regards, Dov On 5/4/07, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Sun, 2007-04-29 at 00:23 +0300, Dov Grobgeld wrote: Continuing on my latest posting, I investigated the definition of the unicode canonical ordering that is used by g_utf8_normalize() and I found the following quote from http://unicode.org/faq/normalization.html#8: quote Q: Isn't the canonical ordering for Arabic characters wrong? A: The Unicode Standard does not guarantee that the canonical ordering of a combining character sequence for any particular script is the 'correct' order from a linguistic point of view; the guarantee is that any two canonically equivalent strings will have the same canonical order. In retrospect, it would have been possible to have assigned combining classes for certain Arabic and Hebrew non-spacing marks (plus characters for a few other scripts) that would have done a better job of making a canonically ordered sequence reflect linguistic order or traditional spelling orders for such sequences. However, retinkerings at this point would conflict with stability guarantees made by the Unicode Standard when normalization was specified, and cannot be done now. [KW] /end quote Basically it sais that the ordering of the accent characters for Arabic and Hebrew, may not be relied upon for any linguistic interpretation. I consider what character to erase when pressing backspace to be such an interpretation. As I see it there are two ways of fixing this: 1. Add an calc_char_to_erase() routine in the pango language modules that receives a cluster and determines what character should be erased. If the language module does not define such a routine than either canonical ordering or no reordering is done. 2. Drop the canonical ordering all together. Thanks Dov for raising this. This is discussed in bugs 155948 and 350132. My plan to fix the backspacing issue is very similar to what you suggest. In short: - Add new Pango API pango_backspace() or something. It will take text of a single grapheme in UTF-8 and return new text for it. Apps need to call this only if backspace_deletes_char attribute is set to TRUE, but doesn't harm if they call it unconditionally. - pango_backspace() then will normalize text to NFD, convert it to a GArray of gunichar items, calls backend API to delete one char, or if no backend API, delete the last char, convert back to UTF-8, and finally if the initial normalization expanded the text, normalize it to NFC and return. - A new method in Pango lang engine API will be added, something like backspace() even, that takes the GArray and performs the right thing for the script and language involved. I may go ahead and code this tonight. A further enhancement is for Gtk+ to be smart in input mode. That is, when backspace is hit, it will check the undo buffer, if the last performed action was adding one or more character to the cluster at the current cursor position, it will remove that instead of calling into Pango. Supporting this for more than one backspace is a bit more involved by doable. This makes for a much better user experience where backspace undoes what you typed last. Regards, Dov Cheers, -- 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-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
g_idle_add() used for scrolling of text view to the end iter
Hello, In message log window i used g_idle_add() method for the purpose of scrolling to the end iter. During progress bar it works fine for the hard disk but when i goes to work on FTP there is some warnings across word_wrap and wide_margins in Log window during progress. Any body can help me out for this. How i can scroll window automatically to end iter when messages put on log window during process. Kind Regards, Ibrar Ahmed - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to compile all icons used in programm
On Thu, May 03, 2007 at 11:24:27PM -0300, Rafael Pacheco wrote: i need compile my icons into application how can i do it and how to access ? Use gdk-pixbuf-csource. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Hello and win32 g_io_channel help needed
On Fri, 4 May 2007 10:40:30 +1000
Burke.Daniel [EMAIL PROTECTED] wrote:
I can easily achieve this under Linux with a little
re-organisation to separate out the platform specific
portions.
Does anyone have a fairly straightforward approach to
do the same under windows? If I cannot add a watch to
the serial port I am afraid I may have to either fake
it with a poll?
Short answer - no.
Longer answer - the Windows serial port handling is ugly and painful,
and really seriously not designed for this. It assumes you'll be using
a separate thread for everything. But there is just about provision for
it. Polling is even worse, because Windows doesn't support anything
equivalent to the Unix select call.
Here are some extracts from the code I've used on Windows (using
Borland C++ Builder) with some sucess:
CommsLink::CommsLink ( const char * port, int baud ) {
DCB ioDCB;
hFile = CreateFile ( port, GENERIC_READ | GENERIC_WRITE, 0,
NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED,
NULL );
sReadOverlap.hEvent = 0;
sReadOverlap.Offset = 0;
sReadOverlap.OffsetHigh = 0;
sWriteOverlap.hEvent = 0;
sWriteOverlap.Offset = 0;
sWriteOverlap.OffsetHigh = 0;
if ( GetCommState ( hFile, ioDCB ) )
{
// Set up appropriate attributes
ioDCB.BaudRate = baud;
ioDCB.ByteSize = 8;
ioDCB.Parity = NOPARITY;
ioDCB.StopBits = ONESTOPBIT;
ioDCB.fParity = false;
ioDCB.fBinary = true;
SetCommState ( hFile, ioDCB );
}
else
{
CloseHandle ( hFile );
hFile = INVALID_HANDLE_VALUE;
return;
}
}
VOID CALLBACK HandleAsyncRx ( DWORD error, DWORD NumBytes,
LPOVERLAPPED lpOverlapped ) {
CommsLink * cml = (CommsLink*)lpOverlapped-hEvent;
lpOverlapped-hEvent = 0;
cml-HandleRXEvent ( error, NumBytes );
}
bool CommsLink::SetRXHandler ( CommsCallback * cb )
{
RxCallBack = cb;
sReadOverlap.hEvent = (void*)this;
ReadFileEx ( hFile, AsyncReadBuffer, 8, sReadOverlap,
HandleAsyncRx );
return true;// Should check something
}
The problem is, Windows doesn't have the nice clean Gtk main loop to
poll for that event. So while the above has avoided needing a separate
thread, it doesn't work unless you have a timer tick regularly putting
your code into a suitable interruptible sleep state :
void __fastcall TAppWindow::Timer1Timer(TObject *Sender)
{
if ( SleepEx ( 0, 1 ) != 0 )
{
// There was an event, which means we received some data
etc..
I had this more-or-less working when my customer decided to use Linux.
The port to Gtk was much easier.
Cheers,
Rob
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GLib 2.12.12 released
--- Michael Ekstrand [EMAIL PROTECTED] wrote: On Thu, 2007-05-03 at 12:41 -0700, Sergei Steshenko wrote: I can try, but I'm definitely missing the point, which is: * 'make' CAN detect that it's GNU libiconv; * 'configure' can NOT detect that it's GNU libiconv 'make' does not detect that it is GNU libiconv. 'make' does not detect anything. The file that is being compiled does a little consistency check - it makes sure that the type of iconv header it has is consistent with the type of iconv that configure said it is supposed to be building with. 'configure' does try to detect the type of iconv. It evidently determined that your system had a non-GNU (native) iconv. But when the actual compilation happened, it went whoops, this isn't supposed to be a GNU iconv header we have problems. It looks like your iconv library and the iconv header that the compiler finds don't match, most likely. Either that, or there's something else weird with your iconv build setups. So, what is the point in having such a configure script - 'configure' is supposed to detect such things. Things like this are what configure options are for - to guide configure along when it doesn't make the right choice. It is neither practical nor, in many cases, possible for configure to provide a 100% guarantee that its success will imply a successful 'make'. It is not intended for it to provide such a guarantee. It merely tries to configure the software and sets up the Makefiles - if it couldn't make sense of your setup, it may not create appropriate Makefiles. It can't detect every possible contingency. It did reasonable checks to see which iconv your system has, and then that turned out to be inconsistent. In this case, it may be practical to add a test. That's up to the GTK+ devs. But in general, asking configure to detect every possible 'make' problem is essentially asking it to try to compile the program. That's make's job. And you only want to run 'make' once. - Michael -- Michael Ekstrand Research Assistant, Scalable Computing Laboratory Goanna, compute cluster and InfiniBand network monitor tool: http://www.scl.ameslab.gov/Projects/Monitor/ In simple and short English - why can't 'configure' have the same check as the one that causes But when the actual compilation happened, it went whoops, this isn't supposed to be a GNU iconv header we have problems. ? And regarding the way 'configure' at all functions - here is the command line using which it is called: build.pl :INFO: executing == cd /maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12; PATH=/maxtor5/sergei/AppsFromScratchWD/install/gettext-0.16.1/bin:/maxtor5/sergei/AppsFromScratchWD/install/libiconv-1.11/bin:/maxtor5/sergei/AppsFromScratchWD/install/pkg-config-0.21/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/kde3/bin:/home/sergei/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/home/sergei/bin; export PATH; LD_LIBRARY_PATH=/maxtor5/sergei/AppsFromScratchWD/install/gettext-0.16.1/lib:/maxtor5/sergei/AppsFromScratchWD/install/libiconv-1.11/lib; export LD_LIBRARY_PATH; PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/opt/kde3/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/opt/gnome/share/pkgconfig; export PKG_CONFIG_PATH; LDFLAGS='-L/maxtor5/sergei/AppsFromScratchWD/install/gettext-0.16.1/lib -L/maxtor5/sergei/AppsFromScratchWD/install/libiconv-1.11/lib'; export LDFLAGS; CPPFLAGS='-I/maxtor5/sergei/AppsFromScratchWD/install/gettext-0.16.1/include -I/maxtor5/sergei/AppsFromScratchWD/install/libiconv-1.11/include'; export CPPFLAGS; ./configure --prefix=/maxtor5/sergei/AppsFromScratchWD/install/glib-2.12.12 --with-libiconv=gnu 1configure.log 21 - please pay attention that paths to libiconv-1.11 are present in the command line. So, why do I have to also give '--with-libiconv=gnu' on command line to make 'make' work ? (yes, with '--with-libiconv=gnu' 'make' is OK). Regards, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
scrolling logs in GtkTextView to the end (Re: scrolling windows)
HI,
http://mail.gnome.org/archives/gtk-app-devel-list/2003-March/msg00064.html
Please see this reference where this problem already handled, but there is
issue regarding work on FTP server.
I Used this code for scrolling logs in GtkTextView to the end
Execution crash due to g_idle_add();
So please tell me how i can use this idle method.
static gboolean
status_page_scroll_to_end (gpointer data)
{
GtkTextIter iter;
gtk_text_buffer_get_end_iter (GTK_TEXT_BUFFER (viewbuf), iter);
gtk_text_view_scroll_to_iter (GTK_TEXT_VIEW(view), iter, 0, TRUE, 0.0, 1.0);
return FALSE;
}
/**
* status_message
static void
status_message (const gchar *msg)
{
gtk_text_buffer_get_end_iter (GTK_TEXT_BUFFER (viewbuf), end);
gtk_text_buffer_insert( ... );
...
g_idle_add ( (GSourceFunc) status_page_scroll_to_end, NULL );
}
Regards,
ibrar ahmed
-
Ahhh...imagining that irresistible new car smell?
Check outnew cars at Yahoo! Autos.___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: scrolling logs in GtkTextView to the end (Re: scrolling windows)
Hi, On 5/4/07, ibrar ahmed [EMAIL PROTECTED] wrote: http://mail.gnome.org/archives/gtk-app-devel-list/2003-March/msg00064.html Please see this reference where this problem already handled, but there is issue regarding work on FTP server. I use the following code to append to a text buffer and scroll to the bottom. It seems to work fine for me and doesn't need an idle handler: GtkTextView *text_view = GTK_TEXT_VIEW( trace-view ); GtkTextBuffer *text_buffer = gtk_text_view_get_buffer( text_view ); GtkTextMark *mark = gtk_text_buffer_get_insert( text_buffer ); GtkTextIter iter; gtk_text_buffer_get_end_iter( text_buffer, iter ); gtk_text_buffer_move_mark( text_buffer, mark, iter ); gtk_text_buffer_insert_at_cursor( text_buffer, buf, -1 ); gtk_text_view_scroll_to_mark( text_view, mark, 0.0, TRUE, 0.5, 1 ); John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: scrolling logs in GtkTextView to the end (Re: scrolling windows)
Thank you! I done it the same way which you told, now it working fine here also. Again thanx. Regards, Ibrar Ahmed [EMAIL PROTECTED] wrote: Hi, On 5/4/07, ibrar ahmed wrote: http://mail.gnome.org/archives/gtk-app-devel-list/2003-March/msg00064.html Please see this reference where this problem already handled, but there is issue regarding work on FTP server. I use the following code to append to a text buffer and scroll to the bottom. It seems to work fine for me and doesn't need an idle handler: GtkTextView *text_view = GTK_TEXT_VIEW( trace-view ); GtkTextBuffer *text_buffer = gtk_text_view_get_buffer( text_view ); GtkTextMark *mark = gtk_text_buffer_get_insert( text_buffer ); GtkTextIter iter; gtk_text_buffer_get_end_iter( text_buffer, iter ); gtk_text_buffer_move_mark( text_buffer, mark, iter ); gtk_text_buffer_insert_at_cursor( text_buffer, buf, -1 ); gtk_text_view_scroll_to_mark( text_view, mark, 0.0, TRUE, 0.5, 1 ); John - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Showing tool tips on toolbar buttons, progress bar and combobox
Hi, I created custom tool tip window, where i placed icon and markup label as well. I got help fom gtktooltip.c and devhelp. In gtktooltip.c event_after signal is handled for show and hide tooltip window. I used the same thing which is already implemented there. But problem is that no event generated for GtkToolBar buttons, GtkProgressBar and GtkComoboBox. So i want to show the tool tip window against these widgets like tool bar buttons, progress bar and combobox. Reference link below for gtktooltip.c: http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtktooltip.c?view=markuppathrev=17628 Regards, Ibrar Ahmed - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Heading of tooltips should be colored
Hi, On tooltip window there are two labels, one is for heading and one is for description. I want to color the text of heading label on tooltip window. How to color the text of a lable. Thanx in advance! Kind Regards, Ibrar Ahmed - Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games.___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
problem gdk_window_lookup function
Hi, Im trying to write a application. I called gdk_window_lookup with a valid xid to get a GdkWindow structure... But the function just returns NULL. Can anybody tell me what mistake i cud have made? and im using gnome only on my fedora core 6 system.. -- Saripalli Siva Prakash V P Junior Year, BTech CS04B024 Computer Science and Engineering IIT MADRAS Mobile No:- 09246626159 http://www.cse.iitm.ac.in/~svpsiva ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkImage problem
On Fri, May 04, 2007 at 05:26:40PM -0700, beginner.c wrote: Compile error passing argument 1 of 'gtk_image_set_from_file' from incompatible pointer type Do what it says and typecast the variable with GTK_IMAGE(). Runtime errors (process:12275): GLib-GObject-CRITICAL **: gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function Do what is says and call gtk_init() (g_type_init() would not be enough for you use Gtk+ too) as you have to in any Gtk+ program. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: perl gtk window always on top
On Sun, 29 Apr 2007 22:02:53 -0400 muppet [EMAIL PROTECTED] wrote: On Apr 27, 2007, at 7:40 AM, Bert Verhaeghe wrote: is it possible to show a gtk dialog from within a perl script that is above all other open windows (and especially a full screen rdesktop session)? That will depend entirely on your window manager. set_keep_above() is just a hint. and, according to the docs, is not supposed to be used for drawing attention to dialogs, but more for things like making your music player stay visible over other windows. set_transient_for() is the traditional way to get a window to stay atop another window, but that's usually only within your app. If the window is full-screen, the window manager may consider it to own the screen and disallow any other window taking it over in the z order. Have you considered an audible notification instead of a visual one? There is http://www.gnomepro.com/tsclient/ which looks promising. A Gnome front-end for rdesktop which promises geometry and depth control. zentara -- I'm not really a human, but I play one on earth. http://zentara.net/japh.html ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Bug: GtkAboutDialog does not hide when close button clicked
On Thu, 2007-05-03 at 22:42 -0400, muppet wrote: In perl code, you have an easy implementation. In xs code, you have less memory use at runtime, in shareable memory. *shrug* I'm fine with either patch. If your XS patch fixes the bug people have been seeing (that's a hint to you, reporters!), then I'd prefer it over the Perl patch. -- Bye, -Torsten ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
