WindowBoundingRect in Linux

[Richard Gaskin]

Richmond wrote:

> I am not quite sure how to answer this:
>
> 1. I am running Ubuntu 10.10 "Moronic Meerkat" that has had its GUI
> hacked about a bit
> insofar as I have an AVANT WINDOW NAVIGATOR set up rather like the Mac
> OS X dock
> along the bottom of my desktop, and a DOCKY on the right-handside of my
> screen (for Windows
> stuff running under WINE).
>
> I am writing this using Mozilla Thunderbird -
>
> If I maximise my Thunderbird window it takes DOCKY into account and does not
> maximise so bits of the window are "behind" it. However, Thunderbird
> does NOT take
> AVANT into account and does maximise "behind" it.
>
> 2. If I maximise a LiveCode stack it behaves exactly like Thunderbird,
>
>      It doesn't go completely bonkers and do such things as vanishing
> under the PANEL.
>
> 3. This is the situation for 4.5 dp-4, Studio 4.0 and RunRev 2.2.1;
> which means that it is
>      a long-running situation.
>
> This would suggest to me, that, on my machine at least, that the problem
> lies with Avant Window Navigator

Thank you for looking into this, but I'm referring to a different behavior.

The windowBoundingRect is entirely internal to Rev, governing the 
maximum size a Rev window will be sized to when the user clicks the 
window's maximize control.

True, it can be difficult to be able to know the full extent of various 
window trimmings in Linux (Cairo Dock seems to do a good job of having 
the OS constraint the max size, as do the built-in panels, but there are 
so many docks available that I imagine some work better than others).

But in my case all I need to do is to be able to constrain our document 
windows within the bounds established by our app's toolbar -- all Rev stuff.

On OS X and Win, setting the windowBoundingRect will indeed constrain 
maximizing as expected, but I haven't been able to get this to work in 
Linux.  Unfortunately, this rather hoses an 
otherwise-almost-ready-to-ship-for-Linux app we have in the works which 
has a toolbar that needs to be accounted for.

I've logged the bug here:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=9058>

If anyone here knows of a way to get this to work I'd be most grateful.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv