From porizka at gmail.com  Wed Aug  3 06:00:21 2011
From: porizka at gmail.com (=?UTF-8?B?Um9tYW4gUG/FmcOtemth?=)
Date: Wed, 3 Aug 2011 12:00:21 +0200
Subject: [openbox] window cycling dialog
Message-ID: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>

Hello,
I have tried openbox 3.5 today and I've been using the least overlap patch,
but I cannot switch of the window cycling dialog... In my rc.xml is:

    <keybind key="A-Tab">
      <action name="NextWindow"/>
      <dialog>no</dialog>
    </keybind>
    <keybind key="A-S-Tab">
      <action name="PreviousWindow"/>
      <dialog>no</dialog>
    </keybind>

but it doesn't help...

Could you please tell me, what am I doing wrong?

Best regards,
Roman Porizka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/openbox/attachments/20110803/decae909/attachment.htm>

From dv at adfinis.ch  Wed Aug  3 07:00:03 2011
From: dv at adfinis.ch (David Vogt)
Date: Wed, 03 Aug 2011 13:00:03 +0200
Subject: [openbox] window cycling dialog
In-Reply-To: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>
References: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>
Message-ID: <4E392A33.7010303@adfinis.ch>

Hi!

On 03/08/11 12:00, Roman Po??zka wrote:
> Hello,
> I have tried openbox 3.5 today and I've been using the least overlap
> patch, but I cannot switch of the window cycling dialog... In my rc.xml is:

I don't think that the least-overlap patch has something to do with it. But:

>
> <keybind key="A-Tab">
> <action name="NextWindow"/>
> <dialog>no</dialog>
> </keybind>

As of my understanding, the <dialog> should be places inside the action, 
like this:

     <keybind key="A-Tab">
       <action name="NextWindow">
         <dialog>no</dialog>
       </action>
     </keybind>

However, this doesn't work for me either.

> [...]
>
> Could you please tell me, what am I doing wrong?

I think you found a bug - the <dialog>no</dialog> also fails in the 
SendToDesktop* actions, for example.

Or maybe this is a feature that was removed intentionally? Maybe someone 
of the main developers could throw in a word?


Sincerely,
Dave


-- 
David Vogt, Dipl. Techn. HF Software Eng. | Project Manager, Developer
Post:        adfinis GmbH, Br?ckfeldstrasse 21, 3012 Bern (Switzerland)
Email:       dv at adfinis.ch,          Web: http://www.adfinis.ch
Jabber/XMPP: dv at jabber.adfinis.com,  Phone: +41 31 381 70 47

From mikachu at gmail.com  Wed Aug  3 10:33:30 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Wed, 3 Aug 2011 16:33:30 +0200
Subject: [openbox] window cycling dialog
In-Reply-To: <4E392A33.7010303@adfinis.ch>
References: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>
	<4E392A33.7010303@adfinis.ch>
Message-ID: <CAHYJk3Sr67cKThjqp+fMQJxDDzwOf9rmWUZLxC3DzSavqZQ7UQ@mail.gmail.com>

On 3 August 2011 13:00, David Vogt <dv at adfinis.ch> wrote:
> Hi!
>
> On 03/08/11 12:00, Roman Po??zka wrote:
>>
>> Hello,
>> I have tried openbox 3.5 today and I've been using the least overlap
>> patch, but I cannot switch of the window cycling dialog... In my rc.xml
>> is:
>
> I don't think that the least-overlap patch has something to do with it. But:
>
>>
>> <keybind key="A-Tab">
>> <action name="NextWindow"/>
>> <dialog>no</dialog>
>> </keybind>
>
> As of my understanding, the <dialog> should be places inside the action,
> like this:
>
>    <keybind key="A-Tab">
>      <action name="NextWindow">
>        <dialog>no</dialog>
>      </action>
>    </keybind>
>
> However, this doesn't work for me either.
>
>> [...]
>>
>> Could you please tell me, what am I doing wrong?
>
> I think you found a bug - the <dialog>no</dialog> also fails in the
> SendToDesktop* actions, for example.
>
> Or maybe this is a feature that was removed intentionally? Maybe someone of
> the main developers could throw in a word?

I think it's a minor mistake. When we added the listmode, the value
changed from a boolean, and the new code looks for the word "none",
not "no", to disable the dialog.

-- 
Mikael Magnusson

From porizka at gmail.com  Wed Aug  3 10:55:03 2011
From: porizka at gmail.com (=?UTF-8?B?Um9tYW4gUG/FmcOtemth?=)
Date: Wed, 3 Aug 2011 16:55:03 +0200
Subject: [openbox] window cycling dialog
In-Reply-To: <CAHYJk3Sr67cKThjqp+fMQJxDDzwOf9rmWUZLxC3DzSavqZQ7UQ@mail.gmail.com>
References: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>
	<4E392A33.7010303@adfinis.ch>
	<CAHYJk3Sr67cKThjqp+fMQJxDDzwOf9rmWUZLxC3DzSavqZQ7UQ@mail.gmail.com>
Message-ID: <CAAbnjVK43C-8UH90rM+e4+tjPdK2RFb9+obOOA5VoTLVbDcF-A@mail.gmail.com>

On Wed, Aug 3, 2011 at 4:33 PM, Mikael Magnusson <mikachu at gmail.com> wrote:

> On 3 August 2011 13:00, David Vogt <dv at adfinis.ch> wrote:
> > Hi!
> >
> > On 03/08/11 12:00, Roman Po??zka wrote:
> >>
> >> Hello,
> >> I have tried openbox 3.5 today and I've been using the least overlap
> >> patch, but I cannot switch of the window cycling dialog... In my rc.xml
> >> is:
> >
> > I don't think that the least-overlap patch has something to do with it.
> But:
> >
> >>
> >> <keybind key="A-Tab">
> >> <action name="NextWindow"/>
> >> <dialog>no</dialog>
> >> </keybind>
> >
> > As of my understanding, the <dialog> should be places inside the action,
> > like this:
> >
> >    <keybind key="A-Tab">
> >      <action name="NextWindow">
> >        <dialog>no</dialog>
> >      </action>
> >    </keybind>
> >
> > However, this doesn't work for me either.
> >
> >> [...]
> >>
> >> Could you please tell me, what am I doing wrong?
> >
> > I think you found a bug - the <dialog>no</dialog> also fails in the
> > SendToDesktop* actions, for example.
> >
> > Or maybe this is a feature that was removed intentionally? Maybe someone
> of
> > the main developers could throw in a word?
>
> I think it's a minor mistake. When we added the listmode, the value
> changed from a boolean, and the new code looks for the word "none",
> not "no", to disable the dialog.
>
> --
> Mikael Magnusson
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>


Thanks a lot! Both changes together are working now! So the correct XML code
is:

  <keybind key="A-Tab">
      <action name="NextWindow">
        <dialog>none</dialog>
      </action>
    </keybind>
    <keybind key="A-S-Tab">
      <action name="PreviousWindow">
        <dialog>none</dialog>
      </action>
    </keybind>

Could you please correct the documentation at the url:
http://openbox.org/wiki/Help:Actions#NextWindow ?

Thanks a lot and regards,
Roman Porizka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/openbox/attachments/20110803/15ad977c/attachment.htm>

From mikachu at gmail.com  Wed Aug  3 10:59:40 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Wed, 3 Aug 2011 16:59:40 +0200
Subject: [openbox] window cycling dialog
In-Reply-To: <CAAbnjVK43C-8UH90rM+e4+tjPdK2RFb9+obOOA5VoTLVbDcF-A@mail.gmail.com>
References: <CAAbnjVK2XMKjb73pb6dbSYKx0uPCHHFVt7fG3DaizHiQOajdMg@mail.gmail.com>
	<4E392A33.7010303@adfinis.ch>
	<CAHYJk3Sr67cKThjqp+fMQJxDDzwOf9rmWUZLxC3DzSavqZQ7UQ@mail.gmail.com>
	<CAAbnjVK43C-8UH90rM+e4+tjPdK2RFb9+obOOA5VoTLVbDcF-A@mail.gmail.com>
Message-ID: <CAHYJk3TzbLyRxALO3h3J8Je3QRYdF=aQf+fecvLZfm2sA7X6Mw@mail.gmail.com>

On 3 August 2011 16:55, Roman Po??zka <porizka at gmail.com> wrote:
> On Wed, Aug 3, 2011 at 4:33 PM, Mikael Magnusson <mikachu at gmail.com> wrote:
>>
>> On 3 August 2011 13:00, David Vogt <dv at adfinis.ch> wrote:
>> > Hi!
>> >
>> > I think you found a bug - the <dialog>no</dialog> also fails in the
>> > SendToDesktop* actions, for example.
>> >
>> > Or maybe this is a feature that was removed intentionally? Maybe someone
>> > of
>> > the main developers could throw in a word?
>>
>> I think it's a minor mistake. When we added the listmode, the value
>> changed from a boolean, and the new code looks for the word "none",
>> not "no", to disable the dialog.
>
> Thanks a lot! Both changes together are working now! So the correct XML code
> is:
>   <keybind key="A-Tab">
>       <action name="NextWindow">
>         <dialog>none</dialog>
>       </action>
>     </keybind>
>     <keybind key="A-S-Tab">
>       <action name="PreviousWindow">
>         <dialog>none</dialog>
>       </action>
>     </keybind>
> Could you please correct the documentation at the url:
> http://openbox.org/wiki/Help:Actions#NextWindow ?

A lot of documentation needs updating, many of the action names
changed too (the old ones still work obviously).

-- 
Mikael Magnusson

From no.smile.face at gmail.com  Thu Aug  4 07:08:25 2011
From: no.smile.face at gmail.com (nsf)
Date: Thu, 4 Aug 2011 17:08:25 +0600
Subject: [openbox] obkey 1.0 release
Message-ID: <20110804170825.20a06aa6@gmail.com>

Since openbox 3.5.0 was released recently, here is my small
contribution to that.

Obkey existed as a development version for a long time, but I guess
it's stable enough to be called "one point zero". And well, it happened.
No big changes, just for a purpose of making a line here. 

If you don't know what I'm talking about, obkey is a GUI tool for
editing openbox keyboard bindings/chains written in python using pygtk.
The site of the project is here: http://code.google.com/p/obkey/

The 1.0 is available as a tarball here (that's the most important part
for all the package maintainers):
http://obkey.googlecode.com/files/obkey-1.0.tar.gz

