| |||||||||||||
Not The Unix Way?Not The Unix Way?Posted Jul 6, 2007 9:14 UTC (Fri) by Richard_J_Neill (subscriber, #23093)Parent article: Mandriva adds a semantic layer to the KDE 4 desktop
Maybe I'm misunderstanding, but this seems to be a violation of "The Unix Way" i.e. lots of little tools, each good at one thing, *without* complex interdependencies, and where it is easy to change the permutations. Another principle is that (almost) every GUI application has a CLI application at its heart.
An example of this: many photo applications (eg digikam) insist on "importing photos" into their own structures, rather than allowing the user to stick with his own choice of filesystem layout. Will other programs (such as gthumb, which don't impose this) become "second class citizens"? Is there actually a risk of KDE becoming increasingly "incompatible" with the shell?
In particular, I hope KDE doesn't become monolithic: many parts of KDE are excellent (eg kwin,klipper,kdeprint), but there are some bits I prefer to avoid (eg arts,dcop). There are also some excellent KDE apps (eg konsole,konqueror,amarok), but these stand on their own (for instance, konqueror works much better with kmplayer than with kaffeine; amarok is great for playing music, but not for managing it.)
(Log in to post comments)
Not The Unix Way? Posted Jul 6, 2007 9:58 UTC (Fri) by MathFox (guest, #6104) [Link] The idea behind the "semantic layer" is that there is one interface to store metadata behind objects. If you've made pictures and mp3 recordings of your daughter singing a song, you can link the different media to the event. The event can be part of "July 2007" and "daughter"
IMO it is "the UNIX way" in a sense that small and simple programs (like gthumb) become more powerful because they can make better use of the relations layer, not imposing a structure on their own.
Not The Unix Way? Posted Jul 6, 2007 11:40 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link] That makes sense - providing that it isn't a KDE-specific thing. I'd have expected it to be more on the lines of something freedesktop.org would provide. We'd also need a good CLI application to match.
However, I still think that metadata belongs *in* the files, not in a database. So if I move/copy a file, the metadata should stay embedded in it.
Not The Unix Way? Posted Jul 6, 2007 12:33 UTC (Fri) by MathFox (guest, #6104) [Link] If the "semantic interface" is simple enough to use in KDE-C++, it shouldn't be too hard to create a GNOME-C adapter for it.
About metadata belonging *in* the files: In what file do you store a relation between files? Furthermore there is the "minor" problem that many file formats don't support metadata of the format required for the semantic layer, it would require tools that can handle "all file formats". And performing a complete file system scan to collect all metadata is a costly operation. I would think about a database that identifies files by hashes of the file contents; such a scheme could work with "off line storage" too.
Not The Unix Way? Posted Jul 7, 2007 0:33 UTC (Sat) by Richard_J_Neill (subscriber, #23093) [Link] You're right about the problems. But I think that the semantic database has got to cope gracefully with editing/renaming/moving of the files, even when they are moved off the computer entirely, and the database loses sync.
Because this is such a hard problem to solve, I'd prefer to do without the semantic stuff, rather than sacrifice the ability to use the unix-shell commands (or risk losing the integrity of the database). [inotify may help a bit here].
Lastly, files which don't have metadata are usually simpler formats such as .txt and emails. So the problem isn't that bad. Anyway, we have grep, and locate (so what more could one ask for?!)
dcop Posted Jul 6, 2007 11:39 UTC (Fri) by rfunk (subscriber, #4054) [Link] Funny you mention disliking dcop. That's a big part of what makes KDEexceedingly scriptable and generally adds a lot of command-line power. Dig into some amarok extension scripts for some examples.
arts, of course, is scheduled to go away in KDE 4; nobody likes it.
dcop Posted Jul 6, 2007 12:43 UTC (Fri) by tzafrir (subscriber, #11501) [Link] Adds command-line power: yes. But only when the GUI is up.
dcop Posted Jul 6, 2007 15:16 UTC (Fri) by rfunk (subscriber, #4054) [Link] Er, when the GUI isn't up then KDE and the remote control that dcop provides areirrelevant.
.... As long as the applications store their data in a way that it can be retrieved without
dcop Posted Jul 6, 2007 15:40 UTC (Fri) by tzafrir (subscriber, #11501) [Link] Remote control of programs is a means to an end. What I need is to be able to do useful things with the data.
Consider an example from the beginning of the thread: images collection of digikam. Or the mail folders of kmail. Or your addressbook.
I'm not saying that the interface that dcop is not highly useful. I do say that it still doesn't help if the GUI itself isn't up.
dcop Posted Jul 6, 2007 12:57 UTC (Fri) by Los__D (guest, #15263) [Link] Isn't DBUS DCOP++, but without being desktop dependant?
dcop Posted Jul 7, 2007 0:24 UTC (Sat) by Richard_J_Neill (subscriber, #23093) [Link] The reason I dislike dcop is that so few of the controls I want are actually implemented! That isn't always true; some applications provide everything one could want (eg amarok, klipper). For example this is a very useful shell script:
#!/bin/bash
However, the dcop commands that I really want to have are usually missing. For example, every option in kcontrol should be dcop-enabled. That way, I could write a shell script to automate KDE configuration every time I set up a new system. (copying ~/.kde brings too much cruft with it).
P.S. Amarok doesn't need dcop
dcop Posted Jul 7, 2007 19:52 UTC (Sat) by tzafrir (subscriber, #11501) [Link] > hat way, I could write a shell script to automate KDE configuration> every time I set up a new system. (copying ~/.kde brings too much > cruft with it).
Again, dcop needs the server to be up in order for it to be configured. You'd have ot run KDE first. Which is unlike what you can do with manipulation of configuration files.
(At least you can manipulate configuration files. With gnome you depend on gconf to be up even for mere configuration)
dcop Posted Jul 8, 2007 14:53 UTC (Sun) by tmg (guest, #46149) [Link] >That way, I could write a shell script to automate KDE configuration>every time I set up a new system. (copying ~/.kde brings too much cruft >with it). You may want to try kwriteconfig / kreadconfig, which seem to even work without KDE running. These commands probably do exactly what you want.
|
|||||||||||||