Appeal Website Launched

Saturday, 13 August 2005  |  Aseigo

After a few months of quiet activity, the Appeal desktop project has rolled out a new project website that documents what everyone has been up to and discussing. Since the the last public announcement many things have occurred, including another Appeal meeting being held in Germany. The project is looking forward to sharing its experiences and gathering input from the general KDE developer community at aKademy 2005 later this month.

Comments:

Greedy for it - Gerry - 2005-08-13

KDE makes my computer fun to use, but its beauty makes it fun to show my computer to others. Good luck.

Re: Greedy for it - Knut - 2005-08-14

Agreed! These things look very interesting!

Re: Greedy for it - Bert - 2005-08-15

But what about non-KDE applications? Applications like Inkscape, like Evolution. Usually there is not even a Icon theme for them and no bridge to apply it. And real Gnome applications look just ugly because they apply a different colour scheme.

Re: Greedy for it - Morty - 2005-08-15

There are several things you can do to make other applications look better under KDE. With different degree of complexity. The easiest one are the color issue, in the color theme module select the option "Apply colors to non-KDE applications". Most applications will follow this, unless they have hardcoded colors or are broken in other ways. The second step are using the GTK-Qt theme engine, this makes GTK2 programs use Qt/KDE widget styles. This makes dynamically linked GTK programs use the same style as your KDE programs, mainly all Gnome and most GTK applications. The third one with icons are little harder, but doable if the programs follow the fdo.org icon specification. If no one has done it yet, you have to pack it up yourself. But it's perfectly doable and I doubt it is necessary to make new icons as you can use the ones already provided by KDE, they are more numerous than the stock Gnome iconset. You only have to match the correct KDE icons to the Gnome ones.

Re: Greedy for it - aile - 2005-08-16

would be a good project for Appeal to automize this. At least everybody at KDE artist seems to work with inkscape.

Re: Greedy for it - Morty - 2005-08-16

Most of this is already there. The only big missing piece are the KDE icon theme for Gnome, and I think making it are more a job for the Gnome side. Or a colabrating task for the -Look comunity. Really no need to involve Appeal at all, it's even doable before the 3.5 release. As for putting much work into the look and feel of non KDE programs, I don't think it should be a very high priority. As the quality and diversity of KDE applications increases, the need for it becomes smaller and smaller. One of the few remaining areas where the native KDE solution are lagging, are the mentioned inkscape. Hopefully Karbon can get some help from the momentum of Krita.

Re: Greedy for it - aile - 2005-08-16

"KDE native" is funny. Inkscape is a Java application. I do not see a reason why GTK application should not integrate into the KDE desktop, despite Gnome fanatics. Linux/KDE is no QT only environment. I once saw Abiword, Evolution and another app with a Crystal Icon theme and it looked almost like a KDE app. It is important for an "appeal" of KDE that application which users run do not look alien. OpenOffice, inscape etc. are examples. Other issues: how to test the "completeness" of an Icon theme?

Re: Greedy for it - Anonymous - 2005-08-16

> Inkscape is a Java application. Good joke.

Re: Greedy for it - Morty - 2005-08-16

Why you think KDE native is funny I can't really say, but by being native you get all the added benefits of the KDE environment. Not that it's any reason for not making GTK or other apps look good, but I don't see reasons to invest much work in it. When in most cases the native solutions are just as good, or better than the non-native ones. BTW Incscape is a GTK application written in C++ using gtkmm. Making OpenOffice look and behave good with KDE are already in the works and being paid for by Suse. And your second example of Inscape, I already explained you only have to make the icon theme by copying and renaming some already existing icons. Testing the "completeness" of an icon theme are easy, you compare the filenames of the icons in the standard set to the ones in your new icon theme. When you have the same number of icons with the same names, it's complete.

Re: Greedy for it - James Richard Tyrer - 2005-08-16

KDE will use your GNOME menu entries and icons provided that they are in: $KDEDIR/share I have GNOME and KDE installed in different directories so I added links to create a common "share" directory: "/usr/share"

Re: Greedy for it - Morty - 2005-08-16

