I have a Cocoa app I'm working on and I get a different result in appearance for the NSToolbar I am using for the main window.
Specifically, I'm using a search field as the last NSToolbarItem and, whereas under Snow Leopard it is displayed correctly:
it is cut under Leopard:
Looking at those two versions it appears that the spaces I put between the items are not respected under Leopard. I also saw that sometimes, after I make some update at the toolbar in Interface Builder, these changes are not mirrored in the running application even under Snow. I have to drag the default bar from the customizing menu in order to see them.
UPDATE
The reason for the NSToolbar not always mirroring what is in the .nib file resides in the autosave mechanism that was enabled for me, as NSGod suggested.
What can be the cause of this misbehavior?
Is there something about constraints, (minimum and maximum) sizes that I should have taken into account?
Feel free to point some documentation to me
UPDATE 2
Is there a way to programmatically introduce item and spaces into a NSToolbar or check the consistency (at run time) of those entered with Interface Builder?
While I do recall having a couple of oddities with search fields in NSToolbars, I've never seen the behavior where the right side of it is cut off.
Are the NSToolbarItems that are spaces the fixed one-unit space, or the flexible spaces?
"I also saw that sometimes, after I
make some update at the toolbar in
Interface Builder, these changes are
not mirrored in the running
application even under Snow. I have to
drag the default bar from the
customizing menu in order to see them."
You need to keep in mind that if you've enabled user customization and autosave behavior in the toolbar, then when the user explicitly makes a change, it will be saved to user defaults. If you then re-arrange your toolbar in IB and run the app, it's possible that the configuration saved in user defaults is overriding the default configuration you've specified in the nib file.
What I usually do is during testing, delete the prefs file for my app so changes can't be overridden. (FWIW, I usually use an AppleScript saved as an application that I keep in my Dock. It just runs a do shell script command which deletes the prefs file. Being a GUI-oriented type of person, it's easier for me to just click it to have it run right before debugging. This version of the script asks for the prefs file to delete, though it can also be customized: http://www.markdouma.com/developer/DeleteAppPrefs.zip. If you've never run it before, you get the choose file dialog, and the chosen file is saved as an alias inside the actual AppleScript, so you're not asked again. You can drag the icon onto AppleScript Editor to take a look at the script or change it).
Anyway, then, if I'm going to release a new version of an app that uses a new toolbar layout, and want to prevent the config from being overridden, I'll change the toolbar's identifier (or autosave name) to something like "docToolbar2.0".
Related
I am looking for a way to right click selected text and open it in my app. Eg. via OS X's third party share menu. But I can not find any references at Apple's.
Have a look at the apple docs SysServices for creating a service for you app.
The Docs take you through an example of how to set one up.
Once done you will need to go into System Preferences and Enable the service. Your users will also need to do that.
Here is a quick project that shows an adaption of the apple code.
Update:
Although I think the services work good enough. Creating a Share or Action Extension is possible.
This example uses the same Project as above. But I have added an App Action extension (Target) to it.
The template for the Action is not too hard to understand and it took me 5 minutes to do this quick example.
(So I am not saying everything is as it should be but it works)
For the Action Extension:
Follow the instructions here
Which basically is:
After you choose the extension point that makes sense for your app
extension, add a new target to your containing app. The easiest way to
add an app extension target is to use an Xcode template that provides
a target preconfigured for your extension point.
To add a new target to your Xcode app project, choose File > New >
Target. In the sidebar on the left side of the new target dialog,
choose Application Extension for iOS or OS X. In the pane on the right
side of the dialog, Xcode displays the templates you can choose
Do read the above docs to understand better of what you need to do.
Once you have added the Extension. You can actually run it straight away.
Xcode provides you an option to choose a test app to test it in i.e TextEdit.app and takes you through the whole process of temporarily enabling the Extension.
In this example, remember I chose an Action Extension which suited the App.
The App's function in life is to do a basic encryption of selected text and then display the result.
The App's Action Extension will do the same but instead of displaying it, it will replace the selected text with the encryption text.
All that was needed for me to do, was copy the encryption method from the main app, over to the Extension.
I did have to adjust a couple of things though. Namely the original code deals with a NSString, where as the Extension deals with a NSAttributedString.
The conversion I did works but styling attributes are lost. For this example that does not really matter.
An Action Extension does not use the Share contextual menu. It uses an Action menu.
To see the menu, select some text and the hover the cursor over the selected text. You then should see a discloser button on the left of the text.
Like this:
Click it and choose the Extension.
If you do not see it, go to the 'more' option. This will take you to the system preferences where you can grant access to the extension.
The documentation is mainly concerned about distributing the extension and App via the App store.
But you can code sign your App and extension and do a normal archive export.
From there, all should work ok with gatekeeper.
But again refer to the Docs for a fuller understanding.
Here is a link for the code signed app and also the new Project.
Encrypto2
I hate to ask such simple questions, but nothing I found so far helped me...
So, I've recently started using IntelliJ instead of Eclipse and there are 2 things that really bothers me...
1.) size of javadoc popup window - ok, so I finally get this little guy to pop-up whenever I need it, but it's so small I have to use scroll every single time... and that's pretty anoying when I'm working with unknown libraries...
2.) tabs == spaces - maybe some of you like this, but I don't... Eclipse was treating tabs as tabs and not spaces... I tried to change settings but with no result... or is that maybe connected with project I'm working on? (meaning, if, at the start of a project, setting were such that tabs == spaces and now changes are not applied to it)
Sorry for stupid question but, as I said, nothing I found so far helped me...
1) Just resize the window with your mouse. It will retain the size the next time it opens. You can also click on the gear icon in the upper right corner and adjust the font size. Again, it will retain the size on subsequent use.
2) I'm assuming you make the change to the "Use Tab Character" option on the "Tabs and Indents" tab for all file types and saved the Code Style. After that, you need to run the Reformat Code action (Ctrl+Alt+L or Code > Reformat Code from the menu or Reformat Code from the context menu (i.e. right-click) in The Project Tool window or Navigation Bar). IDEA retains the previous formatting (so spaces in this case) until you run a reformat on the project (or a part of it).
If you have multiple projects already created, for each one, you will need to go into File > Settings > [Project Settings] > Code Style and set the Scheme (and then do a reformat). While the Scheme definition is saved IDE wide, the scheme to use is set per project (which makes sense since an Apache Open Source project you are working on may have different code style requirements than the projects you do at work vs the ones you do for fun).
Finally, you will also want to go into File > Other Settings > Default Settings > [Template Project Settings] > Code Style and make sure your saved code style scheme (with the use tab option) is set so that new projects use that scheme when they are created.
It's possible to create global defines, by placing them in smcs.rsp, and when you hit play - you'll notice those parts of the code are hit and everything is acting as if it should.
However when editing the source in MonoDevelop, it does not recognize the constants that are set in that file.
Leaving you with text that looks like this:
This makes it hard to keep track of what the current constant values are and requires mentally tracking what is turned on and off despite the editor constantly telling you otherwise.
Is it possible to get monodevelop to respect that file?
The method of using smcs.rsp is pretty old and is not needed after unity3d 4.x. Before 4.0 there is not way of doing it without smcs.rsp file but things have changed, the constants can be added from game itslef.
Go to Edit->Project Settings->Player and in the inspector, choose other settings and u will see configuration title, in the box below specify your symbols one by one followed by ;
I have an Xcode 4 objective-C project which contains about 150 .m and .h files in it.
The code underlying the project does not always correspond in underlying disk structure to the folders shown in the Xcode project. I get that part.
What I don't get is why Xcode won't tell me anything about why I can create new project groups and move items to them, with no problems, but certain existing project folders will cause the project to become broken, and the code will no longer build once I move certain .m files or .h files into a different group. When its broken it just shows the file in red. This is frustrating and confusing.
In the screenshot below, the left side of image before shows state before, when all is good, right side shows red (missing) file after moving into a group. Given that groups don't represent a folder on disk, I would not expect moving from one group to another to break things. Sometimes it does, and sometimes it does not. This particular XCode issue upsets me a lot.
In the good old days of Friendly Mac User-Interfaces, you could hit ⌘+I and get some information about the properties of objects, or right click and get to the properties of something via its context menu. Groups (folder icons) in XCode projects have no properties item in their context (right click menu) and yet these groups all clearly NOT all alike. What's up with these identical looking groups?
Secondly, how does a person learn how to reorganize both the on-disk-folder-organization and the visual group organization, in a way that does not leave you bloodied and beaten? (XCode 4 is the most difficult IDE version I have ever used, for this, I'm sure I've missed some important documentation on dealing with folders and files and so on.)
Update: The File Inspector (Identity Inspector in Utilities menu) is the key to this mystery, but exactly how a new user is to discover this (other than by painful experience) is still unknown to me. I also don't really understand what all this is about, with various choices available in the Path drop-down, and the blank or non blank value that has no description or help, just a cryptic icon and either a name of some real on-disk-folder or else a gray text field saying None:
This sort of thing doesn't just happen out of the blue. In this case, what has happened is that a user has opened an .xcodeproj and is unaware of the difference between the various relative or absolute Path options that a Group can be a part of. A Group in XCode is always shown with exactly the same manilla color folder-icon inside your XCode project, no matter what modes or properties it has defined inside of it.
By default the simplest case is that you create a new folder Group object in XCode and it's purely a cosmetic organizational tool that has no disk location information stored in it.
This is not the ONLY thing that these groups do, and not the only "mode" that these groups can be used in. These groups can also be used to point at some folder and say "things that are in this virtual folder are really somewhere else, either underneath this project's main folder in a subdirectory, or even up somewhere else on your hard-drive, either stored in relative path, or absolute path format". When used like this, these things remind me of a Windows "Shortcut" object on the desktop, or a Mac "Alias" object in the finder.
Dragging a file from one group to another does not move it to a different folder on the disk. It simply moves a reference to a file with a certain name, to another group, which might mean that after you drag a file, you haven't really moved it, or copied, or relocated it in any way, you've just moved an alias from a place where it could resolve properly to a real file, to a place where it can't. Thus XCode helpfully turns it red for you, without any helpful error message about what happened.
How do you fix it? In this case, go to the Identity inspector pane in the Utilities menu, and either decide to clear out the bogus value in the place where I have shown in the picture in the original question where I had "Classes". Clearing out a value that is invalid is not exactly easy to do because XCode requires that you basically find the root folder of your project and select that, and that will 'clear" the relative or absolute path property on your folder-group.
Alternatively, you can leave the folder alone, and just don't drag files from group A to group B without first checking what relative or absolute path they reference.
What still seems horrible to me is that XCode tutorials tell you to "use XCode to manage your project's contents, don't just drag files around in the finder inside an XCode project directory", and that's good advice, but it leads me to assume that XCode provides full and intuitive physical (and virtual) group-folder organization tools. It does not. As an example, imagine you inherit a project that has .m and .h files scattered through four physical folders underneath the main XCode project folder and you want to move those files around. You have to do a combination of tricky things inside XCode, and either in Terminal or in the Finder, in order to reorganize your folder. With the complications involved in moving items around in your version control tool of choice added upon the top of that, and XCode's very limited support for only Git and Subversion, you have a really tricky mess.
I've a question. I cannot find the way, how to add buttons to main toolbar programmatically. My problem is, that I've the task to dynamically (based on XML configuration file) build menus and toolbar. I found how to add a menu item programmatically, but not toolbar button.
Tutorials mostly show how to create buttons and menus using plugin descriptor (plugin.xml), but not how to do it programatically. It seems, that it is out of bounds of Eclipse plugin philosophy.
I've just found this:
There might be layout problems with this approach. I also don't
believe the framework will try and re-create your dynamic item except
at random toolbarmanager updates. With Menus they can be updated on an
SWT.Show event, which is why CompoundContributionItem only applies to
Menus.
What shall I do? Can I say Sorry, there is no way to build toolbar dynamically. I can do it just for menus? Collegue says, that it must be possible, but he does neither know how.
The only way to be able to create main toolbar entries programmatically is in an RCP app, where you supply the ActionBarAdvisor for the workbench window. This isn't dynamic, however, just called on window creation.
Another way to do it would be to use org.eclipse.ui.menus and contribute org.eclipse.ui.menus.ExtensionContributionFactory. It also works only on workbench window creation (not really dynamic), but you could read your own XML and provide IContributionItems for the main menu or toolbar.
How dynamic are you trying to be? Most solutions work well on startup/window creation.
PW
Whenever you try to do something programmatically in Eclipse that is normally done through plugin definitions you are walking on thin ice. I've tried it on a few occasions and it rarely ended up being easy or good.
Instead, think of what it is that you only know at runtime and need to be able to change on the fly. Is it the name or icon of the button? That can be changed at runtime.
Take a look at runtime commands, they can be confusing to define properly, but with them you can for example create buttons that are only visible if a condition is active. That condition could be set at runtime.