Date: Mon, 2 Dec 1996 13:25:05 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: text, menu/dialog/windowing, library, ideas? Message-ID: <199612020255.NAA02673@genesis.atrad.adelaide.edu.au> In-Reply-To: <15861.849448832@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 1, 96 06:00:32 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > > Right. And pretty much every other one you'll find, like cdk or the > stuff in ncurses, is either the wrong approach entirely or extremely > difficult to bring into another encapsulation paradigm like TCL. Most ctk would be OK except for the fact that it appears to be an orphan, and the user is likely to try to program it like it was Tk. By virtue of being designed for Tcl, it integrates well. > C library designers think that it's OK to have 14 different structure > types being passed around, which makes it a real nightmare for the > encapsulator. Even that's not so bad; it's as much just that the usual model is "don't call us, we'll call you", and usually without the internal structure necessary to handle timed callbacks. > Ultimately, I think what we're going to have to do is design it from > scratch. It might even be kind of fun, but I'm still wrestling with > some of the design concepts and have come up with multiple approaches > to the problem, all of which have various pros and cons going for > them. Then please start talking at me about it 8) I have the "wrap system libraries for Tcl" stuff prettyuch solved with SWIG, and I want to prototype that modular monster we were talking about before with a small module to frontend for libdisk. A Tk interface would be a trivial exercise, but I want to have a character-only interface as well. > One approach would be to take a very high level slice at the problem > and write a series of very generic "presentation objects" (or > "interactors" or whatever the hell you want to call them). They would This sniffs a lot like a widget heirachy to me 8) You're just saying that the widget types are a little less concrete than the current norm "list of things to select from" rather than "listbox with scrollbar and returning item clicked on". The decoupling is a nice idea, but short of lots of smart code to perform layout work, you end up with a result that looks a lot like most automatically-created UI's - junk. > All that really buys you, however, is the ability to shuffle off all > your icky curses or X specific code into a "display class" object, and > you still need to extend every one of your object classes for each new > object you add (unless that object has no meaning for that display > class, in which case I guess its presence would just be a no-op) which > is kind of a downside. Having looked fairly carefully at the whole thing, I am personally of the opinion that trying to structure a frontend such that the same code works with both an 80x25 and a GUI interface is a mistake. I would love to be wrong on this, and you can make it work by crippling the GUI interface (or at least limiting its scope), but I strongly feel that we should not do this. Naturally, this means that we end up with duplicated functionality and all the attendant headaches, but I think that these are the lesser evil by far. > side of this with my eyes closed, but not the curses stuff. Every > time I think I have its simple-*sounding* model all figured out, > refresh() does things to the screen which leave me mystified. Great. Just what I want to hear 8( > Jordan (sorry if this is digressing a bit much for people) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612020255.NAA02673>