Hello, On 1/31/14, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > A different paradigm has to be solved here. The paradigm of 2D inter‐ > faces to complex tasks. This could be done using swk. If you have swk > done right, then it could be easily run in text or graphics mode.
Currently swk supports SDL and X11, I suppose you either add another gc_VT100 or something so that text is also available. > > The idea of the GUI abstractions is like in every software aimed at > clueless programmers to add more and more layers. I might be a little clueless :) > > That’s where the suckless solution should begin, by having reusable mod‐ > ules. For example there was the idea on the IRC channel to have a sepa‐ > rate GUI process handling the output and giving callbacks via a simple > text interface over a pipe. That process could display the meta‐informa‐ > tion of arranging UI elements (buttons, listbox, entry, forms, menus) > however it is needed. Of course supporting the OpenGL widget won’t work > in text mode. I started something i'm calling swt [1] which aims at the idea above. Though i've been feeling rather clueless about the direction it should go. Currently it has a fifo for input and an output file. its using libsl but it will fork off on its own with the need for further text control. it doesn't handle multi-byte yet. and it can only do equidistant horizontal and vertical layouts of text regions. you can create windows, and add text regions to those windows, you can close windows and possibly remove text regions too...(so still work in progress...) and you can somewhat toggle focus of those text regions. The input fifo should handle things like window creations, creation/manipulation if text regions within those windows and dynamic mapping of key bindings that simply echo to the output for the controlling script to do its thing. On the output side it either echos whats its doing or errors, possible keybindings pressed and information about the state of the ui. it probably should provide drawing to hidden Drawables for future mapping, hiding/unhiding of regions. and multi-byte or UTF-8 of course. With regard to widgets i think for menus we have dmenu, listboxes might be needed given the different modes one can toggle, perhaps a tree view too. buttons seems a bit like a hack to a bad interface or they should be simple standard key mappings (vim?). forms sound like glue around the former. maybe there is a status bar to suggest actions to perform or caret navigation as soon as ":" is pressed like line numbers in vi, every major widget/text region has an assigned number...that could get out of hand. with swt i've tried to define how one would interact with it to create the UI, it could be driven by any language able to read and write to files. its interesting that surf and dwm just got fifo in them...perhaps tabbed should too. perhaps really we should have separate embedable applications with fifos. one for listboxes, one for tree views, an embedable lil'd (son of dwm) for layouts within an app, a keyboard listener for focus switching? this feels like a re-invention of the wheel... One aspect i feel should make this effort legitimate is the amount of keystrokes it takes to navigate this environment. i would like an environment that is navigable by keyboard. but i sometimes question the efficiency of it. and certainly if you are pressing more keys with this env when you could quickly click on something with the mouse, then the battle has been lost. (or is that a smell of a bad application?) > > What’s left is writing this by pointing out the really needed widgets. > Here new ones evolved, like the command line of vim added to browsers, > which could be reused in such applications to always have all UI ele‐ > ments available via a text interface and make it automatically script‐ > able. Then the menu, buttons, of course an editable text field with the > $EDITOR you wish, some way to display graphics (w3mimage for st maybe?), > tables …. > [1](https://github.com/vlaadbrain/swt) --Carlos