Help to make klik better

klik could be even better if KDE would support AppDirs - folders that that launch the application when the folder is clicked in Konqueror. I have reported this wish to the KDE bugtracking system, and in order to get the attention of the KDE developers it would be nice if you could also vote for this feature. To do so, please go to http://bugs.kde.org/show_bug.cgi?id=81772 , click on "Vote" and give it (bug # 81772) 20 points. You have to register with the KDE bug tracking system in order to vote.

Your vote makes KDE and klik even more powerful. Thanks!

Apple describes it this way:

"A bundle is basically a directory that contains an application. Unlike normal folders, however, it appears to the user like an ordinary file. The user can double-click a bundle, and the application will launch. Since the bundle is really a directory, it can contain all the support files that are needed for the application."

http://developer.apple.com/documenta...section_2.html

It would be great to have the functionality described in KDE, so please vote.

No!

Don't vote for this!
A directory is a directory and nothing else.

What a crude idea!

Must come from somebody, who has a monopol, and thinks, a html-file is a ms-html-file, and should allways and only be opened with IE.

What, if the folder is clicked by firefox, mozilla, opera, midnight-commander?
What, if you put a file there by accident?

You cannot adopt the ideas of an apple for linux, because the whole system-architecture wasn't meant for that on linux, but was on the apple.

And mixing the concept in will produce confusion, misbehaving and bugs.

Go, buy an apple, and be happy.

Quote:

---

Originally Posted by user unknown

What, if the folder is clicked by firefox, mozilla, opera, midnight-commander? What, if you put a file there by accident?

---

Simply nothing (just as it is now), especially nothing bad! :)

Quote:

---

Originally Posted by user unknown

You cannot adopt the ideas of an apple for linux, because the whole system-architecture wasn't meant for that on linux, but was on the apple.

---

Apple has many good philosophies that can be taken to other systems as well. (And, in fact, always were. I talked to the inventor of the Mac GUI recently and in fact most of the KDE concepts indirectly come from Apple...)

The last time I used a Mac is more than 10 years ago, and I never owned a Mac myself.
So I don't know to much of its inner technics.

When resources (?) are installed with the application in a folder, how are multiple users handled?
Linux is per se a multi-user system, while MacOs isn't.

What's about shared resources, like libxml, libjpeg, ...?
Is /dev/modem a resource too?

Will the data be stored in the same folder?
Can the technic handle multiple versions like 3.14-stable, 4.0-beta?

When I run a program, I call its name - no need for browsing and clicking.
A normal linux-distro comes with over 2000 executables - browsing for them would be annoying, if they where located in 2000 different folders.

With 3 characters from a-z you may address more than 17.000 apps on the commandline.
Uppercase-letters and numbers are allowed, but seldomly used (SciTe, txt2pho, fish4all, ...), therefore I dont calculate with 62 different characters.

For often used programs, I have an easy to use context-menu, which opens on right-click on a free place at the desktop (which is allways there, because I use tabs for the application-frame).
The menu contains my Top-10 apps, which are - to be accurate - 13, including a submenu with all the seldom used stuff, 'configure' and 'exit'.
To change it, I call my editor and open ~/.fluxbox/menu, edit, save, call 'configure-reread config' and - voila. (No restart/ reboot) neccessary.

A good application should have a menu for recently used files, and as a nice, sophisticated extension, kate for instance, offers the possibility to add folders to its own list of preferred directories to search for files to open.

I never use konqueror to start an application.

Sorry, this post is slightly OT, since I defend the general idea of AppDirs here.

user unknown, please look at the general architecture of klik on http://klik.berlios.de/architecture/ - klik does all of that today already. The only thing I propose is that KDE should have a way to start the wrapper automatically when the AppDir is clicked.

Quote:

---

Originally Posted by user unknown

The last time I used a Mac is more than 10 years ago, and I never owned a Mac myself. So I don't know to much of its inner technics.

---

A lot has changed since then, the Mac OS is now Unix.

Quote:

---

Originally Posted by user unknown

