PDA

View Full Version : Feature Requests


quixote
October 20th, 2006, 09:09 PM
I was wondering if you guys could make a sticky for feature requests. Testers could have a place to post suggestions, and these could be used for G5, or in future versions. Basically an inspirational thread with ideas that can be explored and played around with whenever you guys feel inspired. Nothing in stone; just brainstorming and requests.

Ron
October 20th, 2006, 09:50 PM
Consider this the official feature suggestion thread.

quixote
October 20th, 2006, 10:22 PM
Nice! Thanks, Ron. I have a couple of ideas, but I'll wait till tomorrow when I'm not intoxicated. :D

danward79
October 20th, 2006, 11:48 PM
Nice! Thanks, Ron. I have a couple of ideas, but I'll wait till tomorrow when I'm not intoxicated. :D

I find it best when I am intoxicated to discuss ideas!

quixote
October 21st, 2006, 03:27 PM
I find it best when I am intoxicated to discuss ideas!

Me too, but I get lazy when it's midnight and I've had a few too many.


I have some decent ideas, I think I've probably mentioned some of them in the past, but seeing as there is a new release on the horizon, now might be a good time to review them and add a few others.

1) I'd like a way to hide desktop icons. Mastiff mentioned that a good HTPC should not have any icons on the desktop. I agree, but I'm messy and sometime lazy, and my HTPC is also my automation system and my gaming system, so they tend to pile up. I know this is possible because sysmetrix has the capability to hit a button and toggle the icons instantly. It doesn't actually do anything with the icons; rather it brings the desktop in front of them. I've managed to hide them and show them using a capture:

Message: 273
wParam: 29698
iParam: 0

using send message and targetting Program Manager, but for some reason it only works when I hide them to go into a lockdown mode. When the macro to bring it out of lockdown is fired, they do not show.
This feature could be useful for when you want to make the desktop clean so that others (like the rest of your family) can use it without having to look at the junk that you've accumulated while working on the system. Also, I find it great for my lockdown mode when I don't want my roommate messing with my computer. I hide the icons, hide the start button, hide the system tray (which actually only locks it) and then block the windows key. I also use the mouse plugin to capture the mouse so it can't be moved. Which brings me to my next item on the list -

2) I think that the mouse plugin is so useful that it should be incorporated into the main Girder package. I think that if keyboard events are standard events, mouse events should be too. Pretty much everyone has a mouse. I would also like to see an added feature that is quite important to what I'm aiming for, and that would be toggle mouse cursor visibility. Packages like stardock's cursorXP (I think that's what it's called) have the ability to change the cursor appearance and once a while back I noticed that if you kill that app then your cursor dissappears. That's where I got this idea, and it's obviously possible.

The last two items I mentioned are mostly for front end purposes, but they could have other uses such as access control. Last I checked the screensaver disabled Girder and generally was useless for this type of thing.
Granted, anyone who is good with computers could probably get around the access blocking measures that we put in place with Girder, but we won't be using our systems in public places.

3) This one is not important to me at the moment because I don't use multizone audio, but I think it may be in the future: I'd still like to see use of the audio picker for the "play wav" action and for the "speak" action. This would be immensely useful for status messages and sounds. I ran into this problem a while back while trying to send sounds and speech to a speaker that I had positioned above my front door, both for my alarm system to confirm it was armed/disarmed when I left or arrived and as a sort of intercom system that I could send pre-defined speech messages to people at the front door using a remote such as "I don't want any" and "target aquired" lol just kidding. But there were some useful ones, and I also wanted to make an answering machine type thing also, but I had so much trouble with my audio devices try to switch and switch back all the time, plus the interuptions in my audio stream if I was listening to music or watching a movie, that I abandoned the whole thing.

4) I know that Bluetooth functionalty is pretty much out of the question due to the cost of the licencing for such an undertaking, but this ties into number 3. For a while, Ron, you were trying to get this to work with someone (I think his name was Larry or something) and it showed promise, but then you gave up. I'd like to see you give it another shot because I think that voice recognition is going to become more and more popular, and many of us are using bluetooth microphones. It would be great if Girder could reliably detect the connection of a bluetooth headset. Lots of peopl have them kicking around for their phones anyway, so I think that it seems like the smart way to do it if you want to use voice recognition. No one wants to be tethered to their computer, and good open air mics are pricey.

Anyway I have to run to the hardware store. Thanks for reading.

quixote
October 21st, 2006, 08:15 PM
I didn't have time to include the last one:

5) More display control options. It would be great to have a way to specify which display you want to turn on/off, etc. I can only speak for myself, but I think that more displays make for a much more useful system. I will be building a coffee table for my living room with a screen built into it to display my TV grid and some other controls like lighting etc, and I can foresee that it's going to be annoying if I can't turn off my main display without turning off the second and vice versa. Also, I have my TV hooked up to my system now with an auto video switcher, and it would make it a lot easier if I could turn of the second display (the one for the TV) to switch between different video feeds.

quixote
January 6th, 2007, 10:20 PM
Well, I haven't been around lately and I appologize for my absence (even though I'm sure that most of the time I'm just a PIA).
This is obviously not a very popular thread, but I thought of a couple of requests that I think would be great additions, and I'm hoping that someone will back me up on these:

1) we need a feature in the scheduler that allows us a variance of X number of minutes. I've recently been spending days at a time away from home and it occured to me that the light schedules are waaaaaaay too predictable/observable. We need a way to tell Girder to fire an event at, for instance, 9:00pm +/- 25 minutes.

2) Stop checking for the weather when the weather update is turned off. :P

3) I can't think of number 3. I'll come back when I'm not inebriated. (once again) :D

danward79
January 7th, 2007, 02:30 AM
Well actually now you reminded me of this thread, I have a couple of things I would like to see.


It would be nice to have a button on the lua console to stop scrolling but still allow logging. That way it would not keep moving everytime it got s new entry while tring to read something.
An action to vary a scheduler for 1 trigger by a given number of minutes would be good. For example my HTPC shuts down at about 1am I think. If a recording finishes at 0130hrs, I would miss half of it. In this case I could use the vary schedule action to change it by 30 mins and get my whole show.
I think Dereks No1 should be called a scheduler randomiser :)
It would also be good to see somekind of Motion Sensor Behaviour support. A bit like the homesear mcsMovement & dooMotion plugins. (I am told they are very good, no personal experience!)

quixote
January 12th, 2007, 07:14 PM
I thought of another handy feature, even though it's not very significant. It would be great to be able to name the different simple timers so that you do not accidentally use one that is already designated to an important timer.

quixote
February 1st, 2007, 12:17 AM
How about the ability to use Girder through the phone with the modem?
You could set it up to be an answering machine, but have macro events to send triggers to Girder. They would have to be not only time dependent, but sequential as well. For instance, you call your house, the modem picks up after a certain number of rings and plays the message over the phone. If you punch in your password right away, it would send an event to Girder, (example: GirderEvent PhonePass), then the PhonePass event would be attached to an Enable node action which would enable the Phone functions folder. Then you could play wavs over the phone or use speech that would help you navigate through the menu and each number would send an event to Girder. This way you could control your lights, etc. while you were away and without access to the internet.

What do you guys think?

danward79
February 1st, 2007, 01:00 AM
I use my sms plugin for that! ;-)

quixote
February 1st, 2007, 01:44 AM
I use my sms plugin for that! ;-)

That's cool, I use SMS for my alarm system, but the thing is it costs me almost a buck per message to use, and I can't change my plan. I got a bill one month for $75 when I was first putting together and testing the alarm GML.

:O

Francois
February 4th, 2007, 04:59 AM
Couple of features I'd like to see in Girder 5:

1. A way to print lua script -- Yes, it is possible to export the text into Word or a similar application, redefine tabs, set font to courrier, etc. , but it's far from ideal ;)

2. Improved handling of the (polite) standby and hibernation requests, so that girder would deny these requests if a lua script is still running (Alternatively, providing a bit more time for cleanup time when these events occur would help!)

3. Better handling of Resume events (on my XP machine they don't always trigger when the PC wakes up... pressing a key on the keyboard brings everything back to normal, but the remote doesn't seem to consistently have the same impact)

hoox
February 20th, 2007, 05:12 AM
It would be neat to have built-in Lua functions that persist personal tables/variables.
i.e. the same as gir.WriteConfigTable and gir.ReadConfigTable but for another adjacent default folder...
This could facilitate backups and these variables would be kept in case of reinstall (unlike normal ptable usage).

Rob H
February 20th, 2007, 05:28 AM
Um.. why to a different folder? Why not just use a gir.WriteConfigTable using a different filename?

hoox
February 20th, 2007, 06:04 AM
Not sure what would happen if we use an existing config name by mistake.
I didn't try this actually.

Rob H
February 20th, 2007, 06:11 AM
Well you could put a special prefix in there to ensure that you don't clash e.g. hoox-myconfig

hoox
February 20th, 2007, 06:21 AM
That should do it... Thanks!

