Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.
Doug, If you're looking into windows placement and sizing, would you spend a moment on related, and somewhat annoying problemettes: 1) Windows of certain applications always get placed overlapping the icon strip - wxMaxima. Their size is never retained from the last use, but is set, well, not arbitrarily, there seems to be some logic in this, but with what rules? 2) Position of windows having height equal or approx. equal to the height of the screen is set not to Y=0, but to about 1...1.1 titlebar heights lower. I experience this with Libreoffice. I believe I've tried all reasonable placement schemes and edge resistance/attractance combinations. Now it is 'automatic' with 'edge resistance'. Yury On 09/21/2014 06:56 AM, Doug Torrance wrote: If a user moves a window which is currently maximized, the current behavior is ... -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 4/4] NEWS: Add note about window snapping.
--- NEWS | 16 1 file changed, 16 insertions(+) diff --git a/NEWS b/NEWS index 35319b0..d1852bf 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,22 @@ NEWS for veteran Window Maker users --- +--- 0.95.7 + +Window snapping +--- + +You can now "snap" a window to one side of the screen by dragging it to that +side. It is enabled by setting WindowSnapping = "YES" in +~/GNUstep/Defaults/WindowMaker or selecting "Enable window snapping" under +"Expert User Preferences" in WPrefs.app. + +Note that window snapping is automatically disabled if DontLinkWorkspaces = +"NO", as this feature also involves dragging a window to one side of the +screen. + +Also, now when you move a maximized window, it is automatically unmaximized. + --- 0.95.6 More image format supported -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 3/4] wmaker: Moving unmaximizes windows.
If a user moves a window which is currently maximized, the current behavior is
to keep the window geometry and maximized status unchanged. This can lead to
peculiar behavior. For example, suppose a user maximizes a window to the
right half of the screen (either through the window menu, keyboard shortcut, or
new snapping feature), then moves it, and then attempts maximize it to the
right half of the screen again. Instead of the expected result, the window is
unmaximized and returned to its original geometry.
This patch changes the behavior by unmaximizing any maximized window which is
moved. This is consistent with other desktop environments, e.g., GNOME, Unity,
and Windows.
---
src/moveres.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/moveres.c b/src/moveres.c
index 6899a86..e05d3be 100644
--- a/src/moveres.c
+++ b/src/moveres.c
@@ -1723,6 +1723,20 @@ int wMouseMoveWindow(WWindow * wwin, XEvent * ev)
} else if (abs(ev->xmotion.x_root -
event.xmotion.x_root) >= MOVE_THRESHOLD
|| abs(ev->xmotion.y_root -
event.xmotion.y_root) >= MOVE_THRESHOLD) {
+ if (wwin->flags.maximized) {
+ float titlebar_ratio;
+ int new_x, new_y;
+
+ titlebar_ratio = (moveData.mouseX -
wwin->frame_x) /
+ (float)wwin->frame->core->width;
+ new_y = wwin->frame_y;
+ wUnmaximizeWindow(wwin);
+ new_x = moveData.mouseX -
titlebar_ratio * wwin->frame->core->width;
+ wWindowMove(wwin, new_x, new_y);
+ moveData.realX = moveData.calcX =
wwin->frame_x;
+ moveData.realY = moveData.calcY =
wwin->frame_y;
+ }
+
XChangeActivePointerGrab(dpy, ButtonMotionMask
| ButtonReleaseMask |
ButtonPressMask,
wPreferences.cursor[WCUR_MOVE], CurrentTime);
--
1.9.1
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/4] WPrefs.app: Add ability to enable or disable window snapping.
---
WPrefs.app/Expert.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c
index 8cf5d6d..aee45fb 100644
--- a/WPrefs.app/Expert.c
+++ b/WPrefs.app/Expert.c
@@ -81,6 +81,9 @@ static const struct {
/* default: */ False, OPTION_WMAKER, "KbdModeLock" }
#endif /* XKB_MODELOCK */
+ { N_("Enable window snapping."),
+ /* default: */ False, OPTION_WMAKER, "WindowSnapping" },
+
};
--
1.9.1
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/4] wmaker: Add window snapping feature.
This patch adds the ability to "snap" a window to one side of the screen by
dragging it to that side. It is enabled by setting WindowSnapping = "YES" in
~/GNUstep/Defaults/WindowMaker.
Note that window snapping is automatically disabled if DontLinkWorkspaces =
"NO", as this feature also involves dragging a window to one side of the
screen.
---
src/WindowMaker.h | 1 +
src/defaults.c| 2 ++
src/moveres.c | 64 ++-
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 53d2eaf..a93a64d 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -352,6 +352,7 @@ extern struct WPreferences {
char no_dithering;/* use dithering or not */
char no_animations; /* enable/disable animations */
char no_autowrap; /* wrap workspace when window is moved
to the edge */
+char window_snapping; /* enable window snapping */
char highlight_active_app; /* show the focused app by highlighting
its icon */
char auto_arrange_icons; /* automagically arrange icons */
diff --git a/src/defaults.c b/src/defaults.c
index 72c8b6f..7349443 100644
--- a/src/defaults.c
+++ b/src/defaults.c
@@ -450,6 +450,8 @@ WDefaultEntry optionList[] = {
&wPreferences.no_animations, getBool, NULL, NULL, NULL},
{"DontLinkWorkspaces", "NO", NULL,
&wPreferences.no_autowrap, getBool, NULL, NULL, NULL},
+ {"WindowSnapping", "NO", NULL,
+ &wPreferences.window_snapping, getBool, NULL, NULL, NULL},
{"HighlightActiveApp", "YES", NULL,
&wPreferences.highlight_active_app, getBool, NULL, NULL, NULL},
{"AutoArrangeIcons", "NO", NULL,
diff --git a/src/moveres.c b/src/moveres.c
index c88875b..6899a86 100644
--- a/src/moveres.c
+++ b/src/moveres.c
@@ -588,6 +588,8 @@ typedef struct {
int calcX, calcY; /* calculated position of window */
int omouseX, omouseY; /* old mouse position */
int mouseX, mouseY; /* last known position of the pointer */
+
+ enum {SNAP_NONE, SNAP_LEFT, SNAP_RIGHT} snap;
} MoveData;
#define WTOP(w) (w)->frame_y
@@ -829,6 +831,8 @@ static void initMoveData(WWindow * wwin, MoveData * data)
data->winWidth = wwin->frame->core->width +
(HAS_BORDER_WITH_SELECT(wwin) ? 2 * wwin->screen_ptr->frame_border_width : 0);
data->winHeight = wwin->frame->core->height +
(HAS_BORDER_WITH_SELECT(wwin) ? 2 * wwin->screen_ptr->frame_border_width : 0);
+
+ data->snap = SNAP_NONE;
}
static Bool checkWorkspaceChange(WWindow * wwin, MoveData * data, Bool
opaqueMove)
@@ -1642,12 +1646,48 @@ int wMouseMoveWindow(WWindow * wwin, XEvent * ev)
break;
case MotionNotify:
+ if (IS_RESIZABLE(wwin) && wPreferences.window_snapping
&& wPreferences.no_autowrap) {
+ if (moveData.snap == SNAP_LEFT &&
moveData.mouseX > 1) {
+ moveData.snap = SNAP_NONE;
+ drawTransparentFrame(wwin, 0, 0,
scr->scr_width/2, scr->scr_height);
+ }
+ if (moveData.snap == SNAP_RIGHT &&
moveData.mouseX < scr->scr_width - 2) {
+ moveData.snap = SNAP_NONE;
+ drawTransparentFrame(wwin,
scr->scr_width/2, 0, scr->scr_width/2,
+scr->scr_height);
+ }
+ if (moveData.snap == SNAP_NONE) {
+ if (moveData.mouseX <= 1) {
+ moveData.snap = SNAP_LEFT;
+ drawTransparentFrame(wwin, 0,
0, scr->scr_width/2,
+
scr->scr_height);
+ }
+ if (moveData.mouseX >= scr->scr_width -
2) {
+ moveData.snap = SNAP_RIGHT;
+ drawTransparentFrame(wwin,
scr->scr_width/2, 0, scr->scr_width/2,
+
scr->scr_height);
+ }
+ }
+ }
+
if (started) {
+ if (moveData.snap == SNAP_LEFT)
+ drawTransparentFrame(wwin, 0, 0,
scr->scr_width/2, scr->scr_height);
+ if (moveData.snap == SNAP_RIGHT)
+ drawTransparentFrame(wwin,
scr->scr_width/2, 0, scr->scr_width/2,
+
[PATCH 7/8] wmbattery: Remove config.h.in; automatically generated by autotools.
--- wmbattery/config.h.in | 9 - 1 file changed, 9 deletions(-) delete mode 100644 wmbattery/config.h.in diff --git a/wmbattery/config.h.in b/wmbattery/config.h.in deleted file mode 100644 index dd5a6b3..000 --- a/wmbattery/config.h.in +++ /dev/null @@ -1,9 +0,0 @@ -#ifndef CONFIG_H -#define CONFIG_H - -/* What system header files can I use? */ -#undef HAVE_GETOPT_H -#undef HAVE_SYS_FILE_H -#undef HAVE_SYS_IOCTL_H - -#endif -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.6-17-g416f5986
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project wmaker-crm.git.
The branch, next has been updated
via 416f5986856040881f4fef59c1170833f049e37f (commit)
via 1f905694f3417c7d4ac62495c6ca042970c20b2a (commit)
from 7c5277527d95d0bfad43798a6880a6344909af91 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://repo.or.cz/w/wmaker-crm.git/commit/416f5986856040881f4fef59c1170833f049e37f
commit 416f5986856040881f4fef59c1170833f049e37f
Author: David Maciejak
Date: Fri Sep 19 11:47:36 2014 +0700
util: create custom GNUSTEP dir if needed
This patch is creating the missing custom GNUSTEP dir.
Patch found on vinelinux.org as WindowMaker-0.95.6-GSDIR.patch.
diff --git a/util/wmaker.inst.in b/util/wmaker.inst.in
index 632c112c..ad2a9a84 100644
--- a/util/wmaker.inst.in
+++ b/util/wmaker.inst.in
@@ -111,8 +111,12 @@ if test "x$GNUSTEP_USER_ROOT" = "x"; then
else
GSDIR="$GNUSTEP_USER_ROOT"
if [ ! -d "$GSDIR" ]; then
+ # in this case, and in this case only, mkdir needs -p option
+ mkdir -p $GSDIR || {
echo "Directory specified in GNUSTEP_USER_ROOT environment
variable does not exist"
exit 1
+ }
+ chmod +rwx $GSDIR || exit 1
fi
cd "$GSDIR"
cd ..
http://repo.or.cz/w/wmaker-crm.git/commit/1f905694f3417c7d4ac62495c6ca042970c20b2a
commit 1f905694f3417c7d4ac62495c6ca042970c20b2a
Author: David Maciejak
Date: Fri Sep 19 11:51:08 2014 +0700
wmaker: add clip mouse wheel action to change workspace
This patch is adding mouse wheel action on clip to switch from
one workspace to another. It's a modified version of the vinelinux.org
(WindowMaker-0.95.6-wheel.diff) which was setting the action on the entire
dock.
diff --git a/src/dock.c b/src/dock.c
index e8372807..21f34ad6 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -4020,6 +4020,10 @@ static void iconMouseDown(WObjDescriptor *desc, XEvent
*event)
if (!btn->launching && (!btn->running || (event->xbutton.state
& ControlMask)))
launchDockedApplication(btn, True);
+ } else if (event->xbutton.button == Button4 && dock->type == WM_CLIP) {
+ wWorkspaceRelativeChange(scr, 1);
+ } else if (event->xbutton.button == Button5 && dock->type == WM_CLIP) {
+ wWorkspaceRelativeChange(scr, -1);
}
}
---
Summary of changes:
src/dock.c |4
util/wmaker.inst.in |4
2 files changed, 8 insertions(+), 0 deletions(-)
repo.or.cz automatic notification. Contact project admin crma...@gmail.com
if you want to unsubscribe, or site admin ad...@repo.or.cz if you receive
no reply.
--
wmaker-crm.git ("The Window Maker window manager")
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 6/8] wmbattery: Avoid uninitialized variable warning.
Move assignment of old_status until after cur_info is initialized in
wmbattery.c.
---
wmbattery/wmbattery.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/wmbattery/wmbattery.c b/wmbattery/wmbattery.c
index 91b98b8..fe219b6 100644
--- a/wmbattery/wmbattery.c
+++ b/wmbattery/wmbattery.c
@@ -528,7 +528,6 @@ void alarmhandler(int sig) {
apm_info cur_info;
int old_status;
- old_status = cur_info.battery_status;
#ifdef UPOWER
if (use_upower) {
if (upower_read(1, &cur_info) != 0)
@@ -555,7 +554,9 @@ void alarmhandler(int sig) {
if (sonypi_read(&cur_info) != 0)
error("Cannot read sonypi information.");
}
-
+
+ old_status = cur_info.battery_status;
+
/* Always calculate remaining lifetime? apm and acpi both use a
* negative number here to indicate error, missing battery, or
* cannot determine time. */
--
1.9.1
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 5/8] wmbattery: Escape hyphen in manpage.
--- wmbattery/wmbattery.1x | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wmbattery/wmbattery.1x b/wmbattery/wmbattery.1x index c2bb88c..614376a 100644 --- a/wmbattery/wmbattery.1x +++ b/wmbattery/wmbattery.1x @@ -98,7 +98,7 @@ estimation code even if some other estimate is available. .TP .B \-s granularity Ignore fluctuations less than the specified granularity percent when -estimating time. (Implies -e) +estimating time. (Implies \-e) .TP .B \-a file.au Play the specified au file (by sending it to /dev/audio) when the battery -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 8/8] wmbattery: Add to webpage database.
Based on https://web.archive.org/web/20121031045139/http://dockapps.windowmaker.org/file.php/id/34. --- dockapps.db.in | 7 +++ 1 file changed, 7 insertions(+) diff --git a/dockapps.db.in b/dockapps.db.in index 700e83e..3558653 100644 --- a/dockapps.db.in +++ b/dockapps.db.in @@ -68,6 +68,13 @@ url = dockapps = 216 category = System Monitoring +[wmbattery] +image = wmbattery.gif +description = "Wmbattery displays the status of your laptop's battery in a small icon. This includes if it is plugged in, if the battery is charging, how many minutes of battery life remain, battery life remaining (with both a percentage and a graph), and battery status (high - green, low - yellow, or critical - red)." +url = http://joeyh.name/code/wmbattery/ +dockapps = 34 +category = System Monitoring + [wmbiff] image = wmbiff.jpg description = "WMBiff is an WindowMaker docking utility, that displays the number of read -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 4/8] wmbattery: Remove unnecessary .gitattributes file.
The only attributes given were to debian/changelog, which no longer exists. --- wmbattery/.gitattributes | 1 - 1 file changed, 1 deletion(-) delete mode 100644 wmbattery/.gitattributes diff --git a/wmbattery/.gitattributes b/wmbattery/.gitattributes deleted file mode 100644 index 5d42584..000 --- a/wmbattery/.gitattributes +++ /dev/null @@ -1 +0,0 @@ -debian/changelog merge=dpkg-mergechangelogs -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 3/8] wmbattery: Add ChangeLog (renamed from debian/changelog).
Since wmbattery was previously a Debian native package, all the changes were documented in debian/changelog. Since the debian directory has been removed in the upstream source, this file is being renamed to ChangeLog in the root directory. --- wmbattery/ChangeLog | 546 1 file changed, 546 insertions(+) create mode 100644 wmbattery/ChangeLog diff --git a/wmbattery/ChangeLog b/wmbattery/ChangeLog new file mode 100644 index 000..eac1b89 --- /dev/null +++ b/wmbattery/ChangeLog @@ -0,0 +1,546 @@ +wmbattery (2.44) unstable; urgency=medium + + * Better AC detection. + * Support times with upower and acpi (Closes: #740885). + * Use the latest upower API (Closes: #748935). + * Fix upower detection. + + -- Andrew Shadura Fri, 18 Jul 2014 01:14:49 +0200 + +wmbattery (2.43) unstable; urgency=low + + * Orphaned the package. It will probably be removed as it does not work with +current kernels. + * Added -i to display as icon. Thanks, Tovar Closes: #732398 + + -- Joey Hess Tue, 27 May 2014 16:01:34 -0400 + +wmbattery (2.42) unstable; urgency=medium + + * Stop building with flash-in-the-pan HAL. Instead update acpi +interface to use /sys/class/power_supply. +Note that this needs acpica_version 20011018. +Closes: #613166 +(Patch developed by Andrew Shadura.) + * Also added support for upower, which is used by default, +to avoid chasing kernel sysfs changes. +(Patch developed by Andrew Shadura.) +Closes: #727102 + + -- Joey Hess Thu, 05 Dec 2013 15:29:41 -0400 + +wmbattery (2.41) unstable; urgency=low + + * Accumulated packaging modernizations. Closes: #666370 + + -- Joey Hess Fri, 30 Mar 2012 10:20:17 -0400 + +wmbattery (2.40) unstable; urgency=low + + * Add -s option which can be used to ignore fluctuations +in reported battery charge (as seen on the EeePC) when +using -e. Closes: #527870 (Joseph Huang) + + -- Joey Hess Sat, 09 May 2009 16:53:10 -0400 + +wmbattery (2.39) unstable; urgency=low + + * Use debhelper v7; rules file minimisation. + * Depend on hal since /proc/acpi is gone from the default kernels now. +Closes: #491099 + + -- Joey Hess Tue, 22 Jul 2008 00:23:47 -0400 + +wmbattery (2.38) unstable; urgency=low + + * Magic header file reordering to work around the disgusting +linux-libc-dev/libc headers conflicts (#435700). Closes: #463811 + + -- Joey Hess Wed, 27 Feb 2008 15:08:53 -0500 + +wmbattery (2.37) unstable; urgency=low + + * Support reconnecting to dbus if it's restarted. (AKA giant dbus-PITA) + + -- Joey Hess Wed, 20 Feb 2008 22:44:00 -0500 + +wmbattery (2.36) unstable; urgency=low + + * Support reconnecting to hal if the connection is closed, as happens +if the hal is restarted. + + -- Joey Hess Wed, 20 Feb 2008 22:29:00 -0500 + +wmbattery (2.35) unstable; urgency=low + + * Don't spew error messages if optional hal properties are not available. + * Only check to see if a battery is charging if hal reports there is AC +power. This is perhaps not 100% correct in systems with multiple batteries +that may cross-charge when off AC, but it's faster and it avoids bugs in +hal (#463740). + + -- Joey Hess Sat, 02 Feb 2008 17:28:37 -0500 + +wmbattery (2.34) unstable; urgency=low + + * Bit the bullet, stopped trying to track the kernel's ever changing +interfaces, and added support for querying battery information from hal. +Support for the old kernel interfaces (APM, ACPI, etc) is still present, +but to use new interfaces such 2.6.24's /sys/class/power_adapter, you'll +have to have dbus and hal. +Closes: #456247, #246641, #290712, #393616, #456248 + * Fix -e option. + + -- Joey Hess Fri, 01 Feb 2008 21:36:39 -0500 + +wmbattery (2.33) unstable; urgency=low + + * Correct issue with the statically allocated string returned by +get_acpi_value that caused it to only look at last full capacity and never +really at design capacity. + + -- Joey Hess Sat, 22 Dec 2007 22:26:38 -0500 + +wmbattery (2.32) unstable; urgency=low + + * Guard some divisions against division by zero. I've never seen that +happen and can't reproduce it, but see #454766. + * Merge acpi change from procmeter3: Limit string length when reading from +/proc/. + + -- Joey Hess Fri, 07 Dec 2007 14:56:41 -0500 + +wmbattery (2.31) unstable; urgency=low + + * Further fix for my strange battery. If the present capacity is larger +than the maximum capacity, rescan to figure out the new max capacity. + + -- Joey Hess Sun, 02 Dec 2007 15:50:29 -0500 + +wmbattery (2.30) unstable; urgency=low + + * My new battery has a design capacity of 7800 mAh and yet its +last full capacity was 9488, and its currently charged to 8540. +Deal with this wonderful miracle^W^Wcrap hardware by taking the max +of the design or last full capacities. + + -- Joey Hess Tue, 23 Oct 2007 22:21:06 -0400 + +wmbattery (2.29) unstable; urgency=low + + * Update to
[PATCH 2/8] wmbattery: Remove debian directory.
wmbattery was previously a Debian native package. The debian directory should no longer be included in the upstream source. --- wmbattery/debian/changelog | 546 - wmbattery/debian/compat| 1 - wmbattery/debian/control | 24 -- wmbattery/debian/copyright | 12 - wmbattery/debian/docs | 2 - wmbattery/debian/menu | 2 - wmbattery/debian/rules | 11 - 7 files changed, 598 deletions(-) delete mode 100644 wmbattery/debian/changelog delete mode 100644 wmbattery/debian/compat delete mode 100644 wmbattery/debian/control delete mode 100644 wmbattery/debian/copyright delete mode 100644 wmbattery/debian/docs delete mode 100644 wmbattery/debian/menu delete mode 100755 wmbattery/debian/rules diff --git a/wmbattery/debian/changelog b/wmbattery/debian/changelog deleted file mode 100644 index eac1b89..000 --- a/wmbattery/debian/changelog +++ /dev/null @@ -1,546 +0,0 @@ -wmbattery (2.44) unstable; urgency=medium - - * Better AC detection. - * Support times with upower and acpi (Closes: #740885). - * Use the latest upower API (Closes: #748935). - * Fix upower detection. - - -- Andrew Shadura Fri, 18 Jul 2014 01:14:49 +0200 - -wmbattery (2.43) unstable; urgency=low - - * Orphaned the package. It will probably be removed as it does not work with -current kernels. - * Added -i to display as icon. Thanks, Tovar Closes: #732398 - - -- Joey Hess Tue, 27 May 2014 16:01:34 -0400 - -wmbattery (2.42) unstable; urgency=medium - - * Stop building with flash-in-the-pan HAL. Instead update acpi -interface to use /sys/class/power_supply. -Note that this needs acpica_version 20011018. -Closes: #613166 -(Patch developed by Andrew Shadura.) - * Also added support for upower, which is used by default, -to avoid chasing kernel sysfs changes. -(Patch developed by Andrew Shadura.) -Closes: #727102 - - -- Joey Hess Thu, 05 Dec 2013 15:29:41 -0400 - -wmbattery (2.41) unstable; urgency=low - - * Accumulated packaging modernizations. Closes: #666370 - - -- Joey Hess Fri, 30 Mar 2012 10:20:17 -0400 - -wmbattery (2.40) unstable; urgency=low - - * Add -s option which can be used to ignore fluctuations -in reported battery charge (as seen on the EeePC) when -using -e. Closes: #527870 (Joseph Huang) - - -- Joey Hess Sat, 09 May 2009 16:53:10 -0400 - -wmbattery (2.39) unstable; urgency=low - - * Use debhelper v7; rules file minimisation. - * Depend on hal since /proc/acpi is gone from the default kernels now. -Closes: #491099 - - -- Joey Hess Tue, 22 Jul 2008 00:23:47 -0400 - -wmbattery (2.38) unstable; urgency=low - - * Magic header file reordering to work around the disgusting -linux-libc-dev/libc headers conflicts (#435700). Closes: #463811 - - -- Joey Hess Wed, 27 Feb 2008 15:08:53 -0500 - -wmbattery (2.37) unstable; urgency=low - - * Support reconnecting to dbus if it's restarted. (AKA giant dbus-PITA) - - -- Joey Hess Wed, 20 Feb 2008 22:44:00 -0500 - -wmbattery (2.36) unstable; urgency=low - - * Support reconnecting to hal if the connection is closed, as happens -if the hal is restarted. - - -- Joey Hess Wed, 20 Feb 2008 22:29:00 -0500 - -wmbattery (2.35) unstable; urgency=low - - * Don't spew error messages if optional hal properties are not available. - * Only check to see if a battery is charging if hal reports there is AC -power. This is perhaps not 100% correct in systems with multiple batteries -that may cross-charge when off AC, but it's faster and it avoids bugs in -hal (#463740). - - -- Joey Hess Sat, 02 Feb 2008 17:28:37 -0500 - -wmbattery (2.34) unstable; urgency=low - - * Bit the bullet, stopped trying to track the kernel's ever changing -interfaces, and added support for querying battery information from hal. -Support for the old kernel interfaces (APM, ACPI, etc) is still present, -but to use new interfaces such 2.6.24's /sys/class/power_adapter, you'll -have to have dbus and hal. -Closes: #456247, #246641, #290712, #393616, #456248 - * Fix -e option. - - -- Joey Hess Fri, 01 Feb 2008 21:36:39 -0500 - -wmbattery (2.33) unstable; urgency=low - - * Correct issue with the statically allocated string returned by -get_acpi_value that caused it to only look at last full capacity and never -really at design capacity. - - -- Joey Hess Sat, 22 Dec 2007 22:26:38 -0500 - -wmbattery (2.32) unstable; urgency=low - - * Guard some divisions against division by zero. I've never seen that -happen and can't reproduce it, but see #454766. - * Merge acpi change from procmeter3: Limit string length when reading from -/proc/. - - -- Joey Hess Fri, 07 Dec 2007 14:56:41 -0500 - -wmbattery (2.31) unstable; urgency=low - - * Further fix for my strange battery. If the present capacity is larger -than the maximum capacity, rescan to figure out the new max capacity. - - -- Joey Hess Sun, 02 Dec 2007 15:50:29 -0500 - -wmbatte
[PATCH 1/8] wmbattery: Add to repository.
Version 2.44. Source obtained from: http://ftp.de.debian.org/debian/pool/main/w/wmbattery/wmbattery_2.44.tar.gz --- wmbattery/.gitattributes | 1 + wmbattery/GPL | 340 + wmbattery/INSTALL | 195 wmbattery/Makefile | 52 wmbattery/README | 41 +++ wmbattery/TODO | 11 + wmbattery/acpi.c | 445 wmbattery/acpi.h | 67 + wmbattery/apm.h| 27 ++ wmbattery/autoconf/install-sh | 250 wmbattery/autoconf/makeinfo.in | 21 ++ wmbattery/battery_blink.xpm| 19 ++ wmbattery/battery_high.xpm | 19 ++ wmbattery/battery_low.xpm | 20 ++ wmbattery/battery_medium.xpm | 20 ++ wmbattery/battery_none.xpm | 18 ++ wmbattery/bigfont.xpm | 17 ++ wmbattery/charging.xpm | 19 ++ wmbattery/config.h.in | 9 + wmbattery/configure.ac | 44 +++ wmbattery/debian/changelog | 546 ++ wmbattery/debian/compat| 1 + wmbattery/debian/control | 24 ++ wmbattery/debian/copyright | 12 + wmbattery/debian/docs | 2 + wmbattery/debian/menu | 2 + wmbattery/debian/rules | 11 + wmbattery/dial_bright.xpm | 43 +++ wmbattery/dial_dim.xpm | 43 +++ wmbattery/face.xpm | 74 + wmbattery/mask.xbm | 46 +++ wmbattery/nocharging.xpm | 18 ++ wmbattery/plugged.xpm | 17 ++ wmbattery/simplehal.c | 223 ++ wmbattery/simplehal.h | 2 + wmbattery/smallfont.xpm| 16 + wmbattery/sonypi.c | 74 + wmbattery/sonypi.h | 19 ++ wmbattery/unplugged.xpm| 17 ++ wmbattery/upower.c | 151 ++ wmbattery/upower.h | 2 + wmbattery/wmbattery.1x | 110 +++ wmbattery/wmbattery.c | 653 + wmbattery/wmbattery.h | 70 + 44 files changed, 3811 insertions(+) create mode 100644 wmbattery/.gitattributes create mode 100644 wmbattery/GPL create mode 100644 wmbattery/INSTALL create mode 100644 wmbattery/Makefile create mode 100644 wmbattery/README create mode 100644 wmbattery/TODO create mode 100644 wmbattery/acpi.c create mode 100644 wmbattery/acpi.h create mode 100644 wmbattery/apm.h create mode 100755 wmbattery/autoconf/install-sh create mode 100644 wmbattery/autoconf/makeinfo.in create mode 100644 wmbattery/battery_blink.xpm create mode 100644 wmbattery/battery_high.xpm create mode 100644 wmbattery/battery_low.xpm create mode 100644 wmbattery/battery_medium.xpm create mode 100644 wmbattery/battery_none.xpm create mode 100644 wmbattery/bigfont.xpm create mode 100644 wmbattery/charging.xpm create mode 100644 wmbattery/config.h.in create mode 100644 wmbattery/configure.ac create mode 100644 wmbattery/debian/changelog create mode 100644 wmbattery/debian/compat create mode 100644 wmbattery/debian/control create mode 100644 wmbattery/debian/copyright create mode 100644 wmbattery/debian/docs create mode 100644 wmbattery/debian/menu create mode 100755 wmbattery/debian/rules create mode 100644 wmbattery/dial_bright.xpm create mode 100644 wmbattery/dial_dim.xpm create mode 100644 wmbattery/face.xpm create mode 100644 wmbattery/mask.xbm create mode 100644 wmbattery/nocharging.xpm create mode 100644 wmbattery/plugged.xpm create mode 100644 wmbattery/simplehal.c create mode 100644 wmbattery/simplehal.h create mode 100644 wmbattery/smallfont.xpm create mode 100644 wmbattery/sonypi.c create mode 100644 wmbattery/sonypi.h create mode 100644 wmbattery/unplugged.xpm create mode 100644 wmbattery/upower.c create mode 100644 wmbattery/upower.h create mode 100644 wmbattery/wmbattery.1x create mode 100644 wmbattery/wmbattery.c create mode 100644 wmbattery/wmbattery.h diff --git a/wmbattery/.gitattributes b/wmbattery/.gitattributes new file mode 100644 index 000..5d42584 --- /dev/null +++ b/wmbattery/.gitattributes @@ -0,0 +1 @@ +debian/changelog merge=dpkg-mergechangelogs diff --git a/wmbattery/GPL b/wmbattery/GPL new file mode 100644 index 000..b7b5f53 --- /dev/null +++ b/wmbattery/GPL @@ -0,0 +1,340 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users
[PATCH 0/8] Add wmbattery to dockapps repository.
I am currently adopting wmbattery in Debian. It was recently orphaned by its upstream author. Therefore, I am adding it to the dockapps git repository, along with several patches. Carlos, if these patches are accepted, could the first patch be tagged wmbattery-2.44? Thanks! Doug Torrance (8): wmbattery: Add to repository. wmbattery: Remove debian directory. wmbattery: Add ChangeLog (renamed from debian/changelog). wmbattery: Remove unnecessary .gitattributes file. wmbattery: Escape hyphen in manpage. wmbattery: Avoid uninitialized variable warning. wmbattery: Remove config.h.in; automatically generated by autotools. wmbattery: Add to webpage database. dockapps.db.in | 7 + wmbattery/ChangeLog| 546 ++ wmbattery/GPL | 340 + wmbattery/INSTALL | 195 wmbattery/Makefile | 52 wmbattery/README | 41 +++ wmbattery/TODO | 11 + wmbattery/acpi.c | 445 wmbattery/acpi.h | 67 + wmbattery/apm.h| 27 ++ wmbattery/autoconf/install-sh | 250 wmbattery/autoconf/makeinfo.in | 21 ++ wmbattery/battery_blink.xpm| 19 ++ wmbattery/battery_high.xpm | 19 ++ wmbattery/battery_low.xpm | 20 ++ wmbattery/battery_medium.xpm | 20 ++ wmbattery/battery_none.xpm | 18 ++ wmbattery/bigfont.xpm | 17 ++ wmbattery/charging.xpm | 19 ++ wmbattery/configure.ac | 44 +++ wmbattery/dial_bright.xpm | 43 +++ wmbattery/dial_dim.xpm | 43 +++ wmbattery/face.xpm | 74 + wmbattery/mask.xbm | 46 +++ wmbattery/nocharging.xpm | 18 ++ wmbattery/plugged.xpm | 17 ++ wmbattery/simplehal.c | 223 ++ wmbattery/simplehal.h | 2 + wmbattery/smallfont.xpm| 16 + wmbattery/sonypi.c | 74 + wmbattery/sonypi.h | 19 ++ wmbattery/unplugged.xpm| 17 ++ wmbattery/upower.c | 151 ++ wmbattery/upower.h | 2 + wmbattery/wmbattery.1x | 110 +++ wmbattery/wmbattery.c | 654 + wmbattery/wmbattery.h | 70 + 37 files changed, 3757 insertions(+) create mode 100644 wmbattery/ChangeLog create mode 100644 wmbattery/GPL create mode 100644 wmbattery/INSTALL create mode 100644 wmbattery/Makefile create mode 100644 wmbattery/README create mode 100644 wmbattery/TODO create mode 100644 wmbattery/acpi.c create mode 100644 wmbattery/acpi.h create mode 100644 wmbattery/apm.h create mode 100755 wmbattery/autoconf/install-sh create mode 100644 wmbattery/autoconf/makeinfo.in create mode 100644 wmbattery/battery_blink.xpm create mode 100644 wmbattery/battery_high.xpm create mode 100644 wmbattery/battery_low.xpm create mode 100644 wmbattery/battery_medium.xpm create mode 100644 wmbattery/battery_none.xpm create mode 100644 wmbattery/bigfont.xpm create mode 100644 wmbattery/charging.xpm create mode 100644 wmbattery/configure.ac create mode 100644 wmbattery/dial_bright.xpm create mode 100644 wmbattery/dial_dim.xpm create mode 100644 wmbattery/face.xpm create mode 100644 wmbattery/mask.xbm create mode 100644 wmbattery/nocharging.xpm create mode 100644 wmbattery/plugged.xpm create mode 100644 wmbattery/simplehal.c create mode 100644 wmbattery/simplehal.h create mode 100644 wmbattery/smallfont.xpm create mode 100644 wmbattery/sonypi.c create mode 100644 wmbattery/sonypi.h create mode 100644 wmbattery/unplugged.xpm create mode 100644 wmbattery/upower.c create mode 100644 wmbattery/upower.h create mode 100644 wmbattery/wmbattery.1x create mode 100644 wmbattery/wmbattery.c create mode 100644 wmbattery/wmbattery.h -- 1.9.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sunday, September 21, 2014, Yury Tarasievich wrote: > On 09/20/2014 09:49 PM, Carlos R. Mafra wrote: > >> On Sat, 20 Sep 2014 at 21:35:29 +0300, Yury Tarasievich wrote: >> >>> On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: >>> On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: > I got confused -- will Alt+Tab retain its current rules of window > shuffling, or not? > Yes, the patch was already reverted. >>> >>> ...which was the only reasonable way out, after all. Thanks! >>> >> >> It is not the only way out, though. We can make the behaviour >> follow a config option. >> > > Quite so. I meant not having the expected behaviour suddenly changed. > > Yury > > Interesting thread, I will dig into it later to try to bring both solutions. Still have to finish the big patch I am currently working on which is providing visual workspace switching window.
Re: [PATCH 1/5] wmaker: fix focused window list order
On 09/20/2014 09:49 PM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 21:35:29 +0300, Yury Tarasievich wrote: On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yes, the patch was already reverted. ...which was the only reasonable way out, after all. Thanks! It is not the only way out, though. We can make the behaviour follow a config option. Quite so. I meant not having the expected behaviour suddenly changed. Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 21:35:29 +0300, Yury Tarasievich wrote: > On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: > >On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: > >>I got confused -- will Alt+Tab retain its current rules of window > >>shuffling, or not? > > > >Yes, the patch was already reverted. > > ...which was the only reasonable way out, after all. Thanks! It is not the only way out, though. We can make the behaviour follow a config option. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On 09/20/2014 09:24 PM, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yes, the patch was already reverted. ...which was the only reasonable way out, after all. Thanks! Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote: > I got confused -- will Alt+Tab retain its current rules of window > shuffling, or not? Yes, the patch was already reverted. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
I got confused -- will Alt+Tab retain its current rules of window shuffling, or not? Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 18:07:34 +0100
"Carlos R. Mafra" wrote:
> On Sat, 20 Sep 2014 at 18:02:36 +0200, BALATON Zoltan wrote:
> > On Sat, 20 Sep 2014, Carlos R. Mafra wrote:
> > >On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote:
> > >>On Sat, 20 Sep 2014 17:04:02 +0800
> > >>David Maciejak wrote:
> > >>
> > >>>That is the behaviour i have without the patch (and that's why i
> > >>>called it mixed up windows list):
> > >>>
> > >>>1 has focus
> > >>>alt-tab (next window) show
> > >>>1 [2] 3
> > >>>2 has focus
> > >>>alt-tab show
> > >>>2 [1] 3
> > >>>1 has focus
> > >>>alt-tab show
> > >>>1 [2] 3
> > >>>press another alt-tab, select 3
> > >>>1 2 [3]
> > >>>3 has focus
> > >>>alt-tab show
> > >>>3 [1] 2
> > >>>another alt-tab to 2, show
> > >>>3 1 [2]
> > >>>2 has focus
> > >>>alt-tab show
> > >>>2 [3] 1
> > >>>
> > >>>To do that i just configured the "Focus next window" in WPrefs to
> > >>>alt-tab. But as said that behaviour is sounding more like move
> > >>>focus back to previous focused window.
> > >>>
> > A, B, [C], D
> > now I alt-tab again and with this patch it goes to D
> > A, B, C, [D]
> > >>>
> > >>>yes that was what i was expecting from "Focus next window"
> > >>>
> > [A], B, C, D
> > I 'alt-tab' and while keeping alt down, I 'tab' more and end up
> > on let's say C
> > A, B, [C], D
> > with old behaviour I am back on A
> > [A], B, C, D
> > >>>
> > >>>That's focus on previous focused window.
> > >>>I can understand that feature is useful but not really expected.
> > >>
> > >>I've checked some other operating systems and OS X and Windows XP
> > >>(both using switchpanels) bring application you change to, to the
> > >>front of the window list. I would say it makes a lot of sense in
> > >>keyboard driven windows management. People usually work with few
> > >>applications and want to change between them instantly, without
> > >>going through a whole list (especially if they have a lot of
> > >>windows open), so it makes a lot of sense to keep recently used
> > >>ones closer on list.
> > >>
> > >>Imagine for example:
> > >>webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm,
> > >>xterm with task being: copying stuff from webbrowser to mailapp.
> > >>With your patch you would need each time focus on where your
> > >>browser and mailapp are and go through all those xterms when
> > >>changing windows, instead of instantly changing between them.
> > >
> > >Precisely! What David wants to fix is actually more of a semantic
> > >problem. In practice, the current behaviour is much more desirable
> > >for the reason you pointed out.
> > >
> > >And quite frankly, we cannot change such a behaviour right now.
> > >Long-time wmaker users will just be annoyed, and they are wmaker's
> > >biggest asset.
> > >
> > >>But yes, I've checked and I confirm that it doesn't work too well
> > >>with mouse bindings ("Next Window" keeps changing just between
> > >>two windows, instead of going through list) which, as I
> > >>understand is the way you want to use it.
> > >
> > >I think the way out is to introduce an option to select between
> > >David's and the current behaviour. Something along the lines
> > >of "Strict focus next behaviour" with default off and many
> > >comments about it being useful for the mouse bindings (perhaps
> > >in balloon texts).
> >
> > I remember there used to be an option called something like Windoze
> > cycling in expert prefs but I can't find it any more. Maybe it was
> > removed previously in one of the "clean up" patches. I've tried to
> > find it in history but could not, maybe you have better luck finding
> > it.
>
> I'm not sure what's the WindozeCycling option would imply the
> behaviour that David wants though.
>
> But apparently it's long gone from WPrefs, since
>
> git log -SWindozeCycling -p WPrefs.app/
>
> returns the following patch from 2004:
>
> commit 6cd91272a692f235aa6c8e5e7c57900a603fc963
> Author: kojima
> Date: Tue Oct 19 02:37:58 2004 +
>
> fixed a bug with workspace switching
>
I knew this talk seemed bit familiar, there was report of wanting
behaviour implemented by David a while back:
http://lists.windowmaker.org/user/msg00377.html
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 18:02:36 +0200, BALATON Zoltan wrote:
> On Sat, 20 Sep 2014, Carlos R. Mafra wrote:
> >On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote:
> >>On Sat, 20 Sep 2014 17:04:02 +0800
> >>David Maciejak wrote:
> >>
> >>>That is the behaviour i have without the patch (and that's why i
> >>>called it mixed up windows list):
> >>>
> >>>1 has focus
> >>>alt-tab (next window) show
> >>>1 [2] 3
> >>>2 has focus
> >>>alt-tab show
> >>>2 [1] 3
> >>>1 has focus
> >>>alt-tab show
> >>>1 [2] 3
> >>>press another alt-tab, select 3
> >>>1 2 [3]
> >>>3 has focus
> >>>alt-tab show
> >>>3 [1] 2
> >>>another alt-tab to 2, show
> >>>3 1 [2]
> >>>2 has focus
> >>>alt-tab show
> >>>2 [3] 1
> >>>
> >>>To do that i just configured the "Focus next window" in WPrefs to
> >>>alt-tab. But as said that behaviour is sounding more like move focus
> >>>back to previous focused window.
> >>>
> A, B, [C], D
> now I alt-tab again and with this patch it goes to D
> A, B, C, [D]
> >>>
> >>>yes that was what i was expecting from "Focus next window"
> >>>
> [A], B, C, D
> I 'alt-tab' and while keeping alt down, I 'tab' more and end up on
> let's say C
> A, B, [C], D
> with old behaviour I am back on A
> [A], B, C, D
> >>>
> >>>That's focus on previous focused window.
> >>>I can understand that feature is useful but not really expected.
> >>
> >>I've checked some other operating systems and OS X and Windows XP (both
> >>using switchpanels) bring application you change to, to the front of the
> >>window list. I would say it makes a lot of sense in keyboard driven
> >>windows management. People usually work with few applications and want
> >>to change between them instantly, without going through a whole list
> >>(especially if they have a lot of windows open), so it makes a lot of
> >>sense to keep recently used ones closer on list.
> >>
> >>Imagine for example:
> >>webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm
> >>with task being: copying stuff from webbrowser to mailapp.
> >>With your patch you would need each time focus on where your browser and
> >>mailapp are and go through all those xterms when changing windows,
> >>instead of instantly changing between them.
> >
> >Precisely! What David wants to fix is actually more of a semantic
> >problem. In practice, the current behaviour is much more desirable
> >for the reason you pointed out.
> >
> >And quite frankly, we cannot change such a behaviour right now.
> >Long-time wmaker users will just be annoyed, and they are wmaker's
> >biggest asset.
> >
> >>But yes, I've checked and I confirm that it doesn't work too well with
> >>mouse bindings ("Next Window" keeps changing just between two windows,
> >>instead of going through list) which, as I understand is the way you
> >>want to use it.
> >
> >I think the way out is to introduce an option to select between
> >David's and the current behaviour. Something along the lines
> >of "Strict focus next behaviour" with default off and many
> >comments about it being useful for the mouse bindings (perhaps
> >in balloon texts).
>
> I remember there used to be an option called something like Windoze
> cycling in expert prefs but I can't find it any more. Maybe it was
> removed previously in one of the "clean up" patches. I've tried to
> find it in history but could not, maybe you have better luck finding
> it.
I'm not sure what's the WindozeCycling option would imply the
behaviour that David wants though.
But apparently it's long gone from WPrefs, since
git log -SWindozeCycling -p WPrefs.app/
returns the following patch from 2004:
commit 6cd91272a692f235aa6c8e5e7c57900a603fc963
Author: kojima
Date: Tue Oct 19 02:37:58 2004 +
fixed a bug with workspace switching
diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c
index 3458513..b84fbf1 100644
--- a/WPrefs.app/Expert.c
+++ b/WPrefs.app/Expert.c
@@ -51,11 +51,10 @@ showData(_Panel *panel)
WMSetButtonSelected(panel->swi[1], WMGetUDBoolForKey(udb, "NoXSetStuff"));
WMSetButtonSelected(panel->swi[2], GetBoolForKey("SaveSessionOnExit"));
WMSetButtonSelected(panel->swi[3], GetBoolForKey("UseSaveUnders"));
-WMSetButtonSelected(panel->swi[4], GetBoolForKey("WindozeCycling"));
-WMSetButtonSelected(panel->swi[5], GetBoolForKey("DontConfirmKill"));
-WMSetButtonSelected(panel->swi[6], GetBoolForKey("DisableBlinking"));
+WMSetButtonSelected(panel->swi[4], GetBoolForKey("DontConfirmKill"));
+WMSetButtonSelected(panel->swi[5], GetBoolForKey("DisableBlinking"));
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014, Carlos R. Mafra wrote:
On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote:
On Sat, 20 Sep 2014 17:04:02 +0800
David Maciejak wrote:
That is the behaviour i have without the patch (and that's why i
called it mixed up windows list):
1 has focus
alt-tab (next window) show
1 [2] 3
2 has focus
alt-tab show
2 [1] 3
1 has focus
alt-tab show
1 [2] 3
press another alt-tab, select 3
1 2 [3]
3 has focus
alt-tab show
3 [1] 2
another alt-tab to 2, show
3 1 [2]
2 has focus
alt-tab show
2 [3] 1
To do that i just configured the "Focus next window" in WPrefs to
alt-tab. But as said that behaviour is sounding more like move focus
back to previous focused window.
A, B, [C], D
now I alt-tab again and with this patch it goes to D
A, B, C, [D]
yes that was what i was expecting from "Focus next window"
[A], B, C, D
I 'alt-tab' and while keeping alt down, I 'tab' more and end up on
let's say C
A, B, [C], D
with old behaviour I am back on A
[A], B, C, D
That's focus on previous focused window.
I can understand that feature is useful but not really expected.
I've checked some other operating systems and OS X and Windows XP (both
using switchpanels) bring application you change to, to the front of the
window list. I would say it makes a lot of sense in keyboard driven
windows management. People usually work with few applications and want
to change between them instantly, without going through a whole list
(especially if they have a lot of windows open), so it makes a lot of
sense to keep recently used ones closer on list.
Imagine for example:
webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm
with task being: copying stuff from webbrowser to mailapp.
With your patch you would need each time focus on where your browser and
mailapp are and go through all those xterms when changing windows,
instead of instantly changing between them.
Precisely! What David wants to fix is actually more of a semantic
problem. In practice, the current behaviour is much more desirable
for the reason you pointed out.
And quite frankly, we cannot change such a behaviour right now.
Long-time wmaker users will just be annoyed, and they are wmaker's
biggest asset.
But yes, I've checked and I confirm that it doesn't work too well with
mouse bindings ("Next Window" keeps changing just between two windows,
instead of going through list) which, as I understand is the way you
want to use it.
I think the way out is to introduce an option to select between
David's and the current behaviour. Something along the lines
of "Strict focus next behaviour" with default off and many
comments about it being useful for the mouse bindings (perhaps
in balloon texts).
I remember there used to be an option called something like Windoze
cycling in expert prefs but I can't find it any more. Maybe it was removed
previously in one of the "clean up" patches. I've tried to find it in
history but could not, maybe you have better luck finding it.
Regards,
BALATON Zoltan
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote:
> On Sat, 20 Sep 2014 17:04:02 +0800
> David Maciejak wrote:
>
> > That is the behaviour i have without the patch (and that's why i
> > called it mixed up windows list):
> >
> > 1 has focus
> > alt-tab (next window) show
> > 1 [2] 3
> > 2 has focus
> > alt-tab show
> > 2 [1] 3
> > 1 has focus
> > alt-tab show
> > 1 [2] 3
> > press another alt-tab, select 3
> > 1 2 [3]
> > 3 has focus
> > alt-tab show
> > 3 [1] 2
> > another alt-tab to 2, show
> > 3 1 [2]
> > 2 has focus
> > alt-tab show
> > 2 [3] 1
> >
> > To do that i just configured the "Focus next window" in WPrefs to
> > alt-tab. But as said that behaviour is sounding more like move focus
> > back to previous focused window.
> >
> > > A, B, [C], D
> > > now I alt-tab again and with this patch it goes to D
> > > A, B, C, [D]
> >
> > yes that was what i was expecting from "Focus next window"
> >
> > > [A], B, C, D
> > > I 'alt-tab' and while keeping alt down, I 'tab' more and end up on
> > > let's say C
> > > A, B, [C], D
> > > with old behaviour I am back on A
> > > [A], B, C, D
> >
> > That's focus on previous focused window.
> > I can understand that feature is useful but not really expected.
>
> I've checked some other operating systems and OS X and Windows XP (both
> using switchpanels) bring application you change to, to the front of the
> window list. I would say it makes a lot of sense in keyboard driven
> windows management. People usually work with few applications and want
> to change between them instantly, without going through a whole list
> (especially if they have a lot of windows open), so it makes a lot of
> sense to keep recently used ones closer on list.
>
> Imagine for example:
> webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm
> with task being: copying stuff from webbrowser to mailapp.
> With your patch you would need each time focus on where your browser and
> mailapp are and go through all those xterms when changing windows,
> instead of instantly changing between them.
Precisely! What David wants to fix is actually more of a semantic
problem. In practice, the current behaviour is much more desirable
for the reason you pointed out.
And quite frankly, we cannot change such a behaviour right now.
Long-time wmaker users will just be annoyed, and they are wmaker's
biggest asset.
> But yes, I've checked and I confirm that it doesn't work too well with
> mouse bindings ("Next Window" keeps changing just between two windows,
> instead of going through list) which, as I understand is the way you
> want to use it.
I think the way out is to introduce an option to select between
David's and the current behaviour. Something along the lines
of "Strict focus next behaviour" with default off and many
comments about it being useful for the mouse bindings (perhaps
in balloon texts).
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014 17:04:02 +0800
David Maciejak wrote:
> That is the behaviour i have without the patch (and that's why i
> called it mixed up windows list):
>
> 1 has focus
> alt-tab (next window) show
> 1 [2] 3
> 2 has focus
> alt-tab show
> 2 [1] 3
> 1 has focus
> alt-tab show
> 1 [2] 3
> press another alt-tab, select 3
> 1 2 [3]
> 3 has focus
> alt-tab show
> 3 [1] 2
> another alt-tab to 2, show
> 3 1 [2]
> 2 has focus
> alt-tab show
> 2 [3] 1
>
> To do that i just configured the "Focus next window" in WPrefs to
> alt-tab. But as said that behaviour is sounding more like move focus
> back to previous focused window.
>
> > A, B, [C], D
> > now I alt-tab again and with this patch it goes to D
> > A, B, C, [D]
>
> yes that was what i was expecting from "Focus next window"
>
> > [A], B, C, D
> > I 'alt-tab' and while keeping alt down, I 'tab' more and end up on
> > let's say C
> > A, B, [C], D
> > with old behaviour I am back on A
> > [A], B, C, D
>
> That's focus on previous focused window.
> I can understand that feature is useful but not really expected.
I've checked some other operating systems and OS X and Windows XP (both
using switchpanels) bring application you change to, to the front of the
window list. I would say it makes a lot of sense in keyboard driven
windows management. People usually work with few applications and want
to change between them instantly, without going through a whole list
(especially if they have a lot of windows open), so it makes a lot of
sense to keep recently used ones closer on list.
Imagine for example:
webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm
with task being: copying stuff from webbrowser to mailapp.
With your patch you would need each time focus on where your browser and
mailapp are and go through all those xterms when changing windows,
instead of instantly changing between them.
But yes, I've checked and I confirm that it doesn't work too well with
mouse bindings ("Next Window" keeps changing just between two windows,
instead of going through list) which, as I understand is the way you
want to use it.
>
>
> On Fri, Sep 19, 2014 at 7:39 PM, David Maciejak
> wrote:
> > On Fri, Sep 19, 2014 at 5:24 PM, Carlos R. Mafra
> > wrote:
> >>> On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra
> >>> wrote:
> >>> > On Wed, 17 Sep 2014 at 12:29:57 +0200, Amadeusz Sławiński wrote:
> >>> >> On Thu, 11 Sep 2014 17:50:40 +0800
> >>> >> David Maciejak wrote:
> >>> >>
> >>> >> > This patch is fixing the focused next window list order.
> >>> >> > As now, the switching was only working for 2 windows.
> >>> >> > For example, taking 3 windows called A,B,C.
> >>> >> > If the windows list is A,B,C where A is the current focused
> >>> >> > window. Focusing on B will result on switching position A
> >>> >> > and B, thus C will never be the next window.
> >>> >> > For this example the patch is updating the linked list as
> >>> >> > B,C,A.
> >>> >>
> >>> >>
> >>> >> Hey,
> >>> >>
> >>> >> I think this patch breaks behaviour of Window Maker.
> >>> >>
> >>> >> One thing is that when I change between workspaces it keeps
> >>> >> focusing last created window instead of last used one.
> >>> >>
> >>> >> Other is that it changes focus behaviour, ie, I can't alt-tab
> >>> >> between two windows, now I have to go through whole list to
> >>> >> change between two recently used ones.
> >>> >> For example with windows A, B, C, D (with [A] marking A as
> >>> >> focused) [A], B, C, D
> >>> >> I 'alt-tab' once
> >>> >> A, [B], C, D
> >>> >> I 'alt-tab' once more
> >>> >> A, B, [C], D
> >>> >> where old behaviour would go to:
> >>> >> [A], B, C, D
> >>> >>
> >>> >> I could also choose other window instead of B and I could go
> >>> >> back to A instantly like so
> >>> >> [A], B, C, D
> >>> >> I 'alt-tab' and while keeping alt down, I 'tab' more and end
> >>> >> up on let's say C
> >>> >> A, B, [C], D
> >>> >> now I alt-tab again and with this patch it goes to D
> >>> >> A, B, C, [D]
> >>> >> with old behaviour I am back on A
> >>> >> [A], B, C, D
> >>> >>
> >>> >> I think the old behaviour is more usable.
> >>> >> So I would like to propose reverting this patch
> >>> >
> >>> > Thanks for the detailed description. I also caught
> >>> > myself doing extra Alt+TABs recently because of this.
> >>> >
> >>> > At first I thought it was a good idea when I saw the
> >>> > patch, but the old behaviour is somehow imprinted
> >>> > on my mind.
> >>> >
> >>> > Reverting.
> >>
> >> On Fri, 19 Sep 2014 at 16:57:08 +0800, David Maciejak wrote:
> >>> Reverting the patch will kill the mouse action of switching on
> >>> next window.
> >>
> >> Then that should be fixed as well. Why should the mouse action
> >> depend on the window list order? Why can't it use the same
> >> mapping as the Alt+TAB shortcut?
> >>
> >> By the way, was the "mouse action" patch the motivation for this
> >> "window list order" patch?
> >>
> >>
> >
> > From my point of view, the switchpanel should be fixed inst
Re: [PATCH 1/5] wmaker: fix focused window list order
That is the behaviour i have without the patch (and that's why i called it mixed up windows list): 1 has focus alt-tab (next window) show 1 [2] 3 2 has focus alt-tab show 2 [1] 3 1 has focus alt-tab show 1 [2] 3 press another alt-tab, select 3 1 2 [3] 3 has focus alt-tab show 3 [1] 2 another alt-tab to 2, show 3 1 [2] 2 has focus alt-tab show 2 [3] 1 To do that i just configured the "Focus next window" in WPrefs to alt-tab. But as said that behaviour is sounding more like move focus back to previous focused window. > A, B, [C], D > now I alt-tab again and with this patch it goes to D > A, B, C, [D] yes that was what i was expecting from "Focus next window" > [A], B, C, D > I 'alt-tab' and while keeping alt down, I 'tab' more and end up on let's > say C > A, B, [C], D > with old behaviour I am back on A > [A], B, C, D That's focus on previous focused window. I can understand that feature is useful but not really expected. On Fri, Sep 19, 2014 at 7:39 PM, David Maciejak wrote: > On Fri, Sep 19, 2014 at 5:24 PM, Carlos R. Mafra wrote: >>> On Fri, Sep 19, 2014 at 4:25 PM, Carlos R. Mafra wrote: >>> > On Wed, 17 Sep 2014 at 12:29:57 +0200, Amadeusz Sławiński wrote: >>> >> On Thu, 11 Sep 2014 17:50:40 +0800 >>> >> David Maciejak wrote: >>> >> >>> >> > This patch is fixing the focused next window list order. >>> >> > As now, the switching was only working for 2 windows. >>> >> > For example, taking 3 windows called A,B,C. >>> >> > If the windows list is A,B,C where A is the current focused window. >>> >> > Focusing on B will result on switching position A and B, thus C will >>> >> > never be the next window. >>> >> > For this example the patch is updating the linked list as B,C,A. >>> >> >>> >> >>> >> Hey, >>> >> >>> >> I think this patch breaks behaviour of Window Maker. >>> >> >>> >> One thing is that when I change between workspaces it keeps focusing >>> >> last created window instead of last used one. >>> >> >>> >> Other is that it changes focus behaviour, ie, I can't alt-tab between >>> >> two windows, now I have to go through whole list to change between two >>> >> recently used ones. >>> >> For example with windows A, B, C, D (with [A] marking A as focused) >>> >> [A], B, C, D >>> >> I 'alt-tab' once >>> >> A, [B], C, D >>> >> I 'alt-tab' once more >>> >> A, B, [C], D >>> >> where old behaviour would go to: >>> >> [A], B, C, D >>> >> >>> >> I could also choose other window instead of B and I could go back to A >>> >> instantly like so >>> >> [A], B, C, D >>> >> I 'alt-tab' and while keeping alt down, I 'tab' more and end up on let's >>> >> say C >>> >> A, B, [C], D >>> >> now I alt-tab again and with this patch it goes to D >>> >> A, B, C, [D] >>> >> with old behaviour I am back on A >>> >> [A], B, C, D >>> >> >>> >> I think the old behaviour is more usable. >>> >> So I would like to propose reverting this patch >>> > >>> > Thanks for the detailed description. I also caught >>> > myself doing extra Alt+TABs recently because of this. >>> > >>> > At first I thought it was a good idea when I saw the >>> > patch, but the old behaviour is somehow imprinted >>> > on my mind. >>> > >>> > Reverting. >> >> On Fri, 19 Sep 2014 at 16:57:08 +0800, David Maciejak wrote: >>> Reverting the patch will kill the mouse action of switching on next window. >> >> Then that should be fixed as well. Why should the mouse action >> depend on the window list order? Why can't it use the same >> mapping as the Alt+TAB shortcut? >> >> By the way, was the "mouse action" patch the motivation for this "window >> list order" patch? >> >> > > From my point of view, the switchpanel should be fixed instead. > As now there is a linked list of windows which is mixed every time a > alt-tab is done. That means there is no way to know the next window > and do cycling windows. If you check the switchpanel you will see that > each time it's called the icons are in a different order. It should be > better to save the previous focus window in a different dedicated > variable. I can look at that later. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
