STR #2791

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #2791

Application:FLTK Library
Status:4 - Pending
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Minimum size for tiles in an Fl_Tile
Created By:rwsaustin
Assigned To:AlbrechtS
Fix Version:1.4.0
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 rwsaustin
21:25 Dec 10, 2011
#2 rwsaustin
21:12 Dec 13, 2011
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 rwsaustin
14:56 Dec 09, 2011
Robert Strickland wrote:

Create an additional parameter to the Fl_Tile constructor and modify functionality to establish a minimum size for tiles. Default could be twice the width of a DOWN_FRAME border (plus perhaps a pixel or two).

The behavior I would like is for each box in the tile to have some minimum size. Currently, when I drag the border to one side or the other, one or more tiles completely disappears. If the user is unfamiliar with the layout, there is absolutely no visible cue that there is a hidden tile lurking against one edge or corner of the drawn border. The poor user has to randomly try to drag borders until the hidden tile appears.

With the requested change, a minimal tile would still be visible as a double border on one edge or a small square a corner.

Metthais Melcher replied:

Fl_Tile has no function to set a minimum tile size. However, I strongly
believe that there should be one for exactly the reason you state. Using DOWN_FRAMEs for the tiles give a nice visible and draggable border, so defaulting the minimal tile size to twice the width of the border would keep the visual cue and would make it possible to reconstruct all tiles.
#2 rwsaustin
21:34 Dec 10, 2011
File tiletest.cxx is a test of Fl_TileM, inherited from Fl_Tile that sets a minimum threshold for the size of a child tile. This has the effect of displaying a double border along the

Fl_TileM also encapsulates set_cursor() and associated cursor data that were static in the parent Fl_Tile class.

--Robert Strickland
#3 rwsaustin
21:15 Dec 13, 2011
Ignore tiletest.cxx. See instead tiletest2.cxx. Class Fl_TileM overrides Fl_Tile and provides a minimum size threshold for windows. A minimum size of 3 pixels shows a nice double border when FL_DOWN_BOX border is used.  
#4 rwsaustin
21:47 Dec 13, 2011
I tested tiletest2.cxx on fltk1.3.0 on linux. It seems to behave well. I inherited from Fl_Tile primarily to make a self-contained test file that can be compiled with a minimum of dependencies.

Still to do is to get the resize() to display the double border. Also, I need to test a more complicated layout, to make sure dragging one tile into several adjacent tiles works as expected.

For reasons I don't fully understand, I couldn't figure out how to override position() without overriding handle(). I think it is because of the static mouse cursor stuff. I encapsulated this into the class. There are no functional changes to the new handle().

When one tile pushes its neighbor until it is minimal and then pushes
all the way to the edge of the container, only one double border is drawn. I think this behavior is acceptable, but one could argue that the entire layout should always be visible.
position() calls itself recursively to position the other border of a minimal tile. I need to check this with more complicated layouts.
#5 ianmacarthur
13:47 Dec 21, 2011
Note for others: this STR might be tangentially related to STR 2797, where it turns out that if you resize a double window to 0x0 AND are not using XDBE then you can get a segfault from the X11 system...  
#6 AlbrechtS
06:38 Oct 16, 2023
Robert, thank you very much for posting this proposal, and I apologize for the long delay of a reply and working on it. I hope you're still watching this STR.

You wrote "I couldn't figure out how to override position() without overriding handle()". The main reason was that position() was not virtual. In our current work (FLTK 1.4, git branch 'master') we renamed this method to 'move_intersection()' to avoid name clashes (overriding Fl_Widget::position() was a bad idea).

I fixed the subclassing issues in commit 240ff8432624dc2a [1], took your code and reduced it to the minimal necessary code for subclassing, and I posted my work based on your code in GitHub issue #797 ( The comment in describes what I did and has a link to my modifications. I also split your code in tiletest2.cxx in multiple files so it can be put into the FLTK 1.4 tree and be used directly.

I hope you don't mind if we take your code and add the FLTK copyright header. In my work I mentioned your name as original author.

Thank you for your good work and documentation in the code (what you did and why). This made it easy for me to separate the subclassing issues (fixed) from the new code in 'move_intersection()'.

For further progress please watch the above mentioned GitHub issue. I put this STR on status 4 (pending) and all further discussions should be done on the GitHub site - except maybe a short comment here.

bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.