[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: 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 treewindow treecontainer listwidget listentrystringstream, ... , ... , ... , ... myapplication; myapplication application; for_each(application.begin(), application.end(), print(uiout)); ___ 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
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] 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 stdexcept. 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
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:
templatetypename Codecvt, typename SrcOrSink
struct compose { }; // Derives from basic_streambuf.., ..
You could then chain this operation: composeCompress, composeEscape,
composeDecrypt, File . 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] 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
