> 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.
So, you are suggesting an ultra abstract model.
Output the data in such a way that it could be parsed by an output
handler (graphical, text, or however you want).
I must process this idea.
Well, using 2 processes for just an editor is stupid.
HOWEVER, what if we could parse more than one program with the display daemon.
It's like a windows that anyone can draw in.
We could implement this in DWM and each tag is nothing else than
deciding who can draw in the big window.
Have I gone too far?
Have I gone insane? I don't know.
In the way I understand it, it's a completely new way of handling UI.
It would save us a hell lot of coding in graphical apps.
But according to my not-so-long experience in programming, abstracting
gives you headaches and slowdowns, unless you are heading for
something huge. That's why I think that abstracting editor from gui
and use this only for the editor is a bad idea.
Wow, you gave me a hell lot of food for thought...
Received on Fri Jan 31 2014 - 14:34:55 CET
This archive was generated by hypermail 2.3.0
: Fri Jan 31 2014 - 14:36:08 CET