As the release note says, the development is halted (frankly, it was
halted long time ago). The tool should work unless openbox breaks or
adds or removes features in its configuration xml format (I'm pretty
sure it won't happen until 4.0). So.. use it if you like and be
happy. :D

Oh, I should mention that if you want to improve obkey, I still accept
patches (why not?). But, please, don't send me LXDE-related patches.
The best way to send me a patch is a fork & pull request on the
project's github page: http://github.com/nsf/obkey

Well.. that's it. :)

From openboxml023478 at rainslide.net  Sun Aug  7 06:03:38 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sun, 7 Aug 2011 11:03:38 +0100
Subject: [openbox] 3.5.0, $GLOBALAUTOSTART
Message-ID: <20110807100338.GA12535@rainslide.net>

I've always had ". $GLOBALAUTOSTART" at the beginning of my ~/.config/openbox/autostart.sh. I upgraded to 3.5.0 and restarted X. Openbox started, but it didn't execute anything after that line in autostart.sh. I looked at the X output window and saw that it was complaining about not being able to source anything at that line, in other words, $GLOBALAUTOSTART was not defined. I commented out the line and restarted X again. Openbox started as it usually does, executing everything in autostart.sh. Is this new behaviour of 3.5.0, that $GLOBALAUTOSTART has now been removed?

-- 

.

From openboxml023478 at rainslide.net  Sun Aug  7 06:07:43 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sun, 7 Aug 2011 11:07:43 +0100
Subject: [openbox] 3.5.0, openbox-xdg-autostart
Message-ID: <20110807100743.GA12576@rainslide.net>

I noticed in my X output the following line after I upgraded to 3.5.0. Openbox seems to be running normally (after commenting out the $GLOBALAUTOSTART line in autostart.sh - see my previous post), so is it anything to worry about?

ERROR: openbox-xdg-autostart requires PyXDG to be installed

-- 

.

From openboxml023478 at rainslide.net  Sun Aug  7 06:51:42 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sun, 7 Aug 2011 11:51:42 +0100
Subject: [openbox] Mousebind In Client Context
Message-ID: <20110807105142.GA12661@rainslide.net>

I have this, which closes whichever window the cursor is over:

<mouse>
     <context name="Frame">
       <mousebind button="Button8" action="Click">
           <action name="Close"/>
       </mousebind>
     </context>
</mouse>

I'd like that when the cursor is in the Client context of an Opera window, and I press Button8, instead of closing Opera, it closes the tab, ie. issues a ctrl-w key press. I can issue the ctrl-w with xdotool in an <action>...<command>, but what I don't know is how to define that within an Opera Client context only. I'm thinking something like this:

<mouse>
     <context name="Client">
         <application class="Opera" name="opera" type="normal">
             <mousebind button="Button8" action="Click">
                 <action name="Execute">
                     <command>xdotool key ctrl+w</command>
                 </action>
             </mousebind>
         </application>
     </context>
</mouse>

When I put the <application> block into my Client context section, Openbox doesn't give an error when I reconfigure it, but neither does it make a difference.

-- 

.

From mikachu at gmail.com  Sun Aug  7 08:26:18 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Sun, 7 Aug 2011 14:26:18 +0200
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <20110807105142.GA12661@rainslide.net>
References: <20110807105142.GA12661@rainslide.net>
Message-ID: <CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>

On 7 August 2011 12:51, Paul <openboxml023478 at rainslide.net> wrote:
> I have this, which closes whichever window the cursor is over:
>
> <mouse>
>    <context name="Frame">
>      <mousebind button="Button8" action="Click">
>          <action name="Close"/>
>      </mousebind>
>    </context>
> </mouse>
>
> I'd like that when the cursor is in the Client context of an Opera window,
> and I press Button8, instead of closing Opera, it closes the tab, ie. issues
> a ctrl-w key press. I can issue the ctrl-w with xdotool in an
> <action>...<command>, but what I don't know is how to define that within an
> Opera Client context only. I'm thinking something like this:
>
> <mouse>
>    <context name="Client">
>        <application class="Opera" name="opera" type="normal">
>            <mousebind button="Button8" action="Click">
>                <action name="Execute">
>                    <command>xdotool key ctrl+w</command>
>                </action>
>            </mousebind>
>        </application>
>    </context>
> </mouse>
>
> When I put the <application> block into my Client context section, Openbox
> doesn't give an error when I reconfigure it, but neither does it make a
> difference.

Yeah, it's strange but making up syntax doesn't work. ;) What you can
actually do is
<action name="If">
  <title>Opera *</title>
  <then>
     <action name="Execute">...</action>
  </then>
  <else>
     <action name="Close"/>
  </else>
</action>

Also note that if you bind the frame context for a button, the client
context for that button will not be reached, but the only difference
is the client context will pass the click through, which i don't think
makes sense to do in this case anyway, so put the above in the frame
context.

-- 
Mikael Magnusson

From openboxml023478 at rainslide.net  Sun Aug  7 10:20:41 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sun, 7 Aug 2011 15:20:41 +0100
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
References: <20110807105142.GA12661@rainslide.net>
	<CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
Message-ID: <20110807142041.GA12977@rainslide.net>

On Sun, Aug 07, 2011 at 02:26:18PM +0200, Mikael Magnusson wrote:
>Yeah, it's strange but making up syntax doesn't work. ;)

I didn't think it would work, I just didn't want to have not tried anything, and thought that reconfiguring Openbox might have told me something was wrong. Reconfiguring must only parse the XML syntax.

>What you can actually do is
><action name="If">
>  <title>Opera *</title>
>  <then>
>     <action name="Execute">...</action>
>  </then>
>  <else>
>     <action name="Close"/>
>  </else>
></action>

Thanks, that works. I didn't know about the 'if' action. Isn't it on the wiki?

-- 

.

From mikachu at gmail.com  Sun Aug  7 10:42:24 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Sun, 7 Aug 2011 16:42:24 +0200
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <20110807142041.GA12977@rainslide.net>
References: <20110807105142.GA12661@rainslide.net>
	<CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
	<20110807142041.GA12977@rainslide.net>
Message-ID: <CAHYJk3Tm2OqkcDNpBzD0T55CnnYqpTfXfC3GnicBS-OfH8bDbw@mail.gmail.com>

On 7 August 2011 16:20, Paul <openboxml023478 at rainslide.net> wrote:
> On Sun, Aug 07, 2011 at 02:26:18PM +0200, Mikael Magnusson wrote:
>>
>> Yeah, it's strange but making up syntax doesn't work. ;)
>
> I didn't think it would work, I just didn't want to have not tried anything,
> and thought that reconfiguring Openbox might have told me something was
> wrong. Reconfiguring must only parse the XML syntax.
>
>> What you can actually do is
>> <action name="If">
>>  <title>Opera *</title>
>>  <then>
>>    <action name="Execute">...</action>
>>  </then>
>>  <else>
>>    <action name="Close"/>
>>  </else>
>> </action>
>
> Thanks, that works. I didn't know about the 'if' action. Isn't it on the
> wiki?

We haven't quite gotten around to documenting new features yet.

-- 
Mikael Magnusson

From mikachu at gmail.com  Sun Aug  7 12:57:44 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Sun, 7 Aug 2011 18:57:44 +0200
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <CAHYJk3Tm2OqkcDNpBzD0T55CnnYqpTfXfC3GnicBS-OfH8bDbw@mail.gmail.com>
References: <20110807105142.GA12661@rainslide.net>
	<CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
	<20110807142041.GA12977@rainslide.net>
	<CAHYJk3Tm2OqkcDNpBzD0T55CnnYqpTfXfC3GnicBS-OfH8bDbw@mail.gmail.com>
Message-ID: <CAHYJk3Th1W0HbcgcmUcjPXyaNw1JwXr4w49godVP5sF6TbPwKw@mail.gmail.com>

On 7 August 2011 16:42, Mikael Magnusson <mikachu at gmail.com> wrote:
> On 7 August 2011 16:20, Paul <openboxml023478 at rainslide.net> wrote:
>> On Sun, Aug 07, 2011 at 02:26:18PM +0200, Mikael Magnusson wrote:
>>>
>>> Yeah, it's strange but making up syntax doesn't work. ;)
>>
>> I didn't think it would work, I just didn't want to have not tried anything,
>> and thought that reconfiguring Openbox might have told me something was
>> wrong. Reconfiguring must only parse the XML syntax.
>>
>>> What you can actually do is
>>> <action name="If">
>>>  <title>Opera *</title>
>>>  <then>
>>>    <action name="Execute">...</action>
>>>  </then>
>>>  <else>
>>>    <action name="Close"/>
>>>  </else>
>>> </action>
>>
>> Thanks, that works. I didn't know about the 'if' action. Isn't it on the
>> wiki?
>
> We haven't quite gotten around to documenting new features yet.

I've updated the page documenting actions now, there may be some minor
mistakes, let me know if so.

-- 
Mikael Magnusson

From A.Thyssen at griffith.edu.au  Sun Aug  7 23:58:17 2011
From: A.Thyssen at griffith.edu.au (Anthony Thyssen)
Date: Mon, 8 Aug 2011 13:58:17 +1000
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <CAHYJk3Th1W0HbcgcmUcjPXyaNw1JwXr4w49godVP5sF6TbPwKw@mail.gmail.com>
References: <20110807105142.GA12661@rainslide.net>
	<CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
	<20110807142041.GA12977@rainslide.net>
	<CAHYJk3Tm2OqkcDNpBzD0T55CnnYqpTfXfC3GnicBS-OfH8bDbw@mail.gmail.com>
	<CAHYJk3Th1W0HbcgcmUcjPXyaNw1JwXr4w49godVP5sF6TbPwKw@mail.gmail.com>
Message-ID: <20110808135817.2044485c@wraith>

On Sun, 7 Aug 2011 18:57:44 +0200
Mikael Magnusson <mikachu at gmail.com> wrote:
| On 7 August 2011 16:42, Mikael Magnusson <mikachu at gmail.com> wrote:
| > On 7 August 2011 16:20, Paul <openboxml023478 at rainslide.net> wrote:
| >> On Sun, Aug 07, 2011 at 02:26:18PM +0200, Mikael Magnusson wrote:
| >>>
| >>> Yeah, it's strange but making up syntax doesn't work. ;)
| >>
| >> I didn't think it would work, I just didn't want to have not tried anything,
| >> and thought that reconfiguring Openbox might have told me something was
| >> wrong. Reconfiguring must only parse the XML syntax.
| >>
| >>> What you can actually do is
| >>> <action name="If">
| >>>  <title>Opera *</title>
| >>>  <then>
| >>>    <action name="Execute">...</action>
| >>>  </then>
| >>>  <else>
| >>>    <action name="Close"/>
| >>>  </else>
| >>> </action>
| >>
| >> Thanks, that works. I didn't know about the 'if' action. Isn't it on the
| >> wiki?
| >
| > We haven't quite gotten around to documenting new features yet.
| 
| I've updated the page documenting actions now, there may be some minor
| mistakes, let me know if so.
| 

It would be useful if the version number the action was added to was
also listed.

the If action does not seem to be present for my current version of
openbox (from Fedora 14 package repository)

  Anthony Thyssen ( System Programmer )    <A.Thyssen at griffith.edu.au>
 --------------------------------------------------------------------------
    One does expect bugs, but not of this variety
      -- an ant just crawled out of the keyboard.   
                                    -- Ann E Cleary <afactor at ozemail.com.au>
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/

From mikachu at gmail.com  Mon Aug  8 00:02:35 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Mon, 8 Aug 2011 06:02:35 +0200
Subject: [openbox] Mousebind In Client Context
In-Reply-To: <20110808135817.2044485c@wraith>
References: <20110807105142.GA12661@rainslide.net>
	<CAHYJk3QY2b_ng5VkqfTQdbZV+r7jm7CuAqfJKAvaH5LmdxF0EA@mail.gmail.com>
	<20110807142041.GA12977@rainslide.net>
	<CAHYJk3Tm2OqkcDNpBzD0T55CnnYqpTfXfC3GnicBS-OfH8bDbw@mail.gmail.com>
	<CAHYJk3Th1W0HbcgcmUcjPXyaNw1JwXr4w49godVP5sF6TbPwKw@mail.gmail.com>
	<20110808135817.2044485c@wraith>
Message-ID: <CAHYJk3QT8Cf17rRLjZ8GDtwQQSXRLZGg_cNT5PRPWzKgM03CCQ@mail.gmail.com>

On 8 August 2011 05:58, Anthony Thyssen <A.Thyssen at griffith.edu.au> wrote:
> On Sun, 7 Aug 2011 18:57:44 +0200
> Mikael Magnusson <mikachu at gmail.com> wrote:
> | On 7 August 2011 16:42, Mikael Magnusson <mikachu at gmail.com> wrote:
> | > On 7 August 2011 16:20, Paul <openboxml023478 at rainslide.net> wrote:
> | >> On Sun, Aug 07, 2011 at 02:26:18PM +0200, Mikael Magnusson wrote:
> | >>>
> | >>> Yeah, it's strange but making up syntax doesn't work. ;)
> | >>
> | >> I didn't think it would work, I just didn't want to have not tried anything,
> | >> and thought that reconfiguring Openbox might have told me something was
> | >> wrong. Reconfiguring must only parse the XML syntax.
> | >>
> | >>> What you can actually do is
> | >>> <action name="If">
> | >>>  <title>Opera *</title>
> | >>>  <then>
> | >>>    <action name="Execute">...</action>
> | >>>  </then>
> | >>>  <else>
> | >>>    <action name="Close"/>
> | >>>  </else>
> | >>> </action>
> | >>
> | >> Thanks, that works. I didn't know about the 'if' action. Isn't it on the
> | >> wiki?
> | >
> | > We haven't quite gotten around to documenting new features yet.
> |
> | I've updated the page documenting actions now, there may be some minor
> | mistakes, let me know if so.
> |
>
> It would be useful if the version number the action was added to was
> also listed.
>
> the If action does not seem to be present for my current version of
> openbox (from Fedora 14 package repository)

