Send Gtkmm-forge mailing list submissions to
        [EMAIL PROTECTED]

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
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

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 395572] overloading ambiguity in     printoptions.cc with
      Sun Workshop 11 CC (gtkmm (bugzilla.gnome.org))
   2. [Bug 397167] build failure: error: expected       initializer
      before '&' token (glibmm (bugzilla.gnome.org))
   3. [Bug 397167] build failure: error: expected       initializer
      before '&' token (glibmm (bugzilla.gnome.org))
   4. [Bug 364395] gtk_window_set_default_icon_name()   isn't
      available from gtkmm (gtkmm (bugzilla.gnome.org))
   5. [Bug 109966] Dispatcher does not work on win32
      (glibmm (bugzilla.gnome.org))
   6. [Bug 399216] New: New feature:    Glib::ustring::compose()
      (glibmm (bugzilla.gnome.org))
   7. [Bug 399216] New feature: Glib::ustring::compose()
      (glibmm (bugzilla.gnome.org))
   8. [Bug 399403] New: Issue with functions returning
      ArrayHandle<ustring> (glibmm (bugzilla.gnome.org))


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

Message: 1
Date: Wed, 17 Jan 2007 19:56:58 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 395572] overloading ambiguity in
        printoptions.cc with Sun Workshop 11 CC
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=395572

  gtkmm | build | Ver: 2.10.x


Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED




------- Comment #14 from Murray Cumming  2007-01-17 19:55 UTC -------
Many thanks, Marko.


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



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

Message: 2
Date: Wed, 17 Jan 2007 20:12:11 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 397167] build failure: error: expected
        initializer before '&' token
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]




------- Comment #2 from Daniel Elstner  2007-01-17 20:10 UTC -------
It should be safe to simply #undef mkstemp if necessary.  If I remember
correctly, the C standard allows most of the library functions to be actually
macros, but also requires that they still work if #undef'ined.  Well, at least
I hope that this applies to mkstemp, too.


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



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

Message: 3
Date: Thu, 18 Jan 2007 11:24:53 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 397167] build failure: error: expected
        initializer before '&' token
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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





------- Comment #3 from Craig Keogh  2007-01-18 11:23 UTC -------
- fileutils.h
------------------------------------------------------------------

/** Opens a temporary file.
 * @ingroup FileUtils
 * See the %mkstemp() documentation on most UNIX-like systems. This is a
 * portability wrapper, which simply calls %mkstemp() on systems that have
 * it, and implements it in GLib otherwise.
 * @param filename_template A string that should match the rules for
 *   %mkstemp(), i.e. end in <tt>"XXXXXX"</tt>. The <tt>X</tt> string
 *   will be modified to form the name of a file that didn't exist.
 * @return A file handle (as from open()) to the file opened for reading
 *   and writing. The file is opened in binary mode on platforms where there
 *   is a difference. The file handle should be closed with close(). In
 *   case of errors, <tt>-1</tt> is returned.
 */
int std::string& filename_templateNUN4pa;

-- fileutils.cc
----------------------------------------------------------------

int std::string& filename_templatenjCT11

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

two return values, and no (), and jumbled function names.

I see the files are generated by gtkmmproc, so my gtkmmproc must be bugged. But
I don't seem to have the program gtkmmproc on my computer.

Yes Murray, Ubuntu Feisty.


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



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

Message: 4
Date: Sat, 20 Jan 2007 09:08:56 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 364395]
        gtk_window_set_default_icon_name()      isn't available from gtkmm
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=364395

  gtkmm | general | Ver: 2.10.x


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
         OS/Version|Linux                       |All




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



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

Message: 5
Date: Sat, 20 Jan 2007 11:09:36 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 109966] Dispatcher does not work on
        win32
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=109966

  glibmm | threads | Ver: 2.4.x





------- Comment #25 from Daniel Elstner  2007-01-20 11:07 UTC -------
I accidentally found the real cause of the race condition Cedric experienced. 
It was actually a bug in my patch, not in the example.

Also, I just reworked the win32 implementation somewhat (sticking closely to
msdn) in order to make it match the Dispatcher behavior on Unix more closely. 
The code compiles fine with dummy definitions of the win32 API functions, but I
haven't tested yet whether it works at runtime.

