I'm planning to build a simple, lightweight text editor that combines a great look with keyboard focused input.
I want to have a lot of control over things like antialiasing and all the graphics in general, but I don't care about having a whole library of widgets. Almost the entire UI will be text-based and in the main canvas/window of the app.
Toolkits like GTK and Qt seem like overkill - tons of widgets I don't need and a complex codebase.
Titanium, AIR, and XULRunner are even bigger in some ways - dev would be quick, but that's not exactly the lightweight approach.
Shoes seemed like a nearly perfect fit, but it's a little too small and doesn't support enough events (e.g. no window resize).
What do you think, should I just build it on Cairo/Pango or another graphics library and roll the platform specific stuff myself? I'd rather use a framework of some kind.
Basically all I want is:
good event handling
windowing
menus
drawing with really great type rendering choices
I would love to build this cross-platform from the start.
Even if you use just Cairo/Pango you still need windows on the screen.
The simplest combination would be cairo + pango + GDK (the windowing part of GTK+)
however even in that case you have no menus, and constructing menus with pure Cairo
would be a tough (but not impossible) accomplishment.
If you insist on lightweight and crossplatform then check the following
Fast Light Toolkit
Fox Toolkit
wxWidgets (goes great with Python)
Scintilla is a cross-platfrom source code editing component (based on GTK+) with excellent support for syntax highlighting, code folding, text zooming, and of course all the usual text editing functions; it should be an excellent foundation for a text editor.
Related
OCaml comes with the Graphics module which allows the use of a graphical window.
Is it possible to open two graphical window, and switch between them ?
The Graphics module provides machine-independent tools but in case of a negative answer, perhaps it would also be interesting to have solutions for different window system, such as X11.
I looked through the Graphics module API and I don't see support for multiple windows. I would assume Graphics was intended as something useful but simple enough to be part of the base OCaml release.
For more complex graphics, it makes sense just to provide OCaml bindings to an existing library. If I go to opam.ocaml.org/packages and search for "graphics" I see a few possibilities.
I have done OpenGL coding in OCaml but in fact I had to build some wrappers for OS-native GUI functionality to create the windows. This was many years ago, however.
The Graphics module is quite limited and is more intended as a simple basic library for teaching purposes. A possible replacement for Graphics might be the tsdl package which is a thin wrapper around the SDL C library which should work on most platforms.
I would like to use a text-based UI in my Haskell program. I found some bindings for the ncurses library (see also hscurses or ncurses, which one to use?). The hscurses and nanocurses packages are just simple wrappers around the C library, while vty isn't very well documented and a bit ugly (for example mixing snake_case and CamelCase).
The ncurses library on Hackage looks much more pretty and provides API which nicely fits Haskell. The problem is that it doesn't seem to implement some crucial features, like resizing or refreshing the windows.
So my question is:
is there any other Haskell text UI library, either ncurses-based or not, which I missed?
if there isn't anyone, is it possible to extend the ncurses Haskell library to at least support window refreshing and resizing? (this should be probably consulted with the project owner, but I need the solution quickly)
EDIT:
I finally used nscurses without windows (and panels) to avoid the troubles with refreshing them. I had problems with output to bottom-right corner of a window (a very similar issue was reported for Python's ncurses binding). I solved it by not writing there :).
Have you looked at vty-ui? It has a very nice user manual with lots of examples. I believe it's essentially a wrapper around vty.
I've used nanoncurses and hscurses succesfully, my hmp3 app has a binding that was the basis for nanocurses.
No matter what you probably will want a nice high level API. hscurses does have a box abstraction at least.
You'd be fine going with hscurses.
There is another good choice for Text-based user interfaces in haskell;
Brick is written by jtdaugherty, the same person that developed vty-ui which is Deprecated now.
The API is Declarative, which is Better for Presenting a language like Haskell.
also the Documentation was great and complete.
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 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.
I grabbed firefox 3.7a (note go to about:config and enable webgl) and ran the examples on this site http://www.iquilezles.org/apps/shadertoy/
The examples were cool then it hit me. How is it running? Code is being ran is it not? Is this an implementation of LLVM? is something else going on? Would i be able to run my own examples and do something like a command line text based game?
The shader examples on that site are written in a C-like language called GLSL, which is the (Open/Web)GL Shader Language. When they're executed, the JavaScript WebGL code sends the shader source off to your graphics driver's OpenGL functions, which compile it down to a machine code that runs directly on your GPU.
BTW, the shader-only style of coding, while very popular and a great way of writing cool demos, is not an entirely typical use of WebGL. Normally the shaders are used to do a lot of the heavy-duty number crunching, but the design and animation of the various objects that make up your scene is done in JavaScript. (In OpenGL, you would see a similar split between GLSL and some other language, such as C or C++.)
If you want to learn more about coding WebGL, you could do worse than visit the tutorials on my site, learningwebgl.com. I frequently link to other people's demos and tutorials too, so if you don't like my examples you should easily be able to find something better :-)