Re: Row number in TreeView
Thanks for the response. I still have a problem. Maybe because I use GTKmm. I have signal_row_activated connected to the function: void TMainWindow::on_TreeView1_dblclick( const Gtk::TreeModel::Path path, Gtk::TreeViewColumn* tvcolumn) I have taken it from GTKmm documentation. in this function I put what you suggested: gint* i = gtk_tree_path_get_indices (path); Compilation returns an error: cannot convert 'const Gtk::TreePath' to 'GtkTreePath*' for argument '1' to 'gint* gtk_tree_path_get_indices(GtkTreePath*)' What should I change? Where to find the clear explanation of the TreeView widget (gtk.org and gtkmm.org are the best places?) Does GTKmm defines EVERYTHING from the GTK+ or sometimes I will have to use functions from the GTK+? Best regards, LUK 2007/9/16, Claudio Saavedra [EMAIL PROTECTED]: El dom, 16-09-2007 a las 00:32 +0100, Lukasz Gromotowicz escribió: Hi all, I know it is probably something simple, but I am new to the gtk. I have a TreeView and associated ListStore. I am trying to get the row number after I double-click on it. I have a path which I think I should use, but I do not know how. With gtk_tree_path_get_indices (). Claudio -- Claudio Saavedra [EMAIL PROTECTED] Día del Software Libre, Curicó http://curico.diadelsoftwarelibre.cl ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Window with no maximize button
Hi, I wanted to create a Window with only the minimize and close decoration buttons (and no maximize button). The code of what I basically did was: windowPointer = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_widget_realize(windowPointer); mainWindow = windowPointer-window; gdk_window_set_decorations(mainWindow, GDK_DECOR_BORDER | GDK_DECOR_RESIZEH | GDK_DECOR_TITLE | GDK_DECOR_MENU | GDK_DECOR_MINIMIZE); //everything but maximize gtk_widget_show(windowPointer); This does not seem to work as I still get the maximize button on the window. I am using an FC6, with default GNOME installation (and its Metacity WM). On the other hand, if I give a DIALOG hint to the window with gtk_window_set_type_hint(), I am able to remove the maximize and minimize buttons. Is there a difference in which the 2 methods send hints to the WM? How can I get this to work? Thanks in advance, Aniket PS: On an unrelated note, is there an active mailing list for application programming directly using Xlib calls? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Window with no maximize button
On Mon, Sep 17, 2007 at 05:01:05PM +0530, aniket ray wrote: I wanted to create a Window with only the minimize and close decoration buttons (and no maximize button). The code of what I basically did was: windowPointer = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_widget_realize(windowPointer); mainWindow = windowPointer-window; gdk_window_set_decorations(mainWindow, GDK_DECOR_BORDER | GDK_DECOR_RESIZEH | GDK_DECOR_TITLE | GDK_DECOR_MENU | GDK_DECOR_MINIMIZE); //everything but maximize gtk_widget_show(windowPointer); This does not seem to work as I still get the maximize button on the window. I am using an FC6, with default GNOME installation (and its Metacity WM). On the other hand, if I give a DIALOG hint to the window with gtk_window_set_type_hint(), I am able to remove the maximize and minimize buttons. Is there a difference in which the 2 methods send hints to the WM? The DIALOG hint (_NET_WM_WINDOW_TYPE_DIALOG) is an independent hit. So it can influence the window manager decisions independently. Hints are just hints. The window manager decides how to decorate the windows. Apparently, Metacity thinks it's a good idea to remove the two buttons from dialogs. Whatever. My window manager always shows the buttons I told it and only them. Someone else's window manager never shows any window frame at all. You cannot rely on window managers following the hints, some do not even have any meaning with some window management styles. Just set the hints logicaally, i.e. do not randomly choose hints that happen to make your particular window manager behave as you wish. How can I get this to work? You cannot ultimately control the window decorations. And let me immediately add, it's a good thing. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Row number in TreeView
LUK, This link answers your original double-click question! Read the Tutorial! http://scentric.net/tutorial/sec-selections-double-click.html James , On Mon, 2007-09-17 at 09:29 +0100, Lukasz Gromotowicz wrote: Thanks for the response. I still have a problem. Maybe because I use GTKmm. I have signal_row_activated connected to the function: void TMainWindow::on_TreeView1_dblclick( const Gtk::TreeModel::Path path, Gtk::TreeViewColumn* tvcolumn) I have taken it from GTKmm documentation. in this function I put what you suggested: gint* i = gtk_tree_path_get_indices (path); Compilation returns an error: cannot convert 'const Gtk::TreePath' to 'GtkTreePath*' for argument '1' to 'gint* gtk_tree_path_get_indices(GtkTreePath*)' What should I change? Where to find the clear explanation of the TreeView widget (gtk.org and gtkmm.org are the best places?) Does GTKmm defines EVERYTHING from the GTK+ or sometimes I will have to use functions from the GTK+? Best regards, LUK 2007/9/16, Claudio Saavedra [EMAIL PROTECTED]: El dom, 16-09-2007 a las 00:32 +0100, Lukasz Gromotowicz escribió: Hi all, I know it is probably something simple, but I am new to the gtk. I have a TreeView and associated ListStore. I am trying to get the row number after I double-click on it. I have a path which I think I should use, but I do not know how. With gtk_tree_path_get_indices (). Claudio -- Claudio Saavedra [EMAIL PROTECTED] Día del Software Libre, Curicó http://curico.diadelsoftwarelibre.cl ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GVfs status report
On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote: Hi, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? My impression is that ideally on Windows you use the native windows-looking file API, and that the file-descriptor-using API is some kind of weird emulation hack. But I could not comment intelligently on the details. I assume so. Its part of the libc runtime on windows. However, the question is, apart from one layer less, what are the other advantages? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Alexander Larsson wrote: On Fri, 2007-09-14 at 10:47 -0400, Havoc Pennington wrote: Hi, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? My impression is that ideally on Windows you use the native windows-looking file API, and that the file-descriptor-using API is some kind of weird emulation hack. But I could not comment intelligently on the details. I assume so. Its part of the libc runtime on windows. However, the question is, apart from one layer less, what are the other advantages? Pygtk is currently unable to use GIOChannel because both Glib and Python use file descriptor API, but different C runtime libraries. Or something like that. Nobody knows for sure. Problem is, C library on windows is just some library, not the foundation on which everything is built. Plus, there is some fun with normal file descriptors and sockets. So you can have two integers corresponding to the same file, or you can have one integer corresponding to two different files. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
On Sat, 2007-09-15 at 23:08 -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote: char * g_data_input_stream_get_line (GDataInputStream *data_stream, gsize *length, GCancellable *cancellable, GError **error); This actually reads new data from the stream, so it has to dup. One could imagine a similar call that returns some form of object instead of a string. Hi Alex, I think it's pretty common in glib and pango at least to return g_strdup'ed strings. The no-ref-count rule is mostly for objects that have a literal ref/unref pair. Ok, lets start from the general rule that strings are strdup:ed and gobjects are not ref:ed. Here are some violations of that in the gio api, reasons why, and possible changes: GList * g_app_info_get_all_for_type (const char *content_type); GAppInfo *g_app_info_get_default_for_type (const char *content_type); These obviously have to return a ref:ed value, because the content type string doesn't own the result. Maybe I should use another name for these. For instance g_app_info_query_all_fo_type and g_app_info_query_default_for_type. char * g_content_type_get_description (const char *type); char * g_content_type_get_mime_type (const char *type); GIcon * g_content_type_get_icon (const char *type); Same here. char *g_data_input_stream_get_line(...) Independent on the memory allocation properties of this it really should be read_line(). GDrive * g_volume_get_drive (GVolume *volume); This currently refs the result for historical reasons. This API is quite similar to the gnome-vfs volume manager API. There is a singleton volume monitor that keeps track of the volumes and drives availible on the system, which can change at any time. So, if you get the drive for a volume you get the current value, which might change later. In gnome-vfs this API is used by gnome-vfs backends, which means the API have to be threadsafe, and the only way to make it threadsafe is to ref in the getter. In gio we could decide to make this API not threadsafe and have non-reffing getters. Opinions on this? const char *g_file_info_get_attribute_string (GFileInfo *info, const char *attribute); and helpers like: const char *g_file_info_get_name (GFileInfo *info); For these calls it really makes no sense to dup the code. The GFileInfo is the container for the data, and we're just peeking at the data. This is somewhat similar to g_value_get_string() which also doesn't dup. GFile * g_file_get_parent (GFile *file); GFile * g_file_get_child (GFile *file, const char *name); These create a new GFile object, and there just is no way to not ref the return value. Should we use a different name for these, and if so what? I don't have any good ideas. Maybe just g_file_parent() / g_file_child()? GFileInfo *g_file_get_info (GFile *file, const char *attributes, GFileGetInfoFlagsflags, GCancellable*cancellable, GError **error); This is not really a getter, but an i/o operator (its stat/lstat). However, read_info() seems a bit weird name for this. Can anyone think of a better name? Other than that, for functions that return read data from the stream, some people may have reasons to want to avoid malloc/free'ing on each line. One way to work around that is to have the function take a GString, so you can reuse the buffer from the previous line. I know most people are not a big fan of that idea though. Hmmm, there are lots of lowlevel functions that you can use if you want to do fancy array growing and whatnot. get_line() (or better, read_line()) is mainly a very easy to use helper function for reading a full line of text. I don't think we want to make it more complicated, as then the whole point of it is sort of moot. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
On Fri, 2007-09-14 at 12:01 -0400, Matthias Clasen wrote: On 9/4/07, Alexander Larsson [EMAIL PROTECTED] wrote: If we want to use gvfs in Gnome 2.21 there are two possibilities: 1) Release next glib before the next Gtk+ release 2) Temporary ship gio in a separate module, which we later move to glib (pkg-config should magically make this work for users as long as the packages etc conflict properly) Both of these have the disadvantage that we can't use gio in Gtk+. There are a bunch of UI helper dialogs etc that would be nice to have there, but they are not critical. Opinions? I think doing a glib release for 2.21 with gio is at least worth discussion, but as was already mentioned, it would probably be good to have some real-life experience with the api in the form of nautilus and file-chooser ports before committing to the api as part of glib. I don't really know what to do about the GTK+ parts; having them in a libegg-like gvfs library until the next GTK+ release would not be the end of the world; imo. This sounds like a reasonable plan. Anyway, please check out at least the gio module and have a look at it. Please. Pretty Please. Here are some very initial impressions: - why do the GAppInfo launch functions take filena,es/uris, but not generic arguments ? You mean a call that takes GFile args? There is one issue related to this, and that is that GFiles are generally limited to a subset of web uris. For instance, a mailto: uri isn't generally something that makes sense wrt file management, whereas it makes sense to pass such a uri to evolution. I think the reason the API is as it is currently is because it was just designed around what a desktop file is, and it was done before GFile was designed much. I think having a call that takes a list of GFiles makes total sense, however for the above reason it is also good to have a direct uri version of it. - there is a g_app_info_set_as_default_for_type(), but there seems to be no way to let an app hande a content type without being the default ? Yeah, this would be useful for e.g. the open with tab in the nautilus permission dialog. I added it to the TODO comment in gappinfo.h - what is native, exactly ? is there a difference between native and local ? The term local is in general bad for files. For instance, is a file on an NFS share local? Is the file trash:///some-trashed-file.txt (which is backed by a file in ~/.trash/) local? Some people thinks it means that the uri starts with file://, some that its fast, some that its not on the network, etc. We've had problems with it in gnome-vfs, so I decided to avoid this problem in gio by using the term native to refer to files that are expressed in the platform-native filename format (i.e. c:\windows \foo.dll or /usr/bin/ls). And then I've tried to avoid having other types of locality in the API at all, because its generally not useful due to the limited amount of info it gives you (i.e. a lan network share is not local, but can be faster than the local disk). However, I partially failed in this since i used local as part of the type names for the implementation of native paths :(. This is not visibile in the public API, but we should probably still fix that up. Playing around with the demo programs a bit, I did touch foo ./gio-cat gio-cat.c | ./gio-save --backup foo which yields Error closing: Error removing old backup link: No such file or directory and leaves a .goutputstream-6VXKYT file behind. Ah, it got an ENOENT error when removing the possibly existing old backup file. I've fixed this in svn. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
On Mon, 2007-09-17 at 11:57 +0200, Alexander Larsson wrote: char *g_data_input_stream_get_line(...) Independent on the memory allocation properties of this it really should be read_line(). GFileInfo *g_file_get_info (GFile *file, const char *attributes, GFileGetInfoFlagsflags, GCancellable*cancellable, GError **error); After some discussion on irc I decided that we at least should fix these two. So, i changed all the i/o get_XXX() calls in GDataInputStreams to be read_XXX(), and g_file_get_info() and related calls to g_file_query_info(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
The issue is that file descriptors shouldn't be passed from a dll / exe using one C runtime to another using a different C runtime -- or if they are, they must be used only with functions from the appropriate C runtime. Use of file descriptors within a single dll is generally not a problem. That's correct, and a major complaint of people using gstdio's g_fopen() routine. The native win32 calls (CreateFile and others) probably has advantages, but I can't say whether a separate implementation would be desirable. As best as I can tell, most of stdio is just shallow wrappers around the native Win32 API. A major discrepancy (as I've said before) is that Windows places an artificial limit of 2k FILE*s or fd_ts per process. Wine even goes so far as to duplicate this madness. By not using the Win32 CreateFile/OpenFile functions, you unintentionally limit how many open files a user of your library might have. This comes up more than you'd think in real life. For example, here's a bug against Sun's JVM reported against JDK 1.1 and not fixed until JDK 1.5: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4189011 Cheers, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
