klik: point-and-klik software store for Knoppix

[aay]

[quote="bfree"]

Is there a real reason (i.e. not a factor of implementation and the youth of the project) why kilk isn't accessable from lynx in run-level 2?

I can perhaps understand why there has been a desire to have klik switch from something like kdialog to xdialog so that it could be used in other WMs, but run-level 2???? There aren't even any text based apps in the klik store yet.

On another note, I'm working on a recepie, but keep getting errors - shows what a bad programer I am. Probono, I'll be contributing some recipies, but probably not till after the weekend. I'm quite busy. Keep up the good work.

[aay]

The list of apps is growing... now I can sync my Pocket PC with Knoppix on my notebook via infrared... But since I have no other hardware to play with, I need your help on making this work more generally.

Cool. I'd like to try your recipe for SynCE-KDE later. I don't have infrared, but hopefully it will work via usb.

[gowator]

It would be nice if it was capable of working with a HDD install.
I guess then you need to know what the user has previously installed and its a whole new ballgame.

[A. Jorge Garcia]

I've tried it with and hdd install with no problem. The only exception was Apache which looks for the CD.

Regards,
AJG

[probono]

I've tried it with and hdd install with no problem. The only exception was Apache which looks for the CD.

Apache should also work with hd installs as long as there is /etc/init.d/apache

[bfree]

From: http://klik.berlios.de/architecture/
<blockquote>I am very interested in your comments about the klik architecture. It is important to get the design right in the first place (before it gets real messy).</blockquote>
What I was thinking was that rather than maintaing your own configuration system or choosing one front-end why not use debconf? It should be expected to be on KNOPPIX and similar systems (i.e. all debian based systems), however minimal, and it provides numerous interfaces (including kde since the end of december in unstable). Whatever default debconf system is chosen by the system will be used, and people creating recipies can save themselves recreating the wheel by embedding the dialog from debconf into klik when it is really required to ask the user questions (not too common for the target area), and perhaps even "stealing" far more from the preinst and postinst scripts! You can gain a lot, and is there any real expense? It just seems like the right tool for the job to me, but that's just my 0.00002c (that's about as much as it's worth)

However, all this being said what's far more important is working with what you have now, which is great for a most of the target users, and in particular getting the system (primarily chefs) to have an up to date Knoppix klik repository! Keep up the good work.

[probono]

What I was thinking was that rather than maintaing your own configuration system or choosing one front-end why not use debconf?

Excellent suggestion, I did't know debconf, but I will look into it. But probably it will not make it into my recipes until the KDE debconf interface is default in Knoppix

perhaps even "stealing" far more from the preinst and postinst scripts!

That was one of my next "todos"
This must be optional however since not all software is installed with .debs.

[Snow]

So is the Point-and-Klik Software Store going to be set up like the Lindows CNR Ware House wher you will go to the PAKSS and find a program and klik on it and the PAK software will install it for you just like on this demo page?

[probono]

So is the Point-and-Klik Software Store going to be set up like the Lindows CNR Ware House wher you will go to the PAKSS and find a program and klik on it

yes.

But how many packages will be there depends on how many "klik recipes" people contribute. I personally don't have the time to make 1001 recipes. klik is community effort driven, unlike Lindows CNR.

Btw, I added some new stuff recently.

[Snow]

Thats fine.
I was just wondering how it was going to work.