Slashdot Mirror
Developing Attractive non-GUI Apps for Unix?
Lysol asks: "Many years ago I wrote a POS (Point of Sale System) in a language (that's amazingly still around) called PowerBasic. One thing I really liked about it was the ability to do inline assembly and compile to machine code, which was a very big deal for DOS-based Basic code. For my POS app I used many text graphic libraries that gave me a poor-mans GUI for DOS. Now I'm going back to school and I need to brush up on my C, and that got me thinking about developing it in Linux. When I deployed this system it ran on old 386 machines. A lot of newer systems run on expensive hardware and it would be cool to provide a free GPL POS on Linux that can function as aterminal/text based solution. If you've ever used a cash register, sometimes GUI stuff with a mouse is not the best...especially for end users." One only has to look at FreshMeat to find examples of text UI libraries (and I'm sure that list isn't a complete one), but which ones have you used that you found enjoyable to develop in? How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
"I first want to deploy it using a terminal interface instead of a GUI interface for the simple reason that there will be times when it's better to run thin machines without installing X11, and it might be easier to implement rather than jumping right into GTK or some X11 widget toolkit. So does anyone know of any character based UI libraries that are available for C?"
Although you may have a valid point here, the poster said he wants to brush up on his C skills. I'm assuming he needs the C knowledge for the school he will be attending. Although these languages share some similarities with C, they are not C and will not help the poster accomplish what he intended to do.
Simplicity. Both in devlopment and use.
Colour is in EXTENDED XSI Curses and is supported by many curses implementations, including ncurses. BASE XSI Curses provides windowing and widgeting behaviour. forms and panels, ncurses extensions, from handy high-level functions for pretty much what they sound like: forms provides forms (so you don't have to keep all those widgets straight); panels provides overlapping windows (basic curses windows are I guess not "windows" in the classical sense, so you would want to use panels).
I someone telling us what we need...
But seriously, we need a multiple-mode interface description system where we can design the interface in a standard format then utilize it from text-mode, graphical and possibly web-based interfaces.
I'm planning on working on some partial implementation of something like this at work, but I could use some suggestions.
Should such a thing use XML as the layout format? Seems like the current trendy thing to use.
With the web-based interface, are we stuck with Java for validating input? Normal forms seem too clunky for things like that.
Is the project too big in scope to reasonably accomplish? There are things you can do in text-mode that you just can't do from a browser (like assigning meaning to a single keystroke). Likewise, mouse clicks lose their charm when there is no mouse attached.
Any input would be helpful. - TH
As far as I know, it only makes sense to do that with terms- but I enjoyed it so much I thought it'd make a pretty nifty GUI. The term-only GUI :D
http://www.vex.net/parnassus/apyllo.py/808292924.
Yes, I know, you're a C programmer... but (a) this might be useful to someone, and (b) you should really consider using python, at least for your prototype -- it's much, much faster to develop with.
Hell no: the DNA Lounge is a No Microsoft Zone, and will stay that way. Because the Linux POS market is so barren, we ended up going with plain-old cash registers, no network, no OS to speak of: just buttons and LEDs. Perhaps we'll upgrade someday when something better comes along that isn't prohibitively expensive.
Exam:
Question 1:
On Water Paradox's homepage at http://www.trios.org he seems to take a strong dislikening at the Scientologists for trying to force their views upon other with legal matters, while he himself tries to force his views on other with retorics and mythology. Is any way better or worse than the other? Why do you think Water Paradox makes a difference between Scientologists and their views, and Christianity and their views? Is one more dangerous than the other? Why or why not? Discuss.
is to write a program that is user-interface agnostic and then write user interfaces for it. I've been working on your proposal for almost three years now, and to a limited degree you can do it. But then you get into windowing issues, state issues, what do you do if they want graphics issues and wind up doing it server/client anyway.
Besides, on the gnucash mailing lists I see a effort towards this lately. A multiuser gnucash. But then tunneling from the other end of the mountain is EJB architecture. I'm not sure where they will (or even if they will) ever meet but they are working on the same problem. (As an aside, for now at work I am forced to using Microsoft Exchange, queryable folders, web components, digital dashboards, etc in this fashion but I'd rather use Java ejb architecture. *Much* more flexible and intuitive and solid. We're strected out like plasticman-on-twister running to make it through all the hoops in the way we have to make it through them.)
~^~~^~^^~~^
A bit off topic here, but I've been working with Ncurses for a while now, and I'm stuck. Ncurses is my favorite text-mode programming library, however, there sometimes comes a need to output an ANSI file to the screen and actually have it come out usable. However no matter how I try, I cannot get it to work. Either it comes out in pico-like escape codes, or otherwise completely unusable.
Anyone know of any way to get ANSI-escape-coded files and Ncurses to cooperate?
Improvise, adapt, and overcome.
Just write the thing in Elisp. We already have mailreaders, mp3 players, Intercal development environments, and a web browser -- just glue the appropriate parts together and move on with life! Plus, if your users get too frustrated, just set some keybinds to locate `doctor' when they hit F1:
Dewey, what part of this looks like authorities should be involved?
Take your pick: GPL or BSD Licensed. :-)
The Doctor What (KF6VNC)
"Beware by whom you are called sane."
Potato chips are a by-yourself food.
Ncurses is really great.l
It's remarkably easy to use, lets you update
portions of the screen, gives you more direct
access to the keyboard, has been fixed to let
you use STL in your curses apps (hooray!)
There are a few tutorials out there... if you're just looking for a quick view of how ncurses looks, grab "nmix" (a simple ncurses based sound card mixer) from freshmeat... the source is nice and small and demonstrates how simple it is.
As for tutorials/books...
http://www.cscene.org/CS3/CS3-08.html
http://www.oreilly.com/catalog/curses/index.htm
http://dickey.his.com/ncurses/ncurses.faq.html
Those should help set you on your way.
Now if only someone would make an AAlib Xserver.
I designed touch screen based system used to control industrial gauges. The single biggest annoyance with touch screens are the distance between the display LCD and the touch sensor. This creates an offset that is different for each height of person.
For example: A 6'5" person (myself) configures the screen and intializes the touch screen. Now a 5'1" user walks up to that same screen and must tap over top of my locations to hit the same spot. This requires the buttons (or atleast the hot spot detection) to be very tall.
All of the gauges would be much faster and easier to use (let alone programming and setup) with a keyboard only solution. But the industrial PC touch screen was "the in thing". What are you going to do when they want a 1/2 million dollar gauge. Yep, you give the customer what the customer wants.
...but add my voice to the chorus cheering for curses. It's free, it's incredibly easy to understand, and support for it is never going away.
The O'Reilly minibook Programming with curses (which I used to think was a "Unix-Hater's Handbook"-style thing) is a great place to start. Good luck.
spawn_of_yog_sothoth
go grab a copy of turbo vision for unix. it's on freshmeat. it's a port of the old borland turbo vision text gui toolkit for dos.
it's in c++, not c, but it wouldn't be too difficult to make a c binding. or just use c++.
whatever you do, don't use curses. it sucks rocks. unless, of course, your app only needs text entry widgets and buttons.
if you must use curses, at least use cdk (curses development kit) which makes the life of the curses programmer much easier. the maintainer was very responsive to the issues i encountered when using it.
---
Like hell offtopic... thats a good suggestion...
A related question would be to consider lynx, and just code your app up as all cgi based with a central apache server.
Lynx gives you the "gui", and you can support both text and graphical terminals, you have the ultimate in portability, and you client server architecture is completely a done deal for you.
Totally flexible, totally portable, totally scalable.
Bill
Mathematically impossible requirements are technically not against policy.
It's just not about text tho, it's about how the modern GUI - which we pretty much equate with a workstation - sometimes isn't always practical.
I say this mostly out of experience with the last system I built. Think if you worked at a snack bar at a baseball game. It;s not very feasible to be using a mouse and clicking on a bunch of buttons to enter and print stuff out. This is where, in my opinion, TUI or touch screen is king.
It's the same principle behind the argument that console people use when they might face off with Mac or Windows people. How in a lot of situations, keystrokes are faster than mouse and menus.
And another thing to consider is X configuration issues and possible assocatiated hardware and troubleshooting costs. If you can get a Linux login prompt up, then the system should work. No acceleration, no fancy buttons and widgets and no need for a mouse.
I disagree. I've never developed a POS, but I've given it some thought and watched users of POS systems closely (not serious research, though). It seems that what they would want the most is an easy-to-use interface that has intelligently laid-out hot-keys to make it easier to fly through screens/windows.
There are many POS systems using a touch screen for input. I think the problem with that is that it requires special hardware - where a keyboard input device could work on any old P.O.S. (that's a pun) system.
Last I looked at it, Newt documentation was nonexistent. Documentation is a seldom appreciated feature, and it's hard to gauge a library's capability -- let alone use it -- without decent documentation. Also, it lacked a grid/table widget that I needed.
Try something like Xterminal if you are using C++, or CDK or Newt otherwise. These libraries are typically built on top of ncurses and/or Slang, sort of like how Qt/Gtk+ are built on X Windows.
You are oh-so-correct.
However, I'm betting that Ronald and the other clowns at McD's have spent a lot of time and energy calculating the cost-benefits of training their flunkies to type vs. "push the pretty picture".
Sadly, I think the evidence is that dumbed down wins. Their mascot isn't a clown for nothing.
Silly Rabbit, sigs are for kids.
And that the "user interface" is little pictures of food you touch to select?
The moral is that the dumber the interface, the better. Even using a mouse is a learned skill that cashiers might or might not have learned. And using the tab key to cycle between options? Forget it!
Pushing simple buttons is the only answer. If you can't work with a touch-screen, the old reliable Function Keys are your next best bet and seem very popular in POS systems. Of course, don't forget to paint them different colors, and have them custom-covered with key labels like "New Customer", "Visa", or whatever...
To all intents and purposes, you have to design a POS system as if the user had never SEEN a computer, let alone learned anything about them. Fortunately, text-based displays work well with push-button input systems, but before you worry about what your going to draw on the screen, figure out how the brain-addled user is going to tell the system what to do.
paul
Silly Rabbit, sigs are for kids.
note that he has abandonned his own system for now.
You sissies and your monitors...why don't you program like real men, using flashing LEDs to let you know what's going on.
Ahh, you too have no idea how coddled and pampered you really are. When I learned to code, LEDs weren't yet in widespread use, and all of the computers used HEDs (heat emitting diodes) for status displays. The only way to tell if a bit was set was to touch a HED and see if your fingers got burned. It was no fun at all coming off of an all-night hacking binge with my fingers covered in tiny pinpoint-sized burns from a particularly gruelling debugging session, only to go to work for twelve hours manufacturing watch springs in a dangerous sweatshop just so I could afford the computer time and a bit of coal to fuel young Timmy's iron lung.
I'm just glad I wasn't there the night that some fool decided to mess around with the system clock multiplier, causing all the HEDs to set fire to the console, burning down not only the data center but also two adjacent nursing homes and a Salvation Army warehouse used to store surplus 72oz cans of bean w/bacon soup.
Reservoir Zigs
I think another big bonus to curses is that it's most likely already going to work on any flavor of *nix or terminal type you encounter. There are certainly newer and fancier libs than curses, but if you need portability across OS and possibly terminals, it's hard to argue with curses.
> Qt Embedded runs off a floppy if you wish (thought about trying to get that running on a 486 I had).
You underestimate the power of your old computer. My 486 runs XFree86 and KDE in its entirety. Sure it's slow, but it works just fine.
But my grandest creation, as history will tell,
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
if only lynx had dhtml/javascript support ...
I remember GEOS. It also came out for the Apple II, IIRC. Here's one - remember the Tandy CoCo 2?
_______
Scott Jones
Newscast Director / ABC19 WKPT
FC Closer
More and more software doesn't compile on FreeBSD on Solaris because the developers didn't take care to write portable code. Especially for text-based applications, it's worthwhile to write portable code.
Having to move your hand between the keyboard and the mouse frequently is extremely inefficient.
--
Give a man a match, you keep him warm for an evening.
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
CDK is a curses "widget set" which is marginally useful. It's easy to throw a pretty application together with it, but for large scale apps it becomes a bit of a struggle. Any dynamic sizing or placement information is left up to the application and the API is such that changing widget attributes post-initialization is a challenge.
Regardless, it's logically structured and the code is simple to dig in and hack on. I think the official site is:
http://www.vexus.ca/CDK.html
It's not event driven, however, and as my app grew it made me long for a terminal version of GTK...
Do you mean Glade plus libglade with the Python bindings in gnome-python?
Glade, other than generating C source for the GTK+ GUI you design, saves the file describing the GUI in an XML format which can be read via libglade. Then, it's only a matter of linking it in and calling a function which reads the XML file and builds the widget tree. The task of registering your handlers for the various events (i.e. a certain button pressed) can also be performed automatically by libglade, i.e. by looking at the executable symbol table for languages like C, or using the introspection features of the interpreter in the case of Python.
Actually, the C=64 was a great box for creating any type of text based GUI. With the graphic characters on the keyboard you could do some pretty cool stuff.
--James
load "linux",8,1
You should probably take a look at http://www.viewtouch.com/, which is a linux based pos GUI menu system. Granted its GUI, but it might be a good start to work on implementing a text based front end for their stuff. I haven't looked at it enough to give you a much better review than that, but I'm laying odds it'd help you achieve your goals or at least provide a good starting point. The code is GPLed, last I checked, and you can download it to check it out.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Ah, none other than the Jamie Zawinski (of netscape/Mozilla/Lucid Emacs fame) has been working on this particular problem.
m l
Check out:
http://www.dnalounge.com/backstage/log/2001/02.ht
Where Jamie provides a pointer to:
http://www.linuxcanada.com/linuxpos.html
He also took a swipe at hacking up his own Linux based POS system:
http://www.dnalounge.com/backstage/src/pos/
- Any Day above Ground is a good Day (Michael Rich, 1997)
This a really well done Linux POS system that has been done here. It is really top notch...
...and I'm not sure we should trust this Kyle Sagan either.
Check it out here and a Screen Shot is here
code it in C using FCGI. that should take care of the problem of learning C. Also with a browser based interface using lynx for text and netscape for graphics will handle the reusability issue.
FCGI is basically using C as a CGI scripting language library with additional C support libraries available for doing stuff which is hard in C (such as HTML output functions and text parsing and stuff). it simply replaces perl (and mod_perl) with C (and mod_fcgi). its open source and stuff. check out : http://www.fastcgi.com/docs/faq.html#c_cgi_libs
for all those here not old enough to remember the birth of the world wide web and scripting languages for generating dynamic html for web servers, perl was NOT the first scripting language or the fastest. C with FastCGI was the first and it blew away everything in terms of speed (near assembly performance over the web, bare metal -- yeah) but like C's in the usual case it was a bitch to develop dynamic web stuff when perl could do it easier (although slower). so everyone switched to perl and the rest is history (ignoring the flames that went on and ppl whining about perl being really slow).
of course now everyone is switching to java which is even slower but even easier to develop for so history will probably repeat itself again. we already have the java flaming well underway...
I find links renderes slightly pages more pretty than lynx too.
but I keep using lynx because it's classic like that.
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Your problems with curses are caused by working under Windows with no curses library installed, yes?
-- The act of censorship is always worse than whatever is being censored. Always.
Here are your requirements/what you got:
1. Text-based POS system
2. Written in PowerBasic
3. Want a free version under Linux
You say you want to redo it in C - are you sure? Do you have anything to gain by porting it? Perhaps speed - but does it need it? Maybe a re-write - but does it need it?
It doesn't sound like you will gain much, other than a learning experience. I would say if you are going to have to rewrite it, and you want to make it free, you might as well go all out, and do it in style:
Perl/PHP and Apache, with some MySQL or similar free DB on the backend (if needed). You could even provide a web interface if needed.
If not this, why not just leave it as BASIC code? Download a copy of XBasic, and compile - a little will have to be changed (if you use any inline assembler, that might need tweaking), but not as much as doing a complete rewrite in another language...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
TCL/TK combined with a touch-screen would be perfect for POS applications.
Has anybody seen a touch-screen work with Linux?
Widgets, Buttons, and Pop-Up windows in pretty colors can all be text-based. The UI doesn't need to be G.
Actually, I, personally, am dog slow with writing of any sort, and always have been. Typing is the only way I can keep up, which is why I bought palm pilot keyboard (one of the stowaway folding keyboards :)
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
And, some ever helpful links:Turbo Vision For Unix and Turbo Vision. Two different ports. Judging by their freshmeat entries, I'd go with the second one.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
For desktop applications, you're right, but for Point of Sale applications, it's a different ballpark. The user is going to be an employee who is trained in how to use the application. It should provide an interface that is simple and lets the user (cashier, usually) perform their job. Widgets, popups, etc are distracting, not helpful; there should be one simple way to do something and the interface should remain relatively stable and simple. POS apps are different from desktop apps.
It's been ported to UNIX. There's a version out there developed by someone that lets you write an application in TV and that will support Console and X11 (using QT). TV is what is used to build Borland's fine Turbo Debugger GUI, For all you TASM fans out there. I've been told Slang is a MUCH better alternative to curses though I've not coded in either. I havent done console programming in a loong time and want to keep it that way :-).
Peter
--
www.alphalinux.org
www.alphalinux.org
Along the same lines, I have been thinking for a while about a single simple API with multiple backends so you can write an app once and it will either target curses, gtk+, qt, win32 etc.
Obviously I'm talking about seriously simple GUIs here with nothing much more than a few input fields and some validation. No cross-widget realtime updating or drag & drop etc.
Maybe it wouldn't be much use to most ppl, but these are often the kind of simple apps I find myself writing. I think configuration tools would be a good example that could gain from this. (also, I have just thought, how about a HTML backend !?)
I guess my point is that people seem to be choosing ever growing widget sets and committing themselves to an API which is often way more complex than they need. If some ultra-simple, multi-targetted API was available people might run your app in future in ways you didn't possibly imagine.
Maybe I'll start designing it myself some time soon....
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
I would like a way to see all comments that have recieved positive moderation, regardless of their actual score.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
PicoGUI is a GUI for embedded systems I've been working on for a while. It's video library is pretty flexible, so much so that it can render to ncurses! This means that PicoGUI apps can run in text mode almost the same as they would run in a graphical mode. The advantages would be a capable GUI that's in active development, and an easy upgrade path to a graphical system. Oh, and it's client-server if that helps. PicoGUI has client libraries for C and Perl, and more languages will be coming.
Some disadvantages though... Currently the keyboard tabbing isn't fully functional, and mouse input probably isn't applicable here, so you might have to do some funky coding to move the focus from field to field, etc. Also, it's a relatively new GUI so it might be missing features here and there.
-- 2 + 2 = 5, for very large values of 2
"I first want to deploy it using a terminal interface instead of a GUI interface for the simple reason that there will be times when it's better to run thin machines without installing X11, and it might be easier to implement rather than jumping right into GTK or some X11 widget toolkit. So does anyone know of any character based UI libraries that are available for C?"
Have you looked at the ARACHNE Web Browser for Linux it requires svgalib on a 486 with 8MB of RAM, but allows you to design your whole interface in standard HTML since its an HTML/4.0 specification compliant webbrowser. The Linux version is still in alpha/beta stage, but the DOS version can run in Linux using dosemu.
I wouldn't call it a Non-GUI platform, but it is a low resource X11-free platform.
Work for Change & GET PAID!
Turbovision is a very nice C++ (Also Pascal, but I'm not sure if that's been ported to Unix) library, originally written for DOS by Borland, but now ported to Unix. Borland was nice enough to release full source for it around 1995, when they pretty much dropped the DOS targetting for their compilers.
... glorious.
Turbovision was the first application framework I ever used, and I have really fond memories of it. It was a hard way to learn C++, though. TurboVision under Turbo C++ 3.0, senior year of highschool, the first time I ever wrote code for money. It was
http://freshmeat.net/projects/turbovisionforunix/
...depending on your system requirements, you might take a look at the Data Access product line, which includes character mode development environments for DOS and Linux/Unix (DataFlex), a GUI development environment for Windows (Visual Dataflex), and their WebApp Server for web based applications.
This is a high level "4GL" OOP development system, which we've been pretty happy with. Over the years we have moved from CPM (Data Access goes back a ways) and DOS character based "procedural" style programming to (briefly) the OOP character based system, and then to the OOP Windows development system we are using now.
If you must develop database type applications for multiple environments, a strength of DataFlex is the fact you can put business rules in the DataDictionary class definitions, and these will be enforced regardless of the underlying database (their proprietary DB, DB2, MS SQL, or any ODBC accessible database) and the overlying (if that's a word) GUI (character, Windows, Web).
I can't comment on creating a single user interface description and having it applied to different interfaces, as you point out some things do not translate well from one interface to another. Especially when things get more complicated... at least in the DOS/Linux and Windows environments you do work with a similar set of classes (I was actually quite happy when I started using Visual Dataflex because so much of my knowledge of the classes and framework translated straight over).
The WebApp server, btw, is designed to run on NT/IIS. However I think the newest version which is now in open beta has been redesigned to run on Linux/Apache/Java)
This whole "Holy War" against the people here at Slashdot has got to stop sometime soon. What ever happened to the older days of about 2 years ago (random link I found no significance to anything) when things were cooler and calmer, there were no goatsex posts, no little morons running around babbling on like idiots. When someone posted worthy information worth reading.
All I see nowadays are immature idiots posting goatsex, spork, bs music information which wastes so much time, and money via way of bandwidth to process that bs. Get a life no one wants to hear about what problems you may have with Jon Katz, Timothy, Michael, Rob Malda, or whomever else posts an article here.
They work here you don't and thats the bottom line, don't like it then type in another URL in your browser, and that will solve the problem.
We all love a good joke here and there, but attacking someone based on unfounded bs is annoying and downright immature, and can be construed into slander, and libel a crime nevertheless.
Put yourself in the Slashdot staffing position. Provide a neat tech site where information isn't as watered down as it is on sites such as MSNBC, or CNN, along with the opportunity to interact with others who have enough knowledge and talent to run a government if talents were combined and applied. All that for free to the people who browse here.
Wouldn't it be nice to just focus on a subject, and get insights into the way people see things while adding positive input, or providing someone with an answer to their question, or even correcting someone about something they may have taken out of perspective? Its not even a matter of becoming something of a tightwad ass site like FreeRepublic or a pencil pouch wearing stereotypical geek site.
Slashdot used to be fun, still is when we sort through a 300 post thread only to find about 75 posts even relevant to the actual article. Its saddening to see this is going to become a joke if things don't change. This isn't someone's Geocities, Tripod, Xoom, "h3ll0-1'm-4-h4x0r" site, we all know its a hell of a lot better than most of the other sites out there. Yet many idiots seem to think that its some fscking loser site to voice their stupid fish, spork, goatsex, and other oddities. Grow up already do something positive for yourself such as reading an RFC or something insightful.
Shit even I joke many times, but I won't dwell on posting the same redundant shit over and over and over its sickening as hell. Posting something as anonymous is even more moronic. Who gives a shit about karma? Say what you have to say what you feel is relevant if you get moderated down, who cares, it didn't take away a drop of blood from your body, or a dollar in your pocket did it?
joq | deran9ed
Want Root?
Development time is no issue... it is quicker to design a GUI using a guibuilder than it is to code something in curses.
And even if there were a curses-based guibuilder, why would you want to use it?
Sure, there are certain tasks that are better suited to the keyboard and the command line, but the graphical interface is popular for a reason: when done properly it works, and it works well.
Why anyone would want to give up those advantages is completely beyond me.
-p.
I think the younger generation isn't as much a reference to calendar age, as how long one's been using a computer. Kids my age (16) who have been interested in computers for more than four or five years definitely used, if didn't grow up on DOS. Additionally, many elderly people have only been using computers for a very short time, and are hardly even accustomed to the GUIs of Windows and AOL..."command line" is a completely foreign concept to them.
Yes! That guy!
Actually most command line applications (or interfaces) are more capable than GUIs because they can be scripted. Capable is not the keyword for GUI. I prefer user-friendly. The only thing GUIs can do that you just can't do in a command line is graphics. Hence, WinCVS's cool branch graph that isnt in the commandline version.
Someone you trust is one of us.
I agree. My first C program was 'connect-4', done using ncurses. All it took was 'man ncurses' and its related manpages.
I wrote a text-based mp3player using ncurses, called mp3blaster. It is equally interactive as fancy mp3players with GUI's.
(N)curses also has window-like structures, with borders, colours, and everything else. It understands most terminals, although you might find the number of keys that you can use on each keyboard is restricted (e.g. a single 'alt' cannot easily be read by a curses program).
Bram
Forgive me for being ignorant, but doesn't curses simply provide means to write the terminal/screen and accept input? I believe his question regarding the TUI library includes drawing windows on the screen in color. I actually wrote a library in C for DOS (~5 years ago) that does this. It also, if I remember correctly, includes support for controls in the window, such as buttons, text input. Allows for layering of windows and changing the Z-order. Like I said, for DOS. It uses inline assembly interrupt calls to write to the screen. But it could be ported to curses. Reply if you're interested.
Hello little man. I will destroy you!
A CLI is the lowest common denominator for a user interface to a software package. A textual interface with few or no cursor control sequences guarantees accessibility, without any concerns about incompatibility, 8-bit clean transport path issues, or dependencies on functionality (such as certain X display calls) which may be omitted on certain client implementations, or which may be ambiguously defined in the specs and implemented differently on different clients.
For low-level configuration of a system, a CLI is mandatory. This is why Cisco and every successful router and switch company offers a command-line interface that gives access to all facets of device configuration.
With a CLI, I can control my system from anywhere, with the most minimal of interface hardware and software, and no nasty suprises.
I do not deploy Linux. Ever.
Better yet, if Power Basic becomes available for Linux, you can port the code to Linux of you still have it. It was rumored on the Powerbasic sites that they were devloping a version for Linux. Not exactly sure, but that would sure make life easier! :) I have a coworker who swore by Powerbasic. He evn was going to buy a HP LX100 and move a app he created in powerbasic to it. The app he created was his own, personal DOS based PIM. It was programmed to HIS specs. You see, this guy is an albino, and his eyes suck (sorry Jim! :)). Console mode is the best for him to see, becase it's the clearest. He runs 640x480 because it's what he can see. He can't see the higher resolutions. Outlook, Groupwise and any other PIM was too hard for him to read under windows. Only thing that might make his program better is if he had Palm support, but he'd never do that because he can't read palms either.
Gorkman
Think of how nice it would be for them to be able to update their apps to something more modern, running on a Linux server which is far more interoperable than a Netware server. Cuz yes, while they might want to cut costs with their computers, it might make sense to have the *server* networked with some central location and sharing information with them.
With this sort of situation in mind, they can keep their old terminals, and either boot with DOS, launch a TCP/IP stack and telnet application, and connect to the server, running console applications from there (remember dumb terminals?), or maybe, if the computers are fast enough (small 386's will do), do a diskless linux boot from the server and have a much neater and less archaic solution.
However, the question arises, if all is working well under the current Novell setup, why change? well, the answer is: it's getting harder to find someone who knows Novell, and easier to find someone who knows Linux. AND yes, after all those years, the Novell boxes are starting to crap out.
off the top of my head, i can think of two companies I know which could (or do) benefit from having a way to develop a modern app in text-mode. One of them is a freight company which has a centralized system on a DEC Alpha server and has all the branch offices connect via frame relay. Had they needed to upgrade the 386 terminals in the branch offices, it would have meant they couldnt afford to link all the offices together. And i can tell you those 386's WONT run any graphical environment but work in textmode just fine.
The other is a hardware shop with at least 4 locations, running Novell based setups and requiring constant attention because the Novell servers are crapping out, and Novell admins are scarce in that town. A Linux text-based solution would be interesting, because they can more easily find Linux people, plus, at least in my experience, Linux is more stable; i've had Linux servers working without flaws for so long, when they actually needed me to go down there, i'd forgotten how to get there :)
I'll stop ranting now. :)
The same thing works in NT 4 and is located in HKEY_CURRENT_USER\Software\Microsoft\Command Processor
It's an add-on for Tcl which uses almost the same syntax as the Tk toolkit, but renders using curses. If you're familiar with Tk and it's widgets, you'll be right at home with CK.
You can't get it, of course. It was never offered as a product, or else it would have had some other name.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Slightly OT, but while we're [sort of] on the topic, there is a Textmode Quake package available which provides an interesting idea for user interfaces.
I wonder whether this could be combined with the Doom Sysadmin Tool for a text->GUI->text->severe eyestrain session.
i think that 'links' might be a little better than lynx, insomuch as one can view frames, rather than having to guess at which frame you need, and then selecting it. just a thought. great idea using the web browser though. totally great idea...
i'm trying to see how my beliefs in Kali the Eternal Mother and Shiva the Destroyer fits in with your holy ghost. sorry, not seeing it.
While I agree that using a keyboard is faster and more intuitive for data entry than using a mouse, might it not be faster to write the application designed with the touch screen interface in mind. You get the best of both worlds with a GUI presentation, and keyboard speed?
AF-Design, web development.
There are tonnes of GUI based POS systems that don't require a mouse. Check out: Auto~Star and Breakpoint.
Both of these systems have a GUI interface that do NOT require a mouse.
PS Breakpoint systems does not have their current system on their website, their current system is gui based :)
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
OH!!! I all this time I thought people were calling me up trying to sell me a Piece Of Shit!
Ok my karma is maxed out. When do I become Enlightened?
And then there are those of us who started out wiring tabulating-machine plugboards. Getting an IBM Model 84 Collator and a 402 tabulator to write poetry was tough. So there.
2) By some reasons, seems like it's much easier to write bad GUI than to write bad text-based UI. But that doesn't mean any GUI is bad just because it's GUI.
3) I don't think it's harder to operate our programs in Win2000 than in Win95, especially in regards to command line.
4) Going with Linux is good choice, indeed. However, CLI is definitely not the factor that drives developers from Windows to Linux. I have the same bash under both Win2000 and Linux and use the same perl one-liners.
5) Bonus trick. How to enable command-line completion in standard Windows 2000 command-line window:
Start regedit, find the word "CompletionChar". By default it's not set. To set <TAB> as a completion character, set the CompletionChar value to 9. That's all!
Oh yes, the newest versions of this system were NT based, requiring 32 MB of RAM and a Pentium MMX processor and ~1GB of hard disk space. And the backoffice portion was FoxPro, multiuser if you map drive letters, as long as 2 people don't access the same file at once!
chris@xanadu:~$ whatis /.
/.: nothing appropriate.
You're right. Learning the querty keyboard layout, and the three-symbol code for each product would be infinitely faster than learning the register layout, and the one-symbol code for each product.
And, as a special bonus, they'd be able to put friendly, ergonomic 101-key keyboard on the counter, instead of that unisightly thing that looks like a cash register.
Not only that, but when they were running specials, everyone could be trained beforehand on the new three letter codes. If someone forgets, they could just call over the manager -- what would that take? Five minutes, max? It feels more efficient already. Just putting the new picture on the register would mean that learning the new register layout would take a good 10 or 15 seconds for anyone with a brain -- it's just to much work to imagine.
Slashdot is jumping the shark. I'm just driving the boat.
Actually C code can now be written in Perl using Inline::C module; it allows you to embed subroutines written in C inside your Perl code.
Improve Day Trading Skills with Peak Trader
Most of these languages provide nice wrappers around curses or even a full-fledged X interface.
Tired of losing real money in a bear market? Try Peak Trader.
Use the library that Dopewars(tm) was created with. At least your GUI will be addictive.
Moderators: This is an attempt at humor (albeit poor, i agree).
"My mother never saw the irony in calling me a son-of-a-bitch." - Jack Nicholson
How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
Quite easy actually. I've been doing a lot of ncurses programming lately. You can do some amazinly elaborate things with it if your a good programmer. A good technique really pays. If you start running into situations where you're brute-forcing it, I advise that you back off and do a little work on a good "framework" for your app(that's one minus about ncurses, there's very little "flamework").
Some key points about ncurses:
o It's very fast - Text mode applications are great for productivity. Their GUI counterparts always turn out to be slower for some reason. ...etc.
o Menus and Forms - The menu and form libraries are standard on UNIXes. You can fairly easily create fields for data entry that have built in validation routines
o Tables - Well, not exactly, but a clever way to make a very snappy table is to just use a menu. In text mode you can't tell the differnce. Ncurses menu-tables are more than what the Java 1.1 AWT library provides
o Well established - Curses programming has been around for a long time. The characteristics of many terminal types has been worked out(by ESR) and abstracted into the terminfo database. Its quite portable.
o Works Anywhere - You can run it over telnet, ssh, or just dump bulky X alltogether and run on the Linux console.
Here's some links:
Ncurses Intro by Eric S. Raymond and Zeyd M. Ben-Halim
Linux Journal Artical by ESR
Fujitsu ETI Programmers Guide
SCO ETI Programming
I really wish people would concentrate more ncurses programs. They're just damn efficient. Anyone who uses mutt and slrn and such knows what I'm talking about. If you're really clever, you'll librarify whatever it is that your working on so you can hook on a GUI version later after you've tweeked the behavior of the app without wasting a lot of clock-cycles on graphics programming.
I've used S-Lang considerably in the past on projects which needed a TUI. It was intuitive and had a very slight learning curve.
Check out http://www.s-lang.org/
The CLI (Command Line Interface)... aka, "text mode" is alive and well. In fact I maintain a text mode application for my job. There are still several markets that prefer to employ CLI vs GUI. In fact, any place where data needs to be entered quickly and effectively, GUI can't compete.
Unfortunately, Microsoft is making it harder and harder for us to operate our programs on the winX operating systems. Every new version of windows brings us more incompatibilities. I think it's a mistake in microsoft's "strategy" to phase out the console, because text mode programs still have a place in the computer software market!
Good choice going with Linux. When microsoft rubs out the CLI completely, they will lose an important industry segment.
Remember, just because a program doesn't have flashy graphics, doesn't mean it's old and hard to operate.
Skiers and Riders -- http://www.snowjournal.com
To add to this great comment:
I agree that GUI's make the younger generation happy (they never grew up in DOS), and if its speed of input you are worried about (what are the other disadvantages of GUI's?), then ensure that there is a way to run the GUI app without the need of a mouse (tabbing through the textboxes, stuff like that).
GUI's were created to make life easy for the computer illiterate, which is most of the business users this day and age. Eyecandy is what's in...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
What about programming it using gestures, like the miracles in Black & White, and other programs mentioned on /. a couple weeks ago. Its not GUI, doesn't need a desktop, but it does require use of a mouse...
If you could devise a standard, and if it could be taught quickly to the employees, it would make for a very very fast system (just how fast are you with your palm pilot writing? Same thing applies here). Plus, I'd like to see some code that uses this type of system...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Inhouse we use POS as an acronym for Piece Of Shit. E.g. POS driver, POS NIC etc. Now go read the article again... ;)
Now, if a better programmer than me could perhaps make an XML parser that could translate this into classes for an interpreted language like Python you would have all the advantages of Visual Basic without the disadvantages.
------
C'mon, flame me!
No sig for the moment.
I will certainly look it up!
------
C'mon, flame me!
No sig for the moment.
Just cuious, used to work for Babbages in a former life, and this system your talking about sounds alot like the POS system there, if it was congrats, it was an excellent system.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Rolling out retail systems on Linux, right? Home Depot is the largest with a planned 90,000 terminals by 2003. A good chunk of those will be POS, while others will be lookup stations. I assume that HD will be using text only interfaces for the POS systems, but I don't know. It would be interesting to know what their plans are. Is anyone from their development team participating in any GPL code development?
GEOS was great. It was a very clean GUI that needed very little memory to run, and it was a hell of an improvement over the C64 BASIC prompt. For those who are interested, GEOS has evolved into NewDeal.
The clash of honour calls, to stand when others fall.
If I have this much trouble typing in the first three letters of my last name and first two of my first name...I can just imagine how bad these things would be in Point of Sale applications.
Stick with a keyboard!
. . .
Don't you think that...
Developing Attractive non-GUI Apps for Linux
is better than...
Developing non-Attractive GUI Apps for Linux
I'll see your senator, and I'll raise you two judges.
That most people *like* GUI's for when they're using a program. While I probably would have little problem going to a text-based interface (I grew up with DOS, after all), but I'd imagine most people who would be using a POS system wouldn't find it as natural.
I guess it's rooted in one of the rules I've learned since becoming a web developer... People Like Widgets, Buttons, and Pop-Up Windows all in Pretty Colors Complimented by Ugly Animated Graphics .
Sad but true. :-)
What's a sig?
"Younger" in computer experience, not biological existence.
where there's fish, there's cats
What are you defining as the "younger generation"? I'm only 19 now and I DID grow up using DOS, text-based interfaces, LangWin (a text-based windowing system for BASIC), and the like... Perhaps younger people who started using computers later may have started out on GUIs but I can definately remember when Windows 3.0 was nothing more than a novelty toy.
I think it's a mistake therefore, to forsake the GUI. For example, with a GUI you can make a tabbed interface to allow the presentation a lot of information without losing your way.
Also with a non-web based app, you're back to installing the software on each computer where it's going to be used.
What architecture would I use? JSP. (Check out jetty, a simple and free jsp server). Marlin
That was the turning point of my life--I went from negative zero to positive zero.
I've always thought it was Piece Of Shit
When I learned to code, LEDs weren't yet in widespread use, and all of the computers used HEDs (heat emitting diodes) for status displays. The only way to tell if a bit was set was to touch a HED and see if your fingers got burned.
Luxury! Back in my day we had to hoist massive stones around and line them up with the stars (which were always moving, mind you) just to figure out what day of the week it was.
I swear, the kids these days... Call themselves coders and they've not even risked a hernia...
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
If people working at mcdonald's could type, even just a little bit, the order taking would be incredibly streamlined using, for example, 3 letter codes for each food item.
Much faster than having to look down and find the damned button for that food item. You could also maintain eye contact with the customer as you took their order.
Oh well.
Actually, it's pretty apparent to the rest of us.
information is immaterial
Curses on curses. We're developing a text-based UI from scratch in Perl using Win32:Console. Curses didn't work for us. Win32::Console works great, now that we got the up arrow moving the cursor to the previous field...
information is immaterial
Hmmm. Now there's a lesson in using the preview button.
information is immaterial
Few people in this industry want to invest in a GUI interface, and won't for probably another decade or so. The screen is 15 x 15 (characters) and what we do works well: receive shipments, send shipments, move shipments, etcs.
TUI is going to be around for a long time yet. We use Perl and VB. We'd migrate to Linux in a second, if customers would buy it. Given time, they will. But for now, we use Win32...
information is immaterial
As some others have suggested, use curses.
I put together an inventory system more than a decade ago using curses. The company is still using it. Occasionally some of the employees complain about it not being a GUI, but the owner likes it because it's rock-steady stable and it works. And he isn't locked into a perpetual software/hardware upgrade cycle as he would have been with Windows.
Forget your grandfathers' 8086, here's a dusty, late cold-war relic: Raise your hand if you still remember GEOS for the Commodore 64.
I used a system for DOS called Intuit (I can't remember the exact name. It was written in C, and was a complete windowing system. Very light weight and fast. I wish I code find the source for it again. I did port part of it to Unix. I was able to do edit masks and edit templates with a terminal. The neat thing about the system was that you could have all of your graphic output go through one function. Made things very easy to change.
Eagles may soar, but weasels don't get sucked into jet engines!!
The main assembly language support consisted of routines to read/write a line of video in and out of string variables, which had to be presized. Everything else was written in BASIC and ran like blazes on a 286.
Brackets contain world's first nanosig, highly magnified:[.]
A long, long time in a far away country (for most /. readers) I was in my final year of informatics. Some nice female teacher asked her student to learn Pro*C (Oracle's precompiler to embed SQL and PL/SQL in C programs). ...) had a system to easily use to their databses!
Apparently the only system in school that wasn't occupied, had C, and some kind of Oracle was the old Vax...
We had to build something, anything in Pro*C. But me an my two fellow students had a real hard time finding a suitable subject.
So finally we thought to make an SQL-navigator like app. We used just plain C (well and Pro*C naturally) but no UI lib at all.
You now what? Next year they extended the life of the Vax. Just because now they (teachers, admins,
120 chars is not enough!
Try the dialog program in combination with a shell or perl script. It is almost standard on every linux distro. Very fast and easy but not usefull for complex tasks :-(
Most volume data entry people use only one application all day long, and a GUI does nothing to improve their productivity.
Ternimal/Console based applications are alive and well in the data entry arena, and until a GUI can improve (instead of decrease) productivity test based interfaces will be the platform of choice for volume data entry.
The evil empire made it work. After Visual Basic 1.0 came out they introduced Visual Basic for DOS. I re-built Windows Apps written in VB 1.0 by just re-compling the source code. The programs ran fine on old 8088s.
O'course, then Microsoft decided DOS was 'dead' and VB DOS never got past version 1.0. But it was nice while it lasted.
Let the flames begin!
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
Have we forgotten how to add keyboard navigation to our windowed apps? Short of the perception that text based apps are more keyboard friendly, what other advantages do text based apps add.
And please don't pull the "But text based apps are the only thing that will run on my precious 8086 that's been passed down for three hundred years." The majority of machines will run a reasonably powerful windowing environment. Further, it a company cannot invest in machines that are less than 4 years old, perhaps they should stick with paper...
So the question still stands.. What do text based apps have to offer?
There's a part of the POS world that been a bother. There are lots of thingies hung off most POS machines - cash drawers, bar code and mag-stripe readers, time-clocks, ...
Any pointers or suggestions would be much appreciated.
Only us geeks are allowed to do that.
If you are VIOLENTLY opposed to curses it should be fairly easy to write a GUI front end--all of the user interface stuff is separate from the business logic/back end.
OH, it's all written in Perl and PostgreSQL's SQL.
jason (at) BurrellBizSys.com
Some times ago I worked at company which make and support traiding system for Russian markets. It's large program complex includes Linux, SCO, Informix, Postgres. Siemens POS'es was used (i386, 8 Mb RAM, bar code scanner). It's run under Linux + my drivers for specific hardware. POS soft was writed on C with ncurses and postgres libaries. You may use more powerful TI libraries now. Look to newt, for example. It's simple, have modern look & feel and included in standard RedHat distribution. It's have C and Python prog. interfaces, and graphical representation -- gnewt.