The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: KDE -- you are the best!
by Paul Koshevoy on Saturday 14/Oct/2006, @16:07
|
Klik seems about right -- but until the support for klik packages is integrated at the core of KDE it's still useless to me, because I can't count on every possible user having klik installed.
Honestly, klik seems like an overkill -- a simple agreed upon .app directory layout with support for Info.plist and resources (icons, etc..) would have been enough. I mean, what's the server for? Why is mounting required?
Is it possible to specify supported file/document types that a particular application package can handle? Is it possible include icons, templates, localization files and other resources into a klik package, and will they be automatically recognized by KDE? Can I add a klik package to the KDE applications menu?
That's the sort of integration that is necessary.
Paul.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by AC on Saturday 14/Oct/2006, @16:23
|
what's the server for?
is not really neccesary, just nice to have a lot of software available in one click.
Why is mounting required?
that's how MacOS X does it.
Klik is one package in one file.
To run the software, the file is mounted just like an iso-image, making it's content available.
Is it possible to specify supported file/document types that a particular application package can handle?
yes
Is it possible include icons, templates, localization files and other resources into a klik package, and will they be automatically recognized by KDE?
yes
Can I add a klik package to the KDE applications menu?
yes
in my experience, the klik packages were automagicly added to the kde menu, no additional configuration required..
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by Paul Koshevoy on Saturday 14/Oct/2006, @16:50
|
Cool, although I think you are mistaken about OSX mounting the .app bundles. It can mount .dmg images that may contain bundles inside of them, but the .app directories are not mounted. All it does is look inside the .app directory in predefined places for the info file, the executable, the frameworks and resources.
BTW, if KDE4 will be ported to OSX natively then support for .app bundles will be necessary anyway in order to be able to launch native OSX applications from konqueror.
Paul.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by superstoned on Sunday 15/Oct/2006, @03:49
|
OSX does mount .app bundles, you just don't notice it. it's the way they work. you do know osx generally doesn't 'install' apps like linux tools like rpm normally do, isn't it? well, the only other doable way is mounting it like klik does...
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by AC on Sunday 15/Oct/2006, @05:13
|
>>OSX does mount .app bundles, you just don't notice it.
Thats a huge difference between linux and macos: linux shows everything it does, while macos hides it all.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by Paul Koshevoy on Sunday 15/Oct/2006, @10:05
|
No it doesn't mount them.
Look, I am running a Terminal.app on my iMac right now, building Qt 4.2.0:
apple:~ paul$ ps auxwww | grep Termin
paul 230 0.3 2.3 128912 12260 ?? S 9:23AM 1:48.03 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_3407873
And here is the output of the mount command:
apple:~ paul$ mount
/dev/disk0s5 on / (local, journaled)
devfs on /dev (local)
fdesc on /dev (union)
<volfs> on /.vol
automount -nsl [118] on /Network (automounted)
automount -fstab [129] on /automount/Servers (automounted)
automount -static [129] on /automount/static (automounted)
homestead:/home on /private/var/automount/home (automounted)
homestead:/VCR on /private/var/automount/nfs/VCR (automounted)
homestead:/usr/local/unsafe on /private/var/automount/nfs/unsafe (automounted)
As you can see the Terminal.app is not mounted
Paul
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by AC on Sunday 15/Oct/2006, @17:41
|
Are your sure?
Read this:
http://www.stepwise.com/Articles/Technical/2001-03-29.01.html
"2. Next, you want to mount the image. However you do not want the system to be notified of the mount, so you must used the -nomount command."
As said earlier, MacOS hides the mounting of the image.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by Paul Koshevoy on Sunday 15/Oct/2006, @19:56
|
You are confusing a .dmg file with a .app bundle. A .dmg file is a disk image (like a .iso), it can contain anything, not necesssarily a .app bundle. You can mount a .dmg image, but the applications that ship with OSX are not installed as .dmg images, but as straight .app bundles.
Paul.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by Corbin on Monday 16/Oct/2006, @07:13
|
A single image file (the klik image) is generally far easier to move around than a directory with bunches of files in it. With klik you would only have to move a single file around, but with a .app folder there isn't a practical way to distribute it over http or other file transfer protocols without putting it into an image file (say a .dmg). Since the mounting/unmounting of klik images is done automagically by the klik association it really is totally transparent to the user, though hopefully in the future FUSE will remove the need to even edit the fstab file.
|
[
Reply To This | View ]
|
Re: KDE -- you are the best!
by Paul Koshevoy on Sunday 15/Oct/2006, @20:01
|
Also, OSX does show mounted .dmg files which you can see for yourself using the mount command any time you have double clicked on a .dmg file.
Paul.
|
[
Reply To This | View ]
|
klik, .dmg and .app
by AC on Monday 16/Oct/2006, @09:35
|
Paul,
the difference between .app and .dmg is minimal. Basically, .app ("application directory") is an extracted .dmg (or .dmg is a compressed archive of an .app directory structure).
As such, .app and its subdir structure does not need mounting (in this point you are absolutely right), it just needs to be there. A .dmg needs mounting precisely, because mounting lets it look like it is part of the complete file directory system (instead of a single file, which it is if un-mounted.)
A klik bundle can easily be extracted, and then it simply becomes an .app-lik sub-directory structure, from where you can run the application without mounting.
More info about klik here: http://klik.atekon.de/wiki/index.php/User's_FAQ
A question to the KDE community: what happened to previous promises to integrate a klik-friendly client structure into KDE4's core? Ya know, things like support for automatic integration of klik app images into the K menu (and their removal if a .cmg is deleted), display of app-specific icons that are glue-ed to the klik .cmg file, and more goodies?
|
[
Reply To This | View ]
|
Re: klik, .dmg and .app
by anon y mouse on Monday 16/Oct/2006, @15:03
|
In the time honoured fashion of FOSS - what's stopping ya? You want it done - go to it!
|
[
Reply To This | View ]
|
CFBundles and NSBundles are folders
by kram32768 on Wednesday 03/Jan/2007, @20:17
|
.app bundles are just folders in OS X
I have made them by hand before, so I know. just like any other CFBundle object (carbon) or NSBundle object (cocoa) they are just a series of folders, and I think linux could learn from apple on mach-o bundles. if kde used them, no more need for that huge /usr/share/apps folder of the /usr/share/applnk folder either. here is the format of a CFBundle:
Konqueror.App
Contents
Info.plist
MacOS
konqueror
Resources
browser-window.nib
toolbar-customizer-window.nib
...
my point, something like that does not even need to be mounted, it can still be installed the linux way, and anywhere you want it, usually in the /Applications folder though. If anything got mounted other than the .dmg, then you could never unmount the .dmg without unmounting what the .dmg is using, same rule applies to Mac OS classic (9.2.2 and below). another thing, anything that is supermounted, appears on the desktop, btw, darwin tends to supermount all volumes in the /Volumes folder, which isn't that different than HAL on linux 2.6 is doing. I plan on doing research on the apple interface builder format (.nib files) and write knib which can make, modify, and view nib files, also if you havent known yet, the code for CFBundle is in CoreFoundation Lite, thus we can use bundles on linux, I plan to learn objective c and make a cocoa style wrapper for kde sometime that wraps around CF-Lite, btw, I am ready to make a slackware 11 packageand an rpm and a deb, I have the compatibility headers too, the ones that are needed to build cf-lite, and I have a successful build of cf-299.33, even better than on apple's site, I not only have libCoreFoundation.a, but also libCoreFoundation_debug.a and libCoreFoundation_profile.a too, and the headers are all set up, even including AssertMacros.h, AvailabilityMacros.h, and TargetConditionals.h, from darwin 8.0, intel. yes, CF built nicely. I have even tested it on gentoo, in order to link with it, you need to add these -L/usr/include/CoreFoundation -L/usr/include -I/usr/include/CoreFoundation -I/usr/include -lpthread -lm -lCoreFoundation to gcc while building a program or library linked against libCoreFoundation, note: these instructions are for working with my build only, the apple build stores the stuff in /tmp/CoreFoundation.dst/usr/local instead of /usr, so make adjustments accordingly if you choose to build it yourself.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
