Re: [i3] full screencapture with xwd not working only in i3

[Ingo Bürk]

Hi,

the command works fine for me. What version if i3 are you running? Is
your Xorg up to date?
Also, judging from the xwd source code, maybe you can try adding
"-icmap" to the arguments.


Ingo

On 11/15/2015 09:47 AM, Zenny wrote:
> Hi,
>
> I am having problem to take screenshot with xwd*** only in a full
> screenshot mode (but selective screenshot works). This only happens
> with i3, but not with other window managers. Please find the log
> below, fyi.
>
>
> ***PS: I am aware of other tools like scrot, maim and what not, but I
> need this specific xwd to capture a virtual screen running in a
> frambuffer with xvfb which others do not support, if you have any
> tools that can screencapture a virtual x server, let me know.
> Apprexciate that.
>
>
> USER@MACHINE:~/Downloads/xwd$ xwd -root -out i3screenshot_xwd.xwd
> X Error of failed request:  BadColor (invalid Colormap parameter)
>   Major opcode of failed request:  91 (X_QueryColors)
>   Resource id in failed request:  0x0
>   Serial number of failed request:  166
>   Current serial number in output stream:  166
> USER@MACHINE:~/Downloads/xwd$ xwd > i3screenshot_xwd_frame.xwd
> USER@MACHINE:~/Downloads/xwd$ ls -la i3screenshot*.xwd
> -rw-rw-r-- 1 USER USER 3995469 Nov 15 08:33 i3screenshot_xwd_frame.xwd
> -rw-rw-r-- 1 USER USER   0 Nov 15 08:33 i3screenshot_xwd.xwd
>
> Any inputs appreciated!
>
> Cheers.
> /z

Re: [i3] binding the same key to revert the command?

[Ingo Bürk]

Hi,

one possible solution: save the following as /some/path/stopcont.sh and bind

bindsym $mod+p exec --no-startup-id /some/path/stopcont.sh 

Script:
===
#!/usr/bin/env bash
PROCESS=${1}
FILE="/tmp/${PROCESS}.signal"

if [[ -f "${FILE}" ]]; then
  rm ${FILE}
  pkill -SIGCONT ${PROCESS}
else
  touch ${FILE}
  pkill -SIGSTOP ${PROCESS}
fi
===

This will, of course, assume that the process isn't paused by anything
else as that would make it go out of sync. A better and more robust way
would be to write the script such that it instead uses the information
of /proc//stat to check whether the process is currently paused. If
you use a higher-level language such as Python, you can do this nicely
instead of manually parsing the output. See [1] for some more information.

[1]
http://stackoverflow.com/questions/6021771/is-there-a-way-to-determine-if-a-linux-pid-is-paused-or-not


Ingo

On 11/08/2015 04:16 AM, Zenny wrote:
> Hi,
>
> I am trying to use a keybinding to pause a process temporily,
>
> bindsym $mod+p exec pkill -SIGSTOP 
>
> But I could not figure out how to make pressing to same keybinding to
> restart the process?
>
> Currenlty I am using,
>
> bindsym $mod+c exec pkill -SIGCONT 
>
> Instead, I want something like re-pressing $mod+p executes pkill
> -SIGCONT .
>
> Thanks!
>
> /z

Re: [i3] binding the same key to revert the command?

[Ingo Bürk]

Hi,

sorry, my last email didn't go to the mailing list which I diidn't even
notice until this email. Below is my previous email as a quote which
also has a script using /proc/../stat. Never hurts to have multiple
solutions :)
> Hi,
>
> here's a script using /proc/.../stat. The usage is as before. The only
> assumption now is that the process is running exactly once.
>
> 
> #!/usr/bin/env bash
> PROCESS=${1}
> STATE=$(cat /proc/$(pgrep ${PROCESS})/stat | awk -F' ' '{print $3}')
>
> [[ "${STATE}" = "T" ]] && pkill -SIGCONT ${PROCESS} || pkill -SIGSTOP
> ${PROCESS}
> =



On 11/08/2015 05:22 PM, Joep van Delft wrote:
> Elaborating on Ingo's hints: Something like this could be used to not
> to have
> to maintain the state somewhere on disk:
>
> ===
> #!/usr/bin/env bash
> process_name=$1
> for pid in $(pgrep --exact $process_name); do
> # Assumes there is no space in the command name
> if   awk '$3=="T"{exit 1}' /proc/$pid/stat 2>/dev/null
> then kill -SIGCONT $pid
> else kill -SIGKILL $pid
> fi
> done
> ===
>
>
> Kind regards,
>
> Joep
>
>
> Ingo Bürk schreef op 2015-11-08 10:30:
>> Hi,
>>
>> one possible solution: save the following as /some/path/stopcont.sh
>> and bind
>>
>> bindsym $mod+p exec --no-startup-id /some/path/stopcont.sh
>> 
>>
>> Script:
>> ===
>> #!/usr/bin/env bash
>> PROCESS=${1}
>> FILE="/tmp/${PROCESS}.signal"
>>
>> if [[ -f "${FILE}" ]]; then
>>   rm ${FILE}
>>   pkill -SIGCONT ${PROCESS}
>> else
>>   touch ${FILE}
>>   pkill -SIGSTOP ${PROCESS}
>> fi
>> ===
>>
>> This will, of course, assume that the process isn't paused by anything
>> else as that would make it go out of sync. A better and more robust way
>> would be to write the script such that it instead uses the information
>> of /proc//stat to check whether the process is currently paused. If
>> you use a higher-level language such as Python, you can do this nicely
>> instead of manually parsing the output. See [1] for some more
>> information.
>>
>> [1]
>> http://stackoverflow.com/questions/6021771/is-there-a-way-to-determine-if-a-linux-pid-is-paused-or-not
>>
>>
>>
>> Ingo
>>
>> On 11/08/2015 04:16 AM, Zenny wrote:
>>> Hi,
>>>
>>> I am trying to use a keybinding to pause a process temporily,
>>>
>>> bindsym $mod+p exec pkill -SIGSTOP 
>>>
>>> But I could not figure out how to make pressing to same keybinding to
>>> restart the process?
>>>
>>> Currenlty I am using,
>>>
>>> bindsym $mod+c exec pkill -SIGCONT 
>>>
>>> Instead, I want something like re-pressing $mod+p executes pkill
>>> -SIGCONT .
>>>
>>> Thanks!
>>>
>>> /z

Re: [i3] ssh askpass window too small + "sticks around"

[Ingo Bürk]

No, it's not i3. It's the root window. Which means there is no actual
keepass window. :) I'd try running a compositor and setting the
background to see what that does. Making sure your graphics driver is up
to date also won't hurt.


Ingo