Ron
February 26th, 2007, 09:42 PM
* Scheduler Randomizer implemented.
http://www.promixis.com/forums/showthread.php?t=16304

* Mouse plugin inclusion. I will ask John what he thinks about including his plugin.

* Printing from the code editor. I've looked at this and that would be quite a bit of work. I really like the SciTe (http://www.scintilla.org/SciTE.html)editor and can print from there....

* Using Girder through the phone. We have had some internal discussion about this and it will come but there is no time frame set for this.

* I'd like a way to hide desktop icons. Sounds like you have that figured out already.

* Targetted audio output, this one is tricky as vista has a completely new audio stack... so anything we do would be for vista and up.

* Bluetooth audio capture speechrecognition, I don't think we should support that directly, but through the audio drivers that come with the headset. As long as windows can access the headphones + mic you can use the speechrecognition plugin

* It would be nice to have a button on the lua console to stop scrolling but still allow logging -> Sounds good. I'll see.

quixote
February 27th, 2007, 11:34 AM
Our fearless leader has spoken! ;)

Thanks Ron!

By the way, the icon hiding is unreliable. If at all possible, it would be super if Girder had a simple action to toggle the desktop icons. pretty please? :D

JohnHind
March 14th, 2007, 07:12 AM
One feature I'd very much like to see is the ability to tree-script the entire main application window. I envisage this as a third mode alongside "Novice" and "Expert", maybe called "Script". In this mode the presentation would be similar to the Settings dialog and driven by DUI/Treescript in the same way as the Automation section is at present.

I find that I am using Girder more as a Lua scripting/application generation platform and not using the traditional Actions tree very much. It would be nice to be able to leverage the DUI to write Lua applications with user interfaces.

Taking this idea further, on Vista we probably need the ability to store scripts (including treescripts) in user directories to avoid the need to edit protected files in Program Files\Promixis\. Also it would be nice to have a built-in script editor based on Scintilla like the current Scripting Action editor.

Ron
March 14th, 2007, 10:36 AM
Thanks for the suggestion John. This is obviously not going to make it into Girder 5, but I'll take this into consideration.

quixote
April 22nd, 2007, 10:46 PM
At the risk of appearing to be a spoiled brat ;) , I was wondering if there would be any way to integrate the schedule randomizer into the actual Scheduler interface. It would make things a lot more simple and save people a lot of headaches.

danward79
April 23rd, 2007, 02:04 AM
At the risk of appearing to be a spoiled brat ;) , I was wondering if there would be any way to integrate the schedule randomizer into the actual Scheduler interface. It would make things a lot more simple and save people a lot of headaches.

I would say this actually needs to be included in the scheduler, to make the scheduler complete.

danward79
April 23rd, 2007, 11:58 AM
The other thing that would be nice would be able to set the units for everything individually.

For instance

Temp to degrees C,
Speed to Mph
Wind Speed to Knots
etc, etc...

Any chance? I am sure I am not the only one, who would like this.

quixote
May 7th, 2007, 12:09 AM
A useful feature that would save a lot of us a lot of work would be the ability to use a wildcard character in EventStrings, like the good ol' days of DOS.

Eg. - instead of creating a script for each possible key entry for 99 channels/playlists/whatever with events like "playlist01", "playlist02", "playlist03", "playlist04"... you could write one script with the event "playlist**", then grab the last two characters of the EventString for use in your script with something like this:
local Selection = string.sub(EventString, -2, string.len(EventString))

Rob H
May 7th, 2007, 05:11 AM
You can do that - see the help under Lua library reference\gir\AddEventHandler

quixote
May 7th, 2007, 02:10 PM
ah ok. I was looking at that, but it's difficult to understand for someone like me that struggles with Lua (even at a beginner level sometimes). I need a book like "Lua for Dummies" or something. Thanks for the pointer, though.
I still think it would be easier just to be able to put *s in the eventstring, don't you?

quixote
May 16th, 2007, 03:59 AM
By the way, the icon hiding is unreliable. If at all possible, it would be super if Girder had a simple action to toggle the desktop icons.

If anyone is interested, I've found a nice little freeware program that will toggle your desktop icons. Look at the bottom of the page here:

http://www.geocities.com/autohide_hompage/Autohide.htm

Works in Vista, too.

quixote
May 28th, 2007, 11:19 PM
Is device manager going to control devices network-wide? Also, will there be built-in actions to query their states (ie.- return variables)?

Rob H
May 29th, 2007, 06:27 PM
By network wide do you mean with more than one copy of Girder running? That is part of the intention, but the remote device manager hasn't been written yet.

