Window or frog

[szuk...@arcor.de‏]

I have written a viewer using fltk-1.1, fltk-1.3, fltk-2.0
and fltk-3.0 . You can find the viewer here:

 http://home.arcor.de/szukw000

The following problem arises on LINUX only.

From Widget.cxx of fltk-2.0:

/*! Change the size or position of the widget. Nothing is done if the
  passed size and position are the same as before. If there is a
  change then relayout() is called so that the virtual function
  layout() is called before the next draw().  */

bool Widget::resize(int x,int y,int w,int h) {
  uchar flags = 0;
  if (x != this->x()) flags = LAYOUT_X;
  if (y != this->y()) flags |= LAYOUT_Y;
  if (w != this->w()) flags |= LAYOUT_W;
  if (h != this->h()) flags |= LAYOUT_H;
  if (flags) {
    Rectangle::set(x,y,w,h);
    // parent must get LAYOUT_DAMAGE as well as LAYOUT_CHILD:
    if (parent()) {
      layout_damage_ |= flags;
      parent()->relayout(LAYOUT_DAMAGE|LAYOUT_CHILD);
    } else {
      relayout(flags);
    }
    return true;
  } else {
    return false;
  }
}

fltk-1.1, fltk-1.3 and fltk-3.0 do not have such a widget. In
fltk-2.0 I can write:

 win->resize(w,h);

and the window stands still at its origin; only the height resp.
the width change when the image width/height of the still image
changes. Excellent.

In fltk-1.1, fltk-1.3 and fltk-3.0 I can write:

 win->resize(x,y,w,h);

This does not fix the window at the (x,y) position and the window
hops around like a frog when the width/height of the still image
changes.

When the viewer shows a movie AND I drag the window: then the
viewer slides back to the origin it had, before the movie started.

When I write:

 win->size(w,h);

then I can drag the window and it does not slide back.

But movies do not change the geometry of the image. When the viewer
shows a another still image with another geometry: the window again
hops around.

This problem does not arise on Win7 although I use fltk-1.3 on
Win7: the window stands fixed at its (x,y) origin, only the width
or the height changes. Excellent.

The problem is with LINUX.

So what can I do turn this frog into an window?

winfried

[Ian MacArthur‏]

Hi Winfried,

On Tue May 06 2014 11:17:43, szuk...@arcor.de wrote:

> fltk-1.1, fltk-1.3 and fltk-3.0 do not have such a widget. In
> fltk-2.0 I can write:
>
> win->resize(w,h);
>
> and the window stands still at its origin; only the height resp.
> the width change when the image width/height of the still image
> changes. Excellent.
>
> In fltk-1.1, fltk-1.3 and fltk-3.0 I can write:
>
> win->resize(x,y,w,h);

Would it not just be simpler to use the size(w,h) method?

win->size(w,h);

That would be the usual way under fltk-1.x.

> This does not fix the window at the (x,y) position and the window
> hops around like a frog when the width/height of the still image
> changes.

That’s odd.
Seems to work OK for me (testing on F17 and ubuntu-13.10) - what does the resize demo form the test folder do? Does it work?

> When the viewer shows a movie AND I drag the window: then the
> viewer slides back to the origin it had, before the movie started.
>
> When I write:
>
> win->size(w,h);
>
> then I can drag the window and it does not slide back.
>
> But movies do not change the geometry of the image. When the viewer
> shows a another still image with another geometry: the window again
> hops around.
>
> This problem does not arise on Win7 although I use fltk-1.3 on
> Win7: the window stands fixed at its (x,y) origin, only the width
> or the height changes. Excellent.
>
> The problem is with LINUX.
>
> So what can I do turn this frog into an window?

Are there nested windows or some thing like that?
I guess even if there are multiple widgets in the container, it might be worth taking a look at init_sizes() after forcing a re-size, in case the widgets are “remembering” their initial states...

[szuk...@arcor.de‏]

The behaviour is shown when I use FVWM.

I have tried xfce4, fluxbox and others. They all show the FLTK main window fixed.

