Jump to content

wolph

Member
  • Content Count

    66
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by wolph

  1. I've implemented a version of it but I have to be careful not to break anything else. The syntax is "... to/from/diff/difference/change ..." and "... percentage of ..."
  2. Percentages were already somewhat supported but not in the way you're currently using them. Currently they're only part of ratios (i.e. parts per million) I've created a new version that supports pretty much all of this but it ignores the $ sign since there's no currency support yet.
  3. A (temporary) solution could be to use the unit converter I wrote: http://www.alfredforum.com/topic/5256-advanced-calculator-with-fast-off-line-unit-converter/ It's a lot faster and functions without an internet connection and it supports Alfred 2 without a problem. I should note that it probably supports less features so it's a small trade-off
  4. Well, it's just one possible option and not necessarily we should include. But I mean the other way around. This could be a shortcut to definining Alfred scriptfilters from the Python code itself. Instead of having to modify the plist yourself by adding a scriptfilter through Alfred you could have it automatically add a scriptfilter to the plist file using this decorator.
  5. That's a very good point. I think you are right, that is most likely the most convenient option here. Fully generating the files might not be that useful but some part could be. To make the creation of new packages easy it would be very nice if developers could do something like: @alfred.scriptfilter(keyword='spam') def some_function(query): pass That would automatically link that function to a scriptfilter using the specified keyword. Once it's generated there's no real need anymore so everything can be edited by Alfred after that but it can make the link between Alfred and the Pytho
  6. That's indeed interesting information, thanks I suppose that would have to be included somewhere as well but I'm not sure what would be the best location. I don't think the entry_points would be a great fit. Personally I would recommend the usage of MANIFEST.in alone and simply ignore package_data. They largely overlap in functionality and I would argue that the MANIFEST.in system is easier to interpret as it doesn't offer any mapping/rewrite options. As for a better tutorial, chapter 15 of my book covers the usage of MANIFEST.in but I'm not sure if it's that much clearer... I'l
  7. Noted and edited in the first post True... the documentation about extra files is lacking to say the least.The most useful documentation to me is the Python 2 documentation. For some reason this was removed with the Python 3 release unfortunately but the Python 2 docs are still available: https://docs.python.org/2/distutils/sourcedist.html#commands Given a bit of well documented boilerplate it might be enough for beginners. Alternatively, perhaps the cookiecutter package could help to make a simple create-a-workflow wizard: https://cookiecutter.readthedocs.org/en/latest/ I would pers
  8. Perhaps it wasn't meant as such but that's what I felt given your earlier reaction in this topic. It's probably just a matter of backgrounds, I have little experience in the Alfred world but a lot of experience with regular Python packages. With regular Python packages the workflow is generally as I suggested but that might not be the best fit for Alfred packages of course. It has given me an idea for an alternative solution however. Let's continue the discussion here: http://www.alfredforum.com/topic/8765-packaging-python-workflows-would-a-setuptools-command-be-useful/
  9. There are currently several methods for packaging workflows, all with advantages and disadvantages of course. For example: deanishe uses a script similar to: https://gist.github.com/deanishe/b16f018119ef3fe951af documents the export function within Alfred itself: https://alfredworkflow.readthedocs.org/en/latest/tutorial_2.html#sharing-your-workflow shawnrice appears to use a shell script: https://github.com/shawnrice/packal-updater/blob/master/alfred.bundler.sh Wolph (me) uses a Makefile: https://github.com/WoLpH/alfred-converter/blob/master/Makefile It seems to me that there is a better s
  10. Well, compared to having a fulltime job, writing a book (https://www.packtpub.com/application-development/mastering-python), renovating a house and moving to that house (last friday) it should be a bit more quiet
  11. I'm still around. My apologies for not getting much up and running yet, my life has been a crazy rollercoaster ride the last year and a half... I hope/expect it to settle down a bit the coming months. Although I am about to become a father so not entirely sure about that either The only thing I didn't like was your condescending attitude. I realise that you have been a tremendous help for the Alfred community and I respect you for that but I if you're not open to discussing alternative solutions to common workflow problems... well, let's just say that limits my usefulness with your pro
  12. That's currently not directly supported, but it's easy to work around it. Just type "6' in inch" followed by a tab, it will give you the size in inches straight away. After that you can simply add them I've added it to the todo: https://github.com/WoLpH/alfred-converter/issues/5
  13. Wow, works great Thanks Andrew! As for losing focus, while that's indeed an annoyance it might be preferable behaviour to the potential bugs after fixing it. Switching applications and purposefully defocussing Alfred might not be possible otherwise. At the very least that should have to be configurable.
  14. Brilliant, Alfred is all I care about really, I rarely use QL anyhow.
  15. That's unfortunate Is there any other way to work around this issue? Not having Alfred on-top is quite inconvenient at times
  16. Ping Still not working with the latest version of Alfred and MPV
  17. One application to test with: mpv Just run: mpv --ontop [some_video_file(s).mpg|some_photo_file(s).jpg] Would be a lot more usable if it'd be always in front The relevant code from MPV: https://github.com/mpv-player/mpv/blob/efe0fb75bc4bc3572edd241e60f31d620413a919/video/out/cocoa_common.m#L395 s->window_level = NSMainMenuWindowLevel + 2;
  18. What I personally do (and which will probably work for deanishe as well) is have a computer connected to the TV which has Airserver installed. Airserver is a full Airplay server for both video and audio (even lossless) so it works perfectly for iphones and even macbooks. With that you can keep the current setup and speakers and only requires you to buy Airserver but beyond that it gives you all the needed options.
  19. That's weird... it works just fine for me, can you try with this release (I've just uploaded it): https://github.com/WoLpH/alfred-converter/raw/master/unit_converter.alfredworkflow
  20. Right now it's just using the mathematical method of calculating (which means that `(5)(6)` will default to multiplying). And as a side-effect, spaces also multiply I guess To change this to addition instead of multiplying you just need to replace the * with a + over here: https://github.com/WoLpH/alfred-converter/blob/master/converter/safe_math.py#L25
  21. That's definitely annoying... reading those reports though... I do think it might actually be the underlying driver that's responsible for the issue, but it's quite possibly being caused by PySerial. Regardless, if Python is not the best option, other languages can do as well It's actually not that difficult of a script to write, although the network version is slightly more difficult due to the auto detection of the receiver through broadcast messages. I've been making it far too complicated with an automated setup and everything... resulting in nothing really working right now. Argh...
  22. I'm currently writing it in Python using Dean Jackson's workflow library with the Onkyo-EISCP library from Miracle2k (https://github.com/miracle2k/onkyo-eiscp). The commands between the serial version and the network version are luckily much the same, it's just a different socket and the network version requires some magic packet Onkyo obviously didn't need any performance here... 9600 baud, wow
  23. Just a little update, I've been working on it but I'm a little unhappy with the available libraries for Onkyo control so I'm probably making it more complicated than needed No worries though, I'm still working on it Just swamped with work as well.
  24. 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 th
  25. 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
×
×
  • Create New...