I need to develop a large set of tools to be run from the server command line (i.e. not client-server architecture). The systems does not have to be high-performance; I just want something that is easy to develop with.
Which technologies are out there I can use to build simple GUI to be run from the command line? I need only menus where I can select a line/check-box/enter free text in a dialog.
Edit: forgot to add, access to Mysql (i.e. drivers available) is essential.
Shell, with dialog, the old stand-by - http://www.linuxjournal.com/article/2807
EDIT- If it's MySQL-related, take a look at PERL-Tk and DBI.
python + ncurses would be a good combo here.
i like using perl's re.pl from the Devel::REPL library for quickie cli interfaces. read on a bit for my rationale before downvoting!
in this type of app it sounds like you will be doing query-type operations. these naturally lend themselves to a "repl" style interraction. re.pl gives you all of the goodies, namely command editing and history. all you need to write are the functions that users will call. the nice thing is that users who know perl will realize they can use any installed module to extend the functionality of your system on their own. i my case, i used re.pl to create a mysqlclient-like tool to access and display data that was being compressed in a way that the standard mysqlclient couldn't deal with.
i cite perl because it's DBI is the best database abstraction and it is what i have used....but the rationale can be extended to other tools. python's repl or any other would provide the same benefit.
You could use Mono for Linux and write your program in C# .NET, then make it work for Linux, since Mono allows so.
As far as graphic command line interfaces go, one of the best frameworks is ncurses. It abstracts away most of the ugliness associated with graphic command line applications.
I have to say, use Python, because I like it.
But text-based interfaces are pretty much not worth it, because they seem like a good idea until you look at the details:
There isn't really a standard keyboard navigation model for text-UIs; they all use their own scheme
How is unicode supported? (Hint: this is nontrivial)
What about different keyboard layouts? What key does someone press if their keyboard doesn't have, say, a "home", "end", or "Escape" ?
ncurses does not provide a widget set, only low-level operations. The answers to the above questions aren't easy.
It really shows that nobody has put much thought into keyboard-and-text-driven terminal-based UIs recently, or these would all have been solved.
Web interfaces have them solved, in fact, you can use a text-mode web browser if you like.
Modern devices like i(phone|pad)s and even cheap mobile phones have a web browser which is good enough.
It is easy to write a web application which uses a very simple style (few images, little Javascrfipt) and have it work without much effort on a variety of devices.
So I would say go with dmckee's comment "go with what you know".
By building your own terminal-based interface, you are going to box yourself into a corner in the long term.
Related
I am looking to create an AI environment where users can submit their own code for the AI and let them compete. The language could be anything, but something easy to learn like JavaScript or Python is preferred.
Basically I see three options with a couple of variants:
Make my own language, e.g. a JavaScript clone with only very basic features like variables, loops, conditionals, arrays, etc. This is a lot of work if I want to properly implement common language features.
1.1 Take an existing language and strip it to its core. Just remove lots of features from, say, Python until there is nothing left but the above (variables, conditionals, etc.). Still a lot of work, especially if I want to keep up to date with upstream (though I just could also just ignore upstream).
Use a language's built-in features to lock it down. I know from PHP that you can disable functions and searching around, similar solutions seem to exist for Python (with lots and lots of caveats). For this I'd need to have a good understanding of all the language's features and not miss anything.
2.1. Make a preprocessor that rejects code with dangerous stuff (preferably whitelist based). Similar to option 1, except that I only have to implement the parser and not implement all features: the preprocessor has to understand the language so that you can have variables named "eval" but not call the function named "eval". Still a lot of work, but more manageable than option 1.
2.2. Run the code in a very locked-down environment. Chroot, no unnecessary permissions... perhaps in a virtual machine or container. Something in that sense. I'd have to research how to achieve this and how to make it give me the results in a secure way, but that seems doable.
Manually read through all code. Doable on a small scale or with moderators, though still tedious and error-prone (I might miss stuff like if (user.id = 0)).
The way I imagine 2.2 to work is like this: run both AIs in a virtual machine (or something) and constrain it to communicate with the host machine only (no other Internet or LAN access). Both AIs run in a separate machine and communicate with each other (well, with the playing field, and thereby they see each other's positions) through an API running on the host.
Option 2.2 seems the most doable, but also relatively hacky... I let someone's code loose in a virtualized or locked down environment, hoping that that'll keep them in while giving them free game to DoS or break out of the environment. Then again, most other options are not much better.
TL;DR: in essence my question is: how do I let people give me 'logic' for an AI (which I think is most easily done using code) and then run that without compromising the functionality of the system? There must be at least 2 AIs working on the same playing field.
This is really just a plugin system, so researching how others implement plugins is a good starting point. In particular, I'd look at web browsers like Chrome and Safari and their plugin systems.
A common theme in modern plugins systems is process isolation. Ideally you should run the plugin in its own process space in a sandbox. In OS X look at XPC, which is designed explicitly for this problem. On Linux (or more portably), I would probably look at NaCl (Native Client). The JVM is also designed to provide sandboxing, and offers a rich selection of languages. (That said, I don't personally consider the JVM a very strong sandbox. It's had a history of security problems.)
In general, my preference on these kinds of projects is a language-agnostic API. I most often use REST APIs (or "REST-like"). This allows the plugin to be highly restricted, while not restricting the language choice. I like simple HTTP for communications whenever possible because it has rich support in numerous languages, so it puts little restriction on the plugin. In fact, given your description, you wouldn't even have to run the plugin on your hardware (and certainly not on the main server). Making the plugins remote clients removes many potential concerns.
But ultimately, I think something like your "2.2" is the right direction.
I'd like to write a x11 terminal emulator, but I don't know how I should spawn and communicate with the shell, is there any basic (pseudo- or C) code for that? like what sort of PTY to create, how to bind the shell to it, what signals I have to catch or send, etc. don't really feel like sorting through the whole xterm sources.
EDIT: oh and I want to implement a way of communicating with any applications in it, how shall I do the feature discovery? some hidden ansi sequence in the "clients", hoping it's not colliding with other terminal emulators? some environment variable, hoping it's not colliding with the "clients" or removed by the shell?
YAT (yet another terminal) https://github.com/jorgen/yat is suitable for embedding in Qt Quick programs. Contributions for improvement are welcome. (Disclaimer: a friend started that project, and I work on it sometimes.) It takes a mostly correct approach (e.g. it uses a Linux pseudo-terminal properly, something I didn't know about before my friend was explaining that), and has a lot of features; however the parser is written from scratch and is not feature-complete or bug-free yet.
Unfortunately most terminal implementations so far have been starting from scratch, or with a one-off monolithic fork (from rxvt for example), which is a lot of work and results in all of them being incomplete. So I think a better alternative would be to use a reusable logic-only library called libvterm: http://www.leonerd.org.uk/code/libvterm/ or to base your terminal on one which already uses that. That way if you find bugs and fix them, you'll improve the whole ecosystem.
https://github.com/timmoorhouse/imgui-terminal is interesting, and works (at least somewhat) but is a prime candidate to be rewritten with libvterm, IMO. If you are into immediate-mode rendering in OpenGL, it might be a good choice anyway.
http://41j.com/hterm/ does use libvterm, and adds a few features which libvterm doesn't have, for inline graphics rendering (ReGIS and PNG). But the code is not elegant enough or portable enough, IMO, and the graphics rendering "floats" over the text rather than being truly inline. It still might be an adequate starting point for some use cases. In my fork https://github.com/ec1oud/hackterm I got it to build with mostly modern system libraries, however it still depends on an outdated version of SDL, which is included.
OK, if anyone also need this, and is using lua, I found the http://www.tset.de/lpty library works fine. still testing ansi escapes and stuff, but should work.
I am using the standard IDE that comes with python3.
I would like to make use of the backspace function (\b) within the ILE in order to create a NICE LOOKING progressbar. Even a simple percentage counter requires the backspace function.
When I run the script I get a wonderfully useless symbol instead of a backspace.
Questions:
How can I use \b in the IDE
How else can I make a progress bar that would use something similar to a backspace (in other words, I don't want a lame eg: loading:##########################
I've read threads on this and the best solution I've heard involves actually re-writing the IDE base code which is just an tkinter app. I just don't understand why this would be required ... did they think it was a stupid feature to have a function like this in the standard python IDE? Mind-baffling
It sounds to me like you want a 'GUI' (often pronounced 'gooey') widget. That stands for Graphical User Interface. Python normally runs in a Text-Base Interface aka command-line interface (CLI). CLI applications are the sort of boring 1980s style terminal things that they had around before they invented the computer mouse and invented better graphics devices. If you want a progress bar to look modern (my interpretation of 'not lame'), you will have to create a GUI. Python can do this too, if you use special tools. You need a GUI framework. Some good GUI frameworks are listed here. Different frameworks are like different tools. I would recommend using tk and ttk for starters (TKinter and themed TKinter), and you can get that version of the progressbar here.
So actually implementing GUIs is always a mess. It is really complicated and very difficult to program. That is the value of the boring 1980s style CLI terminal applications is that they are much simpler to program.
If you still decide you want a GUI app, you should check out a tutorial or maybe even a GUI-builder. See this stack overflow thread and this website.
I'm a Linux user, and I have been very hesitant to use Glade to design GUIs, since the xml files it produces can easily be modified. I know it doesn't sound like a major issue, but what if it's a commercial app that you just don't want people changing?
I use Mac OS X every once in a while, and I figured out that they use files called ".nib"s for GUIs. I think they're essentially the same type used in Nextstep and Openstep (there's even a Linux app which lets you edit these files). Anyway, these files are included in the application bundle, and according to some people, are completely editable. This person claims he even successfully edited Keynote's interface.
Now, why would that be possible? Is it completely okay for the end user to change the interface? Or is it better to have the GUI directly in the compiled application code, like traditional GTK apps?
OS X nib files are one option; the other option is to do things programmatically. For android, XML files can define the GUI or program code can do it. In Windows WPF, the UI is made in XML. Firefox/Mozilla? XUL, another XML-based UI language.
Most modern GUI toolkits have either both of these options or even just defining UIs in files.
But even binaries are modifiable. With a good binary reverse engineering tool, it's wide open. The only way to be really certain is to do what Apple did with iOS, and run signed code; the entire bundle is signed by a key and can't be run if modified.
This isn't a problem for most everyone. Why do you care if the UI is modified? The underlying code isn't, so functionality can't be added or modified.
As a corollary (and a little off-topic) something that you might have a valid concern about is stuff a little more like this.
I don't really see a problem with it. If a user messes up his UI, then it's his problem. Think of it like moddable games. Users always loved them, and in the end, most games benefit from it. There is usually nothing secret about an application's user interface. If there is, you could always do some sort of encryption.
As others have said, you can also add checksums if you just want to disallow editing.
The xml specifies little more than what the interface looks like. Without the compiled-in event handling code, it's pretty much useless. My opinion is customers change it at their own risk, and you might actually get some free useful improvements out of their hacks.
If you're really paranoid about people changing it, you could always add an MD5 digest verification step or something when you load the xml, or compile the xml string into a header file, but that defeats many of the benefits.
The theming engine can make substantial-looking changes to your GUI, as can tools like Parasite. Updating the Glade layout — at their own risk — is much safer than either of those.
What's wrong with users customizing the UI anyway?
everybody out there!
I'm currently seeking for a technical solution to create a nice literate programming environment. Unfortunately, most editors are too much hard coded, and their functionalities just cover most famous needs, and can't cleanly cover special needs.
I came to Emacs (later after some others), but I also came to numerous troubles with Emacs (I will not talk about these, this is not the topic).
However, there is one thing I like with Emacs and which was indeed matching what I was looking for: it exposes a full text model to a scriptable environment, and the overall UI is designed so it is well suited to either graphical UIs or text UIs (because it is mostly text based). And last but not least, this is scriptable with a kind of LISP, and LISP indeed seems a good choice to me, in the area of text manipulation and interpretation.
I've searched the web for a text editor which would expose a full text model to a scriptable environment, but I have not found anything. I guess this is not an everyday request on the web, so it is probably better to ask some humans about it, better than to ask a robot.
I was, but in short, I'm looking for: an editor which exposes a full text model [*], and which exposes this model to a script engine (preferably LISP, but I would enjoy Python as well, or any others after all).
[*] Talking about text model, I mean: text attributes (optionally font face), text visibility, text read-write property, and text content iteration, at a level as low as the character basis.
Have a nice day! :)
--
Yannick Duchêne
JEdit seems to be very scriptable with Java, BeanShell, Jython and other languages targeting the JVM. Most of its functionality is implemented with OSGI plugins. If you really like LISP, maybe you could even try with Clojure! :-)
Emacs, Climacs, Portable Hemlock (and to some extent Hemlock).
I am sure there are other editors around that exposes a full text model to a script engine that are NOT in "the emacs family", but I don't know them.
Oh, yes, there's the VMS editor framework, but I cannot recall its name.
What Vatine said, plus there's a very minimal Scheme editor built into Fluxus, which I extended with Emacs key-bindings (in my personal copy), so I know it would work as something close to a stubbed implementation (if you rip out all the OpenGL stuff).
Edit:
Looks like I was working with fluxus-0.8, which doesn't even seem to be on the site anymore. If you end up needing to go that low-level to start, let me know and I'll send it over.
Not sure if this is useful, but there is a long list of Emacs-like editors: http://www.finseth.com/emacs.html
Btw., Craig A. Finseth also wrote a book on implementing an Emacs-like editor: http://www.finseth.com/craft/
The Book as PDF.
Report of an (unsuccessfully) ending quest :
Although a possible technical choice I could figure will not work for me (see later), I still point it here, if this can ever be useful to someone running UNIX-Like (I'm running Windows).
Context and state of the “ art ” : near to all (or all) so called Emacsen and Emacs clone, has nothing to compare with Emacs. They just mimics terms like major mode an minor mode, mimics key-bindings, and most of time also, the UI look and feel. But the core is not there. I've learned these are called “ Emacs Ersatz ”.
Disclaimer : for some reasons, I have not tested Climax and Hemlock, so the latter comment does not apply to these.
EFuns : the last one I came to, was EFuns, but unfortunately, I could not compile it on Windows (I suspect something is wrong with the sources, some directory are missing in the archive). Interested parties may get it here : EFuns, an Emacs-like scripted in OCaml. Fortunately for UNIX-Like users, binaries are provided (not for Windows).
Implementations List : to complete the list Rainer Joswig pointed to, here is another one, shorter, but more up-to-date : [ Sorry I can't post this link, it seems I'm not allowed to post more than one link - I'm sorry for interested parties (sad) ]