Gtkmm-forge Digest, Vol 13, Issue 3

From: gtkmm-forge-request lists sourceforge net
To: gtkmm-forge lists sourceforge net
Subject: Gtkmm-forge Digest, Vol 13, Issue 3
Date: Tue, 12 Jun 2007 14:45:45 -0700
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 444755] New: some widgets do not update	dimensions after
      changes in the window (gtkmm (bugzilla.gnome.org))
   2. [Bug 444755] some widgets do not update dimensions	after
      changes in the window (gtkmm (bugzilla.gnome.org))
   3. [Bug 317406] Printable tutorial would be useful.
      (gtkmm (bugzilla.gnome.org))
   4. [Bug 445093] New: Transfer::transfer() without
      progress_callback argument does not work
      (gnomemm (bugzilla.gnome.org))
   5. [Bug 443586] Introduction to TreeView is misleading
      (gtkmm (bugzilla.gnome.org))
   6. [Bug 440888] The gtk-save stock icon was not	included in the
      Windows Gtkmm-2.10 edition (gtkmm (bugzilla.gnome.org))


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

Message: 1
Date: Wed,  6 Jun 2007 15:31:02 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 444755] New: some widgets do not update
	dimensions after changes in the window
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-444755-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=444755

  gtkmm | general | Ver: 2.10.x
           Summary: some widgets do not update dimensions after changes in
                    the window
           Product: gtkmm
           Version: 2.10.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: zoombat runbox com
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: 2.15/2.16
   GNOME milestone: Unspecified


Please describe the problem:
I have an image viewer window which has a filechooser widget embedded which is
shown on key/button press. Of course, the filechooser then takes up space (it
is not shown normally) and the other elements in the window are reduced in
size. In order to keep the image shown at the right size, I poll my Eventbox
containing an image widget for its dimensions as follows and then scale the
image accordingly:

FileChooser.is_visible() ? FileChooser.hide() : FileChooser.show();
//while(Gtk::Main::events_pending()) Gtk::Main::iteration();
ImageBox.ScaleImage(ImageScroller.get_width(),ImageScroller.get_height(),&scalefactor);

When I don't perform the iteration, the dimensions of both the filechooser and
the eventbox are not updated in time and the image is scaled to the old
dimensions. (filechooser remains 1,1 and the eventbox remains x,y, while I
would expect the filechooser to return x,b and the eventbox x,y-b)

If this is intended behaviour, disregard the bug, but I find it quite
counterintuitive that I have to first iterate to get the dimensions of widgets
updated after they have been changed.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


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=444755.



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

Message: 2
Date: Wed,  6 Jun 2007 16:14:12 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 444755] some widgets do not update
	dimensions	after changes in the window
To: gtkmm-forge lists sourceforge net
Message-ID: <20070606161412 C8CD96C429D box 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=444755

  gtkmm | general | Ver: 2.10.x

jonner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathon jongsma gmail com
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG




------- Comment #1 from jonner  2007-06-06 16:14 UTC -------
If you look at the source for gtk_widget_hide() [1], you'll notice that when
you hide a widget, it emits the 'hide' signal for that widget, and then queues
a resize of the widget.  In other words, the resize doesn't actually happen
immediately, it happens when the queued resize request is handled.  This is by
design and not a bug.  
What you most likely want to do in your application is connect to a filechooser
signal that is emitted after the resize actually takes place (perhaps the
'hide' and 'show' signals would work, you could also look into
'configure-event', which will be emitted every time the filechooser is resized,
not just hidden or shown) and then update your dimensions inside the signal
handler.
I'm going to close this bug.  If you need further help with your application,
you might try asking on gtkmm-list.

[1]
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkwidget.c?revision=18025&view=markup


-- 
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=444755.



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

Message: 3
Date: Wed,  6 Jun 2007 16:18:44 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 317406] Printable tutorial would be
	useful.
To: gtkmm-forge lists sourceforge net
Message-ID: <20070606161844 E3FB26C42BC box 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=317406

  gtkmm | reference documentation | Ver: 2.6.x

jonner changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathon jongsma gmail com
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED




------- Comment #5 from jonner  2007-06-06 16:18 UTC -------
I've committed preliminary support for this now.  The output is not perfect,
but it is now possible to generate a PDF of the tutorial by simply typing `make
pdf`.  The pdf is not yet built by default because it is not perfect and it
takes quite a long time to build.  If there are issues with the generated PDF
(e.g. lines too long, pages split at weird places, etc), we should probably
open new bugs to get those issues fixed.  Closing this bug.


-- 
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=317406.



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