On 11/04/2015 11:15 PM, Dieter Plaetinck wrote:
> with background it looks like so (set via nitrogen)
> http://i.imgur.com/RX7syWq.png
> however it seems like if i set the background again after ssh-add finished, 
> the background shows fine without the ghost window. not 100% sure yet on the 
> conditions that trigger the issue. i can play with it a bit more and can 
> probably succesfully work around it. (though it's still weird)
>
>
> process is no longer running:
> ~ ❯❯❯ ps aux | grep ssh-add
> dieter4286  0.0  0.0  10728  2384 pts/3S+   23:07   0:00 grep 
> --color=auto ssh-add
> ~ ❯❯❯ ps aux | grep keepass
> dieter4315  0.0  0.0  10728  2248 pts/3S+   23:07   0:00 grep 
> --color=auto keepass
> ~ ❯❯❯ ps aux | grep x11
> dieter4352  0.0  0.0  10728  2140 pts/3S+   23:07   0:00 grep 
> --color=auto x11
> ~ ❯❯❯ 
>
>
> when i run xprop and then click on the ghost window i get:
> ~ ❯❯❯ xprop
> GDK_VISUALS(INTEGER) = 233, 165
> _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 0, 0
> _NET_DESKTOP_NAMES(UTF8_STRING) = "1", "2", "3", "4", "5", "6", "7", "8"
> _NET_NUMBER_OF_DESKTOPS(CARDINAL) = 8
> _NET_CURRENT_DESKTOP(CARDINAL) = 5
> I3_SHMLOG_PATH(UTF8_STRING) = "/i3-log-769"
> I3_CONFIG_PATH(UTF8_STRING) = "/home/dieter/.i3/config"
> I3_PID(CARDINAL) = 769
> I3_SOCKET_PATH(UTF8_STRING) = "/run/user/1011/i3/ipc-socket.769"
> _NET_ACTIVE_WINDOW(WINDOW): window id # 0x0
> _NET_CLIENT_LIST(WINDOW): window id # 0x103, 0x1a1, 0x180009b, 
> 0x143, 0x207, 0x243, 0x263, 0x283
> _NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x207, 0x243, 
> 0x180009b, 0x263, 0x1a1, 0x103, 0x283, 0x143
> _NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, 
> _NET_WM_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_MOVERESIZE, _NET_WM_STATE_STICKY, 
> _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION, 
> _NET_WM_STATE_MODAL, _NET_WM_STATE_HIDDEN, _NET_WM_STATE, 
> _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_DOCK, 
> _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_UTILITY, 
> _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_SPLASH, 
> _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, 
> _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_DESKTOP, 
> _NET_WM_STRUT_PARTIAL, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, 
> _NET_CURRENT_DESKTOP, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, 
> _NET_DESKTOP_VIEWPORT, _NET_ACTIVE_WINDOW, _NET_CLOSE_WINDOW
> _NET_WM_NAME(UTF8_STRING) = "i3"
> _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x800062
> RESOURCE_MANAGER(STRING) = 
> "urxvt.font:\txft:Terminus\nx11-ssh-askpass*font:\t-*-dina-medium-r-*-*-12-*-*-*-*-*-*-*\nx11-ssh-askpass*background:\t#00\nx11-ssh-askpass*foreground:\t#ff\nx11-ssh-askpass.Button*background:\t#00\nx11-ssh-askpass.Indicator*foreground:\t#ff9900\nx11-ssh-askpass.Indicator*background:\t#090909\nx11-ssh-askpass*topShadowColor:\t#00\nx11-ssh-askpass*bottomShadowColor:\t#00\nx11-ssh-askpass.*borderWidth:\t1\n"
> ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0x64
> _XROOTPMAP_ID(PIXMAP): pixmap id # 0x64
> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "dvorak", "", ""
> XFree86_has_VT(INTEGER) = 1
> XFree86_VT(INTEGER) = 1
> ~ ❯❯❯ 
>
>
> am i seeing this right? it's i3 itself?
>
> On Wed, 4 Nov 2015 09:43:45 -0500
> Ingo Bürk <ad...@airblader.de> wrote:
>
>> Hi Dieter,
>>
>> sorry, I completely forgot about the second issue. Can you check whether
>> there actually IS a window? For example, try pgrep-ing for keepass and
>> also try "xprop"-selecting that window on an empty workspace (where it's
>> not covered by other windows).
>>
>> If there isn't actually a window, this sounds like a typical graphics
>> glitch. If you haven't set a background to your desktop yet, you should
>> do this, even if you want it to be just black. See [1] for some
>> orientation. If that's done and the issue persists, I'd try running a
>> compositor (e.g., compton) if you aren't already. If it STILL persists
>> after that, I would look into my graphics driver.
>>
>> However, if there actually IS a window, tell the keepass guys to look
>> into it. :)
>>
>> [1]
>

Re: [i3] ssh askpass window too small + "sticks around"

[Ingo Bürk]

Hi Dieter,

sorry, I completely forgot about the second issue. Can you check whether
there actually IS a window? For example, try pgrep-ing for keepass and
also try "xprop"-selecting that window on an empty workspace (where it's
not covered by other windows).

If there isn't actually a window, this sounds like a typical graphics
glitch. If you haven't set a background to your desktop yet, you should
do this, even if you want it to be just black. See [1] for some
orientation. If that's done and the issue persists, I'd try running a
compositor (e.g., compton) if you aren't already. If it STILL persists
after that, I would look into my graphics driver.

However, if there actually IS a window, tell the keepass guys to look
into it. :)

[1]
https://faq.i3wm.org/question/6/how-can-i-set-a-desktop-background-image-in-i3/


Ingo

