Closed mchampaneri closed 4 years ago
Hello and thank you!
Looks good to me. Once I fix the Travis builds (it seems, we can't use Go 1.11 or older), I'll merge this.
@mchampaneri You know, on second thoughts I suggest you to opt-in this behavior via a separate Window
method, just in case someone wants to implement this by himself.
For example,
func (s *Window) AddQuitMenu() {
C.MinimalMenu()
}
What do you think?
@pravic
Yes, you are correct. As I have thought of only exit. But if someone combines objective-c, they can get a menu with more functionality that just exit.
Will push an update with same tommorow.
@pravic
It would be better, If we can pass custom menu as parameter in AddMenu function. If paramter is there then will use custom menu otherwise will go with minimalMenu.
But stuck at passing c function as parameter. Have no clue. Can you guide me regard on that?
void CustomMenu(void) {
id menubar = [[NSMenu new] autorelease];
id appMenuItem = [[NSMenuItem new] autorelease];
[menubar addItem:appMenuItem];
[NSApp setMainMenu:menubar];
id appMenu = [[NSMenu new] autorelease];
id appName = [[NSProcessInfo processInfo] processName];
id quitTitle = [@"I want to " stringByAppendingString:appName];
id quitMenuItem = [[[NSMenuItem alloc] initWithTitle:quitTitle
action:@selector(terminate:) keyEquivalent:@"q"]
autorelease];
[appMenu addItem:quitMenuItem];
[appMenuItem setSubmenu:appMenu];
}
func main() {
win, _ := window.New(sciter.DefaultWindowCreateFlag, sciter.DefaultRect)
win.AddMenu( [menus as parameter ])
win.Show()
win.Run()
}
func (s *Window) AddMenu( [menu-as-parameter] ) {
if [menu as parameter ]{
[ menu-as-paramete ]
}else{
C.MinimalMenu()
}
}
@mchampaneri You know, on second thoughts I suggest you to opt-in this behavior via a separate
Window
method, just in case someone wants to implement this by himself.For example,
func (s *Window) AddQuitMenu() { C.MinimalMenu() }
What do you think?
Menu has to go through go-sciter. Otherwise It will open as a separate application. So menu has to be passed as AddMenu function parameter and has to be called from show() or run() function of window.
And in-fact, If passing menu as parameter is feasible, there is also probability that we can support custom menu for every window instead of at app level in mac builds, If we can find way to inject menu from show() function instead of run() function.
It would be better, If we can pass custom menu as parameter in AddMenu function.
It's more complicated.
I think, it's easier to go with this:
func main() {
win, _ := window.New(sciter.DefaultWindowCreateFlag, sciter.DefaultRect)
// win.AddMenu( [menus as parameter ])
win.AddMinimalQuitMenu()
win.Show()
win.Run()
}
User either calls the AddMinimalQuitMenu function, or its complitely own implementation.
It would be better, If we can pass custom menu as parameter in AddMenu function.
It's more complicated.
I think, it's easier to go with this:
func main() { win, _ := window.New(sciter.DefaultWindowCreateFlag, sciter.DefaultRect) // win.AddMenu( [menus as parameter ]) win.AddMinimalQuitMenu() win.Show() win.Run() }
User either calls the AddMinimalQuitMenu function, or its complitely own implementation.
I am agree with you at this moment. Pushing update for AddMinimalQuitMenu().
But will be looking for solutions to pass custom menu through sciter. As I don't want some one to update code of go-sciter to add only custom menu in mac os x.
@pravic
Sorry I have made some mess ups, Instead of merging in mchampaneri/go-sciter:master by mistake I merged it with sciter-sdk/go-sciter:master.
I have reverted the merge. As well travics.yml was showing conflict where I picked your last changes by comparing with my code.
This mess is made due to dual fork of code.
Can you suggest me, How should I do my development. Should I go with my personal fork for update or should go with a branch of sciter-sdk.
It's better to write code in a separate branch and then create Pull Requests in order to review them. Even better - to create a separate branch for each feature/big change (see Git Workflow).
And please, avoid pushing directly to master - give others a chance to review your proposed changes via pull requests.
@pravic
It's better to write code in a separate branch and then create Pull Requests in order to review them. Even better - to create a separate branch for each feature/big change (see Git Workflow).
And please, avoid pushing directly to master - give others a chance to review your proposed changes via pull requests.
I will make sure such thing don't happen again.
func (s *Window) AddQuitMenu() {
C.MinimalMenu()
}
Adding AddQuiteMenu will brake code for windows and linux. As there is no such function.
So before making AddQuiteMenu a window method either we need to implement such behaviour for windows and linux or we should AddQuiteMenu behind the scene for mac.
_If some one want to make custom menu then they have to update windowdarwin.go for flexibility as they need to add menu to cocoa application. So better off is that we add minimal quit menu by default for those who don't want to have other menu then just quit.
If some one want to make custom menu then they have to update window_darwin.go
Why? Instead of win.AddQuitMenu()
they'll call their own function.
As for the Windows / Linux - just add a similar function that does nothing.
Main menubar with exit menu and supports for CMD+q to close application added fo darwin build.