Message: 4
Date: Thu,  7 Jun 2007 12:27:19 +0000 (UTC)
From: "gnomemm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 445093] New: Transfer::transfer()
	without	progress_callback argument does not work
To: gtkmm-forge lists sourceforge net
Message-ID: <bug-445093-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=445093

  gnomemm | gnome-vfsmm | Ver: 2.18
           Summary: Transfer::transfer() without progress_callback argument
                    does not work
           Product: gnomemm
           Version: 2.18
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: minor
          Priority: Normal
         Component: gnome-vfsmm
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: gall0ws tiscali it
         QAContact: gtkmm-forge lists sourceforge net
     GNOME version: 2.17/2.18
   GNOME milestone: Unspecified


Please describe the problem:
Gnome::Vfs::Transfer::transfer takes an optional argument for a progress
callback (SlotProgress). When this argument is no specified the function does
not work properly, basically it throws, always, an exception (operation
interrupted).

Steps to reproduce:
using namespace Gnome;

Vfs::init();

try {
      Vfs::Transfer::transfer(src, dest);                      
}
catch(const Vfs::exception& e) {
      g_print("%s\n", e.what().data());
}

Actual results:
It prints "Operation interrupted".

Expected results:
According to reference, it should copy "src" to "dest"

Does this happen every time?
Yes.

Other information:
Well, I wrote this (see below).
Basically the "old" transfer() is overloaded with a new transfer() :

transfer(const <string or uri> src, const <string or uri> target,
           TransferOptions options = XFER_DEFAULT,
           ErrorMode error_mode = XFER_ERROR_MODE_ABORT,
           OverwriteMode overwrite_mode = XFER_OVERWRITE_MODE_ABORT)

The "old" function now is:

transfer(const <string or uri> src, const <string or uri> target,
           TransferOptions options,
           ErrorMode error_mode,
           OverwriteMode overwrite_mode,
           const SlotProgress& progress_callback)

The arguments are mandatory (to avoid ambiguity), if you don't like this
we can "move" SlotProgress argument back...

I changed also functions with std::auto_ptr<> parameter

The patch is against gnome-vfsmm-2.18.0 but, if you want, I can edit also the
svn branch
----

Index: transfer.cc
===================================================================
--- transfer.cc (revision 1076)
+++ transfer.cc (working copy)
@@ -203,6 +203,52 @@
 }

 #ifdef GLIBMM_EXCEPTIONS_ENABLED
+void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
+      TransferOptions options,
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode)
+#else
+void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
+      TransferOptions options,
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      std::auto_ptr<Gnome::Vfs::exception>& error)
+#endif //GLIBMM_EXCEPTIONS_ENABLED
+{
+  #ifdef GLIBMM_EXCEPTIONS_ENABLED
+  return transfer( Uri::create(source_uri), Uri::create(target_uri), options,
error_mode, overwrite_mode);
+  #else
+  return transfer( Uri::create(source_uri), Uri::create(target_uri), options,
error_mode, overwrite_mode, error);
+  #endif //GLIBMM_EXCEPTIONS_ENABLED
+}
+
+#ifdef GLIBMM_EXCEPTIONS_ENABLED
+void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
+      TransferOptions options, 
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode)
+#else
+void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
+      TransferOptions options, 
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      std::auto_ptr<Gnome::Vfs::exception>& error)
+#endif //GLIBMM_EXCEPTIONS_ENABLED
+{
+  GnomeVFSResult result = gnome_vfs_xfer_uri(source_uri->gobj(),
target_uri->gobj(),
+    static_cast<GnomeVFSXferOptions>(options),
+    static_cast<GnomeVFSXferErrorMode>(error_mode),
+    static_cast<GnomeVFSXferOverwriteMode>(overwrite_mode),
+    NULL, NULL);
+    
+  #ifdef GLIBMM_EXCEPTIONS_ENABLED
+  handle_result(result);
+  #else
+  handle_result(result, error);
+  #endif //GLIBMM_EXCEPTIONS_ENABLED
+}
+
+#ifdef GLIBMM_EXCEPTIONS_ENABLED
 void remove(const Glib::ustring& source_uri,
       TransferOptions options,
       ErrorMode error_mode,
Index: transfer.h
===================================================================
--- transfer.h  (revision 1076)
+++ transfer.h  (working copy)
@@ -98,16 +98,45 @@

 #ifdef GLIBMM_EXCEPTIONS_ENABLED
 void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
+      TransferOptions options,
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      const SlotProgress& progress_callback);
+#else
+void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
+      TransferOptions options, //TODO: Does Default do anything useful?
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      const SlotProgress& progress_callback,
+      std::auto_ptr<Gnome::Vfs::exception>& error);
+#endif //GLIBMM_EXCEPTIONS_ENABLED
+      
+#ifdef GLIBMM_EXCEPTIONS_ENABLED
+void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
+      TransferOptions options,
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      const SlotProgress& progress_callback);
+#else
+void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
+      TransferOptions options, //TODO: Does Default do anything useful?
+      ErrorMode error_mode,
+      OverwriteMode overwrite_mode,
+      const SlotProgress& progress_callback,
+      std::auto_ptr<Gnome::Vfs::exception>& error);
+#endif //GLIBMM_EXCEPTIONS_ENABLED
+
+#ifdef GLIBMM_EXCEPTIONS_ENABLED
+void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
       TransferOptions options = XFER_DEFAULT, //TODO: Does Default do anything