It's quite clearly listed at the top of the page. The page would be a
huge mess if it had both the 3.4 and 3.5 actions on it.

-- 
Mikael Magnusson

From daf at minuslab.net  Mon Aug  8 07:09:48 2011
From: daf at minuslab.net (Dave Foster)
Date: Mon, 8 Aug 2011 07:09:48 -0400
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
Message-ID: <BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>


On Jul 18, 2011, at 3:34 AM, Mikael Magnusson wrote:

> On 18 July 2011 01:27, Freddie <freddie_signup at gmx.co.uk> wrote:
>> On Sun, 17 Jul 2011, Mikael Magnusson wrote:
>>> 
>>> It's technically possible, but it doesn't mesh well with the wm-spec
>>> which openbox follows. Ie, any pagers and panels would be terminally
>>> confused about those windows, there is only a single 'which desktop is
>>> this window on' property per window, and one global 'which desktop is
>>> the user on' property on the root window. For this specific case,
>>> maybe you could simply mark all windows on monitor two as 'All
>>> Desktops'? Unless you also want to switch virtual desktop on monitor
>>> 2, but you didn't say that :).
>> 
>> This is actually the conclusion I've come to. The next problem is finding
>> how to mark windows on monitor 2 as omnipresent, as so far I've only come
>> across "ToggleOmnipresent", which isn't quite what I want. Am I missing an
>> action/property?
> 
> You're not, I was just sure there was one, but there isn't :). You
> could do some silly cludge in the master branch with the If action, to
> only call the toggle action if it isn't currently omnipresent, but it
> might be better to simply let you say "All" to the SendToDesktop
> action. However, if you're already using an applications rule to send
> a window to monitor 2, just make it omnipresent in that rule
> obviously. Is it a big problem that you press the key twice and can't
> tell if you already made it omnipresent or not?

Sorry to necromance here, but just wanted to add that once I got Dana interested in such a daemon-like application, and myself started coding one, but did not get very far as X programming scares me.  Maybe Dana can pick it back up again :)

The way I'd envision it working: post-move hook, it checks which monitor it is on, and applies a rule (make omipresent).  Would obviously be beneficial to be generic.



> 
>> As an aside, what do other xinerama users do about setting background
>> images? I wanted to set two images, one for each monitor. The only tool I've
>> found to allow placing an image at a coordinate is hokum, which actually
>> works quite well.
> 
> http://projects.l3ib.org/nitrogen/

Cheers for the plug :)
dave


From jamslam at gmail.com  Mon Aug  8 15:01:43 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Mon, 8 Aug 2011 15:01:43 -0400
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
	<BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
Message-ID: <CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>

On Mon, Aug 8, 2011 at 7:09 AM, Dave Foster <daf at minuslab.net> wrote:
>
> On Jul 18, 2011, at 3:34 AM, Mikael Magnusson wrote:
>
>> On 18 July 2011 01:27, Freddie <freddie_signup at gmx.co.uk> wrote:
>>> On Sun, 17 Jul 2011, Mikael Magnusson wrote:
>>>>
>>>> It's technically possible, but it doesn't mesh well with the wm-spec
>>>> which openbox follows. Ie, any pagers and panels would be terminally
>>>> confused about those windows, there is only a single 'which desktop is
>>>> this window on' property per window, and one global 'which desktop is
>>>> the user on' property on the root window. For this specific case,
>>>> maybe you could simply mark all windows on monitor two as 'All
>>>> Desktops'? Unless you also want to switch virtual desktop on monitor
>>>> 2, but you didn't say that :).
>>>
>>> This is actually the conclusion I've come to. The next problem is finding
>>> how to mark windows on monitor 2 as omnipresent, as so far I've only come
>>> across "ToggleOmnipresent", which isn't quite what I want. Am I missing an
>>> action/property?
>>
>> You're not, I was just sure there was one, but there isn't :). You
>> could do some silly cludge in the master branch with the If action, to
>> only call the toggle action if it isn't currently omnipresent, but it
>> might be better to simply let you say "All" to the SendToDesktop
>> action. However, if you're already using an applications rule to send
>> a window to monitor 2, just make it omnipresent in that rule
>> obviously. Is it a big problem that you press the key twice and can't
>> tell if you already made it omnipresent or not?
>
> Sorry to necromance here, but just wanted to add that once I got Dana interested in such a daemon-like application, and myself started coding one, but did not get very far as X programming scares me. ?Maybe Dana can pick it back up again :)
>
> The way I'd envision it working: post-move hook, it checks which monitor it is on, and applies a rule (make omipresent). ?Would obviously be beneficial to be generic.

After failing to build my own window manager (using Python), I am
currently modifying Openbox to support the original idea in this
thread: changing desktops on a per monitor basis. I've been wanting
this feature for so long, and since I added a third monitor to my
setup, I've found it to be nearly essential. It's going to be a bit
more than a post-move hook :-)

As Mikael mentioned, this violates the EWMH spec and is essentially
incompatible with all existing pagers. (I need to make one of those
too.) I'm adding a new property called _NET_VISIBLE_DESKTOPS that
should provide all the information an outside application (like a
pager) needs. (Maybe I'll submit it to the EWMH people, but they
haven't updated the spec in a long time...) The _NET_CURRENT_DESKTOP
property is still relevant, I think.

Ideally, this should only change behavior on multi-head setups using
Xinerama. Hopefully I'll make a public branch of Openbox available
soon; I plan on keeping it up to date with Dana's master branch.

The only window managers I know of that exhibit this feature are
Xmonad and i3; except the latter ties each desktop to a specific
monitor that can't be used on other monitors. That is, only Xmonad
gets this right in my opinion.

>
>
>>
>>> As an aside, what do other xinerama users do about setting background
>>> images? I wanted to set two images, one for each monitor. The only tool I've
>>> found to allow placing an image at a coordinate is hokum, which actually
>>> works quite well.
>>
>> http://projects.l3ib.org/nitrogen/
>
> Cheers for the plug :)

Nitrogen is awesome! Thanks :-)

- Andrew

From A.Thyssen at griffith.edu.au  Mon Aug  8 22:11:48 2011
From: A.Thyssen at griffith.edu.au (Anthony Thyssen)
Date: Tue, 9 Aug 2011 12:11:48 +1000
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
	<BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
	<CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
Message-ID: <20110809121148.2bbd1827@wraith>

On Jul 18, 2011, at 3:34 AM, Mikael Magnusson wrote:

> On 18 July 2011 01:27, Freddie <freddie_signup at gmx.co.uk> wrote:
>> On Sun, 17 Jul 2011, Mikael Magnusson wrote:
>>>
>>> It's technically possible, but it doesn't mesh well with the wm-spec
>>> which openbox follows. Ie, any pagers and panels would be terminally
>>> confused about those windows, there is only a single 'which desktop is
>>> this window on' property per window, and one global 'which desktop is
>>> the user on' property on the root window. For this specific case,
>>> maybe you could simply mark all windows on monitor two as 'All
>>> Desktops'? Unless you also want to switch virtual desktop on monitor
>>> 2, but you didn't say that :).
>>
>> This is actually the conclusion I've come to. The next problem is finding
>> how to mark windows on monitor 2 as omnipresent, as so far I've only come
>> across "ToggleOmnipresent", which isn't quite what I want. Am I missing an
>> action/property?
>
> You're not, I was just sure there was one, but there isn't :). You
> could do some silly cludge in the master branch with the If action, to
> only call the toggle action if it isn't currently omnipresent, but it
> might be better to simply let you say "All" to the SendToDesktop
> action. However, if you're already using an applications rule to send
> a window to monitor 2, just make it omnipresent in that rule
> obviously. Is it a big problem that you press the key twice and can't
> tell if you already made it omnipresent or not?



I have looked into using the "If" action, now that it has been added to
the wiki.

However my version of openbox is v3.4.11.2 from the Fedora repository
so it is not available to me, and I am loathed to replace the package
with a personal version.  But looks like I'll need to.




The documentation does not list  "All" as a valid <to>..</to> action for
"SendToDesktop" action!  This was why I did not find it before.

Perhaps the docs need a small update.

Actually the docs previously used <desktop> instead of <to>!

In any case using <to> also does not work, presumably as it is also
a 'new' action.



Hmmm something that is wierd though...

On a window on one desktop...
  obxprop _NET_WM_DESKTOP
  _NET_WM_DESKTOP(CARDINAL) = 0
But on a window with 'All Desktops' that becomes
  obxprop _NET_WM_DESKTOP
  _NET_WM_DESKTOP(CARDINAL) = 4294967295

Is that even a sensible value?

This is also equivelent to toggling OmniDesktop


Note this seems to only be an information properity whcih is used by non
window manager programs. Changing it does not change the windows
desktop, though it does change which desktop the 'pager' displays it
even though it isn't really on that desktop!


  Anthony Thyssen ( System Programmer )    <A.Thyssen at griffith.edu.au>
 --------------------------------------------------------------------------
  Predictive analysis indicates the imminent failure of "USER".
  Please replace unit "USER" as soon as posible.       -- Anthony Thyssen
 --------------------------------------------------------------------------
   Anthony's Castle     http://www.ict.griffith.edu.au/anthony/

From mikachu at gmail.com  Mon Aug  8 23:53:45 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Tue, 9 Aug 2011 05:53:45 +0200
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <20110809121148.2bbd1827@wraith>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
	<BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
	<CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
	<20110809121148.2bbd1827@wraith>
Message-ID: <CAHYJk3R6wn9ETu-tzJ3XYDybHRbTk-xMUO2v-6BDhUr892pbVg@mail.gmail.com>

On 9 August 2011 04:11, Anthony Thyssen <A.Thyssen at griffith.edu.au> wrote:
> On Jul 18, 2011, at 3:34 AM, Mikael Magnusson wrote:
>> You're not, I was just sure there was one, but there isn't :). You
>> could do some silly cludge in the master branch with the If action, to
>> only call the toggle action if it isn't currently omnipresent, but it
>> might be better to simply let you say "All" to the SendToDesktop
>> action. However, if you're already using an applications rule to send
>> a window to monitor 2, just make it omnipresent in that rule
>> obviously. Is it a big problem that you press the key twice and can't
>> tell if you already made it omnipresent or not?
>
> I have looked into using the "If" action, now that it has been added to
> the wiki.
>
> However my version of openbox is v3.4.11.2 from the Fedora repository
> so it is not available to me, and I am loathed to replace the package
> with a personal version.  But looks like I'll need to.

They're so slow, the gentoo livedvd released on sunday already has 3.5 ;)

> The documentation does not list  "All" as a valid <to>..</to> action for
> "SendToDesktop" action!  This was why I did not find it before.
> Perhaps the docs need a small update.

It doesn't list it because it isn't valid.

> Actually the docs previously used <desktop> instead of <to>!
>
> In any case using <to> also does not work, presumably as it is also
> a 'new' action.

Yes, we changed <desktop> to <to>, though <desktop> still works in 3.5
for setting an absolute number as in 3.4, but not the other things.

> Hmmm something that is wierd though...
>
> On a window on one desktop...
>  obxprop _NET_WM_DESKTOP
>  _NET_WM_DESKTOP(CARDINAL) = 0
> But on a window with 'All Desktops' that becomes
>  obxprop _NET_WM_DESKTOP
>  _NET_WM_DESKTOP(CARDINAL) = 4294967295
>
> Is that even a sensible value?

Yes.

> This is also equivelent to toggling OmniDesktop

Yes, omni means all, as you may know :).

> Note this seems to only be an information properity whcih is used by non
> window manager programs. Changing it does not change the windows
> desktop, though it does change which desktop the 'pager' displays it
> even though it isn't really on that desktop!

I suggest you read the icccm and netwm specs if you want to mess with
this stuff, you can't just change the values directly on the window
unless you're the window manager, you have to send a change request to
the root window.

