Re: volume:// uri support

[David Zeuthen]

On Thu, 2007-12-13 at 08:01 +0100, Mathias Hasselmann wrote:
> Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen:
> > There's a screenshot here showing integration into Nautilus
> > 
> > http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png
> 
> Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS
> style drive letters! That wish scares me. There must be a better
> solution than this geek style techie stuff.

Why do think the URI would ever be displayed in the UI?

(In fact, if you want to avoid implementations details like URI's
leaking into the UI one way of solving that problem is to make them
really ugly.)

  David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [directfb-dev] [directfb-users] Problems in GdkWindow Events with Gtk - DirectFb backend

[Sreenivas Chowdary]

Hi Mike,

  I could not find any function to get focussed child
gdkwindow. How to get currently focused gdk child.
  I created a Gdk Window using GDK_WINDOW_CHILD attribute.
  I gone through functionality of gdk_directfb_window_new().
For child GdkWindow, there is no Event Buffer  creation.
When gdk_event_translate() fnction called it could not call
apply_filters() function because child GdkWindow did not have
IdirectFbWindow.

   I can able to listen Events on Top level GdkWindow but how
to track to child gdkwindow inorder to invoke child gdkwindow event
call back handlers?

  Please suggest

Thanks & Regards
Sreenivas

On Dec 5, 2007 10:34 PM, Mike Emmel <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 8:52 AM, Sreenivas Chowdary <[EMAIL PROTECTED]> wrote:
> > Hi Denis,
> >
> >  I am relatively new to Gtk and DirectFb.
> >  Can you give any idea how to implement raw events for
> > child GdkWindow.
> >
>
> Listen to the top level window.
> You can get the currently focused gdk child but note I think you
> actually want the gtk widget which is different.
> In any case you can get the events off the top level and easily track
> the gtk/gdk widget that currently has focus.
> Your approach would not even work under X11 for gtk widgets that are
> not backed by a gdk widget.
>
>
> > Thanks,
> > Sreenivas
> >
> >
> > On Dec 5, 2007 9:07 PM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> > > Christopher Johnson wrote:
> > > > Unless I am grossly mistaken, any other behavior will create a serious
> > > > incompatibility between GTK+ backends.  I am currently struggling with
> > > > code that isn't getting events it expects (DirectFB 1.0.0 and GTK+
> > > > 2.10.13).  Sounds like maybe Mike's explanation might cover my problems
> > > > and incompatibilities with GTK/X.
> > >
> > > If you're not interested in raw X11 events, but only GdkEvents, your code
> > > should work with GDKDirectFB, otherwise it's a bug and needs to be fixed.
> > >
> > >
> > > --
> > > Best regards,
> > >   Denis Oliver Kropp
> > >
> > > .--.
> > > | DirectFB - Hardware accelerated graphics |
> > > | http://www.directfb.org/ |
> > > "--"
> > >
> >
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: volume:// uri support

[Mathias Hasselmann]

Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen:
> There's a screenshot here showing integration into Nautilus
> 
> http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png

Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS
style drive letters! That wish scares me. There must be a better
solution than this geek style techie stuff.

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

volume:// uri support

[David Zeuthen]

Hey Alex,

I've attached some preliminary patches to introduce a new volume:// name
space. The thinking is that g_file_get_uri() will return a persistent
URI if a local file is on user-visible media.

