[boost] Re: GUI/GDI template library
Do I detect some sarcasm here? I thought it was fairly clear why I mentioned javascript, win32, etc. Did I say something you agree with? Something obvious? I can't tell. "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > It smells like what I was saying in part besides the javascript, win32 API & > .NET. What is the definition of a widget? It is basically the visual > representation of a container. In ten years from now, I expect to cout my > application to the screen: > > typedef tree ...> >, ...> >, ...> >, ...> > myapplication; > > myapplication application; > > for_each(application.begin(), application.end(), print(uiout)); > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
I am very interested in this project, and would be willing to devote a considerable amount of time to it, depending on how it evolves. (Please forgive me if I focus exclusively on GUI objects, and ignore the connection with STL-containers of non-GUI objects.) I believe that it is possible to create a flexible, elegant platform-independent user interface system in C++ which serves 90% of most programmers' GUI needs. This should be done in such a way that programmers could fill in the remaining 10%, when necessary, using their favorite platform-specific tools. I have several observations: 1. About three years ago I was interested in designing javascript widgets for the web. Existing collections were disappointing, because the different widgets relied on separate code, and the widgets were only configurable in a limited way. I found, to my surprise, that I was able to write a general toolkit for creating web widgets of all sorts (menus, trees, scrollbars, various sorts of buttons, etc.), with behavior based on simple state machines, which took up only about 27k (after I shortened variable names and removed whitespace using my "javasquish" utility.) It turned out that the widgets built this way did not perform well on the browsers of the time, but it shows how much you can do with almost nothing. 2. Last year I wrote a template-based win32 GUI library, with features inspired by the standard library. All of the significant widgets (tree-views, menus, etc.) have an STL-container-like interface. Also, there is a framework for associating styles with widgets which parallels the locale framework. A style corresponds to a locale; facets include fonts, borders, backgrounds, etc. There is an additional dimension, though: facets are assigned to styles relative to a "style-target", e.g., menu, tree-view, etc. The library is win32 specific, but I think its design could be used as the starting point for a platform-independent library. Each widget inherits from a based class ("Control") which stores information common to all widgets, such as size, position, visibility and list of children. Widgets derive most of their properties from contained policies objects. Each policy object participates in its own delegation hierarchy, which is the main way that behaviour is inherited. The policies in the win32 library are: Properties - corresponds to most the stuff passed to RegisterClassEx and CreateWindowEx, excluding the window procedure Procedure - Corresponds to a window procedure; handlers (in the form of function pointers, pointers to members, ...) can be added for messages, commands and notifications. Style - allows stylistic information to be retrieved via use_facet. Of course these would be different in a general library. Style would subsume Properties, Procedure could be renamed Behavior, and a Layout policy could be added. 3. I believe almost everything can be done using the following ingredients: a. The ability to create, destroy, size, position, show and hide a rectangular window with no children and no decorations. b. The ability to draw an image (bitmap, png, etc.) at a particular point in a window c. The ability to perform simple drawing, possibly limited to filling rectangles and drawing straight lines, but possibly including more sophisticated constructs. d. The ability to draw text, with simple formatting. (Here I am thinking of text only for labels and simple edit controls. Word processing documents would not be supported.) e. A timer facility. f. The ability to harness UI events, such as mouse movements, and direct them to the appropriate widgets. Others have mentioned that item (g) is quite different on different platforms. However, this problem needs to be solved only once in a generic way for each platform, for top-level windows only. Children of top-level windows can be invisible to the native windowing system, so the library can have complete freedom in routing events or invoking callbacks. If one is not careful, one could end up with something that looks like Java Swing or the .NET library. With care, however, I think one could whittle down the set of features which would have to be implemented on each platform to just a few, and still have a useful system. Jonathan "E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I was thinking about designing a GUI/GDI template > library. > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Revised streambuf library
Thank you for your interest. "Paul A. Bristow" <[EMAIL PROTECTED]> wrote: > Sadly the test program fails to compile MSVC 7.1 as indicated below: [snip] > basic_string_source(const string_type& source) > : base_type(member.begin(), member.end()) [snip] > > Looks as though it should be source.begin() but that doesn't compile either: > [snip] > There are also zillions of warnings I've fixed the error you spotted. I also changed the code to use the new iterator adapters. I was not able to reproduce all your warnings, however. I've included an MSVC 7.1 project in the build directory (you'll have to adjust the include path for boost.) Please let me know if you still have trouble. > > Suggestions? > > It would be nice if a working example of a filter was provided too - perhaps one > of the James Kanze examples like 'expand tabs to spaces'. Or is this an > exercise for the student? > You're right. Good industrial strength examples would be compressing with zlib or some serious XML formatting, which I have been thinking of providing. I'll try to put up some simple examples soon -- possibly translations of some of Kanze's examples. I'll also write a test program which uses all the library features, to catch most of the errors like the one you found (I don't see how I was ever able to compile the test.) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Revised streambuf library
"Maxim Egorushkin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Jonathan David Turkanis" <[EMAIL PROTECTED]> wrote in message > ... > > ... You just call new_source or new_sink > > with whatever object you want to make into a source/sink. This is less > > verbose than using, e.g., streambuf iterators. ... > I agree. This is just a matter of taste. I would prefer to write more > generic adapter classes and a bunch of factories. Are you suggesting factories like new_streambuf_source? This sounds okay. I prefer sticking with new_source and new_sink, because it is less typing :-). At any rate, I realize you were right that my adapters contained unnecessary duplication. I rewrote istream_source et al. to make them derive from the iterator-based adapters. Now they just consist of some typedefs and simple inline constructors. Thanks, Jonathan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Revised streambuf library
A little over a month ago, I posted a library for creating streambufs from objects with socket-like interfaces. In response, several people requested filtering capabilities, and others have since posted filtering streambuf code (Larry Evans, Daryle Walker, Paul Bristow) and related material (Maxim Egoruskin.) I have posted a new version of my library, which has been rewritten to incorporate filtering as a basic construct. (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip) In addition to allowing the easy creation of streams and streambuf from objects with socket-like interfaces, it provides a convenient interface for defining i/o filters and for combining them in various ways with each other and with types from the standard library (streams, streambufs, containers, sequences, codecvts.) The library is now implemented as a collection of pluggable components. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in library generating streambufs
I was thinking about adding named template parameters at some point, but I thought it would make everything more complicated. I didn't realize how easy it is with mpl. "Maxim Egorushkin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Thread errors and vc7
"William E. Kempf" <[EMAIL PROTECTED]> wrote: > ...The warnings are known and will > be fixed soon. Ignore them for now. I have built the dll version of the threads library several times, with the mentioned warnings, which I ignore. However, once in a while I get one or two unamed errors (i..e., there is no C or LNK code associated with them.) The errors always reference . I delete all the compiler generated files, rebuild, hold my breath, and _usually_ there are no more errors. The library seems to work fine, but these errors make me very nervous. Jonathan Turkanis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Interest in library generating streambufs
Maxim Egorushkin wrote: > I posted here a while ago streambuf adapters. There was no any answer. May > be you might find it intresting. > > The main idea is simple: to present any linear sequence as > std::basic_streambuf<>. Yes, this is very elegant. No codecvt's in sight -- just pure adaptors. Also nice treatment of optional template parameters. It puts my design (and certain my implementation) to shame. I should have thought more about the general idea of composition before responding to posts. Repositioning may not be releavnt to the type of applications discussed (encryption, formating, etc.) but it is important sometimes and deserves a good general treatment. Also, the ability to add a putback buffer is useful. Yours (humbly), Jonathan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: interest in library generating streambufs
Robert Ramey wrote: >In the course of my work I had occasion to make a small family >of iterator adaptors for escaping/unescaping ascii text, and things >like that. I made the constuction interface so it could use >another iterator adaptor as a "source" thereby permiting me >to compose iterators in any sequence (sort of like unix pipes). > If there is any interest I will post this. > I wonder if one can't make a code_cvt facet >that would be constructed with an arbitray iterator adaptor. Sure, I would like to take a look at your adaptors. I've thought a little more about composition, and I think I see what your getting at. Composing streambufs is easy if the conversion facilities you want to use are expressed as codecvts. A wrapper around the code I posted could be used to generate streambufs like so: template struct compose { }; // Derives from basic_streambuf<.., ..> You could then chain this operation: compose > >. But the interface of std::codevt is complicated by the need to make the member functions const and pass the state as an argument, by the return codes, etc. If a simpler interfaces suffices most of the time this would be nice. I'm interested to see the interface of your iterator adaptors; particularly how general it is. Jonathan Turkanis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Interest in library generating streambufs from objects
Thanks for your interest. I have posted the library at http://groups.yahoo.com/group/boost/files/streambuf_lib/. The implementation needs to be streamlined, but it works, and the main ideas are clear enough. Robert Ramey wrote: > I think it would be more interesting if the following were considered > > a) composability - suppose I have an encryption facility and a > compression facility. I would like to be able to make a > streambuf the compresses thhen encryrpts or vice versa. ... > c) this suggests to me: > i) a implemention set of composable iterator adaptors. > ii) a streambuf that can filter input/output through an itererator adaptor. This > MIGHT be implemented as a codecvt facet that takes an interator adaptor > as an argument. ... > To summarize, I would like see the concept of "adaptable sequence" factored > out of streambuf and a streambuf built that can use any "adaptable sequence". This is good idea! I had thought about composing streambufs to create new streambufs, and indeed this seems fairly straightforward using my approach (perhaps the most difficult part is selecting suitable names for the composition operations -- how about 'operator+' ?) However, reworking the project in terms of iterator adaptors is a completely different story (I think.) Very interesting! Could you give a more detailed example? Jeff Garland wrote: >1) I'd be interested in how this fits with the Boost Socket initiative >http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket >2) I've written something similar for zip files, but looks like you may have >a more general solution -- a toolkit for creating new streambuf types. If >this is the case, it would be very handy. I'll have to look more closely at Boost Sockets (I've only read the requirements.) Also I will look at your compressed streams tonight. Thanks, Jonathan Turkanis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Interest in library generating streambufs from objects withsocket-like interfaces?
I have several class templates for producing standard streambufs based on classes with read, write and seek functions (or a suitable subset thereof.) I have used them successfully to access tcp connections, cryptographic routines, OLE compound documents, zip files, etc. There are templates istreambuf and ostreambuf which perform either input or output exclusively, a template double_streambuf which behaves like an istreambuf glued to an ostreambuf, and a template bidirectional_streambuf which performs input and output using a single shared buffer with a single repositionable file pointer. In addition, template parameters can be used to specify code conversion and to turn off buffering, and a contained error object can be used to customize exception throwing. I there is any interest, I will post them at the vault. Jonathan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost