Do you like the GUI ?

[father of monstermagnet]

Maybe it's time for this questions ?
Please post your opinion !

[birty]

rather than just saying you dont like it why not say WHY you dont like it and what you would like to see changed

[father of monstermagnet]

That' s why i started this poll !

To help Ron building the pefect GUI for beginners and experts.

My english is too bad to post my exact opinion so it's up to you beta testers!

Don't care about the poll just post your suggestions !

[danward79]

I put nice, but, purely because I like the look, but am taking my time getting used to it.

[Ron]

Yeah for this to be of any use you'll have to say what you don't like, possibly even giving some ideas on how to do it better. :-)

[Mark F]

I haven't used the GUI to do much other than debug the serial plugin; however, here are a few changes that I submit for consideration.

In the main window, it would be nice if the current state of "Switch to expert interface" remained the next time I start Girder.
In the variable display window, it would be nice if the current state of the "Only variables" box remained the next time I start Girder.
In the variable display window, when I traverse a table, could you show the current path from the base environment somewhere? Putting it in the variable display window title bar would be OK though the string length may get too large. If you choose to leave the base environment off (_G) that would be OK.

As an example, when I drill into the following structure


Serial = {
DeviceList = {
FireCracker = {
OutputFIFO = {
firstElement = 1,
lastElement = 1,
Array = {}
}
}
}
}

to see the firstElement value, the title could be:
Variable Display - _G.Serial.DeviceList.FireCracker.OutputFIFO
or
Variable Display - Serial.DeviceList.FireCracker.OutputFIFO

Thanks for considering these. :)

[Rob H]

Rather than drilling down, wouldn't a treeview be a better choice for the variable display?

[Mark F]

As long as the current leaf node has the ability to show all of it's contents, yes. Something like file explorer (Variable Explorer?), where the tree is in one window pane and the current leaf contents are in the other, would work for me. I could see the path while looking at the data values.

The more I write about this, the more I think of. :)

In the Log display, when "Display Script Information" is on, the comment field shows some information about functions (if they ar "C" or what file they came from). Any chance this could be added to the Variable Explorer?

EDIT: If the function information is hard to gather (ie. slow), perhaps double clicking a specific fucntion could get the information for that function? That way the penalty is paid when the user specifically asks for it on a function by function basis.

[Rob H]

That sounds good

[Ron]

@ Mark,
regarding point 1, you can set this in on the settings window.
regarding point 3, the path of the table in the title, sure.
regarding the tree, now that is a little bit more intensive CPU wise, but I guess it can be done.

Mark, do you know how to get the info about where function came from?

[Rob H]

Why would it be more CPU intensive?

You could defer populating closed branches until the user opens them, much like Explorer does.

[Ron]

Yeah It is not a big deal.

- Ron

[Mark F]

Doh! I missed the "Start in expert mode" setting. :( It works great.

If the log window works like the logger plugin did, all of the displayed information was acquired through the LUA debug interface. Did the extra filename stuff come for free with the LUA 4 -> LUA 5 upgrade?

I haven't looked at the debug interface for LUA 5. I'll take a look and see if I can get any other ideas. :)

[Ron]

I didn't need to use the debug libs to get the info on the logger window. I guess it was the upgrade to Lua5 that gave us this info.

[Mark F]

Not debug libs but the debug interface. Are you hooking all the calls and returns using lua_sethook()? If so, this is part of the debug interface.

I just looked back into the Logger plugin and LUA 4.0 debug interface. I could have provided the filename as well. Crud.

The LUA 5 debug interface (http://www.lua.org/manual/5.0/manual.html#4)

It looks like you can use code like this


// assume:
// pStrFunctionName -> pointer to full path and function name
// (ie. "Serial.DeviceList.FireCracker.AddCommand")
lua_Debug ar;
lua_pushstring(L, pStrFunctionName);
lua_gettable(L, LUA_GLOBALSINDEX); /* get function on the stack */
lua_getinfo(L, ">S", &ar);
printf("%s\n", ar.short_src);
// or
printf("%s\n", ar.source);

to get the information.

I'll think about this some more. ;)

[Ron]

You are right, the lua_hook thing is part of the debug library. Sorry 'bout that.

[kelmk]

Yes but I wish there were no pop ups. Any of the action pop up dialogs would be much better as part of the interface.

[Promixis]

Yes but I wish there were no pop ups. Any of the action pop up dialogs would be much better as part of the interface.


Can you explain more what you are thinking?

[kelmk]

I would prefer the dialog boxes to be part of the main screen. What about this?
It could just be me though.

[Ron]

I don't want to mess with the docking windows at this point, I will certainly look at this for G4.x (x>0). I was thinking of doing this as well.

[quixote]

My only request pertaining to the topic at hand (at this time):

http://www.promixis.com/phpBB2/viewtopic.php?p=110438&highlight=#110438

[Ron]

Have a look at the attached screenshot.

[quixote]

Wow! Big improvement over V3.3!

[Mark F]

That will work. :) I notice the "Only variables" box is gone. This solves my other problem :)

[Ron]

I'll look into adding another column with some more debug info a little later.

[Rob H]

Awesome!

[Ron]

Mark I looked into getting some more debug information, but the ar structure gives very little. Where you thinking of something else as well?

[Mark F]

No, I was hoping to see if the functions were defined in LUA or C and if LUA, which file they were defined in.

Here is why:

I'm trying to make the transition from the G3 serial plugin to the new serial plugin a bit easier. In the end, I want to write a program that reads the G3 serial plugin registry stuff or a device.ini file and generates a G4 serial plugin support file. To do this, I am building some compatibility "helper" objects that encapsulate the input and output functionality of the previous plugin. When using these helper objects in G4, some of the standard methods (read and write) of a new serial device object get replaced with these helper object's methods. Validating the origin of the serial device object's methods is currently VERY difficult.

[Ron]

@kelmk

This is not a mock-up. :D You can now dock the default editor!!

[kelmk]

nice :)

[Rob H]

BTW why 'result is equal to 0' rather than the conventional 'result is equal to nil'?

[Ron]

You can use either.

[Rob H]

I must admit I'm not comfortable with the idea. Strictly speaking, given that this is LUA 5 it should be 'false' rather than 0 or nil.

Is there an equivalent of this in G3? I don't recall one.

Looks rather like a recipe for confusion, but that may be just me.

[Ron]

I did it this because G3.3 checks for 0. Changing over to nil is neater but requires some attention by the user. However since the upgrade from 3.3 to 4 will require attention maybe we should do this. What do you think?

[Rob H]

I looked but couldn't see where G3 exposes this.

I'd go with 'false' myself. It's far clearer IMO.

[Ron]

we are going to go with true/false