Dnia 2014-01-31, o godz. 10:49:11
Christoph Lohmann <20h_AT_r-36.net> napisał(a):
> Greetings.
>
> St was born out of the reason to have a compatibility layer to all
> of these modes and the applications using it. For writing new
> applications simply use a known subset which works. Since basic
> escape codes require terminfo because st is different to xterm or
> urxvt, the only real alter‐ native is ncursesw. The API isn’t that
> bad. Compare this to any GUI API.
>
> 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.
>
> The idea of the GUI abstractions is like in every software aimed
> at clueless programmers to add more and more layers. You nowadays
> have high level languages taking away the burden to think, then there
> are GUI edi‐ tors where you click to add a button and automatically
> the callback is generated.
>
> 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.
>
> 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 ….
>
> Conclusion: Text is just a way to output the metadata really
> represent‐ ed. There all hope is gone by backwards‐compatibility and
> the wide va‐ riety of terminals. Ncursesw is the only help here.
> Abstract it to the suckless needs.
>
>
> Sincerely,
>
> Christoph Lohmann
Hello.
Topic of Suckles UI always reminds me of The Apollo Display
Manager thread [1].
Terminal emulator is single window which different programs can
control. You can shuffle files around and then run your favourite
editor to write an email in single window. Windows don't pop around.
Much like in web browser - you can search for some music and then play
it in single window (single tab).
Of course there is more to it:
- history of commands and their outputs - history of URLs and to some
extent their representation (cache)
- command completion - URL completion, search suggestions
- not much difference between local and remote operations - same in web
This analogy is leaky, but point stands.
Do we want to create our own display server protocol on top of existing
display servers (fifo/fs interface)?
Or do we want to compose UI from parts (tabbed, surf, st, dmenu, etc.)?
I was experimenting with tabbed to make it possible to make every X app
embeddable in tabbed. Like this:
$ chrwin $TABBEDXID sxiv
chrwin - change root window [2]
It is not finished - it doesn't even read argv. Conceptually:
- acts as unix socket proxy (forks at connect)
- when client creates window with same parent id as root window it
sends request with $TABBEDXID as parent id to Xserver and
reparentnotify to client
Issues:
- my first client/server program
- tried only with hardcoded XID and unix socket addresses
- some windows shouldn't be reparented (dialogs etc.), but supporting
this may be a little too much for this hack, maybe tabbed could
ignore dialogs (using dwm logic for default floating windows)
- xauth not supported, solution:
$ xauth add :123 $(xauth list $DISPLAY | awk '{print $2, $3}')
It's not pretty, but it works and it is small.
I hope that in Wayland it will be much simpler and less hacky.
[1] -
http://lists.suckless.org/dev/1106/8766.html
[2] -
http://hawski.com/chrwin/ - not the latest version
With regards,
Hadrian Węgrzynowski.
Received on Fri Jan 31 2014 - 20:58:45 CET