nanogui: Thread: Comments on NanoWidgets

: 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.

	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.

	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.

	Anyway, these are my $.02 worth (I don't have any SKs). 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

	Widgets that need more than this can have extension api functions, 
but the standard ones can then be used for most.

Greg
	

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

: 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.

	Perhaps that's the answer.

: 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.

	The whole idea is to get a good idea of what the end is like
for most of the primitive objects we will support.  Then we want to have
the same api to create any of them.  This means alot fewer miscelaneous
api's to learn, as the objects, their parents, their size, their title, etc
are all specified at one time.  Sure you can _also_ change them later,
but that's not the standard way.  Most objects don't need to be changed
later, so why make 4 api calls when one could work, and work for most objects?



: 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.

	Create based on a text string class name.  This is a great
way to disassociate class implementations from the calling api.  Remember
not everyone wants the same implementation, but it's sure nice not to have
to rewrite _everything_ in that case.


: 
: 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?


	Yes.  First think about the sorts of things most callbacks want.
A pretty good way is by sending a "message."  This is similar to the events
that Xlib hands over to the user application.  A standard Event structure
is filled in, and a switch statement is executed to process the data.  Replace
the word "Event" with "Callback" above and you've got your callback methodology.

Greg