On 11/03/2015 10:21 PM, Dieter Plaetinck wrote:
> btw i have configured the askpass window to have a 0px border,
> so the other problem (the "ghosting") is now a little less annoying
> (looks like http://i.imgur.com/qgnOTaV.png now)
> though it 'd be nice if we could solve this one too. any ideas ?
>
>
>
> On Tue, 3 Nov 2015 20:57:45 -0500
> Dieter Plaetinck <die...@plaetinck.be> wrote:
>
>> thanks Ingo,
>> reported @ https://bugzilla.mindrot.org/show_bug.cgi?id=2491
>>
>> btw I tried setting the window to 426x94 (cause those values appeared in 
>> other size hints)
>> but that ended up being too low.  I just estimated a height and 115 seems to 
>> look good.
>> I wonder why it hinted at 94..
>>
>> On Tue, 3 Nov 2015 19:59:45 -0500
>> Ingo Bürk <ad...@airblader.de> wrote:
>>
>>> Hi,
>>>
>>> one more thing, to make life easier for yourself you can either locally
>>> revert the commit or use a for_window directive matching that popup and
>>> do something like
>>>
>>> for_window [class="(?i)keepass" …] resize set 500 300
>>>
>>>
>>>
>>> Ingo
>>>
>>> On 11/03/2015 07:43 PM, Ingo Bürk wrote:  
>>>> Thanks! Yeah, the problem is that askpass specifies size flags in
>>>> WM_SIZE_HINTS, but doesn't set useful values (it just says 0x0). i3 then
>>>> falls back to the floating minimum size, which by default is 75x50. You
>>>> should file this as a bug against keepass. keepass should either not set
>>>> these flags in the size hints or give them a reasonable value.
>>>>
>>>> It should be noted that these values in the size hints are considered
>>>> obsolete[1], but that doesn't mean they won't (or shouldn't) be
>>>> interpreted. That's what the flag mask is for. :)
>>>>
>>>> [1]
>>>> https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html
>>>>
>>>>
>>>> Ingo
>>>>
>>>> On 11/03/2015 06:51 PM, Dieter Plaetinck wrote:
>>>>> the i3 log, obtained via i3-dump-log as described on the debugging web 
>>>>> page.
>>>>> http://logs.i3wm.org/logs/5652536396611584.bz2
>>>>> FWIW this was a minimal i3 session, i quit all my apps, just had a 
>>>>> termite terminal so i could invoke ssh-add and the i3-dump-log, and it 
>>>>> also had a bar running, but nothing else.
>>>>>
>>>>> xprop and xwininfo -all output: 
>>>>> https://gist.github.com/Dieterbe/93ec75c6e891a04b8776
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 3 Nov 2015 18:09:10 -0500
>>>>> Ingo Bürk <ad...@airblader.de> wrote:
>>>>>
>>>>>> Thanks. I sort of figured it'd be that commit. Can you please provide
>>>>>> the files I described earlier? This will likely be a bug in askpass. See
>>>>>> also the discussions in the end of https://github.com/i3/i3/issues/1970.
>>>>>>
>>>>>>
>>>>>> Ingo
>>>>>>
>>>>>> On 11/03/2015 06:04 PM, Dieter Plaetinck wrote:
>>>>>>> thanks Ingo,
>>>>>>> due to i3's easy reloading and the fact that i could just run the 
>>>>>>> ssh-add command in a terminal without restarting X, the bisect process 
>>>>>>> was very easy and smooth.
>>>>>>>
>>>>>>> it found the commit. see below
>>>>>>>
>>>>>>> d1262f2b6ae713266b5a1e8cab368333bb332033 is the first bad commit
>>>>>>> commit d12

Re: [i3] ssh askpass window too small + "sticks around"

[Ingo Bürk]

Yeah, a bisect would be useful. You need to run make clean && make &&
sudo make install (to actually install the new binary -- unless you
change your xinitrc to run the local file in your checkout instead).

Restarting X isn't necessary, restarting i3 in-place would suffice. But
since you have wrapped askpass around the i3 session, you'll indeed
probably need to exit your X session and startx again.


Ingo

On 11/03/2015 04:46 PM, Dieter Plaetinck wrote:
> I can confirm the first problem is gone (the window has the correct size) 
> with 4.10.4
> However the ghosting problem still exists, though now it also has the correct 
> size and a black background instead of grey like before.
> see http://i.imgur.com/2uF25R8.png
>
> still want me to do a bisect? for all versions i would just run make clean && 
> make && restart x using the new i3 binary right? anything else needed?
>
> Dieter
>
> On Tue, 3 Nov 2015 16:05:31 -0500
> Ingo Bürk <ad...@airblader.de> wrote:
>
>> Hi Dieter,
>>
>> can you do the following?
>>
>> 1) Downgrade to i3 4.10.4 and see if it fixes the problem. If so, please
>> run a git bisect to figure out which commit broke it. If 4.10.4 has the
>> same problem, try downgrading askpass or report a bug there.
>> 2) Provide a complete i3 log file where you started it. See the
>> debugging docs on the i3 website for information. Also provide the
>> output of "xprop" and "xwininfo -all" when clicking on the opened
>> askpass window.
>>
>>
>> Ingo
>>
>> On 11/03/2015 03:32 PM, Dieter Plaetinck wrote:
>>> hello everyone,
>>> long time no see! i've been a long time i3 user but only since a recent 
>>> upgrade i've started having issues with 
>>> ssh-askpass.
>>>
>>>
>>> to be specific, in my .xinitrc I have:
>>>
>>> i3 -d all >> ~/i3-out 2>> ~/i3-err &
>>> waitpid=$!
>>> ssh-add ~/.ssh/id_rsa_dieter-ws-a7n8x-arch < /dev/null
>>> (.. some more stuff)
>>> wait $waitpid
>>>
>>> i posted my i3 config to 
>>> https://gist.github.com/Dieterbe/d5870b230369818d2d47 (it's pretty much 
>>> default, with a few extra binds and a different bar)
>>>
>>>
>>> the ssh-add spawns the x11-ssh-askpass program and since recently i've been 
>>> seeing these two problems:
>>>
>>> screenshots of both issues @ http://imgur.com/a/TbNn1
>>>
>>> 1) the window is way too small. it used to be just the right size for the 
>>> popup.
>>>
>>> 2) after entering the password and hitting enter, a "ghost" of the window 
>>> stays stuck in all of my i3 workspaces.
>>> those workspaces that have windows in them will have the windows cover it, 
>>> but otherwise if i go to say workspace number 5 while no windows are there, 
>>> it'll show a ghost of the ask pass window.
>>>
>>> any idea what might be the cause? i'm using 4.11
>>>
>>> thanks,
>>> Dieter  

Re: [i3] ssh askpass window too small + "sticks around"

[Ingo Bürk]

Hi Dieter,

can you do the following?

1) Downgrade to i3 4.10.4 and see if it fixes the problem. If so, please
run a git bisect to figure out which commit broke it. If 4.10.4 has the
same problem, try downgrading askpass or report a bug there.
2) Provide a complete i3 log file where you started it. See the
debugging docs on the i3 website for information. Also provide the
output of "xprop" and "xwininfo -all" when clicking on the opened
askpass window.


Ingo

On 11/03/2015 03:32 PM, Dieter Plaetinck wrote:
> hello everyone,
> long time no see! i've been a long time i3 user but only since a recent 
> upgrade i've started having issues with 
> ssh-askpass.
>
>
> to be specific, in my .xinitrc I have:
>
> i3 -d all >> ~/i3-out 2>> ~/i3-err &
> waitpid=$!
> ssh-add ~/.ssh/id_rsa_dieter-ws-a7n8x-arch < /dev/null
> (.. some more stuff)
> wait $waitpid
>
> i posted my i3 config to 
> https://gist.github.com/Dieterbe/d5870b230369818d2d47 (it's pretty much 
> default, with a few extra binds and a different bar)
>
>
> the ssh-add spawns the x11-ssh-askpass program and since recently i've been 
> seeing these two problems:
>
> screenshots of both issues @ http://imgur.com/a/TbNn1
>
> 1) the window is way too small. it used to be just the right size for the 
> popup.
>
> 2) after entering the password and hitting enter, a "ghost" of the window 
> stays stuck in all of my i3 workspaces.
> those workspaces that have windows in them will have the windows cover it, 
> but otherwise if i go to say workspace number 5 while no windows are there, 
> it'll show a ghost of the ask pass window.
>
> any idea what might be the cause? i'm using 4.11
>
> thanks,
> Dieter

