better scripted GUI creation

[bdeshi]

anybody else feel using only html() is too restrictive for GUIs? Submit your +1 's for an alternative scripted GUI creator, even a simple one with basic elements (button, text, chkbox, list... ?) !!!

[PeterH]

Hm - seems I must say

+1

(As I'm absolutely no HTML guy )

[Stef123]

+2
Although I only venture into the most shallow waters of scripting, even I was able to create a professional looking GUI with checkboxes, OK and Cancel - thanks to AutoHotKey. It'd be awesome if something similar were possible within XY.

[binocular222]

GUI drawing is a big pain (see how Don struggle to fit text into Config dialog for different language).
It's almost impossible to draw a correct GUI (x-y-w-d size and position) without knowing a fixed number of control & button & text fields.
So, how simple the GUI can you accept?

[bdeshi]

GUI drawing is a big pain (see how Don struggle to fit text into Config dialog for different language).
It's almost impossible to draw a correct GUI (x-y-w-d size and position) without knowing a fixed number of control & button & text fields.

we're already have to do that with html(). I think this can be left to scripters.

In fact, html's not very bad, but the big problem is there's only one way to return data (and there's always doubt that it might mangle special chars). Also html is relatively slow, also it's based on ie6 which is a bundle of incompatibility and incompetence. Also that close button. The list can go on.

[zer0]

Sorry if this is going to sound ignorant, but what is the purpose of scripting any kind of web-like GUI in a file manager? To me, it seems like abstracting functionality one would expect for the product itself to have.

[bdeshi]

We're not asking for a web-like GUI. We're asking for an alternative to a weblike GUI.

[zer0]

We're not asking for a web-like GUI. We're asking for an alternative to a weblike GUI.

Be that as it may, what is the purpose of having a custom GUI within XY? What task are you trying to accomplish that cannot be done within XY?

[binocular222]

GUI can host multiple fields (radio buttons, check boxes, drop-down lists, text fields,...) and return respective values.
XY scripting such as popupmenu/input only accept and return 1 value at a time.

[Stef123]

what is the purpose of scripting any kind of web-like GUI in a file manager? To me, it seems like abstracting functionality one would expect for the product itself to have.

But isn't that what scripting is all about? Expanding the functionality of the product itself?
I already benefit greatly from existing scripts that require user interaction (BetterFileSelector, SearchwithFileLoctor, FavFolder GUI) - and if I understand correctly, they all have to take detours to offer checkboxes etc - not to mention they always come with a nondescriptive Close-button, even though none of those scripts is meant to stay open. And Close does not equal OK as you may expect. Instead, it cancels out of what you entered, just like the upper-right x button.

[LittleBiG]

Simple GUI means to me: controls in one column. Defined by a simple list, placement would be automatic. Like GUI(text "Title of GUI", separator ,inputbox("text of inputbox",variable), separator, button("OK",button_variable,1), button("Cancel",button_variable,2));
But I am far from sure that this GUI thing could raise Don's interest.

EDIT: Something like this:

[binocular222]

I think working through AHK would be easier as almost all controls are available (drop-down, radio, Tab, checkbox...). I did a complete GUI in AHK before (a launcher app) but to be honest, fairly painful.

[TheQwerty]

Sorry, but I don't feel this is needed at present.

I think we can create feature rich GUIs in HTML just fine - the biggest issue is that we're limited by the control using emulation mode and forcing us back to the dark ages of IE7.

Unfortunately the two solutions to this are not acceptable...
1) Use a Different Embedded Browser - Don doesn't want to introduce dependencies so unless he writes his own this won't happen.

2) Modify the registry to tell Windows to use a better emulation mode for XYplorer.exe - breaks XY's portability and unless XY does it then shared scripts will be hit or miss depending on the user having made this change.


Further, that's not the only option - with CopyData, Get(CopiedData), runret, and even just file access there's plenty of ways to use other languages for GUI.

[zer0]

what is the purpose of scripting any kind of web-like GUI in a file manager? To me, it seems like abstracting functionality one would expect for the product itself to have.

But isn't that what scripting is all about? Expanding the functionality of the product itself?
I already benefit greatly from existing scripts that require user interaction (BetterFileSelector, SearchwithFileLoctor, FavFolder GUI) - and if I understand correctly, they all have to take detours to offer checkboxes etc - not to mention they always come with a nondescriptive Close-button, even though none of those scripts is meant to stay open. And Close does not equal OK as you may expect. Instead, it cancels out of what you entered, just like the upper-right x button.

Yeah, but I see that as a slippery slope where scripting takes over as the main channel of providing additional functionality. Want functionality X? Here is a script. Want functionality Y? Here is another script. The problem with that is that scripting is an alien concept to many people -- granted, it is quite awesome for some other people too -- I would rather see them integrated in the main product than being left to scripting.

[PeterH]

I think we can create feature rich GUIs in HTML just fine - ...

You should have said you can
I can't