Re: [E-devel] Patch for e_modules to add support to gettext with automake-1.10
On Thu, 15 Feb 2007 09:24:14 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: the real problem is introducing cvs as a build and rebuild dep (which it never was before - cvs was entirely divorced and separate from build file creation - which allowed us to divorce CMS from coding if we ever wanted to). sure it'd need the cvs command - but it's sneaking in. it feels very unclean to me. i see the logic of using cvs as a compression scheme for multiple versions of gettext, but where autofoo used to be basic unix utils + m4 now is stealing away with cvs too. we are forever changing out autofoo - mostly for the next user X who uses gentoo or some bleeding edge distro who updates to latest bleeding edge autofoo X and breaks something. Another major problem, at least as far as I'm concerned, is that autotools is forever trying to sneak in GPL licenses and FSF copyrights. I've pointed this out to Marc-Andre in private emails, and I probably mentioned this the last time around. E17 is BSD licensed and copyright Raster + friends, but the use of autopoint generates files that claim FSF copyright over parts of E17. Other projects that use autotools work quite happily by stating the version of autotools required. Since autotools is a developer tool that is not normally used by ordinary users (even if they are compiling from source) specifying specific versions is quite valid, it keeps all the developers on the same page, and reduces the complexities of supporting various systems. So we can stop wasting time supporting the latest bleeding edge autotools, stick with what has worked for years, and get on with E coding. signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Pin a window to a desktop...
Hello,
Don't know if anyone would find this useful or not. But here it is.
After playing with borderless windows it occurred to me it would be nice
to simply Pin a window down to the desktop background. The attached
patch adds a border menu item that will:
- set the window to borderles
- set stacking to below all
- set skip winlist
This has the net effect of pinning it down to the desktop background,
and allowing it to stay there when you toggle the show desktop state.
I find this useful, because I like to have a few items up borderless
below everything, and wish that they not get swept away when showing the
desktop. I realize removing it from the winlist accomplishes that.
However in order to do what I want to several windows I must select all
these settings on each window. Seems a bit tedious. So I created a
border menu to automate it. :)
Gives that Active Desktop feeling that MS had/has going on. You could
add various (dare I say transparent) terminals showing whatever, maybe
pin your calendar app down so its always there. Just ideas.
To complete the 'effect', next would be to remove that clients
eligibility from the dropshadow module. If this patch is accepted, I'll
look into that.
Note that once pinned you may use the alt+rmb combo to bring the menu up
and select unpin.
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_border.h
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_border.h,v
retrieving revision 1.153
diff -u -r1.153 e_border.h
--- e17/apps/e/src/bin/e_border.h 30 Nov 2006 17:42:41 - 1.153
+++ e17/apps/e/src/bin/e_border.h 15 Feb 2007 17:50:23 -
@@ -351,6 +351,7 @@
unsigned intneed_maximize : 1;
E_Maximize maximized;
unsigned intborderless : 1;
+ unsigned intpinned_to_desktop : 1;
const char *bordername;
unsigned intlock_user_location : 1; /*DONE*/
Index: e17/apps/e/src/bin/e_int_border_menu.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_int_border_menu.c,v
retrieving revision 1.55
diff -u -r1.55 e_int_border_menu.c
--- e17/apps/e/src/bin/e_int_border_menu.c 28 Dec 2006 14:05:07 -
1.55
+++ e17/apps/e/src/bin/e_int_border_menu.c 15 Feb 2007 17:50:23 -
@@ -27,6 +27,8 @@
static void _e_border_menu_cb_skip_winlist(void *data, E_Menu *m, E_Menu_Item
*mi);
static void _e_border_menu_cb_sendto_pre(void *data, E_Menu *m, E_Menu_Item
*mi);
static void _e_border_menu_cb_sendto(void *data, E_Menu *m, E_Menu_Item *mi);
+static void _e_border_menu_cb_pin(void *data, E_Menu *m, E_Menu_Item *mi);
+static void _e_border_menu_cb_unpin(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_raise(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_lower(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_state_pre(void *data, E_Menu *m, E_Menu_Item
*mi);
@@ -182,6 +184,28 @@
e/widgets/border/default/sendto);
}
+ if (!bd-pinned_to_desktop)
+ {
+ mi = e_menu_item_new(m);
+ e_menu_item_label_set(mi, _(Pin to Desktop));
+ e_menu_item_callback_set(mi, _e_border_menu_cb_pin, bd);
+e_menu_item_icon_edje_set(mi,
+ e_theme_edje_file_get(base/theme/borders,
+
e/widgets/border/default/stick),
+ e/widgets/border/default/stick);
+ }
+
+ if (bd-pinned_to_desktop)
+ {
+ mi = e_menu_item_new(m);
+ e_menu_item_label_set(mi, _(Unpin from Desktop));
+ e_menu_item_callback_set(mi, _e_border_menu_cb_unpin, bd);
+e_menu_item_icon_edje_set(mi,
+ e_theme_edje_file_get(base/theme/borders,
+
e/widgets/border/default/stick),
+ e/widgets/border/default/stick);
+ }
+
mi = e_menu_item_new(m);
e_menu_item_separator_set(mi, 1);
@@ -795,6 +819,54 @@
}
}
+static void
+_e_border_menu_cb_pin(void *data, E_Menu *m, E_Menu_Item *mi)
+{
+ E_Border *bd;
+
+ bd = e_object_data_get(E_OBJECT(m));
+ if (bd)
+ {
+ bd-pinned_to_desktop = 1;
+ bd-borderless = 1;
+ bd-user_skip_winlist = 1;
+ bd-client.netwm.state.stacking = E_STACKING_BELOW;
+
+if (bd-layer != 50)
+ {
+e_border_layer_set(bd, 50);
+e_hints_window_stacking_set(bd, E_STACKING_BELOW);
+ }
+
+ bd-client.border.changed = 1;
+ bd-changed = 1;
+ }
+}
+
+static void
+_e_border_menu_cb_unpin(void *data, E_Menu *m, E_Menu_Item *mi)
+{
+ E_Border *bd;
+
+ bd = e_object_data_get(E_OBJECT(m));
+ if (bd)
+ {
+ bd-pinned_to_desktop = 0;
+ bd-borderless = 0;
+ bd-user_skip_winlist = 0;
+
Re: [E-devel] Patch for e_modules to add support to gettext with automake-1.10
David Seikel wrote: On Thu, 15 Feb 2007 09:24:14 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: the real problem is introducing cvs as a build and rebuild dep (which it never was before - cvs was entirely divorced and separate from build file creation - which allowed us to divorce CMS from coding if we ever wanted to). sure it'd need the cvs command - but it's sneaking in. it feels very unclean to me. i see the logic of using cvs as a compression scheme for multiple versions of gettext, but where autofoo used to be basic unix utils + m4 now is stealing away with cvs too. we are forever changing out autofoo - mostly for the next user X who uses gentoo or some bleeding edge distro who updates to latest bleeding edge autofoo X and breaks something. We are already far from basic unix utils + m4 as autotools require perl. Adding cvs is just another drop in the ocean. If adding cvs resolves just a few of the issues there have been over time that is in my opinion a price worth paying. Another major problem, at least as far as I'm concerned, is that autotools is forever trying to sneak in GPL licenses and FSF copyrights. I've pointed this out to Marc-Andre in private emails, and I probably mentioned this the last time around. E17 is BSD licensed and copyright Raster + friends, but the use of autopoint generates files that claim FSF copyright over parts of E17. I don't think this is true, please correct me if I'm wrong. autopoint will copy in ABOUT-NLS which contains information about the gettext package, including licensensing, but it does not sneak in anything or otherwise impose licensing that isn't already implied by using gettext in the first place. It can be avoided to include ABOUT-NLS in the distribution tarball by removing it after running autopoint and specifying AUTOMAKE_OPTIONS = foreign in the top-level Makefile.am (meaning this is not a GNU project). If you don't have a COPYING, a GPL one will be copied in somewhere along the auto-line (not sure if it has anything to do with gettext, and AUTOMAKE_OPTIONS = foreign suppresses this) but it will not replace/modify an existing one, which you of course should have to begin with. gettextize, on the other hand, is a tool that can assist you making various changes to the autotool files to get gettext set up for the package. gettextize will mess around all over the place, add stuff to ChangeLog and po/ChangeLog and whatnot, and should *not* be run from autogen.sh. Other projects that use autotools work quite happily by stating the version of autotools required. Since autotools is a developer tool that is not normally used by ordinary users (even if they are compiling from source) specifying specific versions is quite valid, it keeps all the developers on the same page, and reduces the complexities of supporting various systems. So we can stop wasting time supporting the latest bleeding edge autotools, stick with what has worked for years, and get on with E coding. If building E requires specific autotool versions, some documentation of which they are would be nice (wiki?). Should those be coded into all the autogen.sh's? Otherwise maybe provide some tips about how to set up your environment to use the correct autotool versions (wiki?). Downgrading say automake-1.10 to automake-1.9.6 is in my opinion not an option as non-e packages may require 1.10. Or is the message that if I'm too stupid to figure it all out by myself I should go play elsewhere? But I don't. I want E. I goto get-e, edevelop, #e, the mailing lists where you will waste your time giving me bad advice wasting my time. /Kim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Pin a window to a desktop...
On 02/15/2007 14:19, Aleksej Struk wrote:
On Thu, Feb 15, 2007 at 11:05:47AM -0600, Ravenlock wrote:
Hello,
Don't know if anyone would find this useful or not. But here it is.
After playing with borderless windows it occurred to me it would be nice
to simply Pin a window down to the desktop background.
Well, for me it would be really useful. I also would like to have some
borderless windows, like terminal, always on desktop.
K. Just to clarify, in case of misunderstanding. You *can* presently
accomplish this feat today. It simply is a bit less convenient than I'd
like. The patch just makes it quick and easy to nail the window down.
The attached
patch adds a border menu item that will:
- set the window to borderles
- set stacking to below all
- set skip winlist
This has the net effect of pinning it down to the desktop background,
and allowing it to stay there when you toggle the show desktop state.
I find this useful, because I like to have a few items up borderless
below everything, and wish that they not get swept away when showing the
desktop. I realize removing it from the winlist accomplishes that.
However in order to do what I want to several windows I must select all
these settings on each window. Seems a bit tedious. So I created a
border menu to automate it. :)
Gives that Active Desktop feeling that MS had/has going on. You could
add various (dare I say transparent) terminals showing whatever, maybe
pin your calendar app down so its always there. Just ideas.
To complete the 'effect', next would be to remove that clients
eligibility from the dropshadow module. If this patch is accepted, I'll
look into that.
Note that once pinned you may use the alt+rmb combo to bring the menu up
and select unpin.
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_border.h
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_border.h,v
retrieving revision 1.153
diff -u -r1.153 e_border.h
--- e17/apps/e/src/bin/e_border.h30 Nov 2006 17:42:41 - 1.153
+++ e17/apps/e/src/bin/e_border.h15 Feb 2007 17:50:23 -
@@ -351,6 +351,7 @@
unsigned intneed_maximize : 1;
E_Maximize maximized;
unsigned intborderless : 1;
+ unsigned intpinned_to_desktop : 1;
const char *bordername;
unsigned intlock_user_location : 1; /*DONE*/
Index: e17/apps/e/src/bin/e_int_border_menu.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_int_border_menu.c,v
retrieving revision 1.55
diff -u -r1.55 e_int_border_menu.c
--- e17/apps/e/src/bin/e_int_border_menu.c 28 Dec 2006 14:05:07 -
1.55
+++ e17/apps/e/src/bin/e_int_border_menu.c 15 Feb 2007 17:50:23 -
@@ -27,6 +27,8 @@
static void _e_border_menu_cb_skip_winlist(void *data, E_Menu *m,
E_Menu_Item *mi);
static void _e_border_menu_cb_sendto_pre(void *data, E_Menu *m, E_Menu_Item
*mi);
static void _e_border_menu_cb_sendto(void *data, E_Menu *m, E_Menu_Item
*mi);
+static void _e_border_menu_cb_pin(void *data, E_Menu *m, E_Menu_Item *mi);
+static void _e_border_menu_cb_unpin(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_raise(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_lower(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_border_menu_cb_state_pre(void *data, E_Menu *m, E_Menu_Item
*mi);
@@ -182,6 +184,28 @@
e/widgets/border/default/sendto);
}
+ if (!bd-pinned_to_desktop)
+ {
+mi = e_menu_item_new(m);
+e_menu_item_label_set(mi, _(Pin to Desktop));
+e_menu_item_callback_set(mi, _e_border_menu_cb_pin, bd);
+e_menu_item_icon_edje_set(mi,
+ e_theme_edje_file_get(base/theme/borders,
+
e/widgets/border/default/stick),
+ e/widgets/border/default/stick);
+ }
+
+ if (bd-pinned_to_desktop)
+ {
+mi = e_menu_item_new(m);
+e_menu_item_label_set(mi, _(Unpin from Desktop));
+e_menu_item_callback_set(mi, _e_border_menu_cb_unpin, bd);
+e_menu_item_icon_edje_set(mi,
+ e_theme_edje_file_get(base/theme/borders,
+
e/widgets/border/default/stick),
+ e/widgets/border/default/stick);
+ }
+
mi = e_menu_item_new(m);
e_menu_item_separator_set(mi, 1);
@@ -795,6 +819,54 @@
}
}
+static void
+_e_border_menu_cb_pin(void *data, E_Menu *m, E_Menu_Item *mi)
+{
+ E_Border *bd;
+
+ bd = e_object_data_get(E_OBJECT(m));
+ if (bd)
+ {
+bd-pinned_to_desktop = 1;
+bd-borderless = 1;
+bd-user_skip_winlist = 1;
+bd-client.netwm.state.stacking = E_STACKING_BELOW;
+
Re: [E-devel] Patch for e_modules to add support to gettext with automake-1.10
On Thu, 15 Feb 2007 21:02:52 +0100 Kim Woelders [EMAIL PROTECTED] wrote: David Seikel wrote: Another major problem, at least as far as I'm concerned, is that autotools is forever trying to sneak in GPL licenses and FSF copyrights. I've pointed this out to Marc-Andre in private emails, and I probably mentioned this the last time around. E17 is BSD licensed and copyright Raster + friends, but the use of autopoint generates files that claim FSF copyright over parts of E17. I don't think this is true, please correct me if I'm wrong. e17/apps/e/po/Makevars.template, but I guess that one snuck past you. B-) signature.asc Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch for e_modules to add support to gettext with automake-1.10
David Seikel wrote: On Thu, 15 Feb 2007 21:02:52 +0100 Kim Woelders [EMAIL PROTECTED] wrote: David Seikel wrote: Another major problem, at least as far as I'm concerned, is that autotools is forever trying to sneak in GPL licenses and FSF copyrights. I've pointed this out to Marc-Andre in private emails, and I probably mentioned this the last time around. E17 is BSD licensed and copyright Raster + friends, but the use of autopoint generates files that claim FSF copyright over parts of E17. I don't think this is true, please correct me if I'm wrong. e17/apps/e/po/Makevars.template, but I guess that one snuck past you. B-) po/Makevars.template is copied in as a template for you, so you get some hints about what you should write in po/Makevars, which is the one that is actually used. It is a *template*. It resides on *your* disk. It is not used or propagated into the release tarball. po/Makevars is. /Kim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