Re: [i3] ssh askpass window too small + "sticks around"

[Ingo Bürk]

Hi,

one more thing, to make life easier for yourself you can either locally
revert the commit or use a for_window directive matching that popup and
do something like

for_window [class="(?i)keepass" …] resize set 500 300



Ingo

On 11/03/2015 07:43 PM, Ingo Bürk wrote:
> Thanks! Yeah, the problem is that askpass specifies size flags in
> WM_SIZE_HINTS, but doesn't set useful values (it just says 0x0). i3 then
> falls back to the floating minimum size, which by default is 75x50. You
> should file this as a bug against keepass. keepass should either not set
> these flags in the size hints or give them a reasonable value.
>
> It should be noted that these values in the size hints are considered
> obsolete[1], but that doesn't mean they won't (or shouldn't) be
> interpreted. That's what the flag mask is for. :)
>
> [1]
> https://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html
>
>
> Ingo
>
> On 11/03/2015 06:51 PM, Dieter Plaetinck wrote:
>> the i3 log, obtained via i3-dump-log as described on the debugging web page.
>> http://logs.i3wm.org/logs/5652536396611584.bz2
>> FWIW this was a minimal i3 session, i quit all my apps, just had a termite 
>> terminal so i could invoke ssh-add and the i3-dump-log, and it also had a 
>> bar running, but nothing else.
>>
>> xprop and xwininfo -all output: 
>> https://gist.github.com/Dieterbe/93ec75c6e891a04b8776
>>
>>
>>
>>
>> On Tue, 3 Nov 2015 18:09:10 -0500
>> Ingo Bürk <ad...@airblader.de> wrote:
>>
>>> Thanks. I sort of figured it'd be that commit. Can you please provide
>>> the files I described earlier? This will likely be a bug in askpass. See
>>> also the discussions in the end of https://github.com/i3/i3/issues/1970.
>>>
>>>
>>> Ingo
>>>
>>> On 11/03/2015 06:04 PM, Dieter Plaetinck wrote:
>>>> thanks Ingo,
>>>> due to i3's easy reloading and the fact that i could just run the ssh-add 
>>>> command in a terminal without restarting X, the bisect process was very 
>>>> easy and smooth.
>>>>
>>>> it found the commit. see below
>>>>
>>>> d1262f2b6ae713266b5a1e8cab368333bb332033 is the first bad commit
>>>> commit d1262f2b6ae713266b5a1e8cab368333bb332033
>>>> Author: Andrzej Pronobis <a.prono...@gmail.com>
>>>> Date:   Sun Feb 1 17:04:41 2015 -0800
>>>>
>>>> Use WM_SIZE_HINTS whenever it's provided to set the geometry of 
>>>> floating windows.
>>>>
>>>> :04 04 e7c887b2b14e2b24830840133045fe0ba232c3e0 
>>>> 3dd6d2d2864ab7aaec50cb2bff93031170bd50e8 M src
>>>> ~/w/e/i3 ❯❯❯ 
>>>>
>>>>
>>>> On Tue, 3 Nov 2015 17:19:02 -0500
>>>> Ingo Bürk <ad...@airblader.de> wrote:
>>>>  
>>>>> Yeah, a bisect would be useful. You need to run make clean && make &&
>>>>> sudo make install (to actually install the new binary -- unless you
>>>>> change your xinitrc to run the local file in your checkout instead).
>>>>>
>>>>> Restarting X isn't necessary, restarting i3 in-place would suffice. But
>>>>> since you have wrapped askpass around the i3 session, you'll indeed
>>>>> probably need to exit your X session and startx again.
>>>>>
>>>>>
>>>>> Ingo
>>>>>
>>>>> On 11/03/2015 04:46 PM, Dieter Plaetinck wrote:  
>>>>>> I can confirm the first problem is gone (the window has the correct 
>>>>>> size) with 4.10.4
>>>>>> However the ghosting problem still exists, though now it also has the 
>>>>>> correct size and a black background instead of grey like before.
>>>>>> see http://i.imgur.com/2uF25R8.png
>>>>>>
>>>>>> still want me to do a bisect? for all versions i would just run make 
>>>>>> clean && make && restart x using the new i3 binary right? anything else 
>>>>>> needed?
>>>>>>
>>>>>> Dieter
>>>>>>
>>>>>> On Tue, 3 Nov 2015 16:05:31 -0500
>>>>>> Ingo Bürk <ad...@airblader.de> wrote:
>>>>>>
>>>>>>> Hi Dieter,
>>>>>>>
>>>>>>> can you do the following?
>>>>>>>
>>>>>>> 1) Downgrade to i3 4.10.4 and see if it fixes the problem. If so, please
>

Re: [i3] Killing a window's process

[Ingo Bürk]

xkill?

On 10/02/2015 11:12 AM, Jeff Abrahamson wrote:
> I have a window whose process is not responding.  No problem, i3 lets me
> kill windows, so I type that key combination.  Usually it works, but this
> time it doesn't.
>
> My work-around is to use wininfo to find the window id of the dead but
> mapped thing, bc to convert to decimal, use "ps aeww | grep" to find the
> process with that window id in its environment, then send it a kill -15
> (does nothing visible) and then a kill -9 (still mapped, but process now
> shows as defunct).
>
>
> So the* problem* (obviously not critical, since I have a work-around) is
> how could I have avoided the wininfo -> ps -> bc -> kill thing.  Looking at
> the code, it looks like i3's kill window is cmd_kill
> () in commands.c.
> (How can that get called with kill_mode_str == "client"?)  The chain is
> then to call tree_close_con
> () -> tree_close
> () -> x_window_kill
> () -> one_of {
> xcb_destroy_window
> (),
> xcb_kill_client
> () }.
>
> I think to answer that I'l have to run i3 with logging so I can see which
> path it's taking at the end.  And wait for an appropriately hung process.
> My initial hypothesis is that the window supports WM_DELETE_WINDOW but,
> since the proc is hung, it never processes it.
>
>
> Anyway, thanks for any insights.  Clearly this is as much about me learning
> as anything else.
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only when I'm in the UK
>
> *http://www.ml-week.com/fr/* * 2-5 novembre
> 2015*
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>

Re: [i3] managing wifi with i3

[Ingo Bürk]

The window manager is neither responsible nor involved in network
management at all, so I'm afraid you're looking in the wrong direction here.

On 10/01/2015 10:34 AM, Robert Grah wrote:
>
> Hey there,
>
>
>
> I am having some problems getting wifi to work in i3. I tried to add
>
>
>
> exec--no-startup-id nm-applet
> to my config and this braught me the icon, but it can not find any wifi 
> networks.
>
> It seems that there are some problems with the session or similar. I also 
> tried wicd or gnome-network-manager all without results. 
>
>
>
> I am using Ubuntu 15.04 and i3 4.10.4.
>
>
>
> Any ideas?
>
>
>
>

