Need to develop some kind of GUI designer (sigh)
in [TCL]
|
Prev: Weird tdom bug?
Next: catch not catching
From: Larry W. Virden on 3 Mar 2010 07:21 On Mar 2, 2:42 pm, Helmut Giese <hgi...(a)ratiosoft.com> wrote: > - 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? > My first thought was to skip the GUI designer stage, and instead, write an application where the user selects the types of actions s/he needs to perform, and your program would generate a GUI from that. In other words, does program really need to talk in terms of entry widget, colors, sliders, or does the user think in terms of "I need to send this string and this number to a device sitting on this port, and then wait until this response comes back". An attempt to shift from implementation to inputs to gather and outputs to produce, then build an implementation which provides that, might be a useful approach. If the input is a bit more complex, perhaps design a mini-language, in which the user writes statements like Send "string a" "string b" "number 1" to device "over there" and wait for a "numeric" response between 1 and 123 and from that generate the widgets to input a string, number, etc.
From: Helmut Giese on 3 Mar 2010 08:16 Hi Larry, >My first thought was to skip the GUI designer stage, and instead, >write an application where the user selects the types of actions s/he >needs to perform, and your program would generate a GUI from that. > >In other words, does program really need to talk in terms of entry >widget, colors, sliders, or does the user think in terms of "I need to >send this string and this number to a device sitting on this port, and >then wait until this response comes back". that's an interesting thought - comes a bit as a surprise, but then, I was asking for it. :) Thinking about it, the basic concept stems from my own experiences in building GUIs _not_ using Tcl (like Delphi, C++ Builder or currently ..NET) - hence the 'drag and drop' paradigm. I'll need a moment to be able to look at it from a fresh POV. Many thanks for your thoughts and best regards Helmut Giese > >An attempt to shift from implementation to inputs to gather and >outputs to produce, then build an implementation which provides that, >might be a useful approach. > >If the input is a bit more complex, perhaps design a mini-language, in >which the user writes statements like > >Send "string a" "string b" "number 1" to device "over there" and wait >for a "numeric" response between 1 and 123 >and from that generate the widgets to input a string, number, etc.
From: Richard Owlett on 3 Mar 2010 10:00 Helmut Giese wrote: > Hi Larry, >> My first thought was to skip the GUI designer stage, and instead, >> write an application where the user selects the types of actions s/he >> needs to perform, and your program would generate a GUI from that. >> >> In other words, does program really need to talk in terms of entry >> widget, colors, sliders, or does the user think in terms of "I need to >> send this string and this number to a device sitting on this port, and >> then wait until this response comes back". > that's an interesting thought - comes a bit as a surprise, but then, I > was asking for it. :) > > Thinking about it, the basic concept stems from my own experiences in > building GUIs _not_ using Tcl (like Delphi, C++ Builder or currently > .NET) - hence the 'drag and drop' paradigm. > > I'll need a moment to be able to look at it from a fresh POV. > Many thanks for your thoughts and best regards > Helmut Giese > For a different perspective you may want to look at http://www.forth.com/starting-forth/ and http://thinking-forth.sourceforge.net/ >> An attempt to shift from implementation to inputs to gather and >> outputs to produce, then build an implementation which provides that, >> might be a useful approach. >> >> If the input is a bit more complex, perhaps design a mini-language, in >> which the user writes statements like >> >> Send "string a" "string b" "number 1" to device "over there" and wait >> for a "numeric" response between 1 and 123 >> and from that generate the widgets to input a string, number, etc. >
From: Helmut Giese on 3 Mar 2010 12:14 Hi Richard, >For a different perspective you may want to look at >http://www.forth.com/starting-forth/ >and >http://thinking-forth.sourceforge.net/ ok, I mentioned 'a fresh POV' in my reply to Larry - but this goes too far. :) No, I am not going to trade in Forth for Tcl - no way. BTW those 2 links _are_ of some interest: I didn't know about the 'Thinking Forth Project' and was equally unaware that there exists an online edition of "Starting Forth". Not that I needed one - I still have the book on my bookshelf (copyright notice of 1981). Did you misunderstand me? I am looking for a way to have non-programmers create a GUI for a (sort of) communication program. Are you serious that using Forth would be helpful here? But I do appreciate an interesting reply. Best regards Helmut Giese
From: Richard Owlett on 3 Mar 2010 14:47
Helmut Giese wrote: > Hi Richard, >> For a different perspective you may want to look at >> http://www.forth.com/starting-forth/ >> and >> http://thinking-forth.sourceforge.net/ > ok, I mentioned 'a fresh POV' in my reply to Larry - but this goes too > far. :) It was Larry's comment on creating a specialized mini-language that triggered an association to FORTH. Not that FORTH has the particular tools for this job. I hadn't associated your name with postings on comp.lang.forth. > No, I am not going to trade in Forth for Tcl - no way. > > BTW those 2 links _are_ of some interest: I didn't know about the > 'Thinking Forth Project' and was equally unaware that there exists an > online edition of "Starting Forth". Not that I needed one - I still > have the book on my bookshelf (copyright notice of 1981). > > Did you misunderstand me? I am looking for a way to have > non-programmers create a GUI for a (sort of) communication program. > Are you serious that using Forth would be helpful here? > > But I do appreciate an interesting reply. > Best regards > Helmut Giese |