Have you made progress on your GUI command protocol?
Curious because having the Propeller (or other micro) interpret a lean command set and render the GUI on an LCD is attractive. This follows Cluso99's suggestion that the GUI does not have to necessarily rendered on a PC.
For example, attached are some pictures of my PocketProp LCD with some GUI elements developed last year (apologies for the picture quality).
Knowing what other elements you intend to support would be nice. As you see, I have 4 GUI elements defined. The attributes are simple so far and would of course require a command protocol for rendering and interaction. @Chris Micro's work allowing sliders and large text boxes on a PC window is also very interesting.
The "OK" button object interface for rendering with my Spin GUI library is defined as follows (events would be handled separately).
' interface methods
pub init(text, x, y, w, h) ' initialize 3d button with text with a rectangle
pub paint ' paint the button as normal
pub click ' paint the button as clicked then return to normal
' button attributes
pub setClick(v) ' set click state
pub getClick
pub setDefault(v) ' set default state
pub getDefault
pub set3dMode(v) ' set 3d mode
pub get3dMode
pub setText(v) ' set button text
pub getText
' common primitive rectangular attributes
pub setTop(v)
pub setLeft(v)
pub setWidth(v)
pub setHeight(v)
pub setBgColor(v)
pub setFgColor(v)
pub getTop
pub getLeft
pub getWidth
pub getHeight
pub getBgColor
pub getFgColor
The point of showing this interface is to stimulate further definition of GUI element attributes. Whether the GUI is rendered on a PC, a Propeller terminal, or whatever, certain items must be defined. The HTML common object model really is a good example of attributes to support although a simpler version is desirable. One does not need to write HTML code or a parser of course.
Having a basic protocol that allows the terminal paint elements with it's own abilities (pretty features, etc...) with a minimal attribute set seems important. A Propeller TV/VGA based terminal may not be able to do 3D rendering because of color limits, but that should not stop it from doing basic element rendering.
One can negotiate terminal abilities, but that is not necessarily desirable. As you may know Telnet has a protocol for negotiating terminal capabilities; that still doesn't work perfectly as far as I know. Better to just avoid such negotiation if possible.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
Nice job jazed. I would thing the first parameter needs to define the objet (button, box circle, etc. Certainly, the call needs to be this simple. As a default, if the object does not exist, then a rectangle at the coordinates and size needs to be paineted with the text inside. A lot can be done with a minimal number fo objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks Cluso99. Yes, one needs to have a type; one also needs an index (or just a separate name) in case of multiple instances of a type. Of course, the object stubs I showed were only for rendering in a Propeller.
Presumably, if you have an object that encapsulates what is being sent to the GUI terminal, some information like the object type is kept in the object, but the index/name would be passed to the object. To keep things small instead of having an object hierarchy, a single generated Spin object containing renderer(s) and handlers could be used with the GUI widget list to send form/widget data to the terminal and handle events.
I've been spending *quality time* with Qt this morning. It's a nice environment.
One of the things that would be useful for GUI terminal users is to have a GUI designer. I've spent time on this before and hacked through a program to do design. Later I found wxWidgets did what I wanted, but that designer is not so friendly.
Enter the Qt Designer - this program can be used to design the GUI to be displayed in your GUI Terminal in a user friendly way. The output is an XML file that can be translated into whatever protocol you want to use, but in the case of Propeller, a Spin file (or other language like Java) can be automatically created to do rendering transmit and receive event handling.
Here is an example dialog as seen in the Qt Designer.
Rendering the framework of your GUI becomes as simple as creating the window, running the protocol translator, and adding text to a spin file or whatever. This is of course just for rendering although the .ui XML output does specify signals and slots (Events and Handlers). Using the Qt Designer also simplifies the definition task ... I prefer text for specifying fields and such to avoid version differences and other headaches. XML as generated is hard to parse in a micro-controller, so that has to go, but having ASCII names for certain things remains useful.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Hello,
Well if we are to get serious about this project we really need to propose a protocol that we can all follow.
The protocol should have to following attributes:
-What is happening (adding, editing etc)
-A starting and ending code
-What objects that we want to display (textbox, button, dropdown)
-What events that the objects can send/recieve
So for example
@create, button, object name, x, y, width, height, events processed&
@modify,object name, attribute to be modified (ie x or y), parameter&
@event, object name, event attribute.
This is a very vague example but gives you some idea of what I was thinking. I would think that we should also replace the characters '@' and '&' with non alpha/numeric characters and also things like 'create' etc with codes instead of string literals. This should save on space because instead of sending the ascii string, you will send codes.
I've had my nose to the grindstone the last few days but I have had a chance to play with Qt and the next step with it is to get the serial interface up with qextserialport. If we can make sure that the actual interface stream (serial connection) uses 8th bit "tags" then we can easily use text strings etc after these tags to specify objects and indices. All data must be transmitted in 7-bit chunks with msb=zero so that the object and state interpreter is kept simple and so that there is no "confusion" as to what a character is. I have seen too much gobblygook emanating from terminal emulators because of stream misinterpretation for whatever reason.
Specifying a protocol can easily turn into a long and protracted academic debate so we should aim for a basic but functional specification first, to kick it off, but with just enough foresight so as to choose the best path. This may mean that instead of being able to describe the an object in all it's glory that we simply say BUTTON(0,0,142,64,"OK") just as a very rough example. In the serial stream a button "tag" would be followed by these basic parameters delimited by a delimiter tag or the start of another tag.
Working in reverse and writing a Spin application that interfaces to this as yet non-existent GUI terminal may be a better way of getting a feel for what is needed rather than trying to predict what "may" be needed.
I don't really have much time this week but next week I will try to create a Qt serial app along these lines as a demonstration and as a basis for discussion.
Unfortunately, I have not seen this thread until now. I have been thinking along the same lines. Tcl/Tk is a perfect fit for this. 1. It is cross platform.(already on most linux installs including on my Zipit, eTcl package for Windows Mobile and other windows) 2. It is fairly light (~4MB memory needed) 3. It is interpreted code so it you can build your GUI interactively. 4. You can connect with one "wish" executable to another one via X windows to send commands interactively from the PC side at the same time with the "send" command. 5. You can quickly build applications in it that like the calculator example look like a standalone application. 6. It is a very mature language now. Here is an example of a simple application:
My goal is to have a propeller based solution. That means, make use of propeller features and emulate them on a PC in whatever environment. I would prefer GLADE and the GTK+/GNOME framework.
@Peter, I'm glad you mentioned QextSerialPort (was looking for something like it yesterday AM).
I've been able to build the example applications and tested enumeration up to COM20 which is a BIG win.
This is exciting enough to motivate me to do Qt versions of my .net tools [noparse]:)[/noparse]
c:\Qt\qextserialport-1.2win-alpha\examples\enumerator>debug\enumerator.exe
List of ports:
port name: COM8
friendly name: USB Serial Port (COM8)
physical name: \Device\000000a3
enumerator name: FTDIBUS
===================================
port name: COM20
friendly name: USB Serial Port (COM20)
physical name: \Device\000000a5
enumerator name: FTDIBUS
===================================
Once the application rendering/event protocol is defined you can write the terminal with any tool for any platform.
It may be a while before some consensus on a common protocol is reached. The free market approach (anyone
developing anything and a leader ultimately emerging) can produce a reasonable end result. Of course it may
or may not be better or be available faster than a solution developed in open collaboration. Designing something
new by committee can be difficult and time consuming. Leveraging a model that already exists and works can
speed things up.
Now, trying to following Jesse Massey's outline:
1. What is happening (adding, editing etc)
Understood
2. A starting and ending code
Unclear ... is this a packet transfer reference or what?
Maybe you mean like Form_Load / Unload from VB ?
3. What objects that we want to display (textbox, button, dropdown)
Understood
4. What events that the objects can send/recieve
Understood
5. Additionally, numeric data byte order must be defined if strings are not used.
Treating everything as a string eliminates this problem.
Here is a starting list for item 3. It is obviously influenced by Qt.
QCheckBox :: Checkbox with a text label
QComboBox :: Combined button and popup list
QCommandLinkButton :: Vista style command link button
QDateEdit :: Widget for editing dates based on the QDateTimeEdit widget
QDateTimeEdit :: Widget for editing dates and times
QDial :: Rounded range control (like a speedometer or potentiometer)
QDoubleSpinBox :: Spin box widget that takes doubles
QFocusFrame :: Focus frame which can be outside of a widget's normal paintable area
QFontComboBox :: Combobox that lets the user select a font family
QLCDNumber :: Displays a number with LCD-like digits
QLabel :: Text or image display
QLineEdit :: One-line text editor
QMenu :: Menu for use in menu bars, context menus, and other popup menus
QProgressBar :: Horizontal or vertical progress bar
QPushButton :: Command button
QRadioButton :: Radio button with a text label
QScrollArea :: Scrolling view onto another widget
QScrollBar :: Vertical or horizontal scroll bar
QSizeGrip :: Resize handle for resizing top-level windows
QSlider :: Vertical or horizontal slider
QSpinBox :: Spin box widget
QTabBar :: Tab bar, e.g. for use in tabbed dialogs
QTabWidget :: Stack of tabbed widgets
QTimeEdit :: Widget for editing times based on the QDateTimeEdit widget
QToolBox :: Column of tabbed widget items
QToolButton :: Quick-access button commands/options, usually used inside a QToolBar
QWidget :: The base class of all user interface objects
Perhaps the GUI elements (widgets) can be trimmed or alternatively send the terminal a
GUI System(version) identifier such as QT4.1(V1) TK(V1) (where V1 is the GUI terminal version).
Identifiers would allow the terminal advanced notice of what may be coming and know how to deal with it later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
PhiPi said...
Perl/Tk maybe. Tcl is pretty much a dinosaur these days.
I don't know what you mean here? It is still being developed, but is mature. Tcl isn't as old as Perl(1990 vs 1986), I think, but the Tcl/Tk combination is older than Perl/Tk.
I find Tcl one of the easiest languages I have ever learned, and one of the fastest I have used to build a useful applications. Before I learned Tcl, I used perl, but it took a lot longer to learn with it's unique variable references and hard to read code.
from cgibin.erols.com/ziring/cgi-bin/cep/cep.pl?_alpha=t
Tcl has extensive I/O capabilities, as well as good features for invoking and controlling local utility programs. Tcl also provides network I/O support, and mechanisms for asynchronous (event-driven) scripting
Tk is a comprehensive GUI toolkit offering the usual buttons, menus, labels, and scrollbars. It also offers higher-level facilties like lists, a vector-graphic canvas, a sophisticated text display/editor, color and clipboard management, and more.
Tcl was originally designed to be a common scripting language to be embedded in Unix graphical tools.
I was working on a Tcl/Tk interface for the propeller but ran into problems with echoing the commands back. The propeller could log into the linux serial port and start up the interface to toggle leds on the demoboard. After getting on the #tcl freenode IRC last night(with tkirc) I got some help that should resolve the echo problem, and probably eliminate the need for the propeller to login to the linux box.
With launching the python loader with the Tcl/Tk gui, one could kick the whole thing off. There is a lot of resources available at tcl.tk
@jazzed: Tcl/Tk....aren't window managers, they are graphical languages. Some window managers are twm, motif, fluxbox, fvwm, and windowmaker.
On another subject, I really like your gui things you have built for the prop...and your prop keychain.
hinv said...
@jazzed: Tcl/Tk....aren't window managers, they are graphical languages. Some window managers are twm, motif, fluxbox, fvwm, and windowmaker.
Of course. Please excuse me.
So what do you think of the list of widgets I posted? What are the common widgets for TK?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I like your widgets on the prop. I would love see you get most of the main ones working. It would eliminate the need for an external GUI for some. www.tcl.tk/man/tcl8.5/TkCmd/contents.htm is a list of all of the Tk commands in 8.5.
Comments
Have you made progress on your GUI command protocol?
Curious because having the Propeller (or other micro) interpret a lean command set and render the GUI on an LCD is attractive. This follows Cluso99's suggestion that the GUI does not have to necessarily rendered on a PC.
For example, attached are some pictures of my PocketProp LCD with some GUI elements developed last year (apologies for the picture quality).
Knowing what other elements you intend to support would be nice. As you see, I have 4 GUI elements defined. The attributes are simple so far and would of course require a command protocol for rendering and interaction. @Chris Micro's work allowing sliders and large text boxes on a PC window is also very interesting.
The "OK" button object interface for rendering with my Spin GUI library is defined as follows (events would be handled separately).
The point of showing this interface is to stimulate further definition of GUI element attributes. Whether the GUI is rendered on a PC, a Propeller terminal, or whatever, certain items must be defined. The HTML common object model really is a good example of attributes to support although a simpler version is desirable. One does not need to write HTML code or a parser of course.
Having a basic protocol that allows the terminal paint elements with it's own abilities (pretty features, etc...) with a minimal attribute set seems important. A Propeller TV/VGA based terminal may not be able to do 3D rendering because of color limits, but that should not stop it from doing basic element rendering.
One can negotiate terminal abilities, but that is not necessarily desirable. As you may know Telnet has a protocol for negotiating terminal capabilities; that still doesn't work perfectly as far as I know. Better to just avoid such negotiation if possible.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Presumably, if you have an object that encapsulates what is being sent to the GUI terminal, some information like the object type is kept in the object, but the index/name would be passed to the object. To keep things small instead of having an object hierarchy, a single generated Spin object containing renderer(s) and handlers could be used with the GUI widget list to send form/widget data to the terminal and handle events.
I've been spending *quality time* with Qt this morning. It's a nice environment.
One of the things that would be useful for GUI terminal users is to have a GUI designer. I've spent time on this before and hacked through a program to do design. Later I found wxWidgets did what I wanted, but that designer is not so friendly.
Enter the Qt Designer - this program can be used to design the GUI to be displayed in your GUI Terminal in a user friendly way. The output is an XML file that can be translated into whatever protocol you want to use, but in the case of Propeller, a Spin file (or other language like Java) can be automatically created to do rendering transmit and receive event handling.
Here is an example dialog as seen in the Qt Designer.
Rendering the framework of your GUI becomes as simple as creating the window, running the protocol translator, and adding text to a spin file or whatever. This is of course just for rendering although the .ui XML output does specify signals and slots (Events and Handlers). Using the Qt Designer also simplifies the definition task ... I prefer text for specifying fields and such to avoid version differences and other headaches. XML as generated is hard to parse in a micro-controller, so that has to go, but having ASCII names for certain things remains useful.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Post Edited (jazzed) : 3/25/2010 8:31:22 PM GMT
Well if we are to get serious about this project we really need to propose a protocol that we can all follow.
The protocol should have to following attributes:
-What is happening (adding, editing etc)
-A starting and ending code
-What objects that we want to display (textbox, button, dropdown)
-What events that the objects can send/recieve
So for example
@create, button, object name, x, y, width, height, events processed&
@modify,object name, attribute to be modified (ie x or y), parameter&
@event, object name, event attribute.
This is a very vague example but gives you some idea of what I was thinking. I would think that we should also replace the characters '@' and '&' with non alpha/numeric characters and also things like 'create' etc with codes instead of string literals. This should save on space because instead of sending the ascii string, you will send codes.
Jesse
Specifying a protocol can easily turn into a long and protracted academic debate so we should aim for a basic but functional specification first, to kick it off, but with just enough foresight so as to choose the best path. This may mean that instead of being able to describe the an object in all it's glory that we simply say BUTTON(0,0,142,64,"OK") just as a very rough example. In the serial stream a button "tag" would be followed by these basic parameters delimited by a delimiter tag or the start of another tag.
Working in reverse and writing a Spin application that interfaces to this as yet non-existent GUI terminal may be a better way of getting a feel for what is needed rather than trying to predict what "may" be needed.
I don't really have much time this week but next week I will try to create a Qt serial app along these lines as a demonstration and as a basis for discussion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
/home/doug> /usr/bin/wish
% button .b -text "Howdy" -command {puts "Hello, World!"}
.b
% pack .b
What do you guys think? Have you looked into Tcl/Tk?
Doug
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
-Phil
I've been able to build the example applications and tested enumeration up to COM20 which is a BIG win.
This is exciting enough to motivate me to do Qt versions of my .net tools [noparse]:)[/noparse]
Regarding window managers ....
Perl/Tk
Tcl/Tk
Py/Tk
Cocoa
Qt4
Wx
VB6
Net2
Net3.5
Whatever ...
... and the list goes on [noparse]:)[/noparse]
Once the application rendering/event protocol is defined you can write the terminal with any tool for any platform.
It may be a while before some consensus on a common protocol is reached. The free market approach (anyone
developing anything and a leader ultimately emerging) can produce a reasonable end result. Of course it may
or may not be better or be available faster than a solution developed in open collaboration. Designing something
new by committee can be difficult and time consuming. Leveraging a model that already exists and works can
speed things up.
Now, trying to following Jesse Massey's outline:
1. What is happening (adding, editing etc) Understood 2. A starting and ending code Unclear ... is this a packet transfer reference or what? Maybe you mean like Form_Load / Unload from VB ? 3. What objects that we want to display (textbox, button, dropdown) Understood 4. What events that the objects can send/recieve Understood 5. Additionally, numeric data byte order must be defined if strings are not used. Treating everything as a string eliminates this problem.
Here is a starting list for item 3. It is obviously influenced by Qt.Perhaps the GUI elements (widgets) can be trimmed or alternatively send the terminal a
GUI System(version) identifier such as QT4.1(V1) TK(V1) (where V1 is the GUI terminal version).
Identifiers would allow the terminal advanced notice of what may be coming and know how to deal with it later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Post Edited (jazzed) : 3/26/2010 7:48:13 PM GMT
I don't know what you mean here? It is still being developed, but is mature. Tcl isn't as old as Perl(1990 vs 1986), I think, but the Tcl/Tk combination is older than Perl/Tk.
I find Tcl one of the easiest languages I have ever learned, and one of the fastest I have used to build a useful applications. Before I learned Tcl, I used perl, but it took a lot longer to learn with it's unique variable references and hard to read code.
from cgibin.erols.com/ziring/cgi-bin/cep/cep.pl?_alpha=t
Tcl has extensive I/O capabilities, as well as good features for invoking and controlling local utility programs. Tcl also provides network I/O support, and mechanisms for asynchronous (event-driven) scripting
Tk is a comprehensive GUI toolkit offering the usual buttons, menus, labels, and scrollbars. It also offers higher-level facilties like lists, a vector-graphic canvas, a sophisticated text display/editor, color and clipboard management, and more.
Tcl was originally designed to be a common scripting language to be embedded in Unix graphical tools.
I was working on a Tcl/Tk interface for the propeller but ran into problems with echoing the commands back. The propeller could log into the linux serial port and start up the interface to toggle leds on the demoboard. After getting on the #tcl freenode IRC last night(with tkirc) I got some help that should resolve the echo problem, and probably eliminate the need for the propeller to login to the linux box.
With launching the python loader with the Tcl/Tk gui, one could kick the whole thing off. There is a lot of resources available at tcl.tk
Doug
On another subject, I really like your gui things you have built for the prop...and your prop keychain.
So what do you think of the list of widgets I posted? What are the common widgets for TK?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
www.tcl.tk/man/tcl8.5/TkCmd/contents.htm is a list of all of the Tk commands in 8.5.