(Emphasis on user-visible. As in the media is visible in the UI, e.g.
computer://, Nautilus's sidebar and the file chooser). Notably files on
your rootfs (which we hide in the UI) will still use file:// URI's.)

For example this snippet

 GFile *f;
 f = g_vfs_get_file_for_path ("/media/disk/path/to/file.txt");
 uri = g_file_get_uri (f);
 printf ("uri is %s", uri);

 f = g_vfs_get_file_uri 
("volume://name=davidz%20data;uuid=1234/path/to/file.txt");
 uri = g_file_get_path (f);
 printf ("path is %s", uri);

will print

 volume://name=davidz%20data;uuid=1234/path/to/file.txt
 /media/disk/path/to/file.txt

There's a screenshot here showing integration into Nautilus

http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png

The patch to Nautilus also includes a small patch to show the URI in the
Location file under preferences; this is just for testing. Also, note
that the GUnixVolumeMonitor doesn't implement this yet; only the hal one
does (finding file system uuid's requires root privileges) - I'll get
around to send the finished hal patch tomorrow...

(there's also a bugfix in the Nautilus patch in src/nautilus-pathbar.c)

Anyway, the thinking is that this can be used in

 - Things like Rhythmbox, Banshee, F-Spot etc. to make sure things Just
   Work(tm) when having collections on removable media / external drives

 - Indexers like Beagle, Tracker etc.

 - Recently used files

Implementation-wise there's little to no overhead except that

 - g_vfs_get_file_from_uri() may block the very first time it's
   called with a volume:// URI since it needs to construct a
   GVolumeMonitor object

 - ditto for g_file_get_uri()

I don't think these are real problems; we already block for GDaemonFile
all the time IIRC. Other notes:

 - We probably want g_volume_monitor_get() to keep around a ref to
   the singleton when it's called and release that ref, say, 5 seconds
   later via a timeout. This is to avoid constructing and tearing down 
   volume monitors all the time. Thoughts?

 - Obviously things don't work when e.g. doubleclicking the icon
   representing /media/disk/path/to/file.txt because gedit isn't
   yet using gio (on my system). This is because Nautilus passes
   a volume:// URI. 

About the latter; there's a couple of options

 1. Introduce g_file_get_stable_uri() and always make g_file_get_uri()
return file:// URI's for local files

 2. Like 1. but reversed; introduce g_file_get_file_uri() (better name
wanted). Then we'd patch the few applications passing URI's to
other applications to use this on.

 3. Just screw it and port applications to gio already. Though there's
the compatibility with other desktops to take into account too.

 4. Like 3. and backport volume:// support to gnome-vfs

Personally I'd just go for option 4. - there's nothing like a little
breakage to help nudge people into fixing their apps to use newer API.
Thoughts?

  David

Index: gunixmount.c
===
--- gunixmount.c	(revision 6105)
+++ gunixmount.c	(working copy)
@@ -167,6 +167,20 @@
   return g_object_ref (unix_mount->icon);
 }
 
+static const char *
+g_unix_mount_get_uuid (GMount *mount)
+{
+  return NULL;
+}
+
+static const char *
+__g_unix_mount_get_mount_path (GMount *mount)
+{
+  GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
+
+  return unix_mount->mount_path;
+}
+
 static char *
 g_unix_mount_get_name (GMount *mount)
 {
@@ -340,6 +354,8 @@
   iface->get_root = g_unix_mount_get_root;
   iface->get_name = g_unix_mount_get_name;
   iface->get_icon = g_unix_mount_get_icon;
+  iface->get_uuid = g_unix_mount_get_uuid;
+  iface->get_mount_path = __g_unix_mount_get_mount_path;
   iface->get_drive = g_unix_mount_get_drive;
   iface->get_volume = g_unix_mount_get_volume;
   iface->can_unmount = g_unix_mount_can_unmount;
Index: glocalvfs.c
===
--- glocalvfs.c	(revision 6105)
+++ glocalvfs.c	(working copy)
@@ -1,3 +1,5 @@
+/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
+
 /* GIO - GLib Input, Output and Streaming Library
  * 
  * Copyright (C) 2006-2007 Red Hat, Inc.
@@ -23,6 +25,8 @@
 #include 
 #include "glocalvfs.h"
 #include "glocalfile.h"
+#include "gvolumemonitor.h"
+
 #include 
 #include 
 #ifdef HAVE_PWD_H
@@ -77,29 +81,69 @@
   return _g_local_file_new (path);
 }
 
+#include 
+
 static GFile *
 g_local_vfs_get_file_for_uri (GVfs   *vfs,
   const char *uri)
 {
+  char *uuid;
   char *path;
   GFile *file;
+  gsize path_offset;
+  char *local_path;
+  const char *mount_path;
+  GVolumeMonitor *volume_monitor;
+  GMount *mount;
 
-  path = g_filename_from_uri (uri, NULL, NULL);
+  if (g_str_has_prefix (uri, "volume://"))

Re: Gtk (X11) on Embedded Device Query

[Saroj Kumar]

Hi,

I ported X11 and Gtk with X11 support on Embedded board(arm-linux).
The problem I am facing now is setting the fontconfig. Because I have
fontconfig and freetype libraries for X11 and I compiled Gtk with those
libraries.

The following error is produced when I tried to run gtkdemo application.

*(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Could not open converter from 'UTF-8' to 'ISO-8859-'

(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Conversion from character set 'UTF-8' to 'ISO-8859-d
Fontconfig warning: line 32: unknown element "cachedir"
Fontconfig warning: line 33: unknown element "cachedir"
Fontconfig error: "conf.d", line 1: no element found

(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Conversion from character set 'UTF-8' to 'ISO-8859-d

(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Conversion from character set 'UTF-8' to 'ISO-8859-d

(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING:
Conversion from character set 'UTF-8' to 'ISO-8859-d
Segmentation fault
*

What I am doing is correct or not. Pls. suggest some solution for this.

Thanks and Regards,
Saroz


On Nov 30, 2007 5:54 PM, Ross Burton <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-11-30 at 17:41 +0530, Saroj Kumar wrote:
> > Now I am planning to run gtk+ on X-server. I started hunting for
> > X-server and found TinyX.
> > Now how to cross-compile X-server? Is there any document on it.
> >
> > I downloaded X-server from Xfree86 ftp site. Plz. guide me on
> > cross-compiling.
>
> The releases on x.org are probably preferable, as they are easier to
> build.  I really recommend that you investigate a build system such as
> Poky or OpenEmbedded instead of building it all by hand, which is a
> *world of pain*.
>
> Ross
> --
> Ross Burton mail: [EMAIL PROTECTED]
>  jabber: [EMAIL PROTECTED]
> www: http://www.burtonini.com./
>  PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: PLS HELP-URGENT...Error in running GTK application on MIPS board using GTK+ over DirectFB

[Sven Neumann]

Hi,

these questions are better asked on the directfb-user list. They are not
really specific to GTK+ and you are more likely going to get an answer
there.


Sven


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Sven Neumann]

Hi,

On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> We stronlgy suggest to use a common g_io/GIO prefix for all
> functions/types in GIO.
> 
> GAsnc*-> GIOAsync*
> G*Stream  -> GIOStream*
> GIcon -> GIOIcon
> G*Icon-> GIOIcon*
> GCancellable  -> GIOCancellable

I strongly agree with Mitch here. Having a common prefix would help a
lot to keep the GLib API structured.

> Also, subclasses should probably append their name, not prepend it:
> 
> GFilterOutputStream -> GIOOutputStreamFilter
> GUnixOutputStream   -> GIOOutputStreamUnix

Yes please. This is perhaps not close to the human language, but we are
talking about an API here. I really like to see all output stream
classes listed together and this naming convention achieves this
automatically.


Sven


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMountOperation concerns

[David Zeuthen]

On Wed, 2007-12-12 at 12:05 -0500, David Zeuthen wrote:
> So I'm thinking a similar pattern would be useful for g_volume_mount();
> it would move all credentials handling out of process. The downside is
> that the application itself cannot draw it's own dialogs for asking for
> credentials. But I think that's fine; we don't let gnome-keyring using
> apps do this either.

Just to clarify; this is how the interaction would be

 +-+  gvfs IO Channel
 | App using libgio.so |+
 +-+|
|  +-+
| IPC (e.g. D-Bus) | out-of-process gvfs plug-in |
|  +-+
  +-+|
  | ask-credentials-program |+
  +-+   Secure Channel for
passing credentials
(not D-Bus in session bus mode as the
bus is snoopable)

Of course to make this secure both ask-credentials-program and the
out-of-process gvfs plugin (e.g. smb://) will need to be locked down.
One easy way to do this is plain-vanilla UNIX-like systems is to make
them setgid nobody (so libc secure mode kicks in). 

Also, the ask-credentials-program could be a proxy for a GTK+ program,
e.g. gtk-ask-credentials-program, that runs on another secure desktop
session (e.g. the gdm login screen) and to get there you would need to
use SAK (secure attention key; e.g. ctrl+alt+backspace or whatever); or
when the windowing system and toolkit have secure modes that could be
used.

For the record I'm not proposing that we do this work now; I'm only
proposing to make the API secure and capable of doing things like this
in the future.

 David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: nmake build fixes for glib.

[Cody Russell]

On Wed, 2007-12-12 at 17:43 +0100, Lieven van der Heide wrote:
> Hi,
> 
> I made some fixes for the nmake makefiles and the win32-fixup.pl script.
> 
> glib, gmodule, gthread and gobject build fine now. gio and tests don't
> build yet, but I don't think that's related to the makefiles.
> 
> Also, right now (in svn), it assume that libiconv and gettext are in a
> folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions
> don't seem to be outdated anyway, but instead of changing it to the
> current version, I just changed it to plain ../gettext and
> ../libiconv, because I don't think there's really one specific version
> you want to link to, just as long as it isn't too old (I assume they
> try to stay API and ABI compatible with older version).

This is really awesome!  I'll test it out hopefully later today.  In the
mean time, would you mind opening a Bugzilla bug for this and attaching
your patches to it?  CC me on the bug, or email me the bug# too.

/ Cody

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GMountOperation concerns

[David Zeuthen]

Hi,

I've looked at the GMountOperation class today and I have some security
concerns. Basically, the way I understand how it's supposed to work is
that if you mount something you may need to provide credentials. Also,
I understand a GtkMountOperation subclass is planned that can also fetch
the credentials from gnome-keyring. 

I suppose the two main (and probably only) users who are here are the
file manager and the file chooser. As the latter runs in-process in any
application X it means the process space of application X can see the
passwords. This is pretty suboptimal especially considering that you may
not want to trust the application (e.g. closed source stuff using gvfs).

So, ideally, dialogs prompting for credentials should be as small as
possible and run in their own process space. With technologies such as
SELinux, and in the future XACE, one can ideally lock such applications
down insofar that no other process owned by the same user can interfere
with it [1] (e.g. use ptrace(2) or read it's memory). This is the
approach I've take for PolicyKit (which prompts for both user and
superuser credentials); basically the core fd.o PolicyKit library (which
is toolkit agnostic) defines an session-wide D-Bus service 

http://hal.freedesktop.org/docs/PolicyKit/model-authentication-agent.html

that desktops like GNOME or KDE or whatever can implement. For GNOME, I
have such an agent implementing this standard interface

http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html

and I know some KDE guys are working on a similar implementation for
KDE.

So I'm thinking a similar pattern would be useful for g_volume_mount();
it would move all credentials handling out of process. The downside is
that the application itself cannot draw it's own dialogs for asking for
credentials. But I think that's fine; we don't let gnome-keyring using
apps do this either.

Thoughts?

 David


[1] : Sure, this is _a lot_ of work and will require a "secure mode" for
toolkit libraries just like libc has a secure mode (which is forced for
setgid/setuid binaries etc). I understand this is currently not a goal
of GTK+ but someday it may be [2]. There's also lots of other attach
vectors; X11, a11y etc. etc.

The point is really that gio is toolkit agnostic and one may want to use
a secure toolkit, perhaps on a platform when using a secure windowing
system (e.g. not X11 or X11 with e.g. XACE).

[2] : I'm not really interested in starting a "should GTK+ have a secure
mode" thread; I fully understand all the issues and why it's like this
today.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

nmake build fixes for glib.

[Lieven van der Heide]

Hi,

I made some fixes for the nmake makefiles and the win32-fixup.pl script.

glib, gmodule, gthread and gobject build fine now. gio and tests don't
build yet, but I don't think that's related to the makefiles.

Also, right now (in svn), it assume that libiconv and gettext are in a
folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions
don't seem to be outdated anyway, but instead of changing it to the
current version, I just changed it to plain ../gettext and
../libiconv, because I don't think there's really one specific version
you want to link to, just as long as it isn't too old (I assume they
try to stay API and ABI compatible with older version).

Greets,

Lieven van der Heide.


for build folder.patch
Description: Binary data


for glib folder.patch
Description: Binary data
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Michael Natterer]

Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
>> G*Monitor:
>> ==
>>
>> GFileMonitor  -> GIOMonitorFile
>> GDirectoryMonitor -> GIOMonitorDirectory
>>
>> Wouldn't it make sense to have a common (perhaps abstract) base class here,
>> or derive one from the other? The APIs are very similar at least.
> 
> They are very similar, but I'm not sure what advantage a common base
> class would have. Its not likely that you pass around an object that is
> either a file monitor or a directory monitor, so GMonitor would not be
> used anywhere.

Well the common base class would install the "changed" signal, it
would have cancel(), is_cancelles(), set_rate_limit() and emit_event()
APIs, they would share their properties, and they would share the code
instead of duplicating it.

GIOMonitor would simply be an abstract base class, and it doesn't
matter if you really need the polymorphy here (passing them around
around as Monitor instead of File or Directory monitor), the point
is that there is code duplication in two very similar classes,
that almost cries for a common base class.

ciao,
--mitch
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Murray Cumming]

On Wed, 2007-12-12 at 16:37 +0100, Alexander Larsson wrote:
> > >> GAsnc*-> GIOAsync*
> > >> G*Stream  -> GIOStream*
> > >> GIcon -> GIOIcon
> > >> G*Icon-> GIOIcon*
> > >> GCancellable  -> GIOCancellable
> > >> ...
> > > 
> > > I strongly oppose this. 
> > 
> > I personally prefer the naming Mitch suggests. I know from the name
> > which sub-library the API belongs to in GLib.
> 
> I don't think this is something that is all that important when you
> actually use the API. It certainly isn't so important that its worth
> (methaphorically) punching you in the face every time you read or
> write
> the symbol.

If these are are all about IO and/or generally meant to be used
together, I would also like them to share some namespace. If glib
doesn't do it then I'll probably do it when I wrap them in glibmm. But I
love namespaces.

If they are likely to be used separately, if they are generally meant to
be self-contained then I'd be happy with just g_.

-- 
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Mikael Hallendal]

12 dec 2007 kl. 14.59 skrev Alexander Larsson:

Hi,

> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:

>
>> A big issue is that GIO wastes namespaces massively:
>>   g_app, GAsync, g_buffered, g_cancellable, g_content, g_data,
>>   g_desktop, g_directory, g_drive, g_file, g_filename, g_filter,
>>   g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable,
>>   g_local, g_memory, g_mount, g_native, g_seekable, g_simple,
>>   g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop
>>
>> That's clearly too much and can be reduced. While these are not
>> strictly "namespaces" (the namespace is g_), they partly clash with
>> g_foos and g_bars we already have, or might need in the future. We
>> stronlgy suggest to use a common g_io/GIO prefix for all
>> functions/types in GIO.
>>
>> GAsnc*-> GIOAsync*
>> G*Stream  -> GIOStream*
>> GIcon -> GIOIcon
>> G*Icon-> GIOIcon*
>> GCancellable  -> GIOCancellable
>> ...
>
> I strongly oppose this.
>
> While gio is a separate library these are all symbols in the glib
> module, and while it might be a problem at times we can handle any
> conflict issues (since we control both libs and release them  
> toghether).
> So, I don't think the problem with this is that bad. I mean, gobject
> doesn't call its symbols GObjectClosure, g_object_signal,  
> GObjectValue,
> etc, and this has not been a problem.

The big issue is that GIO wastes a lot (31) of namespaces for no  
purpose. While some might not make sense to put under the GIO  
namespace (GIOIcon might be one of these, I don't know), the main  
chunk of them do.

The examples you took from GObject are perfect examples of parts that  
are a fundamental and big part of the GObject library and got their  
own namespaces. I'm sure there are a bunch of those in GIO as well,  
however, we should really consider it several times when introducing  
new namespaces. Both for future and for people trying to use the  
library.

Best Regards,
   Mikael Hallendal

--
Imendio AB, http://www.imendio.com/

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Michael Natterer]

Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
>> Hey everybody,
>>
>> We've been doing a GIO API review in the last couple of days and
>> here is the list of comments and issues we've come up with:
>>
>>
>> General:
>> 
>>
>> It seems GIO allows individual files to be included, this should be
>> avoided like gobject does it:
>>
>> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION)
>> #error "Only  can be included directly."
>> #endif
> 
> Why? I know gobject does this, but I never understood why. It seems to
> just make build times longer.

Because otherwise you get into the very same typedef and include mess
we have in glib and gtk+. It makes it *very* hard to change anything
type related in the future. Any addition of a new function that happens
to use a new type which was not used in that header before might work
fine for the library's build itdelf, but might break the build of
applications that include whatever combination of headers.

Clear structure of headers and types should never be traded for compile
time, we also keep distinct things in distinct .c files. Why would we
scatter our typedefs across our libraries, or keep certain includes in
headers forever?

Allowing single library headers to be included just adds one more
completely unneccessary layer of compatibility that needs to be
preserved by all means as long as we guarantee source compatibility.

*Please* let's at least get rid of that compatibility mess by simply
not creating it in the first place.

Also, if you have a common header for your library, you can easily
split headers later if it turns out to be neccessary.

I would even argue that it makes most sense to keep all opaque typedefs
in one single file and include that from "gio.h" and from each source
file within GIO. This way you can avoid including any headers from
headers at all and it makes things so *very* much easier to maintain.
We changed all of GIMP to this policy a few years back and never had
a single (!!!) problem related to includes ever since.

Deploying such a policy makes it completely clear where the opaque
typedefs are: they are always in giotypes.h. There would be no need
to have the typedef for GMount in gfile.h and have a comment like this:

/* GMount typedef is in gfile.h due to include order issues */

in gmount.h, because there would be *no* include order issues.

(will follow up on the rest in another mail)

ciao,
--mitch
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Mathias Hasselmann]

I have to support regarding the stream and file class names:

"GIOInputStreamUnix"

reads to me, like using a "Unix" class which is in the "InputStream"
namespace, that's embedded in the "GIO" namespace:

GIO::InputStream::Unix

So using that naming conventions input and output stream would end in
different namespaces:

GIO::OutputStream::Unix

Well, and what's an "Unix" anyway?

The suffix game works for GtkTextView and GtkTreeView, as its "Iter"s
and "Path"s and whatever are objects for which it makes sense to live in
a Gtk::TextView namespace. "Iter" and "Path" are reasonable class names
on them own. "Unix" isn't.

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Alexander Larsson]

On Wed, 2007-12-12 at 15:13 +, Martyn Russell wrote:
> Alexander Larsson wrote:
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
> >>
> >> GAsnc*-> GIOAsync*
> >> G*Stream  -> GIOStream*
> >> GIcon -> GIOIcon
> >> G*Icon-> GIOIcon*
> >> GCancellable  -> GIOCancellable
> >> ...
> > 
> > I strongly oppose this. 
> 
> I personally prefer the naming Mitch suggests. I know from the name
> which sub-library the API belongs to in GLib.

I don't think this is something that is all that important when you
actually use the API. It certainly isn't so important that its worth
(methaphorically) punching you in the face every time you read or write
the symbol.

> > So, I don't think the problem with this is that bad. I mean, gobject
> > doesn't call its symbols GObjectClosure, g_object_signal, GObjectValue,
> > etc, and this has not been a problem.
> 
> There are of course inconsistencies through out the toolkit already.

I wouldn't call it inconsistent. I think it is a correct design decision
that it is called g_signal_stop_emission, and not
g_object_signal_stop_emission.

> > The negative aspect of such a change is that every symbol and name gets
> > longer, which is harder to read and harder to write. Also when you work
> > on a higher level you're forced to know which sub library of glib each
> > class is from (which you don't really care about, especially if these
> > types are exposed in higher level APIs). 
> 
> That's true.
> 
> > It also makes the symbol names weird. I mean GIOIcon? Is that in icon
> > somehow related to an io operation (no), or is it an generic icon type
> > (yes, that we hopefully will be using in a lot more APIs later)?
> 
> Well, that depends how you look at it. Some people might think that it
> is just an icon object which is part of the GIO library, others might
> think it is an icon object with IO functions.
> 
> I suppose you could argue that if it doesn't have any IO functionality,
> could it be added to the glib core library?

No it can't, because it uses GObject. This goes back to the previous
discussion about what library to use when adding other gobject based
APIs like DConf to glib. At the moment I think the idea is to put those
in libgio, but have separate headers and a separate .pc files. This
makes the g_io_ prefix even weirder.


> > And I really think the current model is better. Its flows more natural
> > in human language and its what other programming languages do, Its also
> > easy to understand what name a class should have, while the postfix
> > model does not always make this obvious, especially with multiple levels
> > of inheritance:
> 
> I tend to find the current naming less clear regarding what exactly it
> inherits from and takes longer to adopt to when learning the new API. I
> agree though, it doesn't sound too nice when saying it from a human
> language point of view.

I think this misses the point. I don't see the primary thing for a class
name is to describe what class it inherits from, it is to describe what
the class *does*. In some cases this is a completely different name from
the base class, as in GtkButton vs GtkWidget (not GtkButtonWidget), but
sometimes a good way to describe the class is to prepend something to
it. Take for instance GDataInputStream, where "Data" was prepended,
resulting in a new name that describes what it does (data input). 

Now, there is sort of a third case which is where we have a
implementation of an abstract class/interface for a specific backend,
such as GVolume/GUnixVolume or GFile/GLocalFile. I think its really this
case that people think is better to use postfixes for. But I don't think
its better even there.

> > While it certainly won't hurt to add it there I don't really see it as
> > much of an advantage either. You really want the cancel button to
> > immediately cancel the operation, not wait until the next progress
> > callback. Furthermore, many ops don't have a progress callback so you
> > need a cancellable object stored anyway. So, the natural thing is to
> > store the cancellable in the cancel dialog and then pass it into the
> > operation and use this for all cancellation. Then, when updating the
> > progress bar in the dialog cancellation is not involved at all.
> 
> That is assuming you never want to cancel the operation from some
> calculation inside the callback. I personally would prefer the
> cancellation in the callback.

Its certainly possible to cancel from the callback. All you have to do
is store the cancallable in the dialog and pass the dialog pointer as
user data. 

Now, do we want to make it *easier* to cancel from the progress
callback. I don't think doing so is a good design as it will cause
cancellation to not be as responsive as it should be. So, passing the
cancellable in the progress callback would encourage problematic
designs.

> >> GIOScheduler:
> >> =
> >>
> >> Each function has a different namespace here, I suggest:
> >>
> 

Re: GIO API review

[Martyn Russell]

Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
>>
>> GAsnc*-> GIOAsync*
>> G*Stream  -> GIOStream*
>> GIcon -> GIOIcon
>> G*Icon-> GIOIcon*
>> GCancellable  -> GIOCancellable
>> ...
> 
> I strongly oppose this. 

I personally prefer the naming Mitch suggests. I know from the name
which sub-library the API belongs to in GLib.

> So, I don't think the problem with this is that bad. I mean, gobject
> doesn't call its symbols GObjectClosure, g_object_signal, GObjectValue,
> etc, and this has not been a problem.

There are of course inconsistencies through out the toolkit already.

> The negative aspect of such a change is that every symbol and name gets
> longer, which is harder to read and harder to write. Also when you work
> on a higher level you're forced to know which sub library of glib each
> class is from (which you don't really care about, especially if these
> types are exposed in higher level APIs). 

That's true.

> It also makes the symbol names weird. I mean GIOIcon? Is that in icon
> somehow related to an io operation (no), or is it an generic icon type
> (yes, that we hopefully will be using in a lot more APIs later)?

Well, that depends how you look at it. Some people might think that it
is just an icon object which is part of the GIO library, others might
think it is an icon object with IO functions.

I suppose you could argue that if it doesn't have any IO functionality,
could it be added to the glib core library?

Before you mentioned that it could be considered to have IO
functionality, I hadn't really thought of it like that, I just assumed
it was an Icon object in the GIO library :) But I see your point.

>> Also, subclasses should probably append their name, not prepend it:
>>
>> GFilterOutputStream -> GIOOutputStreamFilter
>> GUnixOutputStream   -> GIOOutputStreamUnix
>> ...
>>
>> This makes the file and inheritence structure much clearer and would
>> be consistent with stuff we already have (e.g. GtkTreeModelFilter,
>> GtkTreeModelSort).
> 
> This was brought up on this list before during the initial gio reviews.
> The original version in fact had things appended (at least at places, it
> wasn't totally consistent). But it was all cleaned up to be consistent,
> and after that discussion I picked the current model.
> 
> And I really think the current model is better. Its flows more natural
> in human language and its what other programming languages do, Its also
> easy to understand what name a class should have, while the postfix
> model does not always make this obvious, especially with multiple levels
> of inheritance:

I tend to find the current naming less clear regarding what exactly it
inherits from and takes longer to adopt to when learning the new API. I
agree though, it doesn't sound too nice when saying it from a human
language point of view.

Just don't look at the Gossip source code ;)

>> All progress callbacks should have a cancellable argument, otherwise
>> you always need to pass the cancellable as user_data if your progress
>> dialog has a cancel button.
> 
> While it certainly won't hurt to add it there I don't really see it as
> much of an advantage either. You really want the cancel button to
> immediately cancel the operation, not wait until the next progress
> callback. Furthermore, many ops don't have a progress callback so you
> need a cancellable object stored anyway. So, the natural thing is to
> store the cancellable in the cancel dialog and then pass it into the
> operation and use this for all cancellation. Then, when updating the
> progress bar in the dialog cancellation is not involved at all.

That is assuming you never want to cancel the operation from some
calculation inside the callback. I personally would prefer the
cancellation in the callback.

>> Also, there is no good reason to use abbreviations like "std" and "fs",
>> we are not in the 60ies any more ;)
>>
>> std -> standard
>> fs  -> filesystem
>>
>> std:type  -> standard::type
>> std:is_hidden -> standard::is-hidden
> 
> standard::type is 14 bytes, std:type is 8, given 10 std:* attributes per
> file and 1000 files in a directory, this means transfering 6 more
> bytes over dbus when reading this directory using gvfs. I'm not sure
> this is a horrible number, as there are bound to be other slow parts
> when involving gvfs (such as network traffic), but it might matter.
> 
> I don't mind changing this though. What do other people change?

