-
Senior Member
registered user
make most debian software klik-able (alpha)
Hi all,
I'm working on serverside-apt, the goal of which is to auto-generate klik recipes on-the-fly so that one day, all software that is in debian will be klik-installable without further manual intervention.
In principle, it already can be done, which I am showing below. In fact, most debian KDE apps work right now! In reality yet, there are still many obstacles to be solved.
You can try what already works:
klik://kino - video editor
klik://bidwatcher - eBay sniper
klik://sim - ICQ client
klik://kbabel - translation
klik://gkrellm - system monitor
klik://nmapfe - nmap frontend
klik://keduca
klik://kmerlin
klik://kmoon
klik://bibletime
klik://kaboodle - multimedia player
klik://korn - E-Mail monitor
and even klik://trywhateveryouwant
Remember, the klik recipes for these installations are generated "on the fly" from the debian repository with serverside-apt. All of this is completely unsupported and just to show what is already possible.
-
Senior Member
registered user
Congratulations probono!
This is a giant advance for the live boot CD paradigm.
It combines an incorruptible base operating system
(except for the dog chewing on the CD)
with flexibility to easily add programs.
It may change the "ideal" content of the KNOPPIX CD to
focus more on libraries and the basic support programs,
but free up space since applications can be easily
added.
Can complex programs really be added on the fly?
Now for my 2 cents worth
To invoke a klik shell program one types:
~/app-name/wrapper app-name
Could you change "wrapper" to "go"
and teach wrapper how to find the argument app-name?
This trick should allow a script to get the name of its directory:
Code:
echo -n "AppName=\"`pwd`\"">&/var/tmp/AppName
. /var/tmp/AppName
AppName=${AppName##/*/}
Best Wishes,
paradocs
-
Senior Member
registered user
Originally Posted by
paradocs
Congratulations probono!
It combines an incorruptible base operating system
(except for the dog chewing on the CD)
with flexibility to easily add programs.
Exactly that is my intention. A rock solid, unbreakable "core system" that can be userland-extended with appications as needed without the risk of ever breaking anything. Personally, I have been using "poor man's intstall" of Knoppix as my main and single operating system for nearly one year now. I never had any problems with broken packages, forced upgrades and the like.
Originally Posted by
paradocs
It may change the "ideal" content of the KNOPPIX CD to
focus more on libraries and the basic support programs,
but free up space since applications can be easily
added.
Right. I think absolutely the same. The "core system" should be "stable" in terms of what packages it contains. In my opinion, it should include all the "low-level stuff" that is used in common by many applications, plus the latest KDE. It should also contain the larger "frameworks" (such as the LaTeX environment). Everything that is used by just a few applications instead could be klik'd.
Originally Posted by
paradocs
Can complex programs really be added on the fly?
In principle, anything (but kernel stuff) can. It really does not depend on the complexity of an app, but on how well designed it is. The least problematic are KDE apps. Nearly all of these can be klik'd without changes because they do not contain hard-coded paths. Instead, KDE uses variables such as "KDEDIRS", which can be easily set by the klik wrapper. Unfortunately, many other apps do include hard-coded paths, for example they expect a certain library in /usr/lib. The trick klik does here is to patch the binary to use ./../lib instead. This is a rather crude hack, but it does work for many apps. Some "frameworks" such as LaTeX are so reliant on hard-coded paths that I didn't get them to be klik-able yet. But in theory, there are no limitations.
What I really dream of: Convincing the debian developers not to accept hard-coded paths into the distribution anymore but I guess that will be a tough one...
Originally Posted by
paradocs
To invoke a klik shell program one types:
~/app-name/wrapper app-name
I know that is not ideal. The main problem is that many packages contain more than just one command line executable, and often the main executable does not even have the same name as the package (e. g. everything with "-utils" in its name). Please let me know if you find a solution for this.
klik right now is usable mainly for graphical apps. The typical command line user most likely knows how to use shell scripts in order t achieve his goals, or won't probably use klik in the first place. If he wants a klik'd command line app to be really "integrated", he will change /etc/profile or ~/.bashrc to include the PATH, LD_LIBRARY_PATH, MANPATH, etc. -> but this is not considered "professional" by some.
Since klik is KDE-focused, why don't we just make a menu entry for each command line app and open a konsole window? That's probably what I will do.
-
Junior Member
registered user
This thread may not be the appropriate place for my question (not sure...), but I'll ask anyway: Is there any possibility this concept can be modified to accomodate Win32 applications, for configuration under WINE? I see you have generic handler code for WINE apps at the software store, but most of the programs I desire are not yet klik-able (such as Exact Audio Copy, or VirtualDub).
- M.
-
Senior Member
registered user
Since there is no centralized repository like debian for Windows software (that I would know of), there is no way to have a genericized klik installer. Instead, a klik recipe has to be written for each individual WINE app. (Ideally, this involves nothing more than the URL of the installer...)
-
Senior Member
registered user
For ExactAudioCopy, you could try grip, klik://grip
For VirtualDub you could try the Linux app avidemux.
I didn't test klik://avidemux yet though.
-
Junior Member
registered user
Originally Posted by
probono
For ExactAudioCopy, you could try grip, klik://grip
For VirtualDub you could try the Linux app avidemux.
I didn't test klik://avidemux yet though.
While the cdparanoia libraries used by grip are good, the Exact Audio Copy verification routines are better... with the added benefit of an EAC user being able to properly calibrate the read/write offsets of their own drive, to ensure no lateral shift of the PCM data relative to the index points. (Grip/cdparanoia offers no such offset calibration, nor does any other Linux-based Audio CD ripping/recording utility to the best of my awareness. But even if the software did offer offset correction, I would still have a higher level of confidence in Exact Audio Copy.)
I need to investigate thhe relative advantages/disadvantages of avidemux. It may well be an acceptable replacement, although I would prefer to run VirtualDub under WINE; on the avidemux links page, the author even points out that VirtualDub "was the modele after which avidemux was made".
- M.
P.S.: For Exact Audio Copy there are four files which (ideally) should be scripted; two are static links to older versions (ZIP) hosted on the EAC site, and one is a dynamic link to the current release (also ZIP). The exception, and the version to script if only a single choice could be made, is unfortunately no longer accessible from the EAC website but permanently hosted in the ÜberNet.org archive as an EXE installer. Under WINE, Exact Audio Copy may still require an ASPI layer placed in the same directory as EAC.
Recommended installer:
Exact Audio Copy V0.9 beta 4 * recommended for most users (maximum functionality)
Nero ASPI Layer DLL
ZIP:
Exact Audio Copy V0.85 beta 4
Exact Audio Copy V0.9 prebeta 11
Exact Audio Copy V0.95 prebeta 5
-
Senior Member
registered user
Serverside app is not working for me. When I click on the link (like kino for example) it reports that klik is trying to run software on my local drive from an untrusted page. I select follow. It opens up a second tab in konqueror It then says klik is going to install software, and I choose okay. It pauses for a while then opens up a dialogue box that says "error while trying to run kino"
Any suggestions on what I might be doing wrong? I was able to install lphoto all right.
-
Senior Member
registered user
Please try another software. Also, please be aware that serverside-apt is very experimental right now. Does it work for anyone (besides me)?
-
Senior Member
registered user
Same error on all packages noted. I should comment that I'm behind a firewall, but (some of) the other klik packages install for me (i.e. lphoto, guarddog, gdeskcal, etc.)
Looking to hear from others regarding success /failure.
Regards,
~pau1
Similar Threads
-
By ede4e in forum German Forum
Replies: 0
Last Post: 07-31-2005, 09:35 PM
-
Replies: 15
Last Post: 01-20-2005, 02:53 AM
-
By morgan73 in forum Hdd Install / Debian / Apt
Replies: 15
Last Post: 12-16-2004, 08:51 PM
-
Replies: 210
Last Post: 12-04-2004, 03:04 PM
-
By bongski55 in forum Klik
Replies: 2
Last Post: 11-28-2004, 08:52 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
Mitel ShoreTel IP480G VoIP Business Phone w/Handset 630-3481-01 - NIB *NEW*
$99.00
Cisco CP-8821-K9 Wireless IP VoIP Phone WITH BATTERY
$194.99
Grandstream GS-HT802 2 Port Analog Telephone Adapter VoIP Phone & Device, Black
$29.99
AdTran 2nd Gen Total Access 916e 4242916L5 VOIP SIP Gateway
$129.00
GRANDSTREAM HT802 2 PORT FXS ANALOG VOIP PHONE TELEPHONE ADAPTER WORKING *READ
$21.17
New Cisco IP Phone 7911 CP-7911G VoIP PoE Business Desktop Phone -
$20.00
VoIP Entry Phone with Color Video Camera
$450.00
Grandstream GS-HT802 2 Port Analog Telephone Adapter VoIP Phone & Device, Black
$29.00
Yealink W56H HD DECT Expansion Handset for Cordless VoIP Phone
$65.69
GRANDSTREAM WP820 Cordless Wireless VOIP Phone
$49.99