Re: gtkmm-list Digest, Vol 159, Issue 8

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtkmm-list Digest, Vol 159, Issue 8

deepak.bhujangachar
Hi All,

I got solution to the last problem. I am sorry asking such a vague  
questions. I am learner in gtkmm please help. Next time I will be more  
specific about my problems. It will not happen again.

Thanks
Deepak

Quoting [hidden email]:

> Send gtkmm-list mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gtkmm-list digest..."
>
>
> Today's Topics:
>
>    1. Re: Accessing combo box text (Murray Cumming)
>    2. Re: Returning sigc::signal by value from a const method?
>       (Murray Cumming)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Jul 2017 14:18:38 +0200
> From: Murray Cumming <[hidden email]>
> To: Daniel Boles <[hidden email]>, gtkmm-list
> <[hidden email]>
> Subject: Re: Accessing combo box text
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sat, 2017-07-22 at 12:23 +0100, Daniel Boles wrote:
>>
>> On 22 July 2017 at 12:07, <[hidden email]>
>> wrote:
>> > Hi All,
>> >
>> > I am getting message like this after stop debugging. "gtkmm-
>> > CRITICAL **: gtkmm: object `Product_Combo' not found in GtkBuilder
>> > file." Please help.
>> >
>> > Thanks
>> > Deepak
>>
>> Well? Is it in the ui file? Despite your many messages indicating
>> that you think people here are psychic, they are not.
>>
>> I mean, look at what you've asked. What are we meant to do with that?
>> Psychically tell you what is wrong with this mysterious .ui file you
>> haven't shown us?
>>
>> Again, please spend more time thinking about how to ask usable
>> questions. You can't just keep posting here saying 'I tried this, but
>> it doesn't work. What is wrong' and no more info that that. It
>> doesn't provide any fuel for discussion, and frankly it's starting to
>> feel like spam.
>
> Daniel, please be more patient if you choose to respond. This person is
> asking for help. Your first two sentences would have been enough.
>
> If you also want to teach him how to ask, please be nicer about it.
>
>
> --
> Murray Cumming
> [hidden email]
> www.murrayc.com
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 24 Jul 2017 14:20:20 +0200
> From: Murray Cumming <[hidden email]>
> To: Daniel Boles <[hidden email]>, gtkmm-list
> <[hidden email]>
> Subject: Re: Returning sigc::signal by value from a const method?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sat, 2017-07-22 at 10:58 +0100, Daniel Boles wrote:
>> As an aside, since realising that providing any form of full access
>> to a signal gives external users the ability to emit() it, clear()
>> it, etc. - I am considering moving to a model whereby I only expose
>> signals via a method like this:
>>
>> sigc::connection signal_whatever_connect(signal_whatever_type slot);
>>
>> This involves quite a bit of boilerplate, albeit not all that much
>> worse than what we have to write to implement a (pointless) by-
>> reference or -value getter anyway.
>>
>>
>> However, it got me wondering. Has anyone ever come up with a better
>> way to only allow users to connect() to signals and nothing more, or
>> at least a way to reduce the required boilerplate of my proposed
>> mechanism somehow?
>>
>> I did find an old thread where IIRC Murray talked about how he would
>> like to see access control on signals, FWIW! That may have changed in
>> the meantime, whether through opinion or just practicality.
>>
>> I guess it could be done, but with smoe huge API changes; e.g. I
>> imagine we could return a base class that does not have the modifying
>> methods from our own objects, while using a derived class that does
>> provide them internally.
>>
>>
>> At the end of the day, the real question is whether the work of
>> providing access control would be justifiably better than just
>> requiring users to encapsulate signals for themselves; I suspect the
>> answer might be no. Still interested in any thoughts.
>
> I'm not aware of any efforts to make this easier. It does bother me
> too.
>
> --
> Murray Cumming
> [hidden email]
> www.murrayc.com
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gtkmm-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>
> ------------------------------
>
> End of gtkmm-list Digest, Vol 159, Issue 8
> ******************************************



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Loading...