copying a file from a source path to destination path
Hi Team, How can i copy a file from a source path to destination using Glib libraries. I have checked using Glib file utilities, but could not find my requirement. Could you please look into this issue, and help me come out of this. Thanks and Regards, Lenin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: copying a file from a source path to destination path
Le vendredi 10 décembre 2010 à 10:55 +0530, Lourembam Lenin a écrit : > Hi Team, > > How can i copy a file from a source path to destination using Glib > libraries. See http://library.gnome.org/devel/gio/stable/GFile.html#g-file-copy > I have checked using Glib file utilities, but could not find my > requirement. I guess you only found the page listing basic file utility functions. The main GLib part for handling files is GIO. Next time you need help, please use gtk-app-devel-l...@gnome.org. The present list is only for development of GLib/GTK itself, not of applications using it. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
I have mostly taken care of GdkDragContext, GdkVisual and GdkDevice now. Some of the remaining pieces look more like candidates for dropping/cleanup instead of virtualization though: > gdk_spawn_command_line_on_screen > gdk_spawn_on_screen > gdk_spawn_on_screen_with_pipes Looking over the backends, only X11 has anything that is not a 100% direct mapping to g_spawn apis, and even that is only setting DISPLAY to a value returned by gdk_screen_make_display_name(). We could just make this backend-specific. I think the same goes for the various apis related to foreign windows: It would seem much more natural to me to move those to be backend-specific. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
While we're talking about getting rid of stuff, I'd like to get rid of > gdk_utf8_to_string_target > gdk_string_to_compound_text_for_display > gdk_utf8_to_compound_text_for_display > gdk_free_text_list > gdk_free_compound_text But I lack enough clue about selections to do that. Is there anyone with enough clue that could find an API that can do this? The biggest problem I have with these APIs is that either they should be used (in which case we need to make sure people actually use them when they have to by introducing GdkCompoundText etc types) or they should not be used and the gdk selection code should take care of them. But the current situation is that even people who worked on the DND code have no idea what it's for. (I asked in #gtk+ and nobody had any clue.) Benjamin On Fri, Dec 10, 2010 at 6:22 PM, Matthias Clasen wrote: > I have mostly taken care of GdkDragContext, GdkVisual and GdkDevice now. > Some of the remaining pieces look more like candidates for dropping/cleanup > instead of virtualization though: > >> gdk_spawn_command_line_on_screen >> gdk_spawn_on_screen >> gdk_spawn_on_screen_with_pipes > > Looking over the backends, only X11 has anything that is not a 100% > direct mapping to g_spawn apis, and even that is only setting DISPLAY > to a value returned by > gdk_screen_make_display_name(). We could just make this backend-specific. > > I think the same goes for the various apis related to foreign windows: > It would seem much more natural to me to move those to be > backend-specific. > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Fri, Dec 10, 2010 at 12:37 PM, Benjamin Otte wrote: > While we're talking about getting rid of stuff, I'd like to get rid of >> gdk_utf8_to_string_target >> gdk_string_to_compound_text_for_display >> gdk_utf8_to_compound_text_for_display >> gdk_free_text_list >> gdk_free_compound_text > > But I lack enough clue about selections to do that. Is there anyone > with enough clue that could find an API that can do this? > The biggest problem I have with these APIs is that either they should > be used (in which case we need to make sure people actually use them > when they have to by introducing GdkCompoundText etc types) or they > should not be used and the gdk selection code should take care of > them. But the current situation is that even people who worked on the > DND code have no idea what it's for. (I asked in #gtk+ and nobody had > any clue.) > Compound text is an old multi-charset encoding (in the spirit of iso 2022, from before the rise of unicode). The ICCCM specifies the a some (mostly obsolete) properties are to be set in this encoding, unless I misremember, and selection owners are probably also expected to handle it if it is requested. It has very little relevance in todays Unicode-dominated world, and we should probably look if we move the support for this entirely into the X11 backend and not expose it in apis. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Fri, Dec 10, 2010 at 12:22 PM, Matthias Clasen wrote: > I have mostly taken care of GdkDragContext, GdkVisual and GdkDevice now. > Some of the remaining pieces look more like candidates for dropping/cleanup > instead of virtualization though: > >> gdk_spawn_command_line_on_screen >> gdk_spawn_on_screen >> gdk_spawn_on_screen_with_pipes > > Looking over the backends, only X11 has anything that is not a 100% > direct mapping to g_spawn apis, and even that is only setting DISPLAY > to a value returned by > gdk_screen_make_display_name(). We could just make this backend-specific. > > I think the same goes for the various apis related to foreign windows: > It would seem much more natural to me to move those to be > backend-specific. > One more question I had forgotten to add here: What about GdkDisplayManager ? How does that relate to GdkBackend in your plans ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Wed, 2010-12-08 at 23:28 -0500, Matthias Clasen wrote: > On Tue, Dec 7, 2010 at 7:33 AM, Alexander Larsson wrote: > > On Mon, 2010-12-06 at 23:28 +0100, Alexander Larsson wrote: > > > * Merge gdk and gtk+ (if we want to do this, and i think it makes sense) > > * Rename libgtk-x11-3.0.so to libgtk-3.0.so > > * Change the way the pc files are set up so that gtk+-x11-3.0.pc just > > depends on gtk+-3.0 and adds the includedir for gdkx.h. > > I've committed my attempt at doing these tasks to the gdk-backend branch. I see you didn't add a gtk+-x11-3.0.pc. Maybe we still want this in so that apps can easily specify a build-time requirement for the x11 backend. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an old-fashioned arachnophobic paranormal investigator fleeing from a secret government programme. She's a mentally unstable cigar-chomping politician 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
Re: Building multiple backends on on same system
On Fri, 2010-12-10 at 12:53 -0500, Matthias Clasen wrote: > On Fri, Dec 10, 2010 at 12:22 PM, Matthias Clasen > wrote: > > I have mostly taken care of GdkDragContext, GdkVisual and GdkDevice now. > > Some of the remaining pieces look more like candidates for dropping/cleanup > > instead of virtualization though: > > > >> gdk_spawn_command_line_on_screen > >> gdk_spawn_on_screen > >> gdk_spawn_on_screen_with_pipes > > > > Looking over the backends, only X11 has anything that is not a 100% > > direct mapping to g_spawn apis, and even that is only setting DISPLAY > > to a value returned by > > gdk_screen_make_display_name(). We could just make this backend-specific. > > > > I think the same goes for the various apis related to foreign windows: > > It would seem much more natural to me to move those to be > > backend-specific. > > > > One more question I had forgotten to add here: > > What about GdkDisplayManager ? How does that relate to GdkBackend in > your plans ? I wasn't aware of that. Seems like we don't need GdkBackend then, just make GdkDisplayManager derived by the backends and add some vfuncs. Then we need to make gdk_display_manager_get() pick the right type of backend if there are multiple backends built-in. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish crooked matador looking for a cure to the poison coursing through his veins. She's a provocative tempestuous hooker with an MBA from Harvard. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Fri, Dec 10, 2010 at 1:29 PM, Alexander Larsson wrote: > On Wed, 2010-12-08 at 23:28 -0500, Matthias Clasen wrote: >> On Tue, Dec 7, 2010 at 7:33 AM, Alexander Larsson wrote: >> > On Mon, 2010-12-06 at 23:28 +0100, Alexander Larsson wrote: >> >> > * Merge gdk and gtk+ (if we want to do this, and i think it makes sense) >> > * Rename libgtk-x11-3.0.so to libgtk-3.0.so >> > * Change the way the pc files are set up so that gtk+-x11-3.0.pc just >> > depends on gtk+-3.0 and adds the includedir for gdkx.h. >> >> I've committed my attempt at doing these tasks to the gdk-backend branch. > > I see you didn't add a gtk+-x11-3.0.pc. Maybe we still want this in so > that apps can easily specify a build-time requirement for the x11 > backend. Yes, I am going to bring it back. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting, 2010-12-14
On Thu, 2010-12-09 at 14:25 +, Emmanuele Bassi wrote: > hi everyone; > > this is a reminder that the next GTK team meeting is scheduled for: > > Tuesday, December 14th, 2010 @ 20:00 UTC > > http://www.timeanddate.com/worldclock/fixedtime.html?day=14&month=12&year=2010&hour=20&min=0&sec=0&p1=0 > > channel: #gtk-devel on irc://irc.gnome.org > > agenda: > > • Release date for 3.0 > ‣ Pending tasks > • TreeView refactor > • GDK backend > • last minute API/ABI changes I'm not following things very well, but the radio groups work has not landed, nor is it listed here. Are we dropping that? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a deeply religious sweet-toothed card sharp who knows the secret of the alien invasion. She's a hard-bitten cigar-chomping wrestler 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: [REMINDER] GTK+ Team Meeting, 2010-12-14
On Fri, Dec 10, 2010 at 2:18 PM, Alexander Larsson wrote: > On Thu, 2010-12-09 at 14:25 +, Emmanuele Bassi wrote: >> hi everyone; >> >> this is a reminder that the next GTK team meeting is scheduled for: >> >> Tuesday, December 14th, 2010 @ 20:00 UTC >> >> http://www.timeanddate.com/worldclock/fixedtime.html?day=14&month=12&year=2010&hour=20&min=0&sec=0&p1=0 >> >> channel: #gtk-devel on irc://irc.gnome.org >> >> agenda: >> >> • Release date for 3.0 >> ‣ Pending tasks >> • TreeView refactor >> • GDK backend >> • last minute API/ABI changes > > I'm not following things very well, but the radio groups work has not > landed, nor is it listed here. Are we dropping that? We have some related button work in a branch, but it is not really conclusive. Ryan wanted to look into making things more to his liking, but he got pulled away... I guess we should revisit that on Tuesday, too. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Dec 10, 2010, at 9:37 AM, Benjamin Otte wrote: > While we're talking about getting rid of stuff, I'd like to get rid of >> gdk_utf8_to_string_target >> gdk_string_to_compound_text_for_display >> gdk_utf8_to_compound_text_for_display >> gdk_free_text_list >> gdk_free_compound_text > > But I lack enough clue about selections to do that. Is there anyone > with enough clue that could find an API that can do this? > The biggest problem I have with these APIs is that either they should > be used (in which case we need to make sure people actually use them > when they have to by introducing GdkCompoundText etc types) or they > should not be used and the gdk selection code should take care of > them. But the current situation is that even people who worked on the > DND code have no idea what it's for. (I asked in #gtk+ and nobody had > any clue.) > GdkSelection is a wrapper around the X11 selection functions. It's not used by Gtk, which has its own higher-level selection object which ties into GtkClipboard and GtkDnd... which is why almost nobody knows about GdkSelection any more. I only know about it only because I implemented GtkSelection for quartz last summer. It probably should be dropped completely, but if that's too radical, by all means banish it to the X11 backend. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Fri, Dec 10, 2010 at 3:50 PM, John Ralls wrote: > > > GdkSelection is a wrapper around the X11 selection functions. It's not used > by Gtk, which has its own higher-level selection object which ties into > GtkClipboard and GtkDnd... which is why almost nobody knows about > GdkSelection any more. I only know about it only because I implemented > GtkSelection for quartz last summer. > > It probably should be dropped completely, but if that's too radical, by all > means banish it to the X11 backend. That is not really true. $ grep -l gdk_selection *.c gtkdnd.c gtkselection.c gtktextbuffer.c ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building multiple backends on on same system
On Dec 10, 2010, at 2:21 PM, Matthias Clasen wrote: > On Fri, Dec 10, 2010 at 3:50 PM, John Ralls wrote: >> > >> >> GdkSelection is a wrapper around the X11 selection functions. It's not used >> by Gtk, which has its own higher-level selection object which ties into >> GtkClipboard and GtkDnd... which is why almost nobody knows about >> GdkSelection any more. I only know about it only because I implemented >> GtkSelection for quartz last summer. >> >> It probably should be dropped completely, but if that's too radical, by all >> means banish it to the X11 backend. > > That is not really true. > > $ grep -l gdk_selection *.c > gtkdnd.c > gtkselection.c > gtktextbuffer.c Sorry, you're right. I incorrectly confounded Kris's gtkdnd and my gtkselection implementations for quartz with the main one. GtkSelection is implemented in terms of GdkSelection -- otherwise I wouldn't have had to redo it for quartz. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: C99 complex types in Glib
hi; glib development is discussed on the gtk-devel mailing list, but I can directly answer to you right now. On Sat, 2010-12-11 at 00:19 +0100, CaStarCo wrote: > I write here because i have many doubts and because i want to > contribute with my code to the Glib library ^^ . cool, contributions are much welcome... > The first doubt is : The Glib project is using the C99 spec or the C89 > spec? for portability reasons, GLib follows the C89 spec. the C99 spec is not fully implemented by all compilers on all platforms we're tracking, so it cannot be used. > If it's the second case... there is any way to contribute to Glib > adding support to the complex floating point types that C99 introduced > in the year 2000 ? honestly, I doubt this is a compelling enough use case to introduce new types; applications that require complex floating point types will also require other ad hoc facilities that GLib does not provide. nevertheless, if new types have been introduced and if they can be checked at configure-time, then they may be supported by wrapping them, in to provide a graceful degradation path. code contributions for GLib go through Bugzilla: http://bugzilla.gnome.org/enter_bug.cgi?product=glib ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: C99 complex types in Glib
Hello :) 2010/12/11 Emmanuele Bassi > > hi; > > glib development is discussed on the gtk-devel mailing list, but I can > directly answer to you right now. > > On Sat, 2010-12-11 at 00:19 +0100, CaStarCo wrote: > > > I write here because i have many doubts and because i want to > > contribute with my code to the Glib library ^^ . > > cool, contributions are much welcome... > > > The first doubt is : The Glib project is using the C99 spec or the C89 > > spec? > > for portability reasons, GLib follows the C89 spec. the C99 spec is not > fully implemented by all compilers on all platforms we're tracking, so > it cannot be used. > > > If it's the second case... there is any way to contribute to Glib > > adding support to the complex floating point types that C99 introduced > > in the year 2000 ? > > honestly, I doubt this is a compelling enough use case to introduce new > types; applications that require complex floating point types will also > require other ad hoc facilities that GLib does not provide. > I don't think so :p , one usage example: extending the Vala language, in any case, the complex.h header provides simple functions to work with complex numbers. Another usage example: simplify the code of, for example, gcalctool. In any case, if the reasons of not extending Glib are related with compatibility, that's a stronger reason :) . > > nevertheless, if new types have been introduced and if they can be > checked at configure-time, then they may be supported by wrapping them, > in to provide a graceful degradation path. > > I have a doubt about that. To introduce a type following the way you described... I must create another "mini library" inside the Glib? > code contributions for GLib go through Bugzilla: > > http://bugzilla.gnome.org/enter_bug.cgi?product=glib > > ciao, > Emmanuele. > > > Thanks for your atention! -- - Per la llibertat del coneixement - - Per la llibertat de la ment... - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
