Gtkmm-forge Digest, Vol 8, Issue 13



Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-owner lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 396958] New: Glib::signal_idle().connect()	not
      thread-safe (glibmm (bugzilla.gnome.org))
   2. [Bug 396963] New: Add	Glib::signal_idle().connect_once()
      (glibmm (bugzilla.gnome.org))
   3. [Bug 396399] New: PrintOperation class has	problems on Mac OS
      X (gtkmm (bugzilla.gnome.org))
   4. [Bug 397167] New: build failure: error: expected	initializer
      before '&' token (glibmm (bugzilla.gnome.org))
   5. [Bug 390978] Glib::Module does not report errors	correctly
      (glibmm (bugzilla.gnome.org))
   6. [Bug 396399] PrintOperation class has problems on	Mac OS X
      (gtkmm (bugzilla.gnome.org))
   7. [Bug 396399] PrintOperation class has problems on	Mac OS X
      (gtkmm (bugzilla.gnome.org))


----------------------------------------------------------------------

Message: 1
Date: Mon, 15 Jan 2007 18:01:26 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396958] New:
	Glib::signal_idle().connect()	not thread-safe
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-396958-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=396958

  glibmm | main loop | Ver: 2.13.x

           Summary: Glib::signal_idle().connect() not thread-safe
           Product: glibmm
           Version: 2.13.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: main loop
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: daniel kitta gmail com
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Connecting to Glib::signal_idle() or one of the other special signal sources in
glibmm (timeout, io, etc) is not thread-safe, as memory visibility rules aren't
observed.

Details as discussed on the gtkmm mailing list:

Now to the bad news.  Glib::signal_idle().connect() returns a
sigc::connection object.

connection::connection(slot_base& sl)
: slot_(&sl)
{
  slot_->add_destroy_notify_callback(this, &notify);
}

connection::~connection()
{
  if (slot_)
    slot_->remove_destroy_notify_callback(this);
}

Doomed, I'd say.  At least the call to remove_destroy_notify_callback()
after the GSource mutex has been unlocked is unavoidable with the
current API.  Maybe we'll be able to play some tricks and put something
entirely different into the sigc::connection object.  A special-purpose
slot which holds a connection ID or something, and goes through the
GMainLoop/GSource interface to destroy the callback slot.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 2
Date: Mon, 15 Jan 2007 18:15:43 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396963] New: Add
	Glib::signal_idle().connect_once()
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-396963-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=396963

  glibmm | main loop | Ver: 2.13.x

           Summary: Add Glib::signal_idle().connect_once()
           Product: glibmm
           Version: 2.13.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Keywords: API
          Severity: enhancement
          Priority: Normal
         Component: main loop
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: daniel kitta gmail com
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


New API proposal:

Add a connect_once() method to the idle and timeout signals in glibmm which
takes a sigc::slot<void> and doesn't return a sigc::connection object.

This new API would simplify a common use case of these signals.  Currently, if
one connects a method not defined in one's own source code to the idle signal,
it is necessary to either write a wrapper function or use sigc::bind_return().

Beyond the simplification, this new API call would ensure that the
thread-safety problem of bug #396958 simply cannot occur, since the
complexities of returning a sigc::connection are avoided.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 3
Date: Sun, 14 Jan 2007 11:37:11 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396399] New: PrintOperation class has
	problems on Mac OS X
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-396399-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=396399

  gtkmm | general | Ver: 2.10.x

           Summary: PrintOperation class has problems on Mac OS X
           Product: gtkmm
           Version: 2.10.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: Bernhard Sonderegger cui unige ch
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Steps to reproduce:
1. Make an application that makes use of the PrintOperation class for printing
2. Do not specify any "gtk-print-backends" or "gtk-print-preview-command"
manually
3. Try to print from the application or try to use print preview

When attempting to print, the application crashes with the following message:
dyld: lazy symbol binding failed: Symbol not found: _httpGetFd
  Referenced from: 
/usr/local/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so
  Expected in: flat namespace

When attempting to preview no preview is shown and a message is displayed in
the consle:

"Error launching preview. Failed to execute child process "evince" (No 
such file or directory)"

Stack trace:
Sorry, not my mac -> no trace

Other information:
creating a .gtkrc-2.0 containing the following line resolves the crash when
trying to print put reduces the print interface to lpr functionality:

       gtk-print-backends = "lpr"

adding the following to the same file and wrapping adobe acrobat in a script
called acroscript allows preview to work (the script is necessary since
accessing the native OS X acrobat reader executable from the command line is
not trivial and PrintOperation requires thet the called application delete the
temporary pdf).

       gtk-print-preview-command = "acroscript %f"

Evince is not installed on the system, only gtkmm and libglademm with their
dependancies. Therefore installation of evince just to get preview working
means a lot of overhead.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 4
Date: Tue, 16 Jan 2007 08:22:33 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 397167] New: build failure: error:
	expected	initializer before '&' token
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-397167-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=397167

  glibmm | build | Ver: unspecified

           Summary: build failure: error: expected initializer before '&'
                    token
           Product: glibmm
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: build
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: cskeogh bigpond net au
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: 2.17/2.18
   GNOME milestone: Unspecified


gcc version 4.1.2 20070106 (prerelease) (Ubuntu 4.1.1-21ubuntu7)
--------------------------------


