Re: [XForms] a few questions

[Jens Thoms Toerring]

Hi Derek,

On Tue, Oct 29, 2013 at 12:59:27AM +0100, chapitech wrote:
> >There currently is no way to specify such an alignment. May
> >I ask which window manager has a taskbar that obscures a
> >popup? With the only one I have around here at the moment
> >that has a taskbar this doesn't happen, i.e. it show the
> >popup on top of the taskbar. Is it possible that this only
> >happens witg Xming?
> 
> it only happens with xming, and the choice menu is deprecated,
> furthermore it is a "work in progress menu", so if it gets too
> big I'll just have to get bach to my forms storyboard.

So my guess is that it's really due to te different way the
taskbar is handled under Windows and Unix - under Unix it is
(I guess) just another window) hat can become (partly) ob-
scured by other windows (at least transient ones like the pop-
ups) while under Windows the taskbar is considered to be too
important for even that. 

It's probably a hard to solve problem: XForms doesn't know
that it runs under some Xlib-emulator on Windows. And even
if it would know: how to figure out what amount of screen real
esatate is it allowed to use? I guess that can only be solved
on Xming's level, e.g. by Xming only reporting the size of
the usable window for the "root window" instead of the size
of the whole window, including the taskbar...

So the best fix is probably adding an additional function
that allows you to pecify an alignment for the popup. At
least that's the only "fix" for your problem I can come up
with at the moment.

> I understand that a canvas object is little more than a wrapper
> for Xlib (and very useful it is too) but i don't see why other
> form elements don't report which buttons called them.

As I said, because nobody was interested in this before. And,
to be honest, I'm not sure if it's good UI design if widgets
react differently to different mouse buttons - there's no
visible indication that they do, so this extra functionality
can only be used by the few people that really read the full
documentation;-) The fl_get_button_numb() function was already
there when I took over as maintainer, so I can't ger rid of
it, but otethrwise I probably would have flinched at being
asked to include it.

> specifically I use one slider that can change an array size (free, malloc),
> which combined with an idle callback effectively freezes the machine.
> what I was looking for was a left_button=change value and
> right_button=commit value. if I remember correctly the info seems to
> be simply &'d out before returning which button was pressed.

The button used for an action is nowhere stored at all at the
moment (except for buttons, due to the fl_get_button_numb()
function), so I can't return it in any way. Storing them
would require extra space in the internal structures which
in turn would require a new, non-backward compatible version
of the library. That's something I tend to try to avoid, so
I'd need some good reasons for that.

But from your description of what you try to do (please accept
my apologies if I'm a bit dense and misunderstand you) the pro-
blem seems to be that each movement of the slider gets reported
(even while keeping the mouse pressed down), resulting in calls
of rather time-consuming functions. Would a solution be to have
the slider only report something after the mouse button finally
has been released? I.e. while the user is still changing the
sliders position nothing happens, only when he finally decides
he has found the value he wants this triggers the call of the
callback function (or is returned from fl_do_forms())?

In that case setting under which circumstances the slider
change is reported might be a solution. This can be achieved
by calling fl_set_object_return() on the slider object with
an argument of e.g. 'FL_RETURN_END_CHANGED' - this results in
slider changes to be only reported once the user is finshed
with moving the slider around (indicated by releasing the mouse
button) and wen the value actually changed. Could that be some-
thing that could lowers the workload of your program enough?

> obviously oct2013.png is the most recent, and I was playing with
> some new features so the tent looks quite nice. I would be delighted
> if you were to publish it.
> caption: "Mesh, by Robert Hawkin, for www.chapitech.fr".

Thanks, I'll put it into the screenshot section hopefully to-
mmorow;-)

> btw the 3D autoscale, viewpoint, pan, rotate, and zoom are all fairly
> easy stuff that could be integrated into the demos. if you give me a
> 3D array generator I will send back a simple 3D viewer (in a month or so...)

If you have a good idea for a demo program than please go ahead!
I'll be happy to add it. But of you ask me for a "3D array generator"
I must admit that I don't know what you're expecting from me.
Preferbly the demo programs should be rather simple and basic
and not need input files that are difficult to generate.

                               Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de