Dock covers icons and vice versa
Greetings everyone especially authors, maintainers, developers and other contributors! I can't promise a short message but I'll do my best. :-) I have been using Windowmaker almost from the day of it's first release. For many years a version 0.80.2 covered all my windowmanaging needs but recently I had to try 0.9x.x version again because 0.80.2 doesn't work very well with multiple monitors and xinerama support. Windowmaker 0.95.x on the other hand supports xinerama pretty well although it's a bit buggy in that area as well but this is not the point now. The reason I kept using the 0.80.2 version for so long was the fact that 0.90.x made quite a few, big changes and improvements compared to 0.80.2 and as it is often a case with any improvement, there were also some terribly annoying bugs or design decisions. So, I am now checking on the newest Windowmaker 0.95.5 in order to see if anything changed. I can see a lot of improvements including a native wmdrawer support, code cleanup and many bugfixes. However, a single particularly annoying bug which makes the miniwindows (icons) covered by dock still remains. I have checked on the net and people who used to use older versions of Windowmaker have for a long time asked how to fix this behavior of new versions of Windowmaker and it's probably the time for this issue to be addressed. The 0.80.2 and older versions allowed the miniwindows to lay down in parallel with wmdock (if one wanted it that way) but newer Windowmaker versions could only partially simulate such behavior and that includes to either setting an option NoWindowOverDock to yes or to manually set the dock to "Keep on Top". I didn't go too deep into the 0.9x.x code but I am guessing that although they look different, both options might do the similar action internally. It seems to me that there is no iconyard (a part of the screen where miniwindows/icons would be contained) but rather a position calculated for every icon placement. While looking trough the code I have found that when a wmdock gets set to "Keep on Top", a usable space gets recalculated and shrink thus making miniwindows get out of the wmdock cover (they shouldn't be covered anyway). Similarly when a wmdock is unset from "Keep on Top", a usable area of the screen becomes again the same as totalArea of the screen and icons get covered under the wmdock and vice versa. I am not using the clip, I don't set wmdock to "Keep on Top" and I don't prefer to use options that would prevent other windows from covering the dock or the icons while maximized. In such setup with older Windomaker versions miniwindows would just go along with the dock no matter where it is placed. On the other hand in a newer Windowmaker versions this is unfortunately not the case and this is why I am sending this message to this list. I am hoping that someone better versed in the Windowmaker code could take some time and try to fix this "dock covers icons" issue because I don't see an easy way to do it and it might require a better understanding of Windowmaker internals in order to get properly fixed. Currently I have fixed it for myself in a really ugly fashion by modifying src/actions.c and changing a line: vars[head].xo = vars[head].sx2 - isize; to: vars[head].xo = vars[head].sx2 - isize * 2; but this is only a quick and dirty solution for my particular setup and it would be nice if it could be properly fixed, probably by taking care of the way how and under what conditions icons should get aware that a usable screen area have changed. Whoever came all the way to here reading the complete message, thank you very much for you patience. I hope that someone could help fixing this issue because Windowmaker is a very good windowmanager and it would be a shame to see some lame bugs left behind for years. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Dock covers icons and vice versa
On Sunday 2013-11-10, Amadeusz Sławiński wrote: > > Hey, > > I hope I understood you correctly, are miniaturized windows placed > properly (not under dock) when you in preferences on second panel > (maximization) check "...do not cover dock" and save. > > Amadeusz Hi Amadeusz! You are talking about the NoWindowOverDock option and I have mentioned it before. When it is set to "yes" a dock (a.k.a wmdock) does not cover the icons (a.k.a miniwindows). However, that option should concern windows, not the miniwindows (icons). In short, no matter whether one want to allow windows to cover a wmdock and/or miniwindows, miniwindows should never be covered by the dock nor the dock should be covered by miniwindows. This was the case with 0.80.2 and older version of Windowmaker. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Dock covers icons and vice versa
> On Sun, 10 Nov 2013 23:07:03 +0100 > > Yes I noticed this when I started to look at code, anyway I attach a quick > patch which fixes this. Thank you very much. I'll try the patch during the day. > I fix this in minimization code, however I wonder if it's not better > idea to change how area is calculated and take it into account when > maximizing. I agree. If the minimization code is not triggered during some actions that lead to recalculation of the area (maybe setting a dock to be on top for example) it might not solve the problem completely. I'll make tests when I get some time and let you know. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Dock covers icons and vice versa
> On Sun, 10 Nov 2013 23:07:03 +0100 > > Yes I noticed this when I started to look at code, anyway I attach a quick > patch which fixes this. Thank you very much. I'll try the patch during the day. > I fix this in minimization code, however I wonder if it's not better > idea to change how area is calculated and take it into account when > maximizing. I agree. If the minimization code is not triggered during some actions that lead to recalculation of the area (maybe setting a dock to be on top for example) it might not solve the problem completely. I'll make tests when I get some time and let you know. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Dock covers icons and vice versa
>> On Sun, 10 Nov 2013 23:07:03 +0100
>> I fix this in minimization code, however I wonder if it's not better
>> idea to change how area is calculated and take it into account when
>> maximizing.
>
> I agree. If the minimization code is not triggered during some actions
> that lead to recalculation of the area (maybe setting a dock to be on top
> for example) it might not solve the problem completely. I'll make tests
> when I get some time and let you know.
As I have anticipated, a patch helped regarding this issue but the issue
is not completely fixed.
I'll try to describe what is going on now:
Setup:
- clip is disabled
- "do not cover icons" option in the WPrefs is not set
- dock is not set to "Keep on Top"
- "do not cover icons" in WPrefs is not set
- "do not cover dock" in WPrefs is not set
- I am keeping the dock on the right side
- miniwindows (icons) are parallel to the dock, on the same side of
the screen (right side)
Observations with the patch applied:
- miniwindows and the dock doesn't cover each other any more which is
a good thing
- when the dock is dragged from right to left side of the screen,
miniwindows disappear from the screen completely
- if I set the dock to "Keep on Top" icons appear correctly
- if I set "do not cover dock" in WPrefs, icons appear correctly
- if I set miniwindows and/or a dock to a left side of a screen,
miniwindows behave similar to the case where miniwindows were set on
the right side.
Kind regards
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] [RFC] placing miniwindows
On Monday 2013-11-11, Carlos R. Mafra wrote: > I uploaded the patches in the #next branch and it would be nice if > Josip could test the result. > > If they fix his problem then we can address the lack of commit message > (acknowledging his report, for instance) and the non-compliance of > the coding style. Hi, I have just finished testing of Windowmaker from the #next branch and I can confirm that regarding the issue I have reported, it is now working as expected in all combinations of panel/miniwindows options and panel/miniwindows positions. Thank you all very much for your time and effort you continue to put in Windowmaker project. I could now start reporting other oversights and bugs I have found (there are two bugs related to xinerama) and I could even propose some improvements. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] [RFC] placing miniwindows
On Monday 2013-11-11, Carlos R. Mafra wrote: > Thanks for testing and thanks for the report. You are welcome. > > I could now start reporting other oversights and bugs I have found > > (there are two bugs related to xinerama) and I could even propose > > some improvements. :-) > > Please go ahead. No promises they will be fixed, but at least it's good > to know your complaints. Thanks. I have just made some tests with the version of Windowmaker I have compiled from the #next branch and it will probably make you happy to know that one of the bugs I wanted to report doesn't exist any more. I will have to check if it exists in two-monitor xinerama setup tomorrow morning. It was about a window incorectly calculating it's position during a reparenthing (after maximization and unmaximization but only when the window's Y position starts at 0 and the window have the atribute which ensures it's fullscreen maximization). I will make other reports in separate e-mails with appropriate subjects. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Shaded windows cannot get focus while cycling through the list of stacked windows
Hi everyone! Here is another oversight I have noticed in the process of my transition from 0.80.2 to the latest Windowmaker. If you open three windows and shade one of them and then try to focus next window using ALT+TAB or whatever combination of keys you prefer for window cycling using keyboard, you would notice that shaded window never gets focus. In my opinion shaded window should get a focus in the situation as described above and I have two arguments in favor of this opinion: 1. It is the behavior of the Windowmaker 0.80.2 and earlier versions. 2. It's intuitive and helpful solution or should I say that any other solution in this case would make it harder/slower to find your shaded window under two or three other windows. I am used to use ALT+TAB to quickly rise all or just few of the windows, including those which are shaded and give them a focus and unshade them if needed. I guess that the original behavior was lost at the time of adding windows-like bar that shows window icons wile cycling trough the list of stacked windows. Good thing that there is an option "SwitchPanelImages = None" because it makes to much distraction for my taste. Kind regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
On Monday 2013-11-11, Amadeusz Sławiński wrote: > Hello, > > on last tab in preferences there is checkbox > "Ignore minimized windows when cycling" (CycleIgnoreMinimized), when > it's checked it also ignores shadowed windows. Hi, something is not quite right because it doesn't work that way for me. I am using the newest version (#next branch) of Windowmaker and even when I turn off the option you have mentioned I don't get shaded windows included while cycling through the list of windows. Furthermore, if I keep an option "Raise window when switching focus with keyboard" turned on, only the last minimized window gets raised and focused. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: action of alt-tab + left/right arrow crippled
> With current #next, I can't anymore > switch/browse throught the windows in alt-tab > panel using left/right arrows to walk through > the whole list. The left/right arrow takes me > exactly one window left/right, then window gets > switched to, and alt-tab panel disappears. Old > behaviour was more convenient. Could it be > brought back? I can confirm this. Could this behavior be made configurable through an additional option? In Windowmaker 0.80.2 and older versions such behavior didn't exist at all and for those who doesn't use that feature it might occasionally represent irritation (based on the keyboard shortcuts they use). For example, I am using ALT+L and ALT+R to switch workspaces. If I am doing window cycling using ALT+TAB and want to quickly switch workspaces I usually end up cycling windows instead workspaces because I am used to continue holding ALT key while performing such actions. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[no subject]
Iain Patterson said: > > Quoth Josip Deanovic, > >> Could this behavior be made configurable through an additional option? >> In Windowmaker 0.80.2 and older versions such behavior didn't exist >> at all and for those who doesn't use that feature it might occasionally >> represent irritation (based on the keyboard shortcuts they use). > >It sounds like a bug rather than an intentional change since it > doesn't make a whole lot of sense for the arrow keys to change windows > one at a time - you could use alt-tab for that - and they used to work > intuitively. > >Easily fixed. > I can see that the issue Yury reported now got fixed and Windowmaker from the #next branch is now working as Yury described. Is there a chance to introduce an option that would make possible to turn off that feature thus making it more similar to older Windowmaker behavior? I mean, if you are doing ALT+TAB (cycling windows) and without releasing the TAB key start using LEFT/RIGHT keys, it would continue cycling windows instead workspaces as it would in 0.80.x versions. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: action of alt-tab + left/right arrow crippled
Iain Patterson said: > > Quoth Josip Deanovic, > >> Could this behavior be made configurable through an additional option? >> In Windowmaker 0.80.2 and older versions such behavior didn't exist >> at all and for those who doesn't use that feature it might occasionally >> represent irritation (based on the keyboard shortcuts they use). > >It sounds like a bug rather than an intentional change since it > doesn't make a whole lot of sense for the arrow keys to change windows > one at a time - you could use alt-tab for that - and they used to work > intuitively. > >Easily fixed. > I can see that the issue Yury reported now got fixed and Windowmaker from the #next branch is now working as Yury described. Is there a chance to introduce an option that would make possible to turn off that feature thus making it more similar to older Windowmaker behavior? I mean, if you are doing ALT+TAB (cycling windows) and without releasing the TAB key start using LEFT/RIGHT keys, it would continue cycling windows instead workspaces as it would in 0.80.x versions. P.S. Please ignore my previous e-mail without the subject set. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: action of alt-tab + left/right arrow crippled
Hi! It would be nice (at least for me) that Windowmaker act a bit more as it did in pre 0.90.0 versions. I'll try to explain what is going on. I have disabled switchpanel and I am using ALT+TAB for window cycling and ALT+Left/ALT+Right for workspace cycling. Everything works fine until I try to cycle windows using ALT+TAB and imediatelly after that, without releasing the ALT key I try to switch workspace using ALT+Left or ALT+Right (still holding the ALT key). In that moment instead of workspace I am getting windows switched. Is there any chance to change that behavior so that ALT+Left/ALT+Right doesn't switch windows when the switchpanel is disabled or at least to make that configurable through a separate option? -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
On Monday 2013-11-11, Amadeusz Sławiński wrote: > Hello, > > on last tab in preferences there is checkbox > "Ignore minimized windows when cycling" (CycleIgnoreMinimized), when > it's checked it also ignores shadowed windows. > > Amadeusz Hi! Could we discuss this behavior of the 0.9x.x Windowmaker? I believe that in this case the same rules cannot apply to miniwindows and shaded windows. Miniwindows are unmaped while shaded windows are just shrink (their height is reduced to 0 + window label) thus the shaded windows should act more like normal windows instead of miniwindows. Such behavior would be consistent to the pre 0.90.0 versions of Windowmaker. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Xinerama related bugs
Greetings! There are several xinerama related bugs. I'll start with the one that makes windowmaker hard to use. My setup: - I have two monitors (one laptop's monitor and the other one external VGA monitor) - the external (secondary) monitor is configured in the xorg.conf to be placed above the laptop's monitor. - laptop's monitor is set to be primary monitor and it's placed below the secondary monitor. - primary (laptop's monitor) resolution: 1600x900 - secondary (external vga) monitor resolution: 1680x1050 - windowmaker has been compiled from the latest main branch - Windowmaker has been configured with --enable-xrandr and --enable-xinerama options Here is the relevant configuration from xorg.conf: Section "Monitor" Identifier "Monitor0" VendorName "Lenovo" Option "PreferredMode" "1600_900_60.00" Option "Position" "0 1050" Option "Primary" "true" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Dell" Option "PreferredMode" "1680_1050_60.00" #Option "Above" "Monitor0" Option "Position" "0 0" EndSection Description of the issue: - if the wmdock is placed on the primary monitor on the left side everything seems to work fine unless I try to move the dock to the right side using mouse pointer. In that case wmdock would disappear on the right side and could not be used any more until windowmaker is restarted. - if the wmdock is placed on the right side on the primary monitor it's not visible and cannot be used. - if the wmdock is placed on either side on the above konitor (secondary monitor) wmdock is visible and usable. Note that the primary monitor (the one integrated into the laptop) have a a smaller resolution (1600x900) than the secondary (external VGA) monitor (1680x1050). Also, note that the placement of the wmdock is incorrectly calculated in case you disconnect the secondary monitor and restart the X server. Is there any chance to solve the above issues? Kind regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Xinerama related bugs
On Thursday 2014-03-27, Josip Deanovic wrote: > Greetings! > > There are several xinerama related bugs. > I'll start with the one that makes windowmaker hard to use. [...] > Description of the issue: > - if the wmdock is placed on the primary monitor on the left side > everything seems to work fine unless I try to move the dock to the right > side using mouse pointer. In that case wmdock would disappear on the > right side and could not be used any more until windowmaker is > restarted. > - if the wmdock is placed on the right side on the primary monitor it's > not visible and cannot be used. > - if the wmdock is placed on either side on the above konitor (secondary > monitor) wmdock is visible and usable. > > Note that the primary monitor (the one integrated into the laptop) have a > a smaller resolution (1600x900) than the secondary (external VGA) monitor > (1680x1050). > > Also, note that the placement of the wmdock is incorrectly calculated > in case you disconnect the secondary monitor and restart the X server. > > Is there any chance to solve the above issues? > > Kind regards In addition to the issue described above I have found that I am unable to switch workspace in the primary (laptop's) monitor while dragging a window to the border on the right. A workspace successfully changes when I use the border on the left. When I use secondary (external VGA) monitor and try to drag a window over left or right borders a workspace successfully change as expected. Regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: updates to FrameBorderColor/FrameSelectedBorderColor options
On Monday 2014-05-19 13:58:07 Amadeusz Sławiński wrote: > Click the button around the color. It should be in "selected" (white > color) state for changes to work. I didn't know that such color chooser exists in WPrefs. It's opening is not intuitive at all. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Monday 2013-11-11 22:22:01 by Josip Deanovic:
> Hi everyone!
>
> Here is another oversight I have noticed in the process of my transition
> from 0.80.2 to the latest Windowmaker.
>
> If you open three windows and shade one of them and then try to focus
> next window using ALT+TAB or whatever combination of keys you prefer
> for window cycling using keyboard, you would notice that shaded window
> never gets focus.
>
> In my opinion shaded window should get a focus in the situation as
> described above and I have two arguments in favor of this opinion:
>
> 1. It is the behavior of the Windowmaker 0.80.2 and earlier versions.
> 2. It's intuitive and helpful solution or should I say that any other
>solution in this case would make it harder/slower to find your shaded
> window under two or three other windows. I am used to use ALT+TAB to
> quickly rise all or just few of the windows, including those which are
> shaded and give them a focus and unshade them if needed.
>
> I guess that the original behavior was lost at the time of adding
> windows-like bar that shows window icons wile cycling trough the list of
> stacked windows.
> Good thing that there is an option "SwitchPanelImages = None" because it
> makes to much distraction for my taste.
Greetings,
I finally got some time to check the windowmaker code (from the next
branch) and to fix the issue reported above.
Please consider applying the patch below.
It would make the focus of the shaded windows to work/behave the same as
windowmaker 0.80.2. I have tested the patch with and without switchpannel
and it looks ok.
Without this patch cycling trough the list of mapped windows would never
focus shaded windows thus leaving them hidden under bunch of other windows.
--- wmaker-crm/src/actions.c2014-05-25 10:28:14.0 +0200
+++ wmaker-crm.new/src/actions.c2014-05-25 11:23:21.0 +0200
@@ -234,11 +234,6 @@
wwin->flags.skip_next_animation = 0;
wwin->flags.shaded = 1;
- wwin->flags.mapped = 0;
- /* prevent window withdrawal when getting UnmapNotify */
- XSelectInput(dpy, wwin->client_win, wwin->event_mask &
~StructureNotifyMask);
- XUnmapWindow(dpy, wwin->client_win);
- XSelectInput(dpy, wwin->client_win, wwin->event_mask);
/* for the client it's just like iconification */
wFrameWindowResize(wwin->frame, wwin->frame->core->width,
wwin->frame->top_width - 1);
Kind regards
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 11:42:33 by Carlos R. Mafra: > I cannot apply this. Just checking the chronology of development > I don't understand how removing the above lines can fix your problem. Those lines are part of the "void wShadeWindow(WWindow *wwin)" function. If the window is already shaded it will just return. If not, it will shade it but it will also unmap it and set the flag wwin->flags.mapped to 0. So I have removed those lines because I believe that shaded windows should not be unmaped. By removing those lines I was able to cycle trough the list of windows, including shaded windows. In the meantime I have noticed that changing workspace also affects the cycling of shaded windows until the shaded window is unshaded and shaded again. > You said that wmaker-0.80.2 works for you, but the above lines are > _much_ older than that: Might be that in the meantime some code in the 0.9x that enabled the cycling to include shaded windows has been removed thus leading to the issue I have reported. > Both Amadeusz and Zoltan confirm that your issue is related to > setting "SwitchPanelImages = None". And this patch doesn't explain > why that happens. I believe they didn't fully understand the issue. > Since you have the git repository, you can 'git bisect' the issue > to find the real cause of your bug and fix this properly. It will > probably have something to do with the SwitchPanelImages setting. I am not well versed with the git or any other versioning system but I'll try to see what I can do. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 15:12:37 by Yury Tarasievich: > On 05/25/2014 02:29 PM, Josip Deanovic wrote: > > Quoting message written on Sunday 2014-05-25 11:42:33 by Carlos R. Mafra: > >> I cannot apply this. Just checking the chronology of development > >> I don't understand how removing the above lines can fix your problem. > > ... > > > By removing those lines I was able to cycle trough the list of > > windows, including shaded windows. > > Is this a change of the known default behaviour > of 0.9* series, where ALT-TAB brings out a blue > panel with all the windows to cycle through? Or > does this map to ALT-TAB some other action? I > couldn't tell from reading the posts. 0.80.x and previous versions would include shaded windows when cycling. When using ALT + TAB to cycle trough windows shaded windows would focus and rise as any other normal window. 0.95.x and probably earlier 0.9x versions change this behavior in a way that shaded windows doesn't get focus while cycling through the window list using ALT+TAB or whatever combination of keys one decide to use. 0.9x also brought a blue panel (I believe it's called switchpanel) which is optional and whether you use the switchpanel or not, shaded windows are not included in the list of windows that are able to get focus when cycling using ALT+TAB. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 14:07:12 by Carlos R. Mafra: > On Sun, 25 May 2014 at 14:22:22 +0200, Josip Deanovic wrote: > > 0.9x also brought a blue panel (I believe it's called switchpanel) > > which is optional and whether you use the switchpanel or not, shaded > > windows are not included in the list of windows that are able to get > > focus when cycling using ALT+TAB. > > I don't think this is true. > > I believe that Amadeusz correctly identified the cause. You said you > have "SwitchPanelImages = None". Try without that to see that your > issue goes away, I believe. I have tested it again with the current next branch. This is the current behavior: Shaded window does get focus if: - the option "SwitchPanelImages = None" is not used - the option "CycleIgnoreMinimized = NO" is set (note that shaded window is not minimized and should act more like normal window) NOTE: - if covered by other windows, shaded window doesn't rise although the CirculateRaise option is set to YES - if selected by switchpanel, a shaded window will unshade Shaded window does not get focus nor does it rise if: - the option "SwitchPanelImages = None" is used (no switchpanel) In my opinion, in both cases shaded window should be included in the cycle window list together with other normal windows. And unless switchpanel is used, shaded window shouldn't be unshaded when brought on top and focused. > which I think explains Amadeusz observation that you need to set > "SwitchPanelImages = None". I have "SwitchPanelImages = None" set all the time (unless I am testing switchpanel). > Your patch removes the line setting flags.mapped to 0, so the condition > > (wwin->flags.mapped || include_unmapped) > > becomes true and the window is added to the list. Alternatively, you can > fix the issue by changing the include_unmapped variable. > > And it seems to me that your patch chose the wrong solution. I guess > the patch should clean up the logic behind associating include_unmapped > with wPreferences.swtileImage!=0. I'll look into the suggested lines. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 17:33:00: > The blue panel on my system (several days old > #next) includes shaded windows. > > Yury It does include shaded windows but if you cover shaded windows with some normal windows you will notice that the shaded window doesn't rise. When you turn off the blue panel (the switchpanel) the only way to know that there are shaded windows around is through the window list menu. This is not how things worked in pre 0.9x versions and from my perspective (after using 0.80.x for many years) the behavior regarding cycling windows is broken. Unfortunately this is not the only thing that changed in the 0.9x behavior when compared to 0.80.x and in the fact it was the main reason for avoiding the 0.9x Windowmaker versions. Some of them are already fixed. For example, few months ago it wasn't possible to keep miniwindows and the wmdock in parallel on the right side of the screen. There are few more things that need to be fixed but I prefer to take them one at a time to avoid pressure on the list. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 19:39:00 by Yury Tarasievich: > On 05/25/2014 05:50 PM, Josip Deanovic wrote: > > Quoting message written on Sunday 2014-05-25 17:33:00: > >> The blue panel on my system (several days old > >> #next) includes shaded windows. > > > > It does include shaded windows but if you cover shaded windows > > with some normal windows you will notice that the shaded window > > doesn't rise. > > But it does. I've never used this shading > feature, in any WM, so maybe I'm not reproducing > it right. > Here's how it goes here: > xterm - right click on titlebar - select shade - > xterm shrinks to its titlebar - select anything > normal to put it over shaded xterm - alt+tab - > blue panel pops up - any way of selection partly > transparent icon of the shaded xterm works > > Yury It will look like it works if you left shaded window on the top. So, to properly test you have to: 1. Create two or more windows 2. Shade one of the windows (the way you have described is ok) 3. Move normal windows so that they at least partially cover the shaded window 4. LeftClick on the titlebars of normal windows to make sure they are on top of the shaded window 5. Cycle through windows using alt+tab without releasing the alt key and you will notice that the shaded window never comes on top of the normal windows (it will not rise, it will stay hidden under your normal windows, at the same time you will see it as partly transparent icon on the switchpanel, note that you will not be able to select the partly transparent icon that belongs to the shaded window unless you have the option CycleIgnoreMinimized set to NO) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 18:58:04 by Amadeusz: > I can reproduce, try it like this > > two normal windows + one shaded > > one normal above shaded one and other normal is focused > now press alt+tab (or whatever else you have binded) > keep alt down so shaded one doesn't unroll (and switch panel is visible) > and cycle few times through all of them, > notice that while normal window when being focused is raised up > the shaded ones gets focus but stays below > > Amadeusz Yes, that's it. And when you don't use switchpanel you can't see that there is a shaded window buried under a bunch of other windows. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
Quoting message written on Sunday 2014-05-25 20:15:54 by Yury Tarasievich: > Okay. > > However, I'd really like to know, would fixing > this break the existing alt-tab > behaviour/switching order? I don't think so. You can already see the shaded window in the switch panel and it is shown as partially transparent icon of the shaded window. Fixing this behavior would only make shaded windows to rise as they get focus. Note that when the switchpanel is disabled, shaded window doesn't even get a focus when cycling through the window list. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 01:01:03 by Amadeusz: > Hey, > > so I've taken a look at this, seems like it just needs additional checks > if windows are shaded. I've done some testing and it seems to work ok, > both with and without switchpanel. > > Amadeusz I have just tested it and I can confirm that it works in both cases, including workspace change. If nobody has anything to add I consider this issue closed and I would like add yet another observation related to alt+tab (window cycling). It seems that along with the support for switchpanel came another change that negatively affected setup without switchpanel and it is related to window cycling (specifically alt+tab). I'll try to describe it. When using switchpanel and alt+tab (window cycling), by holding the ALT key and pressing the TAB key, we would get windows cycling through the window list. But if we stop using pressing TAB key while still holding the ALT key, by pressing LEFT or RIGHT key we would continue cycling trough the list of windows. This might even look logical when switchpanel is used because LEFT or RIGHT keys would chose left or right icons that represent their windows on the switchpanel. However, when the switchpanel is disabled the described behavior stays and often doesn't allow to simply reuse ALT key with some other key combination explicitly specified in the configuration that includes LEFT or RIGHT key without first releasing the ALT key. In short, ALT+LEFT and ALT+RIGHT key combination is blocked right after ALT+TAB is used unless the ALT key is released and pressed again. Could we please try to remove such behavior for the case where switchpanel is disabled since there is no use of such behavior when switchpanel is not visible and it's different when compared to windowmaker 0.80.x. I am using 0.95.5 for over a year now and I still can't get used to it. When switchpanel is not used the old behavior is much better especially if you are using ALT+LEFT and ALT+RIGHT for some specific actions. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 13:42:08 by Amadeusz:
> Well something along those lines seems to work, but it seems
> 'workaroundish', problem is that those (and few more like esc and
> return) are hardcoded. But if Carlos has nothing against such approach
> I will write a full patch.
>
>
> diff --git a/src/cycling.c b/src/cycling.c
> index 9331739..35d62d1 100644
> --- a/src/cycling.c
> +++ b/src/cycling.c
> @@ -153,7 +153,7 @@ void StartWindozeCycle(WWindow *wwin, XEvent
> *event, Bool next, Bool class_only) &&
> wKeyBindings[WKBD_FOCUSNEXT].modifier == modifiers) ||
> (wKeyBindings[WKBD_GROUPNEXT].keycode == ev.xkey.keycode &&
> wKeyBindings[WKBD_GROUPNEXT].modifier == modifiers)
> - || ev.xkey.keycode == rightKey) {
> + || (wPreferences.swtileImage &&
> ev.xkey.keycode == rightKey)) {
> newFocused =
> wSwitchPanelSelectNext(swpanel, False, ev.xkey.keycode != rightKey,
> (!class_only && wKeyBindings[WKBD_GROUPNEXT].keycode == ev.xkey.keycode
> && wKeyBindings[WKBD_GROUPNEXT].modifier == modifiers)); oldFocused =
> change_focus_and_raise(newFocused, oldFocused, swpanel, scr, False); @@
> -162,7 +162,7 @@ void StartWindozeCycle(WWindow *wwin, XEvent *event,
> Bool next, Bool class_only) && wKeyBindings[WKBD_FOCUSPREV].modifier ==
> modifiers) || (wKeyBindings[WKBD_GROUPPREV].keycode == ev.xkey.keycode
> && wKeyBindings[WKBD_GROUPPREV].modifier == modifiers)
> - || ev.xkey.keycode == leftKey) {
> + || (wPreferences.swtileImage &&
> ev.xkey.keycode == leftKey)) {
> newFocused =
> wSwitchPanelSelectNext(swpanel, True, ev.xkey.keycode != leftKey,
> (!class_only && wKeyBindings[WKBD_GROUPPREV].keycode == ev.xkey.keycode
> && wKeyBindings[WKBD_GROUPPREV].modifier == modifiers)); oldFocused =
> change_focus_and_raise(newFocused, oldFocused, swpanel, scr, False);
Thank you Amadeusz.
I have just tested your changes with and without switchpanel and it
works fine (the switchpanel case is unaffected by the change).
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 13:12:16 by Carlos R. Mafra: > The patch is simple. I wouldn't consider it seriously before, but > since it apparently matters a lot to Josip I guess it's ok. > > I hope we won't get a report ten years from now asking for the > old behavior back :-) If there will be such report it will not be filed by me. :-) Anyway, that's why I suggested that we leave the current behavior for the switchdesk and only change the behavior of the cycling when the switchdesk is disabled. I guess that most of the new windowmaker users (those who started with 0.9x) mostly use switchpanel thus they will probably not be affected by the change. Most of the people probably don't even know how to turn off the switchpanel. I have always wondered why there is no option in the WPrefs for disable/enable switchpanel. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Buggy Maximus
Greetings! Windowmaker 0.95.2 introduced a new tiled maximization known as Maximus. Windowmaker NEWS file says: Maximus/Maximumize. A new tiled maximization, configured with a keyboard shortcut. Using it will maximize the window to the greatest area such that it will not overlap any other window of the same workspace. This can be configured in WPrefs in the "Keyboard Shortcuts" page, or in the config file with "MaximusKey". I have noticed that in some particular cases a window does not get properly resized when Maximus is used. I'll try to describe the issue: - create two windows, one over the other so that they don't overlap - use Maximus on the upper window - observe the number of pixels between the upper (Maximused) window and the lower window - deMaximuse the upper window so that it returns to it's original size - move the lower window a pixel or two toward the bottom of the screen - use Maximus on the upper window again - observe the number of pixels between the upper (Maximused) window and the lower window, notice that the the number of pixels (distance) between windows has changed - deMaximuse the upper window so that it returns to it's original size - continue repeating the above steps and notice that the distance between windows changes and at some point the upper window will even overlap the lower window by few pixels. I have found that the maximum distance between windows might reach 11px and the minimum distance might be -3px (overlaps the lower window by 3 pixels). Note that moving the upper window does not affect the distance between windows when Maximus is used while the moving of the lower window does. So, yet another complicated description from me. I anticipate a long thread. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 20:27:16 by Yury: > On 05/26/2014 03:20 PM, Josip Deanovic wrote: > > Most of the people probably don't even know how to turn off the > > switchpanel. > > ...or even want to, for that matter :) That too. :-) > If we are talking dear memories 10+ years old, > I'd quite like to see xview's virtual desktops > manager in windowmaker. Possibly, with > additional (windowmaker style) pop-uppish > behaviour triggered by window crossing the > desktop border. Or is there such a thing > available already?? > > Yury Are you talking about Openlook's pager? In 2004 I made pager for windowmaker as well as a simple icon manager but I have planed to add some more features so that cod was never released and still waits in archived directory for me to get some time. My pager doesn't look like the one I remember from Openlook, it's actually meant to be used inside wmdock. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Buggy Maximus
Quoting message written on Monday 2014-05-26 16:45:03 by Amadeusz: > Are any of those windows terminals? They tend to have resize increment > (use `xprop | grep increment` to find it), which may explain changing > gap size, I haven't been able to reproduce the -3 pixels thing. > > Amadeusz Yes, I have tested Maximus using xterm, aterm and gnome-terminal. xprop | grep increment gives "program specified resize increment: 7 by 15". I have now tried it with other applications such as xlogo. Xlogo doesn't have resize increment specified and it doesn't act like gnome-terminal. However, the upper window still overlaps the lover window by 3 pixels when Maximused. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 23:29:13 by Yury: > I don't remember well what was that thingy > called in openwin/ol[v]wm/Xview. > It had the (default) 3x3 matrix of virtual > desktops and the windows' movement was reflected > there live. > It looked like a pinnacle of usability w/r to > the virtual desktops concept. Why an equivalent > seemed never to exist in the open-source? Probably nobody who knew how to write it never felt the need for it or never got the time to write it. > That 64x64 field (or even 48x48 or 32x32, eh?) > might be not so useful, and would take an > expensive screen estate. That's what I dislike > in many WM-styled apps. Yes, 64x64 with the support for four workspaces and for the next four there are arrow buttons. I am not sure if this mailing list rules permit the attachments but I'll attach two small images anyway. :-) > I'd imagine "an ideal xview-like pager" popping > up only if window crosses the desktop border > and/or when some screen edge is hit with mouse > pointer. I see. -- Josip Deanovic
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Monday 2014-05-26 23:10:27 by BALATON Zoltan: > I think Fvwm or Fvwm2 had something similar. But this would not be a > good fit for Window Maker which has separate workspaces that are linear > (next to each other) not a big virtual workspace for which the display > is a view. (So you cannot have a window on two workspaces for example.) > > Regards, > BALATON Zoltan Yes. BTW, FVWM supported both, virtual desktop as well as workspaces. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fix issues with alt-tab
Quoting message written on Tuesday 2014-05-27 09:43:07 by Yury: > Weeell, if there can't be anything better in > wmaker than a set of workspaces, separated with > impenetrable borders from each other, then the > whole discussion is somewhat pointless. > > Knowing wmaker only superficially, I was sort of > hoping something like Xview pager is > implementable fairly easily. It's possible to implement it but there would be no point in presenting workspaces like 3x3 or 5x5 table. Workspaces are best represented either horizontally or vertically (at least this is the case with current Windowmaker). This is the difference in approach to solving the need for additional virtual "screens". One approach is known as virtual desktop and when it's configured to have e.g. 3x3 or 5x5 "cells", it acts like a single huge screen. That implies that the first, upper cell would start with the coordinates x=0, y=0 and the other cells would add the size of the cell to their x and y coordinates. The other is known as virtual workspaces and all workspace start at x=0, y=0. That means that when you move some window to a different workspace, the window could keep the same coordinates. One thing that would change when the window is changing workspace is the ID of it's workspace. There are several standards that tried to define some basic rules for workspace support (KWM (kde1), GNOME, EWMH a.k.a NETwm a.k.a freedesktop). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmbutton dockapp: fail early on missing config
Quoting message written on Thursday 2014-05-29 14:44 by Carlos R. Mafra: > I just wanted to point out that now wmaker has a drawer whose purpose > is (more or less) the same as wmbutton. Have you seen that? Windowmaker's drawer is not comparable to wmbutton dock app as they are used in a different way. Windowmaker's drawer is comparable to wmdrawer dock app and I have been using wmdrawer dock app until Windowmaker got his native drawer support in 0.95.5. Thanks to the authors of both drawers. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/2] EXIF orientation feature
Quoting message written on Sunday 2014-06-01 11:10:22 by David: [...] > *lock my session. I don't care about screensaver thing, just need > something that work like i3lock as xlockmore is not provided anymore on > some distribs and slock is just segfaulting in my tests), what about a > wmlock ? I like the idea of internal locking mechanism in windowmaker. Right now I am using either xlocmore, i3lock or slock and they are working fine but it would be nice to provide the locking mechanism with the window manager distribution so that we can be sure it's maintained. I don't know why many distributions decided to drop xlockmore package. Might be that it hasn't been maintained for some time in the past or that it tend to segfault (I have experienced it several times few years ago). According to i3lock's manual, i3lock is slightly improved version of slock. If people experienced segfaults with slock under some circumstances this is a very bad thing, especially for a screensaver with locking support. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
Quoting message written on Tuesday 2014-06-03 22:43:22 by David Maciejak: > That option is effectively disabling *all* the switch panel, not only > the icons. > In fact it can be used either to disable the panel or to set panel bg > image. That's true but I agree with Carlos that the current description might be misleading to users, especially to those that lack the knowledge of Windowmaker's internal functions and their naming. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
Quoting message written on Tuesday 2014-06-03 22:57:15 by David Maciejak: > On Tuesday, June 3, 2014, Josip Deanovic wrote: > > That's true but I agree with Carlos that the current description might > > be misleading to users, especially to those that lack the knowledge of > > Windowmaker's internal functions and their naming. > > I see no problem to change the description, please everybody share your > ideas ! Maybe something like: "Do not show Alt-Tab window switching panel" or "Do not display Alt-Tab window switching panel" BTW, thank you for adding that option to WPrefs. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: wmaker: default icon size ?
Quoting message written on Wednesday 2014-06-04 14:01:47 by David Maciejak: > Hi, > > Enclosed my current info panel, with an updated logo size from 45x45 to > 64x64, I believe 128x128 could be even better with some auto resize > when necessary. > > Any thoughts ? I think 64x64 is better than before. I don't think that 128x128 with added autoresize support is necessary. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
Quoting message written on Wednesday 2014-06-04 11:58:25 Carlos R. Mafra: > > * Use the text "Show switch( )panel when cycling windows" > > > > (defaulting to on) for the patch under discussion. > > That's a _much_ better description. David, can you redo the patch? Yes, it's better compared to previous suggestions and ALT+TAB doesn't necessary have to be used for cycling windows. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
Quoting message written on Thursday 2014-06-05 10:17:10 by Yury: > On 06/05/2014 09:19 AM, Iain Patterson wrote: > > Having said that I do think that "cycling" is > > fine because if you keep pressing FocusNextKey > > you keep on iterating through the window list > > To repeat myself, if you do one-off alt-tab, do > you get cycling? In fact, you get the opposite, > or, at least, not cycling through the initial set. Yes you do get window cycling, unless you are using option SwitchPanelOnlyOpen = YES; in your WindowMaker config file. > When you work with switch panel activated, you > get additional visual element, which doesn't > change the base logic of the action, but > provides additional controls. And by default you also get window cycling. I have just tested it without SwitchPanelOnlyOpen set. > This just doesn't boil down to "cycle", this is > broader than just "cycle", but then again, > having had worked on l10n for a while, I just > might have a somewhat different perspective on > this... > > BTW, I still remember this little change of > logic of alt-tab behaviour was quite a source of > confusion to me in days of transition from > os2/win guis. These days, I rely on this feature. :) Here is the what NEWS file for 0.95.5 says about switchpanel: ---BEGIN--- To maintain consistency with other popular operating systems, the switchpanel is now configured so that it no longer automatically closes when the shift key is pressed and released. To configure the switchpanel so that it does close on release of the shift key, which was the traditional Window Maker behavior, run the following command: $ wdwrite WindowMaker StrictWindozeCycling NO If you find yourself regularly opening the switchpanel just to visualize open windows, you can run the following command to force the first "FocusNextKey" or similar shortcut to open the panel without switching to a new window. $ wdwrite WindowMaker SwitchPanelOnlyOpen YES ---END--- > > different text for the new preference because > > "Show switch panel when switching windows" is a > > bit weird. Just "Show panel..." maybe? > > There are lots of panels, which one do you have > in mind? :) I agree in this one. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
Quoting message written on Thursday 2014-06-05 09:58:13 Iain Patterson: > Quoth Yury Tarasievich, > > > There are lots of panels, which one do you have in mind? :) > >The one that shows up when you switch windows, hence "Show panel when > switching windows" :) you mean cycle windows? ;-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Double-click on application in wmdock does not launch the application if one instance is already running
Hello As said in the subject, double-click on an application in wmdock does not launch the application in case there is an instance of the application already running. As I heard from a friend of mine it used to work in 0.95.3 and previous versions of Windowmaker with "Shared application icon" check box turned on for a specific application that has been added to wmdock. With version 0.95.5 and version from current git repository it is not the case any more. It is possible to launch additional instance by using right-click and selecting "Launch" option but this really sucks. Is this behavior intentional? A friend of mine decided to downgrade to 0.95.3 until this is resolved. It seems that Windowmaker users constitute a class of users that really don't like unexpected changes. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Thursday 2014-06-05 18:14:29 by Iain Patterson:
> Quoth BALATON Zoltan,
>
> > I don't think it ever worked the way you describe or if it did it was
> > probably a bug. What used to work and should still work is starting
> > additional instances with Ctrl+double click. So I think this is
> > intentional and not a regression.
>
>Going from memory, since I don't use the dock and haven't built from
> any recent commits, starting a docked application wait()s for the
> process so if it runs in the foreground you can't launch another one
> except via one of the methods already discussed. I thought it had
> always been that way.
I have just tested Windowmaker 0.80.2, 0.95.3 and 0.95.4.
I have found that the described (mis)behavior first started to occur in
version 0.95.4.
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
Starting with version 0.95.4 Windowmaker doesn't behave the same way
any more and it is not possible to execute multiple instances of a
docked application using double-click.
It is still possible to execute additional instances of the application
in the wmdock using right-click and then selecting "Launch" from the
menu but this is not practical at all in every day use.
I suggest restoration of the behavior from pre-0.95.4 version
BTW, what is the meaning of the "Shared application icon" option in the
Application Specific Attributes window?
I was convinced that it was meant to instruct Windowmaker to allow
multiple instances of the applications in the wmdock when double-click is
used on them.
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Saturday 2014-06-07 03:34:27 by BALATON Zoltan: > On Sat, 7 Jun 2014, Josip Deanovic wrote: > > I suggest restoration of the behavior from pre-0.95.4 version > > I don't mind either way (not using that option) but isn't double click > with Ctrl pressed sufficient to launch another instance? Double click > brings forward the running application and if it behaved differently for > some applications it would be inconsistent. I prefer to see an app icon and an app icon added to a wmdock as two different things so they don't have to operate in the the same way. In fact it worked like this until recently (up until 0.95.4). Insisting on CTRL + double-click on app icons in the wmdock or app icons in the wmdock looks awfully unintuitive and it's not practical if you tend to start multiple instances of some applications in the wmdock very often (xterm for example). I don't use app icons in the wmdock (I like to bind FN or Win key to start my terminals) but since some people decided to downgrade back to 0.95.3 when they found that the behavior in 0.95.4 and 0.95.5 has changed, it gives us the answer to a question whether CTRL + double-click is enough or not. In short, people would rather chose to stick with old 0.95.3 version than use CTRL + double-click on the wmdocked app icon. As I said, I don't use that option either but since it was there up until 0.95.4 (even in 0.80.x versions and probably earlier versions) and since it's intuitive and practical, I would suggest to bring the described behavior back to Windowmaker. In addition to that, since internal wmdrawer support came after 0.95.4 in order to keep the consistency, app icons in the wmdrawer should be able to start additional instances when double-clicked. > > BTW, what is the meaning of the "Shared application icon" option in > > the Application Specific Attributes window? > > It's what it says, that multiple instances of one application will share > a single icon. For example you can have a single icon for all terminal > windows so you can hide them at once. (Actually on *step the icons > belong to applications which can have multiple windows. So these > windows all belong to a single application and thus icon. This can be > emulated by the shared application icon when the windows are separate > instances of an X application.) Thank you for the explanation. Kind regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2014-06-09 08:39:59 by Yury: > I don't understand Josip's problem. Would > someone clarify? The > more-than-one-instance-unlaunchable-by-simple-action > icons in Dock are there "since ever". I > definitely remember those in 0.92? (what was > that stale version before Carlos took over?). > And I think I can recall my initial confusion > with 0.80? (well before Y2K). > > However, the > more-than-one-instance-unlaunchable-by-simple-action > icons in Dock are not intuitive, indeed, and not > practical, too -- in this Josip's quite right. I > use single-click-activation, still, having to > reach for the CTRL is a source of irritation > (albeit very minor). And I had to stumble upon > the CTRL-click combination, too, after long > using \Launch. Yury, it looks to me that you understand the problem quite well and the problem is: starting from 0.95.4 if you have dragged some app icon to the wmdock you would need to use CTRL + double click or CTRL + single click (in case you are using the "SingleClickLaunch = YES" option) to launch additional instances of the application represented by the app icon in the wmdock. Before 0.95.4 in the case described above CTRL key was not required. The change of this long standing behavior is the problem although it's not mine own problem since I don't use that particular feature. A friend of mine pointed it to me and I am trying to see if it's possible to convince developers to change that particular behavior as it were before 0.95.4. I am inclined to believe to believe that if there is a one person who suffers from some particular change there must be more. P.S. Many things regarding different behavior have changed with 0.9x. Unfortunately when I have tried it back then (I believe it was 2007) I had no time to write complaints and from my point of view back then it looked completely /fucked up/ so I decided to stick with 0.80.2 which worked perfectly well for me until few months back when I had to use multiple monitors and xinerama. I have decided to actively communicate with the developers hoping to either make them change few things the way they worked in previous releases (e.g. 0.80.2) or to make some quick and dirty patches myself as some of the bugs were a real show-stoppers for me. I succeed in my goal and almost all of the discrepancies between 0.80.2 and 0.95.5 I have noticed (or at least those that were particularly important to me) are now "fixed" or "in line" if you don't see the word fixed as appropriate here. :-) Regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2014-06-09 10:43:25 by Yury: > Yes, yes, but hadn't this behaviour been there > "since ever"? You mention the 0.95.4 as a > milestone for this change, and I fairly well > remember having to \Launch to get > an additional instances of xterm as far back as > 0.92/0.93, and I definitely remember this wmaker > behaviour in 2009. So I'm wondering, might you > be talking about something (subtly) different? I have tested 0.80.2, 0.95.3, 0.95.4 and 0.95.5. The behavior I have described has changed in 0.95.4. Maybe you are talking about app icon while I am referring to an app icon dragged into the wmdock? > Personally, I wouldn't mind the change of this > behaviour, anyway. Right now the icon of the app > already launched does nothing useful on > single/double click and just takes up the screen > space. > > That, or completely do without the icons' strips > of any kind. Optionally, if you please. You can > already switch off the Dock and the Clip, why > not dispense with the icons completely? I am disabling app icon for every single application I use so app icons don't really bother me because I see them only once per application (first time I launch an application). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2014-06-09 11:24:28 by Yury: > Disabling every app icon as they appear doesn't > look like a productive scenario to me. :) It doesn't but I can live with it as in my case it doesn't happen too often that I have to launch completely new application. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2014-06-09 11:13:14 by Carlos R. Mafra:
> If some behavior changed that was not intentional and
> we must fix it.
I agree but sometimes I am not sure if something has been
changed intentionally to increase consistency.
For example, recently (last week) Windowmaker has returned
some of it's previous behavior regarding cycling shaded
windows. I am very happy because of that. :-)
However, when you cycle through windows (with switchpanel
disabled) and if you stop on the shaded window, the shaded
window will unshade.
This behavior is the same whether switchpanel is disabled
or not but in the 0.80.2 it wouldn't unshade, it would just
focus and rise.
So, what to do in the example such as this one? Is this
intentional behavior or not and which behavior looks more
logical? To unshade or not to unshade, it is a question now.
> It would be great if you could 'git bisect' the issue to
> a particular patch. That would speed up the fix greatly
> since there is even a confusion about the issue itself.
Ok. I'll need some time to read the git documentation as I
don't know how to use it.
> I guess you can have something like
>
> "*" = {NoAppIcon = YES;};
>
> in your WMWindowAttributes file to disable them entirely.
I know about that option but I chose not to use it. I like
to see the icon of the application I am launching for the
first time and then I simply either disable it for that
particular application or drag the app icon to wmdrawer.
> Perhaps we should have an 'expert' option in WPrefs doing this,
> because I've seen this subject come up many times already.
I have no opinion on the matter but I do agree that some kind
of warning should be set in the description of the option.
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2014-06-09 11:13:14 by Carlos R. Mafra: > It would be great if you could 'git bisect' the issue to > a particular patch. That would speed up the fix greatly > since there is even a confusion about the issue itself. Hello, I am done with git bisect. Let me know if the following output helps: bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit commit bc0700e016c67791d3e3eab855543d849f4ce786 Author: Rodolfo GarcÃa Peñas (kix) Date: Mon Jun 18 11:15:19 2012 +0200 Create WAppIcon always When the application is created, the WAppIcon now is created always, but it is only painted if the flag is not set. The icon initialization to NULL can be done now at app_icon_create_from_docks because it is always called. :04 04 7c58877ad5af211acaddac5288848c2ade7b04cb 33d52affb385d22fbf04ebad3c628b714008785d M src Regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker Fork
Quoting message written on Sunday 2014-08-17 18:07:08 by Charles Philip Chan: > On 17 Aug 2014, k...@kix.es wrote: > > Hi Kix: > > I was thinking about create a Window Maker fork, and probably is the > > best way to contribute to Window Maker. My aim now is include XRandR, > > Multihead and hardware abstration for Window Maker, but this is very > > difficult because we need include a lot of changes and Window Maker > > could be unstable. > > Why a fork instead of an experimental branch? > > Charles Indeed, why? That would only create a confusion. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker as the official window manager of the GNU operating system
Quoting message written on Thursday 2014-11-20 21:31:33: > On Thu, 20 Nov 2014 at 12:27:29 -0800, John H. Robinson, IV wrote: > > I've not read through the GNU Coding Standards to see where the > > differences are between it and the Linux kernel coding standard. If > > the differences are not great, and GNU is tolerant of the deviations, > > I'm for having Window Maker again be listed as the Official window > > manager. > > Yes, I think it's a good idea. > > Are there any immediate changes necessary in order to accept this? What if it happens that the "marriage" between GNU and Windowmaker simply doesn't work for some reason and participants (GNU and Windowmaker) decide to split up and continue with their own paths? What would that imply for Windowmaker developers and the Windowmaker project in the terms of legal liabilities? -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker, GNU, Bruno
Quoting message written on Tuesday 2014-11-25 14:32:18: > I want to publicly apologize for mistakenly purporting to speak for > the GNU project. > > The messages I've posted to this mailing list represent solely my own > opinions and don't necessarily reflect those of the GNU project. > > The GNU project is not liable for any of my posts, being myself the > sole responsible for them. > > I'm sorry for causing any anger or making anyone feel threatened. > > Sincere in motivation, I did what I thought was best for GNU. Mistakenly you say? It is nice to apologize if you think that you are wrong but these are your words from your initial post here: >> The GNU project is, therefore, interested in getting Window Maker back >> into the GNU operating system and under its umbrella. Furthermore, >> the Window Maker community will certainly benefit from the promotion >> and support given by the GNU project and the Free Software Foundation. >> >> Would you like to join us again? It doesn't seem that there was much room left for different interpretations. Furthermore in your other posts in the same thread you have continued to talk in a same manner leaving readers to believe that you actually officially represent the GNU Project. This is just the impression I got after reading your posts and things became clear to me only after John Sulivan posted his notice to the list. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 18/23] wmaker: add code to explicitly ignore Motif-WM flags we don't want to handle
Quoting message written on Monday 2014-12-08 22:42:39:
> The goal is to explain the reason why we don't do anything about them,
> so people looking at the code in the future will know why it is this
> way. The expected side effect is also to silent warnings
> [-Wunused-macros] from gcc.
[...]
> @@ -101,10 +109,26 @@ static void setupMWMHints(WWindow *wwin, MWMHints
> *mwm_hints) WSETUFLAG(wwin, no_closable, 0);
> }
>
> + if (mwm_hints->decorations * MWM_DECOR_MENU) {
> + /*
> + * WindowMaker does not include a button to
display the menu
> + * for windows, this is done using right button on
the title.
> + * As a consequence, we ignore this flag because
we have
> + * nothing to hide.
> + */
> + }
> +
Maybe it would be better if "the right button" is changed to
"the right mouse button" or "the right click". Otherwise it looks
like a reference to a button placed on the right side of the title bar.
Regards
--
Josip Deanovic
Re: Workspace pager not fully visible
Quoting message written on Thursday 2014-12-18 01:33:01: [...] > Even better would be uploading such a huge file to one of the free image > hosting websites and just provide an URL in your message, linking to > that very file. Nonetheless, even in this case it would be very > appreciated to strip down file size. I don't like the idea of using free image hosting web sites in this case as those usually dump the old content leaving the archived message with the broken link and without the image. If someone would try to browse messages in the mailing list archive he wouldn't be able to see the image the post is referring to which is not desirable. -- Josip Deanovic
Re: Changing username
Quoting message written on Thursday 2015-01-15 21:32:17:
> Hi,
>
> on my Arch linux system I changed my username following these steps:
> https://wiki.archlinux.org/index.php/Change_username
>
> This change is cause that that my WindowMaker session start buggy and
> freeze the X Window system. Only Control+Alt+BackSpace can stop X
> Window system.
>
> So I must to do followings to get a working WM session:
> $ mkdir ~/GNUstep
> export GNUSTEP_USER_ROOT="${HOME}/GNUstep"
> $ wmaker.inst
>
> This way I get the default setup so I must to create again my menus,
> etc. However I did a backup of my previous ${HOME}/GNUstep/ directory,
> but with it, as I say, can't run WM session.
>
> Is there a way how can I reuse the backed up $HOME/GNUstep/ directory
> with all setting of icons, menus, etc. now when I changed my username?
Hi!
I would suggest recursive grep through ~/GNUstep directory.
Search for your old username and replace it with your new username.
When finished login with the new username and you should be fine.
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Compile problem
: Leaving directory `/home/djosip/download/novi_wmaker/wmaker-crm.next' make: *** [all] Error 2 Does anyone have a solution for this? Also, please let me know if a more detailed output would be of help. arch: x86_64 autoconf-2.69-12.2 automake-1.11.1-4 libtool-2.2.6-15.5 Thanks in advance -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Compile problem
Quoting message written on Thursday 2015-06-18 21:03:18:
> You might want to add '--enable-silent-rules', although it will not
> solve any of your problem, just make the compilation more readable.
Hi Christophe, thank you for the response.
I have used the '--enable-silent-rules' this time.
> > [...]
> > wraster.h:182: error: wrong number of arguments specified for
> > 'deprecated' attribute
> Could you please provide the answer for both commands:
> gcc --version
$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> fgrep -C1 deprecated wrlib/wraster.h
$ fgrep -C1 deprecated wrlib/wraster.h
#if __GNUC__ >= 4
#define __wrlib_deprecated(msg) __attribute__ ((deprecated(msg)))
#elif __GNUC__ >= 3
#define __wrlib_deprecated(msg) __attribute__ ((deprecated))
#else
#define __wrlib_deprecated(msg)
#endif
--
unsigned int optimize_for_speed:1
__wrlib_deprecated("Flag optimize_for_speed in RContext is not used
anymore "
"and will be removed in future version, please
do not use");
--
*/
#undef __wrlib_deprecated
> > After that I can continue compiling the source until I get to the next
> > problem: [...]
> > /usr/bin/ld: cannot open linker script file libwraster.map: No such
> > file or directory
>
> There are 2 things that would help understanding what's going on:
> - the file 'config.log'
I have attached the config.log file (~102KiB).
> - fgrep libwraster.map wrlib/Makefile
$ fgrep libwraster.map wrlib/Makefile
am__append_1 = -Wl,--version-script=libwraster.map
EXTRA_libwraster_la_DEPENDENCIES = libwraster.map
CLEANFILES = libwraster.map
libwraster.map: $(include_HEADERS)
$(top_srcdir)/script/generate-mapfile-from-header.sh
-n LIBWRASTER -v $(WRASTER_VERSION)
$(srcdir)/$(include_HEADERS) > libwraster.map
Here is how compile looks with '--enable-silent-rules' option:
Window Maker was configured as follows:
Installation path prefix: /usr/local/windowmaker-0.95.7
Installation path for binaries : /usr/local/windowmaker-0.95.7/bin
Installation path for libraries : /usr/local/windowmaker-0.95.7/lib
Installation path for WPrefs.app: /usr/local/windowmaker-0.95.7
Supported core features:: Animations MWMHints XDnD
Supported X extensions: : XShape XShm Xinerama RandR
Supported graphic format libraries : XPM PNG JPEG GIF TIFF WebP Magick
builtin-PPM
Unsupported features:
Antialiased text support in WINGs : yes
Pango text layout support in WINGs : no
Translated languages to support : disabled
$ make
Generating config-paths.h
make all-recursive
make[1]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm'
Making all in wrlib
make[2]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
Making all in .
make[3]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
CC raster.lo
In file included from raster.c:29:
wraster.h:182: error: wrong number of arguments specified for 'deprecated'
attribute
make[3]: *** [raster.lo] Error 1
make[3]: Leaving directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/djosip/download/novi_wmaker/wmaker-crm'
make: *** [all] Error 2
At that point I need to modify the file wrlib/wraster.h in order to continue
with the compile.
In line 181 of the file wrlib/wraster.h I simply change these lines:
unsigned int optimize_for_speed:1
__wrlib_deprecated("Flag optimize_for_speed in RContext is not used
anymore "
"and will be removed in future version, please
do not use");
with these lines:
unsigned int optimize_for_speed:1;
/*__wrlib_deprecated("Flag optimize_for_speed in RContext is not
used anymore "
"and will be removed in future version, please
do not use");*/
And then I can continue with the compile until the next error:
$ make
make all-recursive
make[1]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm'
Making all in wrlib
make[2]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
Making all in .
make[3]: Entering directory `/home/djosip/download/novi_wmaker/wmaker-crm/wrlib'
CC raster.lo
CC alpha_combine.lo
CC draw.lo
CC color.lo
CC load.lo
CC save.lo
CC gradient.lo
CC xpixmap.lo
CC convert.lo
CC context.lo
CC misc.lo
CC scale.lo
CC rotate.lo
CC flip.lo
CC convolve.lo
CC save_xpm.lo
CC xutil.lo
CC load_ppm.lo
CC load_gif.lo
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Saturday 2014-06-14 00:06:14: > Quoting message written on Monday 2014-06-09 11:13:14 by Carlos R. Mafra: > > It would be great if you could 'git bisect' the issue to > > a particular patch. That would speed up the fix greatly > > since there is even a confusion about the issue itself. > > Hello, > > I am done with git bisect. Let me know if the following output > helps: > > > bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit > commit bc0700e016c67791d3e3eab855543d849f4ce786 > Author: Rodolfo GarcÃa Peñas (kix) > Date: Mon Jun 18 11:15:19 2012 +0200 > > Create WAppIcon always > > When the application is created, the WAppIcon now is created always, > but it is only painted if the flag is not set. > > The icon initialization to NULL can be done now at > app_icon_create_from_docks > because it is always called. > > :04 04 7c58877ad5af211acaddac5288848c2ade7b04cb > > 33d52affb385d22fbf04ebad3c628b714008785d M src > > > > Regards Hi everyone Since we are not far away from the releasing of the Windowmaker 0.95.7 I would like to remind everyone about the issue in this thread since I can see that it has not been resolved in current "next" branch and it would be nice to solve it before the 0.95.7. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: About to release wmaker-0.95.7
Quoting message written on Saturday 2015-06-13 08:49:05: > I'm planning to release wmaker-0.95.7 by the end of the > next week, with the current state of the #master branch. > > This is a good time to test it to report any new problems > or even old ones in case they were forgotten. Hi Carlos, I would kindly suggest that you postpone the new release for few more weeks in order to give some more time for some bugs to eventually get solved. I am currently trying to resurrect an old thread I have started few months ago (which is probably not about a bug but a feature lost by mistake at some point). I have two new bugs but they could be related to some compile problems I am experiencing so I'll wait with it until that is resolved. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Compile problem
Quoting message written on Friday 2015-06-19 22:02:24: > Thanks again, I managed to isolate the cause! Thank you for your time. > I have also sent a patch for this, although for this one it will take > you some extra work, sorry for that... Now when I run "./autogen.sh" I get this at the end: ... configure.ac:101: the top level configure.ac:44: require Automake 1.12, but have 1.11.1 autoreconf: automake failed with exit status: 1 I have upgraded my automake to 1.13 and build procedure is now working. Is the update of automake that extra work you are referring to? :-) Thank you for helping me to solve this. Automake 1.12 should be added into the requirements list if it is going to stay like that. Further more, one cannot read the list of prerequisites as the file INSTALL-WMAKER gets built only after you already have some of them met e.g. autoconf, automake, possibly more. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: About to release wmaker-0.95.7
Quoting message written on Friday 2015-06-19 15:15:58: > Quoting message written on Saturday 2015-06-13 08:49:05: > > I'm planning to release wmaker-0.95.7 by the end of the > > next week, with the current state of the #master branch. > > > > This is a good time to test it to report any new problems > > or even old ones in case they were forgotten. > > Hi Carlos, > > I would kindly suggest that you postpone the new release for few more > weeks in order to give some more time for some bugs to eventually > get solved. > > I am currently trying to resurrect an old thread I have started few > months ago (which is probably not about a bug but a feature lost by > mistake at some point). > > I have two new bugs but they could be related to some compile problems > I am experiencing so I'll wait with it until that is resolved. Another suggestion, this time about workspace pager. If I understood correctly workspace pager could not be seen unless a user sets some keyboard shortcut and then use it in order to open/close the workspace pager. That's fine but since such shortcut is not configured by default there is no way for user to open the workspace pager by accident thus this feature is effectively disabled by default. This feature also makes a huge impact on Windowmaker's workspace switching performance which is not visible if the feature is disabled by using "DisableWorkspacePager = YES" or via WPrefs tool (requires restart). I would suggest to set workspace pager feature to disable by default and change the option from "DisableWorkspacePager" to "EnableWorkspacePager" and to replace the description in the WPrefs from "Disable workspace pager." to "Enable workspace pager (requires restart, will produce impact on workspace switching performance)." Otherwise we will have Windowmaker which is slow by default because of the feature most people will never know that exists. I wonder if workspace pager feature really need to make it that slow. There are other issues with it: - it grabs the mouse and doesn't let it out of the pager area so one cannot normally work with windows while pager is opened. - one cannot select workspace in the pager area by using LEFT/RIGHT keyboard keys and this is the most intuitive thing one would expect especially because the keyboard seems to be grabbed as well and one cannot use other keyboard shortcuts while workspace pager is opened - pager cannot show images of the workspaces user didn't switched to yet, and they are shown completely white. - pager also doesn't doesn't correctly show window inside a workspace in case window has been sent to the workspace via "Move To" window menu. I do not expect to see any of this issues solved any time soon (if ever) but we could at least disable it by default until it stops making impact on workspace switching performance. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
configure.ac_libdir.patch
Hi!
I would like to propose this simple patch:
diff -Nru wmaker-crm.next/configure.ac wmaker-crm.next.patched/configure.ac
--- wmaker-crm.next/configure.ac2015-06-20 08:53:05.0 +0200
+++ wmaker-crm.next.patched/configure.ac2015-06-20 08:53:41.0
+0200
@@ -281,6 +281,8 @@
_bindir=`eval echo $bindir`
_bindir=`eval echo $_bindir`
+_libdir=`eval echo $libdir`
+_libdir=`eval echo $_libdir`
lib_search_path='-L${libdir}'
@@ -937,7 +939,7 @@
echo
echo "Installation path prefix: $prefix"
echo "Installation path for binaries : $_bindir"
-echo "Installation path for libraries : $libdir"
+echo "Installation path for libraries : $_libdir"
echo "Installation path for WPrefs.app: $wprefs_base_dir" | sed -e
's|\${prefix}|'"$prefix|"
echo "Supported core features::$supported_core"
echo "Supported X extensions: :$supported_xext"
It would fix the output status of the configure script which
currently gives output such as this:
Window Maker was configured as follows:
Installation path prefix: /usr/local/windowmaker-0.95.7.next
Installation path for binaries : /usr/local/windowmaker-0.95.7.next/bin
Installation path for libraries : ${exec_prefix}/lib
Installation path for WPrefs.app: /usr/local/windowmaker-0.95.7.next
Supported core features:: Animations MWMHints XDnD
Supported X extensions: : XShape XShm Xinerama RandR
Supported graphic format libraries : XPM PNG JPEG GIF TIFF WebP Magick
builtin-PPM
Unsupported features:
Antialiased text support in WINGs : yes
Pango text layout support in WINGs : no
Translated languages to support : disabled
instead of something like this:
Window Maker was configured as follows:
Installation path prefix: /usr/local/windowmaker-0.95.7.next
Installation path for binaries : /usr/local/windowmaker-0.95.7.next/bin
Installation path for libraries : /usr/local/windowmaker-0.95.7.next/lib
Installation path for WPrefs.app: /usr/local/windowmaker-0.95.7.next
Supported core features:: Animations MWMHints XDnD
Supported X extensions: : XShape XShm Xinerama RandR
Supported graphic format libraries : XPM PNG JPEG GIF TIFF WebP Magick
builtin-PPM
Unsupported features:
Antialiased text support in WINGs : yes
Pango text layout support in WINGs : no
Translated languages to support : disabled
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
Quoting message written on Monday 2014-09-22 14:29:36: > Hi Doug, > > Great Feature ! > > Just one comment which I think that it can be improved: > > Apparently right now it just does windo snapping in the right/left > sides. It would be great if top/bottom maximization could be done too. > In particular, since my current monitor is huge, I would also love > having more options: topLeft, topRight, bottomLeft, bottomRight :) But > at least bottom/top I think that are important. I am a bit late but maybe not too late :-) Really nice feature. Doug, would it be to hard to not completely disable the feature in case DontLinkWorkspaces is set to "NO" but to disable just the left/right and corner snapping instead? That way someone who is using workspace linking feature could still snap a window top/bottom which is still more than nothing (actually I feel I would really like that feature while still being able to use workspace linking). Regards -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Malformed checkboxes in Window Attributes window
Quoting message written on Saturday 2015-06-20 10:41:37: > Hi, > > Josip Deanovic schreef: > > Hi! > > > > Did anybody else notice the malformed look of checkboxes in "Window > > Attributes" window? > > Yes, but it's not malformed. The first (read-only) box indicates the > window hint requested by the program. The second one is a tristate check > box, that can be changed to override it. Some programs (GNOME/GTK?) > might need it to run correctly under Window Maker. (See also the Help > balloon, when hovering the first check box. > > It can also be used to remove the resize bar on some Window Maker > panels, as they can't be resized currently. To turn the resize bar off > in those panels by default, would look better imho: WPrefs panel, Color > panel, and the panels for opening images/directories/programs. > Thank you for the response. This is probably some new feature as I don't remember seeing this before. I have just turned on balloons for "internal help". Without this I couldn't see the help balloon for check boxes. The appearance of the check boxes immediately reminded me to the look of an incorrectly drawn area i X, that's why I thought it was a malformed check box. :-) -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/3] Renamed "Apercu" to "MiniPreview" in the configuration database
Quoting message written on Wednesday 2014-12-31 01:09:53: > The name of the 2 settings have been changed: > - enable: MiniwindowApercuBalloons -> MiniwindowPreviewBalloons > - size: ApercuSize -> MiniPreviewSize > > The old name is still supported to avoid breaking user's configuration, > but WPrefs will update the setting to the new names when updating the > configuration. Hi Christophe, I finally got some time to check some new Windowmaker features so I tried to use that MiniPreview a.k.a. apercu feature but it doesn't work out of the box and there are some inconsistencies. Problem 1: - exit windowmaker - in the console manually edit GNUstep/Defaults/WindowMaker file in order to remove all occurance of MiniwindowApercuBalloons and ApercuSize variables - MiniwindowPreviewBalloons is set to YES - MiniPreviewSize is set to let's say 256 - start windowmaker - tail -f .xsession-errors says: /usr/local/windowmaker-0.95.7.next/bin/wmaker(wReadDefaults(defaults.c:1227)): warning: your configuration is using old syntax for Mini-Preview settings; consider running WPrefs.app to update But it doesn't. Let's check using wdread: $ wdread WindowMaker MiniwindowApercuBalloons $ wdread WindowMaker ApercuSize $ wdread WindowMaker MiniwindowPreviewBalloons YES $ wdread WindowMaker MiniPreviewSize 256 Problem 2: And at that moment miniwindows doesn't show any kind of mini preview while balloons still work (I have tried it with balloons turned off but without change). So I started the WPrefs changed MiniPreviewSize to 264, saved the change and closed WPrefs. wdread confirms it: $ wdread WindowMaker MiniPreviewSize 264 Mini window preview for miniwindows still doesn't show up. Then I have tried to use the old variables: $ wdwrite WindowMaker MiniwindowApercuBalloons YES $ wdread WindowMaker MiniwindowApercuBalloons YES At that moment I can see miniwindow preview for the first time but they look more like the original default (twice the size of the miniwindow). Then I start the WPrefs and change the size of the MiniPreviewSize to something else, let's say to 256, save and close WPrefs. Current state: $ wdread WindowMaker MiniwindowApercuBalloons YES $ wdread WindowMaker ApercuSize $ wdread WindowMaker MiniwindowPreviewBalloons YES $ wdread WindowMaker MiniPreviewSize 256 At that moment miniwindow preview shows up as expected, with the size of 256px. - exit Windowmaker - start windowmaker Miniwindow preview shows up in size as twice the size of the miniwindow again. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: add miniwindow apercu
Quoting message written on Thursday 2014-08-14 15:43:57: > This patch is adding miniwindow apercu when the mouse > is over the miniwindows. > > I added this feature about one month ago and was successfully testing > it since then. > To enable it you have to run WPref, in Miscellaneous Ergonomic > Preferences, check miniwindow apercus. > Then, you will be able to see a screenshot of the app when the mouse > is over the miniwindow (I also enclosed a screenshot to show you what > it looks like). Hi David, I have just tested this feature and this is how it looks on my setup. Please check the attached image (~57KiB, PNG). Could you (or maybe some volunteer) modify the titlebar of the preview area so that it reflects either the color/texture of the minimized window or the color of the miniwindow titlebar (variable IconTitleBack)? Next logical step would be to add a minimized window title bar to the title bar of the miniwindow preview area similar to what miniwindows already do. Also notice how miniwindow preview area covers the miniwindows below and the wmdock. Could the position of the miniwindow preview area be recalculated so that it doesn't cover the other miniwindows or the wmdock? Regards -- Josip Deanovic
Re: Compile problem
Quoting message written on Saturday 2015-06-20 14:22:55: > > Yes, that is a known limit of the procedure in place. Actually this > > file is more meant for people compiling from the official package, > > which do not have these problems. The goal is for people compiling > > from > > Git to find this information online on the Website, which is an > > ongoing > > task. > > Sorry, this makes no sense. > > The INSTALL-WMAKER file should be a plain text for people to read > without any hassle. It should contain information to help people > install wmaker. Its existence cannot depend on things that the file is > meant to warn about in the first place. > > Can we get the file back like it was? I remember that there was some talk about it in the past: http://thread.gmane.org/gmane.comp.window-managers.windowmaker.devel/8990/focus=9017 I think that in order to keep INSTALL-WMAKER file in textual form, the source of the documentation could still be kept in texinfo but it should be manually generated every time someone changes the relevant texinfo. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
Quoting message written on Saturday 2015-06-20 12:35:33: > On 06/20/2015 03:41 AM, Josip Deanovic wrote: > > Doug, would it be to hard to not completely disable the feature in > > case > > DontLinkWorkspaces is set to "NO" but to disable just the left/right > > and corner snapping instead? > > > > That way someone who is using workspace linking feature could still > > snap a window top/bottom which is still more than nothing (actually I > > feel I would really like that feature while still being able to use > > workspace linking). > > Thanks for the suggestion! > > I just submitted a patch with this change. > > Doug Thank you very much. I'll test it as soon as I get some time. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
Quoting message written on Saturday 2015-06-20 12:35:33: > On 06/20/2015 03:41 AM, Josip Deanovic wrote: > > Doug, would it be to hard to not completely disable the feature in > > case > > DontLinkWorkspaces is set to "NO" but to disable just the left/right > > and corner snapping instead? > > > > That way someone who is using workspace linking feature could still > > snap a window top/bottom which is still more than nothing (actually I > > feel I would really like that feature while still being able to use > > workspace linking). > > Thanks for the suggestion! > > I just submitted a patch with this change. > > Doug I have just applied the patch and tested it and something is not right. Without workspace linking the feature is still working as usual. With workspace linking enabled I get the window frame created UP/DOWN, depending on the window position but if I decide to stop the snapping action (move the window from the upper/lower border) the window frame would stay and when I release the window it would snap to the border and change its size. So once the window gets near the upper/lower border and its new frame gets drawn, the only thing I can do is to move the window to the opposite border where window would act just the same. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
Quoting message written on Saturday 2015-06-20 22:49:51: > On 06/20/2015 05:11 PM, Josip Deanovic wrote: > > I have just applied the patch and tested it and something is not > > right. > > > > Without workspace linking the feature is still working as usual. > > > > With workspace linking enabled I get the window frame created UP/DOWN, > > depending on the window position but if I decide to stop the snapping > > action (move the window from the upper/lower border) the window frame > > would stay and when I release the window it would snap to the border > > and change its size. > > > > So once the window gets near the upper/lower border and its new frame > > gets drawn, the only thing I can do is to move the window to the > > opposite border where window would act just the same. > > I think I've fixed this. I've just sent a revised patch. > > Doug I have just tested it. I have also tested it with and without workspace linking and in combination with the feature turned on/off. Everything works as expected it should be safe to apply the patch. I didn't thoroughly look at the code so I'll just ask... In case when workspace linking is turned off, is it possible to make a bit borders/area in which window would snap into a corner without changing some other Windowmaker code? While testing the feature I have noticed that it is a bit tricky to pick a corner. You almost need to pinpoint it and you need to keep your cursor steady while releasing the button. Otherwise it could chose to snap to horizontal or vertical border. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
Quoting message written on Sunday 2015-06-21 09:39:18:
> I didn't thoroughly look at the code so I'll just ask...
> In case when workspace linking is turned off, is it possible to
> make a bit borders/area in which window would snap into a corner
> without changing some other Windowmaker code?
>
> While testing the feature I have noticed that it is a bit tricky
> to pick a corner. You almost need to pinpoint it and you need to
> keep your cursor steady while releasing the button. Otherwise it
> could chose to snap to horizontal or vertical border.
I have just looked at the code and I think it could be done.
This is what I did and it works fine. I have used 10px but it might
be increased (lower than 10px wouldn't look good).
It makes corner snapping much easier and it looks more like something
people might be used to while working with other systems.
--- wmaker-crm.next/src/moveres.c 2015-06-21 10:32:38.0
+0200
+++ wmaker-crm.next.patched/src/moveres.c 2015-06-21
10:27:50.0 +0200
@@ -1240,20 +1240,20 @@
static int get_snap_direction(WScreen *scr, int x, int y)
{
- if (x < 1) {
- if (y < 1)
- return SNAP_TOPLEFT;
- if (y > scr->scr_height - 2)
- return SNAP_BOTTOMLEFT;
+if (x < 10 && y < 10)
+ return SNAP_TOPLEFT;
+if (x < 10 && y > scr->scr_height - 10)
+ return SNAP_BOTTOMLEFT;
+ if (x < 1)
return SNAP_LEFT;
- }
- if (x > scr->scr_width - 2) {
- if (y < 1)
- return SNAP_TOPRIGHT;
- if (y > scr->scr_height - 2)
- return SNAP_BOTTOMRIGHT;
+
+ if (x > scr->scr_width - 10 && y < 10)
+ return SNAP_TOPRIGHT;
+if (x > scr->scr_width - 10 && y > scr->scr_height - 10)
+return SNAP_BOTTOMRIGHT;
+ if (x > scr->scr_width - 2)
return SNAP_RIGHT;
- }
+
if (y < 1)
return SNAP_TOP;
if (y > scr->scr_height - 2)
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Icon in the window attributes is not visible until the Reload button is pressed
Hi everyone I have noticed another incorrect behavior which could be considered as a bug. - open window attributes window -> select "Icon and Initial Workspace" - area which should contain either client supplied icon or custom icon file name is not visible until the "Reload" button is pressed. I am sending thins such as this to this mailing list so that they get at least noted somewhere because I am not sure if this is known problem or not. In any case since the pressing the "Reload" button makes the icon visible it is probably not too difficult to find the function responsible for redrawing the icon and call it during the window opening. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Sunday 2015-06-21 20:12:23: > > Hi everyone > > > > Since we are not far away from the releasing of the Windowmaker 0.95.7 > > I would like to remind everyone about the issue in this thread since > > I can see that it has not been resolved in current "next" branch and > > it would be nice to solve it before the 0.95.7. > > Hi, > > On my side I can re-run a new instance of an application by doing > "Ctrl+DblClick" which is an official feature. Do we really need to add > an ugly hack to implement an unexpected side effect, which would be > configured through an option that is totally unrelated to the behaviour > controlled? But it worked in 0.95.3 and I am inclined to believe that author wanted it that way rather than the doubleclick was implemented by mistake. If it actually was a mistake it is still something users saw as a feature. In the meantime some users (not me because I am not using wmdock to start applications) became dependent on that feature and even chose to stick with the 0.95.3 because of it. I know how they feel since I used 0.80.2 for years because 0.9x version changed a way things are done (these have been fixed in the meantime and I am very grateful to the developers and maintainers for this). Since I don't like to see losing perfectly valid features with new versions of WindowMaker I have started this thread some time ago hoping that this feature (even if it is not documented it is still feature) could find its way back into windowmaker. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Sunday 2015-06-21 21:36:27: > On 21 Jun 2015, djosip+n...@linuxpages.net wrote: > > But it worked in 0.95.3 and I am inclined to believe that author > > wanted it that way rather than the doubleclick was implemented by > > mistake. If it actually was a mistake it is still something users saw > > as a feature. > > Isn't double clicking on the docked appicon of a running app suppose to > raise that app to the front? > > Charles Yes but if you select "Shared application icon" check box in the window attributes then the double click would start another instance of the application. This is how it worked up until and including 0.95.3. After thoroughly testing the behavior of the current version I have found that Windowmaker currently works like this (please read my conclusion on the end of the message): Without "Shared application icon" selected in the window attributes window: - every instance of an application creates its own appicon - double click on some appicon would bring up and focus its application instance - ctrl + double click on any appicon would start a new instance of the application and the application would get its own appicon - right click -> Launch from the appicon menu would act exactly the same as the ctrl + double click on the appicon - docked appicon acts a bit differently, double click, ctrl + double click and right click -> Launch in the docked appicon menu would all start a new instance of the application but without creating an appicon. - subsequent double click on the docked appicon would not start a new instance of the application but would bring up and focus the window of the instance which has been created through the docked appicon - subsequent ctrl + double click or right click -> Launch in the docked appicon menu would both start a new instances of the application but now they would have their own appicons created (this is both confusing and nonintuitive) - double click on the docked appicon would still bring up and focus only the window of the first instance of the application created through the docked appicon. With "Shared application icon" selected in the window attributes window: - only the first instance of the application creates the appicon - double click on the appicon would bring up and focus all of the windows of all instances of the application (of course only one of them get focused) - ctrl + double click on the appicon would start a new instance of the application and the application would use the same appicon (the instances are sharing the appicon) - right click -> Launch from the appicon menu would act exactly the same as the ctrl + double click on the appicon - docked appicon acts a bit differently, double click, ctrl + double click and right click -> Launch in the docked appicon menu would all start a new instance of the application but without creating an appicon - subsequent double click would not start a new instance of the application but would bring up and focus windows of all the application instances (of course only one window get focused) - subsequent ctrl + double click or right click -> Launch in the docked appicon menu would both start new instances of the application but now they would not create their own appicons as in the first example because they are sharing the same appicon and that appicon is docked in the wmdock. - double click on the docked appicon would bring up and focus all the windows that belongs to any instance of the application (of course only one window gets focused) My conclusion here is that the docked appicon still acts as an appicon which is not intuitive but its probably correct from the windowmaker design (look and feel) perspective. Windowmaker up until and including 0.95.3 would allow subsequent double clicks on the docked appicon to start new instances of the application which was probably incorrect from the windowmaker design (look and feel) perspective but some people learned to use that "feature". I am now aware that Windowmaker is actually working correctly and I cannot any longer insist on putting the "double click" feature back into the current version as this IMHO would be wrong thing to do. Instead, I would like to propose a new option under the "Application Specific" options, in the application attributes winow which would: - make docked appicon behave more like an launcher for the application instead of the application's instance appicon - allow double click and subsequent double clicks on the docked appicon to launch new instances of the application Users would then be able to drag an appicon to the dock and configure the window attributes in a way that the docked appicon doesn't ack as a docked
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Monday 2015-06-22 07:48:58: > I'd like to chime in with following notes and > queries: > > 1) Ctrl+DblClick is rather weird-looking > feature, way out of what's commonly expected in > 2015. > > Not a good usability, too. One time you open the > item by a single-click, and in another context > (suddenly) you have to use something completely > different? Your penguin may explode. > > I just checked -- yes, even with 'single click > activation' you still have to use DblClick with > Ctrl. That's why I generally open instances off > the popup menu and shun Dock/Clip completely -- > the menu functions in an expected manner. > > 2) How problematic would it be to add > _additional_ Click/DblClick for _indiscriminate_ > opening of an instance? > > 2.1) Or add it as an alternative? > > 2.2) Without breaking the things for guys used > to Ctrl+DblClick behaviour, too, of course. Hi Yury, I have just thoroughly checked the feature. Please check my response to message sent by Charles Philip Chan. In short, the docked appicon is still an appicon and it acts as it has never been docked. I suppose this is the correct behavior not matter how unintuitive it might look to us. There is a huge possibility that some people rely on this. That's why I have proposed (similar to your idea) to add another option in the window attributes window which would (not by default) change the behavior of the docked appicon in order to make it possible to use docked appicon in more intuitive way. Subsequent double clicks on the docked appicons would also be much easier to use on tablets as you wouldn't have to open a menu to "launch" another instance of the application. Not to mention that you usually can't combine CTRL and double click on touch display which are these days more and more common. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
Quoting message written on Sunday 2015-06-21 20:30:46: > Quoting message written by Christophe on Sunday 2015-06-21 20:12:23: > > Hi, > > > > On my side I can re-run a new instance of an application by doing > > "Ctrl+DblClick" which is an official feature. Do we really need to add > > an ugly hack to implement an unexpected side effect, which would be > > configured through an option that is totally unrelated to the > > behaviour > > controlled? > > But it worked in 0.95.3 and I am inclined to believe that author wanted > it that way rather than the doubleclick was implemented by mistake. > If it actually was a mistake it is still something users saw as a > feature. > > In the meantime some users (not me because I am not using wmdock to > start applications) became dependent on that feature and even chose to > stick with the 0.95.3 because of it. > > I know how they feel since I used 0.80.2 for years because 0.9x version > changed a way things are done (these have been fixed in the meantime and > I am very grateful to the developers and maintainers for this). > > Since I don't like to see losing perfectly valid features with new > versions of WindowMaker I have started this thread some time ago hoping > that this feature (even if it is not documented it is still feature) > could find its way back into windowmaker. I'll reply here to myself... In the meantime I have tested the feature thoroughly and I have somewhat changed my mind about it. Please check my response to the message sent by Charles Philip Chan. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Monday 2015-06-22 15:06:36 BALATON Zoltan wrote: > On Mon, 22 Jun 2015, Josip Deanovic wrote: > > Windowmaker up until and including 0.95.3 would allow subsequent > > double > > clicks on the docked appicon to start new instances of the application > > which was probably incorrect from the windowmaker design (look and > > feel) perspective but some people learned to use that "feature". > > I've never seen this behaviour but maybe I've skipped the buggy versions > that had this "feature" or used settings where this didn't happen. > Double click raised app windows and Ctrl+DblClick started another > instance whenever I've tried. The ability to use Ctrl+DblClick on > undocked appicons was added recently, previously it only worked on the > dock/clip. Yes, you would have to set the "Shared application icon" option in the application attributes window. > > Instead, I would like to propose a new option under the "Application > > Specific" options, in the application attributes winow which would: > > - make docked appicon behave more like an launcher for the application > > > > instead of the application's instance appicon > > > > - allow double click and subsequent double clicks on the docked > > appicon > > > > to launch new instances of the application > > > > Users would then be able to drag an appicon to the dock and configure > > the window attributes in a way that the docked appicon doesn't ack as > > a docked appicon but as a launcher which would be much more intuitive > > taking into account the year we live in. :-) > > Window attributes are app specific. This setting seems to be a dock/clip > option so maybe it should be a pref setting for dock/clip instead. A > window attribute does not make much sense here unless you want it > selectively for different apps, but that's really bad ergonomics as > that would be very confusing if icons for different apps would behave > differently when docked. So this looks more like a dock feature to me > to have click on running appicon start new instance more like a > launcher. I have suggested application attributes window because there are already "Shared application icon" and "No application icon" options and they both allow you to configure some applications to act different then the others. So it seems to be logical place for such option if its going to be added in the future. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Monday 2015-06-22 15:41:51 Yury Tarasievich wrote: > I quite agree and would only amend this by using > turn of phrase "double OR single clicks (w/r to > the 'Single click activation' configuration > setting)". > > Well, can YOU implement this? :) I surely would but my programming skills are rusty and I am always short with time. I got some spare time last few days and this is why I became so active on the list lately. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] NEWS: Add note about window snapping.
On Monday 2015-06-22 10:02:56 Doug Torrance wrote: > On 06/21/2015 03:37 AM, Josip Deanovic wrote: > > I have just looked at the code and I think it could be done. > > > > This is what I did and it works fine. I have used 10px but it might > > be increased (lower than 10px wouldn't look good). > > > > It makes corner snapping much easier and it looks more like something > > people might be used to while working with other systems. > > I've adapted your patch a bit to make both the edge and corner detect > distances configurable. > > Carlos, the wireless I'm on currently isn't allowing me smtp access to > use git send-email. I've attached the patch -- I hope that's ok. > > Doug Thank you. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Workspace border patch
scr->totalUsableArea[i].y2 -= size;
+ break;
+ case WB_BOTTOMRIGHT:
+ scr->totalUsableArea[i].x2 -= size;
+ scr->totalUsableArea[i].y2 -= size;
+ break;
+ case WB_ALLDIRS:
scr->totalUsableArea[i].x1 += size;
scr->totalUsableArea[i].x2 -= size;
- }
- if (position & WB_TOPBOTTOM) {
scr->totalUsableArea[i].y1 += size;
scr->totalUsableArea[i].y2 -= size;
+ break;
+ default:
+ return;
}
}
}
diff -Nru wmaker-crm.next/src/WindowMaker.h wmaker-
crm.next.patched/src/WindowMaker.h
--- wmaker-crm.next/src/WindowMaker.h 2015-06-22 19:40:16.0
+0200
+++ wmaker-crm.next.patched/src/WindowMaker.h 2015-06-22
20:14:08.0 +0200
@@ -229,9 +229,17 @@
/* workspace border position */
#defineWB_NONE 0
-#defineWB_LEFTRIGHT1
-#defineWB_TOPBOTTOM2
-#define WB_ALLDIRS (WB_LEFTRIGHT|WB_TOPBOTTOM)
+#define WB_LEFT1
+#define WB_RIGHT 2
+#define WB_TOP 3
+#define WB_BOTTOM 4
+#define WB_LEFTRIGHT 5
+#define WB_TOPBOTTOM 6
+#define WB_TOPLEFT 7
+#define WB_TOPRIGHT8
+#define WB_BOTTOMLEFT 9
+#define WB_BOTTOMRIGHT 10
+#define WB_ALLDIRS 11
/* drag maximized window behaviors */
enum {
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Workspace border patch
Josip DeanovicOn Monday 2015-06-22 23:34:15 wrote: > Hi everyone > > I was playing with the workspace border feature and noticed that it > might be useful but it is rather limiting as one can only chose > left+right, top+bottom or all borders. > > It allows people to have an area which will not be covered by maximized > windows (unless they are set to full screen maximization) but it allows > only LeftRight and TopBottom combination While I would like to be able > to set it to Right only. > > After playing a bit with it I have created a patch which would allow a > user to set the WorkspaceBorder option to eight additional values: > Left, Right, Top, Bottom, TopLeft, TopRight, BottomLeft and BottomRight. > > I didn't modify WPrefs code. It is short with space but I think that > a menu with all the available values might do it. > > > Here is the patch: I have just noticed that "default:" and "return;" lines near the end of the patch should be removed. Sorry about that. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Monday 2015-06-22 21:55:55 Charles Philip Chan wrote: > On 22 Jun 2015, djosip+n...@linuxpages.net wrote: > > Yes but if you select "Shared application icon" check box in the > > window attributes then the double click would start another instance > > of the application. This is how it worked up until and including > > 0.95.3. > > Doesn't happen here. I use "Shared application icon" all the time and > double clicking does not launch a new instant. Sorry, my mistake. Its "No application icon" option, not "Shared application icon". I have just retested it. > > Windowmaker up until and including 0.95.3 would allow subsequent > > double clicks on the docked appicon to start new instances of the > > application which was probably incorrect from the windowmaker design > > (look and feel) perspective but some people learned to use that > > "feature". > > I have used "Window Maker" since the beginning and have never seen this. I have tested it with 0.80.2, windowmaker-0.95.3 and windowmaker-0.95.4. I have even used got bisect to find which patch changed the behavior. So the behavior I am reporting does exist, I have just mistakenly referred to "Shared application icon" instead of "No application icon". You can test it yourself if you are running 0.95.3 or older. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Tuesday 2015-06-23 10:57:24 BALATON Zoltan wrote: > On Tue, 23 Jun 2015, Josip Deanovic wrote: > > Sorry, my mistake. > > Its "No application icon" option, not "Shared application icon". > > I have just retested it. > > Ah, ok, that makes sense. If an app is set to not have an app icon it > cannot be attached to the dock so when you start it the instance will > not have an app icon so the docked one is not linked to the running > instance. Hence clicking on it again may start a new instance. This is > kind of consistent even if quite unintuitive. I agree. > > I have even used got bisect to find which patch changed the behavior. > > Did you find the patch that changed it? Or is this behaviour still > there? Yes, check my message sent in this thread on 2014-06-14 00:06 I'll paste it here so that you don't have to look for it. bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit commit bc0700e016c67791d3e3eab855543d849f4ce786 Author: Rodolfo GarcÃa Peñas (kix) Date: Mon Jun 18 11:15:19 2012 +0200 Create WAppIcon always When the application is created, the WAppIcon now is created always, but it is only painted if the flag is not set. The icon initialization to NULL can be done now at app_icon_create_from_docks because it is always called. :04 04 7c58877ad5af211acaddac5288848c2ade7b04cb 33d52affb385d22fbf04ebad3c628b714008785d M src -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] New library wmgeneral
On Friday 2015-08-14 11:06:16 Doug Torrance wrote: > On 08/14/2015 10:48 AM, Alexey I. Froloff wrote: > > On Thu, Aug 13, 2015 at 05:42:41PM +0200, Rodolfo García Peñas (kix) wrote: > >> This patch includes the library wmgeneral. > > > > Please, don't do it! There's already libdockapp, why would we > > need yet another _shared_ library with, like, five functions? > > What are you trying to fix? Does it really worth it? You only > > make things harder for a package maintainers. > > > > Better rewrite those applets to libdockapp. > > Speaking as the package maintainer for ~30 dockapps in Debian, I think > this is a great idea and makes it easier for me, not harder. > > For example, dockapps that use wmgeneral/list.c were recently not able > to compile with gcc5, and I've had to fix this individually in all my > wmgeneral dockapps in Debian. If the shared library had already > existed, I wouldn't have had to touch these packages individually and > just the library could have been updated. > > Certainly there would be the initial headache of packaging wmgeneral and > changing some lines of code in each dockapp to use the new library, but > it seems worth it to me. > > As far as there being two libraries, wmgeneral is by far more common. I > believe there's around 13 in the dockapps git repository that use it, > but only one or two that use libdockapp. It would be a lot of work to > port them all. On the other hand, I think libdockapp has a better, > more intuitive interface. > > Just my two cents, > Doug > > P.S. On a related note, I'd like to add the new library to the dockapps > portion of the website, but we need a version number to create a git tag > for my script to work. I suppose libwmgeneral-1.0 would be fine? I don't remember that I have ever had to compile wmgeneral library for the dockapps I am using but I might be wrong. On the other hand I am sure that some of the dockapps I am using depend on the libdockapp (e.g. wmnetload). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Set start-up resolution
On Monday 2015-08-17 10:09:07 Jack Montana wrote: > Hi all > > I have an external monitor placed above my laptop monitor. At start-up > WM puts VGA at right of LVDS by default. So any time I log-in I issue > the following: > > $ xrandr --output VGA1 --above LVDS1 > > Once monitors are correctly aligned I then need to issue a "Restart > Window Maker" from menu to make background correctly displayed and > dockapps correctly aligned. Who can I automatize this? > > Is there a way to tell WM to start with VGA above LVDS? Putting the > command in the autostart file still requires me to manually issue the > "Restart Window Maker" command. So, otherwise, is there a way to call > internal command "Restart Window Maker" from script? > > Thank you > Jack I have configured my /etc/X11/xorg.conf like this (this is the excerpt from my config file): Section "ServerLayout" Screen0 "Screen0" 0 0 Option"Xinerama" "on" ... EndSection Section "ServerFlags" Option "RandR""on" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Lenovo" Option "PreferredMode" "1600x900_60.00" Option "Position" "80 1050" Option "Primary" "true" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Dell" Option "PreferredMode" "1680x1050_60.00" Option "Position" "0 0" EndSection The Dell monitor (vga) would sit on top of the Lenovo (LVDS) hence the "Position" options. This configuration is probably using xinerama and not xrandrd but you can use xrandr later to change the layout and position of your monitors if you need. In my case the primary monitor will be the LVDS and it will be positioned under the VGA monitor. If I understood correctly this is what you are trying to achieve. Hope that helps. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Saturday 2015-08-22 10:51:40 Rodolfo García Peñas wrote: > Hi, > > if nobody is using these menus and nobody knows about them, my > proposal is remove this code. I will do it. Vote? Hi, Let's not remove anything until we find out what this really is. There are some features still missing because of such actions in the past. Since we don't yet know what usermenu and appmenu really are I can't say whether I am using that feature or not. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
> On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
> > Let's not remove anything until we find out what this really is.
> > There are some features still missing because of such actions in
> > the past.
>
> Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject "Double-click on application in
wmdock does not launch the application if one instance is already
running".
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > Hi Josip, > > thanks for your report. Sorry about that. Patch is attached. > > Perhaps we should use a different flag to run the application more > times from the same dock icon. I have no objections to that as long as that feature exists and the option is intuitive and logical and doesn't break anything else. :-) Note that in older Windowmaker versions (up until (and I think including but I am not sure any more) 0.95.3) double click on the docked icon could be used to execute multiple instances of the application only if the window attributes of the application are set so that application icon is disabled for that specific application (it's in the window attributes options under the Application Specific menu and the option is represented as "No application icon"). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Sunday 2015-08-23 11:25:57 BALATON Zoltan wrote: > On Sat, 22 Aug 2015, Josip Deanovic wrote: > > On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: > >> Which feature was removed that you are missing? > > > > The one I am talking for over a year now. :-) > > Also app icon caching was broken around the same time. The app icon > cache in CachedPixmaps was meant to store icons retrieved from X > clients so the dock or clip can display those when the client is not > running like after startup. The cache should contain only such icons > and the path should never appear in WMWindowAttributes because the > cache is an internal thing used to look up icons not otherwise > available. If you look at your WMWindowAttributes now it is full of > entries referring to the cache that should not be there and if you look > at the cache dir you'll find a lot of icons from all apps you've ever > started while there should be only the few docked ones that use client > side icons. Also the cache is never cleaned up only new icons are added > to it. > > The icon handling code was a bit complicated before but worked (maybe > cache cleanup was broken before) until overzealous simplification > attempts have messed it up so much that it is now difficult to > untangle. Even more so because the object oriented design was also > messed up by renaming and moving methods around so now it is not clear > what object methods these functions were meant to be. > > I think the principles to follow should be: > > 1. K.I.S.S. > 2. If ain't broke don't fix it. > 3. If you don't understand it don't touch it. (That is, think about all > possible implications of your proposed change because it may work > with your particular settings but a lot of things can be set by > preferences.) > > Regards, > BALATON Zoltan I have noticed that something has changed several years ago regarding this but didn't give much attention to it. Good thing that you have summarized it like this. I wonder if Carlos is able to keep track of all the confirmed and unconfirmed reports that appear on the list through the years. I mean, this report could also get forgotten unless someone continues to remind people about it. Maybe it would be a good idea to start a thread about the bug report and feature request page semi-independent of this list. I know that there was some initiative in the past and I wouldn't like that it grows into a conflict over different solutions and code maintenance again. I like things the way they are and as a user I just feel the need for bug and feature-request report page. That would help users and developers to see what is already reported, what needs to be tested (in order to confirm the potential bug) and what is still waiting to be fixed. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > On Sun, 23 Aug 2015 at 18:16:32 +0200, Josip Deanovic wrote: > > On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > > > Hi Josip, > > > > > > thanks for your report. Sorry about that. Patch is attached. > > Thank you, Rodolfo. Yes, thank you from me too. > Josip, the patch should fix the issue and it's in the #next > branch already. Would you mind testing it? I'll test it in the next 30 minutes. > > > Perhaps we should use a different flag to run the application more > > > times from the same dock icon. > > > > I have no objections to that as long as that feature exists and the > > option is intuitive and logical and doesn't break anything else. :-) > > Note that the issue you found is not intuitive nor logical :-) I didn't find it, my friend pointed it to me and I somehow still remembered that feature from like 20 years ago so I needed to inspect it to confirm that it actually stopped working few years ago. Anyway I didn't put that feature there but it's handy. :-) > There is no reason why the setting of the "No application icon" should > have an effect on being able to execute multiple instances of a docked > application. The "No application icon" option should control just the > application icon, nothing else. I agree. > So what Rodolfo did originally was correct -- he enforced the behavior > that the option stands for. The "execute multiple instances" happened > to work before by chance. > > But nevermind, a regression is a regression and thank you for > reporting it multiple times; it should work again with the latest > patch but ideally this behavior should not be coupled with this > particular option. It would be nice to decouple them then. It would help to avoid loosing the feature in the future. I would suggest adding another option to the Application Specific menu of the Window attributes window. There is a plenty of space there and the only thing that is left to discuss in that case is whether this option should work only in case application icons are disabled for the specific docked application or always. If the option is allowed to be activated even if the application icon is not disabled that could produce some confusion. So in my opinion, ideally the new option should be inactive (disabled/grayed-out) unless the "No application icon" is selected. And by default the new option should be disabled (unselected) by default. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip DeanovicOn Sunday 2015-08-23 19:25:32 wrote: > On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > > Josip, the patch should fix the issue and it's in the #next > > branch already. Would you mind testing it? > > I'll test it in the next 30 minutes. Ok, I have tested it and I can confirm that feature now works but while testing it I have encountered undesirable issues such as windowmaker crash and restart. So this is the procedure I used while testing: 1. I am using kwrite application for my tests 2. Start kwrite application on the command line 3. Checking Application Specific window attributes - No application icon - unselected - Shared application icon - selected 4. Drag the application icon to the dock 5. Enable (select) the option No application icon for the application 6. Close the application and run multiple instances of the application using double-click on the docked icon - everything works fine 7. In the application Specific menu disable (unselect) the option No application icon - windowmaker crashes and restarts -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:48:27 Carlos R. Mafra wrote: > Perhaps it would be better to not even have an option for this, > it should always be possible to execute a docked app multiple times. It already is but only if you use right click and Launch menu option. Double-click has different behavior based on whether the "No application icon" is enabled or not for a specific application. I have checked and described the behavior thoroughly in the thread with the subject: "Double-click on application in wmdock does not launch the application if one instance is already running" > And indeed, one needs to think about what to do with the appicons. > Perhaps just silently behaving as "no appicon" is set starting from > the second instance, I don't know. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:32:06 Rodolfo García Peñas wrote: > Hi Josip, > > confirmed, I am working on it. > > Thanks Cool. Thank you. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > Solved. > > Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 20:02:58 Rodolfo García Peñas wrote: > Quoting Josip Deanovic : > > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > >> Solved. > >> > >> Thanks for your report. > > > > Thank you for the effort. > > > > I have just tested the code from the fresh next branch and > > the issue still exist (Windowmaker crashes and restarts). > > Using the same steps? Yes. I have even relog (not just restart) to make sure that wmaker has been completely restarted. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 20:17:08 Rodolfo García Peñas wrote: > Thanks, > > I will continue with this problem tomorrow. I think I know the > problem, but I need do a deep analysis. Ok, thank you. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:06:30 Carlos R. Mafra wrote: > On Sun, 23 Aug 2015 at 21:28:02 +0200, Josip Deanovic wrote: > > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > > > Solved. > > > > > > Thanks for your report. > > > > Thank you for the effort. > > > > I have just tested the code from the fresh next branch and > > the issue still exist (Windowmaker crashes and restarts). > > But the #next branch doesn't contain Rodolfo's patches yet. He, he, that might be the source of the problem. :-) Ok, where can I get the newest change? I didn't notice any patch attached. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: > > Ok, where can I get the newest change? I didn't notice any patch > > attached. > It is there now. Ok, I'll test it now. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: > It is there now. I have compiled a newest version and tested every combination I could think of and works fine. No crash any more, feature works as expected. I would say that we can close this case. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
