Re: [i3] windows are not selectable with obs-studio with i3-wm
Hey, I can't reproduce this. I can select the windows perfectly well. Please update to the latest version of i3 and try again. On 09/13/2015 08:02 PM, Zenny wrote: Hi, i3 has been a default wm for me for a long time! Having a problem similar to what has been discussed here: https://obsproject.com/forum/threads/tiling-window-managers-xcomposite-no-windows-found.34708/ The xcomposite windows cannot be selectable even under i3 like in Xmonad, however the second reply confirms that it worked fine with Awesome. Seems like it is more a problem of the window manager than the application (obs-studio)! Any inputs?! Thanks! /z
Re: [i3] IPC scripting with Ruby
This is a known bug with i3. Any command that does not include a
`restart` should work correctly. Try to use `reload` whenever you can.
If `reload` does not do something you think it should do that `restart`
does, make an issue on github.
https://github.com/i3/i3/issues/1581
On 06/02/2015 05:20 PM, Kareem Khazem wrote:
> Hi all, wondering if somebody could tell me what's wrong with my
> script that's trying to talk with i3's IPC.
>
> Whenever I try to read a reply from the socket, I apparently just get
> an empty string.
>
> I've already read the warning about using a library and not
> implementing my own, thanks, but the Ruby library is unmaintained and
> doesn't include recent IPC features.
>
> I'm doing this:
>
> ___ 8>< snip ><8 _
> #!/usr/bin/env ruby
> require 'socket'
> socket = Socket.unix(`i3 --get-socketpath`.strip)
>
> payload = "restart"
> type= 0
> length = payload.length
>
> bytes = socket.write("i3-ipc#{[length, type].pack("LL")}#{payload}")
>
> response = socket.read.unpack("L")
> __
>
>
> `bytes' gets the number of bytes written, as expected, and i3 does
> indeed restart, so the message was successful. But `response' seems to
> be nil. If I just ask for socket.read, I just get the empty string.
>
> Can anyone help? thanks!
>
Re: [i3] i3wm exit session
This works bindsym Mod1+Shift+e exec "test -f /tmp/i3-nagbar$DISPLAY.lock || (touch /tmp/i3-nagbar$DISPLAY.lock && i3-nagbar -t warning -m 'You pressed the exit shortcut. Do you really want to exit i3? This will end your X session.' -b 'Yes, exit i3' 'i3-msg exit' && rm /tmp/i3-nagbar$DISPLAY.lock)" On 04/05/2015 01:00 PM, Ingo Bürk wrote: > The pidof solution also completely disregards the possibility of > i3-nagbar being open for a completely different reason, e.g., a > configuration error. In that case displaying both makes total sense. > > On 04/05/2015 06:50 PM, Michael Stapelberg wrote: >> To expand a bit on my original post: I thought about the pidof >> solution, but that will fail on multi-user systems or when you have a >> hanging/broken instance of i3-nagbar sticking around. >> >> Making this more robust is not as simple as one might think, and >> that’s why I wanted to clarify what the real problem here is. If it’s >> merely the dialog showing up more than once (and I _think_ this is >> what the question is about), I think not fixing it outweighs the >> complexity of fixing it. But it could be that I missed something, >> which is why I asked… >> >> On Sun, Apr 5, 2015 at 4:23 PM, Bigby James >> wrote: >>> On 04/05, Tony Crisci wrote: >>>>> Is there any way to add some snipe of code to solve it if I press many >>>> times? >>>> >>>> Change the binding to this >>>> >>>> bindsym Mod1+Shift+e exec "pidof i3-nagbar || i3-nagbar -t warning -m >>>> 'You pressed the exit shortcut. Do you really want to exit i3? This will >>>> end your X session.' -b 'Yes, exit i3' 'i3-msg exit'" >>> More often than not, the simplest solution to a problem is the preferrable >>> one. >>> You can hit several dozen keystrokes writing code to "correct" this >>> "problem," >>> or you can just hit one keystroke and train yourself to not compulsively do >>> the >>> same thing over and over and over when there's no reason to. Incidentally, >>> that >>> ugly yellow thing is called "i3-nagbar," emphasis on "nag." If it's annoying >>> you, it's doing its job. Personally I (and, I suspect, many other users) >>> just >>> remove all mention of i3-nagbar from the configuration. >>> >>> This whole thread reminds me of that old joke: >>> >>>> PATIENT: Doctor, it hurts when I do this... >>>> DOCTOR: Then don't do that. >>> -- >>> "A common mistake that people make when trying to design something >>> completely >>> foolproof is to underestimate the ingenuity of complete fools." - Douglas >>> Adams >>> >> >> >
Re: [i3] i3wm exit session
> Is there any way to add some snipe of code to solve it if I press many times? Change the binding to this bindsym Mod1+Shift+e exec "pidof i3-nagbar || i3-nagbar -t warning -m 'You pressed the exit shortcut. Do you really want to exit i3? This will end your X session.' -b 'Yes, exit i3' 'i3-msg exit'" > Wait, that's not a very empathetic response. Please try not to shut down the discussion of new features for i3-nagbar on the mailing list. On 04/05/2015 03:30 AM, Jeff Abrahamson 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 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 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] Suggestion: Configuration with lua
Hi, As for a configuration file format, there are a lot of complications with using a script, such as requiring people to learn a programming language to configure the window manager as well as the technical complexity and the matter of backwards compatability. For those reasons, I think we are better off where we are for now. However, i3 is already fully scriptable in Lua with the i3ipc-glib project (https://github.com/acrisci/i3ipc-glib). I even created a wrapper library especially for lua which you can find here: https://github.com/acrisci/i3ipc-lua You are welcome to contribute to either of these projects if you don't find the features you want by contributing code or making feature requests on those projects. You can do all the things you mentioned with the ipc events. Check out all the different window events you can subscribe to: http://build.i3wm.org/docs/ipc.html#_window_event We even just added a "binding" event in the development version you can use to listen for keypresses that are bound to a command: http://build.i3wm.org/docs/ipc.html#_binding_event I support this library on the mailing list, the official i3 faq, and in the irc channel (nick: TonyC). On 10/04/2014 05:15 PM, Timo Schmiade wrote: Hi all, first off: Thanks for this wonderful window manager! I've tried many others before and this is the only one that doesn't make me look for other alternatives :) On topic: The only thing I think could be improved in i3 is the config. i3 uses its own configuration file format which is quite restricted. Therefor, I suggest moving to a well-established scripting language that can be embedded into i3's C code - lua comes to mind. The advantages I see: - Profit from lua's development history to have a safe, stable and yet feature-rich embedded scripting language - Avoid maintenance of own configuration file format (features + bug fixes) - Open lua for scripting: Allow lua callback functions to modify lua's behaviour in situations like "New window created" or "Key combination pressed" - Allow users to script configuration, e.g. use for-loop from 0-9 to bind keys for switching to workspaces or moving windows to workspaces What I did so far: I created a purely C- and lua-based test application which allows: - Call lua functions from C - Call C functions from lua - Pass C structs to lua script - Modify C structs in lua script What I could do next: - Integrate the functionality into i3's codebase - Create a public git branch (based on i3 'next') to demonstrate and discuss What I can't do: - Give any guarantees on development time What I need to know: - Is this something the i3 developers would want? Thanks in advance for your time. Kind regards, Timo
Re: [i3] i3-nagbar and keyboard
Here you go: `bindsym $mod+Escape pkill i3-nagbar`. Yes, nobody likes nagbar. But I don't think that there is any reason to change it. Nagbar is meant to be a teaching tool for new users. It appears when you have a syntax error in your config file or duplicate binding. It's there to warn you about the default key combination that exits the wm so you don't press it on accident for the first time. If your config file is free of errors, you should never see it. One thing that I don't like about some desktop environments is that they are too talky. There is always something flashing in the corner or some popup notification that I don't care about on my screen. i3 is designed to be quiet. There is no other window manager "meta information" that needs to be displayed in nagbar other than config errors. This is good unix engineering. On 09/20/2014 10:23 PM, grubernd wrote: On 2014-09-21 01:06, Michael Stapelberg wrote: The nagbar should _nag_ you, and obviously it accomplishes its mission, since you are annoyed enough to write to this mailing list :). Read: this is intentional. ok. well. let's put the - imo quite obvious - use of the nagbar for an exit dialog aside for a moment and consider the more usual case of editing something inside the i3 config and making an error. or lo and behold starting i3 with an error already in the config. if i read that right, it is the intention to force the user to get away from the computer, walk through a convention center, ask everyone if she has a mouse to spare. or walk to the parking lot to the car and dig through the box of odds and ends to see if a mouse is there. or drive to the next electronic market and buy a mouse. or a graphic tablet. not everyone has an external thinkpad keyboard with integrated nipple. all that just to be able to read the error message the fully keyboard enabled window manager is showing in a big red bar but wont let one see until a pointer-enabled HID is attached to the machine. to phrase it in a very blunt way: i consider this rather impolite to force a certain type of HID unto the user that is uneccessary in all other cases. yes, there is a logfile etc, but.. and the above mentioned use case is not made up. i am using computers without a mouse. except for the case that i was so awesome that i did not make an error and did not have to ask a bunch of windows7 laptop users if they had a spare mouse. uh. back to the exit use-case: i have a solution, no harm done. but maybe, just maybe it would be very cool and user-friendly to reconsider the intentional behaviour of the nagbar. because, after all.. it is *the* builtin method into i3 to display meta-messages and dialogs inside the window manager. last time i checked cursor-keys are still available even on apple-keyboards. and shifting focus to the nagbar would be more inline with nagging the user. and more so without breaking usability. just my 2ct. cheers, grubernd
Re: [i3] Cant subscribe to window::focus events
Hi,
You seem to be doing everything right with the library.
The problem is most likely that you are using a version of i3 that does
not emit the `focus` events. This feature was added in version 4.8.
Check your version with `i3 --version` and make sure it is up to date.
Am 08/29/2014 um 01:03 PM schrieb Sargrad, Dave:
I am trying to register for a window::focus event, but am not seeing
the events come in.
I can register for window::new and for workspace::focus just fine.
The code snippet I am using to register is:
*from gi.repository import i3ipc*
**
*# Create the Connection object that can be used to send commands and
subscribe*
*# to events.*
*conn = i3ipc.Connection()*
**
*conn.on('window::focus', on_window_focus)*
I did turn on i3 debug and I did notice the following (this occurs
when I call conn.on):
08/29/2014 04:53:25 PM - ipc.c:add_subscription:744 - should add
subscription to extra 0xef61a0, sub window
08/29/2014 04:53:25 PM - ipc.c:add_subscription:754 - client is now
subscribed to:
08/29/2014 04:53:25 PM - ipc.c:add_subscription:756 - event window
08/29/2014 04:53:25 PM - ipc.c:add_subscription:757 - (done)
Not sure how to interpret that debug info, but I think its telling me
that I need to subscribe for window::focus differently.
Again, I am able to register for workspace::focus just fine (and
receive workspace focus events).
*conn.on('workspace::focus', on_workspace_focus)*
/This message is intended only for the addressee and may contain
information that is company confidential or privileged. Any technical
data in this message may be exported only in accordance with the U.S.
International Traffic in Arms Regulations (22 CFR Parts 120-130) or
the Export Administration Regulations (15 CFR Parts 730-774).
Unauthorized use is strictly prohibited and may be unlawful. If you
are not the intended recipient, or the person responsible for
delivering to the intended recipient, you should not read, copy,
disclose or otherwise use this message. If you have received this
email in error, please delete it, and advise the sender immediately. /
Re: [i3] XFCE Notifications Appearing Centered
Hi, The problems with xfce4-notifyd were fixed recently in the development version. They should work pretty much as expected without extra configuration. The only remaining issue is that the notification windows are not sticky. On 06/24/2014 07:26 PM, Timothy Pollard wrote: Hi, I upgraded to 4.8 from 4.7.2 over the weekend and I've found a small problem with XFCE Notifications. If they are configured to start from the top-left or top-right the first one opens in the center rather than at the top-left or top-right as expected. If additional notifications are opened after the first one they display as normal, and if you configure it to open from the bottom-left or bottom-right it works as normal as well. Assuming you've got XFCE 4 installed you can see an example by running xfce4-notifyd-config and using the Preview button with a different config options. Note that it did work with 4.7.2, though I had had to override some settings for windows of the XFCE4 class, essentially "for_window [class="Xfce4-notifyd"] floating enable; border none; focus mode_toggle", but trying each of those options individually doesn't help, and as a group they actually cause another problem (the "border none" applies to the focused window, not the notification). Anyone know what might be causing this? Or want more details? Thanks,
Re: [i3] Call for testing for the 4.8 release
I can reproduce this easily with `focus_follows_mouse` when switching focus with pointer enter, but not at all with keyboard focus. There is a similar issue on the stable branch, except that focus does not change at all on pointer enter, so i3 remains in sync. This suggests the underlying cause is with `focus_follows_mouse`. On 06/10/2014 02:58 AM, Anders Aagaard wrote: I just noticed one issue now, this is from 7482a0f which I've been using for about a week. I had focus in one window (and the window is active), however when I type it ends up in another window. Unfortunately I jumped in and out of windows trying to figure out what was going on. The problem I saw was the jetbrains/intellij window had focus, I typed and it ended up in gnome-terminal. Switching to another workspace and back seemed to fix it, and the last few characters typed ended up in the correct window. So the problem is from this log, before switching workspace to 2 and then back to 1 again. https://dl.dropboxusercontent.com/u/18745774/i3-focus-issue.log On Tue, Jun 10, 2014 at 12:19 AM, Marcin Herda wrote: Hi, I have been using it for the last month or so without any problems (including saving and restoring layouts http://www.slackword.net/?p=733) Thank you. regards Marcin Hi, I want to release i3 v4.8 soon, so here is a call for testing. If you haven't, please use an i3 build from the "next" git branch. For Debian and Ubuntu, we have http://i3wm.org/docs/repositories.html with that version so that you don't need to compile it yourself. In case you notice a grave problem, please report a bug at http://bugs.i3wm.org/ as usual. If nothing shows up, I'll make a release within the next few days. (FYI: This also means only urgent bugfix patches will be merged until the release is done.) -- Best regards, Michael
Re: [i3] Google hangouts extension
We have been having problems with Xdummy and are anticipating more. I have plans to replace the Xdummy script with Xephyr. Let me make some changes to the testcases that allows you to use the Xephyr backend to see if that resolves your issue before you get too deep into this. On 06/06/2014 01:38 PM, Anders Aagaard wrote: Had another stab at this here : http://cr.i3wm.org/patch/566 Special mentions: In src/manage.c sending in NULL when "Defer setting focus after the 'new' event" is done feels wrong, but I'm frankly not sure if that comment matches the con_set_urgency below it. It's resetting a urgency flag here if one is "lost"? Maybe sending in WM_HINTS is the right thing to do? Or maybe sending WM_HINTS/etc is generally stupid, and it should be one reason called "window_event_change" and another one for "focus_blocked"? Disclaimer : I've been a dev for a long time, but I haven't done anything in C for ages, so the code might be rubish. If I'm told that and you decide to do this in a much cleaner way, I will not have my feelings hurt ;) Gonna have a stab at fixing the Xdummy stuff now.
