Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GUI and TUI common design
301 views
Skip to first unread message
James Harris
Sep 4, 2013, 10:57:01 AM9/4/13
to
Just some thoughts....
GUIs have some known and familiar elements such as buttons, combo boxes,
menus etc.
Such elements usually exist within and are laid out in a window. The window
provides a grouping function for those elements.
The windows themselves are often floating and may be moved around and/or
overlaid as required by the user.
The layout of elements within windows is usually fixed, under the assumption
that a display is big enough. However, it is sometimes not. Theoretically,
scroll bars could be used if the display is too small though I have seen
windows which don't fit on a screen and don't have scroll bars so some of
the window is inaccessible (such as Windows running on a small Asus EEE).
Aside from their physical layout, window elements have a semantic aspect
that is not dependent on where they are placed except in regard to things
like labels having to appear adjacent to text-entry boxes; such things must
be kept together to make sense to the user. The semantic part means
something specific and relates to communication between user and
application.
The above comments could apply to a TUI as well as to a GUI. Aside from the
more cumbersome appearance of a TUI it should be able to support most of the
same elements.
When laid out, the elements in a TUI may well take up more space than they
would on a GUI so they would be less likely to fit in a specific screen
area.
Given the above, it may be possible for an app to use exactly the same code
to manage windows that are rendered on either a GUI or a TUI. I am thinking
that the app would specify the GUI/TUI in such a way that it could be
rendered appropriately. For example, it would not dictate the layout in most
cases (though it could provide hints as to desirable layout) but would focus
on the elements it needs. It would separate the layout from the semantics of
the window elements and how they needed to be grouped together. The renderer
would convert that to a specific layout depending on the mode
(text/graphical), resolution of the underlying canvas and hints provided by
the application.
The idea is for a program to provide a user interface with the
normally-expected elements in such a way that it will work in either text or
graphics mode. For any program the text mode would be useful when no GUI was
possible such as when using a terminal session to another machine. It would
also be useful in the early days of an OS development. And it would allow a
GUI to be rendered automatically on screens of different sizes.
I got to thinking of this in the former case. I was looking at writing a
program to explore and interpret binary files. A text-mode windowing
interface would be ideal for that and would be easy to run on different
environments and under different operating systems.
Am posting here because ISTM it would also be helpful for OS development. A
windowing system could be developed in text mode and later used as a GUI
without having to rewrite the code.
Maybe someone has already defined a common GUI/TUI API but I haven't found
one.
Such a system would have to be defined in layers. There would be widgets and
layout controls at the top and, essentially, rectangles at the bottom. Some
elements would be recursively placeable so that, for example, a given
rectangle could have other rectangles within it and thus effect layouts that
the programmer wants. Further, the programmer should be able to hint at how
essential a given layout is so that the elements could be best shown on a
screen which is not big enough for the ideal layout. Perhaps a user could
even be allowed to move elements within a window rather than just moving
windows.
Bottom line: if there was a GUI/TUI "language" then elements of a user
interface could be defined and used whether the program or OS was running in
a graphical or a textual environment.
James
GUIs have some known and familiar elements such as buttons, combo boxes,
menus etc.
Such elements usually exist within and are laid out in a window. The window
provides a grouping function for those elements.
The windows themselves are often floating and may be moved around and/or
overlaid as required by the user.
The layout of elements within windows is usually fixed, under the assumption
that a display is big enough. However, it is sometimes not. Theoretically,
scroll bars could be used if the display is too small though I have seen
windows which don't fit on a screen and don't have scroll bars so some of
the window is inaccessible (such as Windows running on a small Asus EEE).
Aside from their physical layout, window elements have a semantic aspect
that is not dependent on where they are placed except in regard to things
like labels having to appear adjacent to text-entry boxes; such things must
be kept together to make sense to the user. The semantic part means
something specific and relates to communication between user and
application.
The above comments could apply to a TUI as well as to a GUI. Aside from the
more cumbersome appearance of a TUI it should be able to support most of the
same elements.
When laid out, the elements in a TUI may well take up more space than they
would on a GUI so they would be less likely to fit in a specific screen
area.
Given the above, it may be possible for an app to use exactly the same code
to manage windows that are rendered on either a GUI or a TUI. I am thinking
that the app would specify the GUI/TUI in such a way that it could be
rendered appropriately. For example, it would not dictate the layout in most
cases (though it could provide hints as to desirable layout) but would focus
on the elements it needs. It would separate the layout from the semantics of
the window elements and how they needed to be grouped together. The renderer
would convert that to a specific layout depending on the mode
(text/graphical), resolution of the underlying canvas and hints provided by
the application.
The idea is for a program to provide a user interface with the
normally-expected elements in such a way that it will work in either text or
graphics mode. For any program the text mode would be useful when no GUI was
possible such as when using a terminal session to another machine. It would
also be useful in the early days of an OS development. And it would allow a
GUI to be rendered automatically on screens of different sizes.
I got to thinking of this in the former case. I was looking at writing a
program to explore and interpret binary files. A text-mode windowing
interface would be ideal for that and would be easy to run on different
environments and under different operating systems.
Am posting here because ISTM it would also be helpful for OS development. A
windowing system could be developed in text mode and later used as a GUI
without having to rewrite the code.
Maybe someone has already defined a common GUI/TUI API but I haven't found
one.
Such a system would have to be defined in layers. There would be widgets and
layout controls at the top and, essentially, rectangles at the bottom. Some
elements would be recursively placeable so that, for example, a given
rectangle could have other rectangles within it and thus effect layouts that
the programmer wants. Further, the programmer should be able to hint at how
essential a given layout is so that the elements could be best shown on a
screen which is not big enough for the ideal layout. Perhaps a user could
even be allowed to move elements within a window rather than just moving
windows.
Bottom line: if there was a GUI/TUI "language" then elements of a user
interface could be defined and used whether the program or OS was running in
a graphical or a textual environment.
James
Rod Pemberton
Sep 5, 2013, 8:03:03 AM9/5/13
to
On Wed, 04 Sep 2013 10:57:01 -0400, James Harris
<james.h...@gmail.com> wrote:
> [GUI and TUI equivalences]
> [...]
to in GUIs were first developed for TUIs with mouse support.
You can look at Microsoft and old Borland applications, such
as Borland's Turbo C/C++ text IDE and Microsoft's text-based
OS setup, and see text boxes, scroll bars, buttons, drop-down
menu's, progress indicators, busy indicators, zoom windows, etc.
I'm not sure about check-boxes...
> A windowing system could be developed in text mode and later
> used as a GUI without having to rewrite the code.
Yes, I think so too.
> Such a system would have to be defined in layers. There would
> be widgets and layout controls at the top and, essentially,
> rectangles at the bottom.
I think the real issue you'll face is deciding on which OS
platform and which high-level language to use. I.e., if you
ask for help starting a project from scratch, people are going
to try to get you to chose some things that may not fit your
needs. It's probably best for you to decide some of those
things upfront and do some work first to establish an
existing code base before recruiting people. Then, if they
decide to join your project, they're required to comply with
those already existing constraints set by you. E.g., if the
base code is in C, it's not going to be converted to Lua for
a long time, if ever... That could be important if you don't
prefer the most popular language or feature set, etc.
> Some elements would be recursively placeable so that, for
> example, a given rectangle could have other rectangles
> within it and thus effect layouts that the programmer wants.
How is "recursive rectangles" different from specifying a
window order when multiple windows are on screen? I.e.,
specifying when one window is on top or beneath another
window, or required to be on top or hidden. ISTM, the only
differences are the "recursive" windows are smaller than
some other window, on top of a larger window, and enclosed
by it.
> Bottom line: if there was a GUI/TUI "language" then elements
> of a user interface could be defined and used whether the
> program or OS was running in a graphical or a textual environment.
I don't know if there is a "language" for this, but I seem
to recall Windows developed from TUI to GUI. Linux seems to be
able to output the same bootup messages to either a text console
or a graphics mode depending on Grub configuration settings.
There are a number of open source packages that implement
windowing, but have no idea if they support both TUI and GUI.
Rod Pemberton
<james.h...@gmail.com> wrote:
> [GUI and TUI equivalences]
>
> Given the above, it may be possible for an app to use exactly
> the same code to manage windows that are rendered on either a
> GUI or a TUI.
Yes, I agree.
> Given the above, it may be possible for an app to use exactly
> the same code to manage windows that are rendered on either a
> GUI or a TUI.
> [...]
>
> The idea is for a program to provide a user interface with
> the normally-expected elements in such a way that it will work
> in either text or graphics mode.
I'm pretty sure all the windowing elements one is accustomed
> The idea is for a program to provide a user interface with
> the normally-expected elements in such a way that it will work
> in either text or graphics mode.
to in GUIs were first developed for TUIs with mouse support.
You can look at Microsoft and old Borland applications, such
as Borland's Turbo C/C++ text IDE and Microsoft's text-based
OS setup, and see text boxes, scroll bars, buttons, drop-down
menu's, progress indicators, busy indicators, zoom windows, etc.
I'm not sure about check-boxes...
> A windowing system could be developed in text mode and later
> used as a GUI without having to rewrite the code.
> Such a system would have to be defined in layers. There would
> be widgets and layout controls at the top and, essentially,
> rectangles at the bottom.
platform and which high-level language to use. I.e., if you
ask for help starting a project from scratch, people are going
to try to get you to chose some things that may not fit your
needs. It's probably best for you to decide some of those
things upfront and do some work first to establish an
existing code base before recruiting people. Then, if they
decide to join your project, they're required to comply with
those already existing constraints set by you. E.g., if the
base code is in C, it's not going to be converted to Lua for
a long time, if ever... That could be important if you don't
prefer the most popular language or feature set, etc.
> Some elements would be recursively placeable so that, for
> example, a given rectangle could have other rectangles
> within it and thus effect layouts that the programmer wants.
window order when multiple windows are on screen? I.e.,
specifying when one window is on top or beneath another
window, or required to be on top or hidden. ISTM, the only
differences are the "recursive" windows are smaller than
some other window, on top of a larger window, and enclosed
by it.
> Bottom line: if there was a GUI/TUI "language" then elements
> of a user interface could be defined and used whether the
> program or OS was running in a graphical or a textual environment.
to recall Windows developed from TUI to GUI. Linux seems to be
able to output the same bootup messages to either a text console
or a graphics mode depending on Grub configuration settings.
There are a number of open source packages that implement
windowing, but have no idea if they support both TUI and GUI.
Rod Pemberton
James Harris
Sep 5, 2013, 9:41:42 AM9/5/13
to
"Rod Pemberton" <dont_us...@nohavenotit.com> wrote in message
news:op.w2xs3dfu0e5s1z@-...
...
It's good to know of your agreement on the basic points above (snipped)!
>> Such a system would have to be defined in layers. There would
>> be widgets and layout controls at the top and, essentially,
>> rectangles at the bottom.
>
> I think the real issue you'll face is deciding on which OS
> platform and which high-level language to use. I.e., if you
> ask for help starting a project from scratch, people are going
> to try to get you to chose some things that may not fit your
> needs. It's probably best for you to decide some of those
> things upfront and do some work first to establish an
> existing code base before recruiting people. Then, if they
> decide to join your project, they're required to comply with
> those already existing constraints set by you. E.g., if the
> base code is in C, it's not going to be converted to Lua for
> a long time, if ever... That could be important if you don't
> prefer the most popular language or feature set, etc.
I don't intend to start a project for this - at least not just now. My
comments were just observations.
That said, it might be possible for one person to define a suitable API and
then fairly easily implement it in text mode. As long as the API was good it
could later be implemented in graphics mode also.
I suspect the two hard parts of the task would be 1) getting the API right
and 2) implementing the graphical version. Graphics mode could be written
later but text mode might be fairly easy to write and enable progress to be
quickly made.
Of course, graphics mode could support a few widgets that text mode could
not such as button bars and canvasses for displaying or editing pictures.
They would not be practical in text mode. However, as you illustrated, most
elements would work in both modes.
>> Some elements would be recursively placeable so that, for
>> example, a given rectangle could have other rectangles
>> within it and thus effect layouts that the programmer wants.
>
> How is "recursive rectangles" different from specifying a
> window order when multiple windows are on screen? I.e.,
> specifying when one window is on top or beneath another
> window, or required to be on top or hidden. ISTM, the only
> differences are the "recursive" windows are smaller than
> some other window, on top of a larger window, and enclosed
> by it.
Maybe. I'll try to illustrate the rectangles approach for constructing a
typical window, i.e. just one window. The window itself would be the
enclosing rectangle. It would contain others such as a rectangle at the top
to form the title bar. Below the title bar rectangle would be another
rectangle to form the menu bar. Below that might be a main rectangle to
cover the rest of the window. That main rectangle might be divided into left
and right rectangles and they might be further subdivided. At some point
buttons, spinners, scroll bars etc would be further rectangles. At least
that's the idea.
I should say that the above description suggests a particular arrangement of
elements. Due to lack of space in a text window it might be better to be
less prescriptive as to layout. I'm not sure yet.
One thing I do know from experience with WX widgets is that the right
arrangement of rectangles should be able to make windows sensibly
resizable - something that is lacking in UI elements where windows have a
fixed size. (If anyone wants to check the WX features I think it calls them
sizers.) That could be a big help when adapting a window definition to a
very limited text mode display.
>> Bottom line: if there was a GUI/TUI "language" then elements
>> of a user interface could be defined and used whether the
>> program or OS was running in a graphical or a textual environment.
>
> I don't know if there is a "language" for this, but I seem
> to recall Windows developed from TUI to GUI. Linux seems to be
> able to output the same bootup messages to either a text console
> or a graphics mode depending on Grub configuration settings.
>
> There are a number of open source packages that implement
> windowing, but have no idea if they support both TUI and GUI.
Thinking of having a single description and allowing it to be implemented in
graphics mode and in text mode where the space available may be very limited
here's an example to try to illustrate how semantics might be separated from
appearance.
The application's menu could be defined as a hierarchy of options. The File
option would have children such as Open and Exit, Edit would have children
such as Copy and Paste etc.
Once the menu has been defined it could be placed in the window and work in
text or graphics mode. If the display area is very small the menu bar could
be omitted to save space but still made accessible via right click or via
keystrokes. For example, Alt+F could still work to pull down the File menu
even if the menu bar was not visible. The application would then be able to
work the same way whether the menu was visible or not.
Of course, the menu bar doesn't take up much space but there might be
similar ways to deal with other elements, i.e. to separate semantics from
appearance.
As mentioned, I posted here as I thought the above ideas might allow an OS
to get a windowing shell working quickly. It certainly seems feasible at the
moment.
James
news:op.w2xs3dfu0e5s1z@-...
...
It's good to know of your agreement on the basic points above (snipped)!
>> Such a system would have to be defined in layers. There would
>> be widgets and layout controls at the top and, essentially,
>> rectangles at the bottom.
>
> I think the real issue you'll face is deciding on which OS
> platform and which high-level language to use. I.e., if you
> ask for help starting a project from scratch, people are going
> to try to get you to chose some things that may not fit your
> needs. It's probably best for you to decide some of those
> things upfront and do some work first to establish an
> existing code base before recruiting people. Then, if they
> decide to join your project, they're required to comply with
> those already existing constraints set by you. E.g., if the
> base code is in C, it's not going to be converted to Lua for
> a long time, if ever... That could be important if you don't
> prefer the most popular language or feature set, etc.
comments were just observations.
That said, it might be possible for one person to define a suitable API and
then fairly easily implement it in text mode. As long as the API was good it
could later be implemented in graphics mode also.
I suspect the two hard parts of the task would be 1) getting the API right
and 2) implementing the graphical version. Graphics mode could be written
later but text mode might be fairly easy to write and enable progress to be
quickly made.
Of course, graphics mode could support a few widgets that text mode could
not such as button bars and canvasses for displaying or editing pictures.
They would not be practical in text mode. However, as you illustrated, most
elements would work in both modes.
>> Some elements would be recursively placeable so that, for
>> example, a given rectangle could have other rectangles
>> within it and thus effect layouts that the programmer wants.
>
> How is "recursive rectangles" different from specifying a
> window order when multiple windows are on screen? I.e.,
> specifying when one window is on top or beneath another
> window, or required to be on top or hidden. ISTM, the only
> differences are the "recursive" windows are smaller than
> some other window, on top of a larger window, and enclosed
> by it.
typical window, i.e. just one window. The window itself would be the
enclosing rectangle. It would contain others such as a rectangle at the top
to form the title bar. Below the title bar rectangle would be another
rectangle to form the menu bar. Below that might be a main rectangle to
cover the rest of the window. That main rectangle might be divided into left
and right rectangles and they might be further subdivided. At some point
buttons, spinners, scroll bars etc would be further rectangles. At least
that's the idea.
I should say that the above description suggests a particular arrangement of
elements. Due to lack of space in a text window it might be better to be
less prescriptive as to layout. I'm not sure yet.
One thing I do know from experience with WX widgets is that the right
arrangement of rectangles should be able to make windows sensibly
resizable - something that is lacking in UI elements where windows have a
fixed size. (If anyone wants to check the WX features I think it calls them
sizers.) That could be a big help when adapting a window definition to a
very limited text mode display.
>> Bottom line: if there was a GUI/TUI "language" then elements
>> of a user interface could be defined and used whether the
>> program or OS was running in a graphical or a textual environment.
>
> I don't know if there is a "language" for this, but I seem
> to recall Windows developed from TUI to GUI. Linux seems to be
> able to output the same bootup messages to either a text console
> or a graphics mode depending on Grub configuration settings.
>
> There are a number of open source packages that implement
> windowing, but have no idea if they support both TUI and GUI.
graphics mode and in text mode where the space available may be very limited
here's an example to try to illustrate how semantics might be separated from
appearance.
The application's menu could be defined as a hierarchy of options. The File
option would have children such as Open and Exit, Edit would have children
such as Copy and Paste etc.
Once the menu has been defined it could be placed in the window and work in
text or graphics mode. If the display area is very small the menu bar could
be omitted to save space but still made accessible via right click or via
keystrokes. For example, Alt+F could still work to pull down the File menu
even if the menu bar was not visible. The application would then be able to
work the same way whether the menu was visible or not.
Of course, the menu bar doesn't take up much space but there might be
similar ways to deal with other elements, i.e. to separate semantics from
appearance.
As mentioned, I posted here as I thought the above ideas might allow an OS
to get a windowing shell working quickly. It certainly seems feasible at the
moment.
James
Rod Pemberton
Sep 5, 2013, 6:46:53 PM9/5/13
to
On Thu, 05 Sep 2013 09:41:42 -0400, James Harris
<james.h...@gmail.com> wrote:
> "Rod Pemberton" <dont_us...@nohavenotit.com> wrote in message
> news:op.w2xs3dfu0e5s1z@-...
> ...
>
> It's good to know of your agreement on the basic points above (snipped)!
>
As you may recall, what I did for my OS was entirely text based: one
<james.h...@gmail.com> wrote:
> "Rod Pemberton" <dont_us...@nohavenotit.com> wrote in message
> news:op.w2xs3dfu0e5s1z@-...
> ...
>
> It's good to know of your agreement on the basic points above (snipped)!
>
single text mode. Well, after I was messing with VESA a while back,
I've began thinking about a different method of implementing TUI to GUI.
Of course, I had no interest in coding a GUI, so I began thinking about
converting TUI output to GUI. The idea I was thinking about was to only
implement TUI output. Then, a conversion routine would get the entire
text screen and redraw it as high-res graphics. E.g., if it ran across
a line of dashes on the text screen, that would be scaled and redrawn
as a solid graphics line for the graphics mode, ditto vertical, etc.
I still like the idea. There may be some limitations or issues with
scaling, screen size, or identifying input text boxes etc that would
have to be worked out. Like you, I've not done anything with this idea,
yet. So, the API would just be TUI routines only. The other conversion
process would do the GUI from TUI.
> That said, it might be possible for one person to define a suitable API
> and then fairly easily implement it in text mode. As long as the API was
> good it could later be implemented in graphics mode also.
routines. It's definately not a TUI, but enough to implement one with
"standard" (follows Borland's Turbo C lead ... ?) DOS functions.
E.g., I implemented a TUI front end for a text editor in DOS with
drop-down text menus and mouse support, but never got around to coding
the text editor itself. Although, all the other stuff, like scroll bars,
text boxes, buttons or bullets, was never implmented by me as I saw
no need... Some direct manipulation of the screen was still necessary.
DJGPP had better support for this. OpenWatcom seemed to have more
functions, but had more restrictedd features. AIR, I also had to create
a special function to save/restore screen memory for OpenWatcom, e.g.,
save/restore text region under displayed drop-down menu.
You could also look at the classic "curses" package, or PDCURSES
the Public Domain version, for TUI ideas, e.g., used by Lynx
text web browser. I'd bet that Wikipedia has a page on curses.
I think I mentioned previously that one platform I coded for
had a text, form generator. You described where you wanted text
or numeric fields placed, whether they were input or ouput,
size, formatting, etc and it generated code to correctly display,
access, update, allow input to, format, etc the screen elements.
Rod Pemberton
wolfgang kern
Sep 9, 2013, 5:30:15 AM9/9/13
to
James Harris posted 'Just some thoughts....'
[...]
> The above comments could apply to a TUI as well as to a GUI.
> Aside from the more cumbersome appearance of a TUI it should be able to
> support most of the same elements.
Yes, but...
> Aside from the more cumbersome appearance of a TUI it should be able to
> support most of the same elements.
> When laid out, the elements in a TUI may well take up more space than they
> would on a GUI so they would be less likely to fit in a specific screen
> area.
a font cell size of 8*16 and 16+16 color-attributes.
This mode was size- and view equivalent to the 1024*768,256 graphic-mode.
Even the matching graphic-mode for mode 03 would be 640*400,256, modern
graphic cards lack on detailed information to setup custom text modes to
fit my prefered 1024*768 and higher resolutions.
> Given the above, it may be possible for an app to use exactly the same
> code to manage windows that are rendered on either a GUI or a TUI.
common parameter layout (esi=strptr eax=format-bits ecx=size if NZT).
But right after this point it splits into totally apart code-parts.
> I am thinking that the app would specify the GUI/TUI in such a way that it
> could be rendered appropriately. For example, it would not dictate the
> layout in most cases (though it could provide hints as to desirable
> layout) but would focus on the elements it needs. It would separate the
> layout from the semantics of the window elements and how they needed to be
> grouped together. The renderer would convert that to a specific layout
> depending on the mode (text/graphical), resolution of the underlying
> canvas and hints provided by the application.
But I can't imagine how to convert clickable Icons and bitmaps (like
mouse-moveable scales/bars) into text-fields without loosing precision.
> The idea is for a program to provide a user interface with the
> normally-expected elements in such a way that it will work in either text
> or graphics mode. For any program the text mode would be useful when no
> GUI was possible such as when using a terminal session to another machine.
> It would also be useful in the early days of an OS development.
when a hex-dump tool is able to loop the display and show changes like
running counters (speed limited just by the monitors FPS).
> And it would allow a GUI to be rendered automatically on screens of
> different sizes.
directory view. And instead of scroll-bars I show 'page', ie: 1 of 30,
with Numinput and PGUP/PGDN/HOME/END key-support.
> I got to thinking of this in the former case. I was looking at writing a
> program to explore and interpret binary files. A text-mode windowing
> interface would be ideal for that and would be easy to run on different
> environments and under different operating systems.
> Am posting here because ISTM it would also be helpful for OS development.
> A windowing system could be developed in text mode and later used as a
> GUI without having to rewrite the code.
> Maybe someone has already defined a common GUI/TUI API but I haven't found
> one.
vertical lists, where all additional graphic-elements (borders, circels,
bitmaps,...) were just ignored in text mode.
> Such a system would have to be defined in layers. There would be widgets
> and layout controls at the top and, essentially, rectangles at the
> bottom.
> Some elements would be recursively placeable so that, for example, a given
> rectangle could have other rectangles within it and thus effect layouts
> that the programmer wants. Further, the programmer should be able to hint
> at how essential a given layout is so that the elements could be best
> shown on a screen which is not big enough for the ideal layout. Perhaps a
> user could even be allowed to move elements within a window rather than
> just moving windows.
for all supported modes anyway. Apps usually set their desired mode.
I daubt that an API can be made that smart to cover all opportunities.
Your suggestion for predefined layouts and elements reminds on windoze :)
> Bottom line: if there was a GUI/TUI "language" then elements of a user
> interface could be defined and used whether the program or OS was running
> in a graphical or a textual environment.
then I can't see how a full-screen input-field matrix could be displayed
on a 80*25 mode_3 screen.
And the opposite, ie: a msg-box in text-mode 40*25 APP would show up
as a post-stamp at the top left corner of a 3200*2400 screen without
converting all size and position information (the OS cant do this on
its own, because it dont know about the original resolution).
Ok if you mean only message-boxes, pulldown-menus and a few simple
button-styles to adapt here,
...but there are many other graphic elements used in my OS which I
could never transform into text-based equivalents without creating
totally new functions to achieve the same results.
__
wolfgang
s_dub...@yahoo.com
Sep 9, 2013, 7:07:20 PM9/9/13
to
On Wednesday, September 4, 2013 9:57:01 AM UTC-5, James Harris wrote:
> Just some thoughts....
>
>
>
> GUIs have some known and familiar elements such as buttons, combo boxes,
>
> menus etc.
>
>
>
> Such elements usually exist within and are laid out in a window. The window
>
> provides a grouping function for those elements.
>
>
>
> The windows themselves are often floating and may be moved around and/or
>
> overlaid as required by the user.
>
>
>
> The layout of elements within windows is usually fixed, under the assumption
>
> that a display is big enough. However, it is sometimes not. Theoretically,
>
> scroll bars could be used if the display is too small though I have seen
>
> windows which don't fit on a screen and don't have scroll bars so some of
>
> the window is inaccessible (such as Windows running on a small Asus EEE).
>
>
>
> Aside from their physical layout, window elements have a semantic aspect
>
> that is not dependent on where they are placed except in regard to things
>
> like labels having to appear adjacent to text-entry boxes; such things must
>
> be kept together to make sense to the user. The semantic part means
>
> something specific and relates to communication between user and
>
> application.
>
>
>
> The above comments could apply to a TUI as well as to a GUI. Aside from the
>
> more cumbersome appearance of a TUI it should be able to support most of the
>
> same elements.
>
Similar elements -
> Just some thoughts....
>
>
>
> GUIs have some known and familiar elements such as buttons, combo boxes,
>
> menus etc.
>
>
>
> Such elements usually exist within and are laid out in a window. The window
>
> provides a grouping function for those elements.
>
>
>
> The windows themselves are often floating and may be moved around and/or
>
> overlaid as required by the user.
>
>
>
> The layout of elements within windows is usually fixed, under the assumption
>
> that a display is big enough. However, it is sometimes not. Theoretically,
>
> scroll bars could be used if the display is too small though I have seen
>
> windows which don't fit on a screen and don't have scroll bars so some of
>
> the window is inaccessible (such as Windows running on a small Asus EEE).
>
>
>
> Aside from their physical layout, window elements have a semantic aspect
>
> that is not dependent on where they are placed except in regard to things
>
> like labels having to appear adjacent to text-entry boxes; such things must
>
> be kept together to make sense to the user. The semantic part means
>
> something specific and relates to communication between user and
>
> application.
>
>
>
> The above comments could apply to a TUI as well as to a GUI. Aside from the
>
> more cumbersome appearance of a TUI it should be able to support most of the
>
> same elements.
>
http://www.mixsoftware.com/product/window.htm
>
> When laid out, the elements in a TUI may well take up more space than they
>
> would on a GUI so they would be less likely to fit in a specific screen
>
> area.
>
>
>
> Given the above, it may be possible for an app to use exactly the same code
>
> to manage windows that are rendered on either a GUI or a TUI. I am thinking
>
> that the app would specify the GUI/TUI in such a way that it could be
>
> rendered appropriately. For example, it would not dictate the layout in most
>
> cases (though it could provide hints as to desirable layout) but would focus
>
> on the elements it needs. It would separate the layout from the semantics of
>
> the window elements and how they needed to be grouped together. The renderer
>
> would convert that to a specific layout depending on the mode
>
> (text/graphical), resolution of the underlying canvas and hints provided by
>
> the application.
>
> The idea is for a program to provide a user interface with the
>
> normally-expected elements in such a way that it will work in either text or
>
> graphics mode. For any program the text mode would be useful when no GUI was
>
> possible such as when using a terminal session to another machine. It would
>
> also be useful in the early days of an OS development. And it would allow a
>
> GUI to be rendered automatically on screens of different sizes.
> I got to thinking of this in the former case. I was looking at writing a
>
> program to explore and interpret binary files. A text-mode windowing
>
> interface would be ideal for that and would be easy to run on different
>
> environments and under different operating systems.
>
>
>
> Am posting here because ISTM it would also be helpful for OS development. A
>
> windowing system could be developed in text mode and later used as a GUI
>
> without having to rewrite the code.
>
>
>
> Maybe someone has already defined a common GUI/TUI API but I haven't found
>
> one.
The paradigm of text and graphics are different in certain respects; text is fixed width, 8x8, 9x16, whereas graphics text is proportional. So what ends up is a text emulation in graphics. I'm thinking of a dos windowing application rendered in a dos box on XP, changing the window size changes the fixed width font, and text based window elements/controls, in a scaled fashion. But this all drifts away from what you had in mind.
> Such a system would have to be defined in layers. There would be widgets and
>
> layout controls at the top and, essentially, rectangles at the bottom. Some
>
> elements would be recursively placeable so that, for example, a given
>
> rectangle could have other rectangles within it and thus effect layouts that
>
> the programmer wants. Further, the programmer should be able to hint at how
>
> essential a given layout is so that the elements could be best shown on a
>
> screen which is not big enough for the ideal layout. Perhaps a user could
>
> even be allowed to move elements within a window rather than just moving
>
> windows.
>
>
>
> Bottom line: if there was a GUI/TUI "language" then elements of a user
>
> interface could be defined and used whether the program or OS was running in
>
> a graphical or a textual environment.
>
-But, am I correct to see you coming around to some 'display control language' in your thoughts?
Steve
>
>
> James
James Harris
Sep 10, 2013, 3:23:27 AM9/10/13
to
"wolfgang kern" <now...@never.at> wrote in message
news:l0k82h$mir$1...@newsreader2.utanet.at...
...
>> I am thinking that the app would specify the GUI/TUI in such a way that
>> it could be rendered appropriately. For example, it would not dictate the
>> layout in most cases (though it could provide hints as to desirable
>> layout) but would focus on the elements it needs. It would separate the
>> layout from the semantics of the window elements and how they needed to
>> be grouped together. The renderer would convert that to a specific layout
>> depending on the mode (text/graphical), resolution of the underlying
>> canvas and hints provided by the application.
>
> I see no problem with displaying text-based apps in graphic-mode.
> But I can't imagine how to convert clickable Icons and bitmaps (like
> mouse-moveable scales/bars) into text-fields without loosing precision.
Rather than converting pre-existing GUI elements into text I was thinking
more of defining the essential elements of a user interface and specifying
them in a way that could be rendered as text or graphics. Icons and bitmaps
could not be rendered but scroll bars could.
As mentioned, I'm not proposing a complete solution. These were just some
ideas and are not something I am working on. However, to try to illustrate
what I had in mind perhaps a UI could be defined in the following terms.
Title: usually a bar at the top
Menu: bar and/or pop-up
Status: usually a bar
Clickables: buttons and links
Text entry: boxes, areas
Drop-downs: list selection and combo boxes
Check boxes and radio buttons
Grid
Sliders including scroll bars
Spinners
All of these could appear in either text or graphics mode.
...
>> Am posting here because ISTM it would also be helpful for OS development.
>> A windowing system could be developed in text mode and later used as a
>> GUI without having to rewrite the code.
>
> Yes, in this direction it would work.
Cool.
>> Maybe someone has already defined a common GUI/TUI API but I haven't
>> found one.
>
> As mentioned above, my only G/T-'API' is the formatted text output incl.
> vertical lists, where all additional graphic-elements (borders, circels,
> bitmaps,...) were just ignored in text mode.
I have thought that if windows were allowed to overlap in text mode there
would need to be some way to distinguish one window from another. For that
case a border might be useful and there are characters that can be rendered
as lines. Alternatively, or if space were really tight, each window could
have a different background colour.
>> Such a system would have to be defined in layers. There would be widgets
>> and layout controls at the top and, essentially, rectangles at the
>> bottom.
>> Some elements would be recursively placeable so that, for example, a
>> given rectangle could have other rectangles within it and thus effect
>> layouts that the programmer wants. Further, the programmer should be
>> able to hint at how essential a given layout is so that the elements
>> could be best shown on a screen which is not big enough for the ideal
>> layout. Perhaps a user could even be allowed to move elements within a
>> window rather than just moving windows.
>
> Methink that an APP which can run in both modes should contain layouts
> for all supported modes anyway. Apps usually set their desired mode.
> I daubt that an API can be made that smart to cover all opportunities.
> Your suggestion for predefined layouts and elements reminds on windoze :)
I was really suggesting that the layouts not be predefined but to allow for
hints along the lines of: if there is enough space then lay elements out in
this way.
You'll see I omitted text output aka label boxes from the list above. That's
because they often need to relate to some other control and would need to be
specified along with the control to which they relate. That would allow two
things. First, even though the screen layout can be altered by the rendering
process (to fit the screen) defining them together would allow the renderer
to keep them together. The label might have to be moved from beside the
control to above the control but it could still be kept with the element to
which it relates.
Second, some elements can be selected by Alt+key where the key is underlined
in the label. Defining the label with the control would allow the TUI or GUI
to know which control to select when that alt key combination is pressed.
>> Bottom line: if there was a GUI/TUI "language" then elements of a user
>> interface could be defined and used whether the program or OS was running
>> in a graphical or a textual environment.
>
> Sure, but when I think about an APP written for 1920*1080,32-bit,
> then I can't see how a full-screen input-field matrix could be displayed
> on a 80*25 mode_3 screen.
The idea would not be to convert a big GUI to work in small text mode but to
allow UI elements to be specified in a way that could be rendered on both.
In other words, one would start from the definition of the essential
elements and work from there to the display mechanism. On a large screen all
the elements might be visible at once. On a small text screen the user might
have to scroll up and down to get to all of the elements. For the TUI the
elements themselves would be more chunky and not so good to look at but they
would operate as normal.
The user could even be allowed to rearrange the UI elements within the TUI
or to change some of them from visible to ones which would pop up on
request. For example, a combo box could be just a single dot on the screen.
Clicking that dot would pop-up the full control. Anything to save space!
> And the opposite, ie: a msg-box in text-mode 40*25 APP would show up
> as a post-stamp at the top left corner of a 3200*2400 screen without
> converting all size and position information (the OS cant do this on
> its own, because it dont know about the original resolution).
>
> Ok if you mean only message-boxes, pulldown-menus and a few simple
> button-styles to adapt here,
> ...but there are many other graphic elements used in my OS which I
> could never transform into text-based equivalents without creating
> totally new functions to achieve the same results.
Agreed. It would not work at all for graphical elements but I wasn't
thinking of replacing a GUI, merely of 1) supporting certain apps and 2)
providing a UI while an OS is still in text mode.
James
news:l0k82h$mir$1...@newsreader2.utanet.at...
...
>> I am thinking that the app would specify the GUI/TUI in such a way that
>> it could be rendered appropriately. For example, it would not dictate the
>> layout in most cases (though it could provide hints as to desirable
>> layout) but would focus on the elements it needs. It would separate the
>> layout from the semantics of the window elements and how they needed to
>> be grouped together. The renderer would convert that to a specific layout
>> depending on the mode (text/graphical), resolution of the underlying
>> canvas and hints provided by the application.
>
> I see no problem with displaying text-based apps in graphic-mode.
> But I can't imagine how to convert clickable Icons and bitmaps (like
> mouse-moveable scales/bars) into text-fields without loosing precision.
more of defining the essential elements of a user interface and specifying
them in a way that could be rendered as text or graphics. Icons and bitmaps
could not be rendered but scroll bars could.
As mentioned, I'm not proposing a complete solution. These were just some
ideas and are not something I am working on. However, to try to illustrate
what I had in mind perhaps a UI could be defined in the following terms.
Title: usually a bar at the top
Menu: bar and/or pop-up
Status: usually a bar
Clickables: buttons and links
Text entry: boxes, areas
Drop-downs: list selection and combo boxes
Check boxes and radio buttons
Grid
Sliders including scroll bars
Spinners
All of these could appear in either text or graphics mode.
...
>> Am posting here because ISTM it would also be helpful for OS development.
>> A windowing system could be developed in text mode and later used as a
>> GUI without having to rewrite the code.
>
> Yes, in this direction it would work.
>> Maybe someone has already defined a common GUI/TUI API but I haven't
>> found one.
>
> As mentioned above, my only G/T-'API' is the formatted text output incl.
> vertical lists, where all additional graphic-elements (borders, circels,
> bitmaps,...) were just ignored in text mode.
would need to be some way to distinguish one window from another. For that
case a border might be useful and there are characters that can be rendered
as lines. Alternatively, or if space were really tight, each window could
have a different background colour.
>> Such a system would have to be defined in layers. There would be widgets
>> and layout controls at the top and, essentially, rectangles at the
>> bottom.
>> Some elements would be recursively placeable so that, for example, a
>> given rectangle could have other rectangles within it and thus effect
>> layouts that the programmer wants. Further, the programmer should be
>> able to hint at how essential a given layout is so that the elements
>> could be best shown on a screen which is not big enough for the ideal
>> layout. Perhaps a user could even be allowed to move elements within a
>> window rather than just moving windows.
>
> Methink that an APP which can run in both modes should contain layouts
> for all supported modes anyway. Apps usually set their desired mode.
> I daubt that an API can be made that smart to cover all opportunities.
> Your suggestion for predefined layouts and elements reminds on windoze :)
hints along the lines of: if there is enough space then lay elements out in
this way.
You'll see I omitted text output aka label boxes from the list above. That's
because they often need to relate to some other control and would need to be
specified along with the control to which they relate. That would allow two
things. First, even though the screen layout can be altered by the rendering
process (to fit the screen) defining them together would allow the renderer
to keep them together. The label might have to be moved from beside the
control to above the control but it could still be kept with the element to
which it relates.
Second, some elements can be selected by Alt+key where the key is underlined
in the label. Defining the label with the control would allow the TUI or GUI
to know which control to select when that alt key combination is pressed.
>> Bottom line: if there was a GUI/TUI "language" then elements of a user
>> interface could be defined and used whether the program or OS was running
>> in a graphical or a textual environment.
>
> Sure, but when I think about an APP written for 1920*1080,32-bit,
> then I can't see how a full-screen input-field matrix could be displayed
> on a 80*25 mode_3 screen.
allow UI elements to be specified in a way that could be rendered on both.
In other words, one would start from the definition of the essential
elements and work from there to the display mechanism. On a large screen all
the elements might be visible at once. On a small text screen the user might
have to scroll up and down to get to all of the elements. For the TUI the
elements themselves would be more chunky and not so good to look at but they
would operate as normal.
The user could even be allowed to rearrange the UI elements within the TUI
or to change some of them from visible to ones which would pop up on
request. For example, a combo box could be just a single dot on the screen.
Clicking that dot would pop-up the full control. Anything to save space!
> And the opposite, ie: a msg-box in text-mode 40*25 APP would show up
> as a post-stamp at the top left corner of a 3200*2400 screen without
> converting all size and position information (the OS cant do this on
> its own, because it dont know about the original resolution).
>
> Ok if you mean only message-boxes, pulldown-menus and a few simple
> button-styles to adapt here,
> ...but there are many other graphic elements used in my OS which I
> could never transform into text-based equivalents without creating
> totally new functions to achieve the same results.
thinking of replacing a GUI, merely of 1) supporting certain apps and 2)
providing a UI while an OS is still in text mode.
James
James Harris
Sep 10, 2013, 3:54:54 AM9/10/13
to
<s_dub...@yahoo.com> wrote in message
news:693b761c-986b-41f7...@googlegroups.com...
...
> I get the sense that you are groping for a display control language..
>
> > The idea is for a program to provide a user interface with the
> > normally-expected elements in such a way that it will work in either
> > text or
> > graphics mode. For any program the text mode would be useful when no GUI
> > was
> > possible such as when using a terminal session to another machine. It
> > would
> > also be useful in the early days of an OS development. And it would
> > allow a
> > GUI to be rendered automatically on screens of different sizes.
>
> ..and the example of such a thing for GUI on different sized displays is
> html.
Good point. I don't know if HTML itself is ideal for this purpose but there
are certainly common principles such as:
1. allow the UI elements to be specified
2. have a program render them
3. have the UI allow scrolling to reach any which will not fit on screen
...
In a sense, yes. It might not "control" a display as such but I see it as a
way of specifying UI elements. The idea is that an app should be able to use
those elements to interact with the user without caring whether the user
sees them on a GUI or a TUI. Then a new OS would have a quick way to get
full-screen user interaction working.
BTW, I see your message had a blank line between each line of text. Google's
annoying new interface, perhaps. If it helps, I wrote an autohotkey macro to
delete such lines as follows.
#noenv
#warn
sendmode input
F12::
send {end}+{home}{del}{del}{down}
return
It simply binds F12 to the key sequence End Shift+Home Del Del Down. That
sequence is not perfect but it does help delete alternate lines and so tidy
up similar pieces of text. The hotkey can be changed and so can the key
sequence if you think of a better one.
James
news:693b761c-986b-41f7...@googlegroups.com...
...
> I get the sense that you are groping for a display control language..
>
> > The idea is for a program to provide a user interface with the
> > normally-expected elements in such a way that it will work in either
> > text or
> > graphics mode. For any program the text mode would be useful when no GUI
> > was
> > possible such as when using a terminal session to another machine. It
> > would
> > also be useful in the early days of an OS development. And it would
> > allow a
> > GUI to be rendered automatically on screens of different sizes.
>
> ..and the example of such a thing for GUI on different sized displays is
> html.
are certainly common principles such as:
1. allow the UI elements to be specified
2. have a program render them
3. have the UI allow scrolling to reach any which will not fit on screen
...
way of specifying UI elements. The idea is that an app should be able to use
those elements to interact with the user without caring whether the user
sees them on a GUI or a TUI. Then a new OS would have a quick way to get
full-screen user interaction working.
BTW, I see your message had a blank line between each line of text. Google's
annoying new interface, perhaps. If it helps, I wrote an autohotkey macro to
delete such lines as follows.
#noenv
#warn
sendmode input
F12::
send {end}+{home}{del}{del}{down}
return
It simply binds F12 to the key sequence End Shift+Home Del Del Down. That
sequence is not perfect but it does help delete alternate lines and so tidy
up similar pieces of text. The hotkey can be changed and so can the key
sequence if you think of a better one.
James
wolfgang kern
Sep 10, 2013, 12:26:55 PM9/10/13
to
Steve replied to James:
...
> more space - well cropping of windows is possible but, yes GUI some few
> pixels versus TUI of 8x8 or 9x16 pixels, so in that sense TUI is a subset
> of GUI.
Yeah, but why should we free-lance coders adopt windoze or loonix shit ?
> pixels versus TUI of 8x8 or 9x16 pixels, so in that sense TUI is a subset
> of GUI.
...
>> GUI to be rendered automatically on screens of different sizes.
>..and the example of such a thing for GUI on different sized displays is
> html.
I fully agree on that one (even Html is not very printer friendly).
>..and the example of such a thing for GUI on different sized displays is
> html.
...
>> Maybe someone has already defined a common GUI/TUI API but I haven't
>> found one.
>Not that I know of. There is a body of functions for TUI. There are
> >display control languages and their interpreters for GUI. There are
>display >control languages written using text environments for printer
>printing.
>(TEX).
<q>
The paradigm of text and graphics are different in certain respects; text is
fixed width, 8x8, 9x16, whereas graphics text is proportional. So what ends
up is a text emulation in graphics. I'm thinking of a dos windowing
application rendered in a dos box on XP, changing the window size changes
the fixed width font, and text based window elements/controls, in a scaled
fashion. But this all drifts away from what you had in mind.
</q>
fixed width, 8x8, 9x16, whereas graphics text is proportional. So what ends
up is a text emulation in graphics. I'm thinking of a dos windowing
application rendered in a dos box on XP, changing the window size changes
the fixed width font, and text based window elements/controls, in a scaled
fashion. But this all drifts away from what you had in mind.
Yes right, it may work well only in one direction (show text in graphics).
But the opposite wont even be able to display the quest in a user readable
view.
...
<q>
If you wrote a html renderer/interpreter for Text, you would be partway
there. If you added in PHP for text, then you would have most of it, but
that means instituting a PHP like server, if only a local one. That is a
rather steep development curve, for what benefit - to do it is at least a
learning exercise.
-But, am I correct to see you coming around to some 'display control
language' in your thoughts?
</q>
there. If you added in PHP for text, then you would have most of it, but
that means instituting a PHP like server, if only a local one. That is a
rather steep development curve, for what benefit - to do it is at least a
learning exercise.
-But, am I correct to see you coming around to some 'display control
language' in your thoughts?
I'm fully with you Steve here, a screen-display-language could almost
work like PCL_6 from HP (even I'd miss many Input-field-options then :).
__
wolfgang
wolfgang kern
Sep 10, 2013, 1:07:13 PM9/10/13
to
James Harris replied:
is just found in the mouse rectangles or in the defined hotkey-set.
In oppostion to well-known GP_OS behaviour, my OS can have two active open
menu-plates (dont call them 'windows') at the same time.
They can direct communicate with each other and often drive a third box
to show resulting info...
...
>> Methink that an APP which can run in both modes should contain layouts
>> for all supported modes anyway. Apps usually set their desired mode.
>> I daubt that an API can be made that smart to cover all opportunities.
>> Your suggestion for predefined layouts and elements reminds on windoze :)
> I was really suggesting that the layouts not be predefined but to allow
> for > hints along the lines of: if there is enough space then lay elements
> out in > this way.
I haven't seen this working so far. Any small GUI-designed menuplate wont
>> for all supported modes anyway. Apps usually set their desired mode.
>> I daubt that an API can be made that smart to cover all opportunities.
>> Your suggestion for predefined layouts and elements reminds on windoze :)
> I was really suggesting that the layouts not be predefined but to allow
> for > hints along the lines of: if there is enough space then lay elements
> out in > this way.
even rare fit into a text-screen without reducing understandability.
recogonise apart dots within a character on a text-screen ?
>> And the opposite, ie: a msg-box in text-mode 40*25 APP would show up
>> as a post-stamp at the top left corner of a 3200*2400 screen without
>> converting all size and position information (the OS cant do this on
>> its own, because it dont know about the original resolution).
>>
>> Ok if you mean only message-boxes, pulldown-menus and a few simple
>> button-styles to adapt here,
>> ...but there are many other graphic elements used in my OS which I
>> could never transform into text-based equivalents without creating
>> totally new functions to achieve the same results.
> Agreed. It would not work at all for graphical elements but I wasn't
> thinking of replacing a GUI, merely of 1) supporting certain apps and 2)
> providing a UI while an OS is still in text mode.
may be helpful during code development and early OS-design steps.
__
wolfgang
James Harris
Sep 11, 2013, 5:29:53 AM9/11/13
to
"wolfgang kern" <now...@never.at> wrote in message
news:l0nnvk$nt7$2...@newsreader2.utanet.at...
...
> My way to distingues between instances (I liberate avoid the word 'window'
> is just found in the mouse rectangles or in the defined hotkey-set.
> In oppostion to well-known GP_OS behaviour, my OS can have two active open
> menu-plates (dont call them 'windows') at the same time.
> They can direct communicate with each other and often drive a third box
> to show resulting info...
web?
...
>> The user could even be allowed to rearrange the UI elements within the
>> TUI or to change some of them from visible to ones which would pop up on
>> request. For example, a combo box could be just a single dot on the
>> screen. Clicking that dot would pop-up the full control. Anything to save
>> space!
>
> I see, you would reduce some opportunities... But how would you
> recogonise apart dots within a character on a text-screen ?
character position containing just a dot. I suppose any character could be
used instead of a dot. It might be a good idea to have a letter denoting the
meaning of the combo box underneath. For example, if there were three such
combo boxes for, say, Application, Presentation and Session the text-mode
screen could show - in the case where space was extremely tight - just those
three initial letters as in
A P S
A mouse click on, say, P would bring up the Presentation combo box as a pop
up. Hovering over the P could cause the status bar to display the current
combo box selection. Thus, even though harder to work with, the user would
have access to the controls of the full GUI but in a much smaller space and
the program wouldn't have to know whether it was running in a big-screen GUI
or a small TUI. At least, that's the idea.
James
James Harris
Sep 11, 2013, 12:30:10 PM9/11/13
to
"James Harris" <james.h...@gmail.com> wrote in message
news:l07hnu$vq9$1...@dont-email.me...
...
> Bottom line: if there was a GUI/TUI "language" then elements of a user
> interface could be defined and used whether the program or OS was running
> in a graphical or a textual environment.
As a followup, here are some examples of TUI appearance - mainly that others
have told me about.
http://www.sigala.it/sergio/tvision/images.html
http://www.npcole.com/npyscreen/
http://excess.org/urwid/examples.html
http://www.hexedit.com/hex-edit-shots.htm
I don't intend to implement anything just now but the appearances give an
idea of what can be done in text mode. The Turbovision screenshots look
surprisingly good.
James
news:l07hnu$vq9$1...@dont-email.me...
...
> Bottom line: if there was a GUI/TUI "language" then elements of a user
> interface could be defined and used whether the program or OS was running
> in a graphical or a textual environment.
have told me about.
http://www.sigala.it/sergio/tvision/images.html
http://www.npcole.com/npyscreen/
http://excess.org/urwid/examples.html
http://www.hexedit.com/hex-edit-shots.htm
I don't intend to implement anything just now but the appearances give an
idea of what can be done in text mode. The Turbovision screenshots look
surprisingly good.
James
s_dub...@yahoo.com
Sep 12, 2013, 4:20:43 AM9/12/13
to
On Tuesday, September 10, 2013 11:26:55 AM UTC-5, wolfgang kern wrote:
> Steve replied to James:
...
> > Similar elements -
> > http://www.mixsoftware.com/product/window.htm
> > more space - well cropping of windows is possible but, yes GUI some few
>
> > pixels versus TUI of 8x8 or 9x16 pixels, so in that sense TUI is a subset
>
> > of GUI.
>
> Yeah, but why should we free-lance coders adopt windoze or loonix shit ?
>
I'm with you, the point is to explore new ground, not copy what has been done.
> Steve replied to James:
...
> > Similar elements -
> > http://www.mixsoftware.com/product/window.htm
> > more space - well cropping of windows is possible but, yes GUI some few
>
> > pixels versus TUI of 8x8 or 9x16 pixels, so in that sense TUI is a subset
>
> > of GUI.
>
> Yeah, but why should we free-lance coders adopt windoze or loonix shit ?
>
> ...
>
> >> GUI to be rendered automatically on screens of different sizes.
>
> >..and the example of such a thing for GUI on different sized displays is
> > html.
>
> I fully agree on that one (even Html is not very printer friendly).
> ...
>
> >> Maybe someone has already defined a common GUI/TUI API but I haven't
> >> found one.
>
> >Not that I know of. There is a body of functions for TUI. There are
> >display control languages and their interpreters for GUI. There are
> >display control languages written using text environments for printer
> >printing.
> >(TEX).
>
> And there are several language options with HP_PCL_3..6 for printers.
>
> <q>
>
> The paradigm of text and graphics are different in certain respects; text is
> fixed width, 8x8, 9x16, whereas graphics text is proportional. So what ends
> up is a text emulation in graphics. I'm thinking of a dos windowing
> application rendered in a dos box on XP, changing the window size changes
> the fixed width font, and text based window elements/controls, in a scaled
> fashion. But this all drifts away from what you had in mind.
>
> </q>
>
> Yes right, it may work well only in one direction (show text in graphics).
> But the opposite wont even be able to display the quest in a user readable
> view.
>
Steve
> __
>
> wolfgang
s_dub...@yahoo.com
Sep 12, 2013, 4:37:39 AM9/12/13
to
On Tuesday, September 10, 2013 2:54:54 AM UTC-5, James Harris wrote:
> <s_dub...@yahoo.com> wrote in message
>
> news:693b761c-986b-41f7...@googlegroups.com...
> ...
>
> > I get the sense that you are groping for a display control language..
> > > The idea is for a program to provide a user interface with the
> > > normally-expected elements in such a way that it will work in either
> > > text or
> > > graphics mode. For any program the text mode would be useful when no GUI
> > > was
> > > possible such as when using a terminal session to another machine. It
> > > would
> > > also be useful in the early days of an OS development. And it would
> > > allow a
> > > GUI to be rendered automatically on screens of different sizes.
> >
> > ..and the example of such a thing for GUI on different sized displays is
> > html.
>
> Good point. I don't know if HTML itself is ideal for this purpose but there
> are certainly common principles such as:
> 1. allow the UI elements to be specified
> 2. have a program render them
> 3. have the UI allow scrolling to reach any which will not fit on screen
>
It isn't ideal, and the addon PHP isn't ideal for user inputs, both are examples of using command tags to control the renderer/interpreter (allowing the UI elements to be specified).
> <s_dub...@yahoo.com> wrote in message
>
> news:693b761c-986b-41f7...@googlegroups.com...
> ...
>
> > I get the sense that you are groping for a display control language..
> > > The idea is for a program to provide a user interface with the
> > > normally-expected elements in such a way that it will work in either
> > > text or
> > > graphics mode. For any program the text mode would be useful when no GUI
> > > was
> > > possible such as when using a terminal session to another machine. It
> > > would
> > > also be useful in the early days of an OS development. And it would
> > > allow a
> > > GUI to be rendered automatically on screens of different sizes.
> >
> > ..and the example of such a thing for GUI on different sized displays is
> > html.
>
> Good point. I don't know if HTML itself is ideal for this purpose but there
> are certainly common principles such as:
> 1. allow the UI elements to be specified
> 2. have a program render them
> 3. have the UI allow scrolling to reach any which will not fit on screen
>
This crummy google edit box is an (bad) example.
Steve
> ...
>
>
> James
wolfgang kern
Sep 12, 2013, 3:49:01 AM9/12/13
to
James Harris wrote:
> ...
>> My way to distingues between instances (I liberate avoid the word
>> 'window'
>> is just found in the mouse rectangles or in the defined hotkey-set.
>> In oppostion to well-known GP_OS behaviour, my OS can have two active
>> open
>> menu-plates (dont call them 'windows') at the same time.
>> They can direct communicate with each other and often drive a third box
>> to show resulting info...
> Are there any screen shots of this in operation - perhaps somewhere on the
> web?
It might not be much work to copy screen-contents to a file and convert
this into a windoze-bmp, my PRTSC-key got no function yet anyway ;)
My 'menu-plates' look a bit like the ones you posted a link to
(hex-edit-shots.htm), with 3D-border-rectangles for plates, buttons,
graphs and input fields, it also uses color-highlight, but of course
it's not windoze-styled.
A guess of how my things look like (without 3D-borders) can be found
on my homepage where I once put a short disassembler-demo for windoze
created with RosAsm&KESYS:
http://web.utanet.at/schw1285/KESYS/HEXTUTOR.zip
>>> ... Clicking that dot would pop-up the full control. Anything to save
>>> space!
>> I see, you would reduce some opportunities... But how would you
>> recogonise apart dots within a character on a text-screen ?
> Sorry, I didn't mean dots within a character. I was thinking of a single
> character position containing just a dot. I suppose any character could be
> used instead of a dot. It might be a good idea to have a letter denoting
> the meaning of the combo box underneath. For example, if there were three
> such combo boxes for, say, Application, Presentation and Session the
> text-mode screen could show - in the case where space was extremely
> tight - just those three initial letters as in
>
> A P S
>
> A mouse click on, say, P would bring up the Presentation combo box as a
> pop > up. Hovering over the P could cause the status bar to display the
> current combo box selection. Thus, even though harder to work with, the
> user would have access to the controls of the full GUI but in a much
> smaller space and the program wouldn't have to know whether it was running
> in a big-screen GUI or a small TUI. At least, that's the idea.
Ok, I see.
>> I see, you would reduce some opportunities... But how would you
>> recogonise apart dots within a character on a text-screen ?
> Sorry, I didn't mean dots within a character. I was thinking of a single
> character position containing just a dot. I suppose any character could be
> used instead of a dot. It might be a good idea to have a letter denoting
> the meaning of the combo box underneath. For example, if there were three
> such combo boxes for, say, Application, Presentation and Session the
> text-mode screen could show - in the case where space was extremely
> tight - just those three initial letters as in
>
> A P S
>
> A mouse click on, say, P would bring up the Presentation combo box as a
> pop > up. Hovering over the P could cause the status bar to display the
> current combo box selection. Thus, even though harder to work with, the
> user would have access to the controls of the full GUI but in a much
> smaller space and the program wouldn't have to know whether it was running
> in a big-screen GUI or a small TUI. At least, that's the idea.
__
wolfgang
s_dub...@yahoo.com
Sep 12, 2013, 5:10:28 AM9/12/13
to
Steve
wolfgang kern
Sep 12, 2013, 4:47:55 AM9/12/13
to
Steve asked:
[...spipped the agreed]
> When you developed your OS did you skip text mode and do graphics mode
> from the start?
'PC' with a color-TV monitor and a 3M-tape drive (1983).
No for my very first tools which were just DOS applications.
I had to use DEBUG.COM and later DEBUG.EXE to create my own tools which
were of course only text-based, but soon took the CGA-EGA-..VGA-path.
__
wolfgang
Rod Pemberton
Sep 12, 2013, 7:13:07 AM9/12/13
to
I only see a GUI in the images... (?)
What no link to a TUI used in an x86 BIOS?
What no link to the Linux text install?
What no link to a curses TUI (ncurses, PDcurses, etc)?
What no link to Rogue, Umoria, Lynx, etc.?
:-)
Other examples of TUI appearance:
http://www.tuxarena.com/2011/06/15-great-tools-for-the-terminal/
The first TVision image has multiple overlapped windows.
I only had one save buffer for my DOS program which had
drop down text menus. Multiple overlaps like that, if
implemented, would've overwritten a prior save, i.e.,
some menu or window text wouldn't be able to be restored
after being covered.
I can only assume the contents of each menu and window in
TVision is saved independently of the visible screen area
and then combined for display based on visible window layer.
I see these elements in the TVision images:
menu bar
drop down menus
keys to select menu item
independent text windows
window shadowing
scroll bars
minimize window box (?)
close window box (?)
option select box (square, round)
progress bars
I also see other stuff when I search for curses.
text scroll box (Yast, ncurses)
http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/ch02s10.html
level meters/bars
http://www.muylinux.com/2010/01/26/ncurses-la-interfaz-grafica-de-los-pobres/
text choice option boxes (or dialog)
http://valaurea.free.fr/images/ncurses.jpg
http://upload.wikimedia.org/wikipedia/commons/2/27/Linux-menuconfig.png
Rod Pemberton
--
Fences are great. I need a fence. You can use them to post signs:
"Blind people have the right to bear arms! Why wouldn't we?"
"Sorry officer, I can't call off the dogs. Those aren't MY dogs..."
"I believe in the cross. Cross-hairs on target... nailed to wood."
"Would you like to see a free-range, pitbull hunt? I would! Run."
"Laser dot. Scope. Win 308. C4 vertebra. Spoonfed for life."
James Harris
Sep 12, 2013, 1:26:26 PM9/12/13
to
"Rod Pemberton" <dont_us...@nohavenotit.com> wrote in message
news:op.w3apf5vn0e5s1z@-...
> On Wed, 11 Sep 2013 12:30:10 -0400, James Harris
> <james.h...@gmail.com> wrote:
>
>> "James Harris" <james.h...@gmail.com> wrote in message
>> news:l07hnu$vq9$1...@dont-email.me...
>> ...
>
>>> Bottom line: if there was a GUI/TUI "language" then elements of a user
>>> interface could be defined and used whether the program or OS was
>>> running in a graphical or a textual environment.
>>
>> As a followup, here are some examples of TUI appearance - mainly that
>> others have told me about.
>>
>> http://www.sigala.it/sergio/tvision/images.html
>> http://www.npcole.com/npyscreen/
>> http://excess.org/urwid/examples.html
>> http://www.hexedit.com/hex-edit-shots.htm
>>
>> I don't intend to implement anything just now but the appearances give an
>> idea of what can be done in text mode. The Turbovision screenshots look
>> surprisingly good.
>>
>
> Was the last link to hex-edit a test?
> I only see a GUI in the images... (?)
Ah, yes, you can take that as "an idea of what can be done in text mode"
> <james.h...@gmail.com> wrote:
>
>> "James Harris" <james.h...@gmail.com> wrote in message
>> news:l07hnu$vq9$1...@dont-email.me...
>> ...
>
>>> Bottom line: if there was a GUI/TUI "language" then elements of a user
>>> interface could be defined and used whether the program or OS was
>>> running in a graphical or a textual environment.
>>
>> As a followup, here are some examples of TUI appearance - mainly that
>> others have told me about.
>>
>> http://www.sigala.it/sergio/tvision/images.html
>> http://www.npcole.com/npyscreen/
>> http://excess.org/urwid/examples.html
>> http://www.hexedit.com/hex-edit-shots.htm
>>
>> I don't intend to implement anything just now but the appearances give an
>> idea of what can be done in text mode. The Turbovision screenshots look
>> surprisingly good.
>>
>
> Was the last link to hex-edit a test?
> I only see a GUI in the images... (?)
rather than a TUI as it is principally a textual interface.
James
Jean-Marc L.
Sep 17, 2013, 2:38:29 AM9/17/13
to
James Harris wrote:
...
http://en.wikipedia.org/wiki/Newt_(programming_library)
http://gnewt.sourceforge.net/index_en.html
http://gnewt.sourceforge.net/screen_en.html
Newt was the TUI for the Redhat Linux install system.
Newt software doesn't need to be recompiled, you just need to force the
preload of gNewt to have a GUI.
Newt is very minimal, there is only a few Widgets.
...
> Maybe someone has already defined a common GUI/TUI API but I haven't found
> one.
Several years ago I ported Redhat's Newt to GTK+.
> one.
http://en.wikipedia.org/wiki/Newt_(programming_library)
http://gnewt.sourceforge.net/index_en.html
http://gnewt.sourceforge.net/screen_en.html
Newt was the TUI for the Redhat Linux install system.
Newt software doesn't need to be recompiled, you just need to force the
preload of gNewt to have a GUI.
Newt is very minimal, there is only a few Widgets.
0 new messages