That's rather what he don't want:-) The thing is he don't want Gnome menu entries and applications to use Gnome icons, he wants them using KDE style icons. Since you obviously have bothered to dig into the icon specs, perhaps you can comment on this. I'll use Inkscape as the example here too. If you have $KDEDIR/share/inkscape, symlink or otherwise. One brute force approach to make it use KDE icons are to replace any icons in that dir with a KDE one. Is that all that's needed?

Re: Greedy for it - James Richard Tyrer - 2005-08-16

Perhaps I didn't quit understand the question -- perhaps I didn't wake up yet. :-) But the information is true and explains how this is integrated. Obviously, having an icon in the menu is preferable to having none. The only way to have different icons is to have different icons. With InkScape, how would you make a Crystal style icon? I have a set of HiColor (includes SVG) if anyone wants them: http://home.earthlink.net/~tyrerj/kde/pics/InkScape-HiColor.tar.bz2 Perhaps making them blue would be sufficient. :-D Actually, for the menu icons you would put the KDE icons with the same name as the GNOME icons in the correct KDE icon directory and these will be used in preference to the GNOME ones. I believe that a CrystalSVG icon theme for GNOME does exist. http://www.crystalgnome.org/icons.htm

Too much noise about vapour ware! - Old time KDE user - 2005-08-13

Please, you are overdoing. KDE, Free Software in general, may have too less marketing. But still it did evolve. Perhaps just because it did not make false promises but tell "Use on your own risk, may not work." And works even better than most proprietary one does. That is where the trust comes from. But you are creating a lot of expectations. Without having things to show. Only plans. I can only strongly advise you to better stay with the traditional attitude, good old understatement. If you want to tell people how fine KDE is show what you have, not what you want to have. Good luck.

Re: Too much noise about vapour ware! - Anonymous - 2005-08-13

> If you want to tell people how fine KDE is show what you have This is not about current KDE but about what is intended to start with KDE 4[.0]. Some people develop a vision for KDE and you complain about vaporware. *sigh*

Re: Too much noise about vapour ware! - jumpy - 2005-08-13

Do you think it's better developing towards a target, aiming a common direction, or going random? Having this creates stronger community, aligned views, better consistancy for the user and highen the average of available software. Long life appeal! :-) P.S: link plasma to plasma.kde.org and say it's a part of the global kde appeal project.

Re: Too much noise about vapour ware! - Aaron J. Seigo - 2005-08-13

> link plasma to plasma.kde.org and say > it's a part of the global kde appeal project. oops, you're right: it was linking to the old address (plasma.bddf.ca) from the appeal site. and i've added a note in the footer of the plasma site as well. thanks for pointing these things out =)

Re: Too much noise about vapour ware! - Aaron J. Seigo - 2005-08-13

Appeal is not a marketing effort, it is a social experiment in consciously engaging in coordinated, open and multidisciplinary development. some people seem to disdain vision, perhaps because they've seen other people abuse it as a cheap marketing gimmick instead of being a means to describe the path one is on to others also involved in the same struggles. some of the things i, and others, are involved in require coordinated efforts between a large number of people across a large number of projects. you don't achieve that by not engaging in conversation about it or by allowing misconceptions and ill communication drive things. if a team would developer around konqueror and clearly state the mission and the direction they have set themselves upon maybe the interface issues would dissolve and be addressed for KDE4. to date, konqueror's interface is a jumble specifically because no global vision was applied to it. see, you are suggesting building skyscrapers without the building crew talking to each other or even having a blueprint by which to follow. you might be able to build a toolshed that way, but not an office building. you are right that we have gotten this far with our current techniques of randomness and secrecy. but we started hitting the ceiling of what that was capable of producing when it comes to integrated desktop environments a year or three ago. we need to break through to the next level and that in part requires doing certain things a bit differently. like having, expressing and engaging in statements of vision. you are correct that at the end of the day one needs to be walking the walk. or are you suggesting that i'm sitting here churning out words only?

Re: Too much noise about vapour ware! - superstoned - 2005-08-13

amen.

Re: Too much noise about vapour ware! - fp26 - 2005-08-14

I think it would be useful to have: 1) a mailing list: kde-appeal@kde.org and http://lists.kde.org/?l=kde-appeal 2) an IRC channel: #kde-appeal Maybe the same for plasma? kde-plasma@kde.org #kde-plasma What you think =) At least a mailing list would avoid the noise made by other unrelated topics... and also kde-core-devel is not accepting input from KDE users =(

