> 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...