make  
make  all-recursive
make[1]: Entering directory `/home/oxyde/cvs/gnome2/glibmm'
Making all in tools
make[2]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/tools'
Making all in m4
make[3]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/tools/m4'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/tools/m4'
Making all in pm
make[3]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/tools/pm'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/tools/pm'
Making all in extra_defs_gen
make[3]: Entering directory
`/home/oxyde/cvs/gnome2/glibmm/tools/extra_defs_gen'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/tools/extra_defs_gen'
make[3]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/tools'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/tools'
make[2]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/tools'
Making all in glib
make[2]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib'
make  all-recursive
make[3]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib'
Making all in src
make[4]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib/src'
make[4]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib/src'
Making all in glibmm
make[4]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm'
Making all in private
make[5]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm/private'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm/private'
make[5]: Entering directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm'
if /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-DG_LOG_DOMAIN=\"glibmm\"  -I../../glib -I../../glib
-I/opt/gnome2/include/sigc++-2.0 -I/opt/gnome2/lib64/sigc++-2.0/include
-I/opt/gnome2/include/glib-2.0 -I/opt/gnome2/lib64/glib-2.0/include -pthread
-I/opt/gnome2/include/glib-2.0 -I/opt/gnome2/lib64/glib-2.0/include 
-I/opt/gnome2/include/gnome-vfs-2.0/  -g -O0 -Wall -Wno-long-long -MT
fileutils.lo -MD -MP -MF ".deps/fileutils.Tpo" -c -o fileutils.lo fileutils.cc;
\
        then mv -f ".deps/fileutils.Tpo" ".deps/fileutils.Plo"; else rm -f
".deps/fileutils.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"glibmm\" -I../../glib -I../../glib
-I/opt/gnome2/include/sigc++-2.0 -I/opt/gnome2/lib64/sigc++-2.0/include
-I/opt/gnome2/include/glib-2.0 -I/opt/gnome2/lib64/glib-2.0/include -pthread
-I/opt/gnome2/include/glib-2.0 -I/opt/gnome2/lib64/glib-2.0/include
-I/opt/gnome2/include/gnome-vfs-2.0/ -g -O0 -Wall -Wno-long-long -MT
fileutils.lo -MD -MP -MF .deps/fileutils.Tpo -c fileutils.cc  -fPIC -DPIC -o
.libs/fileutils.o
make[5]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm'
make[4]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib/glibmm'
make[3]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib'
make[2]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm/glib'
make[1]: Leaving directory `/home/oxyde/cvs/gnome2/glibmm'
../../glib/glibmm/fileutils.h:437: error: expected initializer before '&' token
fileutils.cc:136: error: expected initializer before '&' token
make[5]: *** [fileutils.lo] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 5
Date: Tue, 16 Jan 2007 16:55:07 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 390978] Glib::Module does not report
	errors	correctly
To: gtkmm-forge lists sourceforge net
Message-ID: <20070116165507 31D606C4125 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=390978

  glibmm | general | Ver: 2.12.x


Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |murrayc murrayc com




------- Comment #1 from Murray Cumming  2007-01-16 16:53 UTC -------
So I think you are just saying that get_last_error() returns an empty string.
Could we have a simpler test case then?


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 6
Date: Tue, 16 Jan 2007 19:30:40 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396399] PrintOperation class has
	problems on	Mac OS X
To: gtkmm-forge lists sourceforge net
Message-ID: <20070116193040 3F6DA6C41B1 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=396399

  gtkmm | general | Ver: 2.10.x


Marko Anastasov changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marko marko anastasov name




------- Comment #1 from Marko Anastasov  2007-01-16 19:28 UTC -------
I believe that this is not a gtkmm, but a GTK+ issue. But, frankly, I don't
remember how previewing is supposed to work on Mac OS. Evince is supposed to be
the viewer application on Linux, and the native preview dialog is used on
Windows. Perhaps on Mac this is determined by Preview.App? Was it set, or
generally did print previewing work fine before this in other Mac applications?
It seems that here CUPS was detected and assumed to be running on Linux, which
is wrong of course.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

Message: 7
Date: Tue, 16 Jan 2007 19:50:13 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 396399] PrintOperation class has
	problems on	Mac OS X
To: gtkmm-forge lists sourceforge net
Message-ID: <20070116195013 A30496C41C5 box gnome org>
Content-Type: text/plain; charset=utf-8

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=396399

  gtkmm | general | Ver: 2.10.x





------- Comment #2 from Bernhard Sonderegger  2007-01-16 19:48 UTC -------
Marko,

You may very well be right that the problem is in GTK+ and I think you put your
finger on the problem.

Printing from native OS X applications works fine -> cups is configured
properly. But it is the mac OS X modified version of cups. Also, print preview
in native OS X applications works fine and the problem appears to be a default
setting of the preview application to evince. Doesn't mac have a native pdf
viewer which could be used? In any case, I did not find any gtkrc files
containing a "gtk-print-preview-command" line. Thus 'evince' is a default value
coming from elsewhere.

It is difficult for me to follow up on this problem since the mac which is
acting up is literally half-way around the world and my only access is to the
console. I get all the feedback from a user trying to run my programmes.
Personally I run linux on an x86 and neither printing nor previewing leads to
any problems.

Cheers,

Burnce


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email



------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

------------------------------

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 8, Issue 13
******************************************



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]