Cedric, if (and only if) you have the time, I'd appreciate if you could try
whether current glibmm/trunk works for you on win32.  I could also send you a
patch instead if that would make matters easier for you.


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



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

Message: 6
Date: Mon, 22 Jan 2007 00:55:29 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399216] New: New feature:
        Glib::ustring::compose()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]/>
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=399216

  glibmm | strings | Ver: 2.13.x

           Summary: New feature: Glib::ustring::compose()
           Product: glibmm
           Version: 2.13.x
          Platform: Other
        OS/Version: All
            Status: NEW
          Keywords: API
          Severity: enhancement
          Priority: Normal
         Component: strings
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
         QAContact: [EMAIL PROTECTED]
     GNOME version: Unspecified
   GNOME milestone: Unspecified


glibmm should provide the functionality to compose message strings from a
format template and a list of arguments.  Substituting references in a template
string instead of simply concatenating strings is absolutely necessary to
enable proper internationalization.  The STL stream interface is unfortunately
not suitable for this purpose.

Prior art:

1. compose mini-library by Ole Laursen: http://people.iola.dk/olau/compose/
2. custom minimal implementation in regexxer:
http://svn.gnome.org/viewcvs/regexxer/trunk/src/translation.h?view=markup

Ole Laursen's implementation supports formatting values of arbitrary type by
passing the arguments to compose() through an std::wostringstream.  The minimal
variant in regexxer supports only string arguments.

I think glibmm should also offer facilities for formatted conversion to
strings, as Ole Laursen's compose library already does.  However, I'm currently
somewhat in favor of providing a separate format() API, rather than having
compose() do both.  The main new user-visible functions would then be:

static ustring ustring::compose(const char* format, const ustring& s1, ...);
template <class T1, ...> static ustring ustring::format(const T1& a1, ...);

Example usage of the proposed API:

using Glib::ustring;
const int percentage = 50;
const ustring text = ustring::compose("%1%% done",
ustring::format(percentage));

This is subject to change.  I'm going to outline my reasons for favoring the
separate API on the mailing list, so that it can be discussed before the final
decision is made.


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



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

Message: 7
Date: Mon, 22 Jan 2007 01:07:09 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399216] New feature:
        Glib::ustring::compose()
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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=399216

  glibmm | strings | Ver: 2.13.x


Daniel Elstner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gtkmm-                      |[EMAIL PROTECTED]
                   |[EMAIL PROTECTED] |
             Status|NEW                         |ASSIGNED




------- Comment #1 from Daniel Elstner  2007-01-22 01:05 UTC -------
Created an attachment (id=80848)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=80848&action=view)
Proof of concept implementation of the compose API

The attached patch is a proof-of-concept implementation of the separated
compose and format API I'm leaning towards at the moment.  The main advantage
of the separation is that the implementation is small and straightforward,
which should be clearly visible from the patch.  Applies to glibmm trunk.

The patch does not yet add the appropriate configure checks for wchar_t and
std::wstring.  The final version will need to have these checks.


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



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

Message: 8
Date: Mon, 22 Jan 2007 14:56:57 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 399403] New: Issue with functions
        returning       ArrayHandle<ustring>
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]/>
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=399403

  glibmm | general | Ver: 2.12.x

           Summary: Issue with functions returning ArrayHandle<ustring>
           Product: glibmm
           Version: 2.12.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: general
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
         QAContact: [EMAIL PROTECTED]
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
The following code:
Glib::ArrayHandle<Glib::ustring> test() {
  std::list<Glib::ustring> liste;
  liste.push_back("test1"), liste.push_back("test2"), liste.push_back("test3");
  return liste;
}

int main(int argc, char *argv[]) {
  std::list<Glib::ustring> liste=test();
  for (std::list<Glib::ustring>::const_iterator it=liste.begin();
it!=liste.end(); it++)
    std::cout << *it << " ";
  return 0;
}

leads to the following output : test1 test2 test1
instead of : test1 test2 test3

It seems that this due to the fact that the object liste in the function test
is local to the function.

Gtk::DragContext::get_targets() uses similar code and don't run correctly.

Steps to reproduce:
1.
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:


-- 
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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 8, Issue 15
******************************************
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to