Dynamic sizing.

newer
Are windows just ordinary widgets?

David Sankel

26 Apr 2003 26 Apr '03

3:28 a.m.

Hello Everyone, It seems that right now the easiest and best way to deal with dynamic sizing of widgets is as follows: -- CGA/CommonAttributes.hs class HasSize w where size :: Attr w SizeType data SizeType = Fixed (Int,Int) | Standard Where fixed is obviously the pixel size and Standard is some implementation dependant size. For example, a button would likely have a fixed height and a length based on the label size on a macintosh. What does everyone thing about this? It is pretty elegant and simple this way so it makes me think that more "stuff" needs to be added. David J. Sankel

Show replies by date

Wolfgang Thaller

26 Apr 26 Apr

8:47 a.m.

On Samstag, Apr 26, 2003, at 09:28 Europe/Vienna, David Sankel wrote:

...

Hello Everyone,

It seems that right now the easiest and best way to deal with dynamic sizing of widgets is as follows:

-- CGA/CommonAttributes.hs class HasSize w where size :: Attr w SizeType

data SizeType = Fixed (Int,Int) | Standard

I'd rather say data SizeComponent = Fixed Int | Standard type SizeType = (SizeComponent, SizeComponent) (or data SizeType = Size SizeComponent SizeComponent) I'd perhaps want to use a vertical scrollbar that has standard width and a user-specified height. On the other hand, might we not want to query the "standard" size, so that we can perhaps use it to align with another widget? Question to all: Who is not familiar either with Java's GridBagLayout or with Tcl's "grid" geometry manager? (BTW: Is XmRowColumn the same thing or something different?) That's the best way of managing dynamic layouts that I know. Any reasons for not using something like that? Cheers, Wolfgang

David Sankel

3:08 p.m.

--- Wolfgang Thaller wrote:

...

I'd rather say

data SizeComponent = Fixed Int | Standard type SizeType = (SizeComponent, SizeComponent) (or data SizeType = Size SizeComponent SizeComponent)

...

On the other hand, might we not want to query the "standard" size, so that we can perhaps use it to align with another widget?

Of course. We should always be able to query the actual size. How about size is not an attribute? Size could be a ro variable. The attribute is the SizePolicy. SizePolicyType = Fixed Int | -- A fixed, nonnegociable size MinimumSuf Int | -- The Int is the minimum but it -- can be expanded but without -- benefit. MinimumExp Int | -- The Int is the minimum and it -- can be expanded with benefit. MaximumShr Int | -- The int is the maximum size and -- it can be shrunk. Preferred Int | -- The Int is the preferred size -- but it can be expanded without -- benefit or shrunk PreferredExp Int | --The int is the preferred size --and it can be expanded with --benefit or shrunk. Standard

...

Question to all: Who is not familiar either with Java's GridBagLayout or with Tcl's "grid" geometry manager? (BTW: Is XmRowColumn the same thing or something different?) That's the best way of managing dynamic layouts that I know. Any reasons for not using something like that?

I'm used to using HBox's and VBox's. Is a grid as simple as I think it is? If it is . . . HBox, VBox, and GridBox seem to be a good addition. David J. Sankel

Wolfgang Thaller

4:52 p.m.

...

Of course. We should always be able to query the actual size. How about size is not an attribute? Size could be a ro variable. The attribute is the SizePolicy.

Sounds good.

...

SizePolicyType =

We'll have to think about the actual constructors a bit more, I think.

...

I'm used to using HBox's and VBox's. Is a grid as simple as I think it is? If it is . . . HBox, VBox, and GridBox seem to be a good addition.

Grids are reasonably simple to use; they become really great when used in conjunction with a graphical GUI editor. They are slightly more general than HBoxes and VBoxes (although those cases that you can't model with H/VBoxes are rare in practice). For a GridBox, you would specify *) the number of rows and columns *) attributes for rows and columns (attributes include "Resizable" and "NonResizable"; some grid layout managers provide a "weight" attribute for resizable rows/columns). For each widget you place in the grid box, you'd specify *) row and column number *) row and column span (a widget may take up more than one cell) *) other attributes, like alignment (if a column is resized but the widget in it has a fixed size narrower than the column), padding etc. So we could have several different types of containers: HBoxes, VBoxes for simple dynamic layout GridBoxes for complex dynamic layout FixedPlacementBox for crazy people, for strange situations and for implementing dynamic layout schemes on top of it. How would we specify container-specific attributes? Row/Column number, row/column span etc. are not attributes of the widget, and they are attributes of a widget inside a GridBox container. What about having:

...

class Container c where addChild :: Widget w => c -> w -> [Prop (c,w)] -> IO () removeChild :: Widget w => c -> w -> IO ()

So that I could write something like:

...

myGrid <- mkGridBox [columns =: [Resizable, NonResizable], rows =: [NonResizable, NonResizable]] myLabel <- mkLabel [title =: "foo"] myEntry <- mkEditableTextField [] myButton <- mkButton [title =: "bar"]

addChild myGrid myLabel [row =: 1, column =: 1, columnspan =: 2, halign =: Center] addChild myGrid myEntry [row =: 2, column =: 1] addChild myGrid myButton [row =: 2, column =: 2]

... and later I could use things like:

...

set (myGrid, myLabel) [columnspan =: 1]

Of course, HBoxes, VBoxes, fixed placement, and everything else people might come up with, would fit in the same framework. What do you think? Cheers, Wolfgang

Glynn Clements

4:29 p.m.

Wolfgang Thaller wrote:

...

Question to all: Who is not familiar either with Java's GridBagLayout or with Tcl's "grid" geometry manager? (BTW: Is XmRowColumn the same thing or something different?)

Well, XmRowColumn is a widget class, whereas the other two are "standalone" geometry managers. Apart from that, XmRowColumn isn't as flexible the other two case; it won't suffice as a general-purpose container. It's mostly used where you want to arrange all of the children in a single row or column (e.g. menu bars, menus). Motif's "generic" container widget is XmForm. This allows you to place the children arbitrarily, with the edges positioned using attachments. Each child of an XmForm has four constraint resources for each of the four edges (i.e. sixteen resources in total). E.g. the placement of the bottom edge is controlled by: XmNbottomAttachment XmNbottomOffset XmNbottomPosition XmNbottomWidget The attachment resource is set to one of the following: XmATTACH_NONE Do not attach the bottom side of the child. XmATTACH_FORM Attach the bottom side of the child to the bottom side of the Form. XmATTACH_OPPOSITE_FORM Attach the bottom side of the child to the top side of the Form. XmNbotto mOffset can be used to determine the visibility of the child. XmATTACH_WIDGET Attach the bottom side of the child to the top side of the widget or gadget specified in the XmNbottomWidget resource. If XmNbottomWidget is NULL, XmATTACH_WIDGET is replaced by XmAT TACH_FORM, and the child is attached to the bottom side of the Form. XmATTACH_OPPOSITE_WIDGET Attach the bottom side of the child to the bottom side of the widget or gad get specified in the XmNbottomWidget resource. XmATTACH_POSITION Attach the bottom side of the child to a position that is relative to the top side of the Form and in proportion to the height of the Form. This position is determined by the XmNbottomPosition and XmNfractionBase resources. XmATTACH_SELF Attach the bottom side of the child to a position that is proportional to the current y value of the bottom of the child divided by the height of the Form. This position is determined by the XmNbottomPosition and XmNfraction Base resources. XmNbottomPosition is set to a value proportional to the current y value of the bottom of the child divided by the height of the Form. Similarly for the other three edges. Also, you can choose whether to specify attachments for both edges of an opposing pair (top/bottom, left/right), or only one edge; in the latter case, the position of the other edge is determined by the widget's preferred size. Consider a specific example. A dialog has a label across the top, a list in the middle with a scrollbar to its right, and some buttons across the bottom. The label has its top, left and right edges attached to the top, left and right edges of the form, and its bottom edge unattached. The buttons have their bottom edges attached to the bottom of the form. The first button has its left edge attached to the left of the form; the other buttons have their left edges attached to the right edge of the previous button. Their right and top edges are unattached. The scrollbar has its top edge attached to the bottom of the label, its bottom edge attached to the top of one of the buttons, its right edge attached to the right edge of the form, and its left edge unattached. The list has its top and bottom edges attached to the top and bottom of the scrollbar, its right edge attached to the left edge of the scrollbar, and its left edge attached to the left edge of the form. If the dialog is resized vertically, the label and buttons will retain their sizes and their positions relative to their associated edges, while the list and scrollbar will grow or shrink accordingly. Similarly, if the dialog is resized horizontally, the buttons and scrollbar will retain their sizes and relative positions, while the label and list will grow or shrink accordingly.

