9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Federico Benavento <benavento@gmail.com>
To: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Cc: 9fans <9fans@cse.psu.edu>
Subject: [9fans] Re: allowing abaco to receive plumber messages
Date: Fri, 18 Nov 2005 10:45:58 -0300	[thread overview]
Message-ID: <32d987d50511180545h5101f3dat13d64a95b737d16a@mail.gmail.com> (raw)
In-Reply-To: <200511151119.jAFBJvY23022@zamenhof.cs.utwente.nl>

On 11/15/05, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> 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


           reply	other threads:[~2005-11-18 13:45 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <200511151119.jAFBJvY23022@zamenhof.cs.utwente.nl>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32d987d50511180545h5101f3dat13d64a95b737d16a@mail.gmail.com \
    --to=benavento@gmail.com \
    --cc=9fans@cse.psu.edu \
    --cc=Axel.Belinfante@cs.utwente.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).