GtkSourceView build for Windows?
Does anyone know a good Windows build for GtkSourceView and its dependencies ? I've managed to find only this build: http://code.google.com/p/bpad/wiki/GtksourceviewForWindows When unpacked, it provides .a file instead of .lib format. I could link against that, but then my application crashes on startup (I was using Visual Studio 2005). I would like to see the Windows build GtkSourceView and dependencies being offered at the official http://www.gtk.org pages. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkSourceView build for Windows?
On lun, 2008-09-08 at 14:35 +0200, Miroslav Rajcic wrote: Does anyone know a good Windows build for GtkSourceView and its dependencies ? I've managed to find only this build: http://code.google.com/p/bpad/wiki/GtksourceviewForWindows When unpacked, it provides .a file instead of .lib format. I could link against that, but then my application crashes on startup (I was using Visual Studio 2005). I would like to see the Windows build GtkSourceView and dependencies being offered at the official http://www.gtk.org pages. Official gtksourceview windows binaries are available at http://ftp.gnome.org/pub/gnome/binaries/win32/gtksourceview/ and are linked from the download page of gtksourceview web site at http://projects.gnome.org/gtksourceview Ciao Paolo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
John Coppens wrote:
On Sat, 6 Sep 2008 11:58:00 -0300
John Coppens [EMAIL PROTECTED] wrote:
I couldn't find a list of valid format
descriptions. Can anyone point me in the right direction?
Adding some more info: I found an (incomplete) chunk of code on the net
that defines the row data in the GtkTargetEntry array as:
{GTK_TREE_MODEL_ROW, GTK_TARGET_SAME_APP, 0}
I put this in my program, and behold, it worked. I searched for
GTK_TREE_MODEL_ROW as a target type, but couldn't find any reference to
that... So can anyone tell me what the possible values are?
And I'm still interested in an example on how to process row data
received from a drop, into a gtk_tree_store. I promise to write a
tutorial if I can get to understand this.
John
The first argument only has to match the first argument of the source.
There is some information in this tutorial:
http://scentric.net/tutorial/sec-dnd.html#sec-dnd-selected-item-info
There is also some good information in:
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
but you have to be able to read Python.
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to make a widget with border?
I want to make a widget with a border, and the border's color and width can be changed at the run-time. How to do this? And which is the best solution? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
Thanks, Jeffrey, but:
On Mon, 08 Sep 2008 08:19:42 -0600
Jeffrey Barish [EMAIL PROTECTED] wrote:
The first argument only has to match the first argument of the source.
This does not seem to be true. If I replace
{GTK_TREE_MODEL_ROW, GTK_TARGET_SAME_APP, 0} // This works
by, eg.:
{STRING, GTK_TARGET_SAME_APP, 0}// Doesn't work
So the string _is_ interpreted somewhere (outside of my program, that is).
To be specific, the drag seems to work, but drop doesn't - no event is
generated in the second case. BTW, it's not just STRING. I tried with
several other things, like xml_node_pointer (which described what I was
doing), but that didn't work either.
There is some information in this tutorial:
http://scentric.net/tutorial/sec-dnd.html#sec-dnd-selected-item-info
I had found this tutorial, but was somewhat concerned about the '***needs
revision***' statement, and also, it uses the lowest level of interface,
using x and y coordinates. I tried some versions of this, but couldn't
get it to work. Thinking back now, the problem might have been with the
Target string.
There is also some good information in:
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
There's a C version of this Python tutorial somewhere (I've downloaded
the C code, but lost the URL). It works well, but only drops are shown,
and then only simple strings. I do commend the python guys though - I'm
tempted to switch to Python just for the better docs.
The problem I'm now stuck with is what to do with the path I receive in
data_received (the destination path). I made a simple (destination) tree,
and get 'drop possibles' like this:
- Ok
Main item-- Ok
- No
--- Ok
Subitem 1 No
--- Ok
Subitem 2 No
BUT, if I convert those paths into iters, and set some data, I'm
destroying the next existing item. Do I have to insert an item before the
path/iter? I'll try that next. It wouldn't explain why I get a 'possible'
on Main item though.
Thanks for the hints, Jeff...
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
John Coppens wrote:
Thanks, Jeffrey, but:
On Mon, 08 Sep 2008 08:19:42 -0600
Jeffrey Barish [EMAIL PROTECTED] wrote:
The first argument only has to match the first argument of the source.
This does not seem to be true. If I replace
{GTK_TREE_MODEL_ROW, GTK_TARGET_SAME_APP, 0} // This works
by, eg.:
{STRING, GTK_TARGET_SAME_APP, 0} // Doesn't work
So the string _is_ interpreted somewhere (outside of my program, that is).
To be specific, the drag seems to work, but drop doesn't - no event is
generated in the second case. BTW, it's not just STRING. I tried with
several other things, like xml_node_pointer (which described what I was
doing), but that didn't work either.
I was going to tell you that you are crazy, but when I tried putting
GTK_TREE_MODEL_ROW in my program in place of the arbitrary string that I
was using, I found that the behavior of my program changed to something
bizarre (I get too many signals). So I am forced to agree that
GTK_TREE_MODEL_ROW is interpreted somewhere. It's news to me. I have
always used an arbitrary string that matches in the source and destination
specifications.
There is some information in this tutorial:
http://scentric.net/tutorial/sec-dnd.html#sec-dnd-selected-item-info
I had found this tutorial, but was somewhat concerned about the '***needs
revision***' statement, and also, it uses the lowest level of interface,
using x and y coordinates. I tried some versions of this, but couldn't
get it to work. Thinking back now, the problem might have been with the
Target string.
There is also some good information in:
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
There's a C version of this Python tutorial somewhere (I've downloaded
the C code, but lost the URL). It works well, but only drops are shown,
and then only simple strings. I do commend the python guys though - I'm
tempted to switch to Python just for the better docs.
The problem I'm now stuck with is what to do with the path I receive in
data_received (the destination path). I made a simple (destination) tree,
and get 'drop possibles' like this:
- Ok
Main item-- Ok
- No
--- Ok
Subitem 1 No
--- Ok
Subitem 2 No
BUT, if I convert those paths into iters, and set some data, I'm
destroying the next existing item. Do I have to insert an item before the
path/iter? I'll try that next. It wouldn't explain why I get a 'possible'
on Main item though.
The PyGTK FAQ has some hints:
http://faq.pygtk.org/index.py?req=showfile=faq13.030.htp
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
On Mon, 08 Sep 2008 11:03:39 -0600 Jeffrey Barish [EMAIL PROTECTED] wrote: So the string _is_ interpreted somewhere (outside of my program, that is). To be specific, the drag seems to work, but drop doesn't - no event is generated in the second case. BTW, it's not just STRING. I tried with several other things, like xml_node_pointer (which described what I was doing), but that didn't work either. I was going to tell you that you are crazy, but when I tried putting GTK_TREE_MODEL_ROW in my program in place of the arbitrary string that I was using, I found that the behavior of my program changed to something bizarre (I get too many signals). So I am forced to agree that GTK_TREE_MODEL_ROW is interpreted somewhere. It's news to me. I have always used an arbitrary string that matches in the source and destination specifications. Thanks for that test - it does eliminate fears of other problems in my program... In my case it was simple - with anything but GTK_TREE_MODEL_ROW the drop callbacks are _not_ called at all. The question is (for me, at least): where is the list of predefined values? The problem I'm now stuck with is what to do with the path I receive in data_received (the destination path). I made a simple (destination) tree, and get 'drop possibles' like this: - Ok Main item-- Ok - No --- Ok Subitem 1 No --- Ok Subitem 2 No BUT, if I convert those paths into iters, and set some data, I'm destroying the next existing item. Do I have to insert an item before the path/iter? I'll try that next. It wouldn't explain why I get a 'possible' on Main item though. The PyGTK FAQ has some hints: http://faq.pygtk.org/index.py?req=showfile=faq13.030.htp Ok - that example doesn't use DnD, it directly pushes a row up or down, but maybe it clears up some things about the insertion. Also, as far as I can understand it, it works only for GtkListStores, not for TreeStores. Maybe I have to go back to the lower level interface (the one with the x and y coordinates). Thanks again, John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
On Mon, Sep 8, 2008 at 8:31 PM, John Coppens [EMAIL PROTECTED] wrote:
On Mon, 08 Sep 2008 11:03:39 -0600
Jeffrey Barish [EMAIL PROTECTED] wrote:
I was going to tell you that you are crazy, but when I tried putting
GTK_TREE_MODEL_ROW in my program in place of the arbitrary string that I
was using, I found that the behavior of my program changed to something
bizarre (I get too many signals). So I am forced to agree that
GTK_TREE_MODEL_ROW is interpreted somewhere. It's news to me. I have
always used an arbitrary string that matches in the source and
destination specifications.
Thanks for that test - it does eliminate fears of other problems in my
program... In my case it was simple - with anything but
GTK_TREE_MODEL_ROW the drop callbacks are _not_ called at all. The
question is (for me, at least): where is the list of predefined values?
The GTK_TREE_MODEL_ROW target string is indeed interpreted somewhere
-- right inside GtkTreeView. GtkTreeView has built-in support for
reordering a model (moving rows to another position in the same
model), which can be enabled via gtk_tree_view_set_reorderable().
This function will actually set up the tree view as a model drag
source and destination (via
gtk_tree_view_enable_model_drag_{source,dest}) and will specify a
target entry using GTK_TREE_MODEL_ROW as a target string.
Unfortunately the default implementations of the GtkTreeDragDest
interface that are in the GtkListStore and GtkTreeStore models can
only handle the GTK_TREE_MODEL_ROW target. One of the things you can
try is subclass GtkListStore or GtkTreeStore and re-implement the
GtkTreeDragDest interface. If that is not enough, I think another
thing that people tend to do is even override the default
implementation of drag and drop on the tree view widget.
This recent blog entry (and the preceding one) of Davyd may be of use:
http://davyd.livejournal.com/252082.html
I fully agree that the current implementation of drag and drop in tree
view is suboptimal, especially in terms of ease of use and
extensibility. Over the summer I started on a rewrite of this, but as
University has started again I cannot really say when this will be
finished :) But at least improvements are (finally) in the works.
regards,
-kris.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
On Mon, 8 Sep 2008 22:27:08 +0200
Kristian Rietveld [EMAIL PROTECTED] wrote:
This function will actually set up the tree view as a model drag
source and destination (via
gtk_tree_view_enable_model_drag_{source,dest}) and will specify a
target entry using GTK_TREE_MODEL_ROW as a target string.
Unfortunately the default implementations of the GtkTreeDragDest
interface that are in the GtkListStore and GtkTreeStore models can
only handle the GTK_TREE_MODEL_ROW target. One of the things you can
try is subclass GtkListStore or GtkTreeStore and re-implement the
GtkTreeDragDest interface. If that is not enough, I think another
thing that people tend to do is even override the default
implementation of drag and drop on the tree view widget.
Hello Kristian,
Yes, that is what I found out. Most implementations seem to use the lower
level interface. Is GTK_TREE_MODEL_ROW the only string that is
interpreted as special? Or does any of the frequently used ones, like
'STRING' 'TEXT', 'INTEGER', 'text/plain', also have side-effects?
This recent blog entry (and the preceding one) of Davyd may be of use:
http://davyd.livejournal.com/252082.html
Interesting, particularly the part of how to copy data into the
selection - I hadn't seen an example of that elsewhere.
I fully agree that the current implementation of drag and drop in tree
view is suboptimal, especially in terms of ease of use and
extensibility. Over the summer I started on a rewrite of this, but as
University has started again I cannot really say when this will be
finished :) But at least improvements are (finally) in the works.
Nice to see a student who takes his studies seriously! Best of luck...
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
Hi, On Mon, Sep 8, 2008 at 10:49 PM, John Coppens [EMAIL PROTECTED] wrote: Yes, that is what I found out. Most implementations seem to use the lower level interface. Is GTK_TREE_MODEL_ROW the only string that is interpreted as special? Or does any of the frequently used ones, like 'STRING' 'TEXT', 'INTEGER', 'text/plain', also have side-effects? GTK_TREE_MODEL_ROW is the only target string that gets special treatment inside the tree view, the others should not have side-effects. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GDK rendering under win32
Hello, I have been involved for some time with a project written around gtk for graphically displaying some files that are used in the manufacture of circuit boards (gerbv.sf.net). Over the last year one of our developers has added the option to use cairo rendering instead of the direct GDK rendering. What we have observed is that under various unix-like operating systems such as linux or netbsd that the cairo rendering is a good bit slower (up to 8x slower) than GDK rendering although we lose some features like transparency. However, building the same app on windows shows that the GDK rendering is much slower than the cairo rendering (as much as a factor of 3). Just to put some example numbers out there linux, gdk - 4 redraws/sec linux, cairo - 0.5 redraws/sec windows, cairo - 0.5 redraws/sec windows, gdk - 0.17 redraws/sec actually we see a small difference between linux and windows, but ballpark, the cairo rendering is similar between the two. So my question is if GDK rendering is known to be extremely slow under windows when compared to cairo or linux GDK rendering? We're seeing maybe a factor of 25 difference with comparable hardware while the cairo difference is small. I'm using the latest as of today versions of the gtk for win32 stuff (gtk+-2.14.1, glib-2.18.0, ...) Thanks -Dan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkSourceView build for Windows?
- Original Message - From: Paolo Borelli [EMAIL PROTECTED] Official gtksourceview windows binaries are available at http://ftp.gnome.org/pub/gnome/binaries/win32/gtksourceview/ and are linked from the download page of gtksourceview web site at http://projects.gnome.org/gtksourceview Ciao Paolo Thank you. I don't know how I've missed that one :) Regards, Miroslav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GObject-Introspection 0.5.0
Mikkel Kamstrup Erlandsen wrote:
2008/9/7 Paolo Bonzini [EMAIL PROTECTED]:
I'm leaning towards using the ownership terminology instead of
transfer.
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use
*/
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is
*/
} GITypeOwnership;
Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers. Maybe you could come up with something
different, especially in place of 'callee'?
It's actually commonly-used terminology, e.g. caller-save registers
vs. callee-save registers in compilers.
With all due respect I am not sure compiler-writers are the main
audience of GObject Introspection. I for one find the terminology a
bit confusing too.
What about employer and employee instead? :-)
Paolo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject Introspection included in the Softpedia Linux software database
Congratulations, GObject Introspection, one of your products, has been added to Softpedia's database of software programs for Linux. It is featured with a description text, screenshots, download links and technical details on this page: http://linux.softpedia.com/get/Desktop-Environment/Gnome/GObject-Introspection-40832.shtml The description text was created by our editors, using sources such as text from your product's homepage, information from its help system, the PAD file (if available) and the editor's own opinions on the program itself. If you feel that having your product listed on Softpedia is not a benefit for you or simply need something changed or updated, please contact us via email at [EMAIL PROTECTED] and we will work with you to fix any problem you may have found with the product's listing. -- Sincerely, The Softpedia Team --- Softpedia is a library of over 400,000 free and free-to-try software programs for Windows, Mac OS and Linux, games and gaming tools, Windows device drivers, mobile devices and IT-related articles. --- Softpedia - the encyclopedia of free software downloads http://www.softpedia.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Hi, On Mon, Sep 8, 2008 at 12:07 PM, Mike Kestner [EMAIL PROTECTED] wrote: If either attribute is unspecified, it's assumed to be false. Kind of a detail, but with the scanner setup in g-i, I think it would be good to require manual specification of ownership for all allocated types. Otherwise we can't tell what has been looked at. If you're adding introspection to a new library (or a new part of an old library), bottom line is somebody has to go through and specify all the ownerships by hand, so at least in some mode we should be able to tell whether that's been done. If a new function appears in a library, g-i should somehow notify us that ownership has to be specified. If we don't automate detecting the case where ownership hasn't been looked at by hand, surely it's going to constantly break ... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Murray Cumming wrote:
On Mon, 2008-09-08 at 10:09 -0500, Mike Kestner wrote:
On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:
Paul Pogonyshev wrote:
Johan Dahlin wrote:
[...]
I'm leaning towards using the ownership terminology instead of transfer.
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
} GITypeOwnership;
Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers. Maybe you could come up with something
different, especially in place of 'callee'?
Agreed, I'm open to suggestions.
caller/subroutine ?
In GAPI, we have two ownership attributes on list elements: owned and
elements_owned.
or nothing is owned. Yes, we have these 3 in gtkmm too. Johan's system
offers a fourth combination, list-not-owned, element-owned, so-far not
seen in the wild), but it seems fine.
True, but most importantly: it supports lists of lists.
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting - September 9th
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. things I'd like to discuss are o branching o filechooser threading issues (bug 551337) o 2.90/3.0 plan, next steps o cube.gtk.org availability o miscellaneous eventual changes will be notified on the wiki page[0]. everyone can participate, as usual. Matthias [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=9day=9year=2008hour=20min=0sec=0p1=0 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib on Symbian
Kalle Vahlman wrote :-
Wrong. Symbian does not support static data in DLL:s in all versions out
there:
Please refer to the following link for the updated latest version of the
document :-
http://developer.symbian.com/main/downloads/papers/static_data/SupportForWriteableStaticDataInDLLs.pdf
The SYMBIAN OS EKA2 emulator only allows a DLL with WSD to load into a
single process
Hence for Support for emulator WSD
Symbian OS v9.4 provides emulator WSD (EWSD library), a mechanism to allow
DLLs
with WSD to be able to load into multiple processes. The support is not
transparent to the DLL writer;
they have to wrap the WSD in a data structure and pass it to the EWSD
library.
This library maintains the relationship between the library, and its WSD
values in each process.
The DLL writer has to make emulator-conditional changes to the source code
to:
? wrap all the WSD in the DLL into a single ?wrapper? data structure
? change code to refer to the wrapper data member rather than directly
? prevent EPOCALLOWDLLDATA being declared in the emulator build
For example, consider a DLL with a function foo() that uses WSD iState as
shown:
// source for foo.cpp
int iState;
void foo()
{
if (iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
You would change as shown:
// source for foo.cpp
struct MyWSD
{
int iState;
};
void foo()
{
#ifdef _USE_EWSD_
MyWSD *MyWSDPtr = PlsMyWSD(ThisLibUid);
// Pls is an API provided by the ewsd - it fetches the ptr for this
// (process,libuid) tuple.
// You can also pass an initialisation function to Pls() to initialise the
WSD
// ? initialisation is only done the 1st time the templated function is
called
#endif
10
if (MyWSDPtr-iState == ESomeState)
{
//do something
}
else
{
//do something else
}
}
The MMP file of that DLL must not have EPOCALLOWDLLDATA for the emulator
build,
so you would make its specification conditional on use of EWSD in the MMP
file:
#ifndef _USE_EWSD_
EPOCALLOWDLLDATA
#endif
WSD in DLLs is not, and never will be, supported on EKA1 based versions of
Symbian OS. However WSD in DLLs is supported on EKA2.(versions 9.x)
Hence for the port of GLIB to work on EKA2 version of Symbian OS emulator
we had to do these changes.
Regards
Biswajeet Dash|
Symbian Software India Private Limited |
[EMAIL PROTECTED]
Behdad Esfahbod [EMAIL PROTECTED]
Sent by: Behdad Esfahbod [EMAIL PROTECTED]
09/06/2008 02:14 AM
To
sparkymat [EMAIL PROTECTED]
cc
Tor Lillqvist [EMAIL PROTECTED], [EMAIL PROTECTED], gtk+ dev
gtk-devel-list@gnome.org
Subject
Re: glib on Symbian
sparkymat wrote:
We are doing what you have mentioned above, i.e. defining name of global
variables as function calls returning a pointer.
So, this limitation is *only* for the simulator, not the actual Symbian
running on mobile hardware, right? If that's the case I believe the
simulator
should be fixed instead.
behdad
For example, in gdate.c,
static gboolean using_twodigit_years = FALSE;
would become
#if defined(__SYMBIAN32__) defined(EMULATOR)
PLS(using_twodigit_years,gdate, gboolean)
#define using_twodigit_years
(*FUNCTION_NAME(using_twodigit_years ,gdate)()
#else
static gboolean using_twodigit_years = FALSE;
#endif
where the PLS() macro will add the specified variable to the Process
Local Storage, and the define will map it to a function pointer.
This is repeated for all write-able static data (WSD).
Experience innovation in action - visit the Smartphone Show, 21-22
October 2008, Earls Court 2, London
**
Symbian Software Ltd is a company registered in England and Wales
with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London, SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify [EMAIL PROTECTED] and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
**___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