I think "standard" and "filesystem" are better. They save questions and
people looking up the acronyms in the documentation too.

>> There also seems to be quite some duplication between GFileInfo and
>> GFileAttributeValue for no good reason, such as:
>>
>> g_file_info_get_attribute_string vs. g_file_attribute_value_get_string
>> g_file_info_set_attribute_int32  vs. g_file_attribute_value_set_int32
>> ...
>>
>> Where these functions in GFileInfo just seem to create/get a
>> GFileAttrib

Re: GIO API review

[Alexander Larsson]

On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
> Hey everybody,
> 
> We've been doing a GIO API review in the last couple of days and
> here is the list of comments and issues we've come up with:
> 
> 
> General:
> 
> 
> It seems GIO allows individual files to be included, this should be
> avoided like gobject does it:
> 
> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION)
> #error "Only  can be included directly."
> #endif

Why? I know gobject does this, but I never understood why. It seems to
just make build times longer.

> A big issue is that GIO wastes namespaces massively:
>g_app, GAsync, g_buffered, g_cancellable, g_content, g_data,
>g_desktop, g_directory, g_drive, g_file, g_filename, g_filter,
>g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable,
>g_local, g_memory, g_mount, g_native, g_seekable, g_simple,
>g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop
> 
> That's clearly too much and can be reduced. While these are not
> strictly "namespaces" (the namespace is g_), they partly clash with
> g_foos and g_bars we already have, or might need in the future. We
> stronlgy suggest to use a common g_io/GIO prefix for all
> functions/types in GIO.
> 
> GAsnc*-> GIOAsync*
> G*Stream  -> GIOStream*
> GIcon -> GIOIcon
> G*Icon-> GIOIcon*
> GCancellable  -> GIOCancellable
> ...