useful?
       ErrorMode error_mode = XFER_ERROR_MODE_ABORT,
-      OverwriteMode overwrite_mode = XFER_OVERWRITE_MODE_ABORT,
-      const SlotProgress& progress_callback = SlotProgress());
+      OverwriteMode overwrite_mode = XFER_OVERWRITE_MODE_ABORT);
+
 #else
 void transfer(const Glib::ustring& source_uri, const Glib::ustring&
target_uri,
       TransferOptions options, //TODO: Does Default do anything useful?
       ErrorMode error_mode,
       OverwriteMode overwrite_mode,
-      const SlotProgress& progress_callback,
       std::auto_ptr<Gnome::Vfs::exception>& error);
 #endif //GLIBMM_EXCEPTIONS_ENABLED

@@ -115,14 +144,13 @@
 void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
       TransferOptions options = XFER_DEFAULT, //TODO: Does Default do anything
useful?
       ErrorMode error_mode = XFER_ERROR_MODE_ABORT,
-      OverwriteMode overwrite_mode = XFER_OVERWRITE_MODE_ABORT,
-      const SlotProgress& progress_callback = SlotProgress());
+      OverwriteMode overwrite_mode = XFER_OVERWRITE_MODE_ABORT);
+
 #else
 void transfer(const Glib::RefPtr<const Uri>& source_uri, const
Glib::RefPtr<const Uri>& target_uri,
       TransferOptions options, //TODO: Does Default do anything useful?
       ErrorMode error_mode,
       OverwriteMode overwrite_mode,
-      const SlotProgress& progress_callback,
       std::auto_ptr<Gnome::Vfs::exception>& error);
 #endif //GLIBMM_EXCEPTIONS_ENABLED

@@ -168,7 +196,7 @@
 void remove_list_uris(const ListHandleUris& source_uri_list,
       TransferOptions options,
       ErrorMode error_mode,
-      const SlotProgress& progress_callbacki,
+      const SlotProgress& progress_callback,
       std::auto_ptr<Gnome::Vfs::exception>& error);
 #endif //GLIBMM_EXCEPTIONS_ENABLED


-- 
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=445093.



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

Message: 5
Date: Sun, 10 Jun 2007 09:02:58 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 443586] Introduction to TreeView is
	misleading
To: gtkmm-forge lists sourceforge net
Message-ID: <20070610090258 DE2BE6C4181 box 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=443586

  gtkmm | documentation | Ver: unspecified

Murray Cumming changed:

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




------- Comment #1 from Murray Cumming  2007-06-10 09:02 UTC -------
> About 2/3 of the way down the first page of chapter 8 of the GTKmm book, where
> the TreeModel/TreeView scheme is discussed, there is a code extract of how to
> declare a TreeModelColumnRecord. This example looks as if it intends that a
> static instance of the derived class should be created.

Exactly what part of the text do you mean? I can't see anything that explicitly
suggests that it should be static.

> Also, the reference documentation for Gtk::TreeModel::ColumnRecord explicitly states

I have changed the text to:
"
 * Thus you may use a statically allocated
 * TreeModel::ColumnRecord (as long as you make sure it's instantiated after
 * Gtk::Main), even when creating multiple models from it. However, it is very
difficult to 
 * specify the sequence of allocation of static objects, so this should
probably be avoided.
"


-- 
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=443586.



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

Message: 6
Date: Sun, 10 Jun 2007 09:04:14 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 440888] The gtk-save stock icon was not
	included in the Windows Gtkmm-2.10 edition
To: gtkmm-forge lists sourceforge net
Message-ID: <20070610090414 26A386C4180 box 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=440888

  gtkmm | general | Ver: 2.10.x

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         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=440888.



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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

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

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


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