[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/scumm scummvm.cpp,1.99,1.100 scumm.h,1.84,1.85

J.Brown (Ender) ender at scummvm.org
Tue Dec 17 23:27:02 CET 2002


> >Both issues are there to make things easier (until the new debugger at
> >least has the basic functionality of the old). Also I did not want
> >concurrency in this situation, for three reasons:
>
> And I answer with three questions...
>
> >   1) The debugger is far less critical than the GUI
> yeah, so why leave the old source code in CVS???

Read above and the log.

> >   2) The current debugger is almost useless anyway, so concurrency is
> >pointless.
> yeah, so why leave the old source code in CVS???

Read above and the log.

> >   3) It promotes active development of a far more useful replacement.
> >NewGUI is also a far more useful replacement, but OldGUI was at least
> >functionally useful. The old debugger isn't.
> Yeah so why leave the old source code in CVS?

Read above and the log.

To pseudo-quote:
 "The old code is still in the CVS because that way people can easily
copy/paste functionality from it into the new debugger, and switch the
filenames in module.mk if they urgently actually NEED the old debuggers
functionality".

Then, to answer why I left it in CVS, not atticed, read above:
 "Both issues are there to make things easier (until the new debugger at
least has the basic functionality of the old"

Then to answer why I do not run it concurrently, see the three reasons
above:
 "Also I did not want concurrency in this situation, for three reasons:"

...

It's not difficult to understand, is it? :P

Maybe for YOU it makes sense to go digging through Attic'ed files to look
for code to switch rooms from a debugger, or to find out how the variable
watch system worked - however most people who might want to submit a patch
for the debugger are not likely to do this. Think outside YOUR world and
consider we should make things easier for new developers. :)

 - Ender






More information about the Scummvm-devel mailing list