Re: Too much noise about vapour ware! - Aaron J. Seigo - 2005-08-14

appeal already has a mailing list and an irc channel. plasma already has a mailing list and an irc channel. huzzah! =)

Only one word... - fp26 - 2005-08-15

WHERE? WHERE? WHERE!!!!!! =P FOR GOD SAKE WHERE!!!!!!!!!!!!!!!!!!!!!!!!!!

Re: Only one word... - Chris Howells - 2005-08-15

Well I followed the links to the web site and clicked "Contact"... http://appeal.kde.org/wiki/Contact

Re: Only one word... - Aaron J. Seigo - 2005-08-15

Plasma's Developer: Get Involved Page is here: http://plasma.kde.org/cms/1086 the Appeal contact page is here: http://appeal.kde.org/wiki/Contact seeing as both mailing lists are pretty well stocked with subscribers, i think they are decently easy to find. see you in #appeal and #plasma =)

Re: Only one word... - fp26 - 2005-08-16

I see but why they are not listed in the main KDE list of KDE mailing list http://lists.kde.org/?w=2

Re: Only one word... - Anonymous - 2005-08-16

That's a list of the lists archived there (btw an external site) and no list of existing lists.

Re: Too much noise about vapour ware! - Christian Parpart - 2005-08-14

But you really read the site? And you still didn't notice those tech-demo or video demos the do provide already? Well, read again. However, I *do* really like the page's design :) And yeah, good luck ;) Christian.

Too bad.... - mikeyd - 2005-08-13

that it doesn't render properly in konqueror. (The "Create an account or log in" text doesn't fit on the border at the top. I know, bugreport it, just thought it slightly amusing that a kde project website doesn't work properly in the kde browser)

Re: Too bad.... - Aaron J. Seigo - 2005-08-13

odd. it works here, but i'm using trunk/ (what will be 3.5) and have decent fonts installed (not sure which if either of those things makes a difference)

Re: Too bad.... - mikeyd - 2005-08-13

My fonts are pretty decent but I'm still on 3.4. It could well be a khtml flaw that has been fixed, the engine's being improved all the time. I also have a rather large resolution if that's likely to make any difference (if the border's a relative size and the font has a point size or something, that could well be it)

Re: Too bad.... - Morty - 2005-08-13

Tried it on both soon to be 3.5 and good old 3.2.3, and they look to behave similar. It's all dependent on font and fontsize. When the fonts get bigger the border does not resize, so I'd guess some peoples default will show up wrong:-) The border at the bottom does behave correctly. Try hitting "Enlarge font" a few time and you'll see.

Tenor licensing, Version control - Vlad C. - 2005-08-13

