Developing Attractive non-GUI Apps for Unix? 150
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?"
Re:Scripting Language (Score:1)
Re:Why use text? (Score:1)
Re:Curses (Score:1)
What we really need (Score:2)
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
I like hearing this discussion :) (Score:2)
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
Python text interface libraries (Score:4)
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.
Re:A company to check out: ViewTouch (Score:2)
Hell no: the DNA Lounge [dnalounge.com] 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.
Re:Not for me. I love this topic. (Score:1)
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.
better (maybe you'll agree) (Score:1)
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.)
~^~~^~^^~~^
ANSI and Ncurses (Score:1)
Anyone know of any way to get ANSI-escape-coded files and Ncurses to cooperate?
One word: Emacs (Score:3)
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:
Suggestion: TurboVision (Score:3)
Take your pick: GPL or BSD Licensed. :-)
After you're done, talk to JWZ (Score:2)
"Beware by whom you are called sane."
Ncurses (Score:2)
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.
Re:Keyboard vs. Touch Screen (Score:1)
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.
Others will surely have suggested this... (Score:3)
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.
turbo vision (Score:2)
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 [his.com] (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.
---
Re:What Linux needs is some GUI but non-X-based ap (Score:1)
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
Re:Totally Offtopic but needed to be posted (Score:1)
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.
Re:The problem being... (Score:1)
Re:Keyboard vs. Touch Screen (Score:1)
No documentation or grid widget (Score:1)
Answer: NOT Curses or Slang (Score:2)
Try something like Xterminal [sourceforge.net] 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.
Re:Dumb it down. WAY down... (Score:1)
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.
Dumb it down. WAY down... (Score:3)
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
Re:Linux POS System (Score:2)
Re:wussies (Score:5)
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 [prmsystems.com]
Re:Curses (Score:1)
Re:text = cheap (Score:1)
> 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,
use lynx (Score:1)
*Raises hand* (Score:1)
_______
Scott Jones
Newscast Director / ABC19 WKPT
don't program for Linux (Score:1)
Re:The problem being... (Score:1)
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.
CDK Works (Score:2)
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...
Re:Trolltech does this... (Score:1)
Do you mean Glade [gnome.org] plus libglade [gnome.org] 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.
Re:GEOS! (Score:1)
--James
A company to check out: ViewTouch (Score:2)
Linux POS System (Score:5)
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/
Great Linux POS System (Score:1)
Check it out here [pwsinc.com] and a Screen Shot is here [pwsinc.com]
Re:Scripting Language (Score:1)
Re:Scripting Language (Score:1)
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...
links vs lynx (Score:1)
but I keep using lynx because it's classic like that.
Re:Since gfx gui and txt gui API? (Score:1)
--
Re:Actually, a good question (Score:1)
Your problems with curses are caused by working under Windows with no curses library installed, yes?
Hmm... (Score:2)
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 [xbasic.org], 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 [worldcom.com] - Generation Duh!
Re:Keyboard vs. Touch Screen (Score:1)
Has anybody seen a touch-screen work with Linux?
Re:The problem being... (Score:1)
Re:Gesture System? (Score:1)
Re:TurboVision is one (Score:2)
Re:The problem being... (Score:2)
TurboVision is one (Score:1)
Peter
--
www.alphalinux.org
Since gfx gui and txt gui API? (Score:3)
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....
Re:Since gfx gui and txt gui API? (Score:2)
- - - - -
Re:Totally Offtopic but needed to be posted (Score:2)
- - - - -
PicoGUI with ncurses (Score:4)
PicoGUI [sourceforge.net] 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.
How about a GUI without X11? (Score:2)
Have you looked at the ARACHNE Web Browser for Linux [arachne.cz] 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.
Turbovision (Score:1)
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/ [freshmeat.net]
Re:What we really need may be hard to find, but... (Score:1)
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)
Totally Offtopic but needed to be posted (Score:1)
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 [slashdot.org] (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 [freerepublic.com] 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 [antioffline.com], 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
Why bother? (Score:2)
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.
Re:One word: Emacs (Score:1)
Mike.
Re:Others will surely have suggested this... (Score:2)
I think that there's more than enough of that going around without a specific handbook. For reference:
[lizrd@linuxbox lizrd]$ cd /usr/src/linux
[lizrd@linuxbox linux]$ grep -r shit * | wc -l
60
[lizrd@linuxbox linux]$ grep -r fuck * | wc -l
23
[lizrd@linuxbox linux]$ grep -r bastard * | wc -l
4
[lizrd@linuxbox linux]$ grep -r damn * | wc -l
20
I must confess though that the shit grep produces quite a few results for "Matsushita CD-ROM controller" which isn't exactly cursing.
________________________
Re:Younger generation? (Score:1)
Re:What we really need (Score:1)
(Now I just have to figure out why
hmm (Score:2)
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.
Re:Curses (Score:1)
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
Re:Curses (Score:1)
Good reasons for CLI or TUI. (Score:2)
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.
Power Basic (Score:2)
text = cheap (Score:3)
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. :)
Re:CLI development (Score:1)
The same thing works in NT 4 and is located in HKEY_CURRENT_USER\Software\Microsoft\Command Processor
Re:A company to check out: ViewTouch (Score:1)
The overall low quality of VT products is exactly why JWZ was forced to come up with his own system for the DNA Lounge. When I was evaluating POS systems for a local night club, I communicated briefly with Jamie. Neither of us had any success getting VT to work at all, even after I had access to the source code.
Sadly, that nightclub ended up going with an NT-based solution becaus the Linux POS market was so barren. Ah well, hopefully LinuxPOS is mature enough to save the rest of you from that plight. I'm just glad my current employer doesn't deal with cash.
--
Ck -- Curses toolkit for Tcl (Score:1)
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.
How Microsoft did it (Score:2)
You can't get it, of course. It was never offered as a product, or else it would have had some other name.
steveha
Textmode Quake! (Score:1)
I wonder whether this could be combined with the Doom Sysadmin Tool [unm.edu] for a text->GUI->text->severe eyestrain session.
Re:What Linux needs is some GUI but non-X-based ap (Score:1)
Re:Not for me. I love this topic. (Score:1)
Keyboard vs. Touch Screen (Score:2)
Re:Totally Offtopic but needed to be posted (Score:2)
For the on-topic portion of this comment, let me suggest that there is really no reason to do a pure text based GUI anymore. Text based GUIs were invented largely because of limitations in the hardware, which have all must disappeared. These days, the term "Glass TTY" has about as much pertenence as "Horseless Carrage".
Just about ever normal GUI is still able to do text, so if you want a "text only" application, you certainly can get the same functionality, plus benefit from better tools cross-platform functionality, etc.
As far as joq is concerned, I find that browsing at +1 manages to filter out most of the crap pretty well. I wish moderators would spend their time modding up +1 posts to +2 instead of modding down +0 posts to -1, but there isn't much anyone can do about that. It's their mod points after all.
Trolls will be trolls. Ignore them (or read them at -1 if that amuses you). But don't take it seriously.
Curses (Score:4)
blessings,
POS? (Score:4)
OH!!! I all this time I thought people were calling me up trying to sell me a Piece Of Shit!
Re:wussies (Score:2)
Re:Keyboard vs. Touch Screen (Score:2)
On the other hand, I have see touch screens used in business' such as resturants and it seemed to work well, all they had to do was touch what was ordered and so on and it created the bill. In cases where data entry is limited to just touching what is being purchased then this is a good idea.
In the case of the former though I think a plain old text based "gui" would be ideal, if you're up to the task then nothing is really lost, and who knows it might turn out to be a killer app for Linux? And if not it still wont hurt to add to the plethora of Linux apps out there.
Re:Since gfx gui and txt gui API? (Score:3)
I don't know how extesible this could be but I don't see why there couldn't be a drawing tag when you need to free drawings. For things such as bitmap graphics they could be included sperately like they are in HTML pages, they could just be sent in another request or inline if that would be better performance wise. Just some ideas, I'm sure someone who knows more about creating GUIs than I can comment on whether this would be possible and whether it would be a good idea or should we just stick to X?
Re:What we really need (Score:3)
Re:Dumb it down. WAY down... (Score:2)
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.
Re:Why bother? (Score:3)
The time-consuming part of GUI development is never the amount of time it takes to make the computer draw the pretty pictures you want it to draw. The difficult part is deciding how the information should be laid out on the screen, and how the user is going to interact with that information.
There are a few reasons that GUI apps often turn out to be so incredibly shitty for data entry or certain POS tasks, and none of them have anything to do with the GUI. First, they're often written by dumb-asses who believe that the difficult part of creating a GUI is is going clickity-click in the visual builder window. Second, they're often written by people who confuse ease-of-learning with ease-of-use, and no desire to learn the factors that go into ease-of-use for a data entry system.
I have no idea why you'd imagine a GUI system would be any harder or easier to write than a TUI system, when the difficult part has nothing at all to do with actually slapping up the code to do the TUI or GUI part.
Scripting Language (Score:2)
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 [peakprogramming.com].
Dopewars (Score:2)
Moderators: This is an attempt at humor (albeit poor, i agree).
Ncurses Programming (Score:5)
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 [gnu.org] 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 [cs.mun.ca]
Linux Journal Artical by ESR [linuxjournal.com]
Fujitsu ETI Programmers Guide [uni-hannover.de]
SCO ETI Programming [sco.com]
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.
Have you considered SLang? (Score:4)
Check out http://www.s-lang.org/ [s-lang.org]
CLI development (Score:2)
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.
Re:The trouble with non-graphical is... (Score:2)
Developing Attractive non-GUI Apps for Linux
is better than...
Developing non-Attractive GUI Apps for Linux
The problem being... (Score:2)
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. :-)
Why Text-based? (Score:2)
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...
GEOS! (Score:2)
Not such a big deal to write one (Score:2)
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.
Re:The problem being... (Score:3)
But POS systems are fairly specialist. By removing excess graphics you can allow the end user to view the information they *need* in a clearly presented form. Anti-aliased fonts would be nice because higher resolution fonts can be more clear. Animated gifs don't really add any value though :-)
From an intranet development point of view, people like w.i.m.p.-driven interfaces as they're easy to learn but if they have to use them every day (possibly unlikely in a pure web field) they start asking for keyboard shortcuts because they're quicker...
If you watch a user on a unix-telnet system (like one used at a mobile phone company I worked for) you see them struggle to learn to 'archane' keyboard commands but once they have the experience they can switch between screens and get things done with almost amazing speed. The moment they we're 'upgraded' to a windows based system, they had to learn again.
The users never reach the levels of speed previously attainable because physically moving the mouse to the neccessary command buttons takes longer than, say, the time to move between keys on a keyboard.
Despite all this, I've still got to concede that 90%+ of all users, if given a demo of two new systems, will say they 'prefer' the graphical one over the text-based one. Talk about expensive window-dressing!
GUIs don't help for data entry (Score:3)
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.
Re:Why use text? (Score:2)