[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Comments on NanoWidgets
From: Greg Haerr ####@####.#### Date: 5 Oct 1999 22:25:50 -0000 Message-Id: <01BF0F4D.F48A0E50.greg@censoft.com> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Comments on NanoWidgets
From: Greg Haerr ####@####.#### Date: 5 Oct 1999 23:46:10 -0000 Message-Id: <01BF0F59.32A58EC0.greg@censoft.com> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |