On Sat, 20 Sep 2014, Doug Torrance wrote:
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 DontLinkWorks
On Sat, 20 Sep 2014, BALATON Zoltan wrote:
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 b
On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
> 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
>
On Sun, 21 Sep 2014 10:55:43 +0100
"Carlos R. Mafra" wrote:
> On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
> > 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 peculi
I didn't even download these changes, yet, but
I've thought that going 'unmaximised' would NOT
suppose changing the size as well, just the status?
Yury
On 09/21/2014 12:55 PM, Carlos R. Mafra wrote:
On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
If a user moves a window which is
I didn't even download these changes, yet, but
I'd've thought that going 'unmaximised' would
NOT suppose changing the size as well, just the
status?
Yury
On 09/21/2014 12:55 PM, Carlos R. Mafra wrote:
On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
If a user moves a window which
On 09/21/2014 04:33 AM, BALATON Zoltan wrote:
> On Sat, 20 Sep 2014, Doug Torrance wrote:
>> 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.
>>
>> No
On 09/21/2014 04:55 AM, Carlos R. Mafra wrote:
> On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
>> 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.
On 09/21/2014 04:55 AM, Carlos R. Mafra wrote:
> On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:
>> 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.
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 s
This patch adds the ability to completely unmaximize, i.e., clear the maximized
flag and return to the original geometry, a maximized window that is moved.
This behavior mirrors that of other common desktop enviroments, e.g., GNOME,
Unity, and Windows.
To enable this feature, set "UnmaximizeOnMove
After the responses to my original patch "wmaker: Moving unmaximizes windows,"
I have made the default behavior a simple clearing of the maximized flag when
a maximized window is moved, as suggested by Amadeusz. My original proposed
behavior has been moved to a configurable option.
These patches
---
WPrefs.app/Expert.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c
index aee45fb..888ccaa 100644
--- a/WPrefs.app/Expert.c
+++ b/WPrefs.app/Expert.c
@@ -78,12 +78,15 @@ static const struct {
#ifdef XKB_MODELOCK
{ N_(
---
NEWS | 26 ++
1 file changed, 26 insertions(+)
diff --git a/NEWS b/NEWS
index 35319b0..6b57e12 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,32 @@
NEWS for veteran Window Maker users
---
+-- 0.95.7
+
+Window snapping
+---
+
+Yo
On 09/21/2014 08:36 AM, Doug Torrance wrote:
> These patches my previous patches:
> [PATCH 3/4] wmaker: Moving unmaximizes windows.
> [PATCH 4/4] NEWS: Add note about window snapping.
>
This should say "These patches replace my previous patches:"
--
To unsubscribe, send mail to wmaker-dev-unsubscr
It is possible that, when running update-dockapps.pl, a filename may match a
revision, giving an error, e.g.,
fatal: ambiguous argument 'wmbattery': both revision and filename
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
This patch fixes this problem by inserting "--
.db
+++ b/dockapps/dockapps.db
@@ -105,6 +105,15 @@ url =
dockapps = 216
category = System Monitoring
+[wmbattery]
+version-2.44+20140921 = 1a22ccc8011761eec1a71da80973a99f5b935aeb
+version-2.44 = f5f804289e0255a167ca5bc90076007d495a578b
+image = wmbattery.gif
+description = "Wmbattery disp
Quoth Doug Torrance,
This patch changes the behavior by clearing the maximization flag when
a
maximized window is moved. Then, when a window is maximized and then
moved, it
can be maximized again without issues.
[The old way] is explicitly done like that so you can move a maximised
windo
On Sun, 21 Sep 2014 at 8:36:54 -0500, Doug Torrance wrote:
> ---
> NEWS | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/NEWS b/NEWS
> index 35319b0..6b57e12 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -2,6 +2,32 @@
> NEWS for veteran Window Maker users
>
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 a761d7b2cd683e90565754c288968db1fffdc399 (commit)
via 22bc7aeb2fb707e65
On 09/21/2014 01:55 PM, Iain Patterson wrote:
> Quoth Doug Torrance,
>
>> This patch changes the behavior by clearing the maximization flag when a
>> maximized window is moved. Then, when a window is maximized and then
>> moved, it
>> can be maximized again without issues.
>
> [The old way] is e
On 09/21/2014 05:30 PM, Carlos R. Mafra wrote:
> On Sun, 21 Sep 2014 at 8:36:54 -0500, Doug Torrance wrote:
>> +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
>>
---
NEWS | 15 +++
1 file changed, 15 insertions(+)
diff --git a/NEWS b/NEWS
index 35319b0..ce8b86e 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,21 @@
NEWS for veteran Window Maker users
---
+-- 0.95.7
+
+Window snapping
+---
+
+You can now "
*Moving* maximised windows is not a problem,
it's maximised window (suddenly) *changing size*
when moved that's a problem. I only moved it, what?
I foresee folks developing certain subconscious
fear of moving the Wmaker's windows in general -
what if it'll change its size? Perceptionally,
wh
Wait, does this change the window size when
move's in progress, too?
Then it's not "snapping" at all, and the term
used is very confusing.
More precisely, it's something like
"half-maximise when edge is hit" or "half-fill
when edge-snapped".
Snap is only the intermediate result here,
triggerin
On 09/22/2014 12:06 AM, Yury Tarasievich wrote:
> Wait, does this change the window size when move's in progress, too?
> Then it's not "snapping" at all, and the term used is very confusing.
> More precisely, it's something like "half-maximise when edge is hit"
> or "half-fill when edge-snapped".
>
On 09/22/2014 08:18 AM, Torrance, Douglas wrote:
On 09/22/2014 12:06 AM, Yury Tarasievich wrote:
...
Snap is only the intermediate result here, triggering the final result.
The size of the window isn't changed until after the move is completed.
So it's even worse, on two accounts.
First, y
27 matches
Mail list logo