From the FVWM list I have learned that this can not be changed in the fvwm2rc
config file. Look here:
----------------------------------------------------------------------
  case GravityNotify:
  int mask = CWBorderPixel|CWColormap|CWEventMask|CWBitGravity;
  attr.bit_gravity = 0; // StaticGravity; 1:NorthWestGravity
  hints->win_gravity = StaticGravity; // NorthWestGravity
    hints->flags = PMinSize|PWinGravity;
      hints->flags = PMinSize|PMaxSize|PWinGravity;
    hints->flags = PMinSize|PMaxSize|PWinGravity;
fltk-1.3.x-r10217/src/Fl_x.cxx
----------------------------------------------------------------------
The values I need are 1 for bit_gravity and NorthWestGravity for win_gravity.
With NorthWestGravity the FLTK main window stays fixed.

I just now do not understand why xfce4, fluxbox and others can change the
gravity value of the FLTK main window.

winfried

[MacArthur, Ian (Selex ES, UK)‏]

 

The behaviour is shown when I use FVWM.

I have tried xfce4, fluxbox and others. They all show the FLTK main window fixed.

From the FVWM list I have learned that this can not be changed in the fvwm2rc
config file. Look here:
----------------------------------------------------------------------
  case GravityNotify:
  int mask = CWBorderPixel|CWColormap|CWEventMask|CWBitGravity;
  attr.bit_gravity = 0; // StaticGravity; 1:NorthWestGravity
  hints->win_gravity = StaticGravity; // NorthWestGravity
    hints->flags = PMinSize|PWinGravity;
      hints->flags = PMinSize|PMaxSize|PWinGravity;
    hints->flags = PMinSize|PMaxSize|PWinGravity;
fltk-1.3.x-r10217/src/Fl_x.cxx
----------------------------------------------------------------------
The values I need are 1 for bit_gravity and NorthWestGravity for win_gravity.
With NorthWestGravity the FLTK main window stays fixed.

I just now do not understand why xfce4, fluxbox and others can change the
gravity value of the FLTK main window.

winfried

[imm]

Hi winfied,

 

I confess I am not sure what it is you are asking, really: It looks very much as if the behaviour is a “feature” of fvmw2 – possibly even a bug – since it does not manifest in any other WM that we are aware of.

 

That being the case, I’m not sure what we can do about that in fltk. I’m reluctant for us to change something in fltk to make it work with fvmw2, at the risk of breaking it for everybody else. I don’t imagine here are that many folks still using fvwm2 to be honest (I know I stopped using it many years ago!)

 

Is there some specific feature that you believe that fltk is getting wrong?

 

 

 

 

 

 

 

Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[szuk...@arcor.de‏]

>I confess I am not sure what it is you are asking, really:
>It looks very much as if the behaviour is a "feature" of

>fvmw2 - possibly even a bug - since it does not manifest

>in any other WM that we are aware of.

I did not want to ask, I wanted to give an intermediate
report.

Last answer from Dominik Vogt of fv...@fvwm.org:

   The gravity is set by the application, not by the window manager.
   So, if fltk does not use NorthWestGravity, then change fltk or use
   something else.

   If fltk-1.3 relies on poorly defined behaviour, then that's fltk's
   problem, not fvwm's.  The only way to fix that is to change fltk.

Interesting, isn't it? FLTK says, FVWM is faulty. FVWM says: FLTK
is faulty.

winfried

[Ian MacArthur‏]

On Thu Jul 10 2014 20:33:24, szuk...@arcor.de wrote:

> I did not want to ask, I wanted to give an intermediate
> report.

Ah OK, I misunderstood... I thought you were asking for some suggestions or something but I could not figure out what...!

> Last answer from Dominik Vogt of fv...@fvwm.org:
>
> The gravity is set by the application, not by the window manager.
> So, if fltk does not use NorthWestGravity, then change fltk or use
> something else.
>
> If fltk-1.3 relies on poorly defined behaviour, then that's fltk's
> problem, not fvwm's. The only way to fix that is to change fltk.
>
> Interesting, isn't it? FLTK says, FVWM is faulty. FVWM says: FLTK
> is faulty.

Indeed. I confess I do not understand all the wrinkles of X11 window hinting and WM behaviour, but I find it odd that we only have this problem with fvwm. It’s not the first WM related problem that’s been flagged with fvwm either, so even if their interpretation of the specs is strictly correct and ours is wrong (which is quite likely the case) they do seem to be out of step with the majority.

I wonder...


