From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <32d987d50511180545h5101f3dat13d64a95b737d16a@mail.gmail.com> Date: Fri, 18 Nov 2005 10:45:58 -0300 From: Federico Benavento To: Axel Belinfante In-Reply-To: <200511151119.jAFBJvY23022@zamenhof.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200511142147.jAELl0T19882@zamenhof.cs.utwente.nl> <32d987d50511141830y780f0ee0h75645592337f4dfa@mail.gmail.com> <200511151119.jAFBJvY23022@zamenhof.cs.utwente.nl> Cc: 9fans <9fans@cse.psu.edu> Subject: [9fans] Re: allowing abaco to receive plumber messages Topicbox-Message-UUID: adc633ac-ead0-11e9-9d60-3106f5b1d025 On 11/15/05, Axel Belinfante wrote: > > > I don't know if this is what you want: > > > > Hmm, I don't know either, I had thought about this too. > > As you say making it a plumb server allows you to > > click on in the same window. but you loose the open a > > link in a new window capacity. > > Yes, I see there are choices that can be made and it is > not yet clear what is the best solution. > > Being aware of this, and not being burdened by having > to implement it, for me it is easy to say: > I think, for now, while we (you, your users) are still > trying out what works best, it might be best/nicest to have > a very flexible tool, that can be used in various ways, > to allow experimentation, to see what works best. > > I'm wondering if it would be possible/useful to make > a separation between the 'core' rendering thing > (as abaco does) and the navigational stuff around it, > 'the manager' that keeps track of history etc. > > I don't know what is best: > - in some cases you just want to reuse the window for a new page > - in some cases something like tabbed browsing is nice > - in some cases you may want a new window > > It might be nice (but I don't know if possible) to have > an 'open' framework that would allow you to have/build > all of these in an easy way, and abaco would be (re)used > in all cases. > I'm rewriting abaco to use thread(2), and right know my testing threadmain only calls 2 functions: HText *htload(Rune *); void htrender(HText *, Image *, Rectangle); > Would the Plan 9 drawing approach make things easier? > E.g. abaco just renders a url onto a given window > (drawing device), and somehow (plumbing?) gives access to > the links in there. > Then the real browser (gui) just manages windows (drawing devices), > a bit like rio does, but then specialized for web browsing, > also with navigational buttons or so, > either overlaying/next to each other (tabbed browsing), > or by creating new windows, or ... > a bit like ghostview (the postscript engine) renders inside > a gv window on unix. > > > My idea was this: if you want a page to be open in the same > > abaco instance you click on the link, and if you want to open it > > in another window you just plumb the link. > > makes sense. Can you already click a link to open it? > If so, I missed it... > no, you can't do it right now. > > I still, don't know what is better, and still thinking, > > how the UI should be, what I do know is that I need > > to rewrite abaco with threads and change the rendering model: > > no double buffering, because some pages are too large, and > > allocimage fails, and avoid non needed calculations. > > > > If you have more opinions(pros & cons) about making it > > a plumb server, or about the UI, or just about anything. > > I'll be glad to hear them. > > Some ideas above. > > It might interesting to see if indeed it is possible to > keep abaco as simple as possible (let it do one thing and > do it well: render a page, and send url's to the plumber), > and build all stuff the user might like outside 'abaco-core', > where indeed, hopefully, the plan 9 ways of doing things > (/dev/draw, plumbing) make it easy to do build an application > as a collection of small program, working together concurrently > to get the job done (as actually you are already doing, > of course, with webfs and maybe also other stuff I'm not aware of). > hmm... I'm more inclided more for a lib solution. > > Thinking in this context, maybe abaco-core should not > directly accept the web plumber message: they should > go to the 'surrounding' browser gui, which then decides > wether to forward it to an existing abaco instance > (which one? the one that generated the plumb request? > but how do we identify that one?) > or to a new pane (as in tabbed browsing) or even new window, > and then just sets up the right window context (a la rio) > before invoking abaco-core to do the rendering. > maybe the best/simpler solution would be having a command line option "-p" that makes that abaco instance a plumb server, but I'm not sure. -- Federico G. Benavento