Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set initial position of the divisor of a Split Container [Core] #186

Open
Dayof opened this issue Jun 27, 2017 · 8 comments
Open

Set initial position of the divisor of a Split Container [Core] #186

Dayof opened this issue Jun 27, 2017 · 8 comments

Comments

@Dayof
Copy link
Contributor

@Dayof Dayof commented Jun 27, 2017

The current implementation of SplitContainer doesn't allow to modified the initial position of the divisor, so it would be great to set a min/max height or width of each widget inside of the a SplitContainer.

Example of how it looks now:

captura de tela 2017-06-27 as 03 29 50

@Ocupe
Copy link
Collaborator

@Ocupe Ocupe commented Jul 10, 2017

@Dayof I think this is a good idea. Are you working on this?

@Dayof
Copy link
Contributor Author

@Dayof Dayof commented Jul 10, 2017

Not right now! Do you wanna take it? @Ocupe

@polarmutex
Copy link
Contributor

@polarmutex polarmutex commented Aug 19, 2018

It looks like you can add weights when adding content to a split container now. however on macOS the weights do not seem to go into effect till resize the window.

@Bobw147
Copy link
Contributor

@Bobw147 Bobw147 commented May 21, 2020

I have had a look into this today but am not sure how to implement a solution. I have a SplitContainer with 2 panels weighted at 0.3 and 0.7 respectively but on initial display the divider is always set in the central position. Resizing the container causes the divider to jump to its correctly weighted position. The call sequence is:

  1. self.main_window = my_split_container in my app startup
    invokes...

  2. toga_cocoa/window.py
    def set_content(self, widget):
    # Set the window's view to the be the widget's native object.
    self.native.contentView = widget.native

the assignment to contentView invokes, via rubicon, the toga_cocoa/splitcontainer.py delegate method
3) class TogaSplitViewDelegate(NSObject):
@objc_method
def splitView_resizeSubviewsWithOldSize_(self, view, size: NSSize) -> None:

The latter method is the only place where the weighting calculation is performed and that is done only once in total during startup, as described above. The content of the NSSize object has width=0, height=0 and so no actual calculation of the respective panel widths is performed resulting in equal sized panels. (The panel content is visible).

Resizing the box causes this delegate method to be invoked again, this time with the new (non-zero) size, presumably by the Toga event loop.

Is there a way to programatically invoke this delegate with the correct width and height parameters as part of the initialisation sequence and if so, how and where?

@freakboy3742
Copy link
Member

@freakboy3742 freakboy3742 commented May 21, 2020

@Bobw147 Well that's the question, isn't it :-) I'm sure there is a way - but I can't say I know what it is. You can't just invoke the delegate; you have to trigger the event that causes the delegate to be used. What that process is, however, is the mystery.

The place to look for a solution is in the macOS APIs, and StackOverflow posts about direct macOS programming (in Objective C and Swift).

@Bobw147
Copy link
Contributor

@Bobw147 Bobw147 commented May 21, 2020

Stack Overflow? Really? I have to read their venom? :-(
Here I was hoping you would say something like 'yeah, just do this' :-(

Having slept on it I have an idea that I will try out.

@Bobw147
Copy link
Contributor

@Bobw147 Bobw147 commented May 21, 2020

I have a fix that appears to be working ok. I need to do some more testing but so far everything is looking good. I also realised that the weighting calculation was always using the panel width regardless of the splitter direction so have also added a mod for this.

@direnc
Copy link

@direnc direnc commented Sep 18, 2020

I have a fix that appears to be working ok. I need to do some more testing but so far everything is looking good. I also realised that the weighting calculation was always using the panel width regardless of the splitter direction so have also added a mod for this.

Any updates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants