GNOME.org
 

Gtkmm-forge Digest, Vol 34, Issue 15

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 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   2. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   3. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   4. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   5. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))
   6. [Bug 573482] libglademm: thoughts about signal	autoconnecting
      (gtkmm (bugzilla.gnome.org))


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

Message: 1
Date: Tue, 17 Mar 2009 14:26:59 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317142659 C2CC823F518 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #33 from Stas Sergeev  2009-03-17 14:27 UTC -------
> About example.patch, aren't these in the wrong order? Doesn't the signal
> handler need to be declared _before_ you use it?
That doesn't really matter - the class members are
allowed to access the other members of the same class
that were declared later. The patch is, of course, tested. :)

> Also, I would really really like to avoid use of macros at least in the public
> API. Can you try that, please?
Its not an issue to remove the macros, its just
a question of syntax. I wanted to hide the fact
that I am building the map. If you remove macros,
then the user will have to define the function
__init_slots() and call register_slot() from it
for every slot. If that's what the cpp can do,
then I thought why not. What's so bad about the
macros? wxwidgets does everything with macros.
Are there any other ways to build the map automatically?
I am not aware of them, so do you really hate
the macros so much so to force the user to fill
the map himself? The macros are not mandatory
here, but I find them convenient. Maybe, it is
possible to document both ways, so that people
may use the macros, or may not?

> And I unfortunately still don't find this much nicer than connecting manually.
> It only saves me from having to remember the names of the signals that I am
> connecting to, though
You first need to remember all the widgets you
need to connect. Recall their names. Their type.
Get those widgets by names. Recall their respective
handlers. Then connect.
You write the wrapper by doing so. Wrapper needs
to be recompiled when the form changes. You change
the widget name in the GUI builder - adjust the
wrapper + recompile. You add another button that
can use the already existing handler - you nevertheless
adjust the wrapper + recompile.
I agree to recompile when I change or add the
handler itself - this is unavoidable and obviously
justified. But I don't want to have the wrapper,
neither do I want to write it, nor to recompile
every time I am changing the form.
I want only a single call that loads the GUI from
XML and makes it alive. A single call, not more. :)
QT uses wrappers too, but at least, they are
generated there. Here, the wrappers are hand-written.

I also have that mail in my mail-box now:
---
Nice feature. The only thing why I'm not currently using gtkmm anymore
is because of
the lack of autoconnecting signals. I'm using python bindings instead.
Please, make
this feature mainstream for the c++ bindings.
---

Hope that clarifies. :)


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



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

Message: 2
Date: Tue, 17 Mar 2009 14:43:16 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317144316 6BC4C23F52F 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #34 from Stas Sergeev  2009-03-17 14:43 UTC -------
> Note to self: If I implement the signal registration system that would be
> needed to make this work, I would want that registration to only happen just
> before it is actually used, to avoid unnecessary slowdowns during normal gtkmm
> initialization.
I'd like to discuss _my_ implementation a bit. :)
In my implementation, the dynamic registration of
slots happens, not of the signals. And yes, it is
delayed up to the first use.
I am not asking you to implement the dynamic
registration of anything - I don't actually even
understand what you propose. :) My system is almost
complete - unless you can point a serious problems
with it, the only thing remained, is to generate
the connect() method for every widget.
This is a very easy task for gmmproc. I propose
to add the dedicated section to which the
_WRAP_SIGNAL() will emit the code like in the change
to button.ccg in my patch. At the second stage, that
section will go into a .cc file as the implementation
of connect(), and into a .h file as the prototype of
connect(). And thats it - no more changes are required
at all, the task is complete.
What do you think?


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



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

Message: 3
Date: Tue, 17 Mar 2009 14:53:24 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317145324 4711123F52F 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #35 from Stas Sergeev  2009-03-17 14:53 UTC -------
I mean, I can even do such a change to gmmproc
myself, it should be very simple. Unfortunately,
the gmmproc is a bit complex and undocumented,
and is written on the languages I haven't used
much. So I hope you can do that in a reasonable
time frame. But if not - let me know about that.
The change will be very simple, but I am afraid
I'll spend too much time learning how gmmproc
really works, so that's why I am reluctant to
start.


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



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

