Subject:
Re: Comments on NanoWidgets
From:
"Vidar Hokstad" ####@####.####
Date:
5 Oct 1999 22:51:56 -0000
Message-Id: <19991005224812.24204.qmail@mail.relight.com>
On Tue, 5 Oct 1999 16:23:26 -0600 you wrote:
>: In that case I suggest you look at my NanoWidgets widget set, and comment
>: on it if there are specific things you need in order to be able to use
>: it. It would be nice avoiding duplicate efforts.
>
>
>I have comments on NanoWidgets.
>
>
>I am concerned about the api's used to set various
>characteristics of each widget. Although I like the new mechnism
>to get an NOBJECT *, I don't like that there are separate api's to, say,
>resize a widget. This is system endemic. Say we want to resize a button
>(b1)
>and a radio (r1). We have to:
>
>
>b1 = NEW_NOBJECT(button);
>
>r1 = NEW_NOBJECT(radio);
>
>// very cool so far
>
>n_button_init(b1, parent, title);
>
>n_radio_init(r1, parent);
>
>// geez, why do we have separate nobject init calls? Both require
>parents, why not specify them in the NEW? Also, radio's could use a title
>too.
We don't specify them in NEW_NOBJECT() because not all objects are
widgets. For instance NRENDER objects doesn't have any parent. It's easy
easy enough to create a NEW_NWIDGET() too.
As for the title, maybe.
>In general, there ought not be a separate api for each object type.
>The general n_widget_xxx ought to handle standard initializations. I can
>see where someday you might want special widget calls, but not for basic
>stuff like setting titles (text) and default handlers.
I agree in the cases where the same features are available. Currently,
I haven't supported titles for radio buttons, but it might be good
to add support for a title for them.
>In this way, people less inclined to architecture can add new widgets
>without over-extending the api such that you have to know everything about
>the specific object to do anything with it. Take the case of a dialog editor
>application. You mean it's got to be coded specially for each object that
>it wants to place. Bad design.
Again, in the cases where the feature set is overlapping, sure. That is
why the entire system is based on virtual methods all the way, so it is
easy to do just that... But there will still be a considerable amount of
specialized methods for many classes. But of course, whenever you see me
adding overlapping functionality in different places, keep nagging me
about it :-)
>Anyway, these are my $.02 worth (I don't have any SKs).
SK's? I use only NOK's :-)
>I like the overall class design madness that Vidar has built, but I'm kindof
>an api nut and I think this should be sorted out early. This also lets a
>standard api to be used, while letting others reimplement the widget.
>In other words, the widget implementation doesn't come across in the api.
>
>The following ought to be available (changeable by standard api's) for any
>widget:
>
>
>class, x, y, cx, cy, title, parent, style, callback
Class can't be changed for an instantiated object, for obvious reasons
(other than casting to a base class), but creating an object based on a
text string with class name should be acceptable.
As for callbacks, I agree, the callback mechanism should be standarized.
I'm not sure what the best way of doing it is, though. Any suggestions?
x,y,width and height is already settable. parent is settable at
instantiation.
Title? Maybe. It's easy to add it to the widget.
Style is, I presume, what I have called "render object". You can't currently
change the render object, but that is because render objects (NRENDER)
wasn't implemented until earlier today, and I haven't gotten around it yet.
In addition, all widgets are potentially containers (it's just that not
all widgets will display it's children), and can have a layout object
associated with it (not implemented yet), that will handle layout of the
children widgets
Regards,
Vidar