...

That's the best way of managing dynamic layouts that I know. Any reasons for not using something like that?

I find that the mechanisms used by Java and Tcl tend to be a bit too explicit in the actual placement and sizing of widgets. Motif prefers to allow widgets to size themselves, with the size and layout of the parent adjusting accordingly. This simplifies i18n; you don't have to manually create separate layouts for e.g. English ("medium" sized words, "normal" font height), German/Scandanavian (often longer words) and Japanese/Chinese (shorter words, taller font). For more complex layouts, it's common to create a hierarchy of nested containers. E.g., for a situation which XmForm's layout strategy doesn't handle, consider the situation with the above example if the buttons at the bottom of the dialog had differing preferred heights. You would probably want to have the other buttons enlarged to match the tallest, or at least align the bottom of the list and scrollbar with the top of the tallest button. To allow for that, the typical solution would be to place the buttons inside their own container (either XmRowColumn, or XmForm with all buttons having their top and bottom edges attached to the matching edge of the form); the container's preferred size will be as tall as the tallest child. Nesting may also be used for stylistic reasons, i.e. to group together sets of related widgets; Windows dialogs often do this, although it isn't necessary for layout purposes (fixed placement). -- Glynn Clements

Wolfgang Thaller

5:23 p.m.

Glynn Clements wrote:

...

Wolfgang Thaller wrote:

...
Question to all: Who is not familiar either with Java's GridBagLayout or with Tcl's "grid" geometry manager? (BTW: Is XmRowColumn the same thing or something different?)

Well, XmRowColumn is a widget class, whereas the other two are "standalone" geometry managers.

Yes. I actually think we should be using specialized container widgets, not "standalone" geometry managers, because the former can be typechecked more easily (see my last e-mail for an example of what I'm thinking).

...

Motif's "generic" container widget is XmForm. This allows you to place the children arbitrarily, with the edges positioned using attachments.

I lost track somewhere, but I think I get the drift (and I'll try reading it again tomorrow, when tiredness isn't interfering). Is there anything that an XmForm do that Grids can't? I think we should just manually implement a grid-layout manager for the Motif backend. An alternative would be to manually implement something like XmForm on all other platforms, but it looks like that is harder than implementing a grid.

...

...
That's the best way of managing dynamic layouts that I know. Any reasons for not using something like that?

...

I find that the mechanisms used by Java and Tcl tend to be a bit too explicit in the actual placement and sizing of widgets. Motif prefers to allow widgets to size themselves, with the size and layout of the parent adjusting accordingly.

... as do Java's GridBagLayout and Tcl's grid.

...

This simplifies i18n; [...]

Of course. But I don't have to create separate layouts for the Java/Tcl grid layout managers, either.

...

For more complex layouts, it's common to create a hierarchy of nested containers.

Yes, agreed. Cheers, Wolfgang

Glynn Clements

27 Apr 27 Apr

12:49 a.m.

Wolfgang Thaller wrote:

...

...
Motif's "generic" container widget is XmForm. This allows you to place the children arbitrarily, with the edges positioned using attachments.

I lost track somewhere, but I think I get the drift (and I'll try reading it again tomorrow, when tiredness isn't interfering). Is there anything that an XmForm do that Grids can't?

I don't know; my knowledge of grids is pretty rusty. The set of XmATTACH_* options listed in my previous message should be enough to determine exactly what you can and can't do with an XmForm.

...

I think we should just manually implement a grid-layout manager for the Motif backend. An alternative would be to manually implement something like XmForm on all other platforms, but it looks like that is harder than implementing a grid.

Certainly, XmForm is non-trivial. The layout algorithm is iterative; it repeatedly updates the sizes and positions until all of the constraints are satisified (or, if you make a mistake and specify contradictory attachments, until it exceeds the iteration limit). Personally, I suspect that trying to come up with a portable mechanism for geometry management is going to be one of the hard parts. OTOH, it isn't something that programs often need to deal with. Most of the time, the program itself doesn't actually care where the widgets are; it just needs to be able to get/set their state, and receive notification of significant events. In any case, my bottom line is that, even if you provide a portable geometry management mechanism, I ought to be able to just use actual XmForm, XmRowColumn etc widgets for the Motif version of an application. In particular, stylistic attributes (e.g. spacing, margins) which are set via resources need to be respected. -- Glynn Clements

Wolfgang Thaller

4:58 a.m.

New subject: Platform-Specific Extensions (was Re: Dynamic sizing.)

...

In any case, my bottom line is that, even if you provide a portable geometry management mechanism, I ought to be able to just use actual XmForm, XmRowColumn etc widgets for the Motif version of an application. In particular, stylistic attributes (e.g. spacing, margins) which are set via resources need to be respected.

We could just add a platform-specific extension for the Motif backend. If somebody wants to implement a portable XmForm "clone", we could move it to the CGA proper. Proposal for Platform-Specific extensions: 1) Every backend may add additional functions to the CGA, which are only available for that backend. 2) Such platform-specific functions must be clearly marked as such. I suggest that we follow the example of OpenGL and mark extensions using a suffix to the name, e.g. mkXmForm_EXT, loadNibFile_EXT, etc. We could also use a platform-specific suffix, e.g. mkXmForm_MOTIF, loadNibFile_MAC etc. 3) A backend maintainer doesn't need to ask other backend maintainers for permission when adding extensions. Opinions? Cheers, Wolfgang