I strongly oppose this. 

While gio is a separate library these are all symbols in the glib
module, and while it might be a problem at times we can handle any
conflict issues (since we control both libs and release them toghether).
So, I don't think the problem with this is that bad. I mean, gobject
doesn't call its symbols GObjectClosure, g_object_signal, GObjectValue,
etc, and this has not been a problem.

The negative aspect of such a change is that every symbol and name gets
longer, which is harder to read and harder to write. Also when you work
on a higher level you're forced to know which sub library of glib each
class is from (which you don't really care about, especially if these
types are exposed in higher level APIs). 

It also makes the symbol names weird. I mean GIOIcon? Is that in icon
somehow related to an io operation (no), or is it an generic icon type
(yes, that we hopefully will be using in a lot more APIs later)?

> Also, subclasses should probably append their name, not prepend it:
> 
> GFilterOutputStream -> GIOOutputStreamFilter
> GUnixOutputStream   -> GIOOutputStreamUnix
> ...
> 
> This makes the file and inheritence structure much clearer and would
> be consistent with stuff we already have (e.g. GtkTreeModelFilter,
> GtkTreeModelSort).

This was brought up on this list before during the initial gio reviews.
The original version in fact had things appended (at least at places, it
wasn't totally consistent). But it was all cleaned up to be consistent,
and after that discussion I picked the current model.

And I really think the current model is better. Its flows more natural
in human language and its what other programming languages do, Its also
easy to understand what name a class should have, while the postfix
model does not always make this obvious, especially with multiple levels
of inheritance:

GInputStream is a stream for input (shouldn't it then be GStreamInput?),
then we have an abstract subclass for this that adds some file specific
operations: GFileInputStream. What is the name of an implementation of
this for local files. In the prefix model its the easily readable
GLocalFileInputStream. What is it in the postfix model?
GInputStreamFileLocal? GFileInputStreamLocal? The first is the strictly
correct one i guess, but its a quite bad name, the second is slightly
more readable, but seems to imply that its parent is GFileInputStream,
which does not follow the postfix pattern.

> All progress callbacks should have a cancellable argument, otherwise
> you always need to pass the cancellable as user_data if your progress
> dialog has a cancel button.

While it certainly won't hurt to add it there I don't really see it as
much of an advantage either. You really want the cancel button to
immediately cancel the operation, not wait until the next progress
callback. Furthermore, many ops don't have a progress callback so you
need a cancellable object stored anyway. So, the natural thing is to
store the cancellable in the cancel dialog and then pass it into the
operation and use this for all cancellation. Then, when updating the
progress bar in the dialog cancellation is not involved at all.

> All parent instance members should be called "parent_instance" for
> consistency, "parent" is a far too common member name to be used
> like that.

Yeah, I'll change that.

> Nitpick: The number of padding elements in class structures varies, why?

I added a lot where it seemed likely things will be extended in the
future and less for things that weren't likely to change. This is mainly
to save memory. 

> GFile:
> ==

Add to mailing list

[sudam]

 

 

sudam sagara

 



***

"The information contained in this email including in any attachment is 
confidential and is meant to be read only by the person to whom it is 
addressed. If you are not the intended recipient(s), you are prohibited from 
printing, forwarding, saving or copying this email. If you have received this 
e-mail in error, please immediately notify the sender and delete this e-mail 
and its attachments from your computer."

***___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO API review

[Michael Natterer]

Sorry for mis-following-up and resending, i have too many mail accounts.

On Wed, 2007-12-12 at 00:25 +, Emmanuele Bassi wrote:
 > On Tue, 2007-12-11 at 21:22 +0200, Vincent Geddes wrote:
 > > Hi,
 > >
 > > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
 > > > Also, subclasses should probably append their name, not prepend it:
 > > >
 > > > GFilterOutputStream -> GIOOutputStreamFilter
 > > > GUnixOutputStream   -> GIOOutputStreamUnix
 > > > ...
 > > >
 > > > This makes the file and inheritence structure much clearer and would
 > > > be consistent with stuff we already have (e.g. GtkTreeModelFilter,
 > > > GtkTreeModelSort).
 > >
 > > Looking over the GTK+ classes, it seems like the TreeView classes are
 > > the odd ones out. Most classes seem to follow the naming pattern in 
gio,
 > > examples being GtkToggleButton, GtkCheckMenuItem, GtkAccelLabel,
 > > GtkAboutDialog, etc.
 >
 > true. :-)
 >
 > > Besides, the proposed naming in the review does go against the naming
 > > convention set by Smalltalk, Java, C#, et al; and if implemented will
 > > probably confuse users coming to GTK+ from those worlds.
 >
 > even though I usually favour internal consistency against the "proof by
 > other language" when writing an API for my projects, in this case I
 > completely agree: C++, Java, C# and other languages that have I/O stream
 > classes went down the same naming policy with Type(Input|Output)Stream.

I agree it should be InputStream and OutputStream (instead of
StreamInput and
StreamOutput, which would be taking the proposal to its extreme), but
then
we have good examples for the "append" approach in glib (no need to take
GTK+ as an example here):

GParamSpecFloat
GParamSpecInt
GParamSpecFoo
...

This also enables comfortable working with the source code:

 > ls gio/gioinputstream*.h
gioinputstreamfile.h
gioinputstreamfoo.h
gioinputstreambar.h
...

 > grep foo gio/gioinputstream*.c
...you get the idea.

(yes i know you can ls and grep with the other approach too, my point
is rather that it's nice and helpful to recognize common ancestry by
common prefixes)

As Behdad says, this is not a human language, and we shouldn't trade
internal structural consistency and consistency *within* glib for
whatever consistency with other frameworks (which is clearly less
important than internal consistency).

ciao,
--mitch

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: PLS HELP-URGENT...Error in running GTK application on MIPS board using GTK+ over DirectFB

[Attilio Fiandrotti]

Sundeep Prakash wrote:
> Hi,
> 
>I have cross compiled GTK+2.10.12 and DirectFB 1.0.0 for MIPS  
> BCM7401 with all the dependancy as below:

...

> 
> Initially, execution failed at
> 
> ret=directfb->GetInputDevice(directfb, DIDID_KEYBOARD, &keyboard) ;
> 
> in gtk+-2.10.14/gdk/directfb/gdkdisplay- directfb.c  
> 
> I commented out some line related to keyboard because WE ARE NOT USING 
> ANY INPUT DEVICE.

A similar issue was reported some times ago, please have a look at this
thread [1].

Attilio

[1] http://mail.directfb.org/pipermail/directfb-users/2007-June/003077.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gio changes for GVolume and GDrive

[Alexander Larsson]

On Tue, 2007-12-11 at 16:38 -0500, David Zeuthen wrote:
> On Tue, 2007-12-11 at 09:50 -0500, David Zeuthen wrote:
> > > So, Maybe a better set of names would be something like:
> > > GDrive <-1-n-> GVolume <-1-1-> GMount
> > > 
> > > Other alternatives for GMount: GMountedVolume, GMounted, GMountPoint
> > > Any other ideas?
> 
> I've talked to alexl and mclasen on IRC and we went for Alex's
> 
>  GDrive <-1-n-> GVolume <-1-1-> GMount
> 
> So I did the rename and I've committed this to glib/gio trunk. I've also
> fixed up gvfs and nautilus to use this. Everything seems to work fine.

Why did you add padding to GVolume, etc. They are GInterfaces, and as
such extendable without padding.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

PLS HELP-URGENT...Error in running GTK application on MIPS board using GTK+ over DirectFB

[Sundeep Prakash]

 Hi,

   I have cross compiled GTK+2.10.12 and DirectFB 1.0.0 for MIPS  BCM7401
with all the dependancy as below:

tiff 3.7.4
libpng 1.2.18
libjpeg-6b
glib 2.12.13
atk 1.9.1
freetype 2.3.4
fontconfig 2.4.2
cairo 1.2.6
pango 1.16.4

and used the configuration parameter as given at
http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB_for_Embedded_Systems
.

I executed a simple GTK program(code snippet below) which loads an image

#include 

int main( int   argc, char *argv[] )
{
GtkWidget *window;
GtkWidget *pMainWidget;
GdkPixbuf *image;
gboolean ret = 0;
gtk_init (&argc, &argv);

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

gtk_container_set_border_width (GTK_CONTAINER (window), 10);

image  = gdk_pixbuf_new_from_file ("test.gif", NULL);
if (!image)
return FALSE;
pMainWidget = gtk_image_new_from_pixbuf(image);

gtk_widget_show (pMainWidget);

gtk_container_add (GTK_CONTAINER (window), pMainWidget);

gtk_widget_show (window);

gtk_main ();

return 0;
}


Initially, execution failed at

ret=directfb->GetInputDevice(directfb, DIDID_KEYBOARD, &keyboard) ;

in gtk+-2.10.14/gdk/directfb/gdkdisplay-directfb.c

I commented out some line related to keyboard because WE ARE NOT USING ANY
INPUT DEVICE.

The commented lines in file gdkdisplay-directfb.c are below:

//ret=directfb->GetInputDevice(directfb, DIDID_KEYBOARD, &keyboard)

//_gdk_display->keyboard=keyboard;

//_gdk_directfb_keyboard_init ();

//_gdk_input_init ();


I again cross compiled and executed the same GTK example mentioned above.
This time the code executed and got stuck in a function.

I had put some debug messages in GTK library and below is the log of debug
messages



# pixmap_mips
[gtkmain.c:934]
[gtkmain.c:699]
[gtkmain.c:702]
[gtkmain.c:721]
[gtkmain.c:898]
[gdk.c:273]
[gdk.c:277]

 ===|  DirectFB 1.0.0  |===
  (c) 2001-2007  The DirectFB Organization (directfb.org)
  (c) 2000-2004  Convergence (integrated media) GmbH


(*) DirectFB/Core: Single Application  Core. (2007-12-07 07:12) [ DEBUG ]
(*) before  direct_modules_explore_directory
(*) after  direct_modules_explore_directory
(*) inside  direct_list_foreach
(*) inside  direct_list_foreach2
(*) inside  direct_list_foreach
(*) inside  direct_list_foreach2
(*) Going to ABHISHEK initialize 'clipboard' core...
(*) Going to ABHISHEK initialize 'colorhash' core...
(*) Going to ABHISHEK initialize 'system' core...
(*) Going to ABHISHEK initialize 'input' core...
(*) Going to ABHISHEK initialize 'gfxcard' core...
driver_init_driver1
(*)
dfb_fbdev->shared->fix.mmio_start = -1342177280 length in system_map_mmio  =
190, length passes as argument = 190
(*)
dfb_fbdev->shared->page_mask = 4095 addr = 731037696(*)
dfb_fbdev->shared->fix.mmio_start = -1342177280 length in system_map_mmio  =
190, length passes as argument = 190
(*)
dfb_fbdev->shared->page_mask = 4095 addr = 731938816bdrv->mmio_base=
2b92c000 bdrv->mmio_base1 = 2ba08000
(*) DirectFB/Graphics: Broadcom Software Rasterizer 0.0 (www.samsung.com)
(*) Going to ABHISHEK initialize 'screens' core...

Inside Screen InitScreen COMPLETED
(*) Going to ABHISHEK initialize 'layers' core...
(*) Going to ABHISHEK initialize 'wm' core...
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
[gdkdisplay-directfb:99]
[gdkdisplay-directfb:107]
(!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument
(!) DirectFB/FBDev: Panning display failed!
--> Invalid argument
[gdkdisplay-directfb:116]
[gdkdisplay-directfb:125]
[gdkdisplay-directfb:127]
[gdkdisplay-directfb:129]
[gdkdisplay-directfb:131]
[gdkdisplay-directfb:133]
[gdkdisplay-directfb:135]
[gdkdisplay-directfb:138]
[gdkdisplay-directfb:140]
[gdkdisplay-directfb:142]
[gdkdisplay-directfb:144]
[gdkdisplay-directfb:146]
(*) Direct/Thread: Running 'EventBufferFeed' (MESSAGING, 218)...
[gdkdisplay-directfb:148]
[gdkdisplay-directfb:150]
[gdkdisplay-directfb:153]
[gdk.c:279]
[gdk.c:288]
[gdk.c:292]
[gtkmain.c:943]
[sar]in pixmap.c

(pixmap_mips:216): Gdk-DirectFB-WARNING **: gdk_window_set_keep_above() not
implemented.


(pixmap_mips:216): Gdk-DirectFB-WARNING **: gdk_window_set_keep_below() not
implemented.

[gtkwidget.c:2217][gtkwidget.c:2219][gtkwidget.c:][gtkwidget.c:2225][
gtkwidget.c:2229][gtkwidget.c:2232][gtkwidget.c:2234][gtkwidget.c
:2236][gtkwidget.]
[sar]g_main_loop_new returns loop=4339560[gtkmain.c:1146]
[gtkmain.c:1147]
[gtkmain.c:1149]
[gtkmain.c:1164]
[sar]g_main_loop_is_running[gtkmain.c:1167]
[sar][gtkmain.c:before g_main_loop_run (loop = 5d);4339560]
(!) [  216:0.000] --> Caught signal 2 (sent by the kernel) <--


It is not able to exit from g_main_loop_run (loop) function which is called
from gtk_main() function.

I am stuck here and not able to proceed further.

somebody plz help me on