Scenario:
I have inherited a non-ARC project that I wish to refactor.
Problem:
There's a few CF-dependent files (some 3-party) that are screwing up the refactoring.
How can I use the automated ARC refactoring whilst avoiding these troublesome files?
... or do I merely selectively set -fno-objc-arc/-fobjc-arc flags around them in the build phase instead of via the 'front-door' refactoring option?
When you use the Convert to ARC tool in Xcode, you should be presented with a preview of the changes. On the left of that panel is a list of the files that will be changed. Unchecking the files that you want to leave untouched should make the refactoring tool skip over them:
Then add the -fno-objc-arc flag to these files in the Build Phases Pane
and you should be all set.
Related
I've just inherited a large React project. I do not have much experience with React but I'm trying to make some improvements where I know how.
One issue we have is that our main CSS file is huge and one of the main reasons for this is that a bunch of images used in background-image properties have been embedded as Data-URIs despite them being set to relative URLs in the original SASS files.
These images are used multiple times throughout the app and so we end up with a final CSS file that has the same images embedded multiple times!
The application is built using react-scripts build which I believe is the culprit. As stated here:
To reduce the number of requests to the server, importing images that
are less than 10,000 bytes returns a data URI instead of a path.
I don't want this. Is there a way I can disable this? The project isn't using Webpack or any other build tool/bundler. All I have is the scripts in package.json to play with.
I'm not sure if you can do this with a simple toggle, since create-react-app isn't very customizable by design.
In order to change any configuration you'd like, you have a couple of options:
Forking the configuration (https://auth0.com/blog/how-to-configure-create-react-app/), which allows you to modify the configuration but still stay within create-react-app's boundaries.
Ejecting (https://facebook.github.io/create-react-app/docs/available-scripts#npm-run-eject) which will irreversably give you full power over the build configuration (which means you also have to maintain it going forward).
I'm using Visual Studio 2013 with latest Web Essentials. I chose to partition my CSS into separate LESS files, and create a build.less which includes all my stuff. Now when I edit and save for example tables.less, Web Essentials will automatically compile it, adding a lot of "junk" css files to my web project.
I would like to exlude all of my LESS files from compilation except for the build.less one. Of course I know that as a side effect I have to always do a dummy CTRL-S on my build.less, but that's a fair tradeoff for being able to structure my code.
I've checked all of the options of WE related to LESS compilation without success till now. Are there any "hidden" tricks or some LESS preprocessor directives to make it work this way?
Rename the file to start with an _.
I'm considering using less in an upcoming project but have been trying to figure out the best way to work with it while in development.
Usually when developing a site I'll write my html and css then start testing it in the browser, see how it looks, refine, reload, and repeat the whole process until I'm happy with how everything looks.
A crucial part of the process is using the Inspect Element feature in the browser to identify the piece of CSS I need to change. Usually just by looking at the line number I know exactly where to go in my CSS file.
But if I use Less (or any other method of combining/compressing my CSS) it makes the line numbers useless. I know I could use Find to search for the section of code but line numbers are much faster.
This is especially true when working on a project that involves other developers or large CSS files.
I just wondered how others deal with this, or maybe there's a better process?
Minified CSS really should only be going out to the production version of your site. When you're performing tests/changes etc, this should all be done in some test or development version of your site in a secondary server area where you can have the line-numbers version of css available. The same would go for JavaScript. On the production viewable copy, you want it minified. In development, you don't.
In any event, you should always have 2 copies of your css. The first copy is the primary source copy that is your development copy. It has all of your properly formatted styles with line-breaks in it. The other is the very latest minified version of your css that went to production. This will allow you to switch between the 2 files rapidly in the event that you need to work something out, assuming your site uses some sort of templated delivery (layout pages, master pages, or whatever).
The minified version will only be useful in the final delivery. All other needs should use the master copy. It might not be a bad idea to put a configuration in server-side portion of your site that determines what style sheet to use. That way you can simply change a configuration setting and go into a "debug" mode.
I agree with Joel - that's how I handle it. A build script minifies the CSS (and JS) before each release is FTP'ed to production. I just have a switch in PHP like:
if ($config->prod()) {
// incldue the minfied css
} else {
// include all the original files
}
Personnaly, I use an ant build script to make a production version:
it "condense" multiple css files in one
then it minify them with YUI compressor
same for scripts
(page recomposition to point to the newly generated files)
this way you divide your http request for those files, and gain some bandwith from 30% to 70% i'd say. depends on gzip also.
in my case, the dev version have:
18 css weighting 178ko
reduced down to 1 css at 96ko in the production version
I personally use tools to minify and inject the CSS into the browser each time i save my Less file. So i see each change immediately. This way it's pretty clear what just happened. I don't need the referencing line numbers that much any more.
I recently started using source maps, to see the correct file and line numbers (of my less files) when inspecting CSS in the browser again. I think that is what you are looking for. I personally don't need this extra fanciness that much.
I know, this has been asked a few times, but mostly for Xcode 3.x. For the iPad, I have two projects both living in a common workspace
Foo, a view-based application and
Foolib, a static Cocoa-Touch library
the former depending on the latter. I seem unable to work out how to add that dependency. It's not well explained in the documentation, so I tried the following:
Click on the Foo project in the Navigation Area on the left,
Select Build Phases up the top and expand the Target Dependencies section
Click the plus button, but the resulting list is empty.
I have also tried to drag/drop the .a file into that section, with little success. Also, the documentation states
If the build product of one project in a workspace is dependent on the build product of another project in the workspace (for example, if one project builds a library used by the other project), Xcode discovers such implicit dependencies and builds in the correct sequence.
I wonder how Xcode discovers those dependencies. Is Apple saying I don't have to add this target dependency at all? But then how would Xcode discover that one is using the other?
Last but not least, I will need to get the .h files from Foolib across to Foo somehow. What is the recommended way of doing that? Obviously, I don't want to just copy them. With frameworks the header files come included, but what do people generally do when working with static libraries that they themselves develop in parallel.
A nudge in the right direction would be much appreciated. Thank you.
In general Xcode 4 seems to discover the dependencies automatically as the Edit Scheme sheet implies. Other developers have mentioned that the dependencies are not automatically discovered and require explicitly listing them:
So, Edit Scheme -> Build -> add targets from your workspace.
As far as the static library header files go, Xcode 4 seems to have a problem, at least with code completion and syntax highlighting. The only way I can get either to work properly with classes in static libraries to to drag a copy of the header files in question to a location into a group folder in the main project. Note that you should uncheck Add to Target... That takes care of the syntax highlighting and code completion. The rest should be handled by giving it the proper header search path. That would be User Header Search Paths = $(BUILT_PRODUCTS_DIR) - depending on how you set up your locations preferences.
See: this link
I want to change some of the built-in styles contained in a Plone 4 installation, and a reading of the docs tells me that the best way to do this is to copy the base_properties.props file to SOMEWHERE in the file tree, and then to modify it.
A thorough search of this Plone system shows two base_properties.props files, neither of them in the file tree of my custom skin. So, I guess the first problem is to figure out WHICH of these files is active. I am not sure - how to tell easily?
The next problem is WHERE to copy this file into my custom skin file tree. The existing folders are: Skins\custom_images, Skins\custom_js, Skins\custom_styles, Skins\custom_templates. Should the base_properties file then go in the Skins\ root?
I want to change the defaults for things like evenRowBackgroundColor - without modifying the main base_properties file, as I gather that will make site maintenance a bit more difficult down the road.
Sorry if this is rudimentary, but I find myself spending lots of time figuring out how Plone works - and not too much time actually doing any styling...
In a default Plone 4 installation neither of the base_properties.props files is active, because the default "Sunburst" theme doesn't use base properties.
If you're using the Classic theme, then you want to copy base_properties.props from the classic_styles skin layer in the plonetheme.classic egg.
As for the question of which folder to copy into, I would probably put it in custom_styles, since it is related to the styles applied. It doesn't really matter though as long as these custom skin layers are ordered above the layer that you are copying the file from. To check on the order of the layers, go to portal_skins in the ZMI and click on the Properties tab. This lists the layers of each skin, in order of precedence.
As David Glick says:"To check on the order of the layers, go to portal_skins in the ZMI and click on the Properties tab. This lists the layers of each skin, in order of precedence."
But you want to select the default skin for which you are using basic properties and save it at the bottom. I couldn't get the Sumburst Theme to work so I went classic and used that as default and modified it's basic properties.
What are the full paths of the files that you found? That should give you a clue as to which one you should use.
skins/custom_styles is the preferred location although all of them will work.