Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tue, 6 Oct 2009 17:17:10 -0700 Michael Jennings wrote: > On Tuesday, 06 October 2009, at 23:43:58 (+0200), > Kim Woelders wrote: > > > In my opinion the MWM hint is not related to EWMH, so I think all > > that is accomplished is to fetch a potentially rather large atom > > list which shouldn't contain the item being looked for :) > > My impression based on the IRC conversation was that Eterm -x didn't > work under e17 without this patch, and that this patch made Eterm more > EWMH-compliant. If that's not the case, then I misunderstood, and the > patch needs to be rethought. > > > This would just set the MWM hint and hope for the best. If the WM > > handles it, fine (is there any WM around that doesn't?). > > Some user was in IRC yesterday complaining about a WM (e17 I thought, > but I could be mistaken) that did not provide the _MOTIF_WM_INFO atom, > and thus Eterm kicked in override_redirect. Not knowing about > Ctrl-click, he assumed the Eterm was fubar. So apparently *something* > out there doesn't implement MWM hints properly. Is this related to my reported problems with Eterm (and at least one other app) where iconify and maximise don't turn up in the E17 window menu when using borderless? signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tuesday, 06 October 2009, at 23:43:58 (+0200), Kim Woelders wrote: > In my opinion the MWM hint is not related to EWMH, so I think all > that is accomplished is to fetch a potentially rather large atom > list which shouldn't contain the item being looked for :) My impression based on the IRC conversation was that Eterm -x didn't work under e17 without this patch, and that this patch made Eterm more EWMH-compliant. If that's not the case, then I misunderstood, and the patch needs to be rethought. > This would just set the MWM hint and hope for the best. If the WM > handles it, fine (is there any WM around that doesn't?). Some user was in IRC yesterday complaining about a WM (e17 I thought, but I could be mistaken) that did not provide the _MOTIF_WM_INFO atom, and thus Eterm kicked in override_redirect. Not knowing about Ctrl-click, he assumed the Eterm was fubar. So apparently *something* out there doesn't implement MWM hints properly. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "It doesn't take a lot of strength to hang on. It takes a lot of strength to let go." -- Rep. JC Watts, Jr. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Wednesday, 07 October 2009, at 01:52:47 (+0200), hannes.janet...@gmail.com wrote: > ok, looking through other window managers source setting mwm_hints in > net_supported is not common. It seems window managers do not announce > that they handle mwm hints in any special way. I'm going to remove my > patch then.. still i think it's would be the correct way to handle it. I think the standard is referring to EWMH hints being defined in _NET_SUPPORTED, not all hints in general. I thought you were telling me that E or other WM's required this for borderless to work. Perhaps I was confused. :) > - just set the hint and let the wm handle it (my vote for it too) Eterm does have a way to assume focus (Ctrl-Button1) for situations where override_redirect was required, or there is no WM, or whatever. That said, if everyone finds it so objectionable, perhaps it should change. Kim, how do you feel about it knowing that focus isn't as much of an issue? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Only an idiot fights a war on two fronts. Only the heir to the throne of the Kingdom of Idiots would fight a war on twelve fronts." -- Ambassador Londo Mollari (Peter Jurasik), "Babylon Five" -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
ok, looking through other window managers source setting mwm_hints in net_supported is not common. It seems window managers do not announce that they handle mwm hints in any special way. I'm going to remove my patch then.. still i think it's would be the correct way to handle it. There is still the problem for users that wonder why their windows get no focus. the options for apps seem to be: - require mwm_info to exist for using borderless. chances are that wm that are not fully mwm compliant just set mwm_info to provide borderless window for these apps without them going override redirect. - some apps do a weak check and look whether mwm_hints exists, this assumes only the wm would create mwm_hints atom (which ecore_x does on init by default..). one could set the hint and hope that it was really the wm that set it. at least one knows when mwm_hints does not exist the wm will definitely not handle it :) - just set the hint and let the wm handle it (my vote for it too) Hannes On Wed, Oct 7, 2009 at 1:00 AM, hannes.janet...@gmail.com wrote: > yes, it says it is 'intended' to replace mwm hints, but > NET_WM_WINDOW_TYPE does not handle the borderless window case. > following EWMH the wm must set hints it supports in _NET_SUPPORTED > (http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449322). > This way apps can know that mwm hints are handled but cant expect the > wm to be fully mwm compliant, which would be required when the wm sets > _MOTIF_WM_INFO. > > > Hannes > > On Tue, Oct 6, 2009 at 11:55 PM, Vincent Torri wrote: >> >> >> On Tue, 6 Oct 2009, Kim Woelders wrote: >> >>> On Tue, 06 Oct 2009 22:27:38 +0200, Michael Jennings wrote: >>> On Tuesday, 06 October 2009, at 21:52:42 (+0200), Kim Woelders wrote: > It seems to me that you are making Eterm e17 compliant in stead of > making > e17 MWM hint compliant. I think he did that too. My thought was to make Eterm more EWMH compliant. Do you feel that this patch fails to accomplish that? >>> In my opinion the MWM hint is not related to EWMH, so I think all that is >>> accomplished is to fetch a potentially rather large atom list which >>> shouldn't contain the item being looked for :) >> >> the MWM hint is not part of EWMH >> >> see http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144 >> >> (the paragraph beginning by 'Rationale') >> >> Vincent >> >> -- >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
yes, it says it is 'intended' to replace mwm hints, but NET_WM_WINDOW_TYPE does not handle the borderless window case. following EWMH the wm must set hints it supports in _NET_SUPPORTED (http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449322). This way apps can know that mwm hints are handled but cant expect the wm to be fully mwm compliant, which would be required when the wm sets _MOTIF_WM_INFO. Hannes On Tue, Oct 6, 2009 at 11:55 PM, Vincent Torri wrote: > > > On Tue, 6 Oct 2009, Kim Woelders wrote: > >> On Tue, 06 Oct 2009 22:27:38 +0200, Michael Jennings wrote: >> >>> On Tuesday, 06 October 2009, at 21:52:42 (+0200), >>> Kim Woelders wrote: >>> It seems to me that you are making Eterm e17 compliant in stead of making e17 MWM hint compliant. >>> >>> I think he did that too. My thought was to make Eterm more EWMH >>> compliant. Do you feel that this patch fails to accomplish that? >>> >> In my opinion the MWM hint is not related to EWMH, so I think all that is >> accomplished is to fetch a potentially rather large atom list which >> shouldn't contain the item being looked for :) > > the MWM hint is not part of EWMH > > see http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144 > > (the paragraph beginning by 'Rationale') > > Vincent > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tue, 6 Oct 2009, Kim Woelders wrote: > On Tue, 06 Oct 2009 22:27:38 +0200, Michael Jennings wrote: > >> On Tuesday, 06 October 2009, at 21:52:42 (+0200), >> Kim Woelders wrote: >> >>> It seems to me that you are making Eterm e17 compliant in stead of >>> making >>> e17 MWM hint compliant. >> >> I think he did that too. My thought was to make Eterm more EWMH >> compliant. Do you feel that this patch fails to accomplish that? >> > In my opinion the MWM hint is not related to EWMH, so I think all that is > accomplished is to fetch a potentially rather large atom list which > shouldn't contain the item being looked for :) the MWM hint is not part of EWMH see http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144 (the paragraph beginning by 'Rationale') Vincent -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tue, 06 Oct 2009 22:27:38 +0200, Michael Jennings wrote: > On Tuesday, 06 October 2009, at 21:52:42 (+0200), > Kim Woelders wrote: > >> It seems to me that you are making Eterm e17 compliant in stead of >> making >> e17 MWM hint compliant. > > I think he did that too. My thought was to make Eterm more EWMH > compliant. Do you feel that this patch fails to accomplish that? > In my opinion the MWM hint is not related to EWMH, so I think all that is accomplished is to fetch a potentially rather large atom list which shouldn't contain the item being looked for :) This may just be my opinion though. AFAIK this is not covered specifically by standards and I don't know what other WMs do. I just find it reasonable that if you test for MWM compliance, you look for _MOTIF_WM_INFO, not _NET_SUPPORTED. If a WM wants to honor MWM_HINTS_DECORATIONS for old apps it most likely has _MOTIF_WM_INFO set anyway. >> I don't think _MOTIF_WM_HINTS should be listed in _NET_SUPPORTED at >> all. It just makes no sense. EWMH unaware apps will certainly never >> look there. > > It doesn't seem to me that this would break anything, though (speaking > specifically about the Eterm patch, not what should/shouldn't be done > to E). > No, no breakage, just overhead. >> If anything should be changed here, I'd consider removing the test >> for _MOTIF_WM_INFO (and going override-redirect if not set) and just >> set the MWM hint if borderless is requested. > > What are your thoughts on why you'd go this route as opposed to > supporting the additional netwm-based mechanism? > This would just set the MWM hint and hope for the best. If the WM handles it, fine (is there any WM around that doesn't?). If not, you'd just get your non-borderless window. I think it is really bad client behavior to resort to override-redirect. It seems to me that it doesn't and can't work properly anyway due to focus issues. > The patch seemed reasonable to me (Hannes had me review it before he > committed), but I'm open to other suggestions as well. > /Kim -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tuesday, 06 October 2009, at 21:52:42 (+0200), Kim Woelders wrote: > It seems to me that you are making Eterm e17 compliant in stead of making > e17 MWM hint compliant. I think he did that too. My thought was to make Eterm more EWMH compliant. Do you feel that this patch fails to accomplish that? > I don't think _MOTIF_WM_HINTS should be listed in _NET_SUPPORTED at > all. It just makes no sense. EWMH unaware apps will certainly never > look there. It doesn't seem to me that this would break anything, though (speaking specifically about the Eterm patch, not what should/shouldn't be done to E). > If anything should be changed here, I'd consider removing the test > for _MOTIF_WM_INFO (and going override-redirect if not set) and just > set the MWM hint if borderless is requested. What are your thoughts on why you'd go this route as opposed to supporting the additional netwm-based mechanism? The patch seemed reasonable to me (Hannes had me review it before he committed), but I'm open to other suggestions as well. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "I gave you my purity, and my purity you stole. Did you think I wouldn't recognize this compromise? Am I just to stupid to realize? Stale incense, old sweat, and lies, lies, lies." -- Nine Inch Nails, "sin" -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth trunk/eterm/Eterm/src
On Tue, 06 Oct 2009 01:54:54 +0200, Enlightenment SVN
wrote:
> Log:
> check wm supporting hints for mwm:
> make borderless also work with window managers that do not pretend to
> be mwm
> Author: jeffdameth
> Date: 2009-10-05 16:54:53 -0700 (Mon, 05 Oct 2009)
> New Revision: 42896
>
> Modified:
> trunk/eterm/Eterm/src/windows.c
>
> Modified: trunk/eterm/Eterm/src/windows.c
> ===
> --- trunk/eterm/Eterm/src/windows.c 2009-10-05 19:34:35 UTC (rev 42895)
> +++ trunk/eterm/Eterm/src/windows.c 2009-10-05 23:54:53 UTC (rev 42896)
> @@ -363,6 +363,46 @@
> XRecolorCursor(Xdisplay, TermWin_cursor, &fg, &bg);
> }
> +int
> +check_mwm_supported(void)
> +{
> +Atom prop, mwm_prop, type_ret;
> +unsigned char *prop_ret;
> +unsigned long bytes_after, num_ret;
> +int format_ret, num, i, supported = 0;
> +
> +/* check whether wm support mwm hint */
> +prop = XInternAtom(Xdisplay, "_NET_SUPPORTED", True);
> +mwm_prop = XInternAtom(Xdisplay, "_MOTIF_WM_HINTS", True);
> +
> +if ((prop != None) && (mwm_prop != None)) {
> +prop_ret = NULL;
> +if (XGetWindowProperty(Xdisplay, Xroot, prop, 0, 0x7fff,
> False,
> + XA_ATOM, &type_ret, &format_ret,
> &num_ret,
> + &bytes_after, &prop_ret) == Success) {
> +
> +if ((type_ret == XA_ATOM) &&
> +(format_ret == 32) &&
> +(num_ret && prop_ret))
> +{
> +for (i = 0; i < num_ret; i++)
> +if (mwm_prop == ((unsigned long*)prop_ret)[i])
> +supported = 1;
> +}
> +if (prop_ret)
> +XFree(prop_ret);
> +}
> +}
> +/* check whether wm is mwm */
> +if (!supported) {
> +prop = XInternAtom(Xdisplay, "_MOTIF_WM_INFO", True);
> +if (prop != None) {
> +supported = 1;
> +}
> +}
> +return supported;
> +}
> +
> /* Create_Windows() - Open and map the window */
> void
> Create_Windows(int argc, char *argv[])
> @@ -378,14 +418,13 @@
> MWMHints mwmhints;
> if (BITFIELD_IS_SET(eterm_options, ETERM_OPTIONS_BORDERLESS)) {
> -prop = XInternAtom(Xdisplay, "_MOTIF_WM_INFO", True);
> -if (prop == None) {
> +if (check_mwm_supported()) {
> +mwmhints.flags = MWM_HINTS_DECORATIONS;
> +mwmhints.decorations = 0;
> +} else {
> libast_print_warning("Window Manager does not support MWM
> hints. Bypassing window manager control for borderless window.\n");
> Attributes.override_redirect = TRUE;
> mwmhints.flags = 0;
> -} else {
> -mwmhints.flags = MWM_HINTS_DECORATIONS;
> -mwmhints.decorations = 0;
> }
> } else {
> mwmhints.flags = 0;
>
Why?!?
It seems to me that you are making Eterm e17 compliant in stead of making
e17 MWM hint compliant.
I don't think _MOTIF_WM_HINTS should be listed in _NET_SUPPORTED at all.
It just makes no sense. EWMH unaware apps will certainly never look there.
If anything should be changed here, I'd consider removing the test for
_MOTIF_WM_INFO (and going override-redirect if not set) and just set the
MWM hint if borderless is requested.
/Kim
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Weird jpeg error on evas_object_image_file_set
Hi, I've started getting a strange error when using evas_object_image_file_set on non-image files. Before evas provided a load error in case it couldn't load a file. Now anything beyond evas_object_image_file_set is not run. ## Backtrace #0 0x00ebd621 in siglongjmp () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0040eb5e in _JPEGFatalErrorHandler (cinfo=0xbfffca2c) at evas_image_load_jpeg.c:51 #2 0x006926f2 in first_marker (cinfo=0xbfffca2c) at ./jdmarker.c:935 #3 read_markers (cinfo=0xbfffca2c) at ./jdmarker.c:960 #4 0x00690a2f in consume_markers (cinfo=0xbfffca2c) at ./jdinput.c:296 #5 0x0068ec67 in jpeg_consume_input (cinfo=0xbfffca2c) at ./jdapimin.c:301 #6 0x0068f0a5 in jpeg_read_header (cinfo=0xbfffca2c, require_image=1) at ./jdapimin.c:249 #7 0x0040ec78 in evas_image_load_file_head_jpeg_internal (ie=0x8103310, f=0x8105388) at evas_image_load_jpeg.c:97 #8 0x00410578 in evas_image_load_file_head_jpeg (ie=0x8103310, file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0) at evas_image_load_jpeg.c:701 #9 0x0026989e in evas_common_load_rgba_image_module_from_file (ie=0x8103310) at evas_image_load.c:120 #10 0x0021eb66 in _evas_cache_image_entry_new (cache=0x8088228, hkey=0xbfffce00 "/home/urandom/.ICEauthority//://(null)", timestamp=1254411927, file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0, lo=0xbfffcf28, error=0xbfffcfcc) at evas_cache_image.c:269 #11 0x0021fdfb in evas_cache_image_request (cache=0x8088228, file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0, lo=0xbfffcf28, error=0xbfffcfcc) at evas_cache_image.c:860 ---Type to continue, or q to quit--- #12 0x0026a689 in evas_common_load_image_from_file ( file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0, lo=0xbfffd03c) at evas_image_main.c:528 #13 0x005fb4e2 in eng_image_load (data=0x808e0f0, file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0, error=0x8103220, lo=0xbfffd03c) at evas_engine.c:594 #14 0x001e59ec in evas_object_image_file_set (obj=0x8103090, file=0x80f2f94 "/home/urandom/.ICEauthority", key=0x0) at evas_object_image.c:316 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Support of silent rules with automake 1.11
Hello. On Tue, 2009-10-06 at 12:01, Vincent Torri wrote: > > The problem is that it is only in automake 1.11. A solution to have it > anyway would be to add in configure.ac: > > m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) > > it should work with and without automake 1.11 and add the feature only if > the macro exists, that is with automake 1.11 > > Is there any objection that I add this in the configure.ac file ? I use exactly the line above on different projects for some weeks now and heard no complains, not even from alsa-lib, about it. It enabled me, and hopefully others, to spot actually interesting messages/warnings during compile and linking a lot easier. I would like to see it used in EFL. regards Stefan Schmidt -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Support of silent rules with automake 1.11
On Tue, Oct 6, 2009 at 7:01 AM, Vincent Torri wrote: > > Hey, > > automake 1.11 has the nice feature of "silent rule", that it, it can > remove the compilation command and display only the file that is compiled > (plus a small character in front of the file (also known as the shaved > feature). > > The problem is that it is only in automake 1.11. A solution to have it > anyway would be to add in configure.ac: > > m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) > > it should work with and without automake 1.11 and add the feature only if > the macro exists, that is with automake 1.11 > > Is there any objection that I add this in the configure.ac file ? go for it! That will enable us to easily spot warnings in the multitude of messages... at least for those non-emacs users out that, since emacs will highlight and jump to errors and warnings automatically ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Support of silent rules with automake 1.11
Hey, automake 1.11 has the nice feature of "silent rule", that it, it can remove the compilation command and display only the file that is compiled (plus a small character in front of the file (also known as the shaved feature). The problem is that it is only in automake 1.11. A solution to have it anyway would be to add in configure.ac: m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) it should work with and without automake 1.11 and add the feature only if the macro exists, that is with automake 1.11 Is there any objection that I add this in the configure.ac file ? Vincent -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
