Re: Dialog Preferences (was whatever)

Francis James Franklin wrote:

>> Which alternatives ? Rewritting it in some way would have been
>> solution, but not for that release.
>
>
> I had earlier looked at the Preferences code and decided it needed a
> rewrite, but hadn't intended to use it as part of 2.2, but then everyone
> was complaining about crashes and the reason was the preferences dialog
> expected there to be at a frame... ahh, yes, but... k, right, how to fix
> this without significant changes to the xp base class? er.

I didn't hace any issue at the time I wrote the dialog. Perhaps changed
something, in that case, there was a mistake.
Fixing XP to make all platform work is NOT a bad thing.
>
> Two solutions:
> 1. Use the new dialog which works mostly?
> 2. Try to fix the old one, which I really didn't, and don't, have the
> patience for?
>
> I have more important things to do.

Then you end up reporting the problem to other. That's called passing
the hot potato....

>
> This assumes that the dialogs are identical across platforms, which I
> accept is one of the goals - but is it an absolute requirement? Doesn't
> it put an undue burden on development of dialogs?

This is a tradeoff to not write the same code zillions time. Note that
this is the functionnal aspect, which we can consider as being the same
accross all the platforms.

> What I much prefer is having an xp class that provides a simple way for
> platform implementations to retrieve information, so that simon says
> "hey, you - update!" and the platform implementation asks:
>

That is almost what we currently do. And it is wrong obvisouly. Most of
the port of dialog code to MacOS X has been done the following:

sed s/Unix/Cocoa/g
create the NIB
edit the source file to change gtk call to cocoa call
test

> What's more, you can implement new stuff in xp and your platform of
> choice without worrying about other platforms; they will catch up in
> their own good time.

No. This has been proven to be wrong. Because changes get forgotten,
never done, not important, whatever. I saw that in MacOS X port, while
the codebase was moving, changer have been done, breaking any other
platform. How many time this made me waste ours, if sometime not days ?
I don't count.

Breaking the build seems to be radical, but at least, it allow to have
things fixed quickier...

When it comes to the new dialog framework, I try to make sure it did not
break windows, because I cannot afford fixing Windows code. But once it
gets dones, I'll make things this way: require it by putting pure
virtual methods pure virtual.

Hub
Received on Fri Feb 25 21:44:11 2005