All I can say is WOW! The website has a treasure trove of ideas, and the fact that you're brainstorming at this stage will surely lead to a unified field for KDE4. I noticed that all the source files for Tenor are licensed LGPL – I think licensing it GPL would better ensure that your code is not linked to non-free, closed source, proprietary software. You can always change from GPL to LGPL later, but going the other way around would be a lot harder. Plus, you (as the authors) will be in a stronger position to financially negotiate with interested closed-source clients :) Reading the section Hide The File System::Transparent Version Control, it struck me that Hans Reiser (lead developer of the ReiserFS filesystem) was thinking along exactly the same lines. Here's part of what he had to say: """ Version control definitely belongs in the filesystem. Filesystems manage files, and that should include managing file versions. Our support for transactions and compression should make it easier to implement version control in Reiser4. ...three things [need to be] changed simultaneously: 1) it was integrated into the filesystem, 2) it was free, 3) it was easy to understand for average users. It should also be as well integrated into apps as version control is in MS Word. """ (the whole interview is at http://interviews.slashdot.org/article.pl?sid=03/06/18/1516239) I think the optimal solution (in terms of least code duplication, fastest performance and earliest release date) would be for KDE to handle the app integration for version control (mostly GUI stuff) and let ReiserFS do the actual file managing.

Re: Tenor licensing, Version control - Anonymous - 2005-08-13

> I think licensing it GPL would better ensure that your code is not linked to non-free, closed source, proprietary software. Who says that KDE wants to prevent that? And for entering kdelibs it has to be LGPL according to KDE's license policy.

Re: Tenor licensing, Version control - Corbin - 2005-08-14

How can kdelibs be LGPL? Since QT is GPL (w/o buying a license), and kdelibs links against it wouldn't that mean that kdelibs has to be GPL? Or does it mean that it acts as if its GPL, _unless_ you have a qt license (and in that case it acts like LGPL)?

Re: Tenor licensing, Version control - KDE User - 2005-08-14

That's just successful GNOME FUD that everything linked against Qt GPL has to be GPL. Your code can be BSD, GPL and still link against GPL Qt, and that's not even counting the additional licenses you can use with QPL Qt.

Re: Tenor licensing, Version control - Fab - 2005-08-14

That's not GNOME FUD .. it is just *plain* FUD. No reason to say it comes from the GNOME camp. Fab

Re: Tenor licensing, Version control - cm - 2005-08-14

> How can kdelibs be LGPL? Since QT is GPL (w/o buying a license), > and kdelibs links against it wouldn't that mean that kdelibs has to be GPL? No, it wouldn't. The GPL and the LGPL are compatible, and that's enough. Note: OTOH, the fact that kdelibs is LGPL does *not* offer a way to circumvent the GPL license of Qt and to create proprietary KDE software. For that there is the combination "proprietarily-licensed Qt (buy one) + LGPLed kdelibs + your proprietary code". That case is also perfectly alright from a legal POV.

Re: Tenor licensing, Version control - Nicolas Goutte - 2005-08-14

You can also look at http://www.gnu.org/licenses/license-list.html for GPL-compatible licenses. Have a nice day!

Re: Tenor licensing, Version control - Philippe Fremy - 2005-08-15

Qt/X11 is also licensed under QPL which is not as strict as the GPL. It mostly specifies that your program must be open source, which is the case for the LGPL.

Re: Tenor licensing, Version control - mihnea - 2005-08-13

>I think the optimal solution (in terms of least code duplication, fastest >performance and earliest release date) would be for KDE to handle the app >integration for version control (mostly GUI stuff) and let ReiserFS do the >actual file managing. KDE wants to work with most/all Linux/UNIX filesystems.

Re: Tenor licensing, Version control - superstoned - 2005-08-13

KDE can use a database (mysql whatever) when there is no advanced filesystem.

Re: Tenor licensing, Version control - Vlad C. - 2005-08-13

>KDE wants to work with most/all Linux/UNIX filesystems. I hope that's not at the expense of desktop performance or user experience. Trying to be all things to all systems (at least from the beginning) will invariably bog KDE down and make it less appealing than proprietary systems like M$ Windows and Apple OS X. Please read Hans Reiser's response to a similar comment by Linux Torvalds: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0448.html The key is to get a task to work outstandingly with a particular combination of tools and then gradually expand support for less-capable filesystems and OS's. I think this strategy would work well because KDE's version control development can be split into two relatively independent components: 1) the backend that manages file version archiving and 2) the frontend that provides GUI access to the archives from KDE apps. I suggest that KDE development initially focus on a frontend (#2) that interoperates with ReiserFS 4's version control system. Once that combination is out, it can act as a proof of concept (and a functional one for Linux/ReiserFS users ;-) If, after that, there is still a market for version control outside of Linux/ReiserFS, KDE development can proceed to focus on a FS-independent archive backend (#1). I suspect the creating the backend will be harder than the frontend, so it would be best to let filesystem developers iron out the details first. Please note that finishing the KDE frontend first will likely *not* interfere with with subsequent development of the backend – if anything, it will speed it up because the backend will then know exactly what the frontend expects from it.

Re: Tenor licensing, Version control - Debian User - 2005-08-14

What I think you fail to understand (not necessarily true) is that ReiserFS 4 is not going to be the following things: 1. Available to the common public. I am not aware of any distribution stock kernel that supports it yet. It is not in the Pengui Pee Kernel, is it in -mm kernel, I think not? 2. Ready before KDE. Because of 1, KDE 4 is going to be in the hands of people earlier than Reiser 4. This is chicken and egg problem. Reiser 4 will not be in distributions because no killer app needs it. 3. Acceptable requirement. If you separate front end back end, why start or focus on a back end that is so rare? You will need another performant backend anyway. In no way is it going to be that the FreeBSD or Windows users of KDE4 will not get to use this. 4. Instead, with Tenor, people are going to able to use FUSE (something that is being merged in the Linux kernel and going to present in distributions soon) to mount Tenor KIO slaves. 5. ReiserFS 4 is the wrong approach. Actually FUSE is the better approach. FUSE is a plugin interface for filesystems, whereas with ReiserFS 4 you must follow Namesys in Code (specific to Linux), Storage Format (not the same as ext2 and so my data is dramatically less safe) and plugins. When all you want is probably the plugin power. In summary, I would say, it is not necessary to solve the problem anywhere near the kernel. Instead, KDE can solve the problem completely inside the framework and then we use already available means (FUSE-KIO) to provide it to the lower level tools. That removes a dependency from the KDE perspective. One that would otherwise slow things down. Reiser 4 as the solution to metadata problems has been vaporware too longer already... Yours, Kay

Re: Tenor licensing, Version control - Segedunum - 2005-08-14

<i>5. ReiserFS 4 is the wrong approach.</i> Actually, it's not. It is far better, and faster, to have a capable very capable filesystem that can do more. If you look at what a filesystem stores and what people want to do with these new metadata systems the goal are one and the same. Andrew Morton is very, very wrong when he talks about a filesystem doing simple stuff and then layering crap on the top. It is simply logical to get the flesystem to do the work it is good at. However, only Be has had the ability to integrate things totally like this. Every other OS has had to compromise in some way. Not even Microsoft could manage it. They layered WinFS on top of NTFS and decided not only that the performance was crap but that it just wasn't going to work, and canned it.

Re: Tenor licensing, Version control - Debian User - 2005-08-14

Hello, the thing about a "capable very capable" filesystem is that it introduces things where they may not belong to. You can see that from that Linux has a VFS (virtual filesystem) layer and then ReiserFS has all the same and more only level deeper again. For what exactly? For having plugins. Overall ReiserFS 4 is an abstraction of the internal Linux VFS and it will make it cheap to develop filesystem plugins that do all kinds of arcance things. That is great for Namesys and I deeply admire the achievement. But abstracting something virtual... well. Don't blame Andrew for not thinking of that as good design. It happens frequently with these kinds of patches that they have to go through some changes. Like e.g. the VFS should do more of what Reiser4 does. That way, every filesystem stands to gain. The possible performance hit of doing what Reiser4 as via FUSE, I don't buy into it at all. The metadata stuff is going to be housekeeping about lots of small things. Like the Email address you received something from, rather than the 1MB attachment itself. You will hardly have lots of big files in that. The metadata is fairly constant too and the most important thing is: In user space, with e.g. using a relational or object database, or your own file format and so on, you can optimize your data layout according to your application needs. That is going to be most critical to performance. Not the question of "find metadata of somefile in somefile/" or some other means. The thing about Linux is that "mv somefile othername" may kill the metadata connection. Unless of course I am doing it through KDE. Or in some directory that is a mount of FUSE. For my own documents, I may use /home/kay/Documents being a mount of my home through a KIO slave like home:/ That said, I fully trust things to work out well. And, the thing is, KDE 4 will be an Alpha/Beta relatively quick after 3.5 release, likely with Tenor and usable now on many systems beyond Linux. And probably performant too. The metadata thing of BeOS was not like Tenor, was it? It was more like, if every mp3 file in the filesystem had its id3 tags as searchable attributes. But saving the mp3 from an email, would you know where it came from? The one thing about Tenor is not the technics of how things are stored. What is stored, why, and how can it be searched without me explaining ever much to the system. Every tag that I have to provide (except file name) is not going to work... Yours, Kay

I think you're missing the point... - Saem - 2005-08-15

that is an FS are basically weak a DBMS. Reiser4 merely embraces this and it's Andrew who is too short sighted in this situation to understand that. Reiser4's brilliant design speaks volumes about how poorly things are done elsewhere, if you've looked at the architecture and realise how natural it is, you'll soon find yourself seeing the current state of affairs as poor, in light of it. Of course, Linux has little to do with meritocracy.

Re: I think you're missing the point... - Debian User - 2005-08-16

Hello, well, well. Reading the documents about Reiser4, can you hint me at anything specific that makes ReiserFS more close to an DBMS than say ext3? And regarding the merit. ReiserFS was the first journaling file system on Linux (2.4.1 if memory serves right, ext3 made it only in at 2.4.15, that's one virtual machine code change later). Indeed, an achievement. But that doesn't make everything right. In particular, Hans took the VFS like it was, saw the shortcomings... and worked around them. I fully understand those, who don't see themselves in charge of any one particular filesystem, but the VFS, to rather solve existing problems in VFS. That said, sooner or later, I predict that Reiser 4 is going to be merged. It is just not going to be a "eat my code" thing. Yours, Kay

Re: I think you're missing the point... - Saem - 2005-08-16

Reiser4 doesn't expose the functionality, but it can roll forward and back changes, on the data itself, not just keeping a meta data journal. There is more, but I can't recall at this point in time. Your argument about VFS goes with the assumption that the VFS is the right way of doing things, I don't think it is, I think Reiser4's design illustrates that because he seems to solve the entire problem much more cleanly, not to mention transparently and in a performant fashion.

Re: Tenor licensing, Version control - Aaron J. Seigo - 2005-08-15

two things about file system approaches: - the most interesting data available on the desktop for contextual linkage does not exist in the filesystem. you have to add it. - filesystems are not portable. they probably don't be within the next decade, either. KDE is portable. highly portable. this means filesystem specific approaches are not feasible. now, once we've got a production ready system together... if someone wishes to write a Tenor backend that targets $COOL_FILESYSTEM, by all means have at it =) i think it would be pretty cool.

Re: Tenor licensing, Version control - Segedunum - 2005-08-16

Like I said - you don't really ever get what seems to be the ideal solution, not in any OS set up ;-). what you've described sounds like the best approach possible to me.

Re: Tenor licensing, Version control - Morty - 2005-08-14

Since ReiserFS 4 and FUSE are totally different things, comparing them are rather pointless. FUSE are more or less useless in this context, FUSE is simply put OS equivalents to KIO-Slaves. They are simple userspace filesystems. Using them for metadatastorage they are no different than storing the metadata in a standard database on top the filesystem, while the more efficient approach of ReiserFS you do it in the filesystem. Besides why you would you want to use FUSE, when the platform independent way of doing it already are to use only KIO-Slaves. Tying it to a single platform technology like FUSE makes little sense. And using KIO-FUSE in KDE makes absolutely no sense since you can use the KIO-Slave directly. KIO-FUSE are only a way for non KDE applications to use KIO-Slaves through FUSE.

Re: Tenor licensing, Version control - Debian User - 2005-08-15

Hi, I totally agree with that FUSE should not be a means to implement anything. I just wanted to point out that rather than requiring ReiserFS to store the metadata, it indeed would make much more sense, to make the KDE metadata engine available through a KIO-FUSE mount. In the ReiserFS approach, Reiser4 becomes a dependency to Tenor. In the other, which will be really done, KDE uses whatever it finds best suited to the job and creates a pseudo-filesystem to publish the metadata along with the files. That way the circle will be closed. Solving too much inside the filesystem is bound for trouble. Yours, Kay

Re: Tenor licensing, Version control - Hans Reiser - 2005-08-16

Happy to work with anyone who wants to add version control to Reiser4, I do indeed think it would be easier to do it in reiser4 than in other filesystems......

Re: Tenor licensing, Version control - Vlad C. - 2005-08-16

"Happy to work with anyone who wants to add version control to Reiser4, I do indeed think it would be easier to do it in reiser4 than in other filesystems......" Thank you very much for being open to cooperation with KDE in implementing file version control. It remains to be seen whether KDE developers will opt for a completely filesystem-independent approach (which might have the drawback of not being transparent/portable to non-KDE apps), or opt for integration with ReiserFS 4, which would have a better chance of providing all apps on the system with access to file version data.

Re: Tenor licensing, Version control - ac - 2005-08-16

"It remains to be seen whether KDE developers will opt for a completely filesystem-independent approach , or opt for integration with ReiserFS 4." I'd assume they'll let the backend decide that, i.e. offer some database backend for systems/partitions where no ReiserFS 4 is available and a ReiserFS 4 backend where it is.

Re: Tenor licensing, Version control - superstoned - 2005-08-16

well, i'm afraid the kde dev's might not be up to writing this and the other things tenor will need as plugins for reiser4. however, maybe linspire or suse will sponsor such an effort, as they (want to) include reiser4. but first i think reiser4 must get into the kernel, and as long as reiser4 duplicates and extends the current VFS so much, this might take some time (or some feature-cutting from reiser4). these innovations should first be merged into the kernel, then the filesystem can follow, then tenor can use it. but KDE4 is still at least a year (likely more) away... so we'll see.

Re: Tenor licensing, Version control - superstoned - 2005-08-16

btw i'd love to see this sponsorship, as i believe doing tenor the reiser4 way is The right thing to do (TM), and the most performant way. also, i think we'll be relying on this metadata more than we can ever imagine, and a database gets easilly corrupted. if i can't find my files because my database borked for the sixth time this year... i'd rather see it safe in an atomic filesystem!

www.google.com/linux - RB - 2005-08-13

Why is google linux not listed as one of the selectable search engines. Url is: http://www.google.com/linux

Re: www.google.com/linux - yadollah - 2005-09-08

just hello

Re: www.google.com/linux - krishna - 2007-05-01

what is linux can"t you me explination about that

Tenor vs. kat - Nobody - 2005-08-13

So should the kat <https://infserver.unibz.it/kat/> be considered usable only with kde3 and that tenor is going to be the default desktop search engine for the kde4, and virtually obsoletes kat?

Re: Tenor vs. kat - Torsten Rahn - 2005-08-13

This might answer your question :-) http://aseigo.blogspot.com/2005/08/akademy-callinng-all-ohioans-kat.html

Re: Tenor vs. kat - Nobody - 2005-08-13

Thanks, it sure did... :-D

Re: Tenor vs. kat - superstoned - 2005-08-13

Kat might develop into tenor, as the upcoming 'tenor-team' will in part consist off members of the current kat-developers. they are working on the api and the capabilities, and as kat is already a nice application, it is more likely the tenor developers team up with them, instead of simply throwing all the work away.

Re: Tenor and kat - Torsten Rahn - 2005-08-13

Tenor is a framework and Kat is an application which might use the Tenor framework one day -- I see no conflicts there :-)

Re: Tenor and kat - Aaron J. Seigo - 2005-08-13

kat also has some framework aspects to it (the file system indexer, full text extraction..), and we're working together to take advantage of the work that has already been done. the kat framework parts are being improved upon and we'll be adding the contextual linkage aspects on to it.

Re: Tenor and kat - jumpy - 2005-08-14

kat framework will be enough evolved when, looking at the properties tab of a file that was moved many times into my hd, it will say "downloaded from the internet ($URL) 16 days ago" or "your friend sue gave sent this to you. track all the other files sent by her".. fanta-framework?

Re: Tenor and kat - Aaron J. Seigo - 2005-08-14

you've just described the contextual linkage side of it that Tenor is concentrating on. =)

Re: Tenor and kat - Segedunum - 2005-08-14

Holy **** dude. I know that's what you mean when you talk about a contextual linkage system, but when it gets described to you it sounds wonderful. I really hope it can be achieved and you don't get bogged down. The strange thing is, Microsoft and Apple are spending billions in research on this stuff and they're no closer to having a working solution - probably due in part to some historical reasons and the existing software they're working with. The open source world seems to be making great strides in this area, on much less of a budget (:-)) and could really take the lead in this area.

Exciting News, but needs a front-page KDE.org link - Jonathan Lee - 2005-08-14

I am really excited about the development of the Appeal project. It is a great thing to see such a level of organized collaboration within the KDE community. As the process develops further I hope to see a page off of the Appeal website that gives a list of tasks or small jobs that need attention. Also, I would like to see on the KDE.org main page under the KDE Projects a link to the Appeal website. Thanks to all the developers working on this as a way to improve the KDE experience.