Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-16-gfd7b117
On Wed, 30 Jan 2013 at 7:50:02 +0100, Rodolfo García Peñas (kix) wrote: > > I don't know what to do. We can use the idea of set the textbox as > non editable and use only the "Browse..." button to set it, but I am > not sure about it. Apart from fixing real problems, I think you should do nothing about making it non editable or selecting things automatically and things like that. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re : Re: [Patch 0/2] Unify codepath for parsing generated and external menus
- Carlos R. Mafra a écrit :
> On Sun, 27 Jan 2013 at 18:24:08 +0100, Andreas Bierfert wrote:
> >
> > This way using an external menu file generated via 'wmmenugen > file'
> > will actually do the same as running wmmenugen as command for the generated
> > menu (which currently just gives an empty menu for me).
>
> Can you please be a bit more verbose about this? How does your
> WMRootMenu look like when you use the first option ('wmmenugen > file')
> and how are you using the second option?
>
> I mean, if you can copy & paste the relevant parts of your WMRootMenu
> in these two cases that would make things easier to understand.
>
> I'm also explicitly Cc'ing Christophe Curis in the hope that he
> can share his thoughts about this :-)
Hi Carlos,
Sorry for the late answer...
I have a little worry about the 2nd patch, because as-is it looks like it makes
the assumption that all the command-generated menus are using the "pl" coding,
which may not be the case every time (and was probably not so far), so we may
break compatibility.
Unfortunately, handling both cases for pipes is not easy (it is not possible to
try-and-restart)... I had some hopes to improve things on the subject (trying
to keep only one format) but have lacked the time lately.
Regards,
Christophe.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-16-gfd7b117
On Wed, 30 Jan 2013, Carlos R. Mafra wrote: On Wed, 30 Jan 2013 at 7:50:02 +0100, Rodolfo García Peñas (kix) wrote: I don't know what to do. We can use the idea of set the textbox as non editable and use only the "Browse..." button to set it, but I am not sure about it. Apart from fixing real problems, I think you should do nothing about making it non editable or selecting things automatically and things like that. I agree that if you could make it work just like before the cleanup patches it would be enough. If you want to improve on that, checking if the text field has changed should also be possible by either observing appropriate notifications or registering your handler function as a delegate to the text field, but I don't know the details about this. Only looked at wtextfield.c briefly but it seems to contain the necessary mechanism to get notifications about changes. Regards, BALATON Zoltan
Re: Re : Re: [Patch 0/2] Unify codepath for parsing generated and external menus
On Wed, 30 Jan 2013 at 11:45:21 +0100, Christophe wrote:
>
> - Carlos R. Mafra a écrit :
> > On Sun, 27 Jan 2013 at 18:24:08 +0100, Andreas Bierfert wrote:
> > >
> > > This way using an external menu file generated via 'wmmenugen > file'
> > > will actually do the same as running wmmenugen as command for the
> > > generated
> > > menu (which currently just gives an empty menu for me).
> >
> > Can you please be a bit more verbose about this? How does your
> > WMRootMenu look like when you use the first option ('wmmenugen > file')
> > and how are you using the second option?
> >
> > I mean, if you can copy & paste the relevant parts of your WMRootMenu
> > in these two cases that would make things easier to understand.
> >
> > I'm also explicitly Cc'ing Christophe Curis in the hope that he
> > can share his thoughts about this :-)
>
> Hi Carlos,
>
> Sorry for the late answer...
Don't worry!
> I have a little worry about the 2nd patch, because as-is it looks like
> it makes the assumption that all the command-generated menus are using
> the "pl" coding, which may not be the case every time (and was probably
> not so far), so we may break compatibility.
Good point. So the pipe menu would not handle the menu in text format after
this patch? I'm afraid we can't do that.
It would be great to add the functionality of proplist generated menus,
but we can't lose the plain text along the way.
Perhaps adding this new code for a new option like OPEN_PLMENU would
be better? This way the old plain text would work unmodified.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
