[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] E CVS: apps/e devilhorns



On Mon, 3 Jul 2006 15:24:31 -0500 brian.mattern@gmail.com wrote:

> On Mon, Jul 03, 2006 at 03:15:49PM -0400, Christopher Michael wrote:
> > Carsten Haitzler (The Rasterman) wrote:
> > > On Mon,  3 Jul 2006 03:35:44 -0400 (EDT) Enlightenment CVS
> > > <noreply@fitx-00.ewr.caosity.org> babbled:
> > > 
> > > What was the reasoning for this? why would one need to pass the
> > > path to an module icon explicitly? (if you want to do your own
> > > icon in a dialog for a different dialog you can always do the
> > > dialog by hand?)
> > > 
> 
> <-- snip -->
> 
> > This was requested by Andy so that modules config dialogs could show
> > their icon in the border of their config dialogs. I think
> > consistency was his main goal and also so users can identify easily
> > what config dialog is for what module.
> > 
> > If it is a problem I can roll it back and change the modules back to
> > previous way of showing the E icon on the border of the config
> > dialog.
> > 
> > dh
> 
> 
> I *think* he meant that e already knows where the modules icon is, so
> you you shouldn't need to pass th path in. That is, it should just
> use the icon by default.

For e_config_dialog_new(), the only thing that it has to go by (if the
path is not passed in) is the E_Container, which has an E_Gadman in it.
I'm unsure if that is enough, isn't gadman going away?  I'm not seeing
any where in there that will point to where the icon is, it only seems
to be in the E_Module.  How to get there from here?

While on the same subject, I'm not so sure that a gadcon can get access
to its E_Module if all it has is the E_Gadcon or E_Gadcon_Client, or
E_Gadcon_Client_Class.  This makes it hard to get access to its own
icon in gadcon callbacks that only get one of those gadcon structs.  I
suggest that the E_Gadcon structs have the relevant E_Module stored in
them.

On the other hand, I'm not sure of all the gory internal details of the
module implementation that is hidden from the average module writer.
All I just said could be complete bollocks.

Attachment: signature.asc
Description: PGP signature