Alastair Reid

9:35 a.m.

New subject: Platform-Specific Extensions

Wolfgang Thaller writes:

...

Proposal for Platform-Specific extensions: [...] Opinions?

Sounds like a fine plan. One little detail: what about datatype declarations? Suppose the standard version provides a datatype like this: data T = A Int | B Float and the foo backend has a third option 'C Char', I can either do: data T = A Int | B Float | C_ext Char or data T = A Int | B Float data T_ext = T_std T | C_ext Char or data T_ext = A_ext Int | B_ext Float | C_ext Char The first is more pleasant to use. The second makes the use of an extension more explicit and is less liable to result in exceptions if user code does case analysis on this type. The third seems like a reasonable compromise between the two and is probably my favourite at the moment. We'd probably want to provide helper functions with types like these: to_T_ext :: T -> T_ext from_T_ext :: T_ext -> Maybe T I'm not especially happy with any of these but I suspect they're pretty much the best that can be done within Haskell's type system. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/

Axel Simon

9:57 a.m.

New subject: Platform-Specific Extensions

On Sun, Apr 27, 2003 at 02:35:50PM +0100, Alastair Reid wrote:

...

Wolfgang Thaller writes:

...
Proposal for Platform-Specific extensions: [...] Opinions?

Sounds like a fine plan.

One little detail: what about datatype declarations?

Suppose the standard version provides a datatype like this:

data T = A Int | B Float

and the foo backend has a third option 'C Char', I can either do:

data T = A Int | B Float | C_ext Char

I think this is not a problem at all. As far as my grasp of our task is concerned, we are just defining an API (CGA). That means we have a bunch of modules declaring data types, functions and some semantics but these modules don't do anything. If the user wants to build an application (s)he has to choose one specific backend (hs-aqua, gtk2hs, HToolkit, etc.) and link to it (using -package hs-aqua or similar). Then it is no problem to have data types with more constructors in each backend. Axel.

Alastair Reid

1:48 p.m.

New subject: Platform-Specific Extensions

[I omitted the following quote in mail this is a reply to a reply to - AR] Wolfgang Thaller writes:

...

I suggest that we follow the example of OpenGL and mark extensions using a suffix to the name, e.g. mkXmForm_EXT, loadNibFile_EXT, etc.

Alastair Reid writes:

...

...
One little detail: what about datatype declarations?

Axel Simon writes:

...

I think this is not a problem at all. As far as my grasp of our task is concerned, we are just defining an API (CGA). That means we have a bunch of modules declaring data types, functions and some semantics but these modules don't do anything. If the user wants to build an application (s)he has to choose one specific backend (hs-aqua, gtk2hs, HToolkit, etc.) and link to it (using -package hs-aqua or similar). Then it is no problem to have data types with more constructors in each backend.

