Menu
▾
▴
#58 custom menu items
Actually the wrapper has the following main menu items under the [(Customizable) Application Name]:
About ==> Wineskin about Window
--------------------------------------
Toggle Full Screen
--------------------------------------
Hide
Hide Others
Show All
--------------------------------------
Quit
It could be nice if we can add some customizable menu items, for example this menu layout:
[My Custom MenuItem1]
[My Custom MenuItem2]
[My Custom MenuItem3]
[etc.]
--------------------------------------
About Wineskin ==> Wineskin about Window
--------------------------------------
Toggle Full Screen
--------------------------------------
Hide
Hide Others
Show All
--------------------------------------
Quit
Where [My Custom MenuItem] is a custom text that points to a local file name (document or executable) or to a web link. Examples:
"Help" ==> drive_c/Program Files/MyApplication/MyManual.pdf
(A relative path within the .app to the user manual of the application or to other links usually installed by the Installer)
"Help on MyApplication for OS X" ==> drive_c/MyAboutOSX.pdf
(A document written specifically for the port of this application to OS X)
"About MyApplication for OS X" ==> http://mywebsite.org/MyApplicationForOSX
(A web link about the porting of this application)
"License/Credits" ==> drive_c/license.txt
(The license/credits of the whole application + wrapper and/or credits)
"Video Tutorial" ==> http://youtube.com/MyVideo
(A web link to a tutorial about this application (maybe specifically under OS X)
"Configure this Wrapper" ==> Wineskin.app
(a relative link to a .app within the bundle, so we can call WineSkin.app or one of the Custom applications within the bundle. So It is possible to replicate the Menus installed by the application under Windows/Start/Programs/Application/MyMenu).
As you can see there are many uses for it. I don't think it is necessary to add the configuration of these items within the WinSkin.app, because its very easy to edit a text file. A bundled User Manual or Online Help of WineSkin explaining this is enough.
Well the top menu items are from WineskinX11, and since I'm working on WS8 now, this is the time to bring up stuff like that.
I think i can put in a menu item or two or three and link them to a specific function in WineskinX11 that will... maybe call a script file to run? I could put like 5 in there and by default they basically do nothing, and you can delete extra ones after the fact (though you couldn't get them back in without starting over)... and just edit the script file associated with it?
of course I have no clue (yet) how to edit how that bin file is being built before hand.. since WineskinX11 is just a fork off XQuartz... but I'll see if I can figure it out and if it can be added...
The menu options will have to be hard coded to what they do... just calling set scripts I think would be the easiest.. those bash scripts can be replaced with perl, or ObjC programs or whatever by the person wanting to use them... kinda like the startup and shutdown scripts.
Having a Wineskin.app launcher one is a good idea.. I've just been dreading figuring out that much more into XQuartz code... but I'm getting to be a veteran with it now.
Would 5 Custom Options be enough? Would I need to have a way they can be removed without someone having to have Interface Builder to edit the nib? the other problem is that the nib is associated with the engine, so changing out the engine would lose all the changes... so I may need to put the nib elsewhere in the wrapper and have it symlinked so thats not lost.
Yes, pointing to a predefined script is great. A very simple solution is to have a bunch of scripts in a particular position calling them
CustomMenu1_xxxxxx.sh
CustomMenu2_xxxxxx.sh
CustomMenuN_xxxxxx.sh
If a script is available then you will add the customized menu item. If the script is not available/present then you will not add it. This at startup of the application. On the run-time-fly is probably not necessary. The xxxxx will be the label of the menu item. I can't think of something simpler.
I would then create one default script
CustomMenu1_WineSkin Configuration.sh that will execute Wineskin.app
Once a wrapper/application is well defined and ready to be delivered probably the Wineskin.app link can be removed, and even the Wineskin.app can be removed, not necessary to the end user.
I have too little experience on OS X coding, so I don't remember if we can do that easily. You may can add up to 9 menu items in the nib and rename them on the fly based on the available scripts.
Thats a good idea...
The only problem I currently have is figuring out how to do it. If XQuartz was an Xcode project, i could do that in a snap.... but its not so I have to figure out how the nib is built and everything.
ok.. I think I found it all... I'm thinking this may not be too hard to implement. Its just changing the main.nib around... which is run off X11Controller.h and .m
The main.nib is already made as is, I'm not sure how to add menu items dynamically or if thats even possible though. I might have to do the first idea where a certain number are there and you manually delete the ones you don't want... but I'm searching. If you find a way to code dynamically changing the contents of a menu in a nib let me know... i'm sure there is a way, but I've not messed with them extensively, keeping things simple and not using the top menus much :-)
ok.. not being annoying, but keep track of my progress here, and keeps anyone updated :-)
I think I can programmatically add in the menu items, but I have to have them defined int he code, meaning I cannot add in endless items. I can basically make items and have conditions enabled wether they are actually showing or not....
so I think the way I have to do this is just add a predefined number of items, so you'll have a Max you can add in. say its was... 5 max, then if you had 0 to 5 scripts in the Custom Menu Item Script folder, then 0 to 5 entries would show up for them, but 5 would still be max.
What would be a good maximum number? i was kind of thinking 10...?
yes, I think that 9 or 10 items are more than enough. From 0 to 9. Probably even 5 is enough.
I have this partially implemented.. I'll finish it later tonight or sometimes in the next couple of days, but I think it will work.... so I'll have it in WS8 which I hope to have out before next weekened.
There is a WineskinMenuScripts folder in Resources.
files are...
Script1--Name
etc... the double dashes is how its parsing to know whats the name to put on the menu and what menu it goes on
There is menu entry under Help and a HelpEntry-- file along with 10 script files... they will show up and name themselves depending on the name and existence of the script
There is also a Wineskin Config menu option which is hard coded to launch Wineskin.app. If Wineskin.app doesn't exist, then it doesn't show up on the menu either...
I think this will work, just have to finish it up a bit and do a build and test it.
"I think I can programmatically add in the menu items, but I have to have
them defined int he code, meaning I cannot add in endless items. I can
basically make items and have conditions enabled wether they are actually
showing or not...."
How so? If you have a reference/outlet/whatever to the container NSMenu you can programmatically create and add as many arbitrary NSMenuItem you want (NSMenu's -addItemWithTitle:action:keyEquivalent:), set the selector for every one of them to the same function, set the tag for each of them to a different value (NSMenuItem's setTag:), and in the called selector check the sender's tag / run the appropriate script (i.e. something based off [NSString stringWithFormat:@"BlaBlaScript-%@-%02d", [sender title], [sender tag]]). (I can share code snippets if you want, poke me on irc or ask here). Unless I'm assuming something wrong, that is :P
P.S.: Remember to start the scripts in the folder where they are located or in a well defined startup folder. So that it is possible to use relative paths within the script.
got this working in test builds of WineskinX11 now for Wineskin 2.5... switching to pending.
Done and working in Beta