Jump to content

Recommended Posts

Does anyone know a good way to make a HUD? In my WHW workflow, I created a way to display the results via a quicklook debugging command, but I want to make it much better. I've looked into the automator action "show website pop-up," which basically created a HUD via a webpage, but it's not so elegant because, in order to include it in a workflow, I'd have to create a sort of "firstrun" script that would update the plist for the automator "application" in order to make it work for each person.

 

Basically, I'd like to be able to create something like this: (http://www.grandtotal.biz/CheatSheet/). Or, another way to do it would be to create a version of the Large Text notification that would be dismissible with an escape key but that would be able to display a html file or something along those lines.

 

Any help? If I can figure out how to do this, then I'll probably abstract it and release it as a library for other workflow developers to use.

 

Shawn

Share this post


Link to post

Oh, and if you know of a way to create a quick dialog-esque box that I could use to collect a bit of information that would then be passed to a script to write a file, that would be awesome too. Since php isn't enabled on everyone's mac automatically, I can't rely on the native webserver to create a dynamic php form that would do this sort of thing.

 

It would be best if the box could be populated with some XML, json, or an html file so that the values aren't hardcoded and can easily be abstracted for others to use.

 

Let me know any ideas that you'd have.

Share this post


Link to post

I think that the entire purpose of Alfred's results is exactly this ... to display results. Wouldn't creating 'another' display window defeat the purpose of Alfred?

Share this post


Link to post

Well, my main goal with this is to display a static help file that is generated to give information about all of your installed workflows. The boxes to display results aren't large enough to be able to present the necessary information, so it doesn't defeat the purpose; it just creates another tool to make Alfred more helpful.

Share this post


Link to post

Well, my main goal with this is to display a static help file that is generated to give information about all of your installed workflows. The boxes to display results aren't large enough to be able to present the necessary information, so it doesn't defeat the purpose; it just creates another tool to make Alfred more helpful.

 

I've never noticed a situation where php isn't active by default. PHP is installed by default on all Mac's and can be run at the command line without having a local web server running. The majority of my workflows are written in PHP and I never have issues distributing them. That being said, I would think that you could easily use php to generate a static html page, then create a result in Alfred, with type="file" and then you could just use quicklook to to view it.

Share this post


Link to post

Well, PHP is always installed, but the native webserver with php active isn't. So, we can use php from the command line, but we can't use "localhost/somewhere/index.php" on a system unless the webserver has been enabled and mod_php has been uncommented in the apache config file.

 

My current approaches are to use python/php from the command line (via Alfred) to create a static html file to display. Unfortunately, quicklook doesn't allow javascript or much css, so, while it's useable, it's far from optimal to be able to display great markup (that's why in the current version of whw, I included the quicklook markdown generator).

 

My current approach, which is better but not best is to use an exported automator application to display the page in a website pop-up. I might be missing something, but I don't see an easy way to feed the webpage to it because it seems that the file needs to be specified from inside the program. I can work with this by having a first-run script that will open the plist file from the automator application and replace the file to be opened with the correct path for the current user.

 

My current desire to get some interactive window is to be able to generate config files (many users have had feature requests for whw that would need to be configurable). I've had some success doing this with AppleScript pop-up dialogs, but I can't just display them all at once, and they are UGLY! I want to find something that isn't quite so ugly. I know that I could do something easily with a php form to write the config file, but I haven't figured out a way to be able to send the post variable from the form to a script to write the configuration file because I can rely on php only from the command line (again, I might be missing something obvious here).

 

Does that help clarify what I want and what I'm doing? I have a feeling that this request might be unanswerable without me having to dig into Xcode.

Share this post


Link to post

Hello Shawn,

 

We seem to be aiming for the same thing, but I don't think you are get going to get exactly what you want 'quickly' in the forums.  You could look at the 'website pop-up' again; I've messaged you a link that is interesting, that shows an example of what it could be used for.  I played around with this for a while, and tucked it away for use later.

 

I really do believe that your vision of an addon/helper for Alfred, isn't as well received as it should be; for what ever reason that is, your guess is as good as mine.

 

I think you may resort to xcode in the end; I'm new to xcode, but have stared writing/learning to write my own HUD. In a day, I've only got as far as a nice transparent window of any size, that appears where ever I want on screen.  I've added the growl.framework to my HUD.app, and I can send messages to growl from it.

But I'm still driving towards a large on screen HUD which can display a lot of formatted info.  I need to figure out how to get my HUD app to receive input from other sources, such as Alfred.  If you would like to help out, let me know.  It may end up being more than just a better 'Large Type', or a helper app for Alfred; lets see.

 

Best Regards

Share this post


Link to post

I've played with that same technique. One tip for debugging, however (I ran into this): if you want to turn it into an app and distribute it with a workflow, then it needs to be signed; otherwise, for those who have their "trust settings" set high, the application will not open; if you try to open it from the command line, then the error won't be visible, and it will fail silently, causing frustration as to why it isn't working when it should be working, etc...

 

Other than that, the HUD is a great way to go. I do have a bit of trouble getting the focus on it initially, however.

Share this post


Link to post

I think that the entire purpose of Alfred's results is exactly this ... to display results. Wouldn't creating 'another' display window defeat the purpose of Alfred?

Came across this thread while looking for HUD techniques for Alfred.

The thing is, Alfred already has another display window: the notifications area.

So I don't think it's unreasonable to have a HUD display for showing help pages or messages that need more space.

However, the HUD should only allow for one action: close.

It would be great if there was a built-in workflow module that supported this.

Though I can see how allowing the HUD to render as HTML could cause problems.

Edited by MuppetGate

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...