Recently I've started to play around with SmartWin. Despite very poor support for dynamic layout management and very bad-looking example programs (sorry!), SmartWin seems to be a very promising tool. By the way, I really think the examples bundled with SmartWin should be fundamentally redesigned to look more mainstream, or they will keep many potential users away (initially they scared me off).
I'd like to ask you a question about the WidgetToolbar widget. I'm trying to create a toolbar with only textual buttons. The problem is that if I don't change setButtonSize(), the text is almost not visible (it's most part lies below the bottom edge of the toolbar; what is more, the button is much too big). I don't know what should I set toolbar's button size to. It can't be in any way relative to the size of a bitmap, because I don't use any bitmaps at all. However small values like (1, 1) or (0, 0) seem to be almost fine. The final misbehavior is that a button's label doesn't get centered inside button's surrounding rectangle -- it's a bit too low.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> very bad-looking example programs (sorry!)
Which ones do you dislike the most ?
>> very poor support for dynamic layout management
Could you expand about what you don't like ? Have you looked at the Place class ? What kind of dynamic layout management do you like ?
best regards, Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry I'm responding so late, but I've been having quite a hot time recently.
> Which ones do you dislike the most ?
I'll try to point out main problems (in my opinion) which are common to most examples.
Please stop using nonstandard fonts in the examples. For example take a look at the AdressBook. Italics? Hardly readable! Comic Sans? Even bold style should be used with care! Font changes when switching between tabs looks preety bad, too. Since I've been alraady talking about the AddressBook example, I must add another weird thingy. User can resize the central grid widget. It stays out of the crowd, but let's say it's only an example and the purpose of such behaviour is to show that it can be done. However relative size of mentioned widget is not kept after resizing the whole window. That leaves a bad impression.
In many cases there is not enough space for text contained in a widget (no margin is left). For example take a look at WidgetToolbar and the "Undock" button. BTW WidgetToolbar again uses nonstandard and hard-to-read fonts. What is more it's suffering from another problem: big white rectangles looking like they hardly belong to places they were placed in (at least they should have some frame around them).
> Have you looked at the Place class ? What kind of dynamic layout management do you like ?
It would be nice to have the ability to make layout as simple as in Tk. For example to create some widgets (like buttons) without worrying about their size, placement (in case of "pack" manager), margins and adaptation to resizing of their parent. I don't see any such possibility in SW right now. Dynamic layout could be also based on some other approach. Maybe similar to Motif's or the one from QT (I'm afraid I'm not familiar with any of them, but from what I know, at least Motif's approach is simple yet efficient).
It's not possible to place a widget in the center of some area by simply using the Place class, is it?
What about my main question? Is there a bug in WidgetToolbar's implementation? Or maybe I'm not using it correctly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess the main purpose of the samples has been to provide test cases for the functionality, rather than attract people for their style and beauty.
RE:
"For example to create some widgets (like buttons) without worrying about their size, placement (in case of "pack" manager), margins and adaptation to resizing of their parent"
Yes, some people would like to have manager classes that did the layout according to policies set at the Widget creation time rather than in response to a resize event generated by Win32. So far SmartWin only has helper classes that help you arrange placement and layout.
Yes, its possible to center a rectangle inside another SmartWin::Rectangle with the shrink member function:
/// Size of the rectangle will be * factor, Position adjusted for the same center.
/** Creates a smaller rectangle from the old rectangle. <br>
* size.x *= factor, and pos.x is adjusted inwards to compensate. <br>
* <pre>
* ####
* #### -> ##
* #### ##
* ####
* </pre>
* shows the effect of shrink( 0.5 ) <br>
* shrink( long border ) is similar, but removes a constant border amount of pixels on all sides.
*/
Rectangle shrink( double factor ) const;
This one operates by a fraction of the previous Rectangle's size. There is also
/// For both dimensions, move inwards by Border and shrink the size by 2*Border
/** We add border to the position, and subtract it twice from the size.
* Same as shrink( long xBorder, long yBorder ); except the x and y border are the same.
* shrink( double factor ) is similar, but expresses the new rectangle as a fraction of the old.
*/
Rectangle shrink( long border ) const;
which operates with a specific border.
You may be right about WidgetToolbar. The sample is now using Coolbar now. Let me check.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
Recently I've started to play around with SmartWin. Despite very poor support for dynamic layout management and very bad-looking example programs (sorry!), SmartWin seems to be a very promising tool. By the way, I really think the examples bundled with SmartWin should be fundamentally redesigned to look more mainstream, or they will keep many potential users away (initially they scared me off).
I'd like to ask you a question about the WidgetToolbar widget. I'm trying to create a toolbar with only textual buttons. The problem is that if I don't change setButtonSize(), the text is almost not visible (it's most part lies below the bottom edge of the toolbar; what is more, the button is much too big). I don't know what should I set toolbar's button size to. It can't be in any way relative to the size of a bitmap, because I don't use any bitmaps at all. However small values like (1, 1) or (0, 0) seem to be almost fine. The final misbehavior is that a button's label doesn't get centered inside button's surrounding rectangle -- it's a bit too low.
Thanks for commenting,
>> very bad-looking example programs (sorry!)
Which ones do you dislike the most ?
>> very poor support for dynamic layout management
Could you expand about what you don't like ? Have you looked at the Place class ? What kind of dynamic layout management do you like ?
best regards, Andrew
I'm sorry I'm responding so late, but I've been having quite a hot time recently.
> Which ones do you dislike the most ?
I'll try to point out main problems (in my opinion) which are common to most examples.
Please stop using nonstandard fonts in the examples. For example take a look at the AdressBook. Italics? Hardly readable! Comic Sans? Even bold style should be used with care! Font changes when switching between tabs looks preety bad, too. Since I've been alraady talking about the AddressBook example, I must add another weird thingy. User can resize the central grid widget. It stays out of the crowd, but let's say it's only an example and the purpose of such behaviour is to show that it can be done. However relative size of mentioned widget is not kept after resizing the whole window. That leaves a bad impression.
In many cases there is not enough space for text contained in a widget (no margin is left). For example take a look at WidgetToolbar and the "Undock" button. BTW WidgetToolbar again uses nonstandard and hard-to-read fonts. What is more it's suffering from another problem: big white rectangles looking like they hardly belong to places they were placed in (at least they should have some frame around them).
> Have you looked at the Place class ? What kind of dynamic layout management do you like ?
It would be nice to have the ability to make layout as simple as in Tk. For example to create some widgets (like buttons) without worrying about their size, placement (in case of "pack" manager), margins and adaptation to resizing of their parent. I don't see any such possibility in SW right now. Dynamic layout could be also based on some other approach. Maybe similar to Motif's or the one from QT (I'm afraid I'm not familiar with any of them, but from what I know, at least Motif's approach is simple yet efficient).
It's not possible to place a widget in the center of some area by simply using the Place class, is it?
What about my main question? Is there a bug in WidgetToolbar's implementation? Or maybe I'm not using it correctly?
About the Toolbar: To achieve what you want, create your toolbar like this:
WidgetToolbar::Seed seed;
seed.style |= TBSTYLE_LIST;
toolbar = createToolbar(seed);
toolbar->setButtonSize(0, 32);
...
Where 32 is the desired height of the buttons.
I guess the main purpose of the samples has been to provide test cases for the functionality, rather than attract people for their style and beauty.
RE:
"For example to create some widgets (like buttons) without worrying about their size, placement (in case of "pack" manager), margins and adaptation to resizing of their parent"
Yes, some people would like to have manager classes that did the layout according to policies set at the Widget creation time rather than in response to a resize event generated by Win32. So far SmartWin only has helper classes that help you arrange placement and layout.
They are explained somewhat here:
http://home.comcast.net/~andrew7webb/smartwin/layout.html
and in the doxygenin\html directory.
Yes, its possible to center a rectangle inside another SmartWin::Rectangle with the shrink member function:
/// Size of the rectangle will be * factor, Position adjusted for the same center.
/** Creates a smaller rectangle from the old rectangle. <br>
* size.x *= factor, and pos.x is adjusted inwards to compensate. <br>
* <pre>
* ####
* #### -> ##
* #### ##
* ####
* </pre>
* shows the effect of shrink( 0.5 ) <br>
* shrink( long border ) is similar, but removes a constant border amount of pixels on all sides.
*/
Rectangle shrink( double factor ) const;
This one operates by a fraction of the previous Rectangle's size. There is also
/// For both dimensions, move inwards by Border and shrink the size by 2*Border
/** We add border to the position, and subtract it twice from the size.
* Same as shrink( long xBorder, long yBorder ); except the x and y border are the same.
* shrink( double factor ) is similar, but expresses the new rectangle as a fraction of the old.
*/
Rectangle shrink( long border ) const;
which operates with a specific border.
You may be right about WidgetToolbar. The sample is now using Coolbar now. Let me check.