GNOME.org
 

Gtkmm-forge Digest, Vol 27, Issue 19

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 549525] New: gtkmm/glibmm MSVC builds need	not require
      MFC (gtkmm (bugzilla.gnome.org))
   2. [Bug 549525] gtkmm/glibmm MSVC builds need not	require MFC
      (gtkmm (bugzilla.gnome.org))
   3. [Bug 547901] Implementing unwrapped copy functions	for
      Glib::NodeTree (glibmm (bugzilla.gnome.org))
   4. [Bug 547889] Implementing C++ version of GNode	test case for
      Glib:NodeTree (glibmm (bugzilla.gnome.org))
   5. [Bug 549343] ustring.cc including config.h assumes	gnu tool
      build (glibmm (bugzilla.gnome.org))
   6. [Bug 547901] Implementing unwrapped copy functions	for
      Glib::NodeTree (glibmm (bugzilla.gnome.org))
   7. [Bug 547901] Implementing unwrapped copy functions	for
      Glib::NodeTree (glibmm (bugzilla.gnome.org))


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

Message: 1
Date: Wed, 27 Aug 2008 00:39:45 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 549525] New: gtkmm/glibmm MSVC builds
	need	not require MFC
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-549525-5595 http bugzilla gnome org/>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=549525

  gtkmm | build | Ver: 2.13.x
           Summary: gtkmm/glibmm MSVC builds need not require MFC
           Product: gtkmm
           Version: 2.13.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: build
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: kovacsp3 comcast net
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
Armin,

I'm opening this bug for completeness sake since the MFC header problem was
discussed tangentially on bug #549343.  

All .rc.in files in the gtkmm/glibmm projects should be patched:

a) to remove the #include <resource.h> header and
b) to replace the #include <afxres.h> header with #include <windows.h>

The existing headers assume the installation of MFC (MS foundation classes) and
the newer "Express" edition environments from Microsoft do not include MFC,
e.g. Microsoft Visual C++ 2008 Express.  These patches should enable building
on more MS platforms.  I suggest thorough testing, of course.

The affected files: for gtkmm:

../atkmm/atkmm.rc.in
../gdkmm/gdkmm.rc.in
../pangomm/pangomm.rc.in
../gtkmm/gtkmm.rc.in and

for glibmm:

../glibmm/glibmm.rc.in

Phil

Steps to reproduce:
1. Import project into MS Visual C++ 2008 Express
2. 
3. 


Actual results:
Unable to locate resource.h
Unable to locate afxres.h

Expected results:


Does this happen every time?
yes

Other information:


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=549525.



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

Message: 2
Date: Wed, 27 Aug 2008 01:13:55 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 549525] gtkmm/glibmm MSVC builds need
	not	require MFC
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827011355 F2E7323F517 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=549525

  gtkmm | build | Ver: 2.13.x




------- Comment #1 from Philip Kovacs  2008-08-27 01:13 UTC -------
Similarly for cairomm!

Phil


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=549525.



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

Message: 3
Date: Wed, 27 Aug 2008 09:24:48 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 547901] Implementing unwrapped copy
	functions	for Glib::NodeTree
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827092448 42C1D23F52E label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=547901

  glibmm | build | Ver: 2.17.x

Szil?rd Pfeiffer changed:

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




------- Comment #8 from Szil?rd Pfeiffer  2008-08-27 09:24 UTC -------
(In reply to comment #7)
> 
> In general, I think that any copy constructor (not all constructors) should
> have a corresponding operator=() because it's not always easy to know when one
> or the other will be used, so they should both exist, and should both do the
> same thing. I have added that.

In general, I really agree with you, but it is a little bit special case.

In this case there is a difference between the copy constructor and the
operator= in my mind. The copy constructor creates a brand new NodeTree object
which is a root item, so it has neither parent nor any siblings.

In case of operator= the object in question may be in a tree, so it may have
parent and siblings. If we want to retain the original position of the object
in the tree we must not unlink it (as it happens in your implementation).

The another problem with the implementation of the operator= is the fact that
it does not copy the data as the copy constructor does.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=547901.



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

Message: 4
Date: Wed, 27 Aug 2008 09:24:48 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 547889] Implementing C++ version of
	GNode	test case for Glib:NodeTree
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827092448 AE10023F58D label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=547889

  glibmm | tests | Ver: 2.17.x

Bug 547889 depends on bug 547901, which changed state.

Bug 547901 Summary: Implementing unwrapped copy functions for Glib::NodeTree
http://bugzilla.gnome.org/show_bug.cgi?id=547901

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |



-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=547889.



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

Message: 5
Date: Wed, 27 Aug 2008 10:00:59 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 549343] ustring.cc including config.h
	assumes	gnu tool build
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827100059 75EEC23F536 label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=549343

  glibmm | build | Ver: 2.16.x

Armin Burgmeier changed:

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




------- Comment #8 from Armin Burgmeier  2008-08-27 10:00 UTC -------
I committed the #ifdef HAVE_CONFIG_H ... #endif pair around #include
<config.h>.

Thanks again for the resource thing. I will change the resource files
accordingly in the relevant *mm projects.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=549343.



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

Message: 6
Date: Wed, 27 Aug 2008 10:43:09 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 547901] Implementing unwrapped copy
	functions	for Glib::NodeTree
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827104309 6FA5023F52E label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=547901

  glibmm | build | Ver: 2.17.x




------- Comment #9 from Murray Cumming  2008-08-27 10:43 UTC -------
(In reply to comment #8)
> In this case there is a difference between the copy constructor and the
> operator= in my mind. The copy constructor creates a brand new NodeTree object
> which is a root item, so it has neither parent nor any siblings.
> 
> In case of operator= the object in question may be in a tree, so it may have
> parent and siblings. If we want to retain the original position of the object
> in the tree we must not unlink it (as it happens in your implementation).

That's weird. I guess we need to not affect the other tree, while creating a
new one.

> The another problem with the implementation of the operator= is the fact that
> it does not copy the data as the copy constructor does.

Oops.

Could you patch it to do that?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=547901.



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

Message: 7
Date: Wed, 27 Aug 2008 11:46:28 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 547901] Implementing unwrapped copy
	functions	for Glib::NodeTree
To: gtkmm-forge lists sourceforge net
Message-ID: <20080827114628 CFBBE23F53B label gnome org>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=547901

  glibmm | build | Ver: 2.17.x




------- Comment #10 from Szil?rd Pfeiffer  2008-08-27 11:46 UTC -------
(In reply to comment #9)
> (In reply to comment #8)
> > In this case there is a difference between the copy constructor and the
> > operator= in my mind. The copy constructor creates a brand new NodeTree object
> > which is a root item, so it has neither parent nor any siblings.
> > 
> > In case of operator= the object in question may be in a tree, so it may have
> > parent and siblings. If we want to retain the original position of the object
> > in the tree we must not unlink it (as it happens in your implementation).
> 
> That's weird. I guess we need to not affect the other tree, while creating a
> new one.

I do not understand what kind of "other tree" you have mentioned. The problem
is that the clear function what you have created from the destructor unlinks
the node (if it is not the root) which the operator= function belongs to.

> 
> > The another problem with the implementation of the operator= is the fact that
> > it does not copy the data as the copy constructor does.
> 
> Oops.
> 
> Could you patch it to do that?
> 
Yes, I could.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=547901.



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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

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


End of Gtkmm-forge Digest, Vol 27, Issue 19
*******************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]