Re: [i3] flash player plugin broken with i3 4.10.4

[Ingo Bürk]

I don't understand how the window manager is relevant for this. Are you
sure you didn't also update your browser or flash or anything else?

On 09/13/2015 05:14 PM, Robert Grah wrote:
> Hi there,
>
> I updated from the stable Ubuntu version of i3 to 4.10.4 via the official 
> ppa. After that upgrade I am having a problem with my flash plugin in the 
> browser (chrome and firefox). The plugin is not loaded properly and is not 
> recognized correctly by pages. Any ideas on this? Here is my LOG file: 
> http://logs.i3wm.org/logs/5685057352105984.bz2
>
> Cheers,
> Robert
>
>
>
>
>
>
>

Re: [i3] Keep windows focused on workspace move

[Ingo Bürk]

Yes, true. I guess I was too quick on that. :)

On 09/03/2015 08:45 PM, Michael Stapelberg wrote:
> Yeah, but bindsym doesn’t match anything. You need to use criteria to
> match windows.
>
> On Thu, Sep 3, 2015 at 8:44 PM, Ingo Bürk <ad...@airblader.de> wrote:
>> It should work with just "focus" because the separation with a comma
>> means the focus command will still be ran on the matched window.
>>
>> On 09/03/2015 08:40 PM, Michael Stapelberg wrote:
>>> What are you trying to accomplish with “exec i3-msg workspace $WS1”?
>>> This is equivalent to just “workspace $WS1”, but will be executed
>>> out-of-order because it spawns a new process in the background which
>>> sends the command.
>>>
>>> Also, I think the “focus” command used on its own (i.e. without any
>>> criteria) is a no-op.
>>>
>>> The previously mentioned “move container to workspace 1, workspace 1”
>>> command is the way to go.
>>>
>>> On Wed, Sep 2, 2015 at 4:59 PM, Serge Kroes <se...@kroescontrol.nl> wrote:
>>>> Hi
>>>>
>>>> i'm using this:
>>>> bindsym $mod+Shift+1 move container to workspace $WS1, exec i3-msg 
>>>> workspace
>>>> $WS1, focus
>>>>
>>>>
>>>> On Wed, Sep 2, 2015 at 4:38 PM, Florian Lindner <mailingli...@xgm.de> 
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> Am Mittwoch, 2. September 2015, 16:17:56 schrieb Mateusz Poszwa:
>>>>>> Je 2015-09-02 16:06:41
>>>>>> Florian Lindner <mailingli...@xgm.de> skribis:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> when I move a window from a workspace to another (mod + shift + num)
>>>>>>> it looses the focus and a window (or parent) of the originating 
>>>>>>> workspace is
>>>>>>> focused.
>>>>>>>
>>>>>>> How can I have the window to stay focused when moved across
>>>>>>> workspaces?
>>>>>>>
>>>>>>> Use case:
>>>>>>> I have a conversation open on the small and farer away laptop screen.
>>>>>>> I see activity there and I move it to one of my main screens. I want it 
>>>>>>> to
>>>>>>> keep focused.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Florian
>>>>>> Hello.
>>>>>>
>>>>>> Try to change your binding from
>>>>>> move workspace «X»
>>>>>> to
>>>>>> move workspace «X», focus workspace «X»
>>>>> I have set it to:
>>>>>
>>>>> bindsym $mod+Shift+1 move container to workspace 1, focus workspace 1
>>>>> bindsym $mod+Shift+2 move container to workspace 2, focus workspace 2
>>>>> bindsym $mod+Shift+3 move container to workspace 3, focus workspace 3
>>>>> bindsym $mod+Shift+4 move container to workspace 4, focus workspace 4
>>>>> [...]
>>>>>
>>>>> but that shows no effect.
>>>>>
>>>>> Thanks,
>>>>> Florian
>>>>
>>>>
>>>> --
>>>> Serge Kroes | Kroescontrol | LinkedIn | Twitter
>>>
>
>

Re: [i3] Keep windows focused on workspace move

[Ingo Bürk]

It should work with just "focus" because the separation with a comma
means the focus command will still be ran on the matched window.

On 09/03/2015 08:40 PM, Michael Stapelberg wrote:
> What are you trying to accomplish with “exec i3-msg workspace $WS1”?
> This is equivalent to just “workspace $WS1”, but will be executed
> out-of-order because it spawns a new process in the background which
> sends the command.
>
> Also, I think the “focus” command used on its own (i.e. without any
> criteria) is a no-op.
>
> The previously mentioned “move container to workspace 1, workspace 1”
> command is the way to go.
>
> On Wed, Sep 2, 2015 at 4:59 PM, Serge Kroes  wrote:
>> Hi
>>
>> i'm using this:
>> bindsym $mod+Shift+1 move container to workspace $WS1, exec i3-msg workspace
>> $WS1, focus
>>
>>
>> On Wed, Sep 2, 2015 at 4:38 PM, Florian Lindner  wrote:
>>> Hello,
>>>
>>> Am Mittwoch, 2. September 2015, 16:17:56 schrieb Mateusz Poszwa:
 Je 2015-09-02 16:06:41
 Florian Lindner  skribis:

> Hello,
>
> when I move a window from a workspace to another (mod + shift + num)
> it looses the focus and a window (or parent) of the originating workspace 
> is
> focused.
>
> How can I have the window to stay focused when moved across
> workspaces?
>
> Use case:
> I have a conversation open on the small and farer away laptop screen.
> I see activity there and I move it to one of my main screens. I want it to
> keep focused.
>
> Best Regards,
> Florian
 Hello.

 Try to change your binding from
 move workspace «X»
 to
 move workspace «X», focus workspace «X»
>>> I have set it to:
>>>
>>> bindsym $mod+Shift+1 move container to workspace 1, focus workspace 1
>>> bindsym $mod+Shift+2 move container to workspace 2, focus workspace 2
>>> bindsym $mod+Shift+3 move container to workspace 3, focus workspace 3
>>> bindsym $mod+Shift+4 move container to workspace 4, focus workspace 4
>>> [...]
>>>
>>> but that shows no effect.
>>>
>>> Thanks,
>>> Florian
>>
>>
>>
>> --
>> Serge Kroes | Kroescontrol | LinkedIn | Twitter
>
>

Re: [i3] default kbd layout per window

[Ingo Bürk]

For_window will only be run when the window is opened, not everytime it is 
focused. 

What you need to do is hook into the focus event on the IPC, match the window 
there and execute the command. 

Regards
Ingo 

Sent from TypeMail