-- 
Mikael Magnusson

From rephorm at rephorm.com  Tue Aug  9 12:53:16 2011
From: rephorm at rephorm.com (Brian Mattern)
Date: Tue, 9 Aug 2011 09:53:16 -0700
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
	<BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
	<CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
Message-ID: <20110809165316.GC4286@ocelot>

On Mon, 08 Aug 2011, Andrew Gallant wrote:

> After failing to build my own window manager (using Python), I am
> currently modifying Openbox to support the original idea in this
> thread: changing desktops on a per monitor basis. I've been wanting
> this feature for so long, and since I added a third monitor to my
> setup, I've found it to be nearly essential. It's going to be a bit
> more than a post-move hook :-)
> 
> As Mikael mentioned, this violates the EWMH spec and is essentially
> incompatible with all existing pagers. (I need to make one of those
> too.) I'm adding a new property called _NET_VISIBLE_DESKTOPS that
> should provide all the information an outside application (like a
> pager) needs. (Maybe I'll submit it to the EWMH people, but they
> haven't updated the spec in a long time...) The _NET_CURRENT_DESKTOP
> property is still relevant, I think.
> 
> Ideally, this should only change behavior on multi-head setups using
> Xinerama. Hopefully I'll make a public branch of Openbox available
> soon; I plan on keeping it up to date with Dana's master branch.
> 
> The only window managers I know of that exhibit this feature are
> Xmonad and i3; except the latter ties each desktop to a specific
> monitor that can't be used on other monitors. That is, only Xmonad
> gets this right in my opinion.


Enlightenment DR17 (www.enlightenment.org) implements
monitor-independent desktops as well. I once (as proof of concept)
forcibly implemented this type of behavior in compiz's wall desktop
switcher as well.  Unfortunately, I got too lazy to also go "fix" all
the other pager / switcher plugins in compiz, resulting in a thoroughly
broken desktop. (Then openbox cured me of compiz.)

I think that this feature is extremely useful, and would love to see it
added to openbox. It would be nice if
there were a standard way of implementing it so that external pagers
could get on board. (Although the topology of the "virtual desktop"
changes quite a bit compared to traditional xinerama, so some pagers may
simply not be compatible.)

Brian

From jamslam at gmail.com  Tue Aug  9 13:31:23 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Tue, 9 Aug 2011 13:31:23 -0400
Subject: [openbox] Two x displays (not xinerama) support
In-Reply-To: <20110809165316.GC4286@ocelot>
References: <20110408071528.GA13835@apartia.fr>
	<alpine.DEB.2.02.1107171201420.15352@play.lan>
	<CAHYJk3QVGZ2VOE6o0gMOpAnEvMGKw6ErEOP+4Zj-BpyjoE=9YQ@mail.gmail.com>
	<alpine.DEB.2.02.1107180023220.11219@play.lan>
	<CAHYJk3RHqW0uKadDtKfkySWwfO24Ont93CLTK0qtmY-vX6y_Vg@mail.gmail.com>
	<BCB9CED5-F49B-4573-B434-44CBBBA0A53D@minuslab.net>
	<CAMfjfuE7F0C1veuZZ3uKjVmBy5z32d_QWsrSc4TYCOEC_hJqow@mail.gmail.com>
	<20110809165316.GC4286@ocelot>
Message-ID: <CAMfjfuGpfw1yjDBuBoot6xwOET6UutsGiqGJ3K3xmqwZ4sThcg@mail.gmail.com>

On Tue, Aug 9, 2011 at 12:53 PM, Brian Mattern <rephorm at rephorm.com> wrote:
> On Mon, 08 Aug 2011, Andrew Gallant wrote:
>
>> After failing to build my own window manager (using Python), I am
>> currently modifying Openbox to support the original idea in this
>> thread: changing desktops on a per monitor basis. I've been wanting
>> this feature for so long, and since I added a third monitor to my
>> setup, I've found it to be nearly essential. It's going to be a bit
>> more than a post-move hook :-)
>>
>> As Mikael mentioned, this violates the EWMH spec and is essentially
>> incompatible with all existing pagers. (I need to make one of those
>> too.) I'm adding a new property called _NET_VISIBLE_DESKTOPS that
>> should provide all the information an outside application (like a
>> pager) needs. (Maybe I'll submit it to the EWMH people, but they
>> haven't updated the spec in a long time...) The _NET_CURRENT_DESKTOP
>> property is still relevant, I think.
>>
>> Ideally, this should only change behavior on multi-head setups using
>> Xinerama. Hopefully I'll make a public branch of Openbox available
>> soon; I plan on keeping it up to date with Dana's master branch.
>>
>> The only window managers I know of that exhibit this feature are
>> Xmonad and i3; except the latter ties each desktop to a specific
>> monitor that can't be used on other monitors. That is, only Xmonad
>> gets this right in my opinion.
>
>
> Enlightenment DR17 (www.enlightenment.org) implements
> monitor-independent desktops as well.

Ah, I didn't know about that one. Thanks for the info, I'll check it
out, but I'll definitely stick to modifying Openbox to get this
behavior.

> I once (as proof of concept)
> forcibly implemented this type of behavior in compiz's wall desktop
> switcher as well. ?Unfortunately, I got too lazy to also go "fix" all
> the other pager / switcher plugins in compiz, resulting in a thoroughly
> broken desktop. (Then openbox cured me of compiz.)

Yeah, I think that _NET_VISIBLE_DESKTOPS is enough info for a pager to
do its work. But it's a pretty fundamental change. Here is what I
think my pager will do when I make it:

- Show one rectangle for each desktop, but instead of making them
correspond to the width of _NET_DESKTOP_GEOMETRY (or _NET_WORKAREA),
make them correspond to the width of a single head. (I think a
sacrifice will need to be made when there are multiple heads with
different resolutions. That is, use ratios instead.)

- Group or signal which desktops are visible.

> I think that this feature is extremely useful, and would love to see it
> added to openbox. It would be nice if
> there were a standard way of implementing it so that external pagers
> could get on board.

Absolutely. I'll see what I can do about submitting this to EWMH once
the dust has cleared. Right now I'm using a simple (and
non-interactive) text-based pager that I built for use with Xmonad.

I've found that I can get by without this feature on dual monitors,
but that it is absolutely essential (for me) with three monitors. It
makes things work so much smoother.

Kudos to the Openbox dev team by the way, after only a few days of
hacking I've made some really great progress. The code is really
well-written/designed.

> (Although the topology of the "virtual desktop"
> changes quite a bit compared to traditional xinerama, so some pagers may
> simply not be compatible.)

I'm not sure what you mean here. I think all pagers will be rendered
useless with this kind of change?

- Andrew

From jamslam at gmail.com  Thu Aug 11 18:29:44 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Thu, 11 Aug 2011 18:29:44 -0400
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
Message-ID: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>

After a week of hacking, I've turn Openbox's desktop model from "one
and only desktop visible at a time" to "one desktop visible for each
monitor activated." This creates the ability to switch desktops
*independent* of monitor; and any desktop can appear on any monitor.
I've called it openbox-multihead. [1]

Unfortunately, this breaks the EWMH spec and results in any pager
becoming *almost* useless. (They will still work, but will probably
confuse you.) To temporarily remedy this, I've include a small Python
script 'ob-visible-desks' in the tools directory that will output a
simple text based representation of the available desktops (grouped
into four different visual categories using position/color: current,
visible, hidden with windows and hidden without windows). It should be
used with something like xmobar or dzen2.

I've added several configuration options and a desktop list menu.
These are described in more detail in README.MULTIHEAD. [2]

I've never done anything like this with an existing open source
project, but right now, I'm thinking my plans are this:

- Keep my multihead branch of Openbox up to date with Dana's master branch.

- Continue to develop features that improve on multihead functionality.

- Develop a pager that works with this new desktop model.

- Get omnipresent clients working better. (Docks and the like work
fine, though. It's only the normal clients that are giving me some
focus issues.)

I'm open to suggestions!

Also, if anyone is on Archlinux [3], I've put this in the AUR. [4]

- Andrew

[1] - https://github.com/BurntSushi/openbox-multihead
[2] - https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD
[3] - https://bbs.archlinux.org/viewtopic.php?id=124331
[4] - http://aur.archlinux.org/packages.php?ID=51460

From dv at adfinis.ch  Fri Aug 12 02:52:26 2011
From: dv at adfinis.ch (David Vogt)
Date: Fri, 12 Aug 2011 08:52:26 +0200
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
In-Reply-To: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
References: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
Message-ID: <4E44CDAA.7060903@adfinis.ch>

Hi!

On 12/08/11 00:29, Andrew Gallant wrote:
> After a week of hacking, I've turn Openbox's desktop model from "one
> and only desktop visible at a time" to "one desktop visible for each
> monitor activated." This creates the ability to switch desktops
> *independent* of monitor; and any desktop can appear on any monitor.
> I've called it openbox-multihead. [1]

Very cool, I've been waiting for something like this for ages!


> I'm open to suggestions!
>
> Also, if anyone is on Archlinux [3], I've put this in the AUR. [4]

I'm on Arch and just tried to install it. Unfortunately, it conflicts 
with the "regular" openbox. Would it be much work to rename stuff so it 
doesn't?

Despite this, I'm planning to look into it during the weekend, i'm 
really curious!


Dave

-- 
David Vogt, Dipl. Techn. HF Software Eng. | Project Manager, Developer
Post:        adfinis GmbH, Br?ckfeldstrasse 21, 3012 Bern (Switzerland)
Email:       dv at adfinis.ch,          Web: http://www.adfinis.ch
Jabber/XMPP: dv at jabber.adfinis.com,  Phone: +41 31 381 70 47

From jamslam at gmail.com  Fri Aug 12 10:42:06 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Fri, 12 Aug 2011 10:42:06 -0400
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
In-Reply-To: <4E44CDAA.7060903@adfinis.ch>
References: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
	<4E44CDAA.7060903@adfinis.ch>
Message-ID: <CAMfjfuEa4e5t-UasZctYarOzE2UkseP6_Bw=jBQCscTwttDLLQ@mail.gmail.com>

>> I'm open to suggestions!
>>
>> Also, if anyone is on Archlinux [3], I've put this in the AUR. [4]
>
> I'm on Arch and just tried to install it. Unfortunately, it conflicts with
> the "regular" openbox. Would it be much work to rename stuff so it doesn't?
>
> Despite this, I'm planning to look into it during the weekend, i'm really
> curious!

Hmmm, I think the proper approach here is to just replace the package
on your machine. The problem with renaming stuff is that it has to
*provide* "openbox" so that other programs that depend upon Openbox
can still work with openbox-multihead.