Of course, the code will compile with no problem at all. The idea of having a standard way of marking backend-specific extensions is not to solve a compilation or typechecking problem but to accomplish what we might call a social or software-engineering problem: helping people understand when they are using a non-portable extension. As Wolfgang points out, this is done in OpenGL (which has a similar problem of trying to provide a common frontend to a set of backends with differing capabilities). You'll see similar goals being accomplished if you use the -ansi flag with gcc (warns about use of non-ansi features), the extension qualifier in gcc (can be used to tag functions, variables, types, etc. as being extensions beyond standard C), etc. Hugs' +/-98 flag and GHC's -f[no]glasgow-exts serve a similar goal. You might even consider GHC's 'deprecated' annotation as serving a similar goal. -- Alastair Reid

Glynn Clements

4:14 p.m.

New subject: Platform-Specific Extensions (was Re: Dynamic sizing.)

Wolfgang Thaller wrote:

...

...
In any case, my bottom line is that, even if you provide a portable geometry management mechanism, I ought to be able to just use actual XmForm, XmRowColumn etc widgets for the Motif version of an application. In particular, stylistic attributes (e.g. spacing, margins) which are set via resources need to be respected.

We could just add a platform-specific extension for the Motif backend. If somebody wants to implement a portable XmForm "clone", we could move it to the CGA proper.

I think that the key issue is abstraction. Most of the API, and most of the code which uses it, should be able to work with whatever widgets are passed to it. Using a platform-specific widget class should involve a minor change to the UI construction code; it shouldn't require changes to the rest of the code.

...

2) Such platform-specific functions must be clearly marked as such. I suggest that we follow the example of OpenGL and mark extensions using a suffix to the name, e.g. mkXmForm_EXT, loadNibFile_EXT, etc.

I'd rather just use modules and qualified names. -- Glynn Clements

Axel Simon

28 Apr 28 Apr

4:30 a.m.

New subject: Platform-Specific Extensions (was Re: Dynamic sizing.)

On Sun, Apr 27, 2003 at 09:14:16PM +0100, Glynn Clements wrote:

...

...
2) Such platform-specific functions must be clearly marked as such. I suggest that we follow the example of OpenGL and mark extensions using a suffix to the name, e.g. mkXmForm_EXT, loadNibFile_EXT, etc.

I'd rather just use modules and qualified names.

Me too. We might even use the deprecated pragma (or something similar) to flag if the user uses backend specific functions. Axel.

Wolfgang Thaller

8:27 a.m.

New subject: Platform-Specific Extensions (was Re: Dynamic sizing.)

...

On Sun, Apr 27, 2003 at 09:14:16PM +0100, Glynn Clements wrote:

...
...
2) Such platform-specific functions must be clearly marked as such. I suggest that we follow the example of OpenGL and mark extensions using a suffix to the name, e.g. mkXmForm_EXT, loadNibFile_EXT, etc.

I'd rather just use modules and qualified names.

It's probably the more Haskell-like way. Should be fine as long as we stay away from adding constructors to datatypes (which we probably should anyway). Axel Simon wrote:

...

Me too. We might even use the deprecated pragma (or something similar) to flag if the user uses backend specific functions.

I wouldn't like that, because it would give me tons of warnings for perfectly good platform-specific programs. Just tell users to always import the "extensions" modules qualified, and no-one will ever use an extension without knowing it. Cheers, Wolfgang

Axel Simon

27 Apr 27 Apr

10:50 a.m.

On Sat, Apr 26, 2003 at 11:23:32PM +0200, Wolfgang Thaller wrote:

...

Glynn Clements wrote:

...
Wolfgang Thaller wrote:

...
Question to all: Who is not familiar either with Java's GridBagLayout or with Tcl's "grid" geometry manager? (BTW: Is XmRowColumn the same thing or something different?)

Well, XmRowColumn is a widget class, whereas the other two are "standalone" geometry managers.