On Sep 1, 2015, 17:07, at 17:07, Nokan Emiro  wrote:
>Hi i3wm gurus,
>
>I use i3 with kbdd in order to have different keyboard layouts in
>different
>windows:
>
>exec_always --no-startup-id kbdd
>exec_always setxkbmap -layout de,us -option grp:shift_caps_toggle
>
>
>I figured out that the following command changes the current layout
>into
>the US version:
>
>$  dbus-send --dest=ru.gentoo.KbddService /ru/gentoo/KbddService
>ru.gentoo.kbdd.set_layout uint32:1
>
>...and replacing the uint32:1 with uint32:0 switches to the DE layout.
>
>
>Now, what I couldn't figure out is that how can I set up a default
>layout
>for certain types
>of windows.  New windows start with the DE version (I guess because
>that
>one comes
>first in the list with the 'setxkbmap -layout de,us' command).  So far,
>so
>go.  But on
>terminals I want to use the US layout.  I tried something like this in
>the
>i3wm config:
>
>for_window [window_role="terminal"] exec dbus-send
>--dest=ru.gentoo.KbddService /ru/gentoo/KbddService
>ru.gentoo.kbdd.set_layout uint32:1
>
>Unfortunately this doesn't work.  Can you please tell me how can I do
>this
>kind of
>setup from the i3 config?  (Maybe I could run the dbus-send command
>from the
>bash_profile or something like that, but I hope this can be done with
>for_window
>in the i3 config somehow.)
>
>Thanks,
>Uz.

Re: [i3] GLFW_FLOATING window

[Ingo Bürk]

Hi Michael, 

I agree that there are better choices. On a side note, I noticed the other day 
that Google Hangout screen sharing opens a window to offer ending the screen 
share session with this very atom. That window definitely needs to float, 
though it's easy to argue that Chrome is at fault here and should use a more 
suitable atom.

Either way, i3 doesn't claim to support this atom and that alone should cause 
applications to not rely on it and instead use a more suitable atom. 

Ingo

Sent from TypeMail



On Aug 25, 2015, 17:40, at 17:40, Michael Stapelberg mich...@i3wm.org wrote:
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains:


_NET_WM_STATE_ABOVE indicates that the window should be on top of most
windows (see the section called “Stacking order” for details).

_NET_WM_STATE_BELOW indicates that the window should be below most
windows (see the section called “Stacking order” for details).

_NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user
preferences and should not be used by applications e.g. for drawing
attention to their dialogs (the Urgency hint should be used in that
case, see the section called “Urgency”).


From that, I don’t think using _NET_WM_STATE_ABOVE to make a window
floating is the correct way.

Taking a step back, why does the window need to be floating at all? i3
deliberately only makes dialog windows floating, and if your window is
not a dialog window, it not being floating is working as intended.

On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote:
 Hi everyone,

 GLFW has a window creation flag to make a window FLOATING, it uses
 _NET_WM_STATE_ABOVE to do this in x11_window.c.

 I have tried adding to the if statement in manage.c and the
corresponding
 xmacro to atoms.xmacro, but it still doesn't open as a floating
window.
 After adding this, GLFW's check in x11_init.c works, it didn't
before, so it
 seems to be registered within i3 correctly, but the
 xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check
still
 fails.  Any idea why this could be happening?

 Additionally, if I do get it working, would this be something worthy
of
 submitting? or should GLFW be changed to use something other than the
 WM_STATE_ABOVE atom to make floating windows?  ...although none of
the tests
 used by i3 seem to be the right fit.

 Thanks,
 Kevin



-- 
Best regards,
Michael

Re: [i3] GLFW_FLOATING window

[Ingo Bürk]

Hi Kevin, 

Applications generally shouldn't dictate how the window manager has to manage 
windows. In fact the specs clearly state that the window manager is allowed to 
deny, allow or modify such requests and that the application needs to deal with 
that. Also note that if you provide proper information on the window (class or 
role etc.), any user can make sure that the window will float.

As for supporting the atom in i3, I'm all for i3 supporting more of the 
standards, but we need to find the appropriate way to handle these atoms and 
fully understand the consequences. It doesn't seem immediately clear to me that 
such windows must be floated. I think Michael seems to see it similarly. 

Regards 
Ingo 

Sent from TypeMail



