Awesome v4.3. Trying to launch something in rc.lua.
awful.spawn("xterm", {
border_width = 0,
titlebars_enabled = false,
tag = "2",
placement = awful.placement.bottom_right,
})
xterm spawns, but the listed propertis make no effect on the xterm window.
Am I missing something?
xterm doesn't support the startup notification protocol needed for this to work. Please consider rxvt-unicode (often called urxvt) as a drop-in replacement. It is often faster than xterm and has more features.
If you really want xterm, the client.startup_id documentation provides a workaround to force applications that don't support startup notification to work anyway. In some case, this patch can make the problem worst so it cannot be applied by default. Using applications that comply with the protocol should always be the first choice.
(note to other people reading this in the future: Please consider upgrading to awesome 4.3 or newer. AwesomeWM 4.0-4.2 has a bug regarding this feature and the execution order of the property can clash with the one provided by the awful.rules)
Related
I'm currently trying to make some speed improvements to one of my sites, and I'm looking at Modernizer usage.
Previously all of my javascript (including Modernizer) was lumped into one big js file. I've now removed Modernizer and it sits inline in the head section of the page. For clarity, it is a custom build.
However, not all feature detects are equal - some features benefit from being detected quickly while others can wait.
For instance, detecting webp support is pretty important, because I assume downloading a jpeg then another webp version sort of defeats the object of the feature.
Then, there are things like pointer/touch support, which don't affect layout as such and are more to do with interaction - so they can wait.
With that in mind, the obvious thing is to put two instances of Modernizer in the page - one for the important stuff at the top, and one for the rest at the bottom.
However, I've been unable to find anything on this topic. I guess that leads me to ask two questions: is it possible? And if it is - is it a sensible idea?
It definitively is possible to have two instances of Modernizr on one page; but in order to have that you have to manually rename the global object to something else since Modernizr is exposed to window directly:
e.Modernizr = Modernizr // e is internal ref. to window object
}(window, document);
This however may be considered a dirty patch since you have to alter the production code (& to maintain that alteration through update cycles manually), download and execute exactly the same basic functionality twice, which is less optimal.
Another approach would be to build all that is needed immediately for first batch of (essential) tests and than to utilize Modernizr.addTest (it has to be included in build) later on, for non-essential functionality.
Source and doc-like comments.
Of course, you'd have to write your tests. You may relay on official Modernizr tests, but addTest called outside of the Modernizr's factory method lacks some useful methods (for example, things like Modernizr's internal createElement()).
You have to make choices since there is no way to subsequently add other tests out of the box.
I've been developing a lot of small web development projects in various IDEs, and find myself laboriously typing in jslint configuration headers to silence JSLint. Its warnings and errors are all valid, and I want to keep JSLint in my work cycle, but I spin up 2-3 isolated environments a day, sometimes from generators in Yeoman, other times by hand. These all end up with gripes from JSLint that require the following in every .js file:
/*jslint browser:true*/
/*global require,yada,yada,yada*/
JSHint has a wonderful feature whereby you can declare all these in a parent folder using the body of the .jshintrc file. Does JSLint have something like this? It seems like such an obvious addition, but I can find nothing like this which will work across IDEs (Visual Studio, IntelliJ, Brackets, Sublime Text,...).
I found this for .NET, but I find Visual Studio heavy for projects I might only spend a couple hours on and then throw away (https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings).
Does someone have some insight on this?
Edit: (See my new answer below.)
I think the quick answer is that setting global settings for every file you JSLint is the job of your IDE or favorite text editor. That is, JSLint is essentially just a big javascript file. It doesn't care about file paths, etc, and won't look for a server-wide config.
I mean, you can change the options used when JSLint is called, but that essentially reduces to the same problem you have now.
So then the question is, if you don't like Visual Studio, what tools do you use? In VS, I've used this tool and liked it a good deal. I think that's different (as in not forked or related, but I could be wrong) than the one you found. In Sublime Text, there are two. I've been using Darren Deridder's, but I get the impression that it's the less popular of the two. Etc etc.
So this isn't a javascript/JSLint question so much as a JSLint wrapper question.
It should be said that JSLint's code is very clean, and it's easy to rig up your own process using Node or something similar. I've done it with JavaScript.NET, though I'd use Node if I was doing it again.
And I'd also suggest you consider keeping the file-by-file JSLint headers. I tend to do so, and it keeps your use "excuses" to a minimum, keeping your code tighter. It's way too easy to get a giant /*global ...*/ header line, for instance, if you have a lot of shared config info. It also means that when someone else uses a "shell" tool different than yours to JSLint your files, you know they're using pretty close to your intended accepted behaviors.
So the literal answer to your question is, "No, JSLint doesn't inherently support a box-wide config file." The longer answer is, "Tell us where you do like to work." ;^)
EDIT: Debated staying out of the usual 'Hint vs. 'Lint discussion, but I will quickly say I like how you're thinking. JSLint is more draconian, but JSLinted code means something more specific than code that's been JSHinted. I won't argue that more specific means better, per se, but I will say that I see JSLint's draconian-ness to be an advantage. It might not be the only way to do something, but there's nothing that Crockford's telling you that's a bad idea, and it's nice to get familiar with those conventions. In the parlance of my times, Crockfords's not wrong, Walter.
EDIT 2: So Brackets looks like it's come a long way since I last used it. Seems to have JSLint by default.
It looks like you can set global JSLint options using the jslint.options setting in your preferences file (and there might be/have been a goal to make that a more interactive UI eventually), like this...
{
"debug.showErrorsInStatusBar": false,
"styleActiveLine": true,
"jslint.options": { "sloppy":true, "white":true, "browser": true }
}
And it does allow settings at the top of the file to override these settings.
This really is approaching a golden age of text editors. I still fall back on VIm a lot, but mainly live VS and Sublime Text, with even jEdit, Coda, and PhpStorm for specific tasks. Looks like this might be my new Sublime for Node & html frontend dev. The quick CSS edit is wonderful, though bindings will complicate it. Thanks!
While the previous excepted answer is an excellent one (and many thanks to its author for making it even better over time!), the world has moved on from JSLint. I'd recommend to anyone reading this very old question that you seriously consider chucking JSLint out of your development cycle in favor of its very effective successor, ESLint. For an even better experience, I'd suggest taking a hard look at the ES7 vs. TypeScript paths, with TSLint being your best option for TypeScript linting.
However, for the development experience that trumps even these modern libraries, go directly for Prettier.js. With Prettier, your linting woes become irrelevant, since Prettier will rewrite your code in an opinionated manner every time it's run.
For the best results with Prettier, add the packages "lint-staged" and "husky" to your dev-dependencies, then add the following in your package.json:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,css,md}": [
"prettier --write",
"git add"
]
},
This will force Prettier's auto-linting behavior to run every time Git's commit command runs.
I can't tell you what a relief using Prettier has been for the front-end development teams and projects I am responsible for. We've gone from code reviews bleeding with linting correction comments to zero almost immediately. Feedback from the teams has been universally positive.
The only modification I've made has been to the tabs-vs.-spaces setting. I've modified my .prettierrc.json file to select tabs instead of spaces, because use of spaces at different widths causes dirty git merge histories. You can't control the indentation of 250+ developers spread over multiple hemispheres, some of whom drop in and out of the project before you even know their names. So, setting tabs as the default indentation allows all of the developers to operate with the indentation they're comfortable with without modifying lines in Git. Here's my .prettierrc.json file, with some other slight modifications:
{
"arrowParens": "always",
"bracketSpacing": false,
"singleQuote": true,
"useTabs": true,
"trailingComma": "none"
}
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
RGTK2 block user input while processing its explain how to block user input using RGTK2 but I dont know how to add that code to my GUI code, im using tcltk. What I want same like in RGTK2 block user input while processing but using tcltk2
I use this code to run button "filter cluster" and the command function is filter (function to do something)
tkpack(tkbutton(f4, text='Filter Cluster', command=filter), side='left',padx= 5, pady = 20)
In tcltk, you would use tkgrab.set on a non-responsive window and tkfocus on a window that has a binding on the <Key> event that prevents further processing. An inconspicuous tkframe is great for that sort of thing — set it to size 1×1, but ensure it is on the screen — as it has no default behaviour to get in the way. (You'll also want to make a bunch of cosmetic changes, such as marking the widgets as disabled and setting the cursor to watch.) In 8.6, there's tk busy (call with tcl("tk","busy",…) since the Tcl tk command appears to not have a convenient mapping) which makes this all much easier (though I don't know if/how that's mapped into R). The simplest way to release a grabbed window is to destroy it, but you can also tkgrab.release.
Do not use a global grab. They're easy to get wrong and can cause you a lot of grief. (If you insist, you're strongly recommended to make mouse activity cancel it and to test very thoroughly. Locking up your display is not a pleasant experience!) The default local grabs are less of a problem, since you can switch to another program and kill off a stuck app if necessary.
The full documentation for Tk (and Tcl) is online; pick the version of the docs for the version of the library that you're using, probably 8.5, hopefully 8.6 ('cos it has some nice extras) and possibly 8.4 (old skool!) As the R documentation for tcltk says, you can invoke anything in Tcl or Tk through tcl(…), passing in the words of the command name and arguments as many strings… (Tcl is a naturally var-args language and uses that extensively.) The limited scope of the default convenience mapping should not hinder you substantively.
General advice, not so closely related to your question
Most Tk programmers try to write their code to not lock users out that way if possible. You get a better user experience if you can keep the GUI responsive and instead just temporarily disable (via the state option on most reactive widgets) the parts that would otherwise trigger reentrancy problems for the duration. (The long-running processing might be also event-driven, or put in another thread, or even delegated to a sub-process. Just remember, Tk GUIs are strictly single threaded — the implementation assumes this very deeply, though it's possible to have wholly independent apps in different threads, if rather hairy to get working right — so you've got to come back to the GUI thread to update anything in the GUI.)