quixote
May 30th, 2007, 12:59 AM
Well, here's the deal:

I bought an Insteon PLC long ago hoping to beta test with the others here but found that the device was causing conflicts with my directx and keeping me from playing games (which, despite having recently becoming "over the hill", I still enjoy doing from time to time).

I resorted to leaving a second computer on 24/7 so now my livingroom is like a freakin' sauna from May to September, and not only that -- now I can't do all the nifty stuff I wanted to without going to a whole lot of trouble. Keep in mind that I have yet to start using Netremote (I plan on doing so as soon as I can buy the PDA of my dreams).

I had set up a GML to handle lighting using my remote wonder and I found it was great, though a little more complicated than it should be. It was my second revision and it used a fair bit of scripting. The simple description is that you hit the button for light mode, it checks to see if you have a light selected from the last time you were in that mode. If so, it says the light name and level with text to speech, if not it asks you to select a light. To select a light you hit a number and it turns the light on at 100% if it is off. If the light is already selected you can skip that step.
you can then hit a number again between 1 and 0 (10) and the light dims or brightens to that level, then displays the name of the light and it's brightness percentage on the VFD of my computer. If you hit the button to turn off the light you jump back to the light selection mode in which case there is no longer an active light so if you leave light mode and come back it will ask you to select a light again. If you return when the light is still active it says the name of the light and it's level with text to speech (as I mentioned earlier).

Anyway, you get the idea.

THE REAL POINT OF THIS POST:
By network-wide I mean all machines running Girder on the home network would control and keep track of their devices so that you could use any machine to control or query the devices. Basically, just use common variables to keep track of device states automatically so that I could just take for example the Insteon PLC and plug it into any machine and still have control of it and be able to get the level of any of my lights from any machine without staying up for 8 days straight writing scripts that don't work because of the SDM. ;)

What do you think of that idea?

jwilson56
May 30th, 2007, 03:40 AM
Well, here's the deal:

Keep in mind that I have yet to start using Netremote (I plan on doing so as soon as I can buy the PDA of my dreams).

I would seriously consider using a GUI frontend on your 'game' machine to control your lights through Girder running on your 'server' PC. Later add a PDA for remote control.

I also believe that the Device Manager's variables are accessible from other machines but I have never used Girder to Girder but can't imaging the variables not being available like they are to a Netremote client.

One thing I would like to see is a Text To Speak remote speaker client application written that could be installed on 'client' PC's so that the 'servers' TTS could then be 'announced' locally through their own soundcards. This way all the TTS scripts would be handled on the 'server' yet any PC could be used to announce messages. For text messaging I use the YAC Server and YACTextSend to broadcast not only my Caller ID information but also any other messages I want. The YAC listener will popup over the top of most games so that I can be alerted to things even while deep into battle.

http://sunflowerhead.com/software/yac/

For more information check out my showcase at:

http://www.promixis.com/forums/showthread.php?p=115902#post115902


John


John

quixote
May 30th, 2007, 04:01 AM
John, you can just trigger a speech action remotely and set pld1 as the announcement, then in the speech action on the remote machine enter [pld2]. It just requires that you set up the aciton on each machine that you want to make announcements on.

jwilson56
May 30th, 2007, 04:26 AM
John, you can just trigger a speech action remotely and set pld1 as the announcement, then in the speech action on the remote machine enter [pld2]. It just requires that you set up the aciton on each machine that you want to make announcements on.

I was refering to a small application that would that sit on the client machines, not Girder itself. This is done with other home automation packages.

John

antrix
June 18th, 2007, 07:57 PM
It'd be nice if you could adjust the length of time before reset on a Macro Event from the default of 5 secs. For most of my macro events, 1 or 2 seconds is more than enough time. I've found that I'm often moving on to my next key combo before the 5 seconds is up, which can cause unintended events to fire. For instance, let's say I have three Macro Events: A+A, A+B, and A+C. If I key A+B and then start keying A+C before the 5 seconds is up, A+A will fire.

NeoMorph
October 20th, 2007, 08:49 PM
I'd like to add my vote to the "Lock the Log Screen Output" as sometimes I try to see what is happening but the continuing events generated by a repeating timer keeps pushing the log entries I want to see offscreen. Rather irritating on the level of "fingernails down a blackboard" I think.

Another little fix I would like to see is the "Maximise" button on the girder edit dialogue. When you try editing scripts sometimes the window pops up and gets resized so I have to manually resize it every time I need to edit. Allowing a single buttonpush to max it to the screen would save a LOT of wasted time dragging the edge of the window and tbh the edge grab is so tiny that 9/10 times I drag then entire window and accidentally drop it onto another window where it adds it to a tab that I don't want.

On that subject can you make it so that ability only happens if you hold down the ctrl key like on other programs. It's useful but currently it gets in the way of editing on smaller screens like my laptop as I have to keep moving screens around to maximise my productivity. Sometimes I like to see the log and lua screens on the screen at the same time, other times I like the lua screen maxed out and other times I like to see the scripting editor at the same time as the lua console. Different layouts for different situations. Perhaps having layout shortcuts would be an idea... say CTRL-1 to CTRL-8 sets a layout and SHIFT-1 to SHIFT-8 recalls it. That would be ideal. CTRL and dragging a window lets you drop it on other windows while just dragging it lets you overlap windowns.

Francois
October 21st, 2007, 04:06 AM
Vista Media Center is very difficult (read impossible) to control via the standard methods provided by Girder, it also offers the ability to send some feedback to applications (see the efforts to develop a 'DVDSpy' like application elsewhere).

Adding a standard plugin to support VMC would be useful as this application is quite good (it should also not hurt the sales of Girder as many people may want to graduate from the standard MCE remote)

just my $0.02

(To put developpers on the right track, MCEController 1.1 is able to control vista through some sort of keyboard emulation, but it requires a telnet session from another machine... not from the same one for some reason)

Ron
October 21st, 2007, 01:02 PM
Unzip the attached DLL and XML file over build 523. And look for the "Keyboard Foreground" action in the keyboard action folder. It uses the Win32 SendInput call, that apparently is honored by Vista MCE. This function uses the same syntax as the "Keyboard" action. Tested here with VMCE.

Francois
October 21st, 2007, 03:11 PM
Ron, thanks for the very quick response... I'm starting another thread to discuss controlling Vista MCE (and Keyboard Foreground)

NeoMorph
October 24th, 2007, 05:47 AM
Can't remember if I asled for this already... We have SetVariable in Girder but not GetVariable. Sometimes it would be nice to read the variables in NR without NR having to send the info in ExecuteAction.

Rob H
October 24th, 2007, 06:24 AM
I agree that it would be nice, but it would have to be synchronous whereas SetVariable is asynchronous. That might have nasty consequences for Girder's responsiveness unless it were done from a thread.

NeoMorph
October 24th, 2007, 06:55 PM
I agree that it would be nice, but it would have to be synchronous whereas SetVariable is asynchronous. That might have nasty consequences for Girder's responsiveness unless it were done from a thread.

I've used RunLua to get NR to send back variables using ExecuteAction but you do have to wait to see if the variable comes back... I'm like 90% of the way there but that last 10% is a sod.

Not being able to check what a NR variable is causing headaches for some of my XBMC logic.

NeoMorph
November 18th, 2007, 01:52 PM
What's the chance of getting that Maximize and Minimize buttons added to windows such as the Edit Action dialog, Log Window and Interactive Lua Console. I'm getting tired of having to resize the windows all the time when they default to weird sizes. In VB it's a pretty simple change of form properties to get the resizing options (ie you only have to change the "MaxButton" property to "True"). That's got to be the simplest fix out ;)

Also I've mentioned this before... can you also change it so that you only merge windows when you hold down the ctrl key (like in other RAD environments). I've merged windows when I haven't wanted to so many times now that's it's silly. I just moved the log window slightly to read something underneath it and it merged with the edit dialog once again. I hate having to fight with the editor when I'm also having problems with my code. It's just one more thing to get frustrated with.

The window moving code seems a bit unstable too. Sometimes you grab the window to move it and it has that grey fuzzy outline and then you move it but it moves only half way and sticks... you then have to grab it again and attempt to move it again. It's not moving the mouse and accidentally releasing the button either because I use a logitech trackball and my index finger is solidly on the button when my thumb is moving the ball. I also just had it move across and then merge with another window and both windows closed. :confused:

Do those fixes and add in the ability to lock the Logging Window output (so you can read an entry in the log without it always jumping to the last entry whenever you are getting a lot of action going on) which was suggested by danward79 and that would be the ideal editing environment imho.

NeoMorph
November 18th, 2007, 02:55 PM
Forgot one REALLY important function that's missing.

SEARCH!...

I just wanted to find out what Actions were triggered by "XBMC-List" in my GML and couldn't find it... turns out I had put the action in the wrong GML and I was looking in the wrong place. Thing is it took me ages what a search function could have done in seconds. Another case was where I had an Event trigger copied from another Action but had only changed the title and not the actual action. So when the Action that I copied the Event from got triggered, so did my other Action. Really confused the heck out of me. In the end I had to go through each action and open up the triggering Event for each one to find the culprit. Now if I had a search I could have done a search for the action that was causing it.

I had thought of watching what action was happening in the log to find what was getting triggered but because there was a lot getting triggered at the time it got lost in the rush of data. What I did to find it was use the debugger finally (what a godsend - Thanks Ron) which let me find the problem. Perhaps you could add the event details in brackets after the event name.

For instance....

http://www.neomorph.net/promixis/wrong-event.png

... where you can see that the event is really "List Music" and not "List Videos". I had basically copied from the "List Music" Action/Event pair and changed them to make them list videos instead of music but hadn't changed the event or hadn't saved it after I did the editing. Having the listing show the plugin ID number and the actual event string would definately aid in development.

Another bonus of a search engine is being able to search for references to variables etc in the scripting blocks. Trying to track down where you have set variables etc would aid in tracking down faulty code. This would also be an excellent addition in NetRemote. I once got an error popping up and it said that the error was on line 2 but I couldn't find where the faulty Lua script actually was. OK it is line 2 but it doesn't explain where line 2 actually was. Turns out it was in only of the Lua State containers - that took me hours to find as I had searched through all the main lua code and all the seperate actions.

One of the instances (a NetRemote one in this case) where a search would have really saved me was when I got a variable being updated and I couldn't figure out why it was getting updated. I was sure the code was correct and I even did I dry-run through the program which took a while (for those who don't know what a dry-run is it is when you print out the program and then use paper and pencil and go through each line of the code and do what it says... ie you become the computer.) The dry run revealed nothing... the code was correct. So it must be something else... and sure enough I found an extra line in another part of the program that had got dropped there by mistake - most probably when the NetRemote API was jumping all over the place.

Now if I had a search I could have told it to list out every location that the variable that was being updated was located. That would have identified the rogue line of code in seconds.

Oops... I'm in lecture mode again... sorry for the essay writing... blame the darn touch typing hyped up NeoMorph. :rolleyes:

I hope these ideas sound logical... If you can make life easier for the coder it's got to be good yeah?

Rob H
November 19th, 2007, 02:43 AM
Searching would be very helpful indeed. One possible workaround for Girder GMLs is to load the GML in an XML editor (it is an XML file after all) and use that to search it.

NeoMorph
November 19th, 2007, 04:16 AM
Yeah... Nice workaround Rob. That will work for the time being for Girder...

Unfortunately if you try it with a NR2 CCF (the one that really screams out for a search function) it gives you the some of the wierdest garbles out there (obviously not XML).

Ron
November 19th, 2007, 08:54 AM
Regarding Search, did you look at 'Find' ?

NeoMorph
November 19th, 2007, 09:13 AM
I must have had a mind block... Never saw the "Find" facility because I was expecting it to be in "Tools" instead of "Edit" in Girder for some reason. :o I think I need some new glasses heh. At least that's one function that I'll be using a lot of (I keep forgetting what events are driving what now that this project is getting bigger).

Can we have an identical "Find" in NetRemote too please :D That's the one that's really a problem when tracking down erroneous Lua code (like the State Lua that broke in my XBMC panel.)

Rob H
November 19th, 2007, 10:42 AM
D'oh! I didn't think of that either!!!

NeoMorph
November 19th, 2007, 05:50 PM
D'oh! I didn't think of that either!!!

Sometimes you focus on one thing to the exclusion of others... I wanted a "Search" and of course my subconcious brain said "Find isn't Search"...

Dumb subconcious :o

NeoMorph
November 19th, 2007, 07:08 PM
It's definately NetRemote. I've tried Lua and none-Lua triggers and they are as fast as each other and both seem sluggish. If you try clicking the button in NR really fast it's only registering a small portion of them... I'd say one every 500ms for a rough guess from a test run I did.

To remove any possibility of any code affecting the test I removed all the GMLs and used a CCF with only two buttons and it made no difference. Here is the output with me clicking the mouse button like mad....

Time Date Source Details Payloads
01:02:15:588 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:15:287 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:15:017 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:14:726 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:14:396 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:14:075 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:13:765 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:13:455 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:13:124 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:12:794 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:12:503 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:12:213 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:11:912 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:11:612 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:11:281 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:11:011 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:10:731 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:10:460 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:10:190 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:09:879 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:09:569 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:09:148 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:08:818 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:08:477 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:08:177 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:07:877 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:07:596 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:07:055 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:06:725 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:06:384 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:06:034 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA
01:02:05:603 11/20/2007 Communication Server EVENT_FROM_LUA 1600 192.168.1.3 EVENT_FROM_LUA


