Technology Preview of Rekall DBMS

theKompany.com has announced
a technology preview release of
Rekall, a personal,
programmable DBMS for KDE. Rekall will simplify building database applications
with forms and reports. According to CEO Shawn Gordon, Rekall will have
a full complement of widgets so that applications built with Rekall will be
able to have the look and feel of any other application. He adds that Rekall
applications can be extended in their functionality arbitrarily via embedded
Python as a scripting language (this
capability is not included in the first release). This is a very
positive development for KDE, as programmable databases such as
dBase,
Paradox
and MS Access,
available on other platforms, have enabled
users to focus on the data model and to leverage their business knowledge
into working applications. Rekall even promises some advantages over
the aforementioned products, as it does not rely on a native database and
instead can be used with a database of the user's choice, such as
MySQL,
PostgreSQL or
Oracle, and uses a default database
format that is meant to be light weight, easy to use and require no RDBMS
experience. theKompany is working with the KOffice developers to include portions of this technology in KOffice. More information (including screenshots) is
available at Rekall's
homepage
.

Dot Categories: 

Comments

by Mayhem (not verified)

theKompany.com is overloaded, so there seem to be an interest in this or mayby theKompany.com just rock.

by KDE User (not verified)

They have been literally Slashdotted today.

by Craig Black (not verified)

It's just these type of applications that are going to bring KDE and Linux in general to a wider audiance. Keep up the good work Shawn and bravo to all you KDE and Koffice hackers out there. I looking forward to the final releases of Kapital, Aethera and Rekall. Kde will be looking very sweet by this fall.

Craig

by Pyretic (not verified)

Hi,

Rekall also has a sourceforge page at http://sourceforge.net/projects/rekall

Did anyone had success compiling xbsql on suse 7.1 ?

I get:

-I/usr/include/xbase -I. -I. -g -c xbsql.tab.c
In file included from lex.yy.c:41,
from xbsql.y:456:
/usr/include/unistd.h:310: type specifier omitted for
parameter
/usr/include/unistd.h:310: parse error before `1'
make: *** [xbsql.tab.lo] Error 1

by Olaf Bergner (not verified)

Hi,

I think Rekall could be a major step forward towards a mature KDE-Desktop.So I tried to compile xbsql on my SuSE 6.4 machine but encountered some problems.

1) Using the xbase-rpms, I found xbase.h
installed under /usr/include/xbase/ while
xbsql expects this file under /usr/include.
OK, I copied it.

2) Now I get

xql.cpp: In function `int main( int, char **)'
xql.cpp:137: initialization to `char *' from `const char *' discards qualifiers
xql.cpp:164: initialization to `char *' from
`const char *' discards qualifiers

I am not an expert at C(++), but this looks like some kind of typecast is missing, right? (Probably wrong)
Any hints are welcome.

i had the same error.
i did a make -k install, and installed rekall with --nodeps and it works

by Joe Dow (not verified)

To compile it, do the following:

Problem:
/usr/include/unistd.h:310:
type specifier omitted for parameter

Fix:
Remove the #include unistd.h

Problem:
xql.cpp: In function `int main( int, char **)'
xql.cpp:137: initialization to `char *' from `const char *' discards qualifiers
xql.cpp:164: initialization to `char *' from
`const char *' discards qualifiers

Fix:
Add the cast (char*) where needed in lines
137ff and 164ff

by Shawn Gordon (not verified)

We are looking at the compile problems right now, we'll try to have something for tomorrow.

by Olaf Bergner (not verified)

Many thanks for your immediate response.May I add that IMHO you and your company is doing a great job.

by jorge costa (not verified)

As allways shawn you are the fastest guy i ever seen when it come to email ;-)

keep your Kompany alive

you guys simply rock

by Anders Lund (not verified)

I get theese problems on my mandrake 7.2 system:
After correcting the above mentioned cast probs, it goes fine up to this point:

*** Warning: This library needs some functionality provided by -lfl.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

(The flex package installed by mandrake developer installation provides only a static libfl)

g++ -DHAVE_CONFIG_H -I. -I. -I. -g -c xql.cpp
/bin/sh ../libtool --silent --mode=link g++ -g -g -o xql xql.o -lreadline libxbsql.la
/usr/lib/libreadline.so: undefined reference to `tgetnum'
/usr/lib/libreadline.so: undefined reference to `tgoto'
/usr/lib/libreadline.so: undefined reference to `tgetflag'
/usr/lib/libreadline.so: undefined reference to `BC'
/usr/lib/libreadline.so: undefined reference to `tputs'
/usr/lib/libreadline.so: undefined reference to `PC'
/usr/lib/libreadline.so: undefined reference to `tgetent'
/usr/lib/libreadline.so: undefined reference to `UP'
/usr/lib/libreadline.so: undefined reference to `tgetstr'

which may be a result of the missing libfl??

by Scott Dysinger (not verified)

This probably isn't the proper way to fix it but I modified line 106 of the Makefile in the xbsql directory by adding -lncurses following -lreadline. It then built properly...

xql_LDADD = -lreadline -lncurses libxbsql.la

by Thorsten Schnebeck (not verified)

The screenshot look like "crappy" MDI paradigma.
Come on, there _must_ be something better than this. Falks MDI-class seems to be better the original QT-MDI "trash".

Getting more OT:

I also see some strong usability problems when programs using MDI-structures for control-panes (e.g. Killustrator layer-box).
Think of a user writing a text in KWord. Now she needs a figure and inserts a (e.g.) Krayon-kpart. What she gets is a nearly unusable frame, because the pane occupies the whole kpart-frame. As a user I want to tear off the pane and fix it maybe at the kword-window and (also as a user) I want "full-window"-editing of an active kpart.

Has somebody a good idea for a user friendly multi-document interface in a KPart world?

(Before someone start: Uhh, Thorsten is whining once again about MDI:)

It's only about _this_ kind of MDI. I like the way implemented in Konq and Gideon. Also Kant, ups Kate (sorry Lady ;-) MDI is ok! (I nagged on it in the newsgroup), hmmm - KDevelop-2 MDI is "second quality" (sorry ;-)

[Ok, and next time I start once again nagging on silly filesector-boxes vs. a easy drag&drop "Save" icon ;-))]

Bye

by Shawn Gordon (not verified)

We have this argument internally all the time :), there are some things we are going to try out for the next release.

by Marc Mutz (not verified)

The ugly windows-y MDI interface was what struck me first, too. I also have a problem that I see the others don't seem to have, with what all the cheering around every theKompany announcement:

  1. The development model seems to be too much cathedral-like, mainly because all those theKompany apps are not in the KDE CVS.
  2. Why do they develop applications for which there is already an (KDE native) alternative? I think of Aethera: Why don't they help in extending KMail in the first place?

    I think the development power of theKompany would be better utilized in providing applications that do not yet have an KDE native alternative. Kapital is certainly one of those and I don't mind them charging money for that then.

  3. I always wonder how they will make money from their business model. I appreciate it when a commercial company releases a huge amount of code under a free open source licence, yet if there is not a sound business model behind that, they will probably go the way Eazel currently goes: They have a real great product, but not the economic strength to maintain it (some way done the road). I also believe that domination of a single company w.r.t. the applications of any system is very bad for that system. It has been so (with MS in Windows of course, but also) with ASH in the AtariST world: In the beginning they were celebrated for their Magic TOS-compatibe OS, but soon they took over of what was left of the AtariST app market. So I always get a bad feeling when a single kompany (sic!) does too much for a given platform.

yet, I must admit that I haven't looked at theKompany too closely and maybe I'm unjust w.r.t. them. I just wanted to bring a more critical voice into the discussion.

by Eric Laffoon (not verified)

> The ugly windows-y MDI interface was what struck me first, too.

Could be the fact that they seem to have based it off of the acclaimed QT Designer?

> The development model seems to be too much cathedral-like, mainly because all those theKompany apps are not in the KDE CVS.

Ever look at KDE CVS??? Note kdedb, kivio, kugar, kamera and probably others I'm missing. There is a fair amount of theKompany code in KDE CVS including code applicable to this release.

> Why do they develop applications for which there is already an (KDE native) alternative? I think of Aethera: Why don't they help in extending KMail in the first place?

Do you prefer the "one size fits all" model in the windoze world? FYI Aethera started out as Magellan and theKompany got involved with it. The aims are different and kmail is already well received as very good at what it does... it is just philosophically different as a program.

> yet, I must admit that I haven't looked at theKompany too closely and maybe I'm unjust w.r.t. them. I just wanted to bring a more critical voice into the discussion.

There is nothing wrong with being critical. We should never lose perspective... however perhaps you should look into that which you critisize. If you don't then you run a high risk of appearing foolish or less than constructive. I think most certainly comparing theKompany (who has a business model I can understand) with Eazel (who has no business model I can discern) is rediculous. I don't know how much business you understand but here are two striking differences between theKompany and Eazel. First theKompany has a revenue stream (and model) and second, unlike Eazel if it is not $500k-$1m this month it will not produce red ink and rabid investors! In fact the list of differences between the two companies with regard to business model, philosophy, technology choices, style and involvement in the desktop model is too long to even contemplate here. The only similarities are that they produce software for Linux.

As always I strongly advocate people have some basic knowlege of what they are posting.

by me (not verified)

Yes, I have looked at the KDE CVS lately. A
typical cvs commit looks like this:

"Added changes for latest Kivio from theKompany's CVS."

So obviously the kompany is not using the kde cvs
for development. There are just using it as
distribution medium.

If you advocate people to have some basic knowledge of what they are posting, fine:
best start with yourself.

by Rob (not verified)

I see your point, but I don't think that you are being entirely fair to theKompany wrt applications that they help donated to the KDE project and now help maintain in KDE CVS.

The fact that the apps are in KDE CVS means that anyone with commit rights to that CVS code can make changes. With this in mind, theKompany must synch the code in their CVS with the KDE CVS regularly to ensure that they are not developing with an out of date code base.

I would say that their private CVS is simply an aid to their own development and the official code is in the KDE CVS.

by Eric Laffoon (not verified)

Ironic you claim little knowledge and suddenly post this "revelation". I smell a troll.

> Yes, I have looked at the KDE CVS lately.
I look at it several times a day.

> typical cvs commit looks like this:
"Added changes for latest Kivio from theKompany's CVS."

Funny? What file? I looked at several dozen of the highest rev files in the main module and did not see this in any recent commits. I wanted to be sure before caling an anonymous coward a liar. Of course in your last post it was that theKompany did not have apps in KDE CVS. That was a farce. Try another farce?

If you go back far enough to where Kivio was moved to KDE CVS you will see postings about things being moved. You will also see core KDE developers posting and different developers than on theKompany CVS... yes, they still have Kivio in their public CVS which looks odd. So I pulled it and looked. In a quick review it appears that it has not been updated since the move and they simply have not bothered to delete it from CVS.

> So obviously the kompany is not using the kde cvs for development. There are just using it as distribution medium.

No, obviously you either don't understand what you're looking at... or you are just trolling, lying and and looking to smear a company that is donating free software to the KDE project.

> If you advocate people to have some basic knowledge of what they are posting, fine: best start with yourself.

I will take back what I said. It seems obvious that you do not wish to be confused by facts. So please don't bother posting to try to prove you what know. If you want to say something bad about someone giving you free software I suggest you assume a real identity and deal in facts for a start. It's still slimey but it's slimey with a spine.

Maybe I'm old fashioned. I think if someone gives you something valuable for free you ought to have a modicum of gratitude... and if you wish to say something bad about them you ought to have the decency to do your due dilligence and be certain what you say has some merit.

How can I put this? An opinion with no basis in fact is little more than a prejudice.

by Dave Marotti (not verified)

You are wrong about the KDE CVS. I originally used theKompany's CVS repository for Kivio code. Then the decision was made to put it in the KDE CVS repository. However, there were several complications and over a period of time, development was done out of both KDE and theKompany's CVS repository. This is where comments like this came from.

I personally develop from the KDE CVS repo for Kivio and haven't touched theKompany's for a *long* time.

As for my comments in the KDE CVS repo, I know they are usually very brief or lacking. I personally don't like CVS as I always forget to update my code before I start working on it and other things like that so when I type up a huge description of changes, attempt to commit, and it fails due to a conflict - I don't usually type up the same description again out of frustration.

-dave
(Kivio developer, Queesio author)

by Eric Laffoon (not verified)

> The ugly windows-y MDI interface was what struck me first, too.

Could be the fact that they seem to have based it off of the acclaimed QT Designer?

> The development model seems to be too much cathedral-like, mainly because all those theKompany apps are not in the KDE CVS.

Ever look at KDE CVS??? Note kdedb, kivio, kugar, kamera and probably others I'm missing. There is a fair amount of theKompany code in KDE CVS including code applicable to this release.

> Why do they develop applications for which there is already an (KDE native) alternative? I think of Aethera: Why don't they help in extending KMail in the first place?

Do you prefer the "one size fits all" model in the windoze world? FYI Aethera started out as Magellan and theKompany got involved with it. The aims are different and kmail is already well received as very good at what it does... it is just philosophically different as a program.

> yet, I must admit that I haven't looked at theKompany too closely and maybe I'm unjust w.r.t. them. I just wanted to bring a more critical voice into the discussion.

There is nothing wrong with being critical. We should never lose perspective... however perhaps you should look into that which you critisize. If you don't then you run a high risk of appearing foolish or less than constructive. I think most certainly comparing theKompany (who has a business model I can understand) with Eazel (who has no business model I can discern) is rediculous. I don't know how much business you understand but here are two striking differences between theKompany and Eazel. First theKompany has a revenue stream (and model) and second, unlike Eazel if it is not $500k-$1m this month it will not produce red ink and rabid investors! In fact the list of differences between the two companies with regard to business model, philosophy, technology choices, style and involvement in the desktop model is too long to even contemplate here. The only similarities are that they produce software for Linux.

As always I strongly advocate people have some basic knowlege of what they are posting.

by jono (not verified)

This whole MDI is bad thing is really getting on my nerves.

Let me add my opinion:

- First, if you think that applying a GUI design paradign to any type of software and expecting a good or bad result, you are being silly. You can't just say...MDI is bad...as MDI works well in many application types. The fact is that when developing software, you first look at the document model...is it centric? is it abstractive? is it metaphorical? Once you have an idea of your document model you can base your interface model (paradigm) around it. Some software works well with MDI (like rekall), and some doesnt.

- The whole MDI is bad argument is getting pretty old now. Many people have stated that UI research states that it is bad. Well this is not quite accurate. *Some* UI has stated this, just like some research states MS produces good GUI design data...it is objective.

- Even if UI research states MDI is bad, this doesn't mean that practically it is bad. An example is in MS Office 2000; some designer at MS saw the UI desig rule of "keep visibility limited", and they came up with the arrows thing at the bottom of the menu's which hides things away. My initial research (for my Uni HCI work) shows this new design is very bad for both new and experienced users of the product. Theory is meant as a guide, not a rule.

- We must remember GUI experience and metaphor when expressing opinion on GUI models. I am sure rekall is aimed at a subset of the windows community, and like it or not...the MDI model works very well in the windows world...and it doesnt matter what the usability design and realisation books say...if a user interacts well with an application or information resource...it works.

- The Konqi/Katy MDI method is good for certain document centric applications (usually where the view is a view and not necceccerily a document). Konqi does it well as the multiple views can be used for browsing multiple resources. Also, in Konqi and Katy, there is no concern of screen estate. An example is if you were using a WYSIWYG web editor such as Kafka (which I maintain), a designer may be using a resoloution of 800x600 and rely on a window and document view being the size of the product (web page). An example of this is in image editing where Photoshop uses MDI really well (as does GIMP...although GIMP unfortunatly does not use a grey image window background which affects colour interpretation and mapping). Using the Konqi style MDI would be hell for an image editor. It works well for certain things (such as Konqi), but *not* all things...such as rekall.

Please think about all of the GUI interpretation, experience, natural mapping and metaphors before making ourlandish claims. If you are nopt familier with any of this...then I suggest you get an *informed* opinion before you post.

By the way...I am in the process of building the KDE Usability Study to analyse and test KDE on usability standards and data. Join kde-usability if you want to get involved. :-)

Jono

by Mike Richardson (not verified)

Please! This is the first Rekall TPR.

You can blame me for most of the current code, but we don't intend to force "crappy MDI" on everyone. The general intent is to allow the user to choose the scheme they prefer.

I've had a look at QextMDI, but I found it was currently not up to providing what was needed. The next release will most likely have a "crappy MDI" or "wonderful SDI" option.

I would like to see a standard KDE library for this, to provide application consistency; if this comes along then expect Rekall to migrate to it.

Regards
Mike

by t0m_dR (not verified)

first of all KUDOS!
1)since there will be two versions of the product, one OP.Source and one commercial, will they be compatible? e.g. I develop a database with ReKall commercial , will it run on ReKall Open source?. If not you will have to develop a free runtime, so that we will be able to distribute our work without paying licences/fees.
2)Will there be some pre-built macros for users which don't know how to code?
3)Is porting to windows being thought, for any of your apps? I certainly love using KDE, but in many cases mixed enviropments DO exist. If not porting the entire package, then just porting a Run time executable, should be more than enough, in this case
4) How is your International support? really Support for multiple lanuages and unicode would be very cool!
Thanks for your time!

by Shawn Gordon (not verified)

1) The idea is that the commercial is a series of plug ins that extend the functionality, so they aren't different code bases, Rekall is LGPL. I'm not positive of how the run time will work, we are also working on the details of that structure.

2) There will be wizards that will generate default applications against a table that will add/modify/delete/inquire. We will evolve it from there.

3) Haven't given Windows much thought, we might make it pure Qt and take advantage of that as a multi-platform layer.

4) We have an international group of employees, so that will also be something we do.

by Shawn Gordon (not verified)

We patched the xbsql source and that seems to solve theproblem for many people. Check it out.