Documentation and resizable window

[Richard Gaskin]

Éric Miclo wrote:
 >>> I took a look at bug 2585 and I don't understand why you only set
 >>> it  as a normal bug. I find it more severe.
...
 >> Yeah, I'd like greater convenience too, which is why I posted the  BZ
 >> report.  But even with a little scripting now and then I still  have
 >> righer ROI than I've had with any other tool I've used before.
...
 >> That particular issue is marked as "normal" because it can be
 >> completely resolved by pasting a short scipt (see my previous post).
...
 > The time you loose is not in writting the code, but in finding why it
 > doesn't work as expected.
 > I have the habit to think that I did something wrong before thinking
 > it's a bug in the tool I use (perhaps a not so good habit :-)).

I agree, and I believe that's a wise insight.  Most of the time I spend 
debugging involves diagnostics -- once the root cause of an issue is 
known it's often not hard to either fix it or work around it, as you've 
done. But as you pointed out, getting to that point is where the time 
gets lost.

Perhaps the greatest value of Bugzilla is that it serves as a real-time 
reality check, a way to quickly find out if an issue is known or just 
one's own misunderstanding or a typo.

And of course, in addition to Bugzilla there's this list.  If 
something's not there and a solution isn't readily evident in your code 
it never hurts to pass it by the folks here -- if it's the engine 
they'll confirm that, and if it's your code they'll offer a solution.

I'd like to see the quality high enough that we don't ever need to do 
that, but in this imperfect world most developers have to check in with 
someone to see what's up with the issues they encounter.  I see this 
with operating systems, drivers, and development tools alike. It's not 
ideal, and it benefits everyone to keep raising the bar, but in the 
meantime all I can offer as an outsider to the process is a tip or two 
now and then when they might help. :)

 > Last thing, the workaround is only partial because you can't
 > disable the closeBox under Windows without disabling the
 > resizable of the stack and that means you'll have to write
 > your own code for resizing  stacks and add your own piece
 > of GUI to manage it.

Yes, that part of the bug has no simple workaround, so if you need to 
omit the closebox you're in a different situation indeed.

Is there a way the workflow for that window could be designed such that 
the close box is left in place?  In terms of the semantics of the user 
interaction close boxes are commonly treated as synonymous with a 
"Cancel" button -- could that apply to your window?

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com