I want to code a primitive, DE independant application. Hence I want to be independant of Qt and GTK. What is the next lower library below Qt/GTK. I mean what is the lowest common denominator that is used by either of them and is available on every graphical linux system.
The X11/Xorg server is used by both Qt, GTK, and pretty much every GUI toolkit out there (FLTK, etc...), so it is the "lowest common denominator" you're talking about. You can use it directly with the XCB or Xlib library.
There is no such common library.
If you are writing a desktop app (i.e something you expect the user to interact with through their usual windowing system) my advice would be to use either QT or GTK - choice is yours.
There are some other reportedly simplier 'lightweight' libraries you can use such as EFL (Enlightenment) and TK (i.e. Old school tcl/tk apps haven't seen one of these for years). Or you could even use something more exotic like Motif (for that cutting edge mid 90's unix workstation CDE look and feel) - I hear that is open source now (finally).
For a full screen app like a game I believe you can use SDL or maybe ever write out directly to Linux's frame buffer device - I can't really offer anything here I have no experience.
There is no gurantee any of these libraries will be available on any given Linux installation. Thankfully package management exists to take care of this for you. Write the app publish the source and the make files. If people find it useful and want it in their distribution someone will package it for you.
If you are making a closed source binary you are left with static linking.
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 want to impliment some kind of UI for my Python programs (some simple operations, nothing advanced).
So I looked around and considered ncurses and tkinter for python. Yet I am not sure which of these two would suit best my needs for a simple interface (in the sense of easy to learn to program) with the best output possibilies. It does not have to be fancy or anything, just help me visualise my code (lets say a text based chess game).
intuitively i would take tkinter, but could you probably just summarise for me the advantages of the two UIs? (in addition ncurses does not seem to have a good tutorial for python...)
Thank you in advance!
I would like to suggest tkinter as it comes with python and compare to other GUI packages it has good tutorials. And also it will help you to improve your OOP concept for python
If you plan on using your application across platforms, Tkinter or PyQt are both good choices. If you want a GTK+ application that matches your GNOME environment and don't plan on using the application on other platforms, then I would suggest using GTK+ via gobject-introspection (from pygobject). In Fedora, you should have support for it out of the box. Other distributions may require the installation of additional packages.
For more information on the above bindings, see:
TkDocs
The Python GTK+ 3 Tutorial
(Sorry I couldn't post a link for PyQt because I don't have enough reputation to post more than 2 links.)
Additionally, it's worth noting that both PyQt and GTK+ have interface designers available so that you don't have to create your interfaces programmatically if you don't want to. For PyQt I believe Qt Creator comes with an interface designer. For GTK+ you have Glade.
Anyone knows which syscall is for GUI programing so that we can draw various pictures on the screen?
I don't find one here..
GUI needs kernel support,right?
You draw on the screen by talking the X11 protocol to the system's Xserver. (The system calls involved are the usual ones for talking over a socket, so they're not informative.) Usually you use a library to do that. The usual basic library to use is the X11 library (libX11) and that is usually wrapped by a toolkit library like GTK or Qt (or wxWindows or Tk or …). There are low level libraries too (xcb, which is a thinner layer over the X protocol) and higher level libraries as well (Gnome, KDE). You can also use OpenGL libraries, which is a whole different approach.
There are whole shelves of books on how to do this.
The Xserver itself uses memory mapped devices, and it talks at a very low level to the graphics hardware. It's not a hugely higher level thing than a graphics driver, and it is a very highly privileged process. (If you're comparing with Windows, you need to be aware that the exact levels that things are split at is different, but the level of libX11 is fairly similar to much of the Win API.)
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'm curious to know: is scrolling (such as in Firefox, Nautilus, etc.) handled be each application separately? Or is it done by the environment? Or by the widget toolkit?
What confuses me, is that it is possible to change to "smooth scrolling" in Firefox, which makes it seem like each application handles its scrolling separately. However, when writing software for Linux, you don't really need to specify and it seems like GTK takes care of it on its own.
The reason I'm curious is because I wanted to know if Linux could have it's own "accelerated" scrolling, much like OS X. I know this is possible by app, because Google Picasa has its own built in.
To make this possible for the entire system, does GTK need to be modified? Or something else?
Most applications rely on their toolkit for scrolling behaviors.
Firefox does a lot of stuff by itself, partly because it runs on various platforms with various toolkits (not just GTK), and partly because it has advanced needs that aren't always met by whatever toolkit it happens to be using.
GTK is far from the only toolkit used on Linux. There is also Qt (which is used in KDE), wxWidgets, Tk, FLTK, Motif clones, Xt, and you can even build applications on Xlib itself without a toolkit.
You're using two different terms, "smooth scrolling" and "accelerated scrolling". These are not the same thing, and the latter is technically ambiguous.
There is absolutely nothing preventing Linux (really X) applications from having any particular scrolling behavior. It's up to the application and/or its toolkit, if it relies on one.
Regardless of the above, keep in mind that not everyone agrees that the scrolling behaviors you allude to are good.