Pass by reference...(easy question)
Hi, I know how to pass by reference in C normally. But how do I pass by ref a GTK Widget to a function? -- View this message in context: http://www.nabble.com/Pass-by-reference...%28easy-question%29-tf3688934.html#a10313107 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: Pass by reference...(easy question)
On Thu, 3 May 2007, beginner.c wrote:
I know how to pass by reference in C normally. But how do I pass by ref a
GTK Widget to a function?
The same way, by giving the address of the object. However, with
a GtkWidget what you have in hand is already a pointer so in most
cases it suffices to pass that pointer.
Totally useless but hopefully illustrative code follows:
#include gtk/gtk.h
void f1 (GtkWidget *w)
{
gtk_widget_show(w);
gtk_widget_destroy(w);
}
void f2 (GtkWidget **pw)
{
gtk_widget_show(*pw);
gtk_widget_destroy(*pw);
*pw = NULL;
}
int main (int argc, char **argv)
{
GtkWidget *w;
gtk_init(argc, argv);
w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
printf(created new GtkWidget at %p\n, (void *) w);
f1(w);
/* bzzt, invalid pointer below; it has been freed */
printf(After f1(), w = %p\n, (void *) w);
w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
printf(created new GtkWidget at %p\n, (void *) w);
f2(w);
printf(After f2(), w = %p\n, (void *) w);
return 0;
}
Here, the above prints:
created new GtkWidget at 0x8079000
After f1(), w = 0x8079000
created new GtkWidget at 0x80790a8
After f2(), w = (nil)
Allin Cottrell
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
set acceleration key for a pictured button
hi all, how can i set acceleration key for a button that contain a picture widget? for labeled buttons we use mnemonic feature, but here what should we do?! -- Good Luck http://oxygenws.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 00:50 -0400, David Zeuthen wrote: Or maybe I'm missing something? Feel free to tell me to read docs and/or the code if my question is stupid and the answer already lies there. Thanks! Its true that there is a form of mapping going on with the fuse layer. Here is how it works: There is a set of currently mounted gvfs objects. We run an app that enumerates these and follow changes to this list, we then expose each of these using fuse as a directory in (e.g.) ~/.mounts. Now, normal gvfs using apps are totally ignorant of this vfs mount - pathname mapping. It is basically only used by nautilus when launching a program that doesn't support uris. (Although a gvfs-supporting fileselector could detect the ~/.mount prefix and reverse-map to a uri while showing the file selector.) 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. Its conceivable to have a gvfs mount type that just proxies operations from a uri to a mounted filesystem. Say you'd map media://UUID/path to the mountspec type=media;uid=UUID. Then we automount mountpoints for all currently mounted media. An access to such a mounted media would work, although slowly, as all operations would go through an extra daemon via dbus. Access via the fuse layer would work too, but go through even more layers. 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 can try to mount the location, showing a dialog which could incorporate Please insert volume foo dialogs. Its also possible to modify the uri-to-fuse-path code to map such mounts to their actual location. Although you can't do the reverse mapping in this case (since that has to be a fast and i/o free operation). Will it work. I guess, yes. However, it will be slower for gvfs apps, and I still think the aliasing is gonna be confusing. I.E there will be two visible locations that map to the same place. Code will look at a particular location name and don't expect things like a delete in this place will also delete in some other place (like say the source location of the copy you were doing). We do already have aliasing problems in the fuse case, but there the alias is in a hidden location, only used by non-native applications as a fallback. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a short-sighted alcoholic ex-con gone bad. She's a man-hating blonde mermaid on her way to prison for a murder she didn't commit. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some comments about GVFS
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?
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.
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?
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.
4) The asynchronous API seems to avoid the POSIX asynchronous model in
favour of callbacks. Is there a reason why? I'd have guesses an
asynchronous API looked like GIOChannel with some sugar on top.
Something like this:
if (!g_input_stream_read (stream, buf, size))
g_input_stream_wakeup_when_available (stream, size, func, data);
And have that wake up in the glib main context when enough data is available.
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.
6) Has there been thoughts about using a buffer-like struct? I seem to
remember having talked about that last Guadec, but don't remember. To
elaborate: A buffer structure is basically a refcounted memory region.
All the multimedia libs make use of a structure like it. Some examples
are at [1] and [2]. It allows some neat features like avoiding memcpys
to reference the data and subbuffers.
7) The error handling in gvfs seems to be oriented towards the old
and in glib still common error model of having people supply a GError
to every function. I much prefer the cairo model, where basically the
object keeps its own GError and has a function like cairo_status [3]
that gives you the last error that occured. This has multiple
advantages such as that I don't have to check for errors in every
function, I can get the error on request and don't have to keep it
around manually and function calls have one parameter less.
8) The API seems very forgiving to (IMO) obvious porogramming errors
that should g_return_if_fail. g_input_stream_read for example provides
a proper error message when there's already a pending operation or
when the size parameter is too large.
9) I got the feeling that the API is somewhat designed to make one
Stream object be usable from multiple threads at once. I can't
pinpoint that, it's just a feeling. That's not the case, is it?
Wow, that got more than I thought it would become. Please don't take
that as me slamming gvfs, I'm just curious as to why those decisions
were made.
Cheers,
Benjamin
[1] http://swfdec.freedesktop.org/documentation/swfdec/swfdec-SwfdecBuffer.html
[2]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstBuffer.html
[3] http://www.cairographics.org/manual/cairo-cairo-t.html#cairo-status
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
FileChooserButton API suggestion
Hello! I've fought a few hours with the working of GTKFileChooserButton. I wanted to have a menu item and the button in toolbar opening the same GTKFileChooserDialog. To make this happen I've constructed the GTKFileChooserButton using the constructor, that allows passing my custom GTKFIleChooserDialog. The problem is, that the dialog HAS TO have a button with RESPONSE_ACCEPT, otherwise the button won't set it's label and icon accordingly after selecting a file. I had my 'Open' button in the dialog use RESPONSE_OK and it displayed only the icon, the label was empty. The second issue is with the title. Even when supplying my own FileChooserDialog with the title set to something custom, FileChooserButton resets the dialogs title to default. 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. Best regards [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.12.12 released
--- Matthias Clasen [EMAIL PROTECTED] wrote: GLib 2.12.12 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.12/ http://download.gnome.org/sources/glib/2.12/ glib-2.12.12.tar.bz2 md5sum: 0b3a42098243d054475ff6eb51ed2be1 glib-2.12.12.tar.gzmd5sum: 6c6a61e4b08fb4b110ca7953f71c8b5e This is a bug fix release in the 2.12 series. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.12.11 to GLib 2.12.12 = * Bug fixes: 418862 g_base64_decode will give critical warning when first par... 356843 make check fails if /bin/sh is pdksh 418217 g_unichar_toupper/_totitle broken for single to multiple ... 432895 param_string_validate() frees and modifies static strings 420686 g_key_file_to_data alters original data * Translation updates: (da,es,eu,gl,ja,ro,ru,sr, [EMAIL PROTECTED],ta,zh_CN) A list of all the fixed bugs can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=418862,420686,418217,356843,432895 Thanks to everybody who contributed to this release: Halton Huo Chris Wilson Denis Jacquerye Paul Jarc Tor Lillqvist Michael Natterer Matthias Clasen May 1, 2007 ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list This is a broken release - 'make' fails with these messages: gconvert.c:48:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv make[4]: *** [gconvert.lo] Error 1 make[4]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12' make: *** [all] Error 2 even though 'configure' is OK. Each and every release of each and every library is broken by definition in case 'configure' is OK and 'make' fails. This didn't happen with 2.12.11. I am routinely rebuilding packages using AppsFromScratch whenever new releases are announced, so the problem was discovered during such a rebuild. 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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
On Mon, 2007-04-30 at 12:52 -0400, Havoc Pennington wrote: Something like: - get a few reviews and comments on candidate codebases - iterate codebases accordingly - try to get a couple real-world apps to try them out - iterate accordingly - get review and feedback from gtk maintainers - iterate accordingly - submit resulting mature and well-reviewed codebase to gtk bugzilla If that makes sense, I'd suggest that others review and write up their thinking on GooCanvas, perhaps reading some of the old threads, Piccolo, HippoCanvas, etc. as background material. And also if there are other canvas maintainers who want to put their hat in the ring, they should probably speak up. I've already spent a lot of time on GooCanvas though, so I don't really want to spend a lot more time implementing features the GTK+ maintainers want, and then have them choose another canvas instead. I'd rather they chose one canvas and said do A, B C and it goes in. Damon ___ 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 09:27 -0500, Jerry Haltom wrote: Sure, but that hasn't helped the user any. He still has to remember where he mounted a remote machine, and do the mounting manually. What I'm talking about would be a GVFS schema for cifs:// that would actually create a kernel mount. Or nfs://. But the user can't mount a kernel mount. Only root can do that. In fact, this is one of the primary reasons we're creating a user space vfs. So that any user can create a cifs mount on any platform without being root. What about auto mounting things such as USB devices? Are we going to have an abstraction around those, where you could refer to device by uuid or something? `uuid-of-device://path/to/file` Or are we simply going to consider it `file:///media/usbdisk-1/` and stuff like we do now? I really like the abstraction idea. It would basically be a GVFS mountable that just did whatever pmount work was necessary to get the device mounted, the proxy to the kernel VFS. I haven't planned anything like this. There is an abstraction similar to gnome-volume-monitor for enumerating the devices, but once they are mounted we refer to them as in the filesystem. Again, hasn't helped the user any. He can't record these paths in recent files, because the mount point could change between usages or machines. One day usbdisk could be usbdisk-1, the next it could be usbdisk-2. Sure, paths have problems. But your made up uuid uri has problems too. Like aliasing, or the risk of non-unique uuids and other fragility problems. Not sure what you mean. gvfs backends can support mount on demand if that is what you want. But fuse mounts are not really different than any other kind of mounted filesystem, what special needs do you have? The only need I'm talking about is hiding the actual POSIX location of the mount from the user. If the user is talking about flickerfs, he should be able to refer to it as flickerfs://, and not have to refer to it as file:///mnt/myflicker/. In general the user shouldn't have to type uris at all. If a flickerfs is mounted it should be there in the ui, clickable. And anyway, we won't mount the flickerfs system like that. It will be a user-level mount that is accessed through gvfs and addressed using URIs. I'm not sure what you mean, generally file: uris map to POSIX paths, and no other do. But wouldn't you want to be able to provide a map to POSIX paths for *all* GVFS urls? For sftp://, smb:// and all the others. There has been talk on this thread about creating a ~/.local/mounts/ Fuse directory which would allow non-GVFS enabled programs to use GVFS files. How should a GVFS enabled program go about translating a GFile to this path? Hence the `posix-path` property. For `file:///foo/bar` it would return `/foo/bar`. For `smb://host/foo/bar` it might return `~/.local/mounts/smb;whatever;whatever/foo/bar`. Hence you can simply ask a GFile instance for it's POSIX path, and get one. The g_file_get_path() is meant to return the fuse path in case of a non-native GFile when there is fuse support. This works exactly like you say above. It is possible to make it point to other locations than ~/.mounts/ if we make uri schemes that just alias part of the unix tree, but as i said in my reply to davidz, I think that is very risky to do. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a benighted coffee-fuelled librarian haunted by memories of 'Nam. She's a pregnant French-Canadian archaeologist who believes she is the reincarnation of an ancient Egyptian queen. 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 09:38 -0500, Jerry Haltom wrote: Will it work. I guess, yes. However, it will be slower for gvfs apps, and I still think the aliasing is gonna be confusing. I.E there will be two visible locations that map to the same place. Code will look at a particular location name and don't expect things like a delete in this place will also delete in some other place (like say the source location of the copy you were doing). We do already have aliasing problems in the fuse case, but there the alias is in a hidden location, only used by non-native applications as a fallback. I don't really understand why it would have to be slower. Lets say you have a gio aware application, it is accessing `file:///foo/bar`. How does the mount for file know to not talk to a daemon? How does it know to actually just do regular io against `/foo/bar`. The answer to this is the same as the answer to the question about how `media-uuid://foo/bar` knows to use real POSIX io to `/media/usbdisk-1/foo/bar`. At some point, in the gio consuming application, a decision has to be made about whether the io can be done locally, should be done locally, or should be done through a daemon. For file: this decision is obvious. It should always be done in process. For http: it should be done out of process. For media-uuid: it should be done in process, but during the mounting stage something has to make sure the volume is actually present and mounted by the kernel. All of these paths should be translatable into a posix-safe path for non gio-aware applications, either by returning the real underlying path, or by returning a path to a fuse mounted file system into gio. 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.) One of the defining aspects of the GFile object is that its a light-weight client side only reference to a file. In all aspects an abstraction of a filename string. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a hate-fuelled Jewish filmmaker with a passion for fast cars. She's a bloodthirsty wisecracking journalist living homeless in New York's sewers. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
On 4/28/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, I read over the GooCanvas code and wrote down everything I thought of, some of it is half-baked or quarter-baked, but hopefully helpful in some way. Looks like a pretty good list. I would add that, at least for widget-y uses, layout should happen in integer pixels, not in double. Marco ___ 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
Hi, allowing you to put up dialogs such as +--+ | The application Frobnicator is trying to access a file on a | | device that is not available right now. To continue please | | attach the device| | | | logo 4GB file system labeled Raptor| | Sandisk Cruzer Micro (in small grey font) | | | | [Cancel] [Continue] | +--+ (for removable media it would say insert the media rather than attach the device) One place where this type of dialog would be really useful is if a stick is already mounted, and the user pulls it without unmounting it. Rather than propagating an I/O errors to apps using the stick at the time of removal, it could tell the user to reinsert the stick and continue where it left off. --Ray ___ 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, 3 May 2007 11:11:39 +0200, Benjamin Otte wrote:
I much prefer the cairo model, where basically the
object keeps its own GError and has a function like cairo_status [3]
that gives you the last error that occured.
It's worth pointing out an additional aspect of the cairo
error-handling model: The object becomes entirely inert as soon as an
error occurs within it. That is, all methods of the object first check
the status and return immediately on error.
That part of the model is essential for the application code to be
able to benefit by deferring error-checking to a convenient time.
-Carl
PS. After I wrote that much I also wrote the following rambling
treatise on the model. I didn't have time to make it shorter, so feel
free to delete it. (I almost deleted it myself, but I think someone
might find it useful).
I think the model is extremely successful in that it actually becomes
practical to write correct programs. We started with the assumption
that programmers rarely include all the necessary checks to make their
program correct, so we decided to make the program correct without all
of those checks.
And that means that the correct program can remain readable---there's
a lot less clutter without from error-checking paths. I love the fact
that code samples in the documentation of the library don't need those
often-seen disclaimers, error-checking code removed for readability.
Another great benefit is that compiler features such as
attribute(warn_unused_result) can actually become feasible to use,
(that is, it doesn't result in a bunch of false-positive noise).
For example, in cairo's core API of about 200 functions, there are
less than 15 that can return an error status indication, (not counting
the calls where the user is explicitly asking for a status value). All
other functions are either void or are returning a value that is of
direct interest to the caller, (such as a constructor or a get
function). So, from the calling convention, it's obvious to the user
that the great majority of the time there's no further error-checking
required. And, in the few functions that _do_ return an error status,
it's actually very important for the user to check those, (and
something like the warn_unused_result attribute can be quite helpful
for this).
One thing that can be get trickier with this model is tracking down
what actually caused the error once it is detected. While it's
convenient to be able to defer the error checking, this also means
that detection of the error becomes separated in time and code from
when the error was committed. (With the old approach there is often
unintended deferral due to missing error-checks, but hopefully the
user gets lucky and a crash happens soon after the error. But the
inert stuff described above prevents this.)
So, to successfully adopt this model, the user really needs to be
provided with some means for getting early reports about detected
errors. Cairo is quite conservative about this, providing only a
function that can be set as a breakpoint for when an error is
detected---and that's probably not quite as much help as will be
desired in many cases. Within a glib world there should be no
compunction in spewing messages or allowing applications to register a
callback for when errors are detected by the library.
Also, another subtle issue is that application code can be incorrect
if it depends on side-effects of library calls that will not always
happen in the face of inert methods. For example, imagine some
fictitious code that looks like this:
while (collection_has_more_items (collection)) {
...
collection_remove_item (collection);
}
...
/* Finally check status of collection here. */
if (collection_has_error (collection))
handle_error();
If collection_remove_item could become inert, then the implicit
side-effect of reducing the return-value of collection_has_more_items
would be violated, and the application code would result in an
infinite loop.
So this would be a situation where the inert-object style would not
help at all. Writing a correct program in this case would be more
difficult, (the user would have to anticipate the problem and add an
extra call to check for errors within the loop), than if the
remove_item call directly returned an error indication, (letting the
user know it is important to check for that error).
For cairo, we largely get to ignore this issue, simply because the
side-effects of cairo operations, (drawing operations), rarely have
such a direct impact on a program's control flow.
So that's something else to keep in mind if considering this style.
Finally, cairo also avoids returning NULL from failed object-creation
functions. (The idea being to return a non-NULL object that can
indicate what type of failure occurred.) I don't know that that aspect
has been entirely successful. The application code ends up wanting to
Re: VFS integration with kernel mounts
On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote: This uuid could be private to GVFS and there would be a lookaside table I think HAL should be able to return to us UUIDs which would be valid between machines. Which is interesting, as it means uris such as these could be saved in shortcuts or recent files. If HAL can't do this, it probably should. ___ 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 Wed, 2007-05-02 at 14:55 +0200, Alexander Larsson wrote: On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote: I've been reading back in the discussion this February, about GVFS and Alex's design and such. Read the postings about legacy VFS integration and creating a Fuse mount point into GVFS at ~/.mount or similar. I find that really interesting. What about the reverse? Are we going to use file:/// to access NFS directories and in-kernel CIFS mounts? Or is an abstraction going to be provided around these where appropriate? Or are we simply going to not touch on the problem? I'm not sure what you mean. Access to such files would be through the GFile apis, and will result in normal posix calls. Sure, but that hasn't helped the user any. He still has to remember where he mounted a remote machine, and do the mounting manually. What I'm talking about would be a GVFS schema for cifs:// that would actually create a kernel mount. Or nfs://. What about auto mounting things such as USB devices? Are we going to have an abstraction around those, where you could refer to device by uuid or something? `uuid-of-device://path/to/file` Or are we simply going to consider it `file:///media/usbdisk-1/` and stuff like we do now? I really like the abstraction idea. It would basically be a GVFS mountable that just did whatever pmount work was necessary to get the device mounted, the proxy to the kernel VFS. I haven't planned anything like this. There is an abstraction similar to gnome-volume-monitor for enumerating the devices, but once they are mounted we refer to them as in the filesystem. Again, hasn't helped the user any. He can't record these paths in recent files, because the mount point could change between usages or machines. One day usbdisk could be usbdisk-1, the next it could be usbdisk-2. Then what about arbitrary FUSE file systems? Is it an acceptable solution to write a fuse GVFS backend which auto-mounts? Not sure what you mean. gvfs backends can support mount on demand if that is what you want. But fuse mounts are not really different than any other kind of mounted filesystem, what special needs do you have? The only need I'm talking about is hiding the actual POSIX location of the mount from the user. If the user is talking about flickerfs, he should be able to refer to it as flickerfs://, and not have to refer to it as file:///mnt/myflicker/. How should the translation from GVFS URI to POSIX path be handled? A `posix-path` property on a GFile? It should mount in ~/.mount if it was a pure-GVFS file system, or return the real underlying kernel path if it's just wrapped? I'm not sure what you mean, generally file: uris map to POSIX paths, and no other do. But wouldn't you want to be able to provide a map to POSIX paths for *all* GVFS urls? For sftp://, smb:// and all the others. There has been talk on this thread about creating a ~/.local/mounts/ Fuse directory which would allow non-GVFS enabled programs to use GVFS files. How should a GVFS enabled program go about translating a GFile to this path? Hence the `posix-path` property. For `file:///foo/bar` it would return `/foo/bar`. For `smb://host/foo/bar` it might return `~/.local/mounts/smb;whatever;whatever/foo/bar`. Hence you can simply ask a GFile instance for it's POSIX path, and get one. ___ 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
Will it work. I guess, yes. However, it will be slower for gvfs apps, and I still think the aliasing is gonna be confusing. I.E there will be two visible locations that map to the same place. Code will look at a particular location name and don't expect things like a delete in this place will also delete in some other place (like say the source location of the copy you were doing). We do already have aliasing problems in the fuse case, but there the alias is in a hidden location, only used by non-native applications as a fallback. I don't really understand why it would have to be slower. Lets say you have a gio aware application, it is accessing `file:///foo/bar`. How does the mount for file know to not talk to a daemon? How does it know to actually just do regular io against `/foo/bar`. The answer to this is the same as the answer to the question about how `media-uuid://foo/bar` knows to use real POSIX io to `/media/usbdisk-1/foo/bar`. At some point, in the gio consuming application, a decision has to be made about whether the io can be done locally, should be done locally, or should be done through a daemon. For file: this decision is obvious. It should always be done in process. For http: it should be done out of process. For media-uuid: it should be done in process, but during the mounting stage something has to make sure the volume is actually present and mounted by the kernel. All of these paths should be translatable into a posix-safe path for non gio-aware applications, either by returning the real underlying path, or by returning a path to a fuse mounted file system into gio. ___ 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
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. 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. One of the defining aspects of the GFile object is that its a light-weight client side only reference to a file. In all aspects an abstraction of a filename string. ___ 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: On Thu, 3 May 2007 11:11:39 +0200, Benjamin Otte wrote: I much prefer the cairo model, where basically the object keeps its own GError and has a function like cairo_status [3] that gives you the last error that occured. It's worth pointing out an additional aspect of the cairo error-handling model: The object becomes entirely inert as soon as an error occurs within it. That is, all methods of the object first check the status and return immediately on error. Yeah, I think this keeps the Cairo model from being fully general - it only works for some types of operations or objects. Another thing about the Cairo model is that it's either weird or possibly broken if an object is used by multiple threads, which could arise in the current gvfs presumably. Another thing that's needed for gvfs for sure but not for Cairo perhaps is the error message. A strerror()/errno type of thing is just not sufficient to give good errors from a system with pluggable backends. Even in Cairo, functions like cairo_surface_write_to_png return pretty unhelpful info on failure. Failure is uncommon, and the info would generally only be helpful to programmers not users anyway (gdk-pixbuf returns stuff like Value for PNG text chunk cannot be converted to 8859-1), but nonetheless in a lot of cases I think a detailed error can be better than a strerror-style string. Sometimes the error will be user-helpful, e.g. You aren't allowed to save to directory Foo Returning *helpful* errors, even if only to programmers and techies, also frequently depends on context - meaning, the error can be more helpful if it's checked right away after every call. errno obviously is an extreme example since it's garbage if not checked immediately. But say you do a series of gvfs operations then get a no permissions error, if the error message says which operation lacked permissions, that is much more helpful. strerror(EPERM) is not as good as You aren't allowed to save to directory Foo Finally, Cairo of course mixes programmer errors (g_return_if_fail in GLib-world) with should-be-reported errors (GError in GLib-world) with unavoidable-and-should-be-ignored errors (just get ignored in GLib-world). See GError docs for how these are separated in GLib: http://developer.gnome.org/doc/API/2.2/glib/glib-Error-Reporting.html For me when using Cairo drawing I would say should-be-reported errors aren't really possible. When the problem is that I passed nonsense to a Cairo API, I would prefer some verbose warning to the silent failure plus an error code I have to figure out the origin of. When the problem is something unavoidable (say not enough memory or whatever) then I just don't care, I'm not going to check the error code for this or in any way recover. So in neither case here do I find the error codes useful. I guess for some surfaces there might be a recoverable error I can imagine caring about, but for painting widgets in X, it just hasn't happened. The Cairo error reporting is something I simply don't use in connection with any drawing code, except in temporary code to figure out how I misused the API, where in GTK I'd instead have seen a warning right away. When the programmer _should_ check the error, e.g. cairo_surface_write_to_png, I think GError-style reporting is ideal, and the return code as write_to_png has is OK and does the job and is pretty much equivalent to GError except there's no memory management (plus) and no error message (minus). So to sum up: - cairo model is most usable when it can be correct to ignore errors, which is particularly common for programming errors (GLib would use return_if_fail/assert) or unavoidable runtime errors that are best handled by simply ignoring them - cairo model should perhaps be extended to support an error message for more general applications (since in the drawing case the idea is to almost always ignore errors, there's no point, but for file and network ops, there may well be) - cairo model raises issues when the error state is shared by multiple threads accessing one object - when it's really probably wrong to not check errors (e.g. when saving a file), a GError-type model with a function arg you must consider, or a return value with warn_unused_result as Carl mentions, is better than the cairo_t store-error-on-object model IMO - I personally believe programmer errors should get the return_if_fail or assert type treatment and not be runtime-detectable, because a nice warning is more helpful to the programmer or in bug reports, and runtime detecting these is just wrong anyway - fix the bug, don't recover from the bug by adding bug-handling code For those reasons I don't agree at all with Benjamin that GError is the old approach, I think it is still the right approach *for errors that should generally be handled or recovered from in some way*. For
Re: VFS integration with kernel mounts
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... 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.. David [1] : One of the things I dislike about current gnome-vfs is that apps themselves get to display the error dialog which is a source for inconsistencies... For example, the one used by Nautilus and the one used by gnome-vfs-daemon don't look the same which is annoying. [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. ___ 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 5/3/07, Havoc Pennington [EMAIL PROTECTED] wrote: Yeah, I think this keeps the Cairo model from being fully general - it only works for some types of operations or objects. Another thing about the Cairo model is that it's either weird or possibly broken if an object is used by multiple threads, which could arise in the current gvfs presumably. [...] For those reasons I don't agree at all with Benjamin that GError is the old approach, I think it is still the right approach *for errors that should generally be handled or recovered from in some way*. I think the cairo style is the best way for recoverable errors that are fatal for the affected object. In that case you want to put the object into an error state and ignore further functions called on the object. To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile, GMarkup. All of those have a lot of functions (not all of them) that are fatal to the object and both the API and the code using it would look a lot nicer if there was one argument less. It may be interesting for some objects to have a function to recover from errors. It's very very important IMO to distinguish the three types of errors (programming, recoverable, and unavoidable-and-ignorable) when designing any API in this area. I'm not sure there are unavoidable-and-ignorable errors. At least I'm not very impressed by the error reporting of Gtk when X has problems. (That one's probably mostly Xlib's fault though). I agree with you that there are programming errors and recoverable errors, but not ignorable errors. Even cairo drawing errors should be somehow handled, and even if it's just printing to stdout. But almost all of those errors indicate a problem in your code (like cairo_scale (cr, 0.0, x)). The reason for allowing the programmer to check errors whenever he wants is to make programs of lazy people easier. We all know that good programs check errno after every call into libc, but most of us are lazy. And lazy people don't remember later that they passed NULL to g_key_file_get_double(). Nor do people that have to fix bugs. And to say it once again: It's nice that the object carries the object around with it. That way I don't have to carry the Error around myself all the time as an extra argument. Benjamin ___ 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, Benjamin Otte wrote: To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile, GMarkup. I'd be for that in the case that the API has a required ending call, the equivalent of close(). Then you can force error checking on that last call with a GError or warn_if_unused approach and in theory people could skip the intermediate error checks. That makes sense. I'm not sure there are unavoidable-and-ignorable errors. To me anything that could happen to cairo_t is probably in this category... what am I going to do if I draw a rectangle and it fails? I really have no idea what kind of recovery code I'd write for that. Certainly nobody is writing such code that I've seen. I don't even know where the error check would go - in every widget's expose handler? In the toplevel event loop? Is there anything that could happen to cairo_t in this category? I don't know. I'm mostly assuming there is because I have no idea what the cairo_t error state is for otherwise ;-) (other than as an internal make everything a noop flag) My guess is that out of memory (on client side or X server side) is in this category in cairo, it silently doesn't draw if OOM occurs, no? You're right that if this class of error exists it's pretty rare. It would probably mean a bug or at least design bug in something, though possibly not your own app. At least I'm not very impressed by the error reporting of Gtk when X has problems. (That one's probably mostly Xlib's fault though). Examples? Any recoverable error it should handle for you or report to you, the main unrecoverable error is BadAlloc which causes a g_error just like out of memory on the client side, and then some X errors are programming errors which GTK often tries to predict for you with return_if_fail but sometimes does not catch. Most X errors I would say are programming errors, the big exception is that if you are messing with another process's windows (as a WM does) there are lots of unavoidable but recoverable errors. Patches adding return_if_fail to avoid all the programming error Xlib errors would probably be accepted, is my guess. Xlib is definitely guilty of mixing up different kinds of error into one system that isn't appropriate or convenient for any kind of error... And to say it once again: It's nice that the object carries the object around with it. That way I don't have to carry the Error around myself all the time as an extra argument. As long as the individual calls failing don't affect control flow, there's some close() call that reminds you to grab the error, and the errors are interesting/recoverable in the first place, I agree this is 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 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. But once the media mounted/connected, it needs to be as efficient as possible. For example, it's reasonable to assume that some apps (for better or worse) might want to create GFile objects for hundreds or maybe thousands of URI's at startup (say, you have a view of hundreds of photos) so performance needs to be comparable with the usual open(2) call. Within the same order of magnitude at least. I guess that was your point? I suppose all this is possible by just creating a GLocalRemovableFile class (that implements GFile and possibly derives from GLocalFile). This would have to be smart about figuring out whether the media is available or not, e.g. it could utilize a temporary cache file (shared by all users of the gio API) in your home directory that maps the media UUID to the mount point. So it would only poke HAL the very first time, in a session, it tries an URI from a given piece of media. It would also use inotify etc. to watch that cache file so you wouldn't even need to do open/read/close the file every time. If the media is not available, NOT_MOUNTED is returned and the file chooser / file manager / app is free to do what it wants, e.g. put up a dialog (preferably using common shared utility API). Just like GDaemonFile I suppose. 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? David ___ 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, 03 May 2007 14:11:02 -0400, Havoc Pennington wrote: Yeah, I think this keeps the Cairo model from being fully general - it only works for some types of operations or objects. Sure. If you want the object to remain usable after an error, then it shouldn't shut down. And note that that with cairo, we do have functions that do return an error indication instead of shutting down, (cairo_surface_write_to_png, for example). So I think a fair characterization of the cairo model is that it recognizes that you don't always do the shutdown-on-error thing, but it is darn handy when it's the right thing to do. Another thing about the Cairo model is that it's either weird or possibly broken if an object is used by multiple threads, which could arise in the current gvfs presumably. For cairo, at least, there's nothing broken here. If you want to use the same object from multiple threads, then you need to be doing your own locking. As for weird, the shutdown thing should only be happening if there's really no other appropriate response. There's a difference between causing an error _in_ an object, (in which case it will shutdown, and it's appropriate for it to be shutdown for all threads), as opposed to causing an error _with_ an object, (in which case it should just return the error indication and not shutdown). Another thing that's needed for gvfs for sure but not for Cairo perhaps is the error message. The model of lodging errors inside the objects doesn't prevent you from putting as detailed a message in their as you'd like. With cairo itself, we don't actually store anything more than an enum, but... 8859-1), but nonetheless in a lot of cases I think a detailed error can be better than a strerror-style string. Sometimes the error will be user-helpful, e.g. You aren't allowed to save to directory Foo ... even with the very strerror-style approach that cairo encourages, it's very easy for the calling application to add context like this when generating its error message. Returning *helpful* errors, even if only to programmers and techies, also frequently depends on context - meaning, the error can be more helpful if it's checked right away after every call. Sure. So everytime you want to emit a useful error message, check the status and generate the message with all the context you want. Or, like I said above, you could envision applying the cairo model and also adding a string to it. (That is, if applying the cairo model pushes the GError from a parameter to every function to instead be a field within the object, that doesn't mean that GErrror needs to become any less capable). Finally, Cairo of course mixes programmer errors (g_return_if_fail in GLib-world) with should-be-reported errors (GError in GLib-world) with unavoidable-and-should-be-ignored errors (just get ignored in GLib-world). See GError docs for how these are separated in GLib: http://developer.gnome.org/doc/API/2.2/glib/glib-Error-Reporting.html I definitely agree with you that there are different classes of errors and they require different kinds of handling. And I won't argue that cairo gets all of this right yet. (In a very real sense I've always felt that cairo's error-handling strategy was a big experiment, and it would be interesting to see how it played out. So I'm quite glad to see this discussion happening around it.) In the meantime, it's not clear to me that either cairo or glib has this all figured out yet. For example, the document above says: First and foremost: GError should only be used to report recoverable runtime errors, never to report programming errors. If the programmer has screwed up, then you should use g_warning(), g_return_if_fail(), g_assert(), g_error(), or some similar facility. For that second sentence, if we're talking about a non-recoverable programmer error, then what guidance is there for choosing g_return_if_fail as opposed to g_assert? Are programmer errors actually divided into two classes? I could imagine a consistent argument that all programmer errors should lead to an abort, (to force errors to get noticed and dealt with early). And I could accept that some people would want to configure the abort away as well, (which G_DISABLE_ASSERT allows for example). So I could imagine a consistent argument that g_assert should be used for all detected programmer errors. But how does g_return_if_fail fit into your model? Isn't it really doing basically the same thing as cairo's inert object functions? Differences I see are that: 1. g_return_if_fail prints a message 2. cairo's inert objects come with a guarantee that once an object shuts down, no future call to that object will have any effect. For me when using Cairo drawing I would say should-be-reported errors aren't really possible. When the problem is that I passed nonsense to a Cairo API,
Re: VFS integration with kernel mounts
I'm usually a lurker here, just chiming in on this: On Qui, 2007-05-03 at 16:48 +0200, Alexander Larsson wrote: But the user can't mount a kernel mount. Only root can do that. In fact, this is one of the primary reasons we're creating a user space vfs. So that any user can create a cifs mount on any platform without being root. Yes only root can do kernel level mounts. But isn't the whole point of HAL and the future PolicyKit to allow user apps to make these kind of requests and have them checked againt some kind o policy ACL? Rui signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS integration with kernel mounts
On Thu, 2007-05-03 at 12:43 -0400, Ray Strode wrote: Rather than propagating an I/O errors to apps using the stick at the time of removal, it could tell the user to reinsert the stick and continue where it left off. Surely brings back memories from the Amiga (You MUST replace the disk in drive df0:/).. However, this is practically impossible to do when using a file system kernel driver (various device mapper tricks aside). I guess you could do this by using a user space FAT file system driver though. (Btw, such a user space driver wouldn't be a bad thing at all; it can run in a very confined security context such that flaws / buffer overflows in said file system driver wouldn't turn into local root exploits. So security-sensitive sites would only allow using this driver for externally attached media/drives. But now I'm drifting off-topic..) David ___ 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, 03 May 2007 15:41:43 -0400, Havoc Pennington wrote: I'd be for that in the case that the API has a required ending call, the equivalent of close(). Then you can force error checking on that last call with a GError or warn_if_unused approach and in theory people could skip the intermediate error checks. That makes sense. Yes, forcing the user to check the return value when finished with the object is definitely a good idea. Aside for the public error-handling strategy, we've been adopting the same shutdown-on-error approach internally within cairo bit-by-bit. And as we do that, we really need to propagate errors from one object to another. And we've found that forcing a check when disposing of an object is a good way to help us not forget that. We've wondered whether we can change cairo_destroy from void to cair I'm not sure there are unavoidable-and-ignorable errors. To me anything that could happen to cairo_t is probably in this category... what am I going to do if I draw a rectangle and it fails? Well, for draw a rectangle, cairo basically says that that can never fail, (if you look at the X interfaces we get, there's no other option). So I think that's an error case that really doesn't exist, as opposed to something that's unavoidable and ignorable. Just look at cairo_status_t---there's nothing like the requested drawing operation didn't happen there. really have no idea what kind of recovery code I'd write for that. Certainly nobody is writing such code that I've seen. I don't even know where the error check would go - in every widget's expose handler? In the toplevel event loop? As you said before, at the very least at the required ending call, (which is cairo_destroy in this case), you should definitely be checking this error. Is there anything that could happen to cairo_t in this category? I don't know. I'm mostly assuming there is because I have no idea what the cairo_t error state is for otherwise ;-) (other than as an internal make everything a noop flag) My guess is that out of memory (on client side or X server side) is in this category in cairo, it silently doesn't draw if OOM occurs, no? There's certainly not a large class of errors that can happen while drawing, (yes, out of memory is one). But the other way you can get an error lodged into a cairo_t is via propagation from some other object. So, if you forget to check a cairo_surface_t's status, (say it's FILE_NOT_FOUND), and then you do cairo_create(surface) then the FILE_NOT_FOUND status will propagate into the cairo_t. It would have been kind of nice if GTK+ were creating the cairo_t for the expose handler and then also checking the status, and printing that message. But that's not how GTK+ integrates with cairo---oh, well. And, no, getting a FILE_NOT_FOUND status on a cairo_t is not going to give you a meaningful error message. And no, I wouldn't think it would be sane for anyone to right code to handle a FILE_NOT_FOUND status from a cairo_t. But it might actually give enough of a hint to help you know where to look, (or else just go and get a _cairo_error-induced stack trace). And, yes, when you find the cairo_image_surface_create_from_png call that's failing, (and was missing any errro checking), you should add code there to print a meaningful error message. As long as the individual calls failing don't affect control flow, there's some close() call that reminds you to grab the error, and the errors are interesting/recoverable in the first place, I agree this is nice. That sounds quite reasonable to me. I don't think everyone will agree on which errors are or are not interesting. And I don't think it hurts at all to be able to fetch an uninteresting status value from an object, (see my example above of cairo_t reporting a FILE_NOT_FOUND status). -Carl pgpAjmYycGVjS.pgp Description: PGP signature ___ 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 5/3/07, Carl Worth [EMAIL PROTECTED] wrote: So that looks to me like if you modified _cairo_error to do the equivalent of g_assert, you'd basically get what you want for your recoverable and unavoidable cases. But that would leave you with always having g_assert and never g_return_if_fail for programming errors though. So please explain more to me about how that handling should be distinguished. I've learned that the difference between a g_assert and a g_return_if_fail is whose fault it is. g_assert would be used for internal consistency checks inside cairo, where the cairo developers ensure they don't write bad code. The best example here is a case statement as in get/set_property functions, where it's common to add an assert in the default case. g_return_if_fail is for developers using your library. It's used to tell them that they are doing something wrong. It's basically the same thing, just catering to a different audience. In short: applications should have no call to g_return_if_fail. Everything should be g_assert. There's some advantages to this differentiation: 1) It allows you as a developer to disable internal assertions for various reasons (try running DBUS with all checks enabled and compare the speed) while still getting informed about faults in using the library. 2) It allows adding warnings later on. If people have been using your library wrong because they didn't know about something, you can add a g_return_if_fail to that function and the next time they'll run the program, they'll notice the warning and hopefully fix the bug. GThread has recently done something like this with printing a warning when g_thread_init() wasn't the first function called. There's some things that I don't like about the Glib/Gnome approach: 1) Assertions aren't disabled in releases. This leads to people often not putting enough assertions where it matters. Noone wants inner loops to be slow. DBUS does that differently and I think it has really helped developing DBUS. 2) g_return_if_fail returning often isn't useful and will lead to a crash. An example here is all those functions that have a GError argument and return FALSE on failure. They return FALSE in the return_if_fail case, too, but don't set the error. This of course causes a program to assume an error was set to crash nonetheless. It would probably be nice to just return TRUE. In general, I think being as annoying as possible when a developer does something wrong is a good thing, because people are lazy. So unless you force them to care about something, they won't and just hope it works anyway. So I could probably live fine with making every g_return_if_fail an assertion. But maybe I'm a bit extreme that way. I'm known to annoy people with -Werror. ;) Benjamin ___ 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, Havoc Pennington wrote: In GLib/GTK it's library bugs vs. app bugs, D-Bus maintains the same distinction for _dbus_return_if_fail vs. _dbus_assert *but* D-Bus makes them both fatal so it doesn't matter much anyhow. And as Benjamin pointed out, D-Bus ships with assertions disabled in stable releases, so it can have loads and loads of them in devel snapshots. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
What are the most useful versions of Pango and dependencies for bug reporting?
I would like to build the latest version of Pango to see whether what seems to be a bug in my old system version of Pango still persists. It appears from http://www.pango.org/Download that jhbuild is the way to do such Pango builds. I have jhbuild checked out from subversion, but now I am a bit stuck on what options to use in .jhbuildrc. Thus, please let me know your recommendations for that file to get the most useful build of Pango (and all its dependencies) for bug investigation and reporting. Note, the libLASi library depends on libpango so I just want to build Pango and its dependencies, but nothing else from GNOME. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: What are the most useful versions of Pango and dependencies for bug reporting?
On Thu, 2007-05-03 at 12:52 -0700, Alan W. Irwin wrote: I would like to build the latest version of Pango to see whether what seems to be a bug in my old system version of Pango still persists. It appears from http://www.pango.org/Download that jhbuild is the way to do such Pango builds. I have jhbuild checked out from subversion, but now I am a bit stuck on what options to use in .jhbuildrc. Thus, please let me know your recommendations for that file to get the most useful build of Pango (and all its dependencies) for bug investigation and reporting. Note, the libLASi library depends on libpango so I just want to build Pango and its dependencies, but nothing else from GNOME. Cairo 1.4.6 and Pango 1.16.4 are the versions you want. Not sure about the jhbuild magic to get it do that. behdad Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- 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
Re: What are the most useful versions of Pango and dependencies for bug reporting?
On Thu, 2007-05-03 at 16:20 -0700, Alan W. Irwin wrote: Behdad, are there any other tarball version changes in the Pango dependencies that you would recommend for the above group of jhbuild module files? For example, they use fontconfig-2.4.1 and glib-2.13.0 in the jhbuild. Let me know if you prefer something else. Latest stable versions are typically the best. That will be some glib-2.12.x, fontconfig-2.4.2 IIRC, and freetype 2.3.4. Recent freetype versions all have known problems though. -- 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
Re: GLib 2.12.12 released
--- Matthias Clasen [EMAIL PROTECTED] wrote: GLib 2.12.12 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.12/ http://download.gnome.org/sources/glib/2.12/ glib-2.12.12.tar.bz2 md5sum: 0b3a42098243d054475ff6eb51ed2be1 glib-2.12.12.tar.gzmd5sum: 6c6a61e4b08fb4b110ca7953f71c8b5e This is a bug fix release in the 2.12 series. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.12.11 to GLib 2.12.12 = * Bug fixes: 418862 g_base64_decode will give critical warning when first par... 356843 make check fails if /bin/sh is pdksh 418217 g_unichar_toupper/_totitle broken for single to multiple ... 432895 param_string_validate() frees and modifies static strings 420686 g_key_file_to_data alters original data * Translation updates: (da,es,eu,gl,ja,ro,ru,sr, [EMAIL PROTECTED],ta,zh_CN) A list of all the fixed bugs can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=418862,420686,418217,356843,432895 Thanks to everybody who contributed to this release: Halton Huo Chris Wilson Denis Jacquerye Paul Jarc Tor Lillqvist Michael Natterer Matthias Clasen May 1, 2007 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list This is a broken release - 'make' fails with these messages: gconvert.c:48:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv make[4]: *** [gconvert.lo] Error 1 make[4]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12/glib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/glib-2.12.12' make: *** [all] Error 2 even though 'configure' is OK. Each and every release of each and every library is broken by definition in case 'configure' is OK and 'make' fails. This didn't happen with 2.12.11. I am routinely rebuilding packages using AppsFromScratch whenever new releases are announced, so the problem was discovered during such a rebuild. 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
Re: gtk accessibility on Windows
Thanks, I've added some info to the bug. On 5/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Lainaus Steve Lee [EMAIL PROTECTED]: What is the status of accessibility on the Windows port of gtk? See http://bugzilla.gnome.org/show_bug.cgi?id=303304 Basically, only the trivially portable plumbing (atk, gail) has been ported, but the real interface to MSAA (or whatever else) nobody has worked on. --tml -- Steve Lee www.fullmeasure.co.uk www.oatsoft.org www.schoolforge.org.uk ___ 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 Thu, 2007-05-03 at 14:04 +1000, Burke.Daniel wrote: Hail! I am new.. so gday to everyone here. I am after some assistance with getting my event-driven serial port input working on Windows. The project is a portable serial tool for internal use within our company, I am writing it using libglademm since I love C++ and am a big Gnome/GTK fan (my laptop being Ubuntu Gnome based) On Linux I am using open and termios to handle the serial port setup, finally returning a GIOChannel for monitoring and so far.. so good. However I am now trying to get the evil version of it running and am not so happy. Here I am using CreateFile to open and configure my port, then use: m_PortDescriptor = _open_osfhandle((long)m_PortHandle, 0); channel = g_io_channel_unix_new(m_PortDescriptor); to get the channel. Later on I use g_io_add_watch to setup a monitor which seems to compile and run ok, however when I send data using g_io_channel_write_chars it seems to crash and I also don’t seem to be receiving data (often resulting another application halt) You mention that you are using Windows, so is there any reason why you are calling g_io_channel_unix_new() instead of the g_io_channel_win32_new*() functions to create the GIOChannel object? Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GLib 2.12.12 released
Sergei Steshenko wrote: This is a broken release - 'make' fails with these messages: gconvert.c:48:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv Try --with-libiconv=gnu in configure. And please keep an eye on how many lists you crosspost to! -- Andrew ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GLib 2.12.12 released
--- Andrew Sobala [EMAIL PROTECTED] wrote: Sergei Steshenko wrote: This is a broken release - 'make' fails with these messages: gconvert.c:48:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv Try --with-libiconv=gnu in configure. And please keep an eye on how many lists you crosspost to! -- Andrew 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 . So, what is the point in having such a configure script - 'configure' is supposed to detect such things. 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
GObject: Freeing memory of instance members?
Hi, I've just started to use GObject, and I think I understand most of it by now. There's still some questions remaining. Here's one: I have an instance struct that has a pointer to a some data that's dynamically allocated in a method. How can I free this memory when the object is finalzed? Is this done automatically in g_object_unref() (when refcounter is zero) ? -Øystein PS: I see a pointer to a func in the info struct called base_finalize and another called class_finalize, but these seems to be used for cleaning up when I have base_init and class_init. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GLib 2.12.12 released
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/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
On Thu, May 03, 2007 at 09:51:05PM +0200, ?ystein Johansen wrote: I have an instance struct that has a pointer to a some data that's dynamically allocated in a method. How can I free this memory when the object is finalzed? Is this done automatically in g_object_unref() (when refcounter is zero) ? When the reference count reaches zero and the object is finalized, its finalize() method is called. And that's where you should free any possibly allocated memory. Remember to chain up parent class finalize() method in your finalize(). I see a pointer to a func in the info struct called base_finalize and another called class_finalize, but these seems to be used for cleaning up when I have base_init and class_init. Ignore these, they are related to class initialization and finalization. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
David Nečas (Yeti) wrote: On Thu, May 03, 2007 at 09:51:05PM +0200, ?ystein Johansen wrote: I have an instance struct that has a pointer to a some data that's dynamically allocated in a method. How can I free this memory when the object is finalzed? Is this done automatically in g_object_unref() (when refcounter is zero) ? When the reference count reaches zero and the object is finalized, its finalize() method is called. And that's where you should free any possibly allocated memory. Aha, but how/where to I set the pointer to the finalize() function? Remember to chain up parent class finalize() method in your finalize(). I will! :-) -Øystein ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
On Thu, May 03, 2007 at 10:40:17PM +0200, ??ystein Johansen wrote: Aha, but how/where to I set the pointer to the finalize() function? In my_class_init() where you override all other methods. See (almost) any Gtk+ widget for examples. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
David Nečas (Yeti) wrote:
On Thu, May 03, 2007 at 10:40:17PM +0200, ??ystein Johansen wrote:
Aha, but how/where to I set the pointer to the finalize() function?
In my_class_init() where you override all other methods.
See (almost) any Gtk+ widget for examples.
Aha again! I guess I can free private members in the same method as well?
static void
neural_net_finalize (GObject *object)
{
NeuralNet *nn;
g_return_if_fail (IS_NEURAL_NET(object));
nn = NEURAL_NET(object);
g_free(nn-priv-weight_h);
g_free(nn-priv-weight_o);
g_free(nn-priv-bias_h);
g_free(nn-priv-bias_o);
g_free(nn-priv-filename);
g_free(nn-priv);
g_message(This is the finalize method and I've freed the instance
members!\n);
}
static void
neural_net_class_init (NeuralNetClass *klass){
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
gobject_class-finalize = neural_net_finalize;
g_type_class_add_private (klass, sizeof (NeuralNetPrivate));
}
I think this looks ok, doesn't it? No, wait a minite What about the
parent? This class has GObjectClass as parent, how do I call it's finalize?
Thanks,
-Øystein
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
On 5/3/07, David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Thu, May 03, 2007 at 10:40:17PM +0200, ??ystein Johansen wrote: Aha, but how/where to I set the pointer to the finalize() function? In my_class_init() where you override all other methods. See (almost) any Gtk+ widget for examples. Hey Yeti, since you're on the subject of object destruction, could you explain me the difference between the finalize and dispose methods ? I use finalize for everything but I believe I should be using dispose somewhere, it wouldn't exist if it were useless...I guess :) Thanks, Alexandre Moreira. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject: Freeing memory of instance members?
On 5/3/07, Øystein Johansen [EMAIL PROTECTED] wrote:
David Nečas (Yeti) wrote:
On Thu, May 03, 2007 at 10:40:17PM +0200, ??ystein Johansen wrote:
Aha, but how/where to I set the pointer to the finalize() function?
In my_class_init() where you override all other methods.
See (almost) any Gtk+ widget for examples.
Aha again! I guess I can free private members in the same method as well?
static void
neural_net_finalize (GObject *object)
{
NeuralNet *nn;
g_return_if_fail (IS_NEURAL_NET(object));
nn = NEURAL_NET(object);
g_free(nn-priv-weight_h);
g_free(nn-priv-weight_o);
g_free(nn-priv-bias_h);
g_free(nn-priv-bias_o);
g_free(nn-priv-filename);
g_free(nn-priv);
g_message(This is the finalize method and I've freed the instance
members!\n);
}
static void
neural_net_class_init (NeuralNetClass *klass){
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
gobject_class-finalize = neural_net_finalize;
g_type_class_add_private (klass, sizeof (NeuralNetPrivate));
}
I think this looks ok, doesn't it? No, wait a minite What about the
parent? This class has GObjectClass as parent, how do I call it's finalize?
At your class_init you should peek (g_type_class_peek_parent, using
your class pointer as parameter) a pointer to your parent class and
keep it in a global storage, accessible to your finalize.
Then, in your finalize method you call the finalize method on this
pointer you just got from peek_parent, something like:
G_OBJECT_CLASS(parent_class)-finalize(pointer_to_the_object_being_finalized);
I hope this helps.
Alexandre Moreira.
Thanks,
-Øystein
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
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
Actually I changed it to use the win32 one but it behaves the same. This seems to be a difficult one to answer, so far nobody has been able to even suggest anything. -Original Message- From: Chris Vine [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 May 2007 20:15 To: Burke.Daniel Cc: gtk-list@gnome.org Subject: Re: Hello and win32 g_io_channel help needed On Thu, 2007-05-03 at 14:04 +1000, Burke.Daniel wrote: Hail! I am new.. so gday to everyone here. I am after some assistance with getting my event-driven serial port input working on Windows. The project is a portable serial tool for internal use within our company, I am writing it using libglademm since I love C++ and am a big Gnome/GTK fan (my laptop being Ubuntu Gnome based) On Linux I am using open and termios to handle the serial port setup, finally returning a GIOChannel for monitoring and so far.. so good. However I am now trying to get the evil version of it running and am not so happy. Here I am using CreateFile to open and configure my port, then use: m_PortDescriptor = _open_osfhandle((long)m_PortHandle, 0); channel = g_io_channel_unix_new(m_PortDescriptor); to get the channel. Later on I use g_io_add_watch to setup a monitor which seems to compile and run ok, however when I send data using g_io_channel_write_chars it seems to crash and I also don’t seem to be receiving data (often resulting another application halt) You mention that you are using Windows, so is there any reason why you are calling g_io_channel_unix_new() instead of the g_io_channel_win32_new*() functions to create the GIOChannel object? Chris ___ 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
Failing this method I am moving to have my platform specific code handle the send and receiving, however I would still really like to use some kind of a callback like g_io_add_watch. 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? Regards, Burkey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Burke.Daniel Sent: Friday, 4 May 2007 10:11 To: gtk-list@gnome.org Subject: RE: Hello and win32 g_io_channel help needed Actually I changed it to use the win32 one but it behaves the same. This seems to be a difficult one to answer, so far nobody has been able to even suggest anything. -Original Message- From: Chris Vine [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 May 2007 20:15 To: Burke.Daniel Cc: gtk-list@gnome.org Subject: Re: Hello and win32 g_io_channel help needed On Thu, 2007-05-03 at 14:04 +1000, Burke.Daniel wrote: Hail! I am new.. so gday to everyone here. I am after some assistance with getting my event-driven serial port input working on Windows. The project is a portable serial tool for internal use within our company, I am writing it using libglademm since I love C++ and am a big Gnome/GTK fan (my laptop being Ubuntu Gnome based) On Linux I am using open and termios to handle the serial port setup, finally returning a GIOChannel for monitoring and so far.. so good. However I am now trying to get the evil version of it running and am not so happy. Here I am using CreateFile to open and configure my port, then use: m_PortDescriptor = _open_osfhandle((long)m_PortHandle, 0); channel = g_io_channel_unix_new(m_PortDescriptor); to get the channel. Later on I use g_io_add_watch to setup a monitor which seems to compile and run ok, however when I send data using g_io_channel_write_chars it seems to crash and I also don’t seem to be receiving data (often resulting another application halt) You mention that you are using Windows, so is there any reason why you are calling g_io_channel_unix_new() instead of the g_io_channel_win32_new*() functions to create the GIOChannel object? Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
How to compile all icons used in programm
hi all i need compile my icons into application how can i do it and how to access ? tks all ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Bug: GtkAboutDialog does not hide when close button clicked
On 03/05/07, Torsten Schoenfeld [EMAIL PROTECTED] wrote: On Sun, 2007-04-29 at 21:56 -0400, muppet wrote: The close_cb() actually manipulates a couple of internal widgets to which we do not have access. About the best we can do is the attached patch. I expect I'm missing the point, but what is wrong with: my $about = Gtk2::AboutDialog-new; $about-set_name ($program); $about-set_version ($version); $about-set_authors ($authors); $about-set_comments ($comments); $about-run; $about-destroy; ? The close button works fine this way. Jeff ___ 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 May 3, 2007, at 3:01 PM, Torsten Schoenfeld wrote: On Sun, 2007-04-29 at 21:56 -0400, muppet wrote: The close_cb() actually manipulates a couple of internal widgets to which we do not have access. About the best we can do is the attached patch. There's also this thread from some time ago with a Perl imitation of the behavior: http://mail.gnome.org/archives/gtk-perl-list/2006-December/ msg6.html I asked for feedback on it but received none. That's why I never committed it. Guh, no wonder it seemed very familiar. Now that i see the thread, i remember it. :-( 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. -- One, two, free, four, five, six, sebben, eight, nine, ten, elebben, twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen, fiffeen, elebbenteen! -- Zella, aged three, counting to twenty. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