It should be as simple as replacing the package, and if you don't like
it, you should be able to reinstall regular Openbox without any fuss.
:-) If you're really against replacing the current package, it would
probably still be easier to just checkout the repo and build it
yourself (but don't do 'make install'). Then use your xinitrc to start
'gitrepo/openbox/openbox'.

Just make sure to check out the new configuration options. (They are
added to the default rc.xml in /etc/xdg/openbox/rc.xml when you
install.)

- Andrew

From andreas.fink85 at googlemail.com  Sat Aug 13 06:34:43 2011
From: andreas.fink85 at googlemail.com (Andreas Fink)
Date: Sat, 13 Aug 2011 12:34:43 +0200
Subject: [openbox] GrowToEdge constrain to monitor in multihead setup
Message-ID: <20110813123443.5c8dbee1@jocker-laptop>

Hello,

I have two monitors, however I often try to arrange two windows side-by-side on one of the monitor. Therefore I use the GrowToEdge action. It would be nice if I could restrict the GrowToEdge action to not span over the second monitor, but rather let the window shrink, as if there is no second monitor. Is this possible or planned?

Cheers
Andreas 

From mikachu at gmail.com  Sat Aug 13 08:46:50 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Sat, 13 Aug 2011 14:46:50 +0200
Subject: [openbox] GrowToEdge constrain to monitor in multihead setup
In-Reply-To: <20110813123443.5c8dbee1@jocker-laptop>
References: <20110813123443.5c8dbee1@jocker-laptop>
Message-ID: <CAHYJk3RM7eK4VTgwVv4j4XNpdbN=UfBHUVV4+VMPYPSMXFBESA@mail.gmail.com>

On 13 August 2011 12:34, Andreas Fink <andreas.fink85 at googlemail.com> wrote:
> Hello,
>
> I have two monitors, however I often try to arrange two windows side-by-side on one of the monitor. Therefore I use the GrowToEdge action. It would be nice if I could restrict the GrowToEdge action to not span over the second monitor, but rather let the window shrink, as if there is no second monitor. Is this possible or planned?

No, but 3.5 has the ShrinkToEdge action. (So you would first move/grow
it to the edge, then shrink it to the window on the other edge).

-- 
Mikael Magnusson

From jamslam at gmail.com  Sun Aug 14 23:52:42 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Sun, 14 Aug 2011 23:52:42 -0400
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
In-Reply-To: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
References: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
Message-ID: <CAMfjfuG+UeVTKe0V0xwiYr4KhvQs=YE39WcbxtAtgpsWUG1hLw@mail.gmail.com>

I have got around to developing that pager I was talking about before.
It uses pygtk and also adds the ability to dynamically manage your
workspaces with a bit more flexibility than core Openbox would
typically allow for.

I've written a good overview of it over at the Archlinux forums. [1]

Thanks!
- Andrew

[1] - https://bbs.archlinux.org/viewtopic.php?id=124528


On Thu, Aug 11, 2011 at 6:29 PM, Andrew Gallant <jamslam at gmail.com> wrote:
> After a week of hacking, I've turn Openbox's desktop model from "one
> and only desktop visible at a time" to "one desktop visible for each
> monitor activated." This creates the ability to switch desktops
> *independent* of monitor; and any desktop can appear on any monitor.
> I've called it openbox-multihead. [1]
>
> Unfortunately, this breaks the EWMH spec and results in any pager
> becoming *almost* useless. (They will still work, but will probably
> confuse you.) To temporarily remedy this, I've include a small Python
> script 'ob-visible-desks' in the tools directory that will output a
> simple text based representation of the available desktops (grouped
> into four different visual categories using position/color: current,
> visible, hidden with windows and hidden without windows). It should be
> used with something like xmobar or dzen2.
>
> I've added several configuration options and a desktop list menu.
> These are described in more detail in README.MULTIHEAD. [2]
>
> I've never done anything like this with an existing open source
> project, but right now, I'm thinking my plans are this:
>
> - Keep my multihead branch of Openbox up to date with Dana's master branch.
>
> - Continue to develop features that improve on multihead functionality.
>
> - Develop a pager that works with this new desktop model.
>
> - Get omnipresent clients working better. (Docks and the like work
> fine, though. It's only the normal clients that are giving me some
> focus issues.)
>
> I'm open to suggestions!
>
> Also, if anyone is on Archlinux [3], I've put this in the AUR. [4]
>
> - Andrew
>
> [1] - https://github.com/BurntSushi/openbox-multihead
> [2] - https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD
> [3] - https://bbs.archlinux.org/viewtopic.php?id=124331
> [4] - http://aur.archlinux.org/packages.php?ID=51460
>

From tom at wizetek.com  Wed Aug 17 13:30:27 2011
From: tom at wizetek.com (Tom Wizetek)
Date: Wed, 17 Aug 2011 13:30:27 -0400
Subject: [openbox] Cycle windows with mouse wheel
In-Reply-To: <d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
References: <d85253a21001112126n3f3d5851kca2d8e18c5a95c96@mail.gmail.com>
	<d85253a21001112136v324082bew903e7527f6f9b58e@mail.gmail.com>
	<d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
Message-ID: <CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>

I'm still looking for the ability to cycle windows with a mouse wheel up/down.

my ~/.config/openbox/rc.xml:

  <context name="Desktop">
    <mousebind button="Up" action="Click">
      <action name="PreviousWindow">
        <dialog>no</dialog>
        <bar>yes</bar>
        <raise>yes</raise>
        <linear>no</linear>
      </action>
    </mousebind>
    <mousebind button="Down" action="Click">
      <action name="NextWindow">
        <dialog>no</dialog>
        <bar>yes</bar>
        <raise>yes</raise>
        <linear>no</linear>
      </action>
    </mousebind>
  </context>

The issue is that after cycling windows I have to make a window active
either with a left-mouse-click or by pressing ENTER on the keyboard. I
am now running openbox-git 20110816 on Arch Linux.

It was mentioned at some point that a 'stopInteractive' config option
in the <focus> section would take care of it but I can't seem to get
it to work.

How can I get the desired behaviour?

From rephorm at rephorm.com  Thu Aug 18 13:16:08 2011
From: rephorm at rephorm.com (Brian Mattern)
Date: Thu, 18 Aug 2011 10:16:08 -0700
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
In-Reply-To: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
References: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
Message-ID: <20110818171608.GA11734@ocelot>

Hi,

On Thu, 11 Aug 2011, Andrew Gallant wrote:

> After a week of hacking, I've turn Openbox's desktop model from "one
> and only desktop visible at a time" to "one desktop visible for each
> monitor activated." This creates the ability to switch desktops
> *independent* of monitor; and any desktop can appear on any monitor.
> I've called it openbox-multihead. [1]

I finally got a chance to try this out. For the most part it seems to
be working. However, one bit of behavior is a bit puzzling.

I have two monitors. On the first, I have a single terminal window open,
the second is empty. If I move the mouse to the empty monitor and try to
change desktops, it changes the first monitor's desktop instead. The
only way I've found to bring focus to the empty monitor (I don't have
"FocusRoot" bindings installed yet) is to try to change to whatever
desktop is currently being shown on that monitor (I assume this won't
work if I turn on "greedy" desktops).

Maybe we could track the "active monitor", updating it whenever a new
window is selected OR the mouse enters a monitor?


> I've include a small Python script 'ob-visible-desks' ...

I installed xpyb and your xpyb-utils lib. The ob-visible-desks script
prints out a single line, but then loses the X connection as soon as
window focus or the current desktop changes (maybe when any X event is
received?). I'll try to dig into it more this weekend, but wanted to
give you a heads up.

> - Develop a pager that works with this new desktop model.

The pager you wrote seems to work, although I'm still on python2.6,
which doesn't have the { x:y for x,y in ... } construct yet. Easy enough
to fix, however.

Anyway, its definitely a good start!

Take care,
Brian

P.S. This is all on ubuntu 10.04, so some issues could be due to older
packages.


From jamslam at gmail.com  Thu Aug 18 13:33:56 2011
From: jamslam at gmail.com (Andrew Gallant)
Date: Thu, 18 Aug 2011 13:33:56 -0400
Subject: [openbox] Openbox Multihead (featuring per-monitor desktops)
In-Reply-To: <20110818171608.GA11734@ocelot>
References: <CAMfjfuGCOoF6MxWR1aRLUdEBj1ArCoh35S73=+ffCFUMABdxgA@mail.gmail.com>
	<20110818171608.GA11734@ocelot>
Message-ID: <CAMfjfuF8OVZoty_-bR9Ftf=nhbOQ9zD8Ejgm0r5GKJWMEWFN6w@mail.gmail.com>

> I finally got a chance to try this out. For the most part it seems to
> be working. However, one bit of behavior is a bit puzzling.

Thanks for testing it out :-)

> I have two monitors. On the first, I have a single terminal window open,
> the second is empty. If I move the mouse to the empty monitor and try to
> change desktops, it changes the first monitor's desktop instead.

This actually sounds like it is working as I intended. You should be
able to *click* on that empty monitor, and focus should switch to that
desktop. Does that work for you? (If you have a "desktop" window, like
one that KDE might put there, then this won't work.)

> The
> only way I've found to bring focus to the empty monitor (I don't have
> "FocusRoot" bindings installed yet) is to try to change to whatever
> desktop is currently being shown on that monitor

Mouse clicking should work; hopefully that's something you just
haven't tried yet and nothing buggy is happening.

> (I assume this won't
> work if I turn on "greedy" desktops).

Right. It would bring whichever desktop you're switching to to the
current monitor.

> Maybe we could track the "active monitor", updating it whenever a new
> window is selected OR the mouse enters a monitor?

Well, the active monitor should switch if you focus a window. (Greedy
is forcefully disabled from this kind of desktop switching.)

The mouse *entering* the monitor is an interesting idea. Sort of like,
monitor-focus-follows-mouse. I'll definitely experiment with that,
although it will have to wait a few days; I'll be camping this
weekend.

I should mention that the FocusRoot option is intended to make monitor
switching really easy. Perhaps that would work for you in the interim?
(I am not suggesting that monitor-focus-follows-mouse is made useless
by FocusRoot, though.) I like to bind 'Alt-w', 'Alt-e' and 'Alt-r' to
monitors 1, 2 and 3. It should switch monitor focus whether the
monitor is empty or not.

>> I've include a small Python script 'ob-visible-desks' ...
>
> I installed xpyb and your xpyb-utils lib. The ob-visible-desks script
> prints out a single line, but then loses the X connection as soon as
> window focus or the current desktop changes (maybe when any X event is
> received?). I'll try to dig into it more this weekend, but wanted to
> give you a heads up.

Yeah, unfortunately you're going to need xpyb-git or xpyb-ng-git. (I
recommend the latter if it's doable.) The xpyb package is absurdly
outdated and broken.

>> - Develop a pager that works with this new desktop model.
>
> The pager you wrote seems to work, although I'm still on python2.6,
> which doesn't have the { x:y for x,y in ... } construct yet. Easy enough
> to fix, however.

Ah, damn. It'd probably be a good idea to roll my dependencies back to
2.6, because I don't think I'm using anything substantial from 2.7. I
can't say this will be a priority in the immediate future, though.

> Anyway, its definitely a good start!
>
> Take care,
> Brian
>
> P.S. This is all on ubuntu 10.04, so some issues could be due to older
> packages.

Thanks again for taking a stab! I appreciate the feedback :-)

- Andrew

From phil at gunnewiek.com  Thu Aug 18 20:06:05 2011
From: phil at gunnewiek.com (Phil Gunnewiek)
Date: Thu, 18 Aug 2011 20:06:05 -0400
Subject: [openbox] Revert back to the old Alt-Tab?
Message-ID: <CAPcpt9FnNYc0qtmepmy8CJcVUQ4P1tzfk2eNZC=LRD=q3tkwrA@mail.gmail.com>

Is it possible to revert back to the previous alt-tab dialogue? I much
prefer it to the new vertical one.

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/openbox/attachments/20110818/94630b34/attachment.htm>

From itz at buug.org  Sat Aug 20 02:35:23 2011
From: itz at buug.org (Ian Zimmerman)
Date: Fri, 19 Aug 2011 23:35:23 -0700
Subject: [openbox] ignore client requested coordinates?
Message-ID: <87ippsoaj8.fsf@matica.localdomain>


I have an app that tries to remember its last screen position and
reappear at the same place, but in this case that is quite unwanted.
How can I make openbox ignore that request and apply the regular
placement algorithm?

It's an old X Toolkit program if that matters.

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Rule 420: All persons more than eight miles high to leave the court.

From openboxml023478 at rainslide.net  Sat Aug 20 08:31:43 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sat, 20 Aug 2011 13:31:43 +0100
Subject: [openbox] ignore client requested coordinates?
In-Reply-To: <87ippsoaj8.fsf@matica.localdomain>
References: <87ippsoaj8.fsf@matica.localdomain>
Message-ID: <20110820123143.GA20518@rainslide.net>

On Fri, Aug 19, 2011 at 11:35:23PM -0700, Ian Zimmerman wrote:
>I have an app that tries to remember its last screen position and
>reappear at the same place, but in this case that is quite unwanted.
>How can I make openbox ignore that request and apply the regular
>placement algorithm?

 From the example rc.xml that comes with Openbox:

<position force="no">
     # the position is only used if both an x and y coordinate are provided
     # (and not set to 'default')
     # when force is "yes", then the window will be placed here even if it
     # says you want it placed elsewhere.    this is to override buggy
     # applications who refuse to behave
     <x>center</x>
     # a number like 50, or 'center' to center on screen. use a negative number
     # to start from the right (or bottom for <y>), ie -50 is 50 pixels from the
     # right edge (or bottom).
     <y>200</y>
     <monitor>1</monitor>
     # specifies the monitor in a xinerama setup.
     # 1 is the first head, or 'mouse' for wherever the mouse is
</position>

-- 

.

From itz at buug.org  Sat Aug 20 12:37:59 2011
From: itz at buug.org (Ian Zimmerman)
Date: Sat, 20 Aug 2011 09:37:59 -0700
Subject: [openbox] ignore client requested coordinates?
In-Reply-To: <20110820123143.GA20518@rainslide.net> (Paul's message of "Sat,
	20 Aug 2011 13:31:43 +0100")
References: <87ippsoaj8.fsf@matica.localdomain>
	<20110820123143.GA20518@rainslide.net>
Message-ID: <87wre8hwd4.fsf@matica.localdomain>


Ian> I have an app that tries to remember its last screen position and
Ian> reappear at the same place, but in this case that is quite unwanted.
Ian> How can I make openbox ignore that request and apply the regular
Ian> placement algorithm?

Paul> From the example rc.xml that comes with Openbox:

Paul> <position force="no">
Paul> # the position is only used if both an x and y coordinate are provided
Paul> # (and not set to 'default')
Paul> # when force is "yes", then the window will be placed here even if it
Paul> # says you want it placed elsewhere.    this is to override buggy
Paul> # applications who refuse to behave
Paul> <x>center</x>
Paul> # a number like 50, or 'center' to center on screen. use a negative number
Paul> # to start from the right (or bottom for <y>), ie -50 is 50 pixels from the
Paul> # right edge (or bottom).
Paul> <y>200</y>
Paul> <monitor>1</monitor>
Paul> # specifies the monitor in a xinerama setup.
Paul> # 1 is the first head, or 'mouse' for wherever the mouse is
Paul> </position>

Well, I saw that ;-) It doesn't really say how to do what I wrote,
though.  Should I use "default" for both x and y?

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Rule 420: All persons more than eight miles high to leave the court.

From mikachu at gmail.com  Sat Aug 20 16:13:01 2011
From: mikachu at gmail.com (Mikael Magnusson)
Date: Sat, 20 Aug 2011 22:13:01 +0200
Subject: [openbox] Revert back to the old Alt-Tab?
In-Reply-To: <CAPcpt9FnNYc0qtmepmy8CJcVUQ4P1tzfk2eNZC=LRD=q3tkwrA@mail.gmail.com>
References: <CAPcpt9FnNYc0qtmepmy8CJcVUQ4P1tzfk2eNZC=LRD=q3tkwrA@mail.gmail.com>
Message-ID: <CAHYJk3SsDFVTdsWgR9ZsZNTUxO3a4xRTsXrwHNwt4r17-kGEeQ@mail.gmail.com>

On 19 August 2011 02:06, Phil Gunnewiek <phil at gunnewiek.com> wrote:
> Is it possible to revert back to the previous alt-tab dialogue? I much
> prefer it to the new vertical one.
> Phil

Yes, set <dialog>icons</dialog> in your nextwindow (or previouswindow) action.

-- 
Mikael Magnusson

From openboxml023478 at rainslide.net  Sun Aug 21 08:18:20 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Sun, 21 Aug 2011 13:18:20 +0100
Subject: [openbox] ignore client requested coordinates?
In-Reply-To: <87wre8hwd4.fsf@matica.localdomain>
References: <87ippsoaj8.fsf@matica.localdomain>
	<20110820123143.GA20518@rainslide.net>
	<87wre8hwd4.fsf@matica.localdomain>
Message-ID: <20110821121820.GA24116@rainslide.net>

On Sat, Aug 20, 2011 at 09:37:59AM -0700, Ian Zimmerman wrote:
>Well, I saw that ;-) It doesn't really say how to do what I wrote,
>though.  Should I use "default" for both x and y?

Oh, sorry. I don't know. Maybe try simply not giving the x and y elements.

-- 

.

From openboxml023478 at rainslide.net  Fri Aug 26 13:57:53 2011
From: openboxml023478 at rainslide.net (Paul)
Date: Fri, 26 Aug 2011 18:57:53 +0100
Subject: [openbox] 3.5.0 Wiki
Message-ID: <20110826175753.GA6970@rainslide.net>

FYI, I've just seen that the Arch Linux wiki (https://wiki.archlinux.org/index.php/Openbox) has better documentation for 3.5.0 than Openbox's own wiki, in particular it mentions the 'environment' file as well as 'showIcons' and some troubleshooting tips.

-- 

.

From earshinov at gmail.com  Sat Aug 27 05:53:16 2011
From: earshinov at gmail.com (Eugene Arshinov)
Date: Sat, 27 Aug 2011 13:53:16 +0400
Subject: [openbox] [Recipe] Using Openbox in Gnome 3 Fallback Mode
In-Reply-To: <20110729134320.17159994@ibm>
References: <20110729134320.17159994@ibm>
Message-ID: <20110827135316.11d05a0f@ibm>

Hi there.  A little addition to the previous mail: what I described
was already proposed in a bug report months ago (#5022 [1])

[1] https://bugzilla.icculus.org/show_bug.cgi?id=5022

From dana at orodu.net  Tue Aug 30 12:02:34 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:02:34 -0400
Subject: [openbox] Cycle windows with mouse wheel
In-Reply-To: <CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
References: <d85253a21001112126n3f3d5851kca2d8e18c5a95c96@mail.gmail.com>
	<d85253a21001112136v324082bew903e7527f6f9b58e@mail.gmail.com>
	<d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
	<CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
Message-ID: <CAP1a_acc2V5K4sDBkWsup8w3myvszDiXaiaE8RwRj+iQ=Qcauw@mail.gmail.com>

On Wed, Aug 17, 2011 at 1:30 PM, Tom Wizetek <tom at wizetek.com> wrote:
>
> I'm still looking for the ability to cycle windows with a mouse wheel up/down.
>
> my ~/.config/openbox/rc.xml:
>
> ?<context name="Desktop">
> ? ?<mousebind button="Up" action="Click">
> ? ? ?<action name="PreviousWindow">
> ? ? ? ?<dialog>no</dialog>
> ? ? ? ?<bar>yes</bar>
> ? ? ? ?<raise>yes</raise>
> ? ? ? ?<linear>no</linear>
> ? ? ?</action>
> ? ?</mousebind>
> ? ?<mousebind button="Down" action="Click">
> ? ? ?<action name="NextWindow">
> ? ? ? ?<dialog>no</dialog>
> ? ? ? ?<bar>yes</bar>
> ? ? ? ?<raise>yes</raise>
> ? ? ? ?<linear>no</linear>
> ? ? ?</action>
> ? ?</mousebind>
> ?</context>
>
> The issue is that after cycling windows I have to make a window active
> either with a left-mouse-click or by pressing ENTER on the keyboard. I
> am now running openbox-git 20110816 on Arch Linux.
>
> It was mentioned at some point that a 'stopInteractive' config option
> in the <focus> section would take care of it but I can't seem to get
> it to work.
>
> How can I get the desired behaviour?

Use a <finalactions> option in the NextWindow action.  This holds
whatever actions you want to execute.  Make one of them "Focus" with
the option "stopInteractive" set to true.

From dana at orodu.net  Tue Aug 30 12:04:43 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:04:43 -0400
Subject: [openbox] 3.5.0, $GLOBALAUTOSTART
In-Reply-To: <20110807100338.GA12535@rainslide.net>
References: <20110807100338.GA12535@rainslide.net>
Message-ID: <CAP1a_ace8HZTaQxTYfPte6Oc0jFd=PbYbSzo+VC_DsQk11ASoA@mail.gmail.com>

On Sun, Aug 7, 2011 at 6:03 AM, Paul <openboxml023478 at rainslide.net> wrote:
> I've always had ". $GLOBALAUTOSTART" at the beginning of my
> ~/.config/openbox/autostart.sh. I upgraded to 3.5.0 and restarted X. Openbox
> started, but it didn't execute anything after that line in autostart.sh. I
> looked at the X output window and saw that it was complaining about not
> being able to source anything at that line, in other words, $GLOBALAUTOSTART
> was not defined. I commented out the line and restarted X again. Openbox
> started as it usually does, executing everything in autostart.sh. Is this
> new behaviour of 3.5.0, that $GLOBALAUTOSTART has now been removed?

GLOBALAUTOSTART is no longer being passed to the user's autostart
script.  Instead, the system wide autostart file is run before the
user one automatically.

From dana at orodu.net  Tue Aug 30 12:06:15 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:06:15 -0400
Subject: [openbox] 3.5.0, openbox-xdg-autostart
In-Reply-To: <20110807100743.GA12576@rainslide.net>
References: <20110807100743.GA12576@rainslide.net>
Message-ID: <CAP1a_adQEOX7ZDeWFpyW3kjgfV0P57NYML483KSPDqo=8MWr=g@mail.gmail.com>

On Sun, Aug 7, 2011 at 6:07 AM, Paul <openboxml023478 at rainslide.net> wrote:
> I noticed in my X output the following line after I upgraded to 3.5.0.
> Openbox seems to be running normally (after commenting out the
> $GLOBALAUTOSTART line in autostart.sh - see my previous post), so is it
> anything to worry about?
>
> ERROR: openbox-xdg-autostart requires PyXDG to be installed

Only if you want to run things via the .desktop autostart system.
This allows packaging systems to easily define applications that
should be started with your X session.  If you don't want that then
you don't need to worry.

From dana at orodu.net  Tue Aug 30 12:08:55 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:08:55 -0400
Subject: [openbox] 3.5.0 Wiki
In-Reply-To: <20110826175753.GA6970@rainslide.net>
References: <20110826175753.GA6970@rainslide.net>
Message-ID: <CAP1a_afxW_gNHuLXAQXhx5Jg2_jhQkJNTvAt_zuWxiZg1mtHbQ@mail.gmail.com>

On Fri, Aug 26, 2011 at 1:57 PM, Paul <openboxml023478 at rainslide.net> wrote:
> FYI, I've just seen that the Arch Linux wiki
> (https://wiki.archlinux.org/index.php/Openbox) has better documentation for
> 3.5.0 than Openbox's own wiki, in particular it mentions the 'environment'
> file as well as 'showIcons' and some troubleshooting tips.

Cool, well at least the environment file I know I added to the Openbox
wiki myself a while ago, in the autostart section.  But there's lots
of things that could be filled in for sure.  And some better
organization also.  Glad to know the arch wiki is doing a good job.

From dana at orodu.net  Tue Aug 30 12:12:31 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:12:31 -0400
Subject: [openbox] [Recipe] Using Openbox in Gnome 3 Fallback Mode
In-Reply-To: <20110827135316.11d05a0f@ibm>
References: <20110729134320.17159994@ibm> <20110827135316.11d05a0f@ibm>
Message-ID: <CAP1a_acoUamnppFtCs8PueEpsdoiO4TX3YPVRVA6-4zoL5Ko2w@mail.gmail.com>

Does this fix the "missing registration" issue that gnome-session 3
was reporting, causing the X session to be terminated?

On Sat, Aug 27, 2011 at 5:53 AM, Eugene Arshinov <earshinov at gmail.com> wrote:
> Hi there. ?A little addition to the previous mail: what I described
> was already proposed in a bug report months ago (#5022 [1])
>
> [1] https://bugzilla.icculus.org/show_bug.cgi?id=5022
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>

From dana at orodu.net  Tue Aug 30 12:15:09 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:15:09 -0400
Subject: [openbox] Openbox unable to build on Debian Wheezy/Sid
In-Reply-To: <BANLkTi=i3-WeKsn=oX-SMJo-wokxudvwuQ@mail.gmail.com>
References: <BANLkTi=i3-WeKsn=oX-SMJo-wokxudvwuQ@mail.gmail.com>
Message-ID: <CAP1a_aeCFHFPAw1ZgC2r8t=fqc_t1TRxFw0uWSnmXic538QkDQ@mail.gmail.com>

On Fri, May 13, 2011 at 5:21 PM, Israel Jacques <mrkotfw at gmail.com> wrote:
> Hello everyone.
>
> I was unable to build openbox from the Git repos. This is under Debian
> Wheezy/Sid. Attached (and a link) of the patch: http://sprunge.us/iAMa?diff

This is fixed now yes ?

From dana at orodu.net  Tue Aug 30 12:17:02 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:17:02 -0400
Subject: [openbox] Claws-Mail and lost focus
In-Reply-To: <20110420010453.70027d99@gaydenko.com>
References: <20110420010453.70027d99@gaydenko.com>
Message-ID: <CAP1a_af8W8SpH6KZA_cGJuhozu7J-OisrEEQe82S20EXxg+=3g@mail.gmail.com>

Hello,

On Tue, Apr 19, 2011 at 5:04 PM, Andrew Gaydenko <a at gaydenko.com> wrote:
> Hi!
>
> Claws-Mail is yet the only application I have noticed having problems with focus. Steps to reproduce are:
>
> 1. open two apps on a desktop X, being Claws-Mail one og the apps
> 2. select (focus) Claws-Mail
> 3. switch to desktop Y
> 4. return to desktop X
>
> Result: Claws-Mail is still above another (opened on desktop X) app, but it is that second app who accepts keyboard input.
>
> At my case Firefox played the role of that second app, and it is very funny to see Claws-Mail, but - via Alt-F - to navigate Firefox menu.
>
> BTW, tint2 also shows the second app to be active.
>
> Can anybody suggest ideas for further issue investigation? Which window/application properties are in the game? How to browse and direct them? Workarounds? Additional action for desktop X switch key?
>
> //---- lyrics ---
>
> I have switched from KDE to OpenBox just few days ago and very happy with this migration. Indeed. Very. And it is the only issue I have. Unfortunately, it is rather annoying issue as far as mail client is one of the main app I use during all the day (and, you see, night also).
>
> Under other WM/DE which I have tried there were not any such problems with Claws-Mail (or any other apps).

Could you open a bug report in the bugzilla for this problem?  It
sounds sketchy and I'd like to look at it, and keep track of it in
there.

Thanks!

From dana at orodu.net  Tue Aug 30 12:18:54 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:18:54 -0400
Subject: [openbox] openbox menus called from xlib
In-Reply-To: <4D754B3D.5060008@scribus.info>
References: <4D754B3D.5060008@scribus.info>
Message-ID: <CAP1a_acGgcz5ixCgOxv5cD8NMZOasE4rX0sAVV9+rmvqtW_Lgw@mail.gmail.com>

On Mon, Mar 7, 2011 at 4:16 PM, Petr Vanek <petr at scribus.info> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi all,
>
> I need to implement something to be able to call openbox menu(s) when
> user clicks on my app main widget (fullscreen, the first app in the
> openbox session).
>
> I try to do it this way:
> http://pastebin.com/azeN8Rvp
>
> But it looks like it works for normal windows but not for root one -
> the app menu is shown for eg. terminal window.
>
> Are openbox menus handled over Xlib mouse Xevents? Or are they handled
> in another way?

They are currently opened only thru Openbox actions, which are only
accessible via keyboard or mouse bindings.  I'd like to change this in
the future but atm that's what we've got.

> thanks,
> Petr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNdUs9AAoJEC8yRjM4uE2tpqwH/1ttxwWpBMejTK4fWqtkMMIM
> 5CgeNdUHAwZGQvp3EHZg+THQy4k0CWY4QsYE2XvluXQYHnIOKsFIJbbWkMH3URWH
> LDPXMacA+s2kNENzM4KbF2y3MfL2XSk9O0388t5yWRtw9V7FAzo057gvWEouRvf4
> prf3piwuJDKnc3vzr26xtz/X0Kdd13I3Wuuk7uLiuD6IPpWNPaAxjwiBxqVwE8Ni
> YRlEgFmA5+5EJ3BS02XTQGFEdf42CdmpRwkAJ5XmstHRFfH0517ztkW5e97lcnys
> s7bVjJNNbWk56Ee7MWxj+WRq+Cu2mrMRONopgMlFfzcKkufDxhkg8FoBR0noKmM=
> =Mehi
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>

From dana at orodu.net  Tue Aug 30 12:21:04 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:21:04 -0400
Subject: [openbox] Fullscreen and window layers problem
In-Reply-To: <1301354038.18894.37.camel@hans-laptop>
References: <1301354038.18894.37.camel@hans-laptop>
Message-ID: <CAP1a_aer8tVjP+RvnMe7CKA9t-UqhN6D7Gef_+VYXMA9KO7fQA@mail.gmail.com>

On Mon, Mar 28, 2011 at 7:13 PM, arcasys <mail at arcasys.de> wrote:

> **
> Hi folks,
> I'm new to the list and I'm using openbox since quite a while for a Java
> based POS system (POSper).
> I like openbox for being  so lightweight and easy to configure.
> Now here's the problem:
>
> The Java application POSper can run in window mode (but using the full
> screen resolution or in fullscreen mode. In openbox it's configured to run
> without window decorations.
> The system uses a touchscreen, no keyboard, no mouse.
> For occasional keyboard input, a virtual keyboard (xvkbd) can be started
> from the application. In openbox it's configured
> to appear at a defined position and on top.
> If I start POSper in window mode everything is fine: the keyboard pops up
> and I can enter input.
> But if I start POSper in fullscreen mode the virtual keyboard never appears
> on top although it's running.
>
> Why can' I just stay with fullscreen mode then? Because, depending on the
> monitor used, it can happen that a user inadvertently touches a border of
> the window
> and wipes it out of position and it's near to impossible to bring it back.
>
> So I'm in a dilemma: I can either keep the application window stable in
> place and have no virtual keyboard available or I can have the keyboard but
> risk moving the application window.
>
> I'd be grateful for any idea how to bring the  virtual keyboard on top even
> when the Java application is in fullscreen mode.
>

There was some discussion of this issue on the wmspec mailing list also.
 Fullscreen windows are required to be above all other unrelated windows.

A solution for this problem that was suggested there is to have the keyboard
window adjust its parent to whatever window currently has focus.  That may
not help you, but we're unable to stick the keyboard above a fullscreen
window without that, and without being noncompliant with the specification
(and breaking other things).


>
> Thanks
> Hans
>
>
>
> Kassensysteme
> Warenwirtschaft
> Vernetzung
> __________________________
> Hans Artmann
> Fl?ggenstr. 10
> 80639 M?nchen
> Tel +49 89 17095721
> Fax +49 89 17095722
> Mob +49 151 17413090
> www.arcasys.de
>
> Ust-Id: DE261339573
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/openbox/attachments/20110830/8fe422be/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1618 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20110830/8fe422be/attachment-0001.gif>

From dana at orodu.net  Tue Aug 30 12:22:58 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:22:58 -0400
Subject: [openbox] pam-ssh or gnome-keyring?
In-Reply-To: <20110414080741.GA14110@apartia.fr>
References: <20110408071528.GA13835@apartia.fr>
	<20110414080741.GA14110@apartia.fr>
Message-ID: <CAP1a_adrhcz9DvQC6f6ApS9TDdxD5M+27HMM6c4iCWhgbzNrLQ@mail.gmail.com>

On Thu, Apr 14, 2011 at 4:07 AM, Louis-David Mitterrand
<vindex+lists-openbox at apartia.org> wrote:
> On Fri, Apr 08, 2011 at 09:15:28AM +0200, Louis-David Mitterrand wrote:
>> Hi,
>>
>> I'm using gdm3 as login manager and a ~/.xsession file with
>>
>> ? ? ? exec openbox
>>
>> to launch ob when using "session default" in gdm3.
>>
>> When I login to gnome gnome-keyring automatically unlocks my ssh key.
>> How can I have the same thing when logging in to straight openbox?
>
> Answering my own question. Maybe worthy of a FAQ entry?

Or you could add a page to the wiki somewhere to discuss gnome-keyring
and openbox interaction. :)

>
> In order to use the gnome-keyring-daemon launched by
> libpam-gnome-keyring and gdm3 (under debian at least) when using a
> straight ~/.xsession file:
>
> - open a "gnome" session with gdm
>
> - launch a ssh session and unlock ssh key in the gnome-keyring dialog
> ?while checking the "unlock ssh key at login" (or something like that),
>
> - add in ~/.xsession:
>
> ? ? ? ?eval $(gnome-keyring-daemon --start --components=ssh)
>
> This configures the auto-launched gnome-keyring-daemon which otherwise
> times out and exits.
>
> - go back to your usual "system default" gdm session,
>
> - your ssh key is unlocked,
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>

From dana at orodu.net  Tue Aug 30 12:25:38 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 12:25:38 -0400
Subject: [openbox] grsync dialog window
In-Reply-To: <AANLkTi=LTnvbxR4FuE3pyrZ9y4G3mOw5v=fo=3RvZvqE@mail.gmail.com>
References: <AANLkTi=LTnvbxR4FuE3pyrZ9y4G3mOw5v=fo=3RvZvqE@mail.gmail.com>
Message-ID: <CAP1a_aeK7kf=V7sOYdJV=5Qw7u2OhSvWsTURka1FmS1U+kfx0A@mail.gmail.com>

2011/4/2 Francois du Toit <fpdutoit.lists at gmail.com>:
> Hi,
>
> When using grsync and clicking the run/dry-run button the dialog
> window pops up and all is well.
> But when any window goes over the grsync windows, clicking on the
> grsync button in the taskbar does not bring it to the front again. The
> only way to get to the grsync window is to minimize all windows.
>
> Is there anyway to fix this?

Not sure... Can you open a bug report for this in the bugzilla so we
can track it better?

Thanks!
- Dana

> Thanks
> Francois
>
> --
> ??
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>

From dana at orodu.net  Tue Aug 30 13:53:54 2011
From: dana at orodu.net (Dana Jansens)
Date: Tue, 30 Aug 2011 13:53:54 -0400
Subject: [openbox] ignore client requested coordinates?
In-Reply-To: <20110821121820.GA24116@rainslide.net>
References: <87ippsoaj8.fsf@matica.localdomain>
	<20110820123143.GA20518@rainslide.net>
	<87wre8hwd4.fsf@matica.localdomain>
	<20110821121820.GA24116@rainslide.net>
Message-ID: <CAP1a_aeef7c=vwAUxEJ80HWrKCh5p1pQxd77x1UbSs778reybQ@mail.gmail.com>

On Sun, Aug 21, 2011 at 8:18 AM, Paul <openboxml023478 at rainslide.net> wrote:
> On Sat, Aug 20, 2011 at 09:37:59AM -0700, Ian Zimmerman wrote:
>>
>> Well, I saw that ;-) It doesn't really say how to do what I wrote,
>> though. ?Should I use "default" for both x and y?
>
> Oh, sorry. I don't know. Maybe try simply not giving the x and y elements.

Would be nice to provide this.  There is no way besides overriding
with new positions at the moment.  Perhaps a bugzilla feature request
is in order?

From earshinov at gmail.com  Tue Aug 30 14:45:35 2011
From: earshinov at gmail.com (Eugene Arshinov)
Date: Tue, 30 Aug 2011 22:45:35 +0400
Subject: [openbox] [Recipe] Using Openbox in Gnome 3 Fallback Mode
In-Reply-To: <CAP1a_acoUamnppFtCs8PueEpsdoiO4TX3YPVRVA6-4zoL5Ko2w@mail.gmail.com>
References: <20110729134320.17159994@ibm> <20110827135316.11d05a0f@ibm>
	<CAP1a_acoUamnppFtCs8PueEpsdoiO4TX3YPVRVA6-4zoL5Ko2w@mail.gmail.com>
Message-ID: <20110830224535.36d8bab6@ibm>

On Tue, 30 Aug 2011 12:12:31 -0400
Dana Jansens <dana at orodu.net> wrote:

> Does this fix the "missing registration" issue that gnome-session 3
> was reporting, causing the X session to be terminated?
> 

No.  Currently I have to stick with 3.4.11 because of that.  For
clarity, that was me who added comments #1 and #2 in the bug report.
 
> On Sat, Aug 27, 2011 at 5:53 AM, Eugene Arshinov
> <earshinov at gmail.com> wrote:
> > Hi there. ?A little addition to the previous mail: what I described
> > was already proposed in a bug report months ago (#5022 [1])
> >
> > [1] https://bugzilla.icculus.org/show_bug.cgi?id=5022
> > _______________________________________________
> > openbox mailing list
> > openbox at icculus.org
> > http://icculus.org/mailman/listinfo/openbox
> >
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox

From tom at wizetek.com  Wed Aug 31 00:31:30 2011
From: tom at wizetek.com (Tom Wizetek)
Date: Wed, 31 Aug 2011 00:31:30 -0400
Subject: [openbox] Cycle windows with mouse wheel
In-Reply-To: <CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
References: <d85253a21001112126n3f3d5851kca2d8e18c5a95c96@mail.gmail.com>
	<d85253a21001112136v324082bew903e7527f6f9b58e@mail.gmail.com>
	<d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
	<CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
Message-ID: <CABBrbZFT37kBqgXQWnfrA+yxu46vBTNOEkgDaZ149wu8jD586Q@mail.gmail.com>

Did I get this right?

      <mousebind button="Down" action="Click">
        <action name="NextWindow">
          <dialog>none</dialog>
          <bar>yes</bar>
          <raise>yes</raise>
          <linear>no</linear>
          <finalactions>
            <action name="Focus">
              <stopInteractive>true</stopInteractive>
            </action>
          </finalactions>
        </action>
      </mousebind>

This still doesn't do it for me. :(

From bogorodskiy at gmail.com  Wed Aug 31 01:12:29 2011
From: bogorodskiy at gmail.com (Roman Bogorodskiy)
Date: Tue, 30 Aug 2011 22:12:29 -0700
Subject: [openbox] time for obconf release?
Message-ID: <20110831051229.GB2616@reemsky>

Hi,

openbox 3.5.0 was released not so long ago and introduced a few changes
that make obconf 2.0.3 incompatible with the new openbox.

Are there any plans to release a new version of obconf (as it seems
all the stuff was fixed in the git version already)?

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20110830/828c4a85/attachment.pgp>

From dana at orodu.net  Wed Aug 31 10:14:15 2011
From: dana at orodu.net (Dana Jansens)
Date: Wed, 31 Aug 2011 10:14:15 -0400
Subject: [openbox] time for obconf release?
In-Reply-To: <20110831051229.GB2616@reemsky>
References: <20110831051229.GB2616@reemsky>
Message-ID: <CAP1a_adkoH1pV2e6sePKVTdxcrEpFx=-ViXwZ3L0FmNqbCjfQg@mail.gmail.com>

On Wed, Aug 31, 2011 at 1:12 AM, Roman Bogorodskiy
<bogorodskiy at gmail.com> wrote:
> Hi,
>
> openbox 3.5.0 was released not so long ago and introduced a few changes
> that make obconf 2.0.3 incompatible with the new openbox.
>
> Are there any plans to release a new version of obconf (as it seems
> all the stuff was fixed in the git version already)?

Well I'm not able to do anything with it at the moment due to life but
will plan on it sometime soon.

> Roman Bogorodskiy
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>
>

From dana at orodu.net  Wed Aug 31 10:18:03 2011
From: dana at orodu.net (Dana Jansens)
Date: Wed, 31 Aug 2011 10:18:03 -0400
Subject: [openbox] Cycle windows with mouse wheel
In-Reply-To: <CABBrbZFT37kBqgXQWnfrA+yxu46vBTNOEkgDaZ149wu8jD586Q@mail.gmail.com>
References: <d85253a21001112126n3f3d5851kca2d8e18c5a95c96@mail.gmail.com>
	<d85253a21001112136v324082bew903e7527f6f9b58e@mail.gmail.com>
	<d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
	<CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
	<CABBrbZFT37kBqgXQWnfrA+yxu46vBTNOEkgDaZ149wu8jD586Q@mail.gmail.com>
Message-ID: <CAP1a_aekZEt-D07ZxuwWjHA7wDkDrLj2GinF03pEWExTkVo=Ww@mail.gmail.com>

On Wed, Aug 31, 2011 at 12:31 AM, Tom Wizetek <tom at wizetek.com> wrote:
> Did I get this right?
>
> ? ? ?<mousebind button="Down" action="Click">
> ? ? ? ?<action name="NextWindow">
> ? ? ? ? ?<dialog>none</dialog>
> ? ? ? ? ?<bar>yes</bar>
> ? ? ? ? ?<raise>yes</raise>
> ? ? ? ? ?<linear>no</linear>
> ? ? ? ? ?<finalactions>
> ? ? ? ? ? ?<action name="Focus">
> ? ? ? ? ? ? ?<stopInteractive>true</stopInteractive>
> ? ? ? ? ? ?</action>
> ? ? ? ? ?</finalactions>
> ? ? ? ?</action>
> ? ? ?</mousebind>
>
> This still doesn't do it for me. :(

Well that is what I suggested.. but if I think about it I guess that
shouldn't work.  Sorry I don't have the ability to try things first at
the moment.

I think what Mikachu meant, and what is correct is something like

<mousebind ...>
  <action name="NextWindow">...</action>
  <action name="Focus"><stopInteractive>yes</stopInteractive></action>
</mousebind>

The first should select the next window, the 2nd action should focus
is and kill the interactive thing.

From dana at orodu.net  Wed Aug 31 11:23:30 2011
From: dana at orodu.net (Dana Jansens)
Date: Wed, 31 Aug 2011 11:23:30 -0400
Subject: [openbox] Running KDE apps in Openbox
In-Reply-To: <BANLkTikgu=BuVZwT6e1EjGONegFU7yJJYQ@mail.gmail.com>
References: <BANLkTi=J-uBCYH39L1JqwCuGOPfD=FKEZw@mail.gmail.com>
	<BANLkTi=1dj87yk=6m3EYybz=jKUxBr0V4Q@mail.gmail.com>
	<20110424090546.M52422@mh-freiburg.de>
	<BANLkTikgu=BuVZwT6e1EjGONegFU7yJJYQ@mail.gmail.com>
Message-ID: <CAP1a_adk=J7eV7nGbmkAcDpw60BLRgChOAYmHEv+F5zZjjF8kw@mail.gmail.com>

On Sun, Apr 24, 2011 at 5:44 AM, Piscium <groknok at gmail.com> wrote:
> On 24 April 2011 10:08, R. Mattes <rm at mh-freiburg.de> wrote:
>> On Sun, 24 Apr 2011 09:59:54 +0100, Piscium wrote
>>> ....
>>> But my previous question still stands (though slightly modified):
>>> which options or environment variables should I call kdeinit4 with
>>> for optimal operation of KDE 4 apps? I am not familiar at all with
>>> KDE and just want to try a few apps out in Openbox, that is why I am
>>> asking this.
>>
>> Wouldn't it be much more appropriate to ask this question on a KDE
>> mailing list?
>
> I think you have a point, and I may still do that. I thought I would
> try on this list first because on the KDE list people will probably be
> (and this is just a guess) more familiar with running KDE with the KDE
> window manager. I want to see if it is possible to have KDE apps
> co-exist peacefully with Gnome, XFCE and LXDE apps in Openbox, which
> is sometimes tricky using the default window managers for Gnome and
> KDE.
>
>> BTW, if you really only want to run some KDE applications
>> there seems to be no need at all to run start_kdeinit ... I usually just
>> run KDE apps from the terminal.
>
> Thanks, that was good to know.

Well, nothing is required, but it saves time when you are starting up
your first KDE application.

I found the command you mentioned by reading through the startkde or
whatever it is called script that is run to start a KDE session.  I
imagine they have some other script for kde4 and it may or may not
launch some daemon process to set things up.  It should be done the
same way that they do it.

If you wouldn't mind, a bug report in the bugzilla would help make
sure we come back to this and update that command in the autostart to
something more appropriate for kde4.  Also any information you've
gotten from KDE folks would be of use.

Cheers,
Dana

From dana at orodu.net  Wed Aug 31 13:32:40 2011
From: dana at orodu.net (Dana Jansens)
Date: Wed, 31 Aug 2011 13:32:40 -0400
Subject: [openbox] Openbox seems to ignore gravity for
	_NET_MOVERESIZE_WINDOW
In-Reply-To: <20110628122211.1aa4a27f@wraith>
References: <20110628122211.1aa4a27f@wraith>
Message-ID: <CAP1a_ac1K73hsy+4pbq4M6dp2UymRnaKEmQZre_CUooV-6MEcQ@mail.gmail.com>

On Mon, Jun 27, 2011 at 10:22 PM, Anthony Thyssen
<A.Thyssen at griffith.edu.au> wrote:
>
>
> I am using "wmctrl" to move windows, and I want to be able to make use
> of the gravity option in that properity. ?However in my testing openbox
> seems to ignore that setting.
>
> For example...
> ? wmctrl -v -r :ACTIVE: -e 0,20,20,-1,-1
>
> is normal and moves the window relative to the top-left corner. However
> any other value for that first number (a number from 0 to 10) ?does not
> effect the window placement.
>
> For example
> ?wmctrl -v -r :ACTIVE: -e 9,20,20,-1,-1
>
> should position the window relative to the bottom right (south east) corner of the
> desktop. ?but it still appears at the topleft corner.
>
> The gravity setting is being sent, but openbox is ignoring it.
>
>
> For info on the settings see...
> ?http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html

Definitely sounds like a bug. Would you mind opening a bugzilla entry
for this, so we can track it to completion properly?

Thanks!
- Dana

From tom at wizetek.com  Wed Aug 31 13:57:09 2011
From: tom at wizetek.com (Tom Wizetek)
Date: Wed, 31 Aug 2011 13:57:09 -0400
Subject: [openbox] Cycle windows with mouse wheel
In-Reply-To: <CABBrbZFT37kBqgXQWnfrA+yxu46vBTNOEkgDaZ149wu8jD586Q@mail.gmail.com>
References: <d85253a21001112126n3f3d5851kca2d8e18c5a95c96@mail.gmail.com>
	<d85253a21001112136v324082bew903e7527f6f9b58e@mail.gmail.com>
	<d85253a21001120722j777c7938vfe213c7388582a5d@mail.gmail.com>
	<CABBrbZGjDSOJaB0oHbwzyQ46sF3DYnO+BjyFLGzirKkXostKGw@mail.gmail.com>
	<CABBrbZFT37kBqgXQWnfrA+yxu46vBTNOEkgDaZ149wu8jD586Q@mail.gmail.com>
Message-ID: <CABBrbZEPng9wZYx6UQ1vgL_nJ8wBTMzWRVSd_XPBnJYNgfUO_A@mail.gmail.com>

I appreciate your input Dana. Regrettably, your last suggestion isn't
working either.

I also tried...

      <mousebind button="Down" action="Click">
        <action name="NextWindow">
          <dialog>none</dialog>
          <bar>yes</bar>
          <raise>yes</raise>
          <stopInteractive>yes</stopInteractive>
        </action>
      </mousebind>

...without success. When you (or anyone else) get a chance to try it
on your system, please do.

P.S.
If you're bothered by the messed up message threading here, that's
because I'm not subscribed to receive them via email. I read the
responses on icculus.org and just reply to my own initial sent
message.

From johnfbell3 at gmail.com  Wed Aug 31 20:07:28 2011
From: johnfbell3 at gmail.com (John Bell)
Date: Thu, 1 Sep 2011 07:07:28 +0700
Subject: [openbox] Set position of root-menu when triggered via hot-key
Message-ID: <CAF9_zTGiV9bekLkayKziEh5M2v4HKD8ZwkcGuuFUr5A=xXDQWA@mail.gmail.com>

I'd like the root-menu (when triggered via hot key) to always appear
in a specified place on the screen instead of at the position of the
cursor.

Is this possible?

John Bell