On Aug 25, 2015, 17:53, at 17:53, Kevin J jkev...@umbc.edu wrote:
Michael:
The reason I want the window to float is if I want a specific
resolution
for the window (I'm working on an OpenGL project).  Especially if the
window is set to be not user-resizeable, i3 will still resize it to fit
it
to a tile.  I had read that and thought that maybe that wouldn't be the
correct atom to use, but none of the ones i3 uses to determine whether
to
make a window floating seem correct either (MODAL, DIALOG, UTILITY,
TOOLBAR, and SPLASH)

Ingo:
Thanks, I will look into that once I get back from work.  Also instead
use
a more suitable atom do you know of any that would work? Otherwise
should
this atom be added to i3's floating window detection?

On Tue, Aug 25, 2015 at 11:44 AM, Ingo Bürk ad...@airblader.de wrote:

 Hi Michael,

 I agree that there are better choices. On a side note, I noticed the
other
 day that Google Hangout screen sharing opens a window to offer ending
the
 screen share session with this very atom. That window definitely
needs to
 float, though it's easy to argue that Chrome is at fault here and
should
 use a more suitable atom.

 Either way, i3 doesn't claim to support this atom and that alone
should
 cause applications to not rely on it and instead use a more suitable
atom.

 Ingo

 Sent from TypeMail http://www.typeapp.com/r

 On Aug 25, 2015, at 17:40, Michael Stapelberg mich...@i3wm.org
wrote:

 http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains:

 
 _NET_WM_STATE_ABOVE indicates that the window should be on top of
most
 windows (see the section called “Stacking order” for details).

 _NET_WM_STATE_BELOW indicates that the window should be below most
 windows (see the section called “Stacking order” for details).

 _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for
user
 preferences and should not be used by applications e.g. for drawing
 attention to their dialogs (the Urgency hint should be used in that
 case, see the section called “Urgency”).
 

 From that, I don’t think using _NET_WM_STATE_ABOVE to make a window
 floating is the correct way.

 Taking a step back, why does the window need to be floating at all?
i3
 deliberately only makes dialog windows floating, and if your window
 is
 not a dialog window, it not being floating is working as intended.

 On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote:

  Hi everyone,

  GLFW has a window creation flag to make a window FLOATING, it uses
  _NET_WM_STATE_ABOVE to do this in x11_window.c.

  I have tried adding to the if statement in manage.c and the
corresponding
  xmacro to atoms.xmacro, but it still doesn't open as a floating
window.
  After adding this, GLFW's check in x11_init.c works, it didn't
before, so it
  seems to be registered within i3 correctly, but the
  xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check
still
  fails.  Any idea why this could be happening?

  Additionally, if I do get it working, would this be something
worthy of
  submitting? or should GLFW be changed to use something other than
the
  br
 WM_STATE_ABOVE atom to make floating windows?  ...although none of
the tests
  used by i3 seem to be the right fit.

  Thanks,
  Kevin

Re: [i3] GLFW_FLOATING window

[Ingo Bürk]

Hi Kevin, 

On the bottom of manage.c you also need to increase the number of atoms that i3 
lists as supported. Also make sure you added the new atom not at the very end 
of atoms.xmacro as not all of them are copied into the supported list and GLFW 
seems to actually check for support. 

If all of this is correct, it could only be that GLFW only sets the atom after 
the window is created. In this case you'd have to modify the handler. 

Regards 
Ingo 

Sent from TypeMail



On Aug 25, 2015, 17:22, at 17:22, Kevin J jkev...@umbc.edu wrote:
Hi everyone,

GLFW has a window creation flag to make a window FLOATING, it uses
_NET_WM_STATE_ABOVE
to do this in x11_window.c
https://github.com/glfw/glfw/blob/b69b4a9f2a66159f670c5802d8105db211bfec3d/src/x11_window.c#L350-L357
.

I have tried adding to the if statement in manage.c
https://github.com/i3/i3/blob/next/src/manage.c#L374-L384 and the
corresponding xmacro to atoms.xmacro, but it still doesn't open as a
floating window.  After adding this, GLFW's check in x11_init.c
https://github.com/glfw/glfw/blob/afe4aadade132f088a1d88145baed0b384c8d4e0/src/x11_init.c#L438-L439
works,
it didn't before, so it seems to be registered within i3 correctly, but
the
xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still
fails.  Any idea why this could be happening?

Additionally, if I do get it working, would this be something worthy of
submitting? or should GLFW be changed to use something other than the
WM_STATE_ABOVE atom to make floating windows?  ...although none of the
tests used by i3 seem to be the right fit.

Thanks,
Kevin

Re: [i3] Binding adventures between mappings

[Ingo Bürk]

These work for me. I suggest you open an issue on Github and include log
files.
Make sure to restart i3, then press the shortcuts and then take the log
file, that way the file stays relatively small.


Ingo

On 07/02/2015 11:54 AM, Jeff Abrahamson wrote:
 I said that wrong in the subject, let me try in more than one line:

 I have a somewhat modal idea of how to interact with a window manager, so
 my i3 config binds very little at global level, the rest is in modes.  One
 mode I call focus, because the items in that mode I might want to do
 without leaving the mode, mostly moving between windows.  In mode i3,
 most of the bindings end with a mode command, often back to default.

 I have this in my $HOME/i3/.config:

 set $mod Mod1
 bindsym $mod+Tab mode i3

 mode i3 {
 # Some things I might want to do.
 # Includes a transition to focus mode.

 # The mode is long, but here's an example:
 bindsym c  exec urxvt; mode default
 }

 mode focus {
 # A handful of actions that I want in a separate mode.

 # And then there's a bunch of move/resize bindings, and then:

 # If I forget where I am, do the right thing.
 bindsym $mod+Tab mode i3

 # Get me out of here.
 bindsym Return mode default
 bindsym Escape mode default
 bindsym Control+g  mode default
 }

 This works great but for two bindings in focus mode:

 1.  The $mod+Tab binding I would expect to drop me into i3 mode, but it
 has no effect.

 2.  The ESC and C-G bindings exit focus mode correctly, but RET has no
 effect.

 Any suggestions what I've done wrong?

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

Re: [i3] i3wm exit session

[Ingo Bürk]

@Don

Alright, then this was a misunderstanding. My apologies.


Ingo

On 04/05/2015 01:25 PM, Donald Allen wrote:
 On Sun, Apr 5, 2015 at 7:15 AM, Ingo Bürk ad...@airblader.de wrote:
 This is getting meta, but (in a general sense) this:

 don't complain, send a patch
 is a pretty unhelpful reaction in my eyes. So we can't open bugs if we
 don't provide the fix as well? We can't ask for features without
 implementing it? Most of us are busy and to be honest, I don't have the
 time to dig into the source code of *every* application I'm using if I
 feel that an improvement can be made. I wouldn't find time to eat, sleep
 or earn my living anymore. Of course it's a good thing if someone does;
 I just argue it shouldn't be a requirement.
 You don't need to. Even in the extreme world of OpenBSD, no one argues
 that it's a *requirement*;  the developers fix bugs reported by users
 who don't offer patches. Don't complain, send a patch is their
 (less-than-diplomatic) way of encouraging people to contribute. My
 point, perhaps not expressed clearly enough, was that open source
 gives us all the option of making contributions, as Tony Crisci did,
 so this was an example of how open source encourages teamwork,
 communities.

 That being said, I didn't think any of this was dramatic and I didn't
 think Michael's or Jeff's responses were in any way unreasonable.
 Someone asked a question, Michael made his stance, Tony provided a
 reasonable solution.


 Ingo


 On 04/05/2015 01:04 PM, Donald Allen wrote:
 On Sun, Apr 5, 2015 at 3:39 AM, Jeff Abrahamson j...@purple.com wrote:
 (To be clear and before anyone has a chance to remark on it: that was meant
 in support of the OP of the question, not meant as a chastisement of
 Michael.  Sorry if it read a bit as the latter.)
 Yes, it did read that way, pretty clearly. It's good that you realized
 it yourself and sent the above.

 While I think you are correct that it's unintended behavior -- a bug
 -- but not important functionally, I think Michael's response is
 perfectly reasonable, as the developer of good software for which we
 must all remember he is giving us free of charge. I don't know
 Michael, but I have seen indications that he's a busy guy. As someone
 who had a 45-year career in software development, I can tell you that
 just continuing development of i3 and providing the level of support
 he does is a big job. And that's in addition to whatever he does to
 earn his living and have a life. So, without trying to speak for him,
 I'm guessing his response came from that perspective. It was also a
 bit like the old joke about he fellow who says to the doctor Doctor,
 when I do this, it hurts. To which the doctor responded Don't do
 that.

 I would also add that we are living in an open source world. Part of
 the point of open source is that we can all contribute to the
 development of a piece of software. Read or listen to any of Richard
 Stallman's descriptions of his issue with a laser printer many years
 ago that resulted in his leading us in this direction and you see that
 collaboration between users and developers as at the core of the open
 source movement. The original poster expressed a concern about a
 certain behavior in i3, Michael essentially said I have more
 important things to work on, from which you will benefit, so just
 avoid provoking that behavior, and then Tony Crisci suggested a fix
 that doesn't require Michael's involvement. This is the way it's
 supposed to work. Read the OpenBSD mailing lists. While the tone is
 too nasty for my taste, especially when Theo de Raadt gets involved,
 he and they have a point: don't complain, send a patch!

 /Don Allen

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

 On 5 April 2015 at 09:30, Jeff Abrahamson j...@purple.com wrote:
 Wait, that's not a very empathetic response.  I agree with you, Michael,
 that this isn't a huge problem functionally, but it *looks* ugly and it
 *looks* like unintended behavior.  And that's reason enough for the OP to
 raise the issue, in case no one had noticed.

 From there, it's certainly reasonable if you want to say that it's not
 your priority to fix.  And to invite a patch, whether or not you want to
 offer tips on how it might be patched.

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

 On 5 April 2015 at 09:18, Michael Stapelberg mich...@i3wm.org wrote:
 What’s the problem with this behavior?

 It surely is technically possible to avoid it, but why bother?

 On Sun, Apr 5, 2015 at 12:14 AM, Hector c1b3rh...@gmail.com wrote:
 Dear I3wm list ,

 Recently I was using my laptop with i3wm,  my version is 4.8
 (2014-06-15, branch 4.8) I run  debian testing,  I couldn't say that
 I
 haven't fallen in love with it,but checking the option to exit from
 my current session if I press once, I get

Re: [i3] i3wm exit session

[Ingo Bürk]

This is getting meta, but (in a general sense) this:

 don't complain, send a patch

is a pretty unhelpful reaction in my eyes. So we can't open bugs if we
don't provide the fix as well? We can't ask for features without
implementing it? Most of us are busy and to be honest, I don't have the
time to dig into the source code of *every* application I'm using if I
feel that an improvement can be made. I wouldn't find time to eat, sleep
or earn my living anymore. Of course it's a good thing if someone does;
I just argue it shouldn't be a requirement.

That being said, I didn't think any of this was dramatic and I didn't
think Michael's or Jeff's responses were in any way unreasonable.
Someone asked a question, Michael made his stance, Tony provided a
reasonable solution.


Ingo


On 04/05/2015 01:04 PM, Donald Allen wrote:
 On Sun, Apr 5, 2015 at 3:39 AM, Jeff Abrahamson j...@purple.com wrote:
 (To be clear and before anyone has a chance to remark on it: that was meant
 in support of the OP of the question, not meant as a chastisement of
 Michael.  Sorry if it read a bit as the latter.)
 Yes, it did read that way, pretty clearly. It's good that you realized
 it yourself and sent the above.

 While I think you are correct that it's unintended behavior -- a bug
 -- but not important functionally, I think Michael's response is
 perfectly reasonable, as the developer of good software for which we
 must all remember he is giving us free of charge. I don't know
 Michael, but I have seen indications that he's a busy guy. As someone
 who had a 45-year career in software development, I can tell you that
 just continuing development of i3 and providing the level of support
 he does is a big job. And that's in addition to whatever he does to
 earn his living and have a life. So, without trying to speak for him,
 I'm guessing his response came from that perspective. It was also a
 bit like the old joke about he fellow who says to the doctor Doctor,
 when I do this, it hurts. To which the doctor responded Don't do
 that.

 I would also add that we are living in an open source world. Part of
 the point of open source is that we can all contribute to the
 development of a piece of software. Read or listen to any of Richard
 Stallman's descriptions of his issue with a laser printer many years
 ago that resulted in his leading us in this direction and you see that
 collaboration between users and developers as at the core of the open
 source movement. The original poster expressed a concern about a
 certain behavior in i3, Michael essentially said I have more
 important things to work on, from which you will benefit, so just
 avoid provoking that behavior, and then Tony Crisci suggested a fix
 that doesn't require Michael's involvement. This is the way it's
 supposed to work. Read the OpenBSD mailing lists. While the tone is
 too nasty for my taste, especially when Theo de Raadt gets involved,
 he and they have a point: don't complain, send a patch!

 /Don Allen

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

 On 5 April 2015 at 09:30, Jeff Abrahamson j...@purple.com wrote:
 Wait, that's not a very empathetic response.  I agree with you, Michael,
 that this isn't a huge problem functionally, but it *looks* ugly and it
 *looks* like unintended behavior.  And that's reason enough for the OP to
 raise the issue, in case no one had noticed.

 From there, it's certainly reasonable if you want to say that it's not
 your priority to fix.  And to invite a patch, whether or not you want to
 offer tips on how it might be patched.

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

 On 5 April 2015 at 09:18, Michael Stapelberg mich...@i3wm.org wrote:
 What’s the problem with this behavior?

 It surely is technically possible to avoid it, but why bother?

 On Sun, Apr 5, 2015 at 12:14 AM, Hector c1b3rh...@gmail.com wrote:
 Dear I3wm list ,

 Recently I was using my laptop with i3wm,  my version is 4.8
 (2014-06-15, branch 4.8) I run  debian testing,  I couldn't say that
 I
 haven't fallen in love with it,but checking the option to exit from
 my current session if I press once, I get the normal message set
 by the default configuration, but if I press many times
 $mod+Shift+e  I get something like in the attached picture.

 Is there any way to add some snipe of code to solve it if I press many
 times?.

 Can anybody confirm  this behavior maybe I'm wrong and it just
 happend to me.

 Best Regards,
 Hector.



 --
 Best regards,
 Michael

Re: [i3] New to i3wm

[Ingo Bürk]

@Martin

You're confusing a few things here. lifebar is a standalone bar.
i3blocks, however, is not a bar, but just a data provider for i3bar (so
it replaces i3status, not i3bar). This also means that i3blocks has
tray support doesn't really make sense, because the tray support comes
from i3bar, not i3blocks.

Also, lifebar seems like a really early-stage project from the looks of
it. There are plenty other bars which are more widespread, such as dzen2
or lemonbar.


Ingo

On 04/05/2015 10:15 PM, Martin Cigorraga wrote:
 Bienvenido!

 You might be as well interested in these projects too as they bring
 extended usability to this babe:
 [0] j4-dmenu-desktop: only shows applications that have a .destkop file;
 also it is almost several times faster than traditional dmenu (pops out
 almost instantly);
 [1] lifebar: a neat, ready to use status bar replacement. Please note that
 at the moment it lacks support for the system tray;
 [2] quickswitch-i3: super practical tool that lets you quickly locate and
 switch to any window in all your desktops;
 [3] i3blocks: a nimble status bar replacement, allows for deep
 customization and extendability. It has a built-in system tray.

 Now you do have something to play with this Sunday :)
 -Martin

 [0] https://github.com/msx/j4-dmenu-desktop
 [1] https://github.com/lynks--/lifebar
 [2] https://github.com/proxypoke/quickswitch-for-i3
 [3] https://github.com/vivien/i3blocks

 On Sun, Apr 5, 2015 at 6:58 AM, mimosin...@gmail.com wrote:

 Oh dear...! I have had the misfortune of meeting  i3 on my Easter holidays
 [?].

 I have been a happy bunny playing with the configuration
 https://github.com/mimosinnet/i3wm_config so it maps my (not so
 different) FVWM config and contributed to i3tree
 https://github.com/mimosinnet/i3tree (it did not work for me), after 
 reading
 on it in the list
 http://comments.gmane.org/gmane.comp.window-managers.i3.general/469. I
 must say I am very impressed and very much agree with the underlying
 principles guiding I3.

 Thanks for this great piece of software!

 Cheers!