With the release of electron 8, I was implementing the newly released spell check API's on my electron app. The context menu should look similar to this:
I was able to implement learn spelling using ses.addWordToSpellCheckerDictionary API given in docs, however I am stuck trying to implement the ignore spelling part.
The difference between the two according to google is
Ignore spelling
The word is ignored if it occurs again in the document (it will be highlighted in other documents)
Learn Spelling
The word won't be flagged as misspelled in any document.
I can implement it such a way that the dictionary suggestions are not shown for a specific set of words stored in array, but that will still leave a red squiggly line below the word. Besides, there has to be a native API call implemented given spell check has been officially announced.
I could have simply used webFrame.setSpellCheckProvider, but then I would have to hard-code a language, add boilerplate code, use a node module.
Try instead using electron-spellchecker npm package:
It has an:
Option to ignore a word at runtime only.
Related
Adding several unused types to the directives property of the Component decorator in Angular2 is the same as adding the correct directives?
I mean, is the compiler smart enough to output the exact same result within the JS file?
EDIT:
I made a tiny test. I added a COMMON_DIRECTIVES and some of my own directives to a component that didn't use all of them. Got both js and used FileMerge to compare. Both are equal. But I will leave this open, maybe someone has more to add.
I have a longer engineering-centric answer here:
https://gist.github.com/matanlurey/0fec1ac15a7a80c898870546123b70b3
tl;dr, as filiph mentioned, we are very conservative. We are looking to address this in a future version of AngularDart, but it will likely be a breaking change.
At the moment, the compiler is conservative about treeshaking these — so adding directives will add their code to the deployed app even if you don't use them. This is because AngularDart can't be 100% sure that you won't be using those components dynamically.
I'd like to easily test my app with different selections of system text size, including accessibility sizes. These can be set in the Settings app (Display & Brightness => Text Size or General => Accessibility => Larger Text).
The only way I can find to currently do this is to go into Settings and change the value with the UI (edit: partial solution described below). This is slow and cumbersome. I suspect there's a way to dynamically alter it using private APIs, but I can't figure out how. Since my goal is to only use this for debugging, private API use and swizzling is fine (this code won't be making its way to production).
To try to find a private API to do this, I looked at some reverse engineering resources. I'm new to disassemblers, symbol tables, class dumps, and finding private APIs I can use, but this is what I've tried so far:
I successfully swizzled -[UIApplication preferredContentSizeCategory] (other posts said this worked in the past), but this doesn't affect the result returned from +[UIFont preferredFontForTextStyle:].
Using the disassembler IDA I discovered that +[UIFont preferredFontForTextStyle:] is in the private framework UIFoundation.framework. (-[UIApplication preferredContentSizeCategory] is in UIKit.framework but the disassembly didn't look at all useful).
Just as I started writing this question (it always happens that way), I discovered a partial solution. One can set a launch argument in the scheme to set the value on launch. This is useful, but not what I'm after.
Through the above answer, I found the value for the user's preference is apparently stored in "the com.apple.UIKit.plist file located in the Simulator's data/Library/Preferences directory". The value we're after can be set from the command line utility plutil. This is also an improvement! But I'd like to dynamically alter it at runtime.
More on my results from IDA:
I don't really know how to read disassembly, but +[UIFont preferredFontForTextStyle:] seems to point to a symbol called ___UIFontForTextStyle which seems to point to some interesting-sounding symbols called _getUIContentSizeCategoryUnspecified and _getUIContentSizeCategoryPreferenceClass
I also found these symbols using the command-line utility nm on UIFoundation.framework. They were marked with the lowercase letter "s" meaning, apparently, "The symbol is in an uninitialized data section for small objects.". I have no idea what this means (all I've gathered is that they're not a class or method).
Searching the web for the _getUIContentSizeCategory... symbols yields nothing, but nearby there's another symbol _getUIApplicationClass. I searched for that one since it sounded a bit more general, and found something similar in some WebKit source. Could be nothing, but maybe it's an internal Apple convention. Regardless, the example doesn't really help me solve the problem.
Anyway thanks for reading so far. If you're still here, my question is:
I'd like to be able to dynamically mock the value for the dynamic type size preference. These disassembly symbols might help, but maybe I'm on the wrong track. It feels like the solution is close but I just can't put all the pieces together.
Setting this value as a launch argument is nice, but doesn't fully solve my problem. Similarly, modifying the Simulator's value in the plist is also nice for automation, but doesn't solve my problem.
Is there a way to dynamically alter this value at runtime?
How embarrassing! I was looking at some out-of-date iOS 9.x documentation and missed that UITraitCollection gained init(preferredContentSizeCategory: UIContentSizeCategory) and var preferredContentSizeCategory: UIContentSizeCategory in iOS 10, which was helpfully pointed out to me by Brandon Williams. This addresses my needs perfectly.
One easy way is to write a wrapper around UIFontMetrics and route all UIContentSizeCategoryDidChange notifications through that. It allows for unit/UI testing various Dynamic Type settings. I wrote about it here.
First of all it's not the duplicate of this question because i couldn't find any discussion about offline documentation, suitable answers and about future release of updates in Xcode there.
Actually I am from android and java background and currently starting to develop iOS apps too. As we all know we use to implement all methods of an Interface easily with the help of suggestions given in IDE by pressing Alt + Enter.
And here in the iOS we have to see the reference each time and search for all required & optional methods, and implement them manually one by one which consumes times It's fine for a moment But
My Questions are :
Is there Any easiest way to view all required method at first lookup in documentation OR implement all required methods of protocol with the help of IDE ?
Is it possible that we will get this feature in future release of Xcode's update ?
I can't be ensure availability of Internet all the time, And How can I see the documentation at that time ?
Just go ahead and declare that your class adopts the protocol in question.
Xcode will point the error if you fail to implement any of the required methods:
From the list under the disclosure triangle (items with gray "!" icons), you can get a hint of the names of the missing methods. You can start to type and autocomplete will do the rest.
Update for Xcode 9:
It looks like now, you can auto-fill the methods with one click:
Refactoring
Rename a symbol in a single file or in a project across Swift, C, Objective-C, C++ files, and Interface Builder files.
View all the possible changes in one editor pane.
Convert method signatures between Swift and Objective-C formats.
Update properties, getters, setters, and synthesized iVars as needed.
Apply a fix-it everywhere with one button.
Automatically fill in missing cases in switch statements, and mandatory methods for protocol conformance with one click.
Extract method functionality for all supported languages, along with other language-specific local refactoring.
(emphasis mine)
And indeed:
Clicking "Fix" adds the necessary method stubs.
Go to Xcode -> preferences(on top-left corner) -> downloads -> here you will see list of items that can be downloaded. Download the documentation for iOS x.x version. So now, whenever you are offline.. you can go to help(top bar in window) -> documentation and search for whole ios documentation.. all the development guides etc
At the moment I'm testing various logging framework for use in Delphi XE 3. Since using Log4Delphi made least problems concerning implementation into existing programs, I'm currently trying to get additional Informations for my logmessages. Now what I want to have are additional informations like method name and the line of code. I've already found the Jedi Code Librarys' debug functions might provide such data. Sadly I wasn't able to figure out hot to get this to work the way I want it.
As it is I'm currently using this function:
function CurrentFunctionName: string;
begin
Result := jcldebug.getlocationInfoStr(Caller(1));
end;
But while the code examples I've found provide data like this:
[004223A7] jcldebugtest.SomeProcedure (Line 10, "jcldebugtest.dpr")
All data I get when I'm trying to use it in my programs looks like this:
(00E8EF63) [0128FF63]
I don't fully understand the reason for this behavior, so it would be very nice if someone could explain to me how to do this properly and where my mistake/misunderstanding is located.
You need to go into Project->Options->Linker, and turn on the Detailed map file, and then build (not compile!) your project. The map file information is necessary to convert from raw addresses to specific locations in the code.
You can test this using the example located in the JCL\Examples\Windows\Debug\SourceLoc folder. If you build and run the SourceLocExample.dpr, clicking the "Caller()", "Address lookup", or "Stack dump" buttons will return simply the memory addresses. Then follow the instructions above to enable the detailed map file, do a Project->Build from the IDE's menu, and run the example again, clicking the same buttons and comparing the output.
You can then (optionally) use the Project->JCL Debug expert to embed the debug info into your executable instead of providing it as a separate file that needs to be distributed.
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.