If I understand your problem correctly, the issue you have is that (only while running on fvwm) if you display a window then subsequently ask it to resize or reposition itself, it gets into a state where it toggles backwards and forwards between the new size/position and the original size/position.

On other WM however, the new size/position work as expected.

Is that a reasonable summary of your problem, or is there more too it than that?

Cheers,
--
Ian

[Greg Ercolano‏]

On 07/10/14 12:33, szuk...@arcor.de wrote:
> Interesting, isn't it? FLTK says, FVWM is faulty. FVWM says: FLTK
> is faulty.

It's probably a bit of both.

I doubt FLTK has been keeping up with the latest ICCCM features
which includes specific gravity hints.

It could also be something we're doing wrong, but it's odd that
only manifests on the one window manager and not others.
These are "hints", and window managers implementing newish
features should probably investigate supporting older code
as much as we should investigate supporting new WM features,
but I can see where there might be suspicion we're doing something
"wrong".

A good way might be to reduce our code to a straight X windows
"hello world" program, and then try to correct the issue from
looking at that.

Trouble is, I don't think we have active devs familiar with
the window manager internals these days. I think Bill and maybe
Matt were pretty aware of this stuff. I've jumped in as an outsider
from time to time to investigate, but I have limited interest in
window manager stuff.

Folks wanting to fix such issues may have to take some initiative
to dig into the FLTK code to suggest what's up.

A grep(1) for "Gravity" from the FLTK code seems limited to the Fl_x.cxx
file, and the only ones I can see that we work with are:

* The GravityNotify event
* The CWBitGravity window attribute mask
* The StaticGravity window gravity hint
* The PWinGravity flag hint

[Ian MacArthur‏]

On Thu Jul 10 2014 22:13:52, Greg Ercolano wrote:

> I doubt FLTK has been keeping up with the latest ICCCM features
> which includes specific gravity hints.

We are setting the hints to StaticGravity; from my reading of the Xlib manual that *sounds* like the sort of thing we’d want...

If I understand winfried’s post though, he seems to think that NorthWestGravity would be a better bet.

I do not know the answer...!

[szuk...@arcor.de‏]

fltk-1.3.x-r/src/Fl_x.cxx contains the lines:

 attr.bit_gravity = 0; // StaticGravity;

 hints->win_gravity = StaticGravity;

It should contain the lines:
 attr.bit_gravity = 1; // NW
 hints->win_gravity = NorthWestGravity;

With these values (1 and NorthWestGravity) the XWindow stands fixed
(or calm etc) when an FLTK window changes its size because the image
it shows changes its size.

With StaticGravity the FLTK window jumps like a frog: up, down, left, right.

With NorthWestGravity all WM I have tested (EDE, FVWM, XFCE, FLUXBOX)
show the fixed (or calm etc) behaviour.

By the way: fltk-2.0.x-alpha-r9296 shows the same fixed (or calm etc) behaviour.

winfried

[MacArthur, Ian (Selex ES, UK)‏]

> fltk-1.3.x-r/src/Fl_x.cxx contains the lines:
> attr.bit_gravity = 0; // StaticGravity;
> hints->win_gravity = StaticGravity;

> It should contain the lines:
> attr.bit_gravity = 1; // NW
> hints->win_gravity = NorthWestGravity;

> With these values (1 and NorthWestGravity) the XWindow stands fixed
> (or calm etc) when an FLTK window changes its size because the image
> it shows changes its size.

> With StaticGravity the FLTK window jumps like a frog: up, down, left,
> right.

I find this very puzzling; though I acknowledge that my understanding of X11 is very far from complete, I have tried to make sense of the docs and it still seems to me that StaticGravity should be OK for the behaviours that we want.

I can't understand why it is not working as desired under FLWM.
But you report it works OK on other WM? This is all very strange...

> With NorthWestGravity all WM I have tested (EDE, FVWM, XFCE, FLUXBOX)
> show the fixed (or calm etc) behaviour.

OK, that's very useful to know.

> By the way: fltk-2.0.x-alpha-r9296 shows the same fixed (or calm etc)
> behaviour.

Really? That's interesting, though I do not know what it means...

So far as I know, fltk2 sets StaticGravity rather than NorthWestGravity, so it is indeed very curious that it works correctly in that case.

> winfried

> Am Donnerstag, 10. Juli 2014 21:24:04 UTC schrieb Ian MacArthur: