Jump to content

wolph

Member
  • Posts

    68
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by wolph

  1. Yes, that would help a bit. The thing is that I don't want my passwords to be available straight away. And the "special" passwords which normally require an extra password/security input should require the entering of the master password again. I'll check the lastpass cli to see if I can add some extra security measures (i.e. small activation code for every password like the lastpass android app does). I'm just a tad paranoid Well... the thing that concerns me mostly is that any app/script/whatever could read the passwords from lastpass as long as it's active. The odds of exploiting this are slim but it's a bit scary to me. Especially since it (I assume) runs in user space. If it was root memory where only specific apps were allowed to read it, it would be different.
  2. Although the new version looks a lot safer, leaving the lastpass command open and unprotected is too much of a security risk for me. Thanks for the great efforts though, it really does work nicely
  3. Is there anything specific you miss with Alfred that Soulver does support? I've recently created a slightly more advanced calculator for Alfred which supports a large portion of the things that Soulver does: http://www.alfredforum.com/topic/5256-advanced-calculator-with-fast-off-line-unit-converter/
  4. True... I stand corrected. Although I do think that Alfred Workflows are not a great representation of the power of a language
  5. No problem, I didn't see any other options without modifying Alfred-Workflow though. I'll take a look at Alfred-Workflow soon, see if I can think of a clean solution. Perhaps I'll try it for one of my projects too.
  6. Perhaps I don't understand how it works, but I seem to be getting "Error: Unknown command ''" a lot. For example, when I type "tgl project" it still shows the "tgl" icon, but as soon as I make it "tgl projects" the command just disappears. So no option to add a project and the same goes for tags. When I do "tgl sync" followed by a return I get the "Error: Unknown command ''" again. Am I doing something completely wrong? The console shows a huge amount of errors without any error message btw: [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:10 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:10 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:10 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:10 loaded cache 2014/12/25 12:04:10 args: []string{"./alfred-toggl", "tell", "p"} 2014/12/25 12:04:10 op: 'tell' 2014/12/25 12:04:10 kind: 'p' 2014/12/25 12:04:10 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:11 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:11 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:11 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:11 loaded cache 2014/12/25 12:04:11 args: []string{"./alfred-toggl", "tell", "pr"} 2014/12/25 12:04:11 op: 'tell' 2014/12/25 12:04:11 kind: 'pr' 2014/12/25 12:04:11 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:11 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:11 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:11 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:11 loaded cache 2014/12/25 12:04:11 args: []string{"./alfred-toggl", "tell", "pro"} 2014/12/25 12:04:11 op: 'tell' 2014/12/25 12:04:11 kind: 'pro' 2014/12/25 12:04:11 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:24 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:24 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:24 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:24 loaded cache 2014/12/25 12:04:24 args: []string{"./alfred-toggl", "tell", "projects "} 2014/12/25 12:04:24 op: 'tell' 2014/12/25 12:04:24 kind: 'projects' 2014/12/25 12:04:24 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:26 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:26 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:26 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:26 loaded cache 2014/12/25 12:04:26 args: []string{"./alfred-toggl", "tell", "projects"} 2014/12/25 12:04:26 op: 'tell' 2014/12/25 12:04:26 kind: 'projects' 2014/12/25 12:04:26 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:27 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:27 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:27 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:27 loaded cache 2014/12/25 12:04:27 args: []string{"./alfred-toggl", "tell", "project"} 2014/12/25 12:04:27 op: 'tell' 2014/12/25 12:04:27 kind: 'project' 2014/12/25 12:04:27 query: '' [ERROR: alfred.workflow.input.scriptfilter] Code 0: 2014/12/25 12:04:28 Using config file Workflow Data/com.jason0x43.alfred-toggl/config.json 2014/12/25 12:04:28 Using cache file Workflow Data/com.jason0x43.alfred-toggl/cache.json 2014/12/25 12:04:28 loaded config: {316397782fb522ae3a43b76ba057bba0} 2014/12/25 12:04:28 loaded cache 2014/12/25 12:04:28 args: []string{"./alfred-toggl", "tell", "projects"} 2014/12/25 12:04:28 op: 'tell' 2014/12/25 12:04:28 kind: 'projects' 2014/12/25 12:04:28 query: ''
  7. To be fair... PHP is not the greatest language for scripts like these. Due to the monolythic core it's too heavy to start/stop constantly. It works but it's far from ideal... Anyone that's serious about programming should give at least one of the different scripting languages like python and ruby a try. After using that for a bit you'll never switch back willingly
  8. That indeed seems like a better idea, having all of the passwords in my lastpass stored as plain text doesn't sound like a good idea. Kind of beats the purpose of using lastpass
  9. Looking at the traceback and the source, one (hacky) option could be to catch the creation of the workflow and trying it without the update: i.e.: try: wf = Workflow(default_settings=DEFAULT_SETTINGS, update_settings=GITHUB_UPDATE_CONF, help_url=HELP_URL) except: # Are there specific exceptions to catch here? wf = Workflow(default_settings=DEFAULT_SETTINGS, help_url=HELP_URL) Ok... somehow this forum screws up the indenting, but you get the point
  10. Jup, TextEdit is really crappy... I've just replaced it with a symlink to Vim now As for the error, just having a default file and a try/catch around the loading of the personal settings file would help a bit already, but only for the reposettings command I guess.
  11. True, but it required a bit of searching to find the config now the problem was that somehow the default json editor of OSX used curved quotes (which was not visible in my font). Guess that teaches me to edit files with anything but Vim... Guess I never do a regular open on json files...
  12. Awesome workflow, found a "bug" though. If your json file is incorrect the workflow completely stops working without any visible errors. What's worse, you can't open the settings anymore since that also crashes Here's the backtrace: [ERROR: alfred.workflow.action.script] Code 1: Traceback (most recent call last): File "repos.py", line 232, in <module> help_url=HELP_URL) File "workflow/workflow.py", line 944, in __init__ self.check_update() File "workflow/workflow.py", line 2168, in check_update if not force and not self.settings.get('__workflow_autoupdate', True): File "workflow/workflow.py", line 1378, in settings self._default_settings) File "workflow/workflow.py", line 802, in __init__ self._load() File "workflow/workflow.py", line 813, in _load for key, value in json.load(file_obj, encoding='utf-8').items(): File "json/__init__.py", line 290, in load **kw) File "json/__init__.py", line 351, in loads return cls(encoding=encoding, **kw).decode(s) File "json/decoder.py", line 365, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "json/decoder.py", line 383, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded
  13. Is there any reason that the "lpvm.rb" file is not on Github? When it comes to lastpass I'm a bit careful of course
  14. It's just a matter of taste. I personally find it clearer if everything is visible in Github straight away. Personally I don't see many problems with it either, I think it's a good thing to have a readme file in the workflow anyhow As far as I know (correct me if I'm wrong) the only file needed in the base dir of the repo (in that case) is the `info.plist`. And arguably, depending on whether you want to store the png files in your git repo, the `icon.png`. Beyond that everything can be in any (sub)directory you choose I initially tried that, didn't work for me. I had to generate the PNG files to make it work.
  15. For the svg files I would argue that you simply put ".svg" in the blacklist for workflows, there's no point in having them. Tests are usually in a tests directory, so that's just a simple blacklist as well. Scripts to generate data files... thats a gray area, for the units library I actually generate the data file on the fly at the first run of the extension. So the actual data file is included but the generated binary version (which is pickled so it can differ per system) is not. If the png files are generated from the svg files you could argue that the png files shouldn't be in the source control either and should simply be generated when building the package. Currently (and mostly for testing) I keep the png versions of the icons in the repo. But generally I wouldn't keep any file that's generated by another file in the repository. That would mean the png files will be generated from the svg files upon building the "alfredworkflow" file. Perhaps I'll start working on a simple build script to help a little with the initial setup as well. Yours looks really nice so that would be a great start
  16. True, perhaps hiding is not the right word. It's indeed just a matter of preference, I generally prefer to keep things simple. Source straight up in the source control, if it's not source, it shouldn't be in the source control imho Apologies if I appear a bit hostile, I've had a bad couple of days. Was just looking for an interesting discussion
  17. Git is by definition a source control management system, hiding your source in a separate directory seems a bit backwards to me. It's actually a bit weird to store binary files in your git repository, admittedly I do the same since I was too lazy to upload it as a release in Github but that should be the proper flow. As I said previously though, you don't have to bother with blacklists or whitelists to make it work. I looked at your repositories and there wasn't any need for fancy stuff. No need to agree with me but it still doesn't make the structure needed. Perhaps I don't understand what you are saying though, because I don't really understand what a list of ignored filenames and extensions have to do with a directory structure.
  18. In that case a keyword won't do the trick. You'll have to use a scriptfilter. With a scriptfilter you simply modify the "arg" parameter and you're done
  19. You could use the mod argument for that See the docs: http://support.alfredapp.com/workflows:config:inputs-script-filter#toc15 <subtitle mod="shift">Subtext when shift is pressed</subtitle> <subtitle mod="fn">Subtext when fn is pressed</subtitle> <subtitle mod="ctrl">Subtext when ctrl is pressed</subtitle> <subtitle mod="alt">Subtext when alt is pressed</subtitle> <subtitle mod="cmd">Subtext when cmd is pressed</subtitle>
  20. That approach would mostly already work for me, all of my source is already in a separate directory due to using python modules. Having that said, I understand your rationale but I don't see too much benefit. Simply ignoring some extensions and ignoring everything in the .gitignore should do the trick already. Having looked through half a dozen of your repositories ( https://github.com/deanishe?tab=repositories ) I haven't found a single one that wouldn't work by having a single list of ignored files/extensions for all of them. And if you're afraid of filtering out files that should be there, blacklisting instead of whitelisting usually does the trick Just removing all hidden files takes care of most, adding the .gitignore and .alfredworkflow should take care of the rest. Just in case you are still afraid of missing files, if you hook up Travis or something it would be pretty easy to automatically test the build. You would have travis run the tests on the .alfredworkflow file instead of your normal repo of course but at least you have fully automated testing.
  21. Andrew, can I propose another option? Just pass everything along through stdin With an EOF when Alfred closes.
  22. There's actually a potential positive effect to using daemon here, keep alives. Not all languages close the http collection properly so the current approach could open too many connections. In many cases it's probably to complex though. If anyone has a nice use case I'm willing to give it a go
  23. That's good point, didn't really think about that. But I don't think just moving the source files helps enough (at least, not in my case). For me there are other files like tests, test coverage files, gitignore files, temp stuff and more. Having a proper build command which filters the non-needed files is always a good idea Guess I'll start making one for my workflows.
  24. I never said it's without flaws. If the results are indeed too slow to return within a set period of time (whatever time you want to wait in your scriptfilter), it won't return. This can easily be solved by sending the result to a different command in case the user wants to wait longer. The standard way Alfred works is like this: 1. you start typing 2. alfred starts processing the first input 3. alfred waits until your script is finally done processing and it will simply display no results until it's done 4. after the first scriptfilter is finished processing, a new process launches with the current input and the input from the first one is displayed 5. repeat 4 until the user is done typing and the results for the last one are displayed Using the system as I proposed has the flaw that if it's too slow it will never display the results. But it does have the advantage that you can ignore many subsequent requests and implement some rate limiting as to not kill the API. Guess I should have explained it differently, I'm proposing to process everything from a queue. Not kill the existing connections. The situation is not the same as it is right now though. A few advantages: - You can always return results in a timely matter, regardless of how fast the API is. - You can implement rate limiting for the API without losing too much responsiveness. - You can give users the choice to wait for an long time if they want to. I never proposed concurrent requests or killing requests, that would indeed be bad
×
×
  • Create New...