| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2791
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| 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 |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | rwsaustin |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | 32b10cb626fcdf59336a8fed25971eeeebfac6f4 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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 (https://github.com/fltk/fltk/issues/797). The comment in https://github.com/fltk/fltk/issues/797#issuecomment-1764464996 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.
[1] https://github.com/fltk/fltk/commit/6ba7b49baf11e526d1ed19aef491db2cd120e55e | |
| |
| #7 | AlbrechtS
13:02 Dec 13, 2023 |
| Fixed in Git repository.
Done. See new methods init_size_range(..) and size_range(..).
Closing. | |
[ Return to Bugs & Features ]
|
| |
