Reporting Metacard Bugs

[Ken Ray]

On 5/14/06 12:06 AM, "Bob Warren" <bobwarren at howsoft.com> wrote:

> Bob Warren wrote:
> 
>>> With this experience, I can now tell you more precisely what happens in
>>> MC, and it is exactly the same under the 3 Debian-based distros (using
>>> both Gnome and KDE interfaces)I have tried:
>>> 
>>> 1) If you minimize the PROPERTIES BOX or the MESSAGE BOX, everything
>>> disappears from the screen, and you are left with an icon for the Menu
>>> Bar only in the task bar at the bottom.
>>> 
>>> 2) There is no way of restoring anything except the Menu Bar.
>>> 
>>> 3) The above is not intermittent, but guaranteed every time.
> 
> Richard Gaskin wrote:
> 
>> This appears to be different from the behavior on OS X and XP,
>> suggesting a problem in the engine unique to Linux.
> 
> ---------------------------------------------------------
> What, if anything, do you think could be done next?

OK, I installed Ubuntu Breezy Badger and did some testing and here's what I
discovered:

1) Floating palettes just aren't... if you palette a stack and ask for its
style, it comes back as "toplevel", and acts like a toplevel stack.

2) For the reason stated in (1), all stacks open with default decorations -
this causes the palettes (tools, properties) and modeless windows (like the
Message Box) to display the minimize, maximize and close boxes (or if the
'resizable' of the stack is false, the maximize button is not displayed).

(So, Bob, you shouldn't even be *able* to minimize those stacks - they are
supposed to only have a close box.)

3) The minimizing situation is due to the fact that there are 'iconifystack'
and 'uniconifystack' handlers in the MetaCard Menu Bar script (that only
trigger on Linux because of #1 and #2), and for some reason the MetaCard
Menu Bar is *removed* from the list of stacks that should be restored, so
they don't get restored when you "uniconify".

So it seems to me that we can fix the minimizing issue by explicitly making
the IDE set the decorations to just "close" instead of "default", and we can
modify the iconifyStack and uniconifyStack messages so that things are
restored properly, but that doesn't affect the problem that the *engine* is
responsible for not allowing palettes under Linux (or so it appears).
 
> Since this is the same 2.6.1 engine I am (not) using for Rev, does it
> mean that any alteration for the benefit of MC might also affect Rev?

Yes, but only if the changes is made in the engine.

> Or conversely, when finally they produce Rev 2.7 for Linux, MC might
> behave differently?

No, it shouldn't, unless it is an IDE issue vs. an engine issue.

Can requests be put forward to the Rev development

> team to accommodate MC in the engine, or is MC officially dead? If so,
> that would be a pity, because as far as I can see this little thing of
> the minimization of windows might be fairly simple to correct.

Well, the MC *IDE* is not dead (as you've seen), just used by a small number
of people. And since the engine that drives MC is the same as the engine
that drives Revolution, every time they upgrade the engine for Rev, we MC
users get the benefit (or bugs <grin>).

> Who is allowed to mess around with the engine anyway? I imagine it is
> protected and that only Rev engineers are allowed to, is that correct?

Correct.

> Interestingly, although I have only really played with MC Linux a little
> and not really tried developing an app, there is no sign so far of the
> kind of instability (e.g. unexpected crashes, the IDE getting stuck in a
> loop because it cannot decide which window to put at the front, etc.)
> that I have experienced in Rev. Does this mean anything other than the
> fact that the MC IDE is stable, but that the Rev IDE isn't? Or is it
> more complex than that?

Nope, it's as simple as that - the MC IDE is simpler but has also been
extremely well-tested and was rock-solid stable before the RunRev
acquisition of the MC engine, and since we've made only minor modifications
and have really tried to make things "bulletproof" before official release,
that stability remains.

> Sorry if I'm asking goofy questions, but I've never had the opportunity
> of delving into the inner workings of the system before.

No problem, Bob! Keep 'em coming!

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com