On Tue, 2014-01-28 at 13:47 +0100, peter sikking wrote: > Mitch wrote: > > > I really don't know where the problem is here. > > now that I was asked to get involved, read the spec and > made an analysis, here is what the problem is: > > > TITo, as it stands today, is a UI subsystem for which it > was never decided whether it was a search/help system or > a command interpreter. trying to be both, it is simply > substandard at either tasks.
It's not trying to be both, it's a menu/action search. > (yes, there is a hard trade-off between the two: > a search/help system must be compassionate and forgiving, > mapping a large set of search terms to a range of answers. > a command interpreter has a tight, _designed_ command set > whose only goal is to get users as fast a possible to > one unique command to invoke.) > > > since it is a 100% UI subsystem and I am involved anyway, > I realised that the only thing I can do is to help the makers > step by step to get TITo into a shape that makes sense to > release. (OK, the other thing that I can do is to refuse > that this goes into GIMP, but that is not constructive). > > we are at step one which is simple and hard at the same time: > define what TITo is and why it makes sense in a GIMP context. > > already a couple of surprises came out of the woodwork, > information that was not available to me before. for the rest > it is slow going, ‘why does it make sense in GIMP?’ seem to > be a fresh question, where the answers still need to be found. > > up to now various people have offered a lot of tautologies, and the > fact that it has been implemented in completely other contexts. > that is not convincing at all. also that answers from everyone > have a different view on whether it is a search/help system or > a command interpreter. Nobody ever claimed it was a command interpreter. All discussion aside, I have promised the guys that this would go in a long time ago, and just needs some cleanup. That cleanup has happened now and i suggest we merge it, also to prevent the (very real) danger of bitrot. Improvements happen a lot faster once an initial version is in git. Also, a lot of time has passed since the initial proposal (code included) and now, and we cannot piss off people who put a lot of work into that by now rolling back to a state where no code even existed, especially given that merging it was already agrees upon. We can't retroactively change such decisions. Now that we are in this state, we have to work based on what we have. Regards, --Mitch _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