Yes. I actually think we should be using specialized container widgets, not "standalone" geometry managers, because the former can be typechecked more easily (see my last e-mail for an example of what I'm thinking).

Well, at least to get something running I would like to have container widgets first and then think about more alternatives. Maybe we should be content with one portable way of creating window contents on the fly (i.e. dynamically). I think Wolfgang's list is quite ambitious:

...

So we could have several different types of containers:

HBoxes, VBoxes for simple dynamic layout GridBoxes for complex dynamic layout FixedPlacementBox for crazy people, for strange situations and for implementing dynamic layout schemes on top of it.

What do you mean when you say HBoxes and VBoxes? In Gtk even HBoxes and VBoxes are not as simple as putting things next to each other. You still have to specify which and how widgets grow and shrink when the surrounding container changes size. Actually the only way a grid layout is more powerful seems to be the ability to put things into a matrix (e.g. a tic-tac-toe playfield with 9 buttons with their borders all aligned). I don't really know about grid layouts, Gtk has one, but I think every cell is of the same size, so it's not nearly as universial (and complicated) as Motiv's. As such, Gtk's grid is more like Window's dialog units, albeit not fixed in its cell size. (I looked up dialog units: they are horizontally 1/4 of the average character's width and vertically 1/8 of the font size.) It is possible to change the font and size of a specific label in a specific dialog box in Gtk by means of a resource file. If this feature is combined with fixed layout (or one dynamic layout created in Haskell) it will destroy Gtk's native look. Maybe I am missing something, but I don't see a way to start with a fixed layout specification and then but dynamic layout on top of it. Axel.

Wolfgang Thaller

11:34 a.m.

Axel Simon wrote:

...

[...] I think Wolfgang's list is quite ambitious:

...
So we could have several different types of containers:

HBoxes, VBoxes for simple dynamic layout GridBoxes for complex dynamic layout FixedPlacementBox for crazy people, for strange situations and for implementing dynamic layout schemes on top of it.

What do you mean when you say HBoxes and VBoxes? In Gtk even HBoxes and VBoxes are not as simple as putting things next to each other. You still have to specify which and how widgets grow and shrink when the surrounding container changes size.

I put them in the list because David Sankel stated that he is "used to using HBox's and VBox's", and I don't care whether we put them in or not. They probably aren't much effort to implement on top of a "grid" geometry manager. We could leave them out and put them in at the last moment if we really want them.

...

Actually the only way a grid layout is more powerful seems to be the ability to put things into a matrix (e.g. a tic-tac-toe playfield with 9 buttons with their borders all aligned).

No, that's not the only way, because widgets can span more than one row and/or column. I don't think you can achieve the following layout with H/VBoxes: AAB DEB DCC (where AA is just _one_ widget; There are 5 widgets here, A,B,C,D and E).

...

I don't really know about grid layouts, Gtk has one, but I think every cell is of the same size, so it's not nearly as universial (and complicated) as Motiv's.

No, Gtk's "table" does everything I want for a grid. The cells aren't necessarily the same size (unless you set the grid to be "homogeneous").

...

