[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