Date: Thu, 11 Dec 1997 02:18:56 -0800 From: Jonathan Mini <j_mini@efn.org> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Jonathan Mini <j_mini@efn.org>, The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <19971211021856.61158@micron.mini.net> In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800 References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard <jkh@time.cdrom.com> stands accused of saying: > > If I were to write another (smaller, and more acceptable) CUI > > would you be interested in using it in sysinstall also? > > YES! YES! Or, to put it another way, YES! :-) I thought so, but wanted to make ABOSLUTELY sure. :) > The alternative is TurboVision and, as much as I rather like it as a > CUI toolkit and find its look-and-feel to be second to none in the CUI > domain (in fact, I think I can say without fear of hyperbole that it > goes about as far as it's possible to go with a CUI, period), there's You and I are on the same bandwidth. I was brought into the event-driving UI world with Turbo Pascal's version of Turbo Vision 2.0 (which, btw, is _much_ better than the C++ version by far. It is cleaner, smaller, and more ellegant in implementation) Ever since then, I have been unimpressed with other GUI's, as my impression is always that they are bloated, half-functional, and ugly. :) > just this big huge problem with it. It's in C++. I hate C++ and so > do just about all of the other installation hackers, so we have > something of an impasse in the interface group right now (heck, for > the last 8 months even). I HATE C++. It has four problems that I consider unacceptable : 1) It's syntax does not remain constant. For example, a '<<' does not always mean "binary shift left." 2) It had a large number of puns, (Bison would call them Reduce/Reduce conflicts) that is situations where one construct can mean multiple things. This is made most annoying when it combines with #1, in that an operator can have several paths to reach it's goal, and the compiler picks among them implicitly. 3) C++ does not implement data hiding. Sure, you have opaque structs, but you cannoy make an opaque class. That is, you cannot have a class defined where you know how to interface with the functions, but not the details of the internal data. Because you have to define the private data within the same scope as the public interface, private datatypes aren't possible. 4) C++ does things without you knowing it, whether or not you are using classes at all. This goes along with the collision of #1 and #2. A good example is if you define a new data-type, say a fixed real. This fixed real is represented in memory by an integer, which causes problems with the automatic implcit casting code, especially in conjunction with 'overloading' (see #2) where a functino with the same name can handle multiple data types. When it is possible so implicitly cast a foreign data type to more than one function, the compiler gets to (basically) blow up, and the casting has to happen explicitly. But, implcit casting is supposed to be a big deal. :) There are my gripes with C++. > Give me something that's written in straight C and easy to wrap into > TCL (which should be possible unless you decide to pass all kinds of > nasty structures around and expose that in the C API) and I'll be your > friend for life. OK, so maybe that doesn't sound like such a treat, > so let me just say that I'd really really appreciate it and so would > many others. :) > > We basically just need: > > o Buttons - pushbutton, radio, checkbox. > > o Scrolling list menus (or scrolling arrays of buttons, > however you want to conceptualize it) > > o Entry fields with reasonably emacs-like character editing > support. ( ewww, emacs ) > > o Scrolling text boxes and simple text fields. > > o Checkbox / Radio > o Gauges. > > o Compound dialogs. > > o Simple forms entry. > > And we could do everything that sysinstall does messily with libdialog > today. Support for color and the mouse would be optional niceties, > but not strictly necessary. Would have to look reasonably decent in > at least syscons and xterm (vt100) display modes and that's about it. > > What do you think? I have another project which requires a nearly-exactly-identical system. I will spend a few days creating an API and then send you an overview for comments. Do you want me to send it to you personally, post it to hackers, or make the documents available via the web? (My system will be expandable to graphics modes, just FYI) -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971211021856.61158>