When resources (?) are installed with the application in a folder, how are multiple users handled?

---

AppDirs allow users to install apps in userspace. But you could of course also install them to /opt, making them available system-wide.

Quote:

---

Originally Posted by user unknown

What's about shared resources, like libxml, libjpeg, ...?

---

The common ones stay where they are. The less common ones go into the AppDir of the application that needs them. That way each app can have its own matching version of libraries without the danger of messing the whole system. /dev/modem is a systemwide thing, but libtiniweeny-0.6.so not (since not many apps use it).

Quote:

---

Originally Posted by user unknown

Will the data be stored in the same folder?

---

The data that belongs to the app: yes (such as help pages, icons etc), userdata: no (goes still to ~)

Quote:

---

Originally Posted by user unknown

Can the technic handle multiple versions like 3.14-stable, 4.0-beta?

---

Yes!

Quote:

---

Originally Posted by user unknown

When I run a program, I call its name - no need for browsing and clicking.

---

You could still do this, but you are not the average point-and-klik user.

Quote:

---

Originally Posted by user unknown

I never use konqueror to start an application.

---

You don't have to, but I would like to. As a fluxbox user, you are completely unaffected by the progresses in KDE ;)

Quote:

---

Originally Posted by "probono"
user unknown, please look at the general architecture of klik
(...)
AppDirs allow users to install apps in userspace. But you could of course also install them to /opt, making them available system-wide.
(...)
The common ones [resources, uu

stay where they are. The less common ones go into the AppDir of the application that needs them. That way each app can have its own matching version of libraries without the danger of messing the whole system.
(...)
You could still do this [start from CLI, uu], but you are not the average point-and-klik user.
(...)
You don't have to, but I would like to. As a fluxbox user, you are completely unaffected by the progresses in KDE ;)

---

I'm just testing it.
Beeing a crude mixture of modern and conservative, and very sceptic, you won't have an easy job to convince me.
But to be fair, I have to give you a try :) , and sometimes I try to fight my prejusdices.

My first installation didn't asked where to install - it just installed to my home-dir.
That's a big minus.
You remember: 2000 apps - that's not tolerable in my home-dir.
A directory /home/unknown/apps/
and every app there would be ok.
But I need to have an overview of my home.

Another observation was, 'Warning: Invalid service: Knoppix/Net/kppp.desktop".
Which didn't seem to be a real problem.

But I was asked to help a few minutes - I answered 'ok' - and then I was told, konqueror would be started.
Firefox started and told me 'already running - new profile?' - which ended the possibility to help there.

Different libraries are gracefully handled by linux today with version-numbers, and symbolic links:
libfoobar.so-> libfoobar.so.3
libfoobar.so.3-> libfoobar.so.3.4
libfoobar.so.3.4-> libfoobar.so.3.4.7
libfoobar.so.3.4.7
libfoobar.so.2.9.16 (needed for an old application)
- no dll-hell like windows.

How do I start klik? I thought of 'klik' but no 'klik' in path...

Yes - I'm not the average klik-user, but perhaps the average linux-user?

And your solution only works with kde?
That's one of these annoyances.

I installed DBDesigner with klik, and it seemed to work.
Trying to start it, it shows 'Symbolic links exist. Starting dbdesigner.'.
Then silent exit.
(That's the wrong way on Linux/ Unix! Make it just the opposite! Silent, when ok (Symlink exist) and noisy, on errors.
See the OpenBook from Eric S. Raymond: The Art of Unix Programing: 'Silence is golden' here: http://www.catb.org/~esr/writings/ta...l/ch11s09.html

Of course I found the DBD4.log, here is what it says:
Runtime error 234 at 0805DECF

I get the same result when starting from CLI - so the cryptic error-message is fault of the DBDesigner4 - developer, not kliks one.

If I had installed from source, I could investigate on that error, where it comes from, and so on...

I found out, that in the lib-dir, a lot of libraries are installed, which are already installed in /usr/lib etc.
That's annoying.
You waste internet band-width, harddrive-space, and a lot of time.
An updated library has to be put to every user, and every app.
You said 'the common ones stay where they are' - (resources, libs?).
That's a real big minus. Why don't you ship new computers for every app? :)

Another issue: Your script (dbdstart) contains a lot of backtics.
They're deprecated.
Instead of

Code:

---

foo=`echo "$0"  | sed '....'`
#use
foo=$(echo "$0"  | sed '....'')

---

which is
a) better readable
b) nestable

Another small:
The directories are called 'Data, Doc, Linuxlib, ...'
That's MS-style, where nobody uses CLI.
Perhaps your users like to use klik and CLI, and then lowercase letters are faster to type.
And the average linuxuser should know, that his machine is running linux - so 'lib' would be enough. (Perhaps again a DBDesigner-issue and not a klik-one.)

But some nice words shouldn't be missed:
The way the installation started from the web seems to be very userfriendly, and looked nice.
I will test a second one.

Well - I installed digikam, and it seems to work (while it seems to be a much smaller application).

Thanks for your insightful comments. I am always interested in how to make thinks newbie-friendly without upsetting power users.

Perhaps I should make one thing clear first: the idea of klik is to make third party software usable on the Knoppix Live-CD, which is read-only. So everything must run in userland, without root privileges, without write access outside of ~, and single-user. Also, the majority of software comes preinstalled with the Live-CD. klik just adds a few apps that are not on the CD.

Quote:

---

Originally Posted by user unknown

My first installation didn't asked where to install - it just installed to my home-dir.

---

That is what makes sense on Knoppix, but you can move AppDirs anywhere (at least in my latest version of the wrapper). It would be absolutely easy to ask the user where to put the AppDir first. Probably I will include that in the next klik version.

Quote:

---

Originally Posted by user unknown

Firefox started and told me 'already running - new profile?' - which ended the possibility to help there.

---

klik is at the moment a KDE thing. Please set up Konqueror as your default browser. The idea of "profiles" is purely a Firefox thing.

Quote:

---

Originally Posted by user unknown

How do I start klik? I thought of 'klik' but no 'klik' in path...

---

By clicking on a klik link in Konqueror. (Again, I develop purely for KDE, but if you want to, you can write a protocol handler for Firefox, too. No problem)

Quote:

---

Originally Posted by user unknown

I installed DBDesigner with klik

---

The DBDesigner issues you describe are not klik-related.

Quote:

---

Originally Posted by user unknown

I found out, that in the lib-dir, a lot of libraries are installed, which are already installed in /usr/lib etc.
That's annoying. You waste internet band-width, harddrive-space, and a lot of time.

---

Well... You can copy the DBDesigner folder over to another machine... and it will run! But I agree, there should be some universally agreed standard on which libraries are the "core system" (and expected on any machine) and which ones are "special" (and must come with the app that needs them). Another possible solution is serverside-apt, which I am developing. It will check which libraries are installed on your machine and download only the missing ones.

Quote:

---

Originally Posted by user unknown

An updated library has to be put to every user, and every app.

---

No, only apps that need the updated library will have to come with it. Just like the Mac. I don't want that my running core system gets touched (in fact, with Live-CD it can't) just because one app needs a newer version of a lib. The core system should never be touched just to make an app run.

Quote:

---

Originally Posted by user unknown

Why don't you ship new computers for every app? :)

---

That would ensure everything runs flawless! :) (Indeed, I would love to have a virtual machine for each app so that an app behaves deterministic and can't mess with the rest if the system. But that's really overkill then...)

Quote:

---

Originally Posted by user unknown

Another issue: Your script (dbdstart) contains a lot of backtics.

---

That's DBDesigner's script, not mine. But thanks for the info, I also used backticks.

Quote:

---

Originally Posted by user unknown

The directories are called 'Data, Doc, Linuxlib, ...' That's MS-style, where nobody uses CLI.

---

again, DBDesigner's. Install quanta, for example, and you will see /usr,... etc.

Well - developing for live-cd users is a special issue - I see.

I only fear, that the people will try to use it afterwards, when switched to a hd-install, and claim for the same comfort.
As newbies they will not see the price they have to pay for this 'every app its own lib, every user his own app' so easy.
And after using it a year, they're addicted to this policy.

For non-DSL-surfer it might be an expensive experience too.

But for those, who like it that way, it's a good work I guess, and I hope my backtic-hint may compensate you for my stubbornness. :)

For a developer, what do you have to do to make your work klik-able?

Quote:

---

Originally Posted by user unknown

For a developer, what do you have to do to make your work klik-able?

---

Ideally: Don't use absolute paths (like /opt) but variables (like $KDEDIRS) in your software and get it packaged into the debian repository. Then it should be klik-able without further manual intervention (serverside-apt is supposed to do all the magic, see http://www.knoppix.net/forum/viewtopic.php?t=11160).

Practically: Write a klik recipe manually that thells the klik client how to download, binary-patch, install and run your software.

Well - I've never been a friend of absolute pathnames.
But need to find out how to build a debian-package although.

And prepare to tell people in forums, why they are low on memory by running 4 applications, while the can run 10 on windows.

If you need libCoolFont.so.4.7, can't you first look at the standard-places for it?
And wouldn't it be better, to have a structure:

Code:

---

/home/frank/klik/lib/libCoolFont.so.4.7
/home/frank/klik/lib/libCoolFont.so.4.12
/home/frank/klik/bin/yetAnotherEditor (using ../lib/libCoolFont.so.4.7)
/home/frank/klik/bin/yetAnotherEmailClient (using ../lib/libCoolFont.so.4.7)
/home/frank/klik/bin/yetAnotherIRCclient (using ../lib/libCoolFont.so.4.12)
...

---

This would still allow YoopieDoopie Frank to install Software without RootPriviliges and share the libraries.

Drawbacks:
- one more directory (lib).
- how to know, that a library isn't used at all (how do we know today in /usr/local/lib?)

Quote:

---

Originally Posted by probono

But I agree, there should be some universally agreed standard on which libraries are the "core system" (and expected on any machine) and which ones are "special" (and must come with the app that needs them). Another possible solution is serverside-apt, which I am developing. It will check which libraries are installed on your machine and download only the missing ones.

---

Would it be possible to let the user decide:

if he want a shared directory for the library and/or apps?
if he want to share library and/or apps with other users(to save hd space with multiple user system)?
if he want each apps to have its own set of library to be sure that he can copy and use the app-dir anywhere?
(insert your ideas here)...

it would be very cool to have a knoppix liveCD made especially for klik, it would ease the creation of a (klik standard) for that system witch would enable the creation of ready to use cmg file... After that, i think it would be possible to set a user menu that could be updated automatically(from internet). A click on an item would verify if the application is already there. Then it would automatically download the apps (if its not already installed) with a nice progress bar and a start button once the app is downloaded. Maybe the cmg file could be downloaded with bittorrent? ;)

Well i'm not a developper but i would be glad to help if i can.

Swe3tDave

Quote:

---

Originally Posted by swe3tdave

Quote:

---

Originally Posted by probono

But I agree, there should be some universally agreed standard on which libraries are the "core system" (and expected on any machine) and which ones are "special" (and must come with the app that needs them). Another possible solution is serverside-apt, which I am developing. It will check which libraries are installed on your machine and download only the missing ones.

---

Would it be possible to let the user decide:

if he want a shared directory for the library and/or apps?
if he want to share library and/or apps with other users(to save hd space with multiple user system)?
if he want each apps to have its own set of library to be sure that he can copy and use the app-dir anywhere?
(insert your ideas here)...

---

Serverside apt exists now, and works roughly as follows:
You tell the server what you are running
If it is a supported system it knows what you have installed and only installs non-shared components.
If you are on an unsupported system it assumes you have the common packages from the supported systems (at least the lowest version in any of them).

One of the aims of klik would certainly be to NOT have the user being hassled with questions about libraries, though it may be possble to have some optional klik configuration on the machine to do the sorts of things you seem to be describing, having the cmg files built in a globally shared location and perhaps other such features (such as building the cmg to expect only the common packages so it should be portable across supported distros).

Quote:

---

Originally Posted by swe3tdave

it would be very cool to have a knoppix liveCD made especially for klik, it would ease the creation of a (klik standard) for that system witch would enable the creation of ready to use cmg file... After that, i think it would be possible to set a user menu that could be updated automatically(from internet). A click on an item would verify if the application is already there. Then it would automatically download the apps (if its not already installed) with a nice progress bar and a start button once the app is downloaded. Maybe the cmg file could be downloaded with bittorrent? ;)

---

I've been considering trying to build a liveCD designed for klik, whether I'll ever do it or release it is another matter. Anyone who would care to suggest "essential" features or what they think it should be based on go right ahead! I'll post about either what I've done or what I have in mind when I get other things sorted out.

Your automatic downloading of applications idea is interesting, but have you considered:

A: Just how big a menu it would be, it would have thousands of entries.
B: Just how long the delay could be between clicking on a menu item to run a program and it actually launching (potentially hours)

Also it is worth noting that cmg files are not simply downloaded with klik but are actually built on the client machine so serving them by torrent it impractical. For unusual cmg files (like the openoffice 2 preview) where the cmg file itself is going to be distributed bittorrent may be the answer, but in general serving cmg files by bittorrent could require a lot of server effort to build all the cmg files requested so it can serve them up, and given that klik currently builds from debian-sid the length of time the client would be usefully serving the torrent would probably be quite short (never mind how long users would actually be reserving the torrent for).

I think working on the klik site is the best way to work on this as it is effectively the menu you describe.

Quote:

---

Originally Posted by swe3tdave

Well i'm not a developper but i would be glad to help if i can.

---

Ideas, testing, documentation, helping others with their problems ... I'm sure you can help!

Quote:

---

Originally Posted by bfree

One of the aims of klik would certainly be to NOT have the user being hassled with questions about libraries, though it may be possble to have some optional klik configuration on the machine to do the sorts of things you seem to be describing, having the cmg files built in a globally shared location and perhaps other such features (such as building the cmg to expect only the common packages so it should be portable across supported distros).

---

i agree keep it simple but dont forget the power users... :wink:

Quote:

---

Originally Posted by bfree

I've been considering trying to build a liveCD designed for klik, whether I'll ever do it or release it is another matter. Anyone who would care to suggest "essential" features or what they think it should be based on go right ahead! I'll post about either what I've done or what I have in mind when I get other things sorted out.

---

i think that this should be the appropriate essential features:

Quote:

---

Originally Posted by probono

Quote:

---

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.

---

at least its a good start.. :) Maybe you could add OpenOffice, if there is enough space left... :lol:

Swe3tDave

bfree wrote:

Quote:

---

I've been considering trying to build a liveCD designed for klik, whether I'll ever do it or release it is another matter. Anyone who would care to suggest "essential" features or what they think it should be based on go right ahead! I'll post about either what I've done or what I have in mind when I get other things sorted out.

---

Sounds like a great idea...

Not certain that I can suggest "essential" features -- I'm 'peculiarly' reliant on LiveCd + PersistentHome & ConfigSave (knoppix.img, knoppix.sh & configs.tbz) -- I run exclusively from CD, NO Hard-Drive -- and so, my "essentials" will be different from the 'normal' user's.

With that in mind, here's what I suggest:

1) Make the entire design suitable for use on "diskless" systems -- enabling the addition of programs to USB storage devices (in addition to hard drives).

2) Include only the major programs used by most puter users...NOT heavily aimed at EITHER gamers or wordprocessors/spreadsheeters or music-lovers or video/photo types.

For the moment, that's it...One positive druther and one negative...Keep it lean so that users shorter on RAM can operate fairly quickly from OS-on-CD; and so that users on dial-up can add a few (lite) programs without extreme download times.

Thanks for your interest in creating such a CD !

(And, take KlikIt!'s combo with klik into account...)