> 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?
So, why not use surf as the abstract layer I was thinking before
(Roberto's idea)
Roberto:
> You should avoid words as 'stupid', if you don't want to convert
> this in something personal. If you don't agree with an idea,
> please indicate the technical reasons, or in other case shut up.
I didn't mean to offend you. If I did so, you have my apologies.
I liked your idea very much.
I meant "overkill". 2 processes for 1 text editor is overkill.
If you have 2 processes for each editor instance I think that it is an
overkill, but if you have 1 process for each editor + 1 "central"
graphic renderer, it's ok.
Can't we use surf as the graphical renderer?
My concern is that if I do what I'm thinking, I'll end up writing a
fifo interface of ncurses and GTK, which is not the point, as I could
just use the lib directly.
In particular, you suggest a fifo editor. Am I right?
Received on Fri Jan 31 2014 - 15:57:49 CET
This archive was generated by hypermail 2.3.0
: Fri Jan 31 2014 - 16:00:07 CET