Need to develop some kind of GUI designer (sigh)
in [TCL]
|
Prev: Weird tdom bug?
Next: catch not catching
From: Helmut Giese on 2 Mar 2010 14:42 Hello out there, As part of an upcoming application I need to enable _users_ to "design" kind of an instrument panel. Calling it "instrument panel" is actually too much - the requirements GUI-wise are not very exciting: - text fields to display some values, - entries to provide values (to be sent off) - maybe an LED or a slider and - of course some buttons. This "panel" will serve as an interface to interact with some device, so in the end they will need to "connect" those widgets with the device's properties: Button X sends command Y, and display field Z shows temperature, pressure, or whatever. This part is the least of my worries - there will be some GUI which will permit this. The users won't be exposed to Tcl code (they may discover it if they care to look at the files which save their configuration) - for them it will be just 2 black boxes: - One which enables them to do their "design", and - the other which magically allows their creation to talk to the device in question. 'design wise' I am a bit at a loss here. Of course, there exist various GUI design tools, but I have the feeling that they aren't of any use here: 1) They expose way too many options for unknowing users to fiddle around with, 2) their target audience are developers, not end users, and 3) they are stand-alone apps - not meant to be part of a larger app. I am currently in the OMG, how am I going to tackle this! stage and would appreciate any advice: - Maybe there exists a GUI designer which can be easily stripped down and/or - is meant to (or can) be integrated into another app? - Any other thought or idea? Here's hoping for some ideas :^( Best regards Helmut Giese
From: Robert Heller on 2 Mar 2010 16:08 At Tue, 02 Mar 2010 20:42:53 +0100 Helmut Giese <hgiese(a)ratiosoft.com> wrote: > > Hello out there, > As part of an upcoming application I need to enable _users_ to > "design" kind of an instrument panel. Calling it "instrument panel" is > actually too much - the requirements GUI-wise are not very exciting: > - text fields to display some values, > - entries to provide values (to be sent off) > - maybe an LED or a slider and > - of course some buttons. > This "panel" will serve as an interface to interact with some device, > so in the end they will need to "connect" those widgets with the > device's properties: Button X sends command Y, and display field Z > shows temperature, pressure, or whatever. This part is the least of my > worries - there will be some GUI which will permit this. > > The users won't be exposed to Tcl code (they may discover it if they > care to look at the files which save their configuration) - for them > it will be just 2 black boxes: > - One which enables them to do their "design", and > - the other which magically allows their creation to talk to the > device in question. > > 'design wise' I am a bit at a loss here. Of course, there exist > various GUI design tools, but I have the feeling that they aren't of > any use here: > 1) They expose way too many options for unknowing users to fiddle > around with, > 2) their target audience are developers, not end users, and > 3) they are stand-alone apps - not meant to be part of a larger app. > > I am currently in the > OMG, how am I going to tackle this! > stage and would appreciate any advice: > - Maybe there exists a GUI designer which can be easily stripped down > and/or > - is meant to (or can) be integrated into another app? > - Any other thought or idea? Download the Model RR System (http://www.deepsoft.com/ModelRailroadSystem/DownloadMR) and look at the code for the 'Dispatcher' program. This program creates a model railroad control panel for either a CTC (Centralized Traffic Control) or a Tower panel (local control of a single interlocking plant). It is designed for model railroaders, who are not necessarily computer programmers -- maybe not quite what you want, but maybe closer and maybe it will give you some ideas on how to partition the problem. > > Here's hoping for some ideas :^( > Best regards > Helmut Giese > > -- Robert Heller -- Get the Deepwoods Software FireFox Toolbar! Deepwoods Software -- Linux Installation and Administration http://www.deepsoft.com/ -- Web Hosting, with CGI and Database heller(a)deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
From: Arjen Markus on 3 Mar 2010 02:48 On 2 mrt, 20:42, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > Hello out there, > As part of an upcoming application I need to enable _users_ to > "design" kind of an instrument panel. Calling it "instrument panel" is > actually too much - the requirements GUI-wise are not very exciting: > - text fields to display some values, > - entries to provide values (to be sent off) > - maybe an LED or a slider and > - of course some buttons. > This "panel" will serve as an interface to interact with some device, > so in the end they will need to "connect" those widgets with the > device's properties: Button X sends command Y, and display field Z > shows temperature, pressure, or whatever. This part is the least of my > worries - there will be some GUI which will permit this. > > The users won't be exposed to Tcl code (they may discover it if they > care to look at the files which save their configuration) - for them > it will be just 2 black boxes: > - One which enables them to do their "design", and > - the other which magically allows their creation to talk to the > device in question. > > 'design wise' I am a bit at a loss here. Of course, there exist > various GUI design tools, but I have the feeling that they aren't of > any use here: > 1) They expose way too many options for unknowing users to fiddle > around with, > 2) their target audience are developers, not end users, and > 3) they are stand-alone apps - not meant to be part of a larger app. > > I am currently in the > OMG, how am I going to tackle this! > stage and would appreciate any advice: > - Maybe there exists a GUI designer which can be easily stripped down > and/or > - is meant to (or can) be integrated into another app? > - Any other thought or idea? > > Here's hoping for some ideas :^( > Best regards > Helmut Giese Interesting problem :). What about: - Displaying a grid of potential widgets (each represented by a combobox) - The user can select the type of widget to fill in by selecting the desired type from the combobox. - With a pushbutton on the side he/she can fill in the details in a separate dialogue. - Once they have defined the type and associated attributes, a dummy widget is filled in instead of the combobox (with the - tiny - pushbutton still there). Something like: [Label V][..] [Entry V][..] [Empty V][..] [Label V][..] [Scale V][..] [(...) V][..] .... "V" represents the combobox's pulldown thingy [..] is a pushbutton that brings up the dialogue (...) indicates the widget on the left spills into this one That way the user can fill in the details without having to worry too much about the layout or whatever code is underneath. Regards, Arjen
From: Helmut Giese on 3 Mar 2010 04:37 Hi Robert, >Download the Model RR System >(http://www.deepsoft.com/ModelRailroadSystem/DownloadMR) and look at the >code for the 'Dispatcher' program. This program creates a model railroad >control panel for either a CTC (Centralized Traffic Control) or a >Tower panel (local control of a single interlocking plant). It is designed >for model railroaders, who are not necessarily computer programmers -- >maybe not quite what you want, but maybe closer and maybe it will give >you some ideas on how to partition the problem. I got hold of it - whow, what a _huge_ system. Thanks for pointing me to the 'Dispatcher' - this at least narrows down the scope of what to look at. I'll install the whole program and it hopefully gain some inspiration. Thanks again and best regards Helmut Giese
From: Helmut Giese on 3 Mar 2010 04:55
Hi Arjen, >Interesting problem :). glad you found it a challenging idea. :) [snip descriptive text] >Something like: > >[Label V][..] [Entry V][..] [Empty V][..] >[Label V][..] [Scale V][..] [(...) V][..] >... You reminded me of an idea I had in the past: - Restrict the user to some kind of 'table oriented' layout. - Put in some sugar (like allowing to combine rows and/or columns to obtain larger cells which can hold another 'table') and - (Tata) hand the whole stuff over to GridPlus to do the grunt work. Of course it would be a very restricted designer - but for this use case it might not even matter. Definitively an idea to ponder. Many thanks Arjen, looking into my crystal ball I see me occupied the coming weekend. Best regards Helmut Giese |