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.
Related
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.
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.
First off, I'm looking to write GUI apps based on an interpreted language (PHP if possible--otherwise, Python). Second, I'm looking for a rapid-app GUI designer that lets me create windows, drop UI elements on it, and wire those elements up to code easily. Finally, it would be nice to have a simple way to package the whole thing up (deb, rpm, etc). Ideally my application should work on any Linux platform, and in Gnome or KDE.
I'm wondering if Glade is the way to go? And do I install just "glade" (via APT) or "glade-gnome"? (I'm on Linux Mint 10)
Bonus question: it would be cool to be able to have code that I could very easily just port over to Windows & Mac OS and work as well (UI and all). Of course, I'm thinking Python is probably the way to go as the underlying language.. if I recall correctly, Python has some way to build UIs that work on any platform? I could be wrong.
EDIT: Again, I have to say.. it is important to be able to have an interface designer of sorts. I absolutely do not want to code windows, buttons, input boxes, etc., by hand.
I'd really suggest you have a look at Qt. You have Python GPL (PyQt) bindings available or the (newer) LGPL Pyside bindings readily available:
A mature, stable, well documented and extremely rich framework
Comes with a GUI Designer for easy drag and drop UI design
Cross platform for free (Windows, Linux, Mac)
Look at PyGTK, wxPython
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.