Message: 4
Date: Tue, 17 Mar 2009 14:59:31 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317145931 5162323F52F 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #36 from Murray Cumming  2009-03-17 14:59 UTC -------
(In reply to comment #33)
> > Also, I would really really like to avoid use of macros at least in the public
> > API. Can you try that, please?
> Its not an issue to remove the macros, its just
> a question of syntax. I wanted to hide the fact
> that I am building the map. If you remove macros,
> then the user will have to define the function
> __init_slots() and call register_slot() from it
> for every slot.

I think I'd like to force the user to implement the __init_slots() method
overload, or a constructor, if that's possible. That use of a macro obscures
things too much. Then the other macro will not look too bad. The macro should
have a GTKMM_ prefix, by the way.

However, I would like to see an example/test that:
1. Uses both the macro and the method, so it's easier to see what the macro
does.
2. Uses a non-global signal handler, such as sigc::mem_fun(*this,
ExampleWindow::on_test_button_clicked). That would probably have to use
get_widget_derived(). If this only works with global non-class functions then
it's not very useful.


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



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

Message: 5
Date: Tue, 17 Mar 2009 15:01:44 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317150144 1D80823F52F 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #37 from Murray Cumming  2009-03-17 15:02 UTC -------
If we decide that the API works and is useful then I will do the gmmproc work.
We are not quite there yet.


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



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

Message: 6
Date: Tue, 17 Mar 2009 20:00:41 +0000 (UTC)
From: "gtkmm (bugzilla.gnome.org)"
	<bugzilla-daemon bugzilla gnome org>
Subject: [gtkmm bugzilla] [Bug 573482] libglademm: thoughts about
	signal	autoconnecting
To: gtkmm-forge lists sourceforge net
Message-ID: <20090317200041 8006523F536 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=573482

  gtkmm | general | Ver: unspecified




------- Comment #38 from Stas Sergeev  2009-03-17 20:01 UTC -------
> I think I'd like to force the user to implement the __init_slots() method
> overload
Uhm. So you really hate macros... :(

> or a constructor, if that's possible.
I decided against using the constructor, because
not using it gives:
1. Syntactical sugar: you don't have to pass the
class name into GTKBUILDER_DECLARE_SLOTS macro.
I'd like to avoid passing it to the GTKBUILDER_SLOT
macro too, but for the completely stupid reasons
I can't. The completely stupid reasons are requiring
me to qualify the class name when I take the pointer
to the class member _inside that class declaration_!
I find that silly. For example, qualifying the
member declaration with the class name is not
even allowed. So why do they require that when I
take the pointer?
2. Compile-time check. It is easy for the user to
forget to put the necessary macro, especially if
he doesn't know what this macro do. :) I wanted
a compile-time error for that mistake (and it is
there), while with the constructor I don't see how
to impement the compile-time check, and the run-time
error is not that good.
IIRC, wxWidgets has only the link-time error for
that, and with the meaningless error message, so
my implementation is even better. :)
3. Saner documentation. Do it in a constructor,
and you will have to prohibit the user to define
the custom constructor. I don't think someone
will want to define a custom constructor for the
helper class like this, but nevertheless you will
have to mention that in the docs, while it is too
silly to mention in the docs. :)
4. Delayed allocation. Probably completely
unimportant here, but you can't do that with the
ctor.
So overall, I think having these things in the
constructor is not very flexible. It might be
better to have the dedicated function and a few
macros to support. :)

> That use of a macro obscures
> things too much. Then the other macro will not look too bad.
What do you mean? Leave one macro instead of 2?
wxWidgets has way more macros for the purpose
of declaring the event handlers. :)

> However, I would like to see an example/test that:
> 1. Uses both the macro and the method, so it's easier to see what the macro
> does.
> 2. Uses a non-global signal handler, such as sigc::mem_fun(*this,
> ExampleWindow::on_test_button_clicked).
I'll try to implement 1 tomorrow. Having more
than one slotscontainer was not supposed to
happen, but I'll try to add the support for that.
2 will simply require one more macro... :)

> If we decide that the API works and is useful then I will do the gmmproc work.
> We are not quite there yet.
As for API - do you prefer SlotsContainer or
SlotContainer name? Or anything else? I am asking
because this looks like the only glibmm change,
so it can be "stabilized" before the other bits.


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



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

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

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

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


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