Incomplete Query

[xtin]

I'm writing a skype extension and whenever i press enter before the last refresh (a refresh takes maybe 100-500ms) is over it will not send whatever has been typed in the meantime, ending up in incomplete messages. Is there a way to make sure that the actual query in the typing bar and not the one from the field will be passed on? (ideally we could select the behaviour, as both have their justifications.)

[jdfwarrior]

Unfortunately there isn't a way to do this. This is a result of the delay in your script returning valid results back to Alfred. Alfred doesn't know the difference since your script has already returned actionable results that are valid.

[xtin]

I know, maybe move this thread to requests to add a checkbox "reevaluate query on pressing enter" (I'm aware that you can do weird stuff with this, but it also adds some exciting possibilities) to the script filter.

[jdfwarrior]

I know, maybe move this thread to requests to add a checkbox "reevaluate query on pressing enter" (I'm aware that you can do weird stuff with this, but it also adds some exciting possibilities) to the script filter.

 

I did actually move this for a second and then thought about it, even if you "re-eval the input when you press enter", that still won't fix the issue. The issue seems to be a lag in the script producing the XML feedback. Something in the script needs to be optimized. If you add that option you recommended, then it still hasn't actioned what you want because the script hasn't generated results for that input yet.

 

Does that make sense?

[xtin]

No Let me do an example:

 

You type a message for skype, and the script continuously polls the last 5 messages in the last discussion you had with a user (this takes maybe 500ms), the action for all of these 5 entries is the same, namely it forwards what you're currently typing to a next script that actually sends the query to a user. Right now, while you write, what you write has to be included in the query of the entries (i.e. the message you are composing is part of the reply.) because that is what is sent to the next step as {query}. And since it only reevaluates every 500ms, the {query} will represent the message that you entered up to 500ms ago. 

 

There are three ways to remedy this, 2 of which need a feature change.

1.) A checkbox for scriptfilter "return current entry string as {query}", which simply forwards the content of the typing field as a {query} instead of what the currently selected item has as reply.

2.) A checkbox for scriptfilter "evaluate upon sending", which will perform an evaluation of the scriptfilter script after the user has pressed enter with the current state of the typing field. Then it returns the entry the user selected (so if the user selected the first entry it will return the answer of the first item in xml)

3.) Some caching magic to speed up everything, where you either spawn an updater process that works independently of alfred and writes its state to a file or serve static content after it has been fetched once. 

 

My original solution was 2), it has a few serious short comings (e.g. what happens if the user selected the 5th item and reevaluating the script yields only 4), where 1.) seems very clean and easy to understand to me, which is what I would suggest as a feature request. 3) Is either annoying and hacky as it will lead to all sort of potential problems if a sort of background process is spawned or a feature degradation, where new messages can no longer be polled while you write. 

Edited March 24, 2013 by xtin

[jdfwarrior]

No Let me do an example:

 

You type a message for skype, and the script continuously polls the last 5 messages in the last discussion you had with a user (this takes maybe 500ms), the action for all of these 5 entries is the same, namely it forwards what you're currently typing to a next script that actually sends the query to a user. Right now, while you write, what you write has to be included in the query of the entries (i.e. the message you are composing is part of the reply.) because that is what is sent to the next step as {query}. And since it only reevaluates every 500ms, the {query} will represent the message that you entered up to 500ms ago. 

 

There are three ways to remedy this, 2 of which need a feature change.

1.) A checkbox for scriptfilter "return current entry string as {query}", which simply forwards the content of the typing field as a {query} instead of what the currently selected item has as reply.

2.) A checkbox for scriptfilter "evaluate upon sending", which will perform an evaluation of the scriptfilter script after the user has pressed enter with the current state of the typing field. Then it returns the entry the user selected (so if the user selected the first entry it will return the answer of the first item in xml)

3.) Some caching magic to speed up everything, where you either spawn an updater process that works independently of alfred and writes its state to a file or serve static content after it has been fetched once. 

 

My original solution was 2), it has a few serious short comings (e.g. what happens if the user selected the 5th item and reevaluating the script yields only 4), where 1.) seems very clean and easy to understand to me, which is what I would suggest as a feature request. 3) Is either annoying and hacky as it will lead to all sort of potential problems if a sort of background process is spawned or a feature degradation, where new messages can no longer be polled while you write. 

 

Even the re-eval on Enter still isn't going to solve anything though as you are actioning item that YOU generated in your script. So the re-eval on enter, the most that would do is send the finalized string to the script one more time to generate results again, once again leading to a lag in the script, and then once it produces results, you have to press enter AGAIN, to actually action it.

 

I know that, replacing the arg with that the user has entered seems like a valid way to solve it, but it isn't. That may solve one simple use case but a lot of results/args are dynamically generated based on the input. They aren't the actual input. 

 

Once again, I would suggest attempting to optimize the script. The script producing the XML is the bottleneck in this situation, not Alfred

[xtin]

For reference, I'll be talking about a Workflow like this: ScriptFilter -> Script -> Open URL/Display Message/Copy to Clipboard...

 

There's nothing to optimize, e.g. every script that relies on replies from a server will have that problem and there's simply nothing you can do to make servers respond fast enough. (Yes, I could do what suggest in 3) but oh boy... that will be pain and still not elegantly solve the problem.)

 

Now, my suggestion of simply having a checkbox that makes ScriptFilter send the input to the Script instead of the return value of the selected item, will solve the problem for many use cases, namely  Whenever you use the items to display some kind of status or intermediate results and are not particularly interested which item is selected - say, display chat history, do some search, or if you enter a complicated equation in wolfram alpha, you want to make sure the parsing is fine, but in the end when you hit enter to go the website, you want to make sure, that you evaluate what you have entered and not what you have entered a second before hitting enter.

 

Nevertheless, (and here I'm really thankful for your opposition as my feature request suggestion improves with every reply ) the new best (hehe) would be to send both {query} and {input} form ScriptFilter to Script. That's clean, easy to understand for users, seems easy to implement and would empower Alfred to be used for any application where it is important, that what has been put into the input field can be processed in the Script.

 

(I can see why the workflows are implemented as they are, it's easy for users to grasp, easy to develop with and hard to break, however it's also very ugly in some aspects. Say you query some database, what you're essentially doing is opening a database connection every time you enter a script. Same for calling api's - you generate a huge overhead by opening-closing and immediately reopening the connection, sacrificing performance and thereby potential applications). It would be cleaner to have an Interface in every language that needs to be implemented by the programmer with functions such as "OnQueryEnter(), OnQueryUpdate(), OnQueryAutoComplete(), OnQuerySubmit(), OnQueryExit() and OnQueryError()" allowing the script to run all the time. Then you could open a Database connection at OnQueryEnter() update every 500ms and close it on (Exit,Submit and Error), in the mean time Alfred could call OnQueryUpdate() whenever the user presses a button and the script could just spit out the last fetched state, making interaction swift at all times. However at the cost of considerably more complex workflow development and potentially scaring away people with good ideas but less programming experience.)

 

(I created a feature suggestion myself: http://www.alfredforum.com/topic/1470-send-the-content-of-the-input-line-from-scriptfilter-to-the-next-step-as-input/) 

Edited March 25, 2013 by xtin