Subject: Re: lists bug
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Nov 22 2000 - 07:48:39 CST
On Wed, 22 Nov 2000, Thomas Fletcher wrote:
>
> There are definitely some "flaws" with the list dialog. I think that
> the internals (not the look, just the behaviour behind the scenes) can
> be cleaned up enormously. I think that this is a post 0.7.12 release
> job though. This is the first release with lists ... people should
> think of it as a preview of things to come rather than as a polished feature.
>
> > Besides this, and the point that I can't seem to get it to give an instant
> > feedback in the preview how the list will look, and the fact that the only
> > model/design I have to extract the logic from is the "flexible" GTK+ C code
> > (which I after carfeul consideration have come to consider "not fit for
> > human consumption"), and that I haven't really got the hang of which parent
> > class methods&variables do what just yet, we're getting closer. :-)
>
> This is the way that it is on all platforms. I think that the XP code
> only updates the preview when the "m_bisCustomized" flag is set. This
> is a bug in the current behaviour IMHO, but I'm waiting to fix it until
> after 0.7.12. I agree with the not fit for human consumption comment,
> this is mainly because the list dialog has already iterated through
> one lifetime and kept some cruft from that time. You can take a look
> at the QNX dialog. It isn't necessarily better, but it isn't worse =;-)
>
My appologies on the horrible code. I should bit the bullet ages ago and
just rewrote the xp code down to platform code. The reason I didn't was
because the Windows dialog worked albeit with much less than 100%
functionality and there didn't appear to be anyone around at the time to
update the Windows front end. The result would have broken Windows
totally.
Anyway you're fighting between two BADLY named member variables.
m_iListType which is meant to be the list type most recently read from the
current cursor position and m_newListType which is meant to be set from
the GUI. At some times in the Dialog lifecycle it is appropriate to use
m_iListType at others it is m_newListType. Sometimes one is set to the
other.
The bottom line is that what gets displayed in preview is the value of
m_newListType if m_bguiChanged is true otherwise it is what was most
recently read at the current cursor point.
If it makes you guys feel better the Unix version still doesn't do quite I
want it to. I have ended up writing spagetti code to handle all the
assumptions present. I now have 3 boolean member variables which are used
in combination to deterime what gets displayed in the preview. It's
horrible. I should think it through properly. I want to re-write it too.
Sorry.
Martin
> > I won't make a promise, but I'd think it's checked in within the next 24-48
> > hrs. Perhaps not with _all_ the wrinkles ironed out, but I think we can put
> > that in a release note.
>
> Agreed. That is the disclaimer that I will be making with
> the QNX version.
>
> Speaking of release notes, it would be interesting to get
> all of the platforms to write a "platform notes" which
> could accompany the general release. Is this a good idea?
> Is it worth spending time on now?
>
> Thomas
> -------------------------------------------------------------
> Thomas (toe-mah) Fletcher QNX Software Systems
> thomasf@qnx.com Neutrino Development Group
> (613)-591-0931 http://www.qnx.com/~thomasf
>
>
>
This archive was generated by hypermail 2b25 : Wed Nov 22 2000 - 07:48:45 CST