Note it is roughly around 300-600ms between registrations and I was clicking a lot faster than that. So it's not my coding. It could be my network I suppose. I'd need someone else to try the Flatstyle test and the above uberclicker test above to confirm that. Whatever it is, somewhere along the line information is being lost.

NeoMorph
November 19th, 2007, 07:23 PM
I did think of making a VB program but GirderX only supports "TriggerEvent" (which allows you to generate events on the same PC as Girder) and not "TriggerEventEx" (which allows you to generate events across a network) so I can't use it across a network which is a bit of a booger.

Is there any reason why "TriggerEventEx" isn't included?

quixote
December 14th, 2007, 05:54 AM
Can we please have a built-in variable conditional? I'm trying to set my system up to stop/pause my media player automatically if it's playing when I leave my place, and the variable conditional plugin from the download page does not seem to work.

Rob H
December 14th, 2007, 06:22 AM
What's up with it?

quixote
December 14th, 2007, 11:01 PM
well, I've been trying different combinations (string, integer, boolean) with the JRMC stuff that Marquis wrote, using the mc12.status.playback (I think but I'll have to check the variable name -- I'm on my laptop at the moment), which gives me a 1 or a 0, and I set up a macro that would print the variable as well as use the conditional, and regardless of whether it prints a 1 or a 0, the macro fires. If there's anything else I can test for you with it, please let me know.

Rob H
December 15th, 2007, 02:49 AM
How are you testing it? ie are you using an event to trigger it or are you using F5?

quixote
December 15th, 2007, 08:50 AM
I'm using F5 to test it directly.

Rob H
December 15th, 2007, 09:23 AM
Aha, that will be the problem then - conditionals aren't applied when you use F5.

You'll need to trigger it some other way, e.g. have a scripting action that calls gir.TriggerEvent('testconditional', 18) then use the event generated by that to trigger the node you want to test.

quixote
December 15th, 2007, 09:46 AM
OK, Thanks. I'll try it out again later.

quixote
December 18th, 2007, 04:50 AM
Works great. Thanks for the clarification and sorry about the misunderstanding.

quixote
December 18th, 2007, 04:55 AM
One more question--

Why is John's new Scheduler not included in the Girder install? (see here: http://promixis.com/forums/showthread.php?t=17519&highlight=scheduler )
It seems like no one knows about it and won't know about it if they don't actively search for it. Shouldn't we be testing it out with the standard install?
Thanks

quixote
December 19th, 2007, 10:55 AM
Couple more items of interest:

1) This probably belongs in the developer forum, but the variable conditional is giving me lots of errors. Actually it's only a couple repeated over and over and over:

TreeScript (gir_conditional_test): ...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: attempt to index local `v' (a nil value)
stack traceback:
...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:10>
...Promixis\Girder5\/plugins/treescript/variable UI.lua:328: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:286>
TreeScript (gir_conditional_test): ...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: attempt to index local `v' (a nil value)
stack traceback:
...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:10>
...Promixis\Girder5\/plugins/treescript/variable UI.lua:328: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:286>
TreeScript (gir_conditional_test): ...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: attempt to index local `v' (a nil value)
stack traceback:
...Promixis\Girder5\/plugins/treescript/variable UI.lua:14: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:10>
...Promixis\Girder5\/plugins/treescript/variable UI.lua:328: in function <...Promixis\Girder5\/plugins/treescript/variable UI.lua:286>

...


This seems like a good enough reason to create a variable conditional that's built in to Girder 5 by default, if you ask me. :)

2) Now for the main reason I posted in this thread: I would really like to see an event for "Mutex available" or something like that because I'm getting very annoyed and feeling overwhelmed at the way it is set up now. I have tried moving scripts to the lua startup directory and it does not help the fact that my persistent variables will not load and a couple of other commands will not fire because of the mutex lockup.
This has to be a brainless thing to set up. If you create a macro to fire on Girder Open, it must fire and load without question, otherwise Girder is no longer useful in mission critical situations such as for an alarm system, etc.

quixote
December 19th, 2007, 11:21 AM
Go figure... as soon as I post it starts working.
I think that delaying the plugin loading fixed that, though I thought I had already tried that.
Anyway, I still think that the variable conditional should be built in and I'm not sure why it's not when it's so vital.

Rob H
December 19th, 2007, 11:46 AM
Out of interest, what is it vital for? I don't doubt that it's useful, but I've never felt the need for it here.

But then again I'm happy to code in Lua, which probably says more about me than it does about this conditional.

quixote
December 19th, 2007, 11:56 AM
Out of interest, what is it vital for? I don't doubt that it's useful, but I've never felt the need for it here.

But then again I'm happy to code in Lua, which probably says more about me than it does about this conditional.

...and that's why we love you. ;)

OK, it's vital for a number of reasons, but to name a couple off the top of my head --

1) stop my media player and turn off a couple of things when I leave my home and the number of perceived occupants == 0. That way I can leave when I'm in a rush or just too lazy and not mess around trying to shut stuff off.

2) Set up a bunch of events that only execute in certain conditions such as setting your remote mode by setting a variable to "DVD" and then attaching that conditional to macros/commands in groups that you don't want to organize so that only commands for the DVD player reside in that group. For instance, you could make one macro for "Play", place commands for play for your DVD player, VCR, Media player and CD player in that macro, and then attach conditionals to each command to look at the "Mode" variable.

3) Alarm system stuff, tropical fish aquarium stuff, climate control stuff... I'm sure you get the picture. :D

quixote
December 19th, 2007, 03:29 PM
Nope, back to square one with the mutex bullshit. We need a flow control item that will wait for the mutex or something. It's impossible to work with this otherwise, unless your an advanced script writer.

I thin kthe problem is when you are doing anything like playing media files or a virus scan, etc. it screws up Girder's startup.

quixote
December 30th, 2007, 08:27 PM
Sorry for that outburst, but it's really frustrating.

liofr
January 1st, 2008, 09:19 AM
homeseer already do that !!

Rob H
January 1st, 2008, 09:29 AM
Already does what?

Sooloom
February 25th, 2008, 08:08 PM
Lite Lite Lite , hope release a Lite Version, Too bigger

FearTheDentist
February 27th, 2008, 10:48 PM
I use a touchpad on my PC where I do most of my develoment (bluetooth Logitech DiNovo w\ built in touchpad- perfect for a HTPC, although $200 is kinda steep for a keyboard). I'm finding that I'm constantly accidentally dragging and dropping actions, events, etc when I'm using the touchpad due to the inadvertant mouse clicks that are inherant in use of a touchpad. I'd love to see a simple check box on the main page, say in the "General" box below the "enabled" box, which enabled\disabled dragging and dropping of items.

quixote
April 14th, 2008, 08:57 PM
I'd like to add my vote to the "Lock the Log Screen Output" as sometimes I try to see what is happening but the continuing events generated by a repeating timer keeps pushing the log entries I want to see offscreen. Rather irritating on the level of "fingernails down a blackboard" I think.

...........

NeoMorph
April 15th, 2008, 05:58 AM
Yeah.... any news on whether we will be able to lock the output so we can see what's going on? I'm trying to find a problem with my XBMC interface atm and I keep losing the relevent error message up screen....

Rob H
April 15th, 2008, 10:20 AM
That will be up to Ron, but I've done the same sort of thing for NetRemote Designer (in the next version).

Ron
April 15th, 2008, 12:28 PM
I can make the logger -log- always.

jwilson56
April 15th, 2008, 01:43 PM
I think what they are asking for is the ability to freeze the scrolling (while its still logging) so you can copy and paste from it or just look at whats going on.

One similar logging screen that I used at one time did this anytime the scroll bar was not at the bottom... it would stay where the scroll bar was slid... when the bar was at the bottom it would then let the window scroll by itself.

John

Rob H
April 15th, 2008, 01:47 PM
It would also be good if the size of the log buffer were configurable.

Ron
April 15th, 2008, 01:48 PM
Alright requests noted.

jwilson56
April 16th, 2008, 01:42 PM
Another note.... would it possible to have the option for MediaBridge to turn on and off the logging for MP_TrackPositionPercentage and MP_TrackPosition?

When your playing tracks the log file gets filled with these so fast.

quixote
April 16th, 2008, 09:17 PM
Yeah the real issue is control and scrolling. Some things connot be switched off in logging, which doesn't bother me so much as the scrolling problem. It's next to impossible to debug something when your error messages run away from you all the time.

Rob H
April 17th, 2008, 01:29 AM
I'd agree with that, that's why I use DebugView for this at present along with the following bit of Lua that's loaded at startup -

local oldPrint = print
function print(...)
oldPrint(unpack(arg))
local temp = {}
for i, j in ipairs(arg) do
table.insert(temp, tostring(j))
end
win.OutputDebugString(table.concat(temp, ' '))
end