[XForms] Bug in fdesign

[Sian Mountbatten]

I have discovered that if I create a simple form containing two
spinners, fdesign generates a
fd file successfully. Examination of the file shows that three objects
are specified in the
number of object field and, indeed, three objects are detailed.

However, if fdesign is started with the arguments -lax -nocode and then
asked to load the
simple form definition file, fdesign reports that there are less objects
in the file than
expected. It would appear that the program does not count the number of
objects correctly.

At present, I cannot open an already existing form definition file. This
is a definite bug.
--
Sian Mountbatten
Algol 68 specialist
--
Sian Mountbatten
poen...@fastmail.co.uk

[Jens Thoms Toerring]

Hi,

On Mon, Jan 30, 2012 at 06:51:37PM +0000, Sian Mountbatten wrote:
> I have discovered that if I create a simple form containing two
> spinners, fdesign generates a

> .fd file successfully. Examination of the file shows that three objects

> are specified in the
> number of object field and, indeed, three objects are detailed.
>
> However, if fdesign is started with the arguments -lax -nocode and then
> asked to load the
> simple form definition file, fdesign reports that there are less objects
> in the file than
> expected. It would appear that the program does not count the number of
> objects correctly.
>
> At present, I cannot open an already existing form definition file. This
> is a definite bug.

I already wrote to Sian directly, asking for a few details
about the version since I can't reproduce the problem at the
moment with the newest version of fdesign. If someone else
sees the same (or similar) effects please let me know!

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

[Paul Nicholson]

Jens wrote:
> I can't reproduce the problem at the moment

I just tried, cannot reproduce it here either.

3 objects are saved, and load back in ok with
-lax -nocode.

Perhaps there is something happening with particular
coordinates that Sian is using.

--
Paul Nicholson
--

[Jens Thoms Toerring]

Hi Paul,

On Mon, Jan 30, 2012 at 09:53:47PM +0000, Paul Nicholson wrote:
> Jens wrote:
> > I can't reproduce the problem at the moment
>
> I just tried, cannot reproduce it here either.
>
> 3 objects are saved, and load back in ok with
> -lax -nocode.

Thank you!

> Perhaps there is something happening with particular
> coordinates that Sian is using.

Sian, to be able to check for something like that, could you
also send me the .fd file?

Thanks and best regards, Jens

[Jens Thoms Toerring]

Hi Paul,

On Tue, Jan 31, 2012 at 12:59:38PM +0000, Paul Nicholson wrote:
> The attached .fd file has 2 objects.
>
> I can sort-of reproduce this.
>
> Starting with a blank form, select Spinner from the object
> menu, drag to create a spinner, and then drag again to create
> another spinner without noticing that Spinner has de-selected
> itself in the object menu. Of course, same for all other
> objects too. Not a bug, but failure by me to notice that
> the object had de-selected.

But you should get a visual clue that there actually is
just a single spinner, don't you? One could try to not
draw a "rubber band" when there's nothing selected but
that's all I could do (if I find the place, fdesign is
not the simplest program to understand;-)

> While we're on the subject of fdesign bugs, maybe I have
> a little one to offer.
>
> It's a rendering artifact.
>
> Open fdesign, don't bother to create a form or anything,
> just run the slider up and down the Objects menu a few
> times. It creates spurious horizontal lines just above
> and below the Objects menu box.

Thanks, I see it also. No idea at the moment were this is
coming from. I will have a look but, due to the current
workload, I won't make promises when this will happen;-)

Thank you and best regards, Jens

[Jens Thoms Toerring]

Dear Sian,

On Tue, Jan 31, 2012 at 12:21:35PM +0000, Sian Mountbatten wrote:
> I've looked at the source code of fdesign and it looks alright. I am
> using version 1.14
> and I've just used it to open three simple forms and it worked. No bug.
> Very peculiar.

Definitely strange!

> Sometimes it's there and sometimes it isn't. Don't ask me why.

I won't as long as you don't expect an answer from me;-) I just
would like to ask to to keep an eye out on it for reappearances
of the problem.

> Please find attached one of the files in question (very simple).

Thank you. For me it also works without a problem, so I don't
have any idea yet what might have gone wrong, sorry...

Best regards, Jens

[Paul]

Jens wrote:
> I see it also. No idea at the moment were this is
> coming from.

It is present also in demos/browserall

It is something to do with the horizontal browser lines,
the artifacts appear as a browser line scrolls out of view.

I will have a look at how the browser lines are handled.

--
Paul Nicholson
--

[Jens Thoms Toerring]

Hi Paul,

