RE: [boost] C++ GUI - another view
Andy Little wrote:
Recent discussions on boost have talked about GUI's in quite technical terms, windowing etc. Another part of the abstraction is simply that of providing an area for drawing on. The code below is a simple example of what I mean. The "drawFunction" is meant to be like a graphics version of a main() function .( Note that there should ideally be no DeviceHandle visible to the "drawFunction". The DeviceHandle should be wrapped in the GX object, passed to the function so some of the impl is poking through here in form of the gx.line_to etc functions 'hdc' argument. Its early days.)
Your code looks good, but here are a few comments: [1] The general impression from users of a GUI library is that they are against using a template-based library. [2] The DeviceHandle should be hidden via an interface and have an implementation for *nix, mac, Windows and others. [3] I strongly recommend that the graphical side (devices, pens, brushes, images, fonts, etc.) be separate from the GUI (windows/widgets, events, etc.). The GUI framework will make use of the graphics framework for drawing to a window's client area. [4] I like how you specify independant coordinates. Is this customizable (i.e. can you change between pixels, cm, inches, etc.) and can you convert between coordinate systems (e.g. when implementing a web browser, CSS units can be percentages, cm, pc, pt, etc.)? [5] Can you get the width and height of the drawing rectangle? Is it possible to create a scrolling view of a larger drawing area? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
"Reece Dunn" <msclrhd@hotmail.com> wrote
Andy Little wrote:
Your code looks good, but here are a few comments: [1] The general impression from users of a GUI library is that they are against using a template-based library.
I guess there are two issues here. The first and possibly most important is that users see that because things are fixed at compile time, that they cant change them at runtime. Frankly I dont know at the moment whether that will be an issue or not in practise, until I have played around some more. On the other hand it is interesting to find out how much that is thought of as runtime is actually compiletime. However the major concept here is that of achieving device independence by means of specifying dimensions (ie distances mainly) in absolute units. Essentially you (metaphorically) select the size of your drawing in some unit and then draw your lines etc on it in lengths. (The lengths in pqs perform conversions , so if you want to work in inches or meters, km or pica point you can. The example will work exactly the same conceptually if you convert all the lengths in mm to inches or whatever). The draughtsman is always working in so called "world coordinates".. (this is currently a 2D 'world). It is not up to the draughtsman , How that drawing is actually rendered on a device. Typically on the average display, the viewer of the drawing has dropdowns and scrollbars to adjust the actual scale and screen position of what has been drawn to whatever part is of interest. From the draughtsmans point of view they are literally independent of any worry about how to scale the drawing to a particular device and so on and so forth. And it might be a map of the universe or a VLSI logic circuit, but it is drawn at a scale of 1:1. The other concern may simply be the perceived complexity of templates. However if you review the code you will see that in the body of the function there is very litlle if any heavy template machinery, no more really than using (say) std::vector<T>. OTOH it might be useful to find out more detail about what the concerns of potential users are.
[2] The DeviceHandle should be hidden via an interface and have an implementation for *nix, mac, Windows and others.
Absolutely. Its early days. MFC/ ATL users may recognise 'HDC hdc; ' ;-)
[3] I strongly recommend that the graphical side (devices, pens, brushes, images, fonts, etc.) be separate from the GUI (windows/widgets, events, etc.).
Absolutely. On the issue of pens, brushes and so on, I am looking at this from another viewpoint. Typically when you want to draw a line, you want to specify a color and a thickness. So ideally a line is an object with a start point, end point, a colour and a thickness and eg dot dash (possibly a virtual "how to draw this line" function, end style: square or round etc, This gives it its own state independent of pens and so on, and also helps to make it persistent and eases combining primitives into larger more complex objects... all very OOP, but then OOP and GUIs grew up together. Similarly an area of text should have an absolute height and width and so on in pica point or mm etc as you prefer. But again no mention of any device to draw on here. The GUI framework will make use of the graphics framework for drawing
to a window's client area.
From the point of view of the above concept you have created a collection of objects in the drawing, which you can then point at a device (And here I see a windows 'window' as a device), eg via a graphics stream which then has to do the real work of figuring out how to render it. OTOH the 'device' could be a file,printer etc, while the drawing could be a file... very much like an ostream.
[4] I like how you specify independant coordinates. Is this customizable (i.e. can you change between pixels, cm, inches, etc.) and can you convert between coordinate systems (e.g. when implementing a web browser, CSS
units
can be percentages, cm, pc, pt, etc.)?
Yes anything from parsecs to nanometers, pica-point etc. However , in order to achieve device independence there should in theory be no concept of a pixel type at the "world layer". (This is actually simplifying. It is possible to use (say) double, (even) voltage-y, time-x etc, to draw in. The 'morph' functor demoed in the body of the drawFunction is also used to scale at the "world-view" layer described below, but this would require more template parameter exposure) I have separated the thing conceptually into three layers. At the top there is the world layer which is the one in which the drawing is done in 'world units' in relation to the world origin. "Living" in the world are world-elements which are objects with the attribute of a position in relation to the world origin. The "world-view" (which basically represents the user level viewport but in world units,) is just a world-element. ie it has a position in the world and can "wander about" about eg by scrolling in world units. Hence the world-view is a member of the world, but is also conceptually the second layer and is where scaling from drawing world" to "real-world" sizes is performed. The final layer is the viewport layer. This has a physical-size, but the size now is nominally 1:1 with the real world, so for a typical window it might be (say) 150mm by 100mm or whatever. This is a member of the world-view. So the (current) world-view size is then found by scaling the viewport size to world units. but obviously if the user changes the size of the viewport, this will change,as can potentially the size of a pixel. It is possible to draw objects at every layer, so for example if you draw at the "world-view" layer and then scroll, then what you have drawn will effectively remain where it is, if you get my meaning. Finally, at the viewport-layer Neither scaling Nor scrolling will change what you have drawn in relation to the viewport. Other requirements are probably a zoom origin so that zooming in on the world object at the "centre" of the viewport remains where it is , and so on. Note that the drawFunction in my original post does not need to know anything at all about these lower layers.
[5] Can you get the width and height of the drawing rectangle?
Assuming this is the "world" drawing rectangle, it can be set to whatever you wish, either fixed or expanding as elements are added to the "world" Is it
possible to create a scrolling view of a larger drawing area?
Yes, but from the point of view of this particular concept, which is a very simple one, that is a device dependent detail. However in practise to demonstrate the concept I am implementing scaling and scrolling in a windows app. Its currently being done in WTL but I may do a MFC version too. I would like to do a Linux version but will find that quite a hard road as I dont have experience on that platform. regards Andy Little
Andy wrote:
The other concern may simply be the perceived complexity of templates.
No, the *actual* complexity. Most "GUI" programmers happen to be quite junior, and templates are tricky. Types not consisting of one simple lexeme are complex. [And typedef's do not save that...] Not that very senior developers do not do GUI, but that is not their typical chores at a firm, and when they do they put themselves in "GUI mode," meaning that they often set aside their code aesthetics. Regular programmers cannot use templates more than via very simple patterns, such as smart pointers (actullay popularized via Microsoft's Active Template Library, I think), and they can certainly not create their own templates. I have interviewed about a hundred "expert C++ programmer" (from the resume...) of which three (3) had ever created his/her/its own template, and zero (0) had ever used either templates as template parameters or nested template instantiations. I would love to see a GUI library that is for those who have not only dipped their toe into the strange, but beautiful, waters of generic, and generative, programming, but for those who can actually swim in it. Ok, it would not get a "wide" appeal. So, what? If we looked for that, we already have a bunch of solutios to choose from. We have all used Tk, or wrappers thereof. Most of us have used Qt, I think. Note that the "wide" market does not care about platform-agnosticism. /David
"David Bergman" <davidb@home.se> wrote
Andy wrote:
The other concern may simply be the perceived complexity of templates.
No, the *actual* complexity. Most "GUI" programmers happen to be quite junior, and templates are tricky. Types not consisting of one simple lexeme are complex. [And typedef's do not save that...]
Regular programmers cannot use templates more than via very simple
Gee someone oughta sit down and write a book.. I dunno about ... erm metaprogramming and stuff. I guess that might help. Gee... but pigs might fly. These boosters just want to keep all this useful info to themselves. ;-) patterns,
such as smart pointers (actullay popularized via Microsoft's Active Template Library, I think), and they can certainly not create their own templates. I have interviewed about a hundred "expert C++ programmer" (from the resume...) of which three (3) had ever created his/her/its own template, and zero (0) had ever used either templates as template parameters or nested template instantiations.
Again I refer you to the code in my original post. There is really nothing complicated in the body of the function IMO. And you have to start somewhere. Give them a chance.... and who knows.
I would love to see a GUI library that is for those who have not only
dipped
their toe into the strange, but beautiful, waters of generic, and generative, programming, but for those who can actually swim in it. Ok, it would not get a "wide" appeal. So, what?
Somebody Stop Me! ... :-) regards Andy Little
David wrote:
Andy wrote:
The other concern may simply be the perceived complexity of templates.
No, the *actual* complexity. Most "GUI" programmers happen to be quite junior, and templates are tricky. Types not consisting of one simple lexeme are complex. [And typedef's do not save that...]
Not that very senior developers do not do GUI, but that is not their typical chores at a firm, and when they do they put themselves in "GUI mode," meaning that they often set aside their code aesthetics.
If it is true that most companies (mine doesn't) relegate GUI tasks to novices, I think it's a mistake to do so. Contrary to what many think, creating a good GUI is often one of the more complicated parts of a program - and the part of the program with which your customer will interact most. Current GUI programming tools facilitate easy creation of toy GUIs while at the same time hindering the creation of commercial grade applications and also hindering the use of more powerful code reuse mechanisms.
From what I've seen, when average programmers do create 'good' GUIs, they are one time Herculean efforts of will, labors of love, and maintenance nightmares. Without more expressive tools the creation of solid state GUIs will remain solely in domain of highly experienced programmers.
Regular programmers cannot use templates more than via very simple patterns, such as smart pointers (actullay popularized via Microsoft's Active Template Library, I think), and they can certainly not create their own templates.
A well designed library can facilitate the use of powerful template mechanisms without requiring the programmer to understand how they work. You can use Spirit, for instance, without understanding the intricate world of expression templates.
I have interviewed about a hundred "expert C++ programmer" (from the resume...) of which three (3) had ever created his/her/its own template, and zero (0) had ever used either templates as template parameters or nested template instantiations.
I'd agree with that. I'd say over half of the "C++ programmers" I interview can't tell me what the STL is! Brock
David Bergman wrote:
No, the *actual* complexity. Most "GUI" programmers happen to be quite junior, and templates are tricky. Types not consisting of one simple lexeme are complex. [And typedef's do not save that...]
Whoa, slow down there. :) Maybe GUI programmers that _you_ work with are junior and find templates difficult but that's certainly not the case where I work. I do a great deal of GUI coding and can certainly say that I'm comfortable using (and encouraging others to use) templates and generic coding techniques.
Regular programmers cannot use templates more than via very simple patterns, such as smart pointers (actullay popularized via Microsoft's Active Template Library, I think), and they can certainly not create their own templates. I have interviewed about a hundred "expert C++ programmer" (from the resume...) of which three (3) had ever created his/her/its own template, and zero (0) had ever used either templates as template parameters or nested template instantiations.
I hear you. But those kind of 'expert' claims aren't limited to GUI developers.
I would love to see a GUI library that is for those who have not only dipped their toe into the strange, but beautiful, waters of generic, and generative, programming, but for those who can actually swim in it.
I may not be a swimmer, but I can float with the best of them. ;) Seriously, I understand your wishes, but I only want generic/generative techniques used if it enhances the usefulness of the library.
Ok, it would not get a "wide" appeal. So, what? If we looked for that, we already have a bunch of solutios to choose from. We have all used Tk, or wrappers thereof. Most of us have used Qt, I think. Note that the "wide" market does not care about platform-agnosticism.
My perspective is waaay different. I want a cross platform GUI library that uses modern C++ techniques - where applicable - to give me the tools to create GUI applications quickly in a natural C++ syntax. I want something that has wide appeal, so many people use it and it becomes a _useful_ skill (and can find a valuable home on my resume). I have yet to find such a library [1]. And I'd be very willing to help develop one if enough momentum was thrown into it. Let me expand on that - I've seen quite a few GUI libraries started but, because it is such a large undertaking, many lose steam and development trickles to a standstill. I don't want to expend effort unless I'm confident there is support, I just don't have the time. Also, in my experience, your assumption that the wide market is satisfied with a platform specific solution is not valid. Andy, your "unitless" concepts are terrific, keep 'em coming. :) Having said that, first and foremost I want a library to provide me with 'normal' widgets, the 'canvas' comes secondary. Just my 2c! Cheers, Matt [1] Other GUI libraries and some of the issues I have with them: o Win32 Generics - Good work John, but it's not cross platform, an absolute requirement for me. I understand your argument that it's _much_ harder to create a cross platform library (and agree!) but I think it's far from impossible (we use an in-house cross platform library here at work). Personally, I'll avoid using a GUI library if it locks me into a platform, it's just not worth it. - It's also not that simple to use because you need intimate knowledge of Win32. Not a problem for me but it's a step backward IMO. o wxWidgets - One of the more developed libraries but it really needs an overhaul. Message map macros?? - Even though it has limitations it would still probably serve as my pick of the alternatives because it's quite deep, well documented and well supported. o Qt - I've done little development with Qt but it unnecessarily requires a pre-preprocessor (yes, I understand the reasons for moc - they were valid years ago but I don't believe they are any longer). - The sytax is, like wxWidgets, quite 'old school'. - Of course the Windows licensing is an issue. o Notus - Promising but over-templated IMO. - I clash with some of the design decisions (well, I did when I was keeping tabs on it). o WTL - Not cross platform. - Not effectively maintained. - Not effectively documented. o Win32 - Lots of issues. o MFC - See above. I've "played" with FLTK, FOX and GTKMM too and they all seem like reasonable libraries. But I haven't used them enough (and wasn't impressed enough) to comment further. If I should clarify any of the points please just ask... :)
[1] Other GUI libraries and some of the issues I have with them:
o Win32 Generics - Good work John, but it's not cross platform, an absolute requirement
Thanks
for me. I understand your argument that it's _much_ harder to create a cross platform library (and agree!) but I think it's far from impossible
Exactly ;) Making it cross platform would have made the time increase exponentially - I just don't have the time for that ;) <side-note> Especially if you add threading into the picture, implementation gets a lot harder. I should know ;) </side-note>
(we use an in-house cross platform library here at work). Personally, I'll avoid using a GUI library if it locks me into a platform, it's just not worth it. - It's also not that simple to use because you need intimate knowledge of Win32. Not a problem for me but it's a step backward IMO.
You do need some win32 knowledge. I'm working to make it as friendly as possible - and so that you will need as little win32 knowledge as possible. This is a definite long-term direction for me - and I'm doing it one step at a time ;) Also, partly is because of the lack of docs :( I should have the first docs ready by 10th of Oct. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4.0 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
John Torjo wrote:
Exactly ;) Making it cross platform would have made the time increase exponentially - I just don't have the time for that ;)
I understand, it's a shame, but I understand. :)
<side-note> Especially if you add threading into the picture, implementation gets a lot harder. I should know ;) </side-note>
Oh yes. There's no real escaping the fact that threading is _hard_. :(
You do need some win32 knowledge. I'm working to make it as friendly as possible - and so that you will need as little win32 knowledge as possible. This is a definite long-term direction for me - and I'm doing it one step at a time ;)
Also, partly is because of the lack of docs :( I should have the first docs ready by 10th of Oct.
Yeah, the lack of doco is an issue - and I'm pretty glad I've got a working knowledge of the win32 API while I read your CUJ articles! ;) But given that you've chosen to work on only one platform and tightly coupling it to win32, I think you're doing a great job with the library. :) Cheers, Matt
"Matt S Trentini" <matt_trentini@yahoo.com.au> wrote ...
Andy, your "unitless" concepts are terrific, keep 'em coming. :)
Thanks for the encouragement :-) Back in the 'good old days', before GUIs and multitasking os'es, drawing on the display was a simple process, with some form of move_to, line_to, fill etc primitives. I guess I am trying to simulate that approach as closely as possible. IOW C++ currently has standards for character stream output, so I'm thinking... why not a standard for graphics stream output also? I am not looking into embedding any intelligent objects in the 'canvas' to begin with, however I am trying to keep that in mind. The component approach of ATL/WTL is very interesting from that point of view, wherein you add your messaging by multiple derivation, combined with CRTP. This Might be a very useful mechanism to make dumb drawing objects intelligent. For example, if I had a dumb line, it should be possible to 'attach' a class that can detect if that line is being grabbed with the mouse and so on.
Having said that, first and foremost I want a library to provide me with 'normal' widgets, the 'canvas' comes secondary.
Well... If I were to do that (which I am not really considering, simply because I dont have the experience or knowledge and am currently looking into simple 'dumb' drawing primitives), I would make all dimensions (eg size of a window) in some unit eg millimetres rather than pixels . I guess I am trumpetting my physical-quantities library, but to be honest this was a major reason for starting the project. I implemented a millimetres type in a previous project and it made my life much easier. (The physical-quantities library is simply a huge sidetrack from solving that problem.) I just got fed up with device specific unit systems and now I would find it very difficult to go back to using floats or (gasp) ints for (at least 'client') dimensions. regards Andy Little
I am not looking into embedding any intelligent objects in the 'canvas' to begin with, however I am trying to keep that in mind. The component approach of ATL/WTL is very interesting from that point of view, wherein you add your messaging by multiple derivation, combined with CRTP. This Might be a very useful mechanism to make dumb drawing objects intelligent. For example, if I had a dumb line, it should be possible to 'attach' a class that can detect if that line is being grabbed with the mouse and so on.
Its an interesting idea - except that I personally think that all events should be available to be handled from the 'line', at runtime, so that you can dynamically hook up events. By 'attaching' the 'grab' property to a line, you have constrained the line to never being able to dynamically hook up a different type of event. The bigest issue that you will have with attaching events to a simple item, such as a line, is that there is a fundamental limit on the number of window handles available in the system - and this limit is quite low under win32. To implement this design, your canvas will have to synthesise events like MouseEnter, MouseLeave, etc regards, Mathew Robertson
The bigest issue that you will have with attaching events to a simple item,
such as a line, is that there is a fundamental limit on the number of window handles available in the system - and this limit is quite low under win32. [...]
Could you elaborate a bit? What do you think is the window handle limit under win32? Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
John Torjo wrote:
Could you elaborate a bit? What do you think is the window handle limit under win32?
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot. Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break. If you open task manager and select to view the "GDI Objects" column you can see how many objects each process uses. If you, or anyone else, wants some more info or help please let me know because it was quite a difficult nut to crack! Googling for "gdi object limit", particularly in groups, will reveal a heap of stuff. However, I've found only a few official documents that describe the issue. Cheers, Matt PS The last time I looked at your library John it didn't have a 'drawing canvas' object. It's typically through that kind of object (and those kind of drawing routines) that you'll run into issues. If you're only using native Windows widgets this GDI limit is unlikely to bother you. [1] Flashing objects, things draw in the wrong location etc.
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot.
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break.
If you open task manager and select to view the "GDI Objects" column you can see how many objects each process uses.
If you, or anyone else, wants some more info or help please let me know because it was quite a difficult nut to crack!
Googling for "gdi object limit", particularly in groups, will reveal a heap of stuff. However, I've found only a few official documents that describe the issue.
In practise the FOX GUI users group have found that the values are as low as a few thousand, or less if you are dealing with bitmaps. This may still sound like a lot, but if you are allocating a handle to every line on the display (plus any offscreen handles - eg caching a few hundred thumbnails), you can quickly run out. Mathew
Matt S Trentini <matt_trentini@yahoo.com.au> writes:
John Torjo wrote:
Could you elaborate a bit? What do you think is the window handle limit under win32?
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot.
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break.
Yes, IIRC, that's why a spreadsheet implemented with a Window per cell will have a very small maximum size, and why ultimately, any robust window framework under Win32 has to have an abstraction layer that makes the issue of whether or not there's a real "windows window" running the show in any given pane disappear. I personally wouldn't be interested in any Win32 GUI framework that couldn't do that, and once you've done it, you're well along the way to a portable framework so you may as well design the abstraction to be independent of the Win32 API altogether. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Matt S Trentini <matt_trentini@yahoo.com.au> writes:
John Torjo wrote:
Could you elaborate a bit? What do you think is the window handle limit under win32?
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot.
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break.
Yes, IIRC, that's why a spreadsheet implemented with a Window per cell will have a very small maximum size, and why ultimately, any robust window framework under Win32 has to have an abstraction layer that makes the issue of whether or not there's a real "windows window" running the show in any given pane disappear.
Why not just use an existing list control or grid? Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
John Torjo <john.lists@torjo.com> writes:
David Abrahams wrote:
Matt S Trentini <matt_trentini@yahoo.com.au> writes:
John Torjo wrote:
Could you elaborate a bit? What do you think is the window handle limit under win32?
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot.
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break. Yes, IIRC, that's why a spreadsheet implemented with a Window per cell will have a very small maximum size, and why ultimately, any robust window framework under Win32 has to have an abstraction layer that makes the issue of whether or not there's a real "windows window" running the show in any given pane disappear.
Why not just use an existing list control or grid?
You're not getting it; that's just one way to run out of handles. What if the existing list/grid controls don't do what I want? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
You're not getting it; that's just one way to run out of handles.
Yup, there are many more.
What if the existing list/grid controls don't do what I want?
yup, sorry. Got it now. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
PS The last time I looked at your library John it didn't have a 'drawing canvas' object. It's typically through that kind of object (and those
Not yet indeed. It will in the future (2-3 months from now).
kind of drawing routines) that you'll run into issues. If you're only using native Windows widgets this GDI limit is unlikely to bother you.
At this time - yet. There are very few places where I need to override drawing. And then, I use only native widgets. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
see this thread on the FOX GUI mailing list: http://sourceforge.net/mailarchive/forum.php?thread_id=5593128&forum_id=6292 Over the last few weeks there has been a discussion on the number of handles available - you would probably want to go back through some of those messages. Mathew
The bigest issue that you will have with attaching events to a simple item, such as a line, is that there is a fundamental limit on the number of window handles available in the system - and this limit is quite low under win32. [...]
Could you elaborate a bit? What do you think is the window handle limit under win32?
Best, John
Andy Little wrote:
"Matt S Trentini" <matt_trentini@yahoo.com.au> wrote ...
Andy, your "unitless" concepts are terrific, keep 'em coming. :)
Thanks for the encouragement :-)
Back in the 'good old days', before GUIs and multitasking os'es, drawing on the display was a simple process, with some form of move_to, line_to, fill etc primitives. I guess I am trying to simulate that approach as closely as possible. IOW C++ currently has standards for character stream output, so I'm thinking... why not a standard for graphics stream output also?
I am not looking into embedding any intelligent objects in the 'canvas' to begin with, however I am trying to keep that in mind. The component approach of ATL/WTL is very interesting from that point of view, wherein you add your messaging by multiple derivation, combined with CRTP. This Might be a very useful mechanism to make dumb drawing objects intelligent. For example, if I had a dumb line, it should be possible to 'attach' a class that can detect if that line is being grabbed with the mouse and so on.
If I'm not mistaken, in this case, you would need the class to use the same metrics as the line. As you later say - you seem to only want millimeters. I don't think having only one set of metrics is a good thing. At least for me there are a lot of times when I need pixels. Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
"John Torjo" <john.lists@torjo.com> wrote in message news:415123B3.8060905@torjo.com...
Andy Little wrote:
useful mechanism to make dumb drawing objects intelligent. For example, if I had a dumb line, it should be possible to 'attach' a class that can detect if that line is being grabbed with the mouse and so on.
If I'm not mistaken, in this case, you would need the class to use the same metrics as the line.
Hmm... I shouldnt have brought this up. Its way... way beyond what I am currently trying to achieve.:-) However I agree that you need a metric which converts between raw device units and the units of the 'canvas' (Thanks to Matt Trentini for the name). That is IMO entirely logical if you wish to achieve device independence.
As you later say - you seem to only want millimeters.
Not exactly. I prefer to use distances in some 'length' unit of measure, which paved the way for my physical-quantities library. It could be millimeters or miles or whatever., though of course millimeters is easy on Windows... at the device layer.
I don't think having only one set of metrics is a good thing. At least for me there are a lot of times when I need pixels.
Yes..As I have touched in in a previous post this should be accessible at the 'device layer'. OTOH Another way to look at a pixel is as a rectangular box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 mm high or whatever, the next layer up. Obviously you ultimately need pixels on a particular device, but what do you do when you want to render the drawing that you have drawn (or your Window) on a 640x480 pixel diplay on a 1200 dpi laser-printer?. Usually you have to interrogate the system to find out its current pixel 'metric', and convert all your pixels on the display into some number of pixels on the printer. I am just abstracting this process. The problem with pixels is that they can unless you work extremely hard, lock you firmly into one device. So *whenever possible* I would prefer not to deal with them directly. Of course graphics programming has since time immemmorial used pixels, so it may appear that I am 'pulling away the floor from under you'. I would liken it to assembler programmers who see their freedom being taken away when forced to use 'types'. Its a different way of looking at things which might be useful sometimes, so takes time to get used to. I am looking at your own win32gui as well as David Turners C++ gui lib. Hopefully I may be able to apply the 'canvas' concept to either one or both, it is after all designed to be generic:-). Useful thing about gui's is that they can sometimes explain things much better than words:-) regards Andy Little
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little
Yes..As I have touched in in a previous post this should be accessible at the 'device layer'. OTOH Another way to look at a pixel is as a rectangular box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 mm high or whatever, the next layer up.
What does "accessible at the device layer" mean in this context? A pixel is a fundamental unit in any graphics context. I don't think that an application programmer should be forced to jump through hoops to get at it.
Obviously you ultimately need pixels on a particular device, but what do you do when you want to render the drawing that you have drawn (or your Window) on a 640x480 pixel diplay on a 1200 dpi laser-printer?. Usually you have to interrogate the system to find out its current pixel 'metric', and convert all your pixels on the display into some number of pixels on the printer. I am just abstracting this process. The problem with pixels is that they can unless you work extremely hard, lock you firmly into one device. So *whenever possible* I would prefer not to deal with them directly.
I fully support a unified rasterization model across output devices; however, I don't think it should be achieved at the expense of the many programmers who will not use it because they do not need it. For the vast majority of UI programmers, the look of combo boxes and buttons on 1200 dpi laser printers is irrelevant. The specification of certain quantities in pixels is necessary. When designing a graphics API, supporting high-quality output on a diverse set of devices is a large design issue. Text is very different on a monitor than on a high-res laser printer. Nice kerning is heavily affected by the dpi disparities, resulting in a whole host of issues. One major issue: dissimilar line breaking. Inconsistent line breaks can have an enormous impact on presentation. At what resolution should kerning occur? What will pay the price: laser printers, monitors, or layout control?
Of course graphics programming has since time immemmorial used pixels, so it may appear that I am 'pulling away the floor from under you'. I would liken it to assembler programmers who see their freedom being taken away when forced to use 'types'. Its a different way of looking at things which might be useful sometimes, so takes time to get used to.
Since time immemorial, computer science has used algorithms, and I don't think we're getting rid of them anytime soon. :-D I'm a big fan of types and units. I just think that pixels should be a readily accessible type. I think it should be the default unit. Being American, there's nothing special about mm's. I like points more. Or maybe to just get everybody to think about it, the library could default to cubits. ;-) -- Noah
"Noah Stein" <noah@acm.org> wrote in message news:20040923095953.SM01616@enki...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little
Yes..As I have touched in in a previous post this should be accessible at the 'device layer'. OTOH Another way to look at a pixel is as a rectangular box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25mm high or whatever, the next layer up.
What does "accessible at the device layer" mean in this context? A pixel is a fundamental unit in any graphics context. I don't think that an application programmer should be forced to jump through hoops to get at it.
In my current model it is available as (roughly) : Canvas c; c.viewport.device.extent.x; // width of device in pixels c.viewport.device.physical_size.x; // width in (usually) mm but... //The actual units you use are up to you.... // (implicit conversion from mm to point): width::point_comp current_pixel_width = c.viewport.device.physical_size.x / c.viewport.device.extent.x; //note: width could be a length typedef or its own type, //which I am now thinking about.
I fully support a unified rasterization model across output devices;
Not quite sure what that means.
however, I don't think it should be achieved at the expense of the many programmers who will not use it because they do not need it. For the vast majority of UI programmers, the look of combo boxes and buttons on 1200 dpi laser printers is irrelevant.
Hmm... so UI programmers arent at all concerned with explaining the UI to the user? Making the app look as good as possible on a wide range of platforms. Trying to provide a uniform look and feel. Avoiding making the user think in terms of pixels.
The specification of certain quantities in pixels is necessary. When designing a graphics API, supporting high-quality output on a diverse set of devices is a large design issue. Text is very different on a monitor than on a high-res laser printer. Nice kerning is heavily affected by the dpi disparities, resulting in a whole host of issues. One major issue dissimilar line breaking. Inconsistent line breaks can have an enormous impact on presentation. At what resolution should kerning occur? What will pay the price: laser printers, monitors, or layout control?
These are the more interesting issues. I have only just started playing about with units'n guis and havent delved too far into text, fonts and so on. However text does as you say lead to interesting problems. It will be interesting to see if it is easier to deal with text via pixels or units of measure.
I'm a big fan of types and units. I just think that pixels should be a readily accessible type.
They could be a 'runtime type', which you could interrogate to find the current size of a pixel in (say) mm. This would probably be useful in figuring out what fonts to recommend to the user in a selection.
I think it should be the default unit. Being American, there's nothing special about mm's. I like points more. Or maybe to just get everybody to think about it, the library could default to cubits. ;-)
Well... in my physical_quantities library you can use cubits if you wish. If anybody knows what the scaling is between cubits and meters, I'll add it in :-) BTW To those interested in the current status of pqs. I am working on the next distro. But as always I find documentation a heavy slog. But I'm getting there slowly. Hmm... discussing GUI's is so much more fun ;-) regards Andy Little
On Fri, 24 Sep 2004 13:35:41 +0100, Andy Little <andy@servocomm.freeserve.co.uk> wrote: Well... in my physical_quantities library you can use cubits if you wish. If anybody knows what the scaling is between cubits and meters, I'll add it in :-)
There is a cute argument for 1 cubit = 18.24 inches http://www.dsgb.orbix.co.uk/inch.html ;-) matt. matthurd@acm.org
"Matt Hurd" <matt.hurd@gmail.com> wrote in message news:8f48d4a04092409311218b348@mail.gmail.com...
On Fri, 24 Sep 2004 13:35:41 +0100, Andy Little <andy@servocomm.freeserve.co.uk> wrote: Well... in my physical_quantities library you can use cubits if you wish. If anybody knows what the scaling is between cubits and meters, I'll add it in :-)
There is a cute argument for 1 cubit = 18.24 inches http://www.dsgb.orbix.co.uk/inch.html
;-)
Thanks .. err...Hmm ... I think! ;-) regards Andy Little
Andy Little wrote:
"Noah Stein" <noah@acm.org> wrote in message news:20040923095953.SM01616@enki...
From: boost-bounces@lists.boost.org
[mailto:boost-bounces@lists.boost.org]
On Behalf Of Andy Little
Yes..As I have touched in in a previous post this should be accessible at the 'device layer'. OTOH Another way to look at a pixel is as a rectangular box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25mm high or whatever, the next layer up.
What does "accessible at the device layer" mean in this context? A pixel is a fundamental unit in any graphics context. I don't think that an application programmer should be forced to jump through hoops to get at it.
In my current model it is available as (roughly) :
Canvas c; c.viewport.device.extent.x; // width of device in pixels c.viewport.device.physical_size.x; // width in (usually) mm but... //The actual units you use are up to you....
// (implicit conversion from mm to point): width::point_comp current_pixel_width = c.viewport.device.physical_size.x / c.viewport.device.extent.x;
//note: width could be a length typedef or its own type, //which I am now thinking about.
I fully support a unified rasterization model across output devices;
Not quite sure what that means.
however, I don't think it should be achieved at the expense of the many programmers who will not use it because they do not need it. For the vast majority of UI programmers, the look of combo boxes and buttons on 1200 dpi laser printers is irrelevant.
Hmm... so UI programmers arent at all concerned with explaining the UI to the user? Making the app look as good as possible on a wide range of platforms. Trying to provide a uniform look and feel. Avoiding making the user think in terms of pixels.
The specification of certain quantities in pixels is necessary. When designing a graphics API, supporting high-quality output on a diverse set of devices is a large design issue. Text is very different on a monitor than on a high-res laser printer. Nice kerning is heavily
affected
by the dpi disparities, resulting in a whole host of issues. One major
issue
dissimilar line breaking. Inconsistent line breaks can have an enormous
impact
on presentation. At what resolution should kerning occur? What will pay the price: laser printers, monitors, or layout control?
These are the more interesting issues. I have only just started playing about with units'n guis and havent delved too far into text, fonts and so on. However text does as you say lead to interesting problems. It will be
For fonts, won't you use a wrapper over existing OS-primitives? Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)
"John Torjo" <john.lists@torjo.com> wrote in message news:41545215.4000305@torjo.com...
Andy Little wrote:
on presentation. At what resolution should kerning occur? What will pay the price: laser printers, monitors, or layout control?
These are the more interesting issues. I have only just started playing about with units'n guis and havent delved too far into text, fonts and so on. However text does as you say lead to interesting problems. It will be
For fonts, won't you use a wrapper over existing OS-primitives?
If you mean using graphics primitives to create text-characters, I hadnt thought along those lines. I would really like to reuse as far as possible existing file/platform formats for graphics and fonts. Overall , I am currently looking at the bare minimum requirements to disentangle what shouild be the simple function of drawing a vector graphic from the other parts of writing a full blown GUI application . The complexities of dealing with the large number of various file-formats for both graphics and fonts can come later. Typically a font has a name (eg [from Java] Serif, SansSerif, Monospaced), a font character has a size, optional italic, bold etc.In contrast to the function style in the original OP, I am currently thinking in terms of making everything an object, which holds the minimal data required to recreate it. When the object is output on the graphics stream, assuming this is the platform specific default stream, it will then need to be converted into the platform specific equivalent before being sent on to the platform layer. The criterion I am looking at overall is simplicity, rather than (speed and code size) performance.. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:cj2j4j$e1j$1@sea.gmane.org...
"John Torjo" <john.lists@torjo.com> wrote in message news:41545215.4000305@torjo.com...
Andy Little wrote:
on presentation. At what resolution should kerning occur? What will pay the price: laser printers, monitors, or layout control?
These are the more interesting issues. I have only just started
playing
about with units'n guis and havent delved too far into text, fonts and so on. However text does as you say lead to interesting problems. It will be
For fonts, won't you use a wrapper over existing OS-primitives?
[my prev reply snipped] Oops... re-reading the above it sounds like my reply is pretty much what you meant in the first place. So... Yes! regards Andy Little
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Friday, September 24, 2004 6:36 AM To: boost@lists.boost.org Subject: [boost] Re: Re: Re: C++ GUI - another view
<snipped>
Well... in my physical_quantities library you can use cubits if you wish. If anybody knows what the scaling is between cubits and meters, I'll add it in :-)
It varies from user to user. But then, you were replying to *Noah* Stein... <g> Reid
participants (11)
-
Andy Little -
Brock Peabody -
David Abrahams -
David Bergman -
John Torjo -
Mathew Robertson -
Matt Hurd -
Matt S Trentini -
Noah Stein -
Reece Dunn -
Reid Sweatman