Re: Corel Setup Design Proposal
John Lapeyre <lapeyre@physics.arizona.edu> writes:
> Re: boot floppies and QT2. I guess there is no way around except to
> try to ask the boot floppies authors to include an exception clause. If they
> do not want to do this, it will have to be gtk or the framebuffer gui (I
> know nothing about this last thing).
I'm not going to weigh in on the legal issues. I hope Dave takes it
up with Enrique or whoever technically "owns" dbootstrap.
But I don't think Dave was completely clear on what the Corel
'setup-api' *is* in relation to dbootstrap.
Caveat: this is just my understanding and opinion; it may be
incorrect.
dbootstrap itself is a program which runs after the first boot, and
walks the user through the process of initial configuration (setting
up swap, initializing partitions, etc), most by calling other
programs. dbootstrap has a newt frontend and now a fbdev frontend.
Note that the fbdev frontend is just a *shim* for any 'dialogs' and
interface elements created by dbootstrap while it's walking the user
through.
Corel's formulation is that we should recast the core logic of this
system as a 'setup-api', which is just a library which contains calls
for doing the actual steps (invoke partitioning program, invoke swap
generation, tell me what my next step should be, etc etc). The
setup-api is thus a subset of dbootstrap.
Moreover, all GUI and user / navigational flow through the system is
above the level of the 'setup-api' -- let's call it the 'setup-gui'
layer. This layer could be newt, fbdev, an application using qt, even
gekko based perhaps. Each instance of a 'setup-gui' could itself
behave radically differently from the other.
I can understand why they are taking this approach, and it's a very
common approach to take. It is *not* the approach of 'dbootstrap' at
this point. That is, the 'setup-gui' is not just another shim to the
pre-fabbed flow and dialog/content calls of dbootstrap. As such, it
pretty much requires a gutting and stripping out of dbootstrap.
Again, I have no opinions or statements about the licensing.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: