RE: [boost] Java style GUI in C++
Behalf Of David Turner Sent: Friday, 20 August 2004 3:32 AM To: boost@lists.boost.org Subject: RE: [boost] Java style GUI in C++
I am currently designing a GUI framework in C++ (initially targeting the Windows platform) that uses a model similar to that which Java uses in it's AWT and Swing libraries. Specifically:
[snip]
I would appreciate comments and ideas as to what people would like out of a GUI framework, especially one that will be multi-platform.
Boost-style C++ GUI library utilizing boost::signals and with a nice way of handling message loops:
Looks like a very nice conservative approach. I think you're wise to keep it simple and take a conservative c++ approach. Only trouble is it still feels like a lot of other things just shines a bit brighter and has cleaner lines. However I must say I've never seen a UI lib I've been happy with. Nor have I written one, or infrastructure that uses one, that I've been fond of. I find even 200 lines of code (not cxxgui) for a simple split windows file explorer-like interface scary, but the sad thing is that it is a great improvement over the norm. Some rambling thoughts on things I'd like to see are: 1. run-time and compile-time configurability, especially with some like compile time specification language like layout capability. There was some talk about this and some suggestions previously on this list. Marrying this to run-time would be interesting. Perhaps at compile time you can decide if there is an explicit handling method and if not call something with your source and event type that will dispatch. However this would lock you in at run-time if did this as a compile time metaprogramming thing that ending up optimizing to a function call equivalent but perhaps both options are appropriate... 2. reverse structural inheritance of events handler equivalents. Widgets are composed of other widgets. A window may handle the click, or prevent it, for a child. You can attach a handler for a named event at any point in the composition / structural hierarchy, it doesn't have to be the source, but is aware of it. Handling goes down the hierarchy to source. 3. get rid of the distinction between properties, events and methods. Consider a widget a functor with visual side affects. Consider it like a dataflow where properties being set, events and method calls are just messages coming into this node. Allows you to interpose handlers, recorders, do nice testing and all sorts. Draw backs are interoperability with initialization requirements of widgets. That is, some things are set at widget create time. But this might handled by avoiding by not changing such parameters and thus not needing to change, but if initialization only parameters of legacy components change, then destroy and recreate the component. 4. Structural context sensitivity, 4a inherit properties from your run-time structural parents, fonts, colours, whatever, perhaps from theme packages that are higher in the tree. The structural tree is used to find the appropriate handler for properties, events and methods (all one in the same) 4b Context sensitive addressing and sources. Just like event handling, property setting and method calls are sinks that are handled with structural sensitivity, sources, such as changing properties, data propagation flow out and can be addressed in a context sensitive manner. E.g. if you have a widget that is expecting an source for stock code, it should look up the structural hierarchy to find it, unless it is provided with an explicit mapping to a different source. Allow non UI components that can act as holders for properties (like a root blackboarding thingo (technical term) ) so that components can reflect context of non-parental nodes. 4c Context sensitive addressing. Want to be able to get the properties / sources of siblings, i.e. children of parents of yours. "Instrument" -> "maturity". You find the parent and then lock into its context for a piece of detail. 5. must be multiplatform, leveraging off something like wxwidgets like notus does for its implementation layer would probably be a good idea. 6. must have a wysiwyg designer (though I could live without it) (self hosting would be a neat goal) - integrating the compiler into this and being an ide would be nice - perhaps something like eclipse could help 6a Because of the run configurability of everything there is nothing to stop external descriptions of components, including the mapping of sources to sinks to capture most of the requirements. Obviously where code is needed you need code and an xml resource description will not help. 7. Should support run time type conversions to allow easy hooking up of stuff. Not sure how explicit or implicit this should be. A while ago I did something like this that also supported the dimensionality of the data so you could cut, slice and aggregate stuff easily between widgets. E.g. use the entire list, the selected items, etc... would take some kind of multidimensional iterator thing I guess. Allows some sophisticated run-time modelling capabilities. See the data in a grid, or a list control, a combo, .... With this kind of structure you should be able to compose widgets hierarchies that have awareness of the others around them and will have reasonable normal functionality without too much coding at all. Supporting this at run time as well allows you to have some nice drag / drop or otherwise dynamic configurability. Have some that get a list of strings, displays it in a list. Click on a list item and a chart and grid automatically updates. A detailed pane of items relevant to the first click docked at the side updates. The exit item in the menu does the default behaviour of shutting down the application. My goal is that this should be possible with out an enormous number of lines of code. Structurally specify it. Use context sensitivity, standardish workflows and data set handling / iterator capabilities to avoid code. Thwack custom events in where needed. Been thinking about this for years and have implemented various systems that do bits of this approach. Enough to know it works pretty well. It has always been too much work to chew on as a generic solution though... $0.005, Matt. Side issue: resizing / device independence. Problem with swing / wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen. This is often the issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel ( I really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize. Also for device independence you might be able to target a different device by using a capability set where controls map to other controls for that device, they just have to handle the same sources and sinks for their node, i.e. have the same conceptual support. Perhaps that be a nice level of indirection to solve problems. Use a tree control, grid or list or whatever, just don't specific which. The platform configuration maps in the explicit control. Is you use a more refined control that is not available on that specific platform, you can substitute a generic one based on a substitutability principle (like Liskov SP), or perhaps it is an error (perhaps the design can specific the functionality that must exist for the there to be no error). A thin client approach to this would be even nicer, separate the visual aspects from the data it refers to by protocol and/or method call so that interesting thin / thick / adaptive clients can be built. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hurd, Matthew wrote:
Behalf Of David Turner Sent: Friday, 20 August 2004 3:32 AM To: boost@lists.boost.org Subject: RE: [boost] Java style GUI in C++
I am currently designing a GUI framework in C++ (initially targeting the Windows platform) that uses a model similar to that which Java uses in it's AWT and Swing libraries. Specifically:
[snip]
I would appreciate comments and ideas as to what people would like out of a GUI framework, especially one that will be multi-platform.
Boost-style C++ GUI library utilizing boost::signals and with a nice way of handling message loops:
Looks like a very nice conservative approach. I think you're wise to keep it simple and take a conservative c++ approach. Only trouble is it still feels like a lot of other things just shines a bit brighter and has cleaner lines.
However I must say I've never seen a UI lib I've been happy with. Nor have I written one, or infrastructure that uses one, that I've been fond of.
Borland's C++ Builder was very nice, but of course it wasn't standard C++. VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
.
Borland's C++ Builder was very nice, but of course it wasn't standard C++.
True.
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity. I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
I donot understand what you mean by the last sentence. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
John Torjo wrote:
.
Borland's C++ Builder was very nice, but of course it wasn't standard C++.
True.
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity.
I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
I donot understand what you mean by the last sentence.
In the sense that one has to do work at run-time when it could be done at design time. Please notice I said 'most', not all. If you, or anyone else, could come up with a RAD C++ GUI development environment which works with 98%+ conforming C++ compilers ( Como, gcc, VC++ 7.1, Intel etc. ) and enables one to easily set properties and events at design time, ala C++ Builder and Managed C++/.NET, I would be very interested in it and would contribute to it any way that I can if I liked the design. By GUI I also means the sort of components ( properties and events along with traditional C++ method-based programming ) which are supported by C++ Builder and Managed C++. I think non-visual components are also very important and should be available for design time configuration just as much as visual components in such a GUI environment.
[This assumes I understand what you are refering to with the term "design time"...]
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity.
I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
This can be handled by the FOX library _now_. If a widget is capable of handling the incoming event, then it does handle it, otherwise the event just propogates its way back up with widget tree, or it doesn't get handled. It works because it uses message maps which are statically defined (-> they are a design time constraint) -> no need for reflection - either the widget has a handler for the event in its message map, or it doesn't.
easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
I donot understand what you mean by the last sentence.
In the sense that one has to do work at run-time when it could be done at design time. Please notice I said 'most', not all. If you, or anyone else, could come up with a RAD C++ GUI development environment which works with 98%+ conforming C++ compilers ( Como, gcc, VC++ 7.1, Intel etc. ) and enables one to easily set properties and events at design time, ala C++ Builder and Managed C++/.NET, I would be very interested in it and would contribute to it any way that I can if I liked the design. By GUI I also means the sort of components ( properties and events along with traditional C++ method-based programming ) which are supported by C++ Builder and Managed C++. I think non-visual components are also very important and should be available for design time configuration just as much as visual components in such a GUI environment.
FOX has most of this already, simply because you can _only_ set your properties and event at design time, ie: a widget cannot automagically handle new types of events. However you can use either inheritance or event dispatch to extend the widgets' capabilities - but again only at design time. Mathew
Mathew Robertson wrote:
[This assumes I understand what you are refering to with the term "design time"...]
By design time I mean an environment which occurs before the module is executed within a process on an OS, during which one can set properties and events ( event handlers ) for "components". The "components" are then usually created automatically at run-time, their properties are set to values and their events are hooked to event handlers in other "components" which are usually automatically created at run-time. Ideally one should be able to create components, and set properties and event handlers for components at run-time as well.
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity.
I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
This can be handled by the FOX library _now_. If a widget is capable of handling the incoming event, then it does handle it, otherwise the event just propogates its way back up with widget tree, or it doesn't get handled.
It works because it uses message maps which are statically defined (-> they are a design time constraint) -> no need for reflection - either the widget has a handler for the event in its message map, or it doesn't.
I will take a look at it, but message maps do not ring a positive bell with me. Nonetheless my mind is open.
Edward Diener wrote:
John Torjo wrote:
.
Borland's C++ Builder was very nice, but of course it wasn't standard C++.
True.
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity.
I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My
You can emulate "design time". This is what both C++ Builder/ .Net do. You set an event at design time, but behind the scenes, a new event handler is created. Now, you can easily set event handlers at compile time. It'll get even better (look out for CUJ November issue ;)). Having said that, you only need to come up with a wizard that understands what events can be generated for a dialog, and make sure you can edit them. Not very complex, especially knowing how easily you can parse a C++ file for win32gui events.
view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
I don't think you'd want any component to catch events generated by any other component. What I think you'd like is: handle on a dialog, any notification coming from its controls. If the dialog does not/cannot handle this notification, propagate it up the chain (dialog's parent, grand parent, etc.). This is how win32gui handles events right now. And I think this is how C++ Builder/.net handles events as well.
easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
I donot understand what you mean by the last sentence.
In the sense that one has to do work at run-time when it could be done at design time. Please notice I said 'most', not all. If you, or anyone else, could come up with a RAD C++ GUI development environment which works with 98%+ conforming C++ compilers ( Como, gcc, VC++ 7.1, Intel etc. ) and
So far win32gui works for como, gcc, vc71. I intend to port it to other *modern* compilers as I have the time. But I think this will be most likely 3-5 months from now.
enables one to easily set properties and events at design time, ala C++ Builder and Managed C++/.NET, I would be very interested in it and would contribute to it any way that I can if I liked the design. By GUI I also means the sort of components ( properties and events along with traditional C++ method-based programming ) which are supported by C++ Builder and Managed C++. I think non-visual components are also very important and
It'll be possible. Also - I plan to allow it 3-4 months from now. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
John Torjo wrote:
Edward Diener wrote:
John Torjo wrote:
.
Borland's C++ Builder was very nice, but of course it wasn't standard C++.
True.
VC++ Managed C++ .NET is very nice but it is even further away from standard C++. In neither do you have to write hundreds of lines of code to do any GUI programming of significance. In order to have a really top-rate C++ GUI library I believe one needs reflection in C++ in order to do the sort of
Not true. It would be great if you had reflection, but it's not a necessity.
I'll show you (in about 3-4 months) that you don't need reflection to set GUI properties at design time. It'll be just like VB, but only better ;)
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My
You can emulate "design time". This is what both C++ Builder/ .Net do. You set an event at design time, but behind the scenes, a new event handler is created.
That is true, but there is the ability to create properties and event handlers before the program is running in a visual design time environment. That is why I believe one needs reflection in C++ in order to do this. While you are right that the design time environment is able to write code in files in order to create the handler, which the programmer will then fill in himself with whatever functionality he chooses, there is more to it. The design time environment must also hook the event handler to the event when the objects encapsulating the event and the event handler are created at run-time. In C++ Builder this is done by actually writing strings to a resource file, which afterward gets read in at run-time and, through reflection implemented as an extension to C++, the event handler and the event source are hooked together. In .NET, whose inner workings I understand less, I am pretty sure the same technique is being used but with .NET attributes holding special information which then works at run-time to hook handlers to events via delegation. Delegation is built into the .NET run-time as is reflection. Without run-time reflection in .NET I doubt this can be done, but I could be wrong. I know much can be done through boilerplate code, so it is possible that all the code to do this could be done by a design-time environment which creates enough code to make this automatically work at run-time. But even in this latter case, I think that run-time reflection makes a much cleaner environment in which to bridge the gap between a design-time/run-time environment than does boilerplate code.
Now, you can easily set event handlers at compile time. It'll get even better (look out for CUJ November issue ;)).
I understand this possibility and applaud your work, but it still is not design time programming ( yet ).
Having said that, you only need to come up with a wizard that understands what events can be generated for a dialog, and make sure you can edit them. Not very complex, especially knowing how easily you can parse a C++ file for win32gui events.
See above. Perhaps the wizard can produce the correct code without reflection, as you hope to prove. I look forward to seeing how you get it done via templates.
view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
I don't think you'd want any component to catch events generated by any other component. What I think you'd like is: handle on a dialog, any notification coming from its controls. If the dialog does not/cannot handle this notification, propagate it up the chain (dialog's parent, grand parent, etc.).
I heavily disagree with this model. That's MFC/OWL and I would guess plenty of other GUI environments, and it is old. There is no reason why any component shouldn't be able to hook events.
This is how win32gui handles events right now.
And I think this is how C++ Builder/.net handles events as well.
You are completely wrong on this last point. Any C++ Builder component can hook an event ( called a __closure ). Any .NET component can hook an event ( called a delegate ). I am not trying to put down what seems to be your excellent work in any way, but you are conceptually following a model for event generation/event handling which has been superceded IMHO. If you like that model, fine. But I want to point out to you that a much better model, and much more in the spirit of C++, is to allow any functor to handle an event. And of course boost::signal<> is built around this idea. If your events are multi-casting, which I am sure they must be, there is no reason putting limitations on who can handle them unless you are using a means of event generation which is in itself restrictive in what it can do. All you end up doing is making programmers who want to use your GUI angry that they must find workarounds for event handling for many cases for which you haven't yet conceived.
easy RAD programming which C++ Builder and Managed C++ .NET provide. Needless to say, both use extensions to C++ to do reflection. This is not a knock on any of the GUI libraries mentioned, but after using C++ Builder and Managed C++ .NET, even despite their non-C++-isms, most C++ GUI libraries are very primitive by contrast.
I donot understand what you mean by the last sentence.
In the sense that one has to do work at run-time when it could be done at design time. Please notice I said 'most', not all. If you, or anyone else, could come up with a RAD C++ GUI development environment which works with 98%+ conforming C++ compilers ( Como, gcc, VC++ 7.1, Intel etc. ) and
So far win32gui works for como, gcc, vc71. I intend to port it to other *modern* compilers as I have the time. But I think this will be most likely 3-5 months from now.
Sounds great ! I look forward to reading more about it.
enables one to easily set properties and events at design time, ala C++ Builder and Managed C++/.NET, I would be very interested in it and would contribute to it any way that I can if I liked the design. By GUI I also means the sort of components ( properties and events along with traditional C++ method-based programming ) which are supported by C++ Builder and Managed C++. I think non-visual components are also very important and
It'll be possible. Also - I plan to allow it 3-4 months from now.
Good luck !
I am very interested in this and would like very much to see how you will do this at design time. In particular I am interested in how event handlers can be set at design time. All without C++ reflection of course and using strictly the C++ standard, since you are confident that this can be done. My
You can emulate "design time". This is what both C++ Builder/ .Net do. You set an event at design time, but behind the scenes, a new event handler is created.
That is true, but there is the ability to create properties and event handlers before the program is running in a visual design time environment. That is why I believe one needs reflection in C++ in order to do this. While you are right that the design time environment is able to write code in files in order to create the handler, which the programmer will then fill in himself with whatever functionality he chooses, there is more to it. The
Yup, you are right. Here's what I'll do (of course, in about 3-4 months :D) At run-time, you can register your own "design-time properties" (in addition to the predefined ones). So, all you need to do, in order for your properties to be known to the UI designer, is to run your program once. That's it!
design time environment must also hook the event handler to the event when the objects encapsulating the event and the event handler are created at run-time. In C++ Builder this is done by actually writing strings to a
that is not complicated. See how win32gui handles events now, and also, stay tuned for the CUJ November issue ;)
resource file, which afterward gets read in at run-time and, through reflection implemented as an extension to C++, the event handler and the event source are hooked together. In .NET, whose inner workings I understand
No need - again, see how win32gui handles events right now.
I know much can be done through boilerplate code, so it is possible that all the code to do this could be done by a design-time environment which creates enough code to make this automatically work at run-time. But even in this
No, no need for that. Besides, I hate boilerplate code - maintenance nightmare.
Now, you can easily set event handlers at compile time. It'll get even better (look out for CUJ November issue ;)).
I understand this possibility and applaud your work, but it still is not design time programming ( yet ).
I'll be - pretty soon ;)
view of event handlers is that any "component" ( see below ) within such a system should be capable of handling any event generated by any other component; which is true of both C++ Builder and Managed C++/.NET.
I don't think you'd want any component to catch events generated by any other component. What I think you'd like is: handle on a dialog, any notification coming from its controls. If the dialog does not/cannot handle this notification, propagate it up the chain (dialog's parent, grand parent, etc.).
I heavily disagree with this model. That's MFC/OWL and I would guess plenty of other GUI environments, and it is old. There is no reason why any component shouldn't be able to hook events.
Please explain "hook events".
This is how win32gui handles events right now.
And I think this is how C++ Builder/.net handles events as well.
You are completely wrong on this last point. Any C++ Builder component can hook an event ( called a __closure ). Any .NET component can hook an event
Do you mean "respond to an event"?
( called a delegate ). I am not trying to put down what seems to be your excellent work in any way, but you are conceptually following a model for event generation/event handling which has been superceded IMHO. If you like that model, fine. But I want to point out to you that a much better model, and much more in the spirit of C++, is to allow any functor to handle an event. And of course boost::signal<> is built around this idea. If your events are multi-casting, which I am sure they must be, there is no reason putting limitations on who can handle them unless you are using a means of event generation which is in itself restrictive in what it can do. All you end up doing is making programmers who want to use your GUI angry that they must find workarounds for event handling for many cases for which you haven't yet conceived.
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;) Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
On Wed, 25 Aug 2004 12:08:21 +0200, John Torjo <john.lists@torjo.com> wrote:
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets. Have a nice way of name/referring to things in a relative sense to support re-composing without drama. This gives a way of addressing nodes. Sometime referred to as subject addressing. Needs to support implicit or explicit wild cards. Each node has sources and sinks. Read a property by attaching to the source. Write a property by sending a value to a sink. Calling a method is sending a property to a sink. Events handlers attached to items in the hierarchy. The event handler should be at the source node or higher in the hierarchy. An event handler is propagated down the composition hierarchy until it reaches a handler. That handler may allow the propagation to continue. Also method call equivalents, sending a message to a sink at a particular level, could be propagated down the hierarchy. For example, setting a font for all composed items. So there is a work flow between nodes a bit like the intensional style of programming with clocks. The structural composition adds a richness in allowing events to be handled at many sites and methods to have greater context. Add the context of getting a property from any parent, what is my parent font, colour, stock symbol, warehouse location and you end up with a richness of contextually aware widgets that can be composed with limited programming. This conceptual framework for me forms a significant aspect for the basis for an ideal gui. Most gui frameworks kind of work in this manner to some extent. On cross platformness... a thought: Wrapping widgets to be nodes in this framework can give you portability. Have different levels of specialization for the widgets to support more refined aspects improves functionality but makes it more difficult to support on many platforms. I can imagine having a standard for a grid, say different levels, level 0 supports setting string values all of the same font in two d structure with control over fonts, level one adds row and column labels, level two support has sorting on clicking on labels, etc... specific controls will support different generic levels plus their own specialities. A standardisation should exists for the differing levels of controls. Perhaps levels is the wrong approach, perhaps aspects and combining aspects (as per policies) is a better way of thinking of this. Supports interfaces / aspects / concepts (A,B,E,F for grids) plus these custom things on Panther... A boost ui framework needs to define a lot of interfaces / aspects for common properties, events and methods for various type of widgets. Special interfaces not supported on a different platform should still compile with a different widget that is less or more capable, perhaps with appropriate warnings, if the functionality does not make the program incorrect. What makes a grid a grid and is a must have... What other aspects do grids commonly have, etc... Another key would be iterator-like support for collections that widgets refer to and for access to items, selections that widgets have the state of... $0.001 matt.
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets.
Have a nice way of name/referring to things in a relative sense to support re-composing without drama. This gives a way of addressing nodes. Sometime referred to as subject addressing. Needs to support implicit or explicit wild cards.
Each node has sources and sinks. Read a property by attaching to the source. Write a property by sending a value to a sink. Calling a method is sending a property to a sink. Events handlers attached to items in the hierarchy.
The event handler should be at the source node or higher in the hierarchy.
An event handler is propagated down the composition hierarchy until it reaches a handler. That handler may allow the propagation to continue.
Also method call equivalents, sending a message to a sink at a particular level, could be propagated down the hierarchy. For example, setting a font for all composed items.
So there is a work flow between nodes a bit like the intensional style of programming with clocks. The structural composition adds a richness in allowing events to be handled at many sites and methods to have greater context.
Add the context of getting a property from any parent, what is my parent font, colour, stock symbol, warehouse location and you end up with a richness of contextually aware widgets that can be composed with limited programming.
This conceptual framework for me forms a significant aspect for the basis for an ideal gui. Most gui frameworks kind of work in this manner to some extent.
One main problem with this is that (generally speaking) there are at more than one heirachy that needs to be maintained: 1. The parent-child window relationship (eg this is needed for setting font on all children, hiding all children, etc) 2. Tab-order relationship 3. Event propogation heirachy ...just to name a few. From the description above, point 2 is definately not handled. And points 1 and 3 seem to be considered the same thing, which (in practise) they arn't. [ Another heirachy could be needed to provide the ability to replay events - for testing. I have been involved in discussions which say that its just a matter of overlaying the test framework on top of the event propogation heirachy. There were technical discussions at to whether this would always work. ]
On cross platformness... a thought:
Wrapping widgets to be nodes in this framework can give you portability. Have different levels of specialization for the widgets to support more refined aspects improves functionality but makes it more difficult to support on many platforms. I can imagine having a standard for a grid, say different levels, level 0 supports setting string values all of the same font in two d structure with control over fonts, level one adds row and column labels, level two support has sorting on clicking on labels, etc... specific controls will support different generic levels plus their own specialities. A standardisation should exists for the differing levels of controls. Perhaps levels is the wrong approach, perhaps aspects and combining aspects (as per policies) is a better way of thinking of this. Supports interfaces / aspects / concepts (A,B,E,F for grids) plus these custom things on Panther...
wxWindows / wxWidgets has already tried this. The end result is that they now have a layer which implements the widgets non-natively, as well as wrapping native widgets. At compile time, you choose which method you want to use. Mathew
<mathew.robertson@redsheriff.com> wrote:
One main problem with this is that (generally speaking) there are at more than one heirachy that needs to be maintained: 1. The parent-child window relationship (eg this is needed for setting font on all children, hiding all children, etc) 2. Tab-order relationship 3. Event propogation heirachy
....just to name a few. From the description above, point 2 is definately not handled. And points 1 and 3 seem to be considered the same thing, which (in practise) they arn't.
I see tab ordering as a property, but I see your point. I can imagine plugging a composite component into a structure and accepting its children's tab ordering within the context of the parent tab ordering but allowing for the changing of it. Sure 1 and 3 can be arbitrary. Model-View is arbitrary. Thought keeping 1 and 3 together seems necessary to keep the ui simply composable. You can still support external items via sinks and sources. I think that to keep the component drag/droppable and composable within context, with a minimum of fuss and without too much explicit code to hook it up, you need it to be in the form of such a structural package. A more general model-view style can still be accomplished by having data items, "blackboards", higher in the hierarchy simply accept property changes and propagate them down to clients conceptually. This is framed conceptually, there is no reason why the links can't be explicit via boost::signal or some such. The implementation details can be quite different to the conceptual view. Perhaps allowing arbitrary mappings between things in the ui, like model-view allows, makes implies natural, what I call, blackboards (old ai term) at common parent levels which also determines "natural" cut points for sensible composability of the interface... At the end of the day I want to be able to add a stock charting doo-dad to a ui which a simple process of some_composition_point.add( new_ui< stock_chart_thingo>() ); it expects to "inherit" from its context stock information and its widgets will perform appropriately without additional information, including adopting the appropriate fonts etc... Allow for remapping of context... some_composition_point.alias("*.stock.close", "series.point"); some_composition_point.add( new_ui<generic_grapher>() ); A smarter gui might allow the dragging and dropping of components into composition points where they make sense... $0.02 matt hurd.
Mathew Robertson wrote:
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets.
Have a nice way of name/referring to things in a relative sense to support re-composing without drama. This gives a way of addressing nodes. Sometime referred to as subject addressing. Needs to support implicit or explicit wild cards.
Each node has sources and sinks. Read a property by attaching to the source. Write a property by sending a value to a sink. Calling a method is sending a property to a sink. Events handlers attached to items in the hierarchy.
The event handler should be at the source node or higher in the hierarchy.
An event handler is propagated down the composition hierarchy until it reaches a handler. That handler may allow the propagation to continue.
Also method call equivalents, sending a message to a sink at a particular level, could be propagated down the hierarchy. For example, setting a font for all composed items.
So there is a work flow between nodes a bit like the intensional style of programming with clocks. The structural composition adds a richness in allowing events to be handled at many sites and methods to have greater context.
Add the context of getting a property from any parent, what is my parent font, colour, stock symbol, warehouse location and you end up with a richness of contextually aware widgets that can be composed with limited programming.
This conceptual framework for me forms a significant aspect for the basis for an ideal gui. Most gui frameworks kind of work in this manner to some extent.
One main problem with this is that (generally speaking) there are at more than one heirachy that needs to be maintained: 1. The parent-child window relationship (eg this is needed for setting font on all children, hiding all children, etc) 2. Tab-order relationship 3. Event propogation heirachy
...just to name a few. From the description above, point 2 is definately not handled. And points
couldn't agree more ;) That's why in win32gui I hold a map of all windows. Then when you want to find some windows that match a criteria (like, children, descendants, having a certain type, etc.), you ask for them (find_wnd_range<>) and simply iterate them. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets.
already there ;) (in win32gui)
Have a nice way of name/referring to things in a relative sense to support re-composing without drama. This gives a way of addressing nodes. Sometime referred to as subject addressing. Needs to support implicit or explicit wild cards.
already there ;) See the function find_wnd (global) / find_wnd_range (global) / sub_wnd. You can find, for instance, descendants/children/siblings of a window - generically (all of them), or of a certain type (example: all edit controls).
Each node has sources and sinks. Read a property by attaching to the source. Write a property by sending a value to a sink. Calling a
too abstract. A certain node is a window. Based on its type, you can cast it to the desired type. Example: if it's an edit box, cast it to 'edit'. Then, use edit's properties.
method is sending a property to a sink. Events handlers attached to items in the hierarchy.
Yup, already there.
The event handler should be at the source node or higher in the hierarchy.
You attach an event handler to a certain control. Or more specifically, you create an event handler for a certain type of control. At runtime, all controls of that type are subclassed, and your event handler inserted there automatically.
An event handler is propagated down the composition hierarchy until it reaches a handler. That handler may allow the propagation to continue.
Also method call equivalents, sending a message to a sink at a particular level, could be propagated down the hierarchy. For example, setting a font for all composed items.
So there is a work flow between nodes a bit like the intensional style of programming with clocks. The structural composition adds a richness in allowing events to be handled at many sites and methods to have greater context.
This sounds so nice and abstract ;) However, I'm still missing concrete examples. IMO there are very few cases where you need to program this advanced. First of all, you should be able to handle an event that was sent to you. Then, eventually you can decide to send it to your parent, or whereever. Note that in the future win32gui will indeed allow dynamic binding of event handlers - that is, to be able to capture events sent from any widget. And as a side note, there is a much easier way to allow a property to be propagated down the hierarchy. For instance, you can have a special type, like cool_font, and you bind controls to it. Once you reset its value, it forwards it to all other controls - note that there's no event handling involved.
Another key would be iterator-like support for collections that widgets refer to and for access to items, selections that widgets have the state of...
note: find_wnd_range does return an iterator, which you can use to walk through various types of windows. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
John Torjo wrote:
I don't think you'd want any component to catch events generated by any other component. What I think you'd like is: handle on a dialog, any notification coming from its controls. If the dialog does not/cannot handle this notification, propagate it up the chain (dialog's parent, grand parent, etc.).
I heavily disagree with this model. That's MFC/OWL and I would guess plenty of other GUI environments, and it is old. There is no reason why any component shouldn't be able to hook events.
Please explain "hook events".
Be an event handler for a particular event. C++ Builder is single-cast so to be an event handler for an event was simply a matter of assigning one's object's member function to a __closure ( an extension which is dealt very neatly in standard C++ now using boost::bind ). Managed C++ .NET is multicast so one essentially "assigns" one's event handler to a delegate, which encapslates multicast events.
This is how win32gui handles events right now.
And I think this is how C++ Builder/.net handles events as well.
You are completely wrong on this last point. Any C++ Builder component can hook an event ( called a __closure ). Any .NET component can hook an event
Do you mean "respond to an event"?
Yes, if by that you mean have any type of function handle an event. In boost::signal<> this would be a slot, and boost::signal allows anything which can be a boost::function act as an event handler, which means an object's member function, a function object, or a global/static function.
( called a delegate ). I am not trying to put down what seems to be your excellent work in any way, but you are conceptually following a model for event generation/event handling which has been superceded IMHO. If you like that model, fine. But I want to point out to you that a much better model, and much more in the spirit of C++, is to allow any functor to handle an event. And of course boost::signal<> is built around this idea. If your events are multi-casting, which I am sure they must be, there is no reason putting limitations on who can handle them unless you are using a means of event generation which is in itself restrictive in what it can do. All you end up doing is making programmers who want to use your GUI angry that they must find workarounds for event handling for many cases for which you haven't yet conceived.
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
Here is a general example of what I mean. I have a class which needs to respond to some event in your system. The event may be something which usually happens to a visual widget, but my class may neither be a widget as you define it, or it may be a widget but a non-visual one. In good old-fashioned Windows and MFC, only a visual widget ( read "window" or "control" ) can respond to the event. So you follow this paradigm and my poor class, or widget, if you will, despite the fact that it needs to respond to an event for whatever reason, can no longer do so without doing some exotic tricks. Why ? Because you have established some arbitrary barrier, something like "only a embedded widget, or another type of related widget window" can respond to the event. Of course there are no doubt tricks, such as have been used in Windows from time immemorial to get around such limitations, ie. creating a dummy window of the correct kind and doing god knows what other silly but necessary things. But why bother to create such a system with such limitations. When I say respond to some event I almost always mean that my event handler ( or slot if you like that term ) will invariably just be notified that a particular event has occurred, and will do something accordingly within itself. Yes, I understand that many events have responses which change the nature of the visual actions drastically, and that you may feel that you do not want to allow certain classes/widgets to do so, but there is still no reason for such a limitation even in this case. C++ was created to give the programmer maximum control and maximum responsibility. You should honor that design. If the user of your GUI library wants to shoot himself in the foot by having some weird class handle an event in a way that does something really idiotic, let him. Putting up barriers such as, "I think that only X,Y, and Z class member functions should be able to handle this event" is nonsensical. With boost::signal<> allow any class to handle an event. If you want to maintain control internally you can use boost::signal<> easily enough so that your handler is the first to handle an event and can short-circuit everyone else. But don't limit what can handle events or not to the outside user. Here is a real-world situation from my own programming, but because I am still working on the idea and it may be a product for which I charge someday, I will give the minimum information. I have a non-visual class ( or component if you will in certain RAD environments ) which needs to handle the possible OS change of locale by an end user. It turns out that for a particular OS for which I am programming, the message which denotes the change of locale is only sent to a top-level window of a process. So my non-visual component is forced to do some elaborate tricks to handle this message. In an OOP GUI system, built on events/handlers ( or signals/slots ), the system can catch the message and have an event for it which is signaled each time the message occurs with the appropriate parameters being passed. In such a system if it is decided that "only other windows and other specialized window-like widgets" can handle the event, I am back in square 1. But a truly great system says "anyone function, ie boost::function<>, can handle this event" and it is a breeze for my class/component to do so. Why not make that type of system for your end-user rather than the type which has already existed and caused endless programmers to waste their time figuring out how to work around its idiotic limitations. Edward Diener
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
Here is a general example of what I mean. I have a class which needs to respond to some event in your system. The event may be something which usually happens to a visual widget, but my class may neither be a widget as you define it, or it may be a widget but a non-visual one. In good old-fashioned Windows and MFC, only a visual widget ( read "window" or "control" ) can respond to the event. So you follow this paradigm and my poor class, or widget, if you will, despite the fact that it needs to respond to an event for whatever reason, can no longer do so without doing some exotic tricks. Why ? Because you have established some arbitrary barrier, something like "only a embedded widget, or another type of related widget window" can respond to the event. Of course there are no doubt tricks, such as have been used in Windows from time immemorial to get around such limitations, ie. creating a dummy window of the correct kind and doing god knows what other silly but necessary things. But why bother to create such a system with such limitations.
When I say respond to some event I almost always mean that my event handler ( or slot if you like that term ) will invariably just be notified that a particular event has occurred, and will do something accordingly within itself. Yes, I understand that many events have responses which change the nature of the visual actions drastically, and that you may feel that you do not want to allow certain classes/widgets to do so, but there is still no reason for such a limitation even in this case. C++ was created to give the programmer maximum control and maximum responsibility. You should honor that design. If the user of your GUI library wants to shoot himself in the foot by having some weird class handle an event in a way that does something really idiotic, let him. Putting up barriers such as, "I think that only X,Y, and Z class member functions should be able to handle this event" is nonsensical. With boost::signal<> allow any class to handle an event. If you want to maintain control internally you can use boost::signal<> easily enough so that your handler is the first to handle an event and can short-circuit everyone else. But don't limit what can handle events or not to the outside user.
Now I see your point. I still think there are rare cases for this ;) Yes, win32gui will allow it. As I think about it now - from December CUJ issue ;) You can bind an event handler to any window in your hierarchy of windows. I wanted to add this feature in the beginning, but then changed my mind. Anyway, it'll be there ;) Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
Some rambling thoughts on things I'd like to see are:
1. run-time and compile-time configurability, especially with some like compile time specification language like layout capability. There was some talk about this and some suggestions previously on this list. Marrying this to run-time would be interesting.
Perhaps at compile time you can decide if there is an explicit handling method and if not call something with your source and event type that will dispatch. However this would lock you in at run-time if did this as a compile time metaprogramming thing that ending up optimizing to a function call equivalent but perhaps both options are appropriate...
that's more or less what win32gui does. And more to the point, when you extend a window class, you can add your own handlers into the picture. Thus, you can end up with more event handlers for the same event/command/notificiation. This is TOTALLY ok. Whenever a handler for an event/command/notification gets called, it can decide what to consider this event: - event_not_handled: I consider this handler did not handle this event. If more handlers exist, call them. If no more handlers, call default (in our case, DefWindowProc) - event_is_handling. I did handle his event, but it's ok if other handlers handle it too. So, if there are other handlers, call them too. After all handlers are called, DO NOT call default (in our case, DefWindowProc). - event_handled: I handled this event. DO NOT call other handlers, nor the default( DefWindowProc). I thinks this handles most (if not all) cases.
2. reverse structural inheritance of events handler equivalents. Widgets are composed of other widgets. A window may handle the click, or prevent it, for a child. You can attach a handler for a named event at any point in the composition / structural hierarchy, it doesn't have to be the source, but is aware of it. Handling goes down the hierarchy to source.
In fact, I think it should be quite reversed. If a window cannot handle a command/notification, forward it to its parent and so on - until someone handles it or reaches top.
3. get rid of the distinction between properties, events and methods. Consider a widget a functor with visual side affects. Consider it like a dataflow where properties being set, events and method calls are just messages coming into this node. Allows you to interpose handlers, recorders, do nice testing and all sorts.
That is such a funny thing. That's exactly what Win32 API does with its messages. However, I think a wrapper over is quite ok.
4. Structural context sensitivity,
4a inherit properties from your run-time structural parents, fonts, colours, whatever, perhaps from theme packages that are higher in the tree. The structural tree is used to find the appropriate handler for properties, events and methods (all one in the same)
That would indeed be great ;)
4c Context sensitive addressing. Want to be able to get the properties / sources of siblings, i.e. children of parents of yours. "Instrument" -> "maturity". You find the parent and then lock into its context for a piece of detail.
If I understood correcly, you want to easily find siblings??? Easy with win32gui: find_wnd[<some_type>](some_wnd,search_siblings); example: // finds all sibling Edit boxes. find_wnd<edit>(some_wnd,search_siblings);
5. must be multiplatform, leveraging off something like wxwidgets like notus does for its implementation layer would probably be a good idea.
I don't agree with multiplatform for GUI. (note: I totally agree with multiplatform console applications) Of course, in an ideal world, yes - that would be the case. Every OS would have a similar GUI, etc. But our world is far from ideal. A lot of things are different from OS to OS - appearance, events, etc. Some features don't exist on a OS - what do you do? Do you either ignore that, or emulate it on all other OSs?
6. must have a wysiwyg designer (though I could live without it) (self hosting would be a neat goal) - integrating the compiler into this and being an ide would be nice - perhaps something like eclipse could help
Indeed. That would be great ;)
7. Should support run time type conversions to allow easy hooking up of stuff. Not sure how explicit or implicit this should be. A while ago I did something like this that also supported the dimensionality of the data so you could cut, slice and aggregate stuff easily between widgets. E.g. use the entire list, the selected items, etc... would take some kind of multidimensional iterator thing I guess. Allows some sophisticated run-time modelling capabilities. See the data in a grid, or a list control, a combo, ....
With this kind of structure you should be able to compose widgets hierarchies that have awareness of the others around them and will have reasonable normal functionality without too much coding at all. Supporting this at run time as well allows you to have some nice drag / drop or otherwise dynamic configurability.
Have some that get a list of strings, displays it in a list. Click on a list item and a chart and grid automatically updates. A detailed pane
Just a thought - I'll soon (hopefull on Tue ;)) finish save_dlg class - which allows binding of data to controls. Of course, it does not work for list view/tree view - this is way too complex for now. But time will come ;)
Side issue: resizing / device independence. Problem with swing / wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen. This is often the issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel ( I really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize. Also for device independence you might be able to target a different device by using a capability set where controls map to other controls for that device, they just have to handle the same sources and sinks for their node, i.e. have the same conceptual support.
That's exactly what the (Win32) Dialogs are for ;) One of the gooals (http://www.torjo.com/win32gui/goals.html) of win32gui is to increase dialog programming - so that you can set as many properties at design time.
Perhaps that be a nice level of indirection to solve problems. Use a tree control, grid or list or whatever, just don't specific which. The platform configuration maps in the explicit control. Is you use a more
Much like auto-mapping facility from win32gui ;) ? Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
"Hurd, Matthew" <hurdm@sig.com> wrote [snip]
Side issue: resizing / device independence.
IMO This isnt a side issue ;-) The problem of cross platform-ability would be fundamentally eased by a clean abstraction of the viewport(s) and separation of that concept from the concept of a device My own experience is strictly Windows, but from the sound of your following comments the lack of separation seems to be common. There are two common abstractions of a Viewport 1 A matrix of pixels 2 A (usually rectangular) area of a certain length and height. Generally speaking I would guess the one most used at the 'user level' is the second abstraction. The first is used as the 'device level' abstraction. Using the first abstraction at the user level, text displayed on a 640 * 480 pixel 'viewport' would be extremely difficult to read on a 1200 dpi laser printer. I would assume most apps e.g a standard browser construct a framework to achieve the second, so it seems a good candidate as a generic component. I think Windows eg MFC ATL couples the two abstractions in a DeviceContext, but the second abstraction is left very much up to the developer to construct, thought the bones are there in eg GDI. Notably though the DeviceContext must be informed about the user level abstraction. It cant figure this out for itself. Problem with swing /
wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen.
I think it is one of the first problems that hits you when designing a windowed application. A clear sign surely that the user level abstraction of the viewport in that application has not been considered. This is often the
issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel .
This sounds interesting but I dont fully understand it. Do you have a generic algorithm or work 'per device'? ( I
really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize.
Thanks.... I'm working on it . ;-) regards Andy Little
participants (3)
-
Andy Little -
Edward Diener -
Hurd, Matthew -
John Torjo -
Mathew Robertson -
Matt Hurd