On Tue, Jan 31, 2012 at 08:31:34PM +0000, Paul wrote:
> > I see it also. No idea at the moment were this is
> > coming from.
>
> It is present also in demos/browserall
>
> It is something to do with the horizontal browser lines,
> the artifacts appear as a browser line scrolls out of view.

Oh, that's interesting, I hadn't noted that.

> I will have a look at how the browser lines are handled.

Thanks a lot!
Best regards, Jens

[Paul Nicholson]

So far as I can see...

The separator lines are the problem.

These are rendered with a call to draw_symbol()
to do a "@DnLine" but I can't see where this is
being clipped by the window of the tbox object.

By contrast, the ordinay text lines are passed
to fli_drw_stringTAB() and end up at a call to
XdrawString and these seem to clip ok.

I just need to figure out where the clipping takes
place in each case...

--
Paul Nicholson
--

[Paul]

Hi Jens,

I see the cause of the problem now.

The clipping is done by the GC.

Ordinary text in the tbox component of the browser is drawn
using a GC correctly set up for the tbox.

But the separator lines are drawn by a call to fl_drw_text().
This function doesn't use the tbox GC, instead it uses a global
one called flx->gc.

Hence the separator line doesn't get clipped.

Only if the tbox text row that contains the separator is
completely out of the tbox bounds so that fl_drw_text() is
not called at all, then it is ok.

Not sure of the solution, other than to modify fl_drw_text()
to pass down a GC (or NULL) for the lower functions to use.
If a NULL is passed, it would use flx->gc by default.

--
Paul Nicholson
--

[Paul Nicholson]

[Jens Thoms Toerring]

Hi Paul,

Since you have done already all the necessary diagnostics
I guess the real hard work is already done by you! Finding
the therapy should be quite a bit easier;-) Should you feel
like doing also that I won't try to stop you, but you can
also leave it to me. The only problem is that I'm fighting
with Qt to do the right thing since several days and I can't
forsee when I'm done with beating it into submission. And
before I'm finished with that I probably won't have to time
(nor enough of whatever may be left of my patience;-) to
take a closer look at this browser issue...

Thank you and best regards, Jens

[Paul Nicholson]

Jens,

I think there may be a quick solution...

Rather than modifying fl_drw_text (which has over
80 calls), maybe we can set up a temporary target,
call fli_switch_target(), draw the tbox, then call
fli_restore_target().

Something like this is done in image/image_text.c
in order to temporarily set flx->gc to the GC of the
image.

I will test this out.

There may be other objects where incorrect clipping
of lines and symbols is occurring because they are not
using the specific GC of the object.

Good luck with the Qt thing!
--
Paul Nicholson
--

[Jens Thoms Toerring]

Hi everyone,

I'm back to fiddling with XForms and will try to address
all the things that came up in the last few weeks in chrono-
logical order.

> On Tue, Jan 31, 2012 at 12:59:38PM +0000, Paul Nicholson wrote:
> > The attached .fd file has 2 objects.
> >
> > I can sort-of reproduce this.
> >
> > Starting with a blank form, select Spinner from the object
> > menu, drag to create a spinner, and then drag again to create
> > another spinner without noticing that Spinner has de-selected
> > itself in the object menu. Of course, same for all other
> > objects too. Not a bug, but failure by me to notice that
> > the object had de-selected.
>
> But you should get a visual clue that there actually is
> just a single spinner, don't you? One could try to not
> draw a "rubber band" when there's nothing selected but
> that's all I could do (if I find the place, fdesign is
> not the simplest program to understand;-)

I had another look at this and it's not that simple: when
something is selected in the object type browser clicking
into the window and then moving the mouse creates a new
object when the mouse button is released. But when nothing
is selected in the object type browser the same sequence
of events has a different meaning, it is used for selec-
ting object(s).

So not drawing a rubber band when no object type is
selected (or not deselecting the selected object type
after an object has been created) is not really an al-
ternative since then we would lose the ability to
select one or more objects...

So the whole thing is a interface design issue that can't
be corrected by a relatively simple code change but would
require a change of how you can interact with the program.
And that's something I would prefer to spend quite a bit
of time to think about it and discuss this here before
I start fiddling with it.

> > While we're on the subject of fdesign bugs, maybe I have
> > a little one to offer.
> >
> > It's a rendering artifact.
> >
> > Open fdesign, don't bother to create a form or anything,
> > just run the slider up and down the Objects menu a few
> > times. It creates spurious horizontal lines just above
> > and below the Objects menu box.

That's the next thing I will try to fix. Most of the
work already has been done by Paul, so that shouldn't
be too difficult;-)
Best regards, Jens