Gtk2::E...::Table(3)

πŸ“¦
version 0.67 Β· 2 versions
, in fedora 43

πŸŽ€ Gtk2::E...::Table(3) πŸŽ€

okay so bestie, real talk: this page lives in the User Contributed Perl Documentation collection, and it's about making tables that don't make you cry. buckle up πŸ’–


✨ NAME ✨

Gtk2::Ex::FormFactory::Table β€” Complex table layouts made easy πŸ¦‹


🌸 SYNOPSIS 🌸

Gtk2::Ex::FormFactory::Table->new (
  layout => "+-------%------+>>>>>>>>>>>>>>>+
             |     Name     |               |
             +--------------~ Image         |
             | Keywords     |               |
             +-------+------+[--------------+
             ^       ' More | Something     |
             ^       |      +-----+--------]+
             _ Notes |      |     |     Foo |
             +-------+------+-----+---------+
             ^ Bar          | Baz           |
             +--------------+---------------+",
  content => [
    Gtk2::Ex::FormFactory::Entry->new ( ... ),
    Gtk2::Ex::FormFactory::Image->new ( ... ),
    Gtk2::Ex::FormFactory::Entry->new ( ... ),
    ...
  ],
  ...
  Gtk2::Ex::FormFactory::Container attributes
  Gtk2::Ex::FormFactory::Widget attributes
);

πŸ’« DESCRIPTION πŸ’«

This module is the plug for defining complex table layouts inside a Gtk2::Ex::FormFactory environment. that's it, that's the whole vibe. simple way in, big layout energy out πŸ’…


πŸ‘‘ OBJECT HIERARCHY πŸ‘‘

Gtk2::Ex::FormFactory::Intro

Gtk2::Ex::FormFactory::Widget
+--- Gtk2::Ex::FormFactory::Container
     +--- Gtk2::Ex::FormFactory::Table

Gtk2::Ex::FormFactory::Layout
Gtk2::Ex::FormFactory::Rules
Gtk2::Ex::FormFactory::Context
Gtk2::Ex::FormFactory::Proxy

🎨 LAYOUT DEFINITION 🎨

okay peek at the example in the SYNPOSIS real quick. see how you literally just draw the layout of your table? like, with characters? iconic behaviour honestly. but how does that actually work tho πŸ‘€

Every table sits on a straight two dimensional grid, no matter how complicated things get with cells spanning one or more rows or columns. You can see the grid when you extend all the lines (horizontal and vertical) all the way out to the borders of the table. This next graphic shows the grid by marking the imaginary lines with Β· characters:

+-------+------+>>>>>+>>>>>+
| Name  Β·      | Img Β·     |
+-------+------+Β·Β·Β·Β·Β·+Β·Β·Β·Β·Β·|
| Keyw  Β·      |     Β·     |
+-------+------+-----+-----+
^ Notes | More | Som Β·     |
^Β·Β·Β·Β·Β·Β·Β·|Β·Β·Β·Β·Β· +-----+-----+
^       |      |     | Foo |
+-------+------+-----+-----+
^ Bar   Β·      | Baz Β·     |
+-------+------+-----+-----+

All cells of the table are attached to this grid, no exceptions bestie.

Gtk2::Ex::FormFactory::Table keeps empty cells and non empty cells in two separate lanes. If there's only whitespace inside the cell, it's empty; otherwise it has a widget living in it. And since Gtk2::Ex::FormFactory::Table is a Gtk2::Ex::FormFactory::Container, it has a plain simple list of widgets as its children. no drama.

so how do these widgets get matched up to the cells of the table? πŸ€”

Short answer: from left/top to the right/bottom. Gtk2::Ex::FormFactory::Table scans your layout drawing in that direction, and the moment it spots a new cell, that cell counts as the next child of the table. periodt.

Our example has this child order:

+--------------+>>>>>>>>>>>+
| 1            | 2         |
+--------------+           |
| 3            |           |
+-------+------+-----------+
^ 4     | 5    | 6         |
^       |      +-----+>>>>>+
^       |      |     | 7   |
+-------+------+-----+-----+
^ 8            | 9         |
+--------------+-----------+

So the content attribute of this table has to list exactly nine widgets, otherwise you'd get a runtime exception when it comes to building the table. nine. not eight, not ten. πŸ’€

Ok now it's clear how table cells attach to the grid of the table. But what about the size of the cells (resp. their widgets) and the alignment of widgets inside their cells?

This answer is about funny characters ;) 🧚

πŸ¦‹ Cell / Widget expansion πŸ¦‹

