[k3b] confirm (and fix) bug 232148

[sbalfour at att.net]

Hello, folks,

I'm new to k3b, and happy to contribute my part.  None of you would know me at this point.
I was a Unix/Linux tools build and maintenance engineer for 28 years at Cisco Systems,
so I know a thing or two :-).  Say hi if you worked there with me.  On to business:
bug 232148, k3b crashes after ' Closing' the "Waiting for Disk" query window.  I can
reproduce this 100%, so I'd like to get it 'Confirmed'.  I evidently don't have the permission
bits (how do you get them?)  I want this one, so unless someone else already loves it,
assign it to me (how would I do that? - I have a Bugzilla account already).

The crash is easily fixed, a one liner.  It was left there because nobody implemented a
close action and the destructor later attempted to delete some object(s) through null or undefined pointer(s).  The larger issue issue is what should the semantics of 'Close' be
in a positive-choice dialog?  The user may 'Load', 'Eject', or 'Cancel' depending on 
whether he has no media inserted, an invalid media inserted, or decides not to burn
for some other reason.  Close usually means do as much of nothing as possible.  You can't do nothing here.  Ignoring the Close button seems too much like what a malicious
popup window would do.  But not ignoring Close means electing some action, and
any election assigns aggressive semantics to a passive action.  Somebody tell me
what you want to do, and I'll implement it.  Is there a design document like a UI guide,
that specifies these things?

                                                                  Stuart 
                                                                  sbalfour at att.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/k3b/attachments/20100612/f097b3ac/attachment.html>