frontend interaction with ipkg/user prompts (was: Qt Palmtop environment (QPE) 1.3 for Familiar)

I apologize for the crosspost, but since there are developers working
on ipkg frontends in both Familiar and QPE, I thought this should hit
both lists.

Warwick Allison writes:
> On Tuesday 05 June 2001 12:54am, Carl Worth wrote:
> > Instead, please use "ipkg info" and "ipkg status" to get
> > the information you need. These commands currently generate
>
> Oops! Will do.

Great.

> For now, I'll just "yes | ipkg" or "ipkg </dev/null".

Something like that might work. You'd probably be safest with
something like yes that simply emitted carriage-returns. (The default
choice on the config-file prompt is actually No).

> It should be ipkg's job to maintain configuration files between
> upgrades/installs. I'd suggest storing config files twice - once as
> "file.dist.gz" and once as "file". Then ipkg can diff & patch to
> upgrade modified config files.

That might work... but this would add ~130kB in required binaries,
(judging by i386 diff and patch) in addition to double storage for all
configuration files. And the question then becomes what to do if the
patch fails? We'd be right back at the same problem, no?

> Certainly as you say, there needs to be some mechanism to query the
> user, but the less you have to bother the user with weird questions
> the better.

Absolutely! That's why ipkg saves md5sums for all configuration
files. There is no prompt at the time of upgrade unless the user has
modified the config file. I should also eliminate the prompt in the
case that the configuration file has been modified by the user but is
not modified in the package upgrade. That change would make this
prompt rare indeed.

> The Linux/iPAQ is a very narrowly-defined platform,
> unlike arebitrary Linux/x86 which has a huge of possible hardware
> configurations (eg. vdeio, mouse, etc.) and system types (server,
> desktop, router, etc.).

True, but it is still Linux so there is a fair amount of complexity
and configuration choices still exist...

There are currently 3 places that ipkg reads user input:

        1) If packages are pending.

        2) If packages have been requested but are not yet installed,
           (this is still only in my local copy of ipkg).

In each of these two cases the default behavior, (to install the
packages), is very sane. These two cases are hit rarely, (installation
and error recovery). I can either eliminate the prompt or provide a
command-line option to force the default behavior without a prompt.

        3) If the user upgrades a package which has a configuration
           file that the user has modified.

This one is a bit harder to get rid of. I can understand why you would
not want to pop up a terminal, (a window of scrolling messages could
be more disconcerting than a progress bar --- personally I prefer the
window but I may not be typical of the target audience of QPE). But I
can't see a way to eliminate the prompt in all cases, (without wiping
out user configuration). I do plan to come up with a mechanism, (ala
debconf), so that frontends such as qipkg can do all prompting in
their own way, (ie with a dialog box). Would that be acceptable?

Also, the 4th place that prompting can occur is in package-specific
installation scripts. Once we get a debconf-style mechanism in place I
would be comfortable in enforcing the behavior that package scripts
must not assume a tty is available.

> > Let me know if you have any other questions, and keep up the good
> > work!
>
> Does "upgrade" remove old files? It seemed that when I moved a file
> in a later configuration, it stayed at the old place (I actually
> moved a whole directory).

Oops... you caught me. upgrade should do a remove followed by an
install, but it is currently only doing an install.

> > PS. I couldn't find any mechanism for switching between running
> > programs in QPE. I assume this is on the TODO list?
>

> What's "Running"? ;-) We're trying not to make that visible - in
> theory, most apps can terminate at any time (saving their state of
> course). So when you "run" an application, it will just raise the
> current "running" version if there is one, otherwise start one up,
> and in the future, that may also cause an older unused application
> to shut down. But anyway, your options are to use the Q menu to
> open the program, or press button 4 (launch) to raise the launcher.

Yes, I had figured this out and I guessed that this was the model you
were aiming for.

There were two problems that I found:

        1) Some programs don't currently save state (such as the
           terminal). As a workaround, you might consider making the X
           button lower these applications rather than closing
           them. (I don't know how easy that would be in QPE).

        2) I found that several times I would try to "run" an
           application, (which I knew was already running), and it
           wouldn't come to the front, (nothing visible happened at
           all). I don't know if this was application-specific or a
           general problem with raising windows.

Other than those, I found the user-interface to be generally
consistent and intuitive.

-Carl
Received on Tue Jun 05 2001 - 10:45:58 EDT