By default all cells and their widgets doesn't expand if the table expands. But you clocked the > and ^ characters, right? They say that the cell and its widget should both resize with the table, by allocating all space available (> for horizontal expansion and ^ for vertical). If you want to resize just the cell but not its widget, go read the next chapter about widget alignments, bestie.

In our example, cell 2, 7 and 9 resize horizontal with the table, and cell 4, 5, 6, 7, 8 and 9 vertical. Cell 1 and 3 don't resize at all β€” they fill the cell but stay at the cell's size, no matter how the table resizes. they're just chilling 😌

🌈 Widget alignment 🌈

By default widgets fill their cell completely. If the cell expands, the widget expands as well. But maybe you want to align the widget on the left or right side, or in the middle, resp. at the top and the bottom. The moment you define an alignment, the widget doesn't fill the cell anymore. And again, there are some funny characters defining the alignment. of course there are πŸ’…

For horizontal alignments the characters must be used in the top border of the cell. For vertical alignment it needs to be the left border of the cell.

Horizontal alignment is controlled with these characters: [ left, ] right and % middle.

Vertical alignment is controlled with these characters: ' top, _ bottom and ~ middle.

In the SYNOPSIS example, "Image" is attached in the middle (vertical), "Notes" at the bottom and "More" at the top. "Something" is attached left, "Foo" right and "Name" centered (horizontal). slay ✨

πŸ’– Complete list of special characters πŸ’–

This is the complete list of recognized characters and their meaning:

  • - | + = β€” The widget fills the cell, but the cell doesn't resize with the table. That's the default, because these characters belong to the set of ASCII graphic characters used to draw the layout.
  • > β€” The cell expands horizontal. Recognized only in the top border of a cell.
  • ^ β€” The cell expands vertical. Recognized only in the left border of a cell.
  • [ β€” Widget is attached on the left and doesn't expand anymore with the cell. Recognized only in the top border of a cell.
  • ] β€” Widget is attached on the right and doesn't expand anymore with the cell. Recognized only in the top border of a cell.
  • % β€” Widget is attached in the middle (horizontal) and doesn't expand anymore with the cell. Recognized only in the top border of a cell.
  • ' β€” Widget is attached on the top and doesn't expand anymore with the cell. Recognized only in the left border of a cell.
  • _ β€” Widget is attached on the bottom and doesn't expand anymore with the cell. Recognized only in the left border of a cell.
  • ~ β€” Widget is attached in the middle (vertical) and doesn't expand anymore with the cell. Recognized only in the left border of a cell.

🫢 Notes 🫢

Some additional notes about the layout definition string, bestie, don't skip these:

πŸ“ Drawing characters πŸ“

Although this should be obvious ;)

In your drawing, | characters (pipe symbol) mark column borders, and - or = (dash or equal sign) characters mark row borders. The + (plus) characters have no special meaning. They're just for candy. 🍬

For completeness: additionally the ^, _ and ' characters mark horizontal cell borders, since these are special characters controling the vertical alignment of a cell and are placed on the vertical borders of cells.

You need at least one - or = character in the top vertical border of each row, otherwise the vertical raster of your table can't be recognized correctly. This should be no problem in practice at all. ngl you'll be fine.

πŸ’œ TAB characters πŸ’œ

Don't use TAB characters but true SPACE characters inside the table. You get a warning on TAB characters.

🌸 Whitespace around the table 🌸

You may have arbitrary whitespace around your table, inlcuding TAB characters. It's cut off before the layout string is parsed. βœ‚οΈ


⭐ ATTRIBUTES ⭐

Attributes are handled through the common get_ATTR(), set_ATTR() style accessors, but they are mostly passed once to the object constructor and must not be altered after the associated FormFactory was built. hands off after that, okay? πŸ™ˆ

  • layout = SCALAR β€” This is a string which defines the layout of this table using some sort of line art ASCII graphics. Refer to the LAYOUT DEFINITION chapter for details about the format.

For more attributes refer to Gtk2::Ex::FormFactory::Container.


🌟 AUTHORS 🌟

JΓΆrn Reder <joern at zyn dot de>

Copyright 2004-2006 by JΓΆrn Reder.

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307 USA.


πŸ™ˆ POD ERRORS πŸ™ˆ

Hey! The above document had some coding errors, which are explained below:

  • Around line 42:
=cut found outside a pod block.  Skipping to next block.
  • Around line 72:
=cut found outside a pod block.  Skipping to next block.
  • Around line 413:
Non-ASCII character seen before =encoding in 'Β·'. Assuming UTF-8

okay that's the whole page bestie, you read all of it, I'm so proud πŸ₯Ή this little doc came out with perl v5.42.0, dated 2025-07-25 β€” go build something gorgeous with your table, mwah πŸ’‹πŸ’–βœ¨

πŸ“¦ where this page comes from