Re: openbox Digest, Vol 59, Issue 7

I forgot to say:

me@ubuntu:~$ openbox --version
Openbox 3.5.2

On 1/16/14, plmalternate plmalternate <[email protected]> wrote:
> I've gone as far as I can with this. Here are my tentative conclusions:
>
> All the aps I've checked ignore width and height statements in
> ~/.config/openbox/rc.xml even with force set to yes.  Instead they
> open at whatever size they were last closed at, even if the system has
> been rebooted in the meantime.  The file is being read and the x and y
> statements are being acted upon.
>
> The best workaround I've found is to write scripts to open the aps,
> broadly along the lines of this pseudocode:
>
> nohup command-to-start-ap $* &
> #
> # The next step isn't strictly necessary, but if you might have
> multiple instances of the same program up simultaneously, it might be
> needed to give each a unique name so the resizing command will be able
> to do unto it by name.
> wmctrl-or-something-similar command to rename the window something unique
> sleep N
> wmctrl-or-sometning-similar command to set the size and position.
>
> where N is a number of seconds sufficient to let the ap open. In the
> ones I've tested 1 is usually sufficient. Firefox needs 3. YMMV.
> After that use a command from some program like wmctrl to adjust the
> size and position. I use wmctrl but there are others that would
> probably work as well.
>
> If you give the script a unique name and put it in your path you can
> call the program from the command line with that name. Or if you call
> the program with it's own name instead of the script name it will open
> at whatever size it closed at.
>
> I regard this as a bug, because there are no circumstances in which
> the width and height statements take effect other than possibly the
> trivial case of the first run of a newly installed program. I WAS
> UNABLE TO REPORT THIS AS A BUG because I couldn't start and account at
> bugzilla. They kept saying they'd sent me an email but it never came.
> I tried with 3 different email addresses,. If someone here can report
> it I think that would be a good thing.
>
> There were 3 other minor matters:
>
> 1. Windows often don't open at PRECISELY the size they closed at but
> at something very slightly, on the order of 5 pixels or so, different.
> I suspect this is unrelated. It's trivial enough I didn't pursue it.
>
> Speculation:  It is possible that wmctrl can set the size of windows
> at some values the windows don't "like" but can be forced to accept.
> When they are closed and reopened, the force of the
> reopen-at-the-size-you-closed-at principle isn't sufficient to
> override the aps "preference" to open in sizes that vary in increments
> greater than 1 pixel whereas wmctrl or manual resizing may have enough
> "authority" to force the window to accept a size in between more
> "preferred" values.
>
> 2. Similarly, windows often don't open at PRECISELY the position
> specified in rc.xml, but in some position slightly, again on the order
> of 5 pixels or so, different.
>
> Speculation # 1: Very similar to the speculation in case 1, above.
>   - or alternately -
> Speculation # 2: Wmctrl (which is the only other means I have for
> putting a window in a numerically specified place and therefore of
> seeing what that numerical specification means)  and the rc.xml use
> very slightly different definitions of what those numbers mean. There
> 0,0 point may not be exactly the same.
>
> 3. The difference in the behaviour of windows opened in a root
> terminal, vs the behaviour of windows opened with gksu and where the
> size for those windows opened with the root terminal, especially the
> width, was coming from. To me, this is the oddest thing I ran across
> and I haven't a clue why it did what it did. I am quite curious about
> it but it has little practical significance and off the top of my head
> I can't think of any experiment I can do to shed any light on it.
>
> If anyone has a bugzilla account (I can't seem to make the
> registration work) and wants to report this as a bug for what it is
> worth, some of my system specs:
> Ubuntu Saucy,13.10 installed from the mini.iso with only openbox, no
> other DE, thunar, no desktop. 32 bit.
>
> me@ubuntu:~$ uname -a
> Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC
> 2013 i686 athlon i686 GNU/Linux
> __________________
>
> Now a question: Can anyone here confirm with confidence they've gotten
> any of the aps mentioned to honor width and/or height specs in rc.xml
> over the open-at-the-size-closed-at commandment? And if so, can you
> tell us anything you think might be relevant?
>
> On 1/15/14, [email protected] <[email protected]>
> wrote:
>> Send openbox mailing list submissions to
>> 	[email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://icculus.org/mailman/listinfo/openbox
>> or, via email, send a message with subject or body 'help' to
>> 	[email protected]
>>
>> You can reach the person managing the list at
>> 	[email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openbox digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: openbox Digest, Vol 59, Issue 5 (plmalternate plmalternate)
>>    2. Re: openbox Digest, Vol 59, Issue 5 (plmalternate plmalternate)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 14 Jan 2014 18:24:21 -0500
>> From: plmalternate plmalternate <[email protected]>
>> To: [email protected]
>> Subject: Re: [openbox] openbox Digest, Vol 59, Issue 5
>> Message-ID:
>> 	<CAB2o_TFkv1YaqeS+kB_Xe7AgkTTgJfFqj703G_RjmvseFnqdCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Thank you, gentlesapients.  It's not a Firefox issue, or it is, Mirage
>> and Thunar have the same issue. I've done further testing.
>>
>> I realised I need to methodicly test these issues when it became
>> evident I must have been mistaken about Mirage. At any rate it now
>> ignores rc.xml when I change the height spec and relog. It just opens
>> whatever size it had when last open, or at least close to that size (I
>> make that reservation for a reason explained below). xprop gives:
>>
>> program specified minimum size: 421 by 54
>>
>> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
>>
>> WM_CLASS(STRING) = "mirage", "Mirage"
>> (does that mean it should recognise being addressed either way?)
>>
>> WM_ICON_NAME(STRING) = "Mirage - [1 of 1] 007.jpg"
>>
>> _NET_WM_ICON_NAME(UTF8_STRING) = "Mirage - [1 of 1] 007.jpg"
>>
>> WM_NAME(STRING) = "Mirage - [1 of 1] 007.jpg"
>>
>> _NET_WM_NAME(UTF8_STRING) = "Mirage - [1 of 1] 007.jpg"
>>
>> I've got redundant stanzas for title with and without an asterisk
>> following "Mirage" and the same for name in addition to the wildcard
>> stanzas supposed to apply to all windows not otherwise covered. I've
>> got all the stanzas except conky's set to 500 x 500 so if ANY of them
>> work I'm bound to notice the change. I just opened Mirage, wmctrled it
>> to 0,1,1,1912,1025, which I call "full". Closed it. Opened it again.
>> It opened at "full" again (ADDED LATER: Or maybe it was just close -
>> at this point I wasn't suspecting a SMALL displacement). Now I am
>> going to shutdown -h, let it cool, and boot up again, not just relog.
>> Overkill, I know. Giveing it every possible chance.
>>
>> Probably irrelevant but for completeness I should mention my next boot
>> failed to start x. I tried startx from the tty after logging in. It
>> said startx was part of a package not installed and I tried to install
>> it. Apt-get told me the filesystem was damaged and mounted read only.
>> So I sudo fsck'ed it and rebooted normally.
>>
>> OK, I'm seeing both problems with Mirage.
>> 1- It is NOT paying any attention to rc.xml.
>> 2- It opens up very close, but not quite, at the position I closed it
>> at. It is displaced slightly down and to the right of that position,
>> by something on the close order of 5 pixels in both dimensions. With
>> regard to vertical placement it could be that it has placed the top
>> boundary of the border where the bottom boundary was, just barely
>> below the edge of the screen. With respect to horizontal placement, it
>> could be it is doing the opposite - putting the outer edge of the
>> border where the inner edge was when I closed it. This is the same
>> pattern I saw with Firefox, and earlier, with Thunar. Obviously this
>> is not a huge problem. Probably many people would never notice it. But
>> it is annoying. I like to see my window borders because often I have
>> problems with windows that are larger than my screen and hiding
>> important buttons in consequence. A case in point is "Qt
>> Configuration, version 4.8.4". I'm pretty sure it's hiding an "apply",
>> "ok", or "close" button I can't get to. If I can see the borders, at
>> least I know that's not the problem and I'm not missing content. The
>> source of the problem with that window though is undoutedly different
>> from this "slight displacement from historical placement" problem. It
>> won't let me resize it with either mouse or wmctrl. It's just a darned
>> stubborn ap. Enough or Mirage. Now for:
>>
>> --------- Thunar ----------
>> I have a thunar window up already. I opened it with a script (here:
>> http://pastebin.com/XSCmtC36
>>  )that first opens thunar and then wmctrls it thus:
>> wmctrl -r "Desktop - File Manager" -e 0,0,60,1912,970
>> The script was called from an openbox menu entry thus:
>> <command>thun ~/Desktop</command>
>> "thun" is the filename of the script and it's in my path. I doubt any
>> of that's important. Thunar is a well behaved program like most (and
>> unlike "Qt Configuration") and responds to the wmctrl command
>> correctly. When I open it with that menu item, it first appears with
>> no visible bottom border, and then when the wmctrl statement hits it,
>> it jumps up and left a little, again on the close order of 5 pixels or
>> so. So that's where it is now. I close it. Gone. Now I open it with
>> "thunar" (bypassing the script) in lxterminal. Lxterminal didn't give
>> any messages - the cursor just jumped to the next line where it now
>> sits blinking. Thunar is slightly to the right and below its previous
>> placement, following the same pattern as Mirage and Firefox. I wmctrl
>> it from the menu thus:
>> wmctrl -r :SELECT: -e 0,150,1,1000,1078
>> and click on it. It changes size more or less as expected. The bottom
>> is a little lower than I thought that would give me, again by about
>> the width of my fat borders, but that is probably just that I didn't
>> get the numbers quite right when I was editing the menu. I don't use
>> that size very often. I close it by clicking the close button in the
>> title bar. Lxterminal gives me a new prompt. No messages have
>> appeared. So on my terminal are just 2 lines, one with a prompt
>> followed by "thunar" and the second with just a prompt and the
>> blinking cursor (the best thing about having the cursor blink is you
>> can say "the blinking cursor" and it feels like you're cussing with a
>> British accent). I start thunar again by typing thunar [enter] in the
>> same terminal. Ahaa! Something I didn't expect: Thunar appears to have
>> the same width and vertical placement as before (as far as I can tell
>> by eye) but horizontally it is up against the left screen edge.
>> Hypothesis: It's honoring the horizontal placement spec in rc.xml but
>> nothing else. So, I'll test that. I edit rc.xml changing all the x
>> positions from <x>2</x> to <x>100</x> and save it. BTW, all these
>> references to rc.xml are to a plain user's ~/.config/openbox/rc.xml. I
>> suppose root has one too, but I haven't messed with that yet. Now I
>> close thunar. Click the "Reconfigure" item on the menu. Now I raise
>> the lxterminal and it has given me 2 error messages at some point:
>> (thunar:2764): Gdk-CRITICAL **: IA__gdk_window_get_window_type:
>> assertion 'GDK_IS_WINDOW (window)' failed
>>
>> (thunar:2764): Gtk-WARNING **: Error loading theme icon
>> 'user-trash-full' for stock: Icon 'user-trash-full' not present in
>> theme
>>
>> and then a new prompt. I think those messages are probably neither
>> important nor relevant. I open thunar again the same way in the
>> terminal. Ahaa! As I hypothesised, it's a thumb width (about the
>> expected 100 pixels) to the right of the previous position. Now let's
>> see if it honors the y. I'll bet it does. I change all the <y>60</y>
>> to <y>10</y> and save it. Close thunar. Lxterminal has a new prompt.
>> Click "Reconfigure" on the menu. Type "thunar [enter] in lxterminal.
>> /me pauses to shout "Huzzah!" loud enough to disturb the chickens.
>> Thunar opened up near the top edge as rc.xml told it to.
>>
>> Revised hypothesis: Except for a small displacement to the right and
>> down, at least for aps last open with the left and bottom window
>> borders right on the screen edge, which may be a related issue or may
>> be entirely seperate, my aps ARE honoring the position statements in
>> rc.xml, but NOT the size ones. For size, it seems to be honoring the
>> "open at the same size you closed" principle.
>>
>> Well, at least I know openbox IS reading the file, so it's not some
>> kind of permission thing. Also I've shown the problem seems to be the
>> same in the 3 aps I tested: Firefox casually, thunar and mirage more
>> thoroughly. So if it's a bug in the aps they all have the same one or
>> ones. Which if you define a failure to comply with some published
>> standard as a "bug" is not at all unlikely.
>>
>> So is it possible that there is a setting somewhere or a bit of hard
>> code that is giving the "last size" principle precedence over the "do
>> what the rc.xml says" principle with regard to window size? Surely
>> that isn't what's intended. If that were the case the only time rc.xml
>> size statements would have any effect would be the first opening of a
>> newly installed ap.
>>
>> I will do some more tests. Probably with the same aps unless someone
>> requests something else. Maybe starting with windows in the middle of
>> the page with space all around them. Anyway, this is what I've found
>> so far. Gotta run calm those chickens now.
>>
>> Here is my present rc.xml. As before, you can find the beginning of
>> the applications section by seaching for ******.
>> http://pastebin.com/kmC41c27
>>
>>
>> On 1/13/14, [email protected] <[email protected]>
>> wrote:
>>> Send openbox mailing list submissions to
>>> 	[email protected]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> 	http://icculus.org/mailman/listinfo/openbox
>>> or, via email, send a message with subject or body 'help' to
>>> 	[email protected]
>>>
>>> You can reach the person managing the list at
>>> 	[email protected]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of openbox digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>    1. Re: aps not honoring rc.xml position statements, Vol 59,
>>>       Issue 4 (plmalternate plmalternate)
>>>    2. Re: aps not honoring rc.xml position statements, Vol 59,
>>>       Issue 4 (Jim Rees)
>>>    3. Re: most aps ignore rc.xml (Anthony Thyssen)
>>>    4. Re: most aps ignore rc.xml (Johan Vromans)
>>>    5. Re: most aps ignore rc.xml (Anthony Thyssen)
>>>    6. Re: most aps ignore rc.xml (Johan Vromans)
>>>    7. Re: most aps ignore rc.xml (Jim Rees)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 12 Jan 2014 16:13:45 -0500
>>> From: plmalternate plmalternate <[email protected]>
>>> To: [email protected]
>>> Subject: Re: [openbox] aps not honoring rc.xml position statements,
>>> 	Vol 59,	Issue 4
>>> Message-ID:
>>> 	<CAB2o_TF3TLbYBkty4A_5OVQmywLqKFy6L-6AxkSjkG6Ou0Du1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 1/12/14, [email protected] <[email protected]>
>>> wrote:
>>>> Send openbox mailing list submissions to
>>>> 	[email protected]
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> 	http://icculus.org/mailman/listinfo/openbox
>>>> or, via email, send a message with subject or body 'help' to
>>>> 	[email protected]
>>>>
>>>> You can reach the person managing the list at
>>>> 	[email protected]
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of openbox digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>>    1. most aps ignore rc.xml (plmalternate plmalternate)
>>>>    2. Re: most aps ignore rc.xml (Jim Rees)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Sun, 12 Jan 2014 03:36:10 -0500
>>>> From: plmalternate plmalternate <[email protected]>
>>>> To: [email protected]
>>>> Subject: [openbox] most aps ignore rc.xml
>>>> Message-ID:
>>>> 	<CAB2o_TGBA=ie9caq7ej_mhTZfJm33UieE=Wask6VT74tn3hwRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> Most of my aps ignore my ~/.config/openbox/rc.xml specifications for
>>>> window size and placement, despite "<position force="yes">". The only
>>>> ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>>> Thunar, firefox, gedit, k4dirstat, and galculator certainly don't.
>>>> I've gone so far as to write a script to launch thunar and then beat
>>>> it in to shape with wmctrl.  I've even thought about
>>>> recompiling some of the aps and trying to see if I can figure out how
>>>> to write the opening size and position in directly. I've never done
>>>> that and I'm not sure how much work it would be.
>>>>
>>>> I'm running Ubuntu Saucy 13.10, 32 bit, made from an installation cd
>>>> made from the mini.iso, which gives you a console with bash, apt-get,
>>>> and not much more. I added x, lightdm and it's gtk greeter, openbox,
>>>> thunar, lxterminal, conky (for a clock), firefox, and this and that.
>>>> So, it's a plain openbox environment, no desktop, no panels.  After
>>>> logging in, all I see is conky showing the time. I right click for a
>>>> menu and proceed from there.
>>>>
>>>> So, am I doing something wrong in the rc.xml, or maybe somewhere else?
>>>> Or have I just run into the border of the present state of the art
>>>> beyond which things don't yet work quite the way we'd like? Any
>>>> suggestions?
>>>>
>>>> my rc.xml is here:
>>>> http://pastebin.com/0cWbsz2P
>>>>
>>>> The applications section starts
>>>> shortly after a row of commented out asterisks. So searching for
>>>> "*****" should take you right to that part.
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Sun, 12 Jan 2014 11:31:48 -0500
>>>> From: Jim Rees <[email protected]>
>>>> To: openbox mailing list <[email protected]>
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <[email protected]>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> plmalternate plmalternate wrote:
>>>>
>>>>   Most of my aps ignore my ~/.config/openbox/rc.xml specifications for
>>>>   window size and placement, despite "<position force="yes">". The only
>>>>   ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>>>
>>>> This works for me. Two things look odd to me. One is your wildcard.
>>>> Maybe
>>>> openbox stops searching for app stanzas when it finds the first match?
>>>> The
>>>> other is that you are only giving the app name, which I think should
>>>> work,
>>>> but I always give the class too.
>>>>
>>>> Here's what I've got for firefox:
>>>>
>>>>     <application name="Navigator" class="Firefox">
>>>>       <position force="yes">
>>>> 	<x>8</x>
>>>> 	<y>6</y>
>>>>       </position>
>>>>     </application>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> openbox mailing list
>>>> [email protected]
>>>> http://icculus.org/mailman/listinfo/openbox
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of openbox Digest, Vol 59, Issue 4
>>>> **************************************
>>>>
>>> Thank you, sir. You taught me one thing right off the bat. From now on
>>> I'll always use xprop and never make reasonable assumptions about
>>> application's properties. Who'd have thought firefox was "named"
>>> "Navigarot". Now that I know it, I can of course see why. Anyway, I
>>> revised my rc.xml and copied the new version here:
>>> http://pastebin.com/AAWUhPBE
>>> I put your stanza at the top, added width and height, changed the
>>> width and height in the wildcard stanzas because Firefox sets a
>>> minimum I hadn't suspected until I used xprop to confirm the name
>>> "Navigator". I set these notably low, but above Firefox's minimum,  so
>>> that if I get Firefox to honor either of these stanzas, the change in
>>> size will be dramatic enough there will be no mistaking it. Once I get
>>> it working AT ALL I'll change things around so I can determine whether
>>> Firefox honors the first, the last, or the most specific stanza. ATM
>>> it's not honoring any of them.
>>>
>>> In the process of trying to figure this out I think I've discovered a
>>> bug, which I intend to report tonight or tomorrow unless someone tells
>>> me not to. It might be relevant.  The position Firefox DOES open at is
>>> ALMOST the same position I closed it at previously, but shifted down
>>> about 5 - 10 pixels, approximately the width of my fat window borders.
>>> This doesn't happen if I close Firefox in a window adjusted smaller
>>> that I usually use with the lower boundary well away from the screen
>>> edge but, so far as I can tell, only when I close it positioned as I
>>> normally do with the bottom border visible but just barely, sitting
>>> right on the bottom of the screen. I don't mean to drag in another
>>> topic, but I thought it might be related.
>>>
>>> I'm new to software mailing lists so if I'm violating any standard
>>> customs, please let me know. Should I go ahead and report both of
>>> these things as bugs, citing each report in the other in case they are
>>> linked, or should it stay in the mailing list a bit longer first?
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sun, 12 Jan 2014 20:52:06 -0500
>>> From: Jim Rees <[email protected]>
>>> To: openbox mailing list <[email protected]>
>>> Subject: Re: [openbox] aps not honoring rc.xml position statements,
>>> 	Vol 59, Issue 4
>>> Message-ID: <[email protected]>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> There used to be a bug in openbox having to do with window position near
>>> the
>>> bottom of the screen. It's been a while so I don't remember the
>>> details. It's fixed in the repo but if you have an older build maybe
>>> that's
>>> it? Someone else on this list might remember the details better than I.
>>>
>>> Firefox is notoriously bad about adhering to standards with regard to
>>> window
>>> position and size. It ignores all the standard X command line options
>>> and
>>> resources, among other problems. I remember filing a bug on bugzilla
>>> about
>>> 15 years ago about this, and I don't think it was ever fixed. MS Windows
>>> compatibility is a far higher priority for them than linux.
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Mon, 13 Jan 2014 11:56:14 +1000
>>> From: Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>> To: [email protected]
>>> Subject: Re: [openbox] most aps ignore rc.xml
>>> Message-ID: <20140113115614.7a4b32f7-7E98XzJiMbl61XtStRQj1ucKiHSPVgs9unOrhLTifxA@public.gmane.org>
>>> Content-Type: text/plain; charset=US-ASCII
>>>
>>> On Sun, 12 Jan 2014 11:31:48 -0500
>>> Jim Rees <[email protected]> wrote:
>>> | plmalternate plmalternate wrote:
>>> |
>>> |   Most of my aps ignore my ~/.config/openbox/rc.xml specifications for
>>> |   window size and placement, despite "<position force="yes">". The
>>> only
>>> |   ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>> |
>>> | This works for me. Two things look odd to me. One is your wildcard.
>>> Maybe
>>> | openbox stops searching for app stanzas when it finds the first match?
>>> The
>>> | other is that you are only giving the app name, which I think should
>>> work,
>>> | but I always give the class too.
>>> |
>>> | Here's what I've got for firefox:
>>> |
>>> |     <application name="Navigator" class="Firefox">
>>> |       <position force="yes">
>>> | 	<x>8</x>
>>> | 	<y>6</y>
>>> |       </position>
>>> |     </application>
>>> | _______________________________________________
>>> | openbox mailing list
>>> | [email protected]
>>> | http://icculus.org/mailman/listinfo/openbox
>>>
>>>
>>> You do need to ensure the application starts AFTER the window manager!!!
>>> :-)
>>>
>>> I usually don't rely on it. As while I like to position my windows on
>>> login (I use a personal session script to do that), I generally don't
>>> want specific positions for later windows of the appliactions.
>>>
>>> The exception to this is a few special ones I want located on a specific
>>> workspace. For example my music player, which I have special keyboard
>>> keys to to control regardless of what workspace it is in.
>>>
>>> The pet hate is most modern applications no long provide the standard
>>> X window geometry command line options to position initial windows.
>>>
>>> For example here is my scripted launcher for FireFox...
>>>
>>>   ( firefox & ) &
>>>   if id=`xwin_find 60 "Anthony .* Mozilla Firefox"`; then
>>>     echo "Main firefox window found (id=$id)"
>>>     # size, position, and iconify
>>>     xwit -resize 1024 960 -move 330 70 -iconify -id $id
>>>   else
>>>     echo "ERROR: Firefox Default window NOT FOUND!"
>>>   fi
>>>
>>> The script "xwin_find" I wrote and is based on the standard x-window
>>> utility "xwininfo".  You can get it from
>>>   http://www.ict.griffith.edu.au/anthony/software/#xwin_find
>>>
>>> "xwit" is a fairly common Window Helper application
>>> (also look at "xdotool" and "wmctrl" for alternatives.
>>> each has its own pluses/minuses/quirks.
>>> See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>>
>>>
>>>
>>>   Anthony Thyssen ( System Programmer )    <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>
>>> --------------------------------------------------------------------------
>>>   Real Programmers never grow old.
>>>        They suffer from burnouts, monumental crashes, or bugs in thier
>>> DNA.
>>>
>>> --------------------------------------------------------------------------
>>>    Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Mon, 13 Jan 2014 08:20:21 +0100
>>> From: Johan Vromans <[email protected]>
>>> To: [email protected]
>>> Subject: Re: [openbox] most aps ignore rc.xml
>>> Message-ID: <m24n58tkju.fsf-KjnUIgV0B0bak1Ioo/c9IoRWq/[email protected]>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>
>>>> "xwit" is a fairly common Window Helper application
>>>> (also look at "xdotool" and "wmctrl" for alternatives.
>>>> each has its own pluses/minuses/quirks.
>>>> See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>>
>>> Devilspie is a useful tool as well.
>>>
>>>   (if (and (matches (window_name) "Mozilla Firefox")
>>>            (is (application_name) "Firefox"))
>>>       (geometry "1200x1055+0+0"))
>>>
>>> -- Johan
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Mon, 13 Jan 2014 17:44:10 +1000
>>> From: Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>> To: [email protected]
>>> Subject: Re: [openbox] most aps ignore rc.xml
>>> Message-ID: <20140113174410.76478fa7-7E98XzJiMbl61XtStRQj1ucKiHSPVgs9unOrhLTifxA@public.gmane.org>
>>> Content-Type: text/plain; charset=US-ASCII
>>>
>>> On Mon, 13 Jan 2014 08:20:21 +0100
>>> Johan Vromans <[email protected]> wrote:
>>> | Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>> |
>>> | > "xwit" is a fairly common Window Helper application
>>> | > (also look at "xdotool" and "wmctrl" for alternatives.
>>> | > each has its own pluses/minuses/quirks.
>>> | > See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>> |
>>> | Devilspie is a useful tool as well.
>>> |
>>> |   (if (and (matches (window_name) "Mozilla Firefox")
>>> |            (is (application_name) "Firefox"))
>>> |       (geometry "1200x1055+0+0"))
>>> |
>>> | -- Johan
>>> | _______________________________________________
>>> | openbox mailing list
>>> | [email protected]
>>> | http://icculus.org/mailman/listinfo/openbox
>>>
>>> But again it handles every window that opens.  not just the initial
>>> window.
>>> that is why I don't use it!  Though I did look into it.
>>>
>>>
>>>
>>>   Anthony Thyssen ( System Programmer )    <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>
>>> --------------------------------------------------------------------------
>>>    Understanding the question is just as important as the result -
>>>    which we all know is 42 in any case.     Douglas Eadline, Ph.D.
>>>
>>> --------------------------------------------------------------------------
>>>    Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Mon, 13 Jan 2014 09:31:21 +0100
>>> From: Johan Vromans <[email protected]>
>>> To: [email protected]
>>> Subject: Re: [openbox] most aps ignore rc.xml
>>> Message-ID: <m2zjn0s2p2.fsf-KjnUIgV0B0bak1Ioo/c9IoRWq/[email protected]>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>
>>>> But again it handles every window that opens. not just the initial
>>>> window. that is why I don't use it! Though I did look into it.
>>>
>>> It does only handle main window(s) which I haven't experienced being a
>>> problem.
>>>
>>> For Mozilla I filed a bug (not taking command line -geometry into
>>> account) some 10 years ago, and they're still discussing it.
>>>
>>> -- Johan
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Mon, 13 Jan 2014 08:50:30 -0500
>>> From: Jim Rees <[email protected]>
>>> To: openbox mailing list <[email protected]>
>>> Subject: Re: [openbox] most aps ignore rc.xml
>>> Message-ID: <[email protected]>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Johan Vromans wrote:
>>>
>>>   Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>
>>>   > But again it handles every window that opens. not just the initial
>>>   > window. that is why I don't use it! Though I did look into it.
>>>
>>>   It does only handle main window(s) which I haven't experienced being a
>>>   problem.
>>>
>>>   For Mozilla I filed a bug (not taking command line -geometry into
>>>   account) some 10 years ago, and they're still discussing it.
>>>
>>> There used to be undocumented "-width" and "-height" command line
>>> options,
>>> although no way to set the position.
>>>
>>> Firefox also ignores the X "geometry" resource. That bug is over 20
>>> years
>>> old and dates to the first release of Mozilla. It's #444496 in Bugzilla.
>>>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> openbox mailing list
>>> [email protected]
>>> http://icculus.org/mailman/listinfo/openbox
>>>
>>>
>>> ------------------------------
>>>
>>> End of openbox Digest, Vol 59, Issue 5
>>> **************************************
>>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 15 Jan 2014 04:54:08 -0500
>> From: plmalternate plmalternate <[email protected]>
>> To: [email protected]
>> Subject: Re: [openbox] openbox Digest, Vol 59, Issue 5
>> Message-ID:
>> 	<CAB2o_TEyFYyr9rQhYDOMJp3DQEqYjuh78uAAzwE85NqncoBYNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> I can add this. I have put stanzas similar but different enough to
>> distinguish if they have effect in root's rc.xml.  But "gksu thunar"
>> gives me an instance that behaves the same way as plain thunar does.
>> It takes position from USER'S rc.xml but ignores the size specs and
>> opens at whatever size it closed at, If, however, I su and have a root
>> terminal and open and close thunar from there it still gets x and y
>> from USER'S rc.xml, but height and width do NOT come from the size at
>> the previous closing. Where they DO come from I haven't figured out.
>> Height is close to the user's spec, maybe 15 or so pixels greater, but
>> width is much less and right at the thunar minimum of 1204 as given by
>> xprop for a thunar window.
>> EXACTLY 1204.  As in:
>> from xprop:
>>    " thunar minimum size: 1204 by 338"
>> So, presumably something asked openbox to make is smaller than 1204
>> and this was the result. What that something would be I haven't a
>> clue. Not the closing size and not either rc.xml. Maybe somebody can
>> deduce something from this difference in the behaviour of thunar
>> opened from a root terminal and thunar opened with gksu. I know the
>> path is supposed to be a little different but I don't see how that
>> could cause this.
>>
>> I have another hypothesis. There is a demon living in my computer. His
>> name is Maxwell. He's doing this to drive me crazy. Now that fits all
>> the data I have.
>>
>> On 1/14/14, plmalternate plmalternate <[email protected]> wrote:
>>> Thank you, gentlesapients.  It's not a Firefox issue, or it is, Mirage
>>> and Thunar have the same issue. I've done further testing.
>>>
>>> I realised I need to methodicly test these issues when it became
>>> evident I must have been mistaken about Mirage. At any rate it now
>>> ignores rc.xml when I change the height spec and relog. It just opens
>>> whatever size it had when last open, or at least close to that size (I
>>> make that reservation for a reason explained below). xprop gives:
>>>
>>> program specified minimum size: 421 by 54
>>>
>>> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
>>>
>>> WM_CLASS(STRING) = "mirage", "Mirage"
>>> (does that mean it should recognise being addressed either way?)
>>>
>>> WM_ICON_NAME(STRING) = "Mirage - [1 of 1] 007.jpg"
>>>
>>> _NET_WM_ICON_NAME(UTF8_STRING) = "Mirage - [1 of 1] 007.jpg"
>>>
>>> WM_NAME(STRING) = "Mirage - [1 of 1] 007.jpg"
>>>
>>> _NET_WM_NAME(UTF8_STRING) = "Mirage - [1 of 1] 007.jpg"
>>>
>>> I've got redundant stanzas for title with and without an asterisk
>>> following "Mirage" and the same for name in addition to the wildcard
>>> stanzas supposed to apply to all windows not otherwise covered. I've
>>> got all the stanzas except conky's set to 500 x 500 so if ANY of them
>>> work I'm bound to notice the change. I just opened Mirage, wmctrled it
>>> to 0,1,1,1912,1025, which I call "full". Closed it. Opened it again.
>>> It opened at "full" again (ADDED LATER: Or maybe it was just close -
>>> at this point I wasn't suspecting a SMALL displacement). Now I am
>>> going to shutdown -h, let it cool, and boot up again, not just relog.
>>> Overkill, I know. Giveing it every possible chance.
>>>
>>> Probably irrelevant but for completeness I should mention my next boot
>>> failed to start x. I tried startx from the tty after logging in. It
>>> said startx was part of a package not installed and I tried to install
>>> it. Apt-get told me the filesystem was damaged and mounted read only.
>>> So I sudo fsck'ed it and rebooted normally.
>>>
>>> OK, I'm seeing both problems with Mirage.
>>> 1- It is NOT paying any attention to rc.xml.
>>> 2- It opens up very close, but not quite, at the position I closed it
>>> at. It is displaced slightly down and to the right of that position,
>>> by something on the close order of 5 pixels in both dimensions. With
>>> regard to vertical placement it could be that it has placed the top
>>> boundary of the border where the bottom boundary was, just barely
>>> below the edge of the screen. With respect to horizontal placement, it
>>> could be it is doing the opposite - putting the outer edge of the
>>> border where the inner edge was when I closed it. This is the same
>>> pattern I saw with Firefox, and earlier, with Thunar. Obviously this
>>> is not a huge problem. Probably many people would never notice it. But
>>> it is annoying. I like to see my window borders because often I have
>>> problems with windows that are larger than my screen and hiding
>>> important buttons in consequence. A case in point is "Qt
>>> Configuration, version 4.8.4". I'm pretty sure it's hiding an "apply",
>>> "ok", or "close" button I can't get to. If I can see the borders, at
>>> least I know that's not the problem and I'm not missing content. The
>>> source of the problem with that window though is undoutedly different
>>> from this "slight displacement from historical placement" problem. It
>>> won't let me resize it with either mouse or wmctrl. It's just a darned
>>> stubborn ap. Enough or Mirage. Now for:
>>>
>>> --------- Thunar ----------
>>> I have a thunar window up already. I opened it with a script (here:
>>> http://pastebin.com/XSCmtC36
>>>  )that first opens thunar and then wmctrls it thus:
>>> wmctrl -r "Desktop - File Manager" -e 0,0,60,1912,970
>>> The script was called from an openbox menu entry thus:
>>> <command>thun ~/Desktop</command>
>>> "thun" is the filename of the script and it's in my path. I doubt any
>>> of that's important. Thunar is a well behaved program like most (and
>>> unlike "Qt Configuration") and responds to the wmctrl command
>>> correctly. When I open it with that menu item, it first appears with
>>> no visible bottom border, and then when the wmctrl statement hits it,
>>> it jumps up and left a little, again on the close order of 5 pixels or
>>> so. So that's where it is now. I close it. Gone. Now I open it with
>>> "thunar" (bypassing the script) in lxterminal. Lxterminal didn't give
>>> any messages - the cursor just jumped to the next line where it now
>>> sits blinking. Thunar is slightly to the right and below its previous
>>> placement, following the same pattern as Mirage and Firefox. I wmctrl
>>> it from the menu thus:
>>> wmctrl -r :SELECT: -e 0,150,1,1000,1078
>>> and click on it. It changes size more or less as expected. The bottom
>>> is a little lower than I thought that would give me, again by about
>>> the width of my fat borders, but that is probably just that I didn't
>>> get the numbers quite right when I was editing the menu. I don't use
>>> that size very often. I close it by clicking the close button in the
>>> title bar. Lxterminal gives me a new prompt. No messages have
>>> appeared. So on my terminal are just 2 lines, one with a prompt
>>> followed by "thunar" and the second with just a prompt and the
>>> blinking cursor (the best thing about having the cursor blink is you
>>> can say "the blinking cursor" and it feels like you're cussing with a
>>> British accent). I start thunar again by typing thunar [enter] in the
>>> same terminal. Ahaa! Something I didn't expect: Thunar appears to have
>>> the same width and vertical placement as before (as far as I can tell
>>> by eye) but horizontally it is up against the left screen edge.
>>> Hypothesis: It's honoring the horizontal placement spec in rc.xml but
>>> nothing else. So, I'll test that. I edit rc.xml changing all the x
>>> positions from <x>2</x> to <x>100</x> and save it. BTW, all these
>>> references to rc.xml are to a plain user's ~/.config/openbox/rc.xml. I
>>> suppose root has one too, but I haven't messed with that yet. Now I
>>> close thunar. Click the "Reconfigure" item on the menu. Now I raise
>>> the lxterminal and it has given me 2 error messages at some point:
>>> (thunar:2764): Gdk-CRITICAL **: IA__gdk_window_get_window_type:
>>> assertion 'GDK_IS_WINDOW (window)' failed
>>>
>>> (thunar:2764): Gtk-WARNING **: Error loading theme icon
>>> 'user-trash-full' for stock: Icon 'user-trash-full' not present in
>>> theme
>>>
>>> and then a new prompt. I think those messages are probably neither
>>> important nor relevant. I open thunar again the same way in the
>>> terminal. Ahaa! As I hypothesised, it's a thumb width (about the
>>> expected 100 pixels) to the right of the previous position. Now let's
>>> see if it honors the y. I'll bet it does. I change all the <y>60</y>
>>> to <y>10</y> and save it. Close thunar. Lxterminal has a new prompt.
>>> Click "Reconfigure" on the menu. Type "thunar [enter] in lxterminal.
>>> /me pauses to shout "Huzzah!" loud enough to disturb the chickens.
>>> Thunar opened up near the top edge as rc.xml told it to.
>>>
>>> Revised hypothesis: Except for a small displacement to the right and
>>> down, at least for aps last open with the left and bottom window
>>> borders right on the screen edge, which may be a related issue or may
>>> be entirely seperate, my aps ARE honoring the position statements in
>>> rc.xml, but NOT the size ones. For size, it seems to be honoring the
>>> "open at the same size you closed" principle.
>>>
>>> Well, at least I know openbox IS reading the file, so it's not some
>>> kind of permission thing. Also I've shown the problem seems to be the
>>> same in the 3 aps I tested: Firefox casually, thunar and mirage more
>>> thoroughly. So if it's a bug in the aps they all have the same one or
>>> ones. Which if you define a failure to comply with some published
>>> standard as a "bug" is not at all unlikely.
>>>
>>> So is it possible that there is a setting somewhere or a bit of hard
>>> code that is giving the "last size" principle precedence over the "do
>>> what the rc.xml says" principle with regard to window size? Surely
>>> that isn't what's intended. If that were the case the only time rc.xml
>>> size statements would have any effect would be the first opening of a
>>> newly installed ap.
>>>
>>> I will do some more tests. Probably with the same aps unless someone
>>> requests something else. Maybe starting with windows in the middle of
>>> the page with space all around them. Anyway, this is what I've found
>>> so far. Gotta run calm those chickens now.
>>>
>>> Here is my present rc.xml. As before, you can find the beginning of
>>> the applications section by seaching for ******.
>>> http://pastebin.com/kmC41c27
>>>
>>>
>>> On 1/13/14, [email protected] <[email protected]>
>>> wrote:
>>>> Send openbox mailing list submissions to
>>>> 	[email protected]
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> 	http://icculus.org/mailman/listinfo/openbox
>>>> or, via email, send a message with subject or body 'help' to
>>>> 	[email protected]
>>>>
>>>> You can reach the person managing the list at
>>>> 	[email protected]
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of openbox digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>>    1. Re: aps not honoring rc.xml position statements, Vol 59,
>>>>       Issue 4 (plmalternate plmalternate)
>>>>    2. Re: aps not honoring rc.xml position statements, Vol 59,
>>>>       Issue 4 (Jim Rees)
>>>>    3. Re: most aps ignore rc.xml (Anthony Thyssen)
>>>>    4. Re: most aps ignore rc.xml (Johan Vromans)
>>>>    5. Re: most aps ignore rc.xml (Anthony Thyssen)
>>>>    6. Re: most aps ignore rc.xml (Johan Vromans)
>>>>    7. Re: most aps ignore rc.xml (Jim Rees)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Sun, 12 Jan 2014 16:13:45 -0500
>>>> From: plmalternate plmalternate <[email protected]>
>>>> To: [email protected]
>>>> Subject: Re: [openbox] aps not honoring rc.xml position statements,
>>>> 	Vol 59,	Issue 4
>>>> Message-ID:
>>>> 	<CAB2o_TF3TLbYBkty4A_5OVQmywLqKFy6L-6AxkSjkG6Ou0Du1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> On 1/12/14, [email protected] <[email protected]>
>>>> wrote:
>>>>> Send openbox mailing list submissions to
>>>>> 	[email protected]
>>>>>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>> 	http://icculus.org/mailman/listinfo/openbox
>>>>> or, via email, send a message with subject or body 'help' to
>>>>> 	[email protected]
>>>>>
>>>>> You can reach the person managing the list at
>>>>> 	[email protected]
>>>>>
>>>>> When replying, please edit your Subject line so it is more specific
>>>>> than "Re: Contents of openbox digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>>>>    1. most aps ignore rc.xml (plmalternate plmalternate)
>>>>>    2. Re: most aps ignore rc.xml (Jim Rees)
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Sun, 12 Jan 2014 03:36:10 -0500
>>>>> From: plmalternate plmalternate <[email protected]>
>>>>> To: [email protected]
>>>>> Subject: [openbox] most aps ignore rc.xml
>>>>> Message-ID:
>>>>> 	<CAB2o_TGBA=ie9caq7ej_mhTZfJm33UieE=Wask6VT74tn3hwRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>>
>>>>> Most of my aps ignore my ~/.config/openbox/rc.xml specifications for
>>>>> window size and placement, despite "<position force="yes">". The only
>>>>> ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>>>> Thunar, firefox, gedit, k4dirstat, and galculator certainly don't.
>>>>> I've gone so far as to write a script to launch thunar and then beat
>>>>> it in to shape with wmctrl.  I've even thought about
>>>>> recompiling some of the aps and trying to see if I can figure out how
>>>>> to write the opening size and position in directly. I've never done
>>>>> that and I'm not sure how much work it would be.
>>>>>
>>>>> I'm running Ubuntu Saucy 13.10, 32 bit, made from an installation cd
>>>>> made from the mini.iso, which gives you a console with bash, apt-get,
>>>>> and not much more. I added x, lightdm and it's gtk greeter, openbox,
>>>>> thunar, lxterminal, conky (for a clock), firefox, and this and that.
>>>>> So, it's a plain openbox environment, no desktop, no panels.  After
>>>>> logging in, all I see is conky showing the time. I right click for a
>>>>> menu and proceed from there.
>>>>>
>>>>> So, am I doing something wrong in the rc.xml, or maybe somewhere else?
>>>>> Or have I just run into the border of the present state of the art
>>>>> beyond which things don't yet work quite the way we'd like? Any
>>>>> suggestions?
>>>>>
>>>>> my rc.xml is here:
>>>>> http://pastebin.com/0cWbsz2P
>>>>>
>>>>> The applications section starts
>>>>> shortly after a row of commented out asterisks. So searching for
>>>>> "*****" should take you right to that part.
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 2
>>>>> Date: Sun, 12 Jan 2014 11:31:48 -0500
>>>>> From: Jim Rees <[email protected]>
>>>>> To: openbox mailing list <[email protected]>
>>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>>> Message-ID: <[email protected]>
>>>>> Content-Type: text/plain; charset=us-ascii
>>>>>
>>>>> plmalternate plmalternate wrote:
>>>>>
>>>>>   Most of my aps ignore my ~/.config/openbox/rc.xml specifications for
>>>>>   window size and placement, despite "<position force="yes">". The
>>>>> only
>>>>>   ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>>>>
>>>>> This works for me. Two things look odd to me. One is your wildcard.
>>>>> Maybe
>>>>> openbox stops searching for app stanzas when it finds the first match?
>>>>> The
>>>>> other is that you are only giving the app name, which I think should
>>>>> work,
>>>>> but I always give the class too.
>>>>>
>>>>> Here's what I've got for firefox:
>>>>>
>>>>>     <application name="Navigator" class="Firefox">
>>>>>       <position force="yes">
>>>>> 	<x>8</x>
>>>>> 	<y>6</y>
>>>>>       </position>
>>>>>     </application>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Subject: Digest Footer
>>>>>
>>>>> _______________________________________________
>>>>> openbox mailing list
>>>>> [email protected]
>>>>> http://icculus.org/mailman/listinfo/openbox
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> End of openbox Digest, Vol 59, Issue 4
>>>>> **************************************
>>>>>
>>>> Thank you, sir. You taught me one thing right off the bat. From now on
>>>> I'll always use xprop and never make reasonable assumptions about
>>>> application's properties. Who'd have thought firefox was "named"
>>>> "Navigarot". Now that I know it, I can of course see why. Anyway, I
>>>> revised my rc.xml and copied the new version here:
>>>> http://pastebin.com/AAWUhPBE
>>>> I put your stanza at the top, added width and height, changed the
>>>> width and height in the wildcard stanzas because Firefox sets a
>>>> minimum I hadn't suspected until I used xprop to confirm the name
>>>> "Navigator". I set these notably low, but above Firefox's minimum,  so
>>>> that if I get Firefox to honor either of these stanzas, the change in
>>>> size will be dramatic enough there will be no mistaking it. Once I get
>>>> it working AT ALL I'll change things around so I can determine whether
>>>> Firefox honors the first, the last, or the most specific stanza. ATM
>>>> it's not honoring any of them.
>>>>
>>>> In the process of trying to figure this out I think I've discovered a
>>>> bug, which I intend to report tonight or tomorrow unless someone tells
>>>> me not to. It might be relevant.  The position Firefox DOES open at is
>>>> ALMOST the same position I closed it at previously, but shifted down
>>>> about 5 - 10 pixels, approximately the width of my fat window borders.
>>>> This doesn't happen if I close Firefox in a window adjusted smaller
>>>> that I usually use with the lower boundary well away from the screen
>>>> edge but, so far as I can tell, only when I close it positioned as I
>>>> normally do with the bottom border visible but just barely, sitting
>>>> right on the bottom of the screen. I don't mean to drag in another
>>>> topic, but I thought it might be related.
>>>>
>>>> I'm new to software mailing lists so if I'm violating any standard
>>>> customs, please let me know. Should I go ahead and report both of
>>>> these things as bugs, citing each report in the other in case they are
>>>> linked, or should it stay in the mailing list a bit longer first?
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Sun, 12 Jan 2014 20:52:06 -0500
>>>> From: Jim Rees <[email protected]>
>>>> To: openbox mailing list <[email protected]>
>>>> Subject: Re: [openbox] aps not honoring rc.xml position statements,
>>>> 	Vol 59, Issue 4
>>>> Message-ID: <[email protected]>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> There used to be a bug in openbox having to do with window position
>>>> near
>>>> the
>>>> bottom of the screen. It's been a while so I don't remember the
>>>> details. It's fixed in the repo but if you have an older build maybe
>>>> that's
>>>> it? Someone else on this list might remember the details better than I.
>>>>
>>>> Firefox is notoriously bad about adhering to standards with regard to
>>>> window
>>>> position and size. It ignores all the standard X command line options
>>>> and
>>>> resources, among other problems. I remember filing a bug on bugzilla
>>>> about
>>>> 15 years ago about this, and I don't think it was ever fixed. MS
>>>> Windows
>>>> compatibility is a far higher priority for them than linux.
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 3
>>>> Date: Mon, 13 Jan 2014 11:56:14 +1000
>>>> From: Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>> To: [email protected]
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <20140113115614.7a4b32f7-7E98XzJiMbl61XtStRQj1ucKiHSPVgs9unOrhLTifxA@public.gmane.org>
>>>> Content-Type: text/plain; charset=US-ASCII
>>>>
>>>> On Sun, 12 Jan 2014 11:31:48 -0500
>>>> Jim Rees <[email protected]> wrote:
>>>> | plmalternate plmalternate wrote:
>>>> |
>>>> |   Most of my aps ignore my ~/.config/openbox/rc.xml specifications
>>>> for
>>>> |   window size and placement, despite "<position force="yes">". The
>>>> only
>>>> |   ap I'm pretty sure is honoring them is Mirage, a picture viewer.
>>>> |
>>>> | This works for me. Two things look odd to me. One is your wildcard.
>>>> Maybe
>>>> | openbox stops searching for app stanzas when it finds the first
>>>> match?
>>>> The
>>>> | other is that you are only giving the app name, which I think should
>>>> work,
>>>> | but I always give the class too.
>>>> |
>>>> | Here's what I've got for firefox:
>>>> |
>>>> |     <application name="Navigator" class="Firefox">
>>>> |       <position force="yes">
>>>> | 	<x>8</x>
>>>> | 	<y>6</y>
>>>> |       </position>
>>>> |     </application>
>>>> | _______________________________________________
>>>> | openbox mailing list
>>>> | [email protected]
>>>> | http://icculus.org/mailman/listinfo/openbox
>>>>
>>>>
>>>> You do need to ensure the application starts AFTER the window
>>>> manager!!!
>>>> :-)
>>>>
>>>> I usually don't rely on it. As while I like to position my windows on
>>>> login (I use a personal session script to do that), I generally don't
>>>> want specific positions for later windows of the appliactions.
>>>>
>>>> The exception to this is a few special ones I want located on a
>>>> specific
>>>> workspace. For example my music player, which I have special keyboard
>>>> keys to to control regardless of what workspace it is in.
>>>>
>>>> The pet hate is most modern applications no long provide the standard
>>>> X window geometry command line options to position initial windows.
>>>>
>>>> For example here is my scripted launcher for FireFox...
>>>>
>>>>   ( firefox & ) &
>>>>   if id=`xwin_find 60 "Anthony .* Mozilla Firefox"`; then
>>>>     echo "Main firefox window found (id=$id)"
>>>>     # size, position, and iconify
>>>>     xwit -resize 1024 960 -move 330 70 -iconify -id $id
>>>>   else
>>>>     echo "ERROR: Firefox Default window NOT FOUND!"
>>>>   fi
>>>>
>>>> The script "xwin_find" I wrote and is based on the standard x-window
>>>> utility "xwininfo".  You can get it from
>>>>   http://www.ict.griffith.edu.au/anthony/software/#xwin_find
>>>>
>>>> "xwit" is a fairly common Window Helper application
>>>> (also look at "xdotool" and "wmctrl" for alternatives.
>>>> each has its own pluses/minuses/quirks.
>>>> See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>>>
>>>>
>>>>
>>>>   Anthony Thyssen ( System Programmer )    <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>>
>>>> --------------------------------------------------------------------------
>>>>   Real Programmers never grow old.
>>>>        They suffer from burnouts, monumental crashes, or bugs in thier
>>>> DNA.
>>>>
>>>> --------------------------------------------------------------------------
>>>>    Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 4
>>>> Date: Mon, 13 Jan 2014 08:20:21 +0100
>>>> From: Johan Vromans <[email protected]>
>>>> To: [email protected]
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <m24n58tkju.fsf-KjnUIgV0B0bak1Ioo/c9IoRWq/[email protected]>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>>
>>>>> "xwit" is a fairly common Window Helper application
>>>>> (also look at "xdotool" and "wmctrl" for alternatives.
>>>>> each has its own pluses/minuses/quirks.
>>>>> See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>>>
>>>> Devilspie is a useful tool as well.
>>>>
>>>>   (if (and (matches (window_name) "Mozilla Firefox")
>>>>            (is (application_name) "Firefox"))
>>>>       (geometry "1200x1055+0+0"))
>>>>
>>>> -- Johan
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 5
>>>> Date: Mon, 13 Jan 2014 17:44:10 +1000
>>>> From: Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>> To: [email protected]
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <20140113174410.76478fa7-7E98XzJiMbl61XtStRQj1ucKiHSPVgs9unOrhLTifxA@public.gmane.org>
>>>> Content-Type: text/plain; charset=US-ASCII
>>>>
>>>> On Mon, 13 Jan 2014 08:20:21 +0100
>>>> Johan Vromans <[email protected]> wrote:
>>>> | Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>> |
>>>> | > "xwit" is a fairly common Window Helper application
>>>> | > (also look at "xdotool" and "wmctrl" for alternatives.
>>>> | > each has its own pluses/minuses/quirks.
>>>> | > See http://www.ict.griffith.edu.au/anthony/info/X/progs.summary
>>>> |
>>>> | Devilspie is a useful tool as well.
>>>> |
>>>> |   (if (and (matches (window_name) "Mozilla Firefox")
>>>> |            (is (application_name) "Firefox"))
>>>> |       (geometry "1200x1055+0+0"))
>>>> |
>>>> | -- Johan
>>>> | _______________________________________________
>>>> | openbox mailing list
>>>> | [email protected]
>>>> | http://icculus.org/mailman/listinfo/openbox
>>>>
>>>> But again it handles every window that opens.  not just the initial
>>>> window.
>>>> that is why I don't use it!  Though I did look into it.
>>>>
>>>>
>>>>
>>>>   Anthony Thyssen ( System Programmer )    <A.Thyssen-YlX7AVbyhojX/[email protected]>
>>>>
>>>> --------------------------------------------------------------------------
>>>>    Understanding the question is just as important as the result -
>>>>    which we all know is 42 in any case.     Douglas Eadline, Ph.D.
>>>>
>>>> --------------------------------------------------------------------------
>>>>    Anthony's Castle     http://www.ict.griffith.edu.au/anthony/
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 6
>>>> Date: Mon, 13 Jan 2014 09:31:21 +0100
>>>> From: Johan Vromans <[email protected]>
>>>> To: [email protected]
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <m2zjn0s2p2.fsf-KjnUIgV0B0bak1Ioo/c9IoRWq/[email protected]>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>>
>>>>> But again it handles every window that opens. not just the initial
>>>>> window. that is why I don't use it! Though I did look into it.
>>>>
>>>> It does only handle main window(s) which I haven't experienced being a
>>>> problem.
>>>>
>>>> For Mozilla I filed a bug (not taking command line -geometry into
>>>> account) some 10 years ago, and they're still discussing it.
>>>>
>>>> -- Johan
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 7
>>>> Date: Mon, 13 Jan 2014 08:50:30 -0500
>>>> From: Jim Rees <[email protected]>
>>>> To: openbox mailing list <[email protected]>
>>>> Subject: Re: [openbox] most aps ignore rc.xml
>>>> Message-ID: <[email protected]>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> Johan Vromans wrote:
>>>>
>>>>   Anthony Thyssen <A.Thyssen-YlX7AVbyhojX/[email protected]> writes:
>>>>
>>>>   > But again it handles every window that opens. not just the initial
>>>>   > window. that is why I don't use it! Though I did look into it.
>>>>
>>>>   It does only handle main window(s) which I haven't experienced being
>>>> a
>>>>   problem.
>>>>
>>>>   For Mozilla I filed a bug (not taking command line -geometry into
>>>>   account) some 10 years ago, and they're still discussing it.
>>>>
>>>> There used to be undocumented "-width" and "-height" command line
>>>> options,
>>>> although no way to set the position.
>>>>
>>>> Firefox also ignores the X "geometry" resource. That bug is over 20
>>>> years
>>>> old and dates to the first release of Mozilla. It's #444496 in
>>>> Bugzilla.
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> openbox mailing list
>>>> [email protected]
>>>> http://icculus.org/mailman/listinfo/openbox
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of openbox Digest, Vol 59, Issue 5
>>>> **************************************
>>>>
>>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> openbox mailing list
>> [email protected]
>> http://icculus.org/mailman/listinfo/openbox
>>
>>
>> ------------------------------
>>
>> End of openbox Digest, Vol 59, Issue 7
>> **************************************
>>
>
_______________________________________________
openbox mailing list
[email protected]
http://icculus.org/mailman/listinfo/openbox