As such, Gtk's grid is more like Window's dialog units, albeit not fixed in its cell size. (I looked up dialog units: they are horizontally 1/4 of the average character's width and vertically 1/8 of the font size.)

I remember being able to use pixels for placing controls (widgets) in normal windows. If we correctly query the "recommended" sizes for widgets, we can safely ignore dialog units and do our calculations in pixels.

...

It is possible to change the font and size of a specific label in a specific dialog box in Gtk by means of a resource file. If this feature is combined with fixed layout (or one dynamic layout created in Haskell) it will destroy Gtk's native look. Maybe I am missing something, but I don't see a way to start with a fixed layout specification and then but dynamic layout on top of it.

On MacOS, there is of course no other way (because the toolkit itself provides only fixed layout), which is why fixed layout _has to be there_ (as a base for implementing other things). Same for Fltk, which is used in the sample implementation that was posted here. However, I don't see why there should be a problem with implementing layout managers on top of fixed layout. The layout manager would just have to query the (platform- and font-specific) minimum, preferred and maximum sizes of the widgets. If the font settings are changed, the layout manager has to be notified, and it has to redo the layout. For Gtk, we might as well map the Grid layout manager to the native table widget (as long as we don't want to add any features that Gtk's table doesn't have). This would save us some coding effort (but it wouldn't get us a more native look).

...

Maybe we should be content with one portable way of creating window contents on the fly (i.e. dynamically).

Well, the only way of creating window contents on the fly that exists on all platforms is _fixed placement_ (yes, I know that it is impossible to use this portably with hard-coded coordinates). I need fixed placement before I can implement anything else for Mac OS. Cheers, Wolfgang

Axel Simon

noon

On Sun, Apr 27, 2003 at 05:34:58PM +0200, Wolfgang Thaller wrote:

...

Axel Simon wrote:

...
Actually the only way a grid layout is more powerful seems to be the ability to put things into a matrix (e.g. a tic-tac-toe playfield with 9 buttons with their borders all aligned).

No, that's not the only way, because widgets can span more than one row and/or column.

I don't think you can achieve the following layout with H/VBoxes:

AAB DEB DCC

(where AA is just _one_ widget; There are 5 widgets here, A,B,C,D and E).

Ok, granted.

...

...
I don't really know about grid layouts, Gtk has one, but I think every cell is of the same size, so it's not nearly as universial (and complicated) as Motiv's.

No, Gtk's "table" does everything I want for a grid. The cells aren't necessarily the same size (unless you set the grid to be "homogeneous"). [..]

...

On MacOS, there is of course no other way (because the toolkit itself provides only fixed layout), which is why fixed layout _has to be there_ (as a base for implementing other things).

True, you have to be able to UI elements at specific pixel positions before you write your grid layout code. But if that interface is in CGA it means every backend has to implement it as well. I don't like that, but if you think it is easier that way, I will live with that.

...

However, I don't see why there should be a problem with implementing layout managers on top of fixed layout. The layout manager would just have to query the (platform- and font-specific) minimum, preferred and maximum sizes of the widgets. If the font settings are changed, the layout manager has to be notified, and it has to redo the layout.

For Gtk, we might as well map the Grid layout manager to the native table widget (as long as we don't want to add any features that Gtk's table doesn't have). This would save us some coding effort (but it wouldn't get us a more native look).

Perhaps I may request that the grid manager you will propose does not demand anything that is not in the intersection of grid managers of Gtk and Motiv. It's not only that I don't like reimplementing a fundamental part of Gtk (and loosing compatablity with GUI Builders), it's also that sending all these signals and going back and forth between Haskell and C will make Gtk even slower. But otherwise I am happy with grid layout. HBoxes and VBoxes as an add on or backend-specific. Axel.

Wolfgang Thaller

1:15 p.m.

Axel Simon wrote:

...

True, you have to be able to UI elements at specific pixel positions before you write your grid layout code. But if that interface is in CGA it means every backend has to implement it as well. I don't like that, but if you think it is easier that way, I will live with that.

For now, I'd say, let's put the FixedPlacementBox in the "sample implementation". It will also be in the Mac OS version. We could still decide to rename it to "FixedPlacementBoxEXT" later (although I'd still like to have it, because I have actually once encountered a situation where I needed fixed placement). Whats important for myself is a) That a FixedPlacementBox fits in the interface (if the "addChild" function has a hard-coded type that disallows fixed placement, that would be bad) b) That a FixedPlacementBox is present in at least one non-Mac OS implementation, so that I have something to compare my implementation with in the early phases. I think we can agree on that, and we can revisit the question of whether to include it in the public interface later. For Gtk, it should be trivial to implement a FixedPlacementBox using GtkLayout.

...

...
For Gtk, we might as well map the Grid layout manager to the native table widget (as long as we don't want to add any features that Gtk's table doesn't have). This would save us some coding effort (but it wouldn't get us a more native look).

Perhaps I may request that the grid manager you will propose does not demand anything that is not in the intersection of grid managers of Gtk and Motiv.

OK, I think Gtk's "Table" provides enough features (roughly the same feature set as Java's GridBagLayout and Tcl's grid). From Glynn's posts, I gathered that XmRowColumn doesn't have enough features, and that XmForm works completely differently. So unfortunately, a grid layout manager will have to be "emulated" for the Motif backend.

...

[...] it's also that sending all these signals and going back and forth between Haskell and C will make Gtk even slower.

A cost, that we, unfortunately, can't avoid for the Mac OS and Win32 platforms...

...

But otherwise I am happy with grid layout. HBoxes and VBoxes as an add on or backend-specific.

OK. While they are simple to implement on top of Grid, they provide no real benefit. Let's ignore them for now, and include them later only if someone speaks out for them (but there's no need for discussion of H/VBoxes now).

8060

Age (days ago)

8062

Last active (days ago)

List overview

Download

17 comments

5 participants

participants (5)

Alastair Reid
Axel Simon
David Sankel
Glynn Clements
Wolfgang Thaller

Dynamic sizing.

Glynn Clements

Glynn Clements

Glynn Clements

tags

participants (5)