From: Ralph T. <ra...@gm...> - 2005-03-12 00:38:19
|
Okay -- now I understand where you want to go. I've been working on a little toolkit which essentially does the same thing. At the moment I have implementations for MacOS and Win32 (I have a GTK+ version, too, but I haven't ported my test tool to X11 yet, so I don't know if it's really up to snuff). The idea you describe (of having "widget styles defined in terms of widget usage, rather than widget appearance") is the only sensible way of writing this, in my experience. How much interaction is there supposed to be between the ui-core code (window_t, button_t...) and application code? Is it all meant to happen through Adam and Eve, is there ever a circumstance where you want to touch a button_t directly from application code? If not, is it important to implement the same C++ interfaces on every platform so long as the interface from Eve is the same? Best regards, Ralph On Fri, 11 Mar 2005 11:01:38 -0800, Foster T. Brereton <fbr...@ad...> wrote: > On Mar 10, 2005, at 11:40p, Ralph Thomas wrote: > > > Are you planning on making the toolkit interface exactly the same for > > Windows and MacOS (so that the same eve files could be used on both > > platforms)? > > Yes. > > We are trying to do more than provide a common API for all platforms. A > point we are trying to achieve is to distill the semantics of these > widgets down to their minimum requirements, completely separated from > platform-specific UI APIs. We then want to conform the ui_core API to > those semantic needs instead of tying it to a specific platform and > forcing the other platforms to "catch up". In this sense, then, all the > platforms are playing "catch up", because there are varying degrees of > functionality across them, and all should strive to achieve good > implementations for these semantics. Obtaining the ideal dimensions of > a widget is a good example of this-- neither platform does it > perfectly, and yet ultimately that is the behavior you are striving > for. > > What we have found is that the client has a specific intention and > purpose for a widget. With APIs that let clients set various attributes > of a widget (font size and style, event handlers, etc) the client will > set these various attributes for each to match this intention. For > example, buttons in palettes will have a certain "look and feel", as > will buttons in a standard dialog, though the "looks and feels" could > be very different between the two. What we are doing with ui_core is > coding the API to the "look and feel" and not to the minutiae of > achieving that look. More formally, we are writing the API to the > behavior requirements (semantics) of the widget, instead of forcing the > client to define those semantics implicitly through their tweaking of > the widget's minor attributes (font size and style, event handlers, > etc). > > As a specific API example, we do not have "set_font_size" anywhere in > the ui_core API. But we do have a more general "set_theme" (which even > now is still not where we want it). Please keep in mind the ui_core API > is in need of a lot of work, but I hope this gives you a general idea > of the direction we are interested in taking it. > > It is a start, we believe a good start, but only a start... > > Blessings, > Foster > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |