Re: [gui] Concerning Scope (Was: thoughts on a GUI component library)
In-Reply-To: <20041224050911.GA9037@maribor.izzy.net> alan-boost@engrm.com (Alan Gutierrez) wrote (abridged):
I'm a bit concerned about the scope of this boost project. Our drawing framework is pretty huge.
This is an important discussion to have sooner than later.
1) Is a GUI project a bad idea?
2) Is Boost the right place for the a GUI project?
Supposing "yes" to both, that still leaves the question of scope. Possibly a "GUI" could just mean a high-level windowing system, and not a graphics drawing system. There is a lot to do just managing a tree of rectangles and dispatching events to and through them. The windowing system should arguably not care about the contents of the rectangles. It seems to me that adding a graphics system, with pens and brushes and polygons and text and bitmaps and wotnot, makes the project much bigger. Which isn't to say we shouldn't do it, and do all of it, but perhaps it is worth dividing it up into chunks or layers that are more or less independent. If that is possible.
I believe the time is ripe for a small, light-weight, XML + CSS renderer to attack the new surge of RSS content on the web.
OK. Perhaps my issue is that when I think of "GUI" I don't immediately translate that into "XML + CSS". -- Dave Harris, Nottingham, UK
* Dave Harris <brangdon@cix.compulink.co.uk> [2004-12-28 09:21]:
In-Reply-To: <20041224050911.GA9037@maribor.izzy.net> alan-boost@engrm.com (Alan Gutierrez) wrote (abridged):
I'm a bit concerned about the scope of this boost project. Our drawing framework is pretty huge.
This is an important discussion to have sooner than later.
1) Is a GUI project a bad idea?
2) Is Boost the right place for the a GUI project?
Supposing "yes" to both, that still leaves the question of scope. Possibly a "GUI" could just mean a high-level windowing system, and not a graphics drawing system. There is a lot to do just managing a tree of rectangles and dispatching events to and through them. The windowing system should arguably not care about the contents of the rectangles.
Supposing "no" to 1, and "yes" for 2, you mean? In another thread, I'm trying to drive home the point that the graphics needs are different for different platforms, indeed for different client area within the same program. An application might need a form bindery, another might be able to get by with only axis-aligned boxes, and another might require full compliment of vector graphics abstractions. I'm also trying to make the point that there is more to rendering than widgets on the one hand, and vector graphics on the other. I belive the scope is large, but if decomposed correctly, far more managable than what is currently available.
It seems to me that adding a graphics system, with pens and brushes and polygons and text and bitmaps and wotnot, makes the project much bigger. Which isn't to say we shouldn't do it, and do all of it, but perhaps it is worth dividing it up into chunks or layers that are more or less independent. If that is possible.
I agree completely! :^) Whew! In my thread on a GUI taxonomy, I came to see that it was really a rendering taxonomy. That a dialog is one way to render and hit test, a tree of rectangles, each containing a "component", a grid is similiar, but adds scrolling and selection. Both of these components can leave "visibility testing" to the windowing system, and focus on routing events. Rendering is clipped by rectangular view ports, so the overflow strategy is always clip or scroll, never reflow. A document reflows according to publishing convention. I might have a z-axis, so it might require visibility testing. A canvas is a collage of geographic shapes. It certialy requires it's own visibility testing. If I were to create a calendar for PalmOS, I might want to use forms and grids to arrange my information. I'd need axis-aligned boxes for rendering, but no ploygons, and no visibility testing. If I were to create an ER diagraming tool, I'd like to be able to draw on an vector graphics library that would let me compose shapes, and handle the visibility testing. I do not see how one is based off the other, and those libraries that model themselves in a heirarchy are destined to bloat. I think a Canvas is an abstraction that can be compiled out of many GUI applications. It is, to me, a rendering strategy that draws on a Surface, which is a software abstraction of a Device. A Surface class might provide line drawing, or it might provide ploylines, there could be a few classes of Surfaces, just like there are classes of Windows (modal, alert, SDI, MDI, etc.) Again, a very robust Palm OS application can bind to Palm OS form resources, and wouldn't require a Surface abstraction at all.
I believe the time is ripe for a small, light-weight, XML + CSS renderer to attack the new surge of RSS content on the web.
OK. Perhaps my issue is that when I think of "GUI" I don't immediately translate that into "XML + CSS".
I know. I don't think many people here do. I don't think XML+CSS, but I do think semi-structured content, like documents, and I'm putting forward XML+CSS as devil we all know. Also, XUL and XHTML make for nice declarative UIs. With C++, I feel you could create generic rednering compontents, Forms, Grids, Documents, and Canvases, and use generic programming to compose lean UIs. With C++ you can get the declaration and the behavior in the same langauge. You could compose UI renderers from generics, in the same way XUL is used to compose UI from nested XML elements and JavaScript. Talking about this application is to note it doesn't fit in this binary classifcation of widgets/vector graphpics. It is somewhere in between. ~ Also, I'm well aware that the G doesn't belong in the library name. In proper library I'd be able to model forms and documents on the console, just as I can now with curses and lynx. I think we are really talking about an event UI library. !~ In any case, I'm getting ready to wind down my participation in these discussions, because I don't think there is much interest here for a UI library, and I don't want to be accused of again hijacking, especially if I do make some progress on my own. I'll still be mucking around with Boost.Build and maybe that will be of some use to you all. -- Alan Gutierrez - alan@engrm.com
At 10:34 AM 12/28/2004, Alan Gutierrez wrote:
... !~ In any case, I'm getting ready to wind down my participation in these discussions, because I don't think there is much interest here for a UI library, ...
Be careful. Assessing interest is harder than it looks. (1) Because of the holidays, some of the boost regulars haven't been doing much posting. I know I've been totally distracted with non-boost activities, and didn't even check email for several days. (2) Even direct queries regarding interest in some library often draw responses from only three or four people. It isn't realistic to expect large numbers of responses unless a query is controversial. (3) Assessing interest based on responses to technical discussions may not be the best way. A separate message devoted only to the question of interest would be better. --Beman
* Beman Dawes <bdawes@acm.org> [2004-12-28 13:00]:
At 10:34 AM 12/28/2004, Alan Gutierrez wrote:
... !~ In any case, I'm getting ready to wind down my participation in these discussions, because I don't think there is much interest here for a UI library, ...
Be careful. Assessing interest is harder than it looks. (1) Because of the holidays, some of the boost regulars haven't been doing much posting. I know I've been totally distracted with non-boost activities, and didn't even check email for several days. (2) Even direct queries regarding interest in some library often draw responses from only three or four people. It isn't realistic to expect large numbers of responses unless a query is controversial. (3) Assessing interest based on responses to technical discussions may not be the best way. A separate message devoted only to the question of interest would be better.
Thank you for that explaination, it helps, so... I don't want to continue to participate if I'm off-topic. Do people feel that my line thinking is off-topic or beyond the scope of a user interface library? Does not a discussion of UI library design include a discussion of UI design? I don't see that anyone shares my thinking, so I feel like I'm only distracting this group from what it wants to accomplish, which is different from what I'd like to accomplish. I'm hearing that UI design is off topic, and I think that is plain wrong. If in the end I'm implementing similar ideas, with a different focus, I don't want to generate ill-will. I'd like to continue to participate in the UI discussion, to see if anyone returning in January is similiarly directed, but in the mean time, I'm setting up my own work environment so I can play around with UI Design Patterns. If this is a conflict of interest tell me now. -- Alan Gutierrez - alan@engrm.com
Alan Gutierrez wrote:
!~ In any case, I'm getting ready to wind down my participation in these discussions, because I don't think there is much interest here for a UI library
You must be kidding?! I haven't seen interest like this in any library idea since the serialization library review (which probably drew as much interest as Boost.Threads)! Years and years ago I suggested we work on a GUI library, and the reaction was generally negative. Things have apparently changed a *lot* since then.
and I don't want to be accused of again hijacking,
I hope I didn't give the impression of accusing. Your posting gave the impression that you might be planning something like that, and I wanted to head off the possibility. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
!~ In any case, I'm getting ready to wind down my participation in these discussions, because I don't think there is much interest here for a UI library, and I don't want to be accused of again hijacking, especially if I do make some progress on my own.
To echo the sentiments of several other replies, I think it would be a shame to drop this. I'm extremely interested in using whatever may come out of the effort and am interested in helping if I can. There have been some interesting exchanges so far - lots of good ideas. Personally I think it would be useful to complete the proposed survey of existing GUI libraries in order to answer a few key questions before getting too wrapped up in debating implementation details. I've gone through the "On the shoulders of giants" thread and extracted all the suggested links (I think) and collected them on a new page on the Boost Wiki that I hope will help keep this moving forward. Also, I've proposed some broad discussion headers. See: http://tinyurl.com/5jexr (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostGUI) I'm really way too busy to even get involved at all. But, I'll be happy to participate in a discussion about which points specifically to address as part of the survey and have signed myself up to write summaries for the Windows Template Library (WTL). Maybe we can get some experts in some of the other libraries to volunteer to complete portions of the survey? Please hack the Wiki up as you see fit. HTH - Chris
Dave Harris wrote:
In-Reply-To: <20041224050911.GA9037@maribor.izzy.net> alan-boost@engrm.com (Alan Gutierrez) wrote (abridged):
I'm a bit concerned about the scope of this boost project. Our drawing framework is pretty huge.
This is an important discussion to have sooner than later.
1) Is a GUI project a bad idea?
2) Is Boost the right place for the a GUI project?
Supposing "yes" to both, that still leaves the question of scope. Possibly a "GUI" could just mean a high-level windowing system, and not a graphics drawing system. There is a lot to do just managing a tree of rectangles and dispatching events to and through them. The windowing system should arguably not care about the contents of the rectangles.
This is the approach that I am using by placing the focus on a native implementation.
It seems to me that adding a graphics system, with pens and brushes and polygons and text and bitmaps and wotnot, makes the project much bigger. Which isn't to say we shouldn't do it, and do all of it, but perhaps it is worth dividing it up into chunks or layers that are more or less independent. If that is possible.
The main question is what to do when the two overlap. This can occur: 1. When performing size calculations, such as working out the minimum size for a button. 2. When defining the drawing events (i.e. specifying the canvas). 3. When placing bitmaps/images in widgets such as buttons. 4. When performing metric type conversions for a specific device. I intend to keep the level of overlap to a minimum, but there are areas where it is impossible to prevent that overlap. For me, there are 4 parts to a Boost.GUI library: 1. The core library - platform independance and general types; 2. The component library - event management, components/widgets, frames and forms, layout managers, etc.; 3. The graphics core library - device and canvas, pens, fonts, brushes, etc.; 4. The high-level graphics library - lines, polygons, circles, etc.
I believe the time is ripe for a small, light-weight, XML + CSS renderer to attack the new surge of RSS content on the web.
OK. Perhaps my issue is that when I think of "GUI" I don't immediately translate that into "XML + CSS".
The XUL (XML+CSS) look of Firefox/Thunderbird is one type of widget layout construction. Having a simple set of widgets, layout managers and frame types allows for an XUL-style extension, but XUL should not be specific to the Boost.GUI library. XUL is a type of Form binding in that there is an XML description of the layout. This is complicated with the CSS because a CSS renderer is required, and the components need to be hand crafted to support the CSS processing. In order to do this, a large code base would be required. Regards, Reece
participants (2)
-
Alan Gutierrez -
Beman Dawes -
brangdon＠cix.compulink.co.uk -
Christopher D. Russell -
David Abrahams -
Reece Dunn