Opened 15 years ago
Closed 15 years ago
#5522 closed bug (fixed)
LayoutManager / BGLView Bug
Reported by: | ccipri | Owned by: | phoudoin |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/OpenGL Kit | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I have attached a archive with source code (and the compiled binary) of an example which shows a bug related to the layout manager and/or BGLView.
The application consits of 2 Buttons, a time-counter, and a BGLView.
Start the application and resize the window, everything works correctly. Now press on the button "Start" (which starts a time-counter). Now if you make the window bigger it still works correctly, but if you make the window smaller it doesn't resize the views of the window correctly,.
If I replace the BGLView with another Gui-element, let's say a TextControl, then this bug doesn't appear. It only appears when the window has a BGLView object and if the time-counter has been started. (if I modify the time-counter, such that it works correctly, but without displaying the correct number (just static text), then it also works correctly).
I know it sounds quite strange, that's why I attached the source-code (the binary is compiled on one of the recent nightly builds, a gcc4hybrid).
Attachments (1)
Change History (11)
by , 15 years ago
Attachment: | LayoutBug.zip added |
---|
comment:1 by , 15 years ago
Component: | User Interface → Kits/Interface Kit |
---|---|
Owner: | changed from | to
Version: | R1/alpha1 → R1/Development |
comment:2 by , 15 years ago
Component: | Kits/Interface Kit → Kits/OpenGL Kit |
---|---|
Owner: | changed from | to
It's not strange, it just show that BGLView is not layout aware, which is the bug here.
comment:3 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 15 years ago
This problem will happen anytime you use a BView with the default implementation of GetPreferredSize(). The default implementation, for backwards compatibility reasons, returns the current size of the view. Since MinSize() on the other hand uses GetPreferredSize() for convenience reasons (so you actually have to implement only one method), you have the problem if you don't implement either MinSize() or GetPreferredSize() yourself. One solution is to implement GetPreferredSize() for BGLView in Haiku. Another solution is to use SetExplicitMinSize() on the specific view instance in your program.
comment:5 by , 15 years ago
I'm for implementing BGLView::GetPreferredSize(): even if it's the only B*View class outside interface kit, it should be layout aware.
Of course, there is no "preferred" size for a GL viewport. What's a minimal size, then? (0,0)? Or should it be at least visible?
comment:6 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
comment:8 by , 15 years ago
Perhaps I should start a new ticket, but since it's related to the code I attached above I say it here:
If you take a look at the source code you see that I call fTest->SetLowColor() (I want to set the button to red), but nothing happens. If I move this method call after the button is attached to the layout, then it really changes to red. It happens the same with SetViewColor(). It seems like the values set by SetLowColor and SetViewColor are overwritten to the default values( perhaps while the gui-elements are attached to the layout, or somewhere else). I guess this is not a bug, but your intention to force a unified look, but I'm a little unhappy with that because of that I have to write an additional method to correct this (For example you see in the source that I call fTimeView->Init() after layout is constructed, but in normal case this code should be part of the constructor ) )
comment:9 by , 15 years ago
Since hrev35806, BGLView overrides the default BView::GetPreferredSize() method to returns (0, 0) instead of current size, which fix the issue. Please confirm, so I could close the ticket.
comment:10 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
I close it as it's fixed as far I could tell.
application demonstrating a bug