Von lucijan busch am Mi, 29. Januar 2003 um 08:54 #
hallo,
im endefekt sollte kexi mehr als nur ein datenbankfrontend sein. in wengigen tagen sollten wir so weit sein, dass die "mitgelieferte" datenbank in die projektdateien eingebettet werden kann. es wird also im endefekt möglich sein einfach die von kexi erzeugte datei zu kopieren und auf anderen rechnern wieder zu verwenden. die "mitgelieferte" datenbank heißt CQL++ und ist 100% SQL99 kompatibel (nähere informationen: http://www.cql.com). es ist natürlich auch möglich mit mySQL arbeiten zu arbeiten. datenbankplugins sind für psql und sqlite geplant.
wir rechnen damit, bis zur beta 1 von koffice 1.3 (11. April) eine *halbwegs* verwendbare applikation zu haben
@cosmo: was verstehst du denn unter hoschis ? Fuer mich is das eher negativ behaftet, was irgenwie nicht ganz im einklang deines restlichen beitrages waere....
wie mann an den Reaktionen hier schon erkennen kann ist die Bedeutung von "Hoschi" nicht etwa mit dem prolligen "eyh alter" gleich zu setzen. Vielmehr sind mir tatsächlich Bill und Ted in den Sinn gekommen, die auch mal einen Blick in die Zukunft werfen konnten. So wie eben wir hier mit dem release des neuen kOffice.
also : volle Kanne
/* geschrieben von cosmo der sich langsam ernsthafte Gedanken um die kleinkarierten Bemerkungen und die herschende Intoleranz macht.*/
Mal an das gesamte koffice-Team: Saubere Arbeit. Kann man nicht anders sagen.
Ich bin sehr gespannt auf Kexi. So wie das klingt, könnte das ein richtig gutes Argument werden, um Leute, denen Access für Linux fehlt, zum Umstieg zu überreden. ;-)
umfasst SQL99 nicht auch solch lustige dinge wie Transaktionen, Stored Procedures, Integrität, Subselects und co?
Das alles will diese Datenbank schaffen? IMHO untersützen nichtmal DB2 und Oracle mehr als SQL92 + zusätzen. Wenn mich nicht alles täuscht gibt es keine Datenbank die 100% SQL99 kompatibel ist.
wird es trotzdem noch bugfixversionen vom aktuellen koffice geben ?
Kspread kommt leider beim Drucken auf DIN A4 zB. mit den Seitenrändern nicht zurecht. WYSI_N_WYG :-(. Aber trotzdem Danke an das koffice-team für die gute Arbeit - und wenn jemand weiss, wie man das mit dem drucken richten kann - dann freue ich mich auf antwort.
KSpread beherrscht in 1.2.X keine WYSIWYG. Die noetigen Aenderungen waren uns Neu-Einsteigern kurz vor dem Release zu gross.
WYIWYG ist nichts fuer ein Bugfix - es ist ein neues Feature und kommt mit 1.3. Philipp hat schon vieles dahingehend eingebaut. Ansonsten werden wir natuerlich versuchen, die Bugs zu beheben, die uns gemeldet werden (bugs.kde.org), sowohl im 1.3 branch als auch im alten 1.2.X.
Dein Problem hat eigentlich nichts mit WYSIWYG zu tuen. Bei mir funktioniert alles so wie es soll, allerdings haben wir auch den Bugreport: http://bugs.kde.org/show_bug.cgi?id=52894
Mein Problem nun: Ich kann es nicht nachvollziehen und alles was ich nicht reproduzieren kann, kann ich nicht fixen. In dem BR stehen auch ein paar Angaben, was gehen sollte und was wahrscheinlich nicht die Ursache ist.
Ich bitte Dich daher auch Dich an dem BR zu beteiligen, damit wir den Bug fixen können. Ich denke es hat entweder was mit der Distribution zu tuen (ich verwende Debian) oder mit dem XServer bzw seinen Einstellungen. Kann natürlich auch die QT Bibliothek sein, oder der verwendete Druckertreiber. Es kann halt an vielem liegen.
soweit ich weiss, gibt es ein Style and Diction Modul von GNU. Aber leider fehlt bis heute ein sprachlicher Stilberater für die deutsche Sprache. Angesichts der vielen deutschen Coder eigetnlich eine Schande. Könnte das KOffice projekt nicht vielleicht in dieser Hinsicht innovativ sein? Dazu muss man ja nur gängige Fehlformulierungen, Substantivierung u.a. suchen und anstreichen. Ausserdem kann man einen Lesbarkeitstest machen, indem man den Text nach bestimmten Kriterien wie Satzlänge u.a. parst.
Von Moritz Moeller-Herrmann am Do, 30. Januar 2003 um 00:20 #
Überflüssig. Lern lieber selber Stil. Selbst in der framattisch primitiven Sprache englisch kommt da nur Müll raus, weil man Texte VERSTEHEN muss, um sie stilistisch zu beurteilen. Und das kann kein PC.
Als wir vor einem Jahr die Datenbank getestet haben, war es einfach nicht brauchbar.
z.B. - update von zahlen was falsch: 6.0074 wurde upgedatet in 6,74 - feld ergänzen (ALTER COMMAND)-> segmentation fault - drop table zeigte gar keine auswirkung - create index - keine reaktion
ist es alles jetzt ok ??- sonst der bursche hinter der Datenbank ist schon nicht schlecht (Seth Kurtzberg) - zumindest antwortete er immer prompt - dass er die sache anschauen wird!?
Von lucijan busch am Do, 30. Januar 2003 um 18:24 #
hi,
ersteinmal entschuldigung wegen den den 92/89 verwächslungen man hört SQL92 so oft, dass man es automatisch schreibt :)
ja, du hast recht, seth entschuldigt sich bei dir, dass er vergessen hat sich darum zu kümmern, er sagt aber dass diese bugs innerhalb von diesem wochenede -- wenn nicht vorher -- gefixt werden sollen
2) Luká? ,sollte wohl ein im iso-8859-1 nicht vorhandenes Zeichen sein.
Gruß,
tom
im endefekt sollte kexi mehr als nur ein datenbankfrontend sein. in wengigen tagen sollten wir so weit sein, dass die "mitgelieferte" datenbank in die projektdateien eingebettet werden kann. es wird also im endefekt möglich sein einfach die von kexi erzeugte datei zu kopieren und auf anderen rechnern wieder zu verwenden. die "mitgelieferte" datenbank heißt CQL++ und ist 100% SQL99 kompatibel (nähere informationen: http://www.cql.com). es ist natürlich auch möglich mit mySQL arbeiten zu arbeiten. datenbankplugins sind für psql und sqlite geplant.
wir rechnen damit, bis zur beta 1 von koffice 1.3 (11. April) eine *halbwegs* verwendbare applikation zu haben
/*
lucijan - kexi maintainer & developer
*/
genau das hat mir noch gefehlt:
1. Eine einfache Möglichkeit statische DB files für kleinere lösungen zu erzeugen.
2. ein mySQL kompatibles DB frontend!
Und das alles in der homogen gehaltenen KOffice-Proggy Sammlung
schön, schön da freu ich mich schon drauf!
Fuer mich is das eher negativ behaftet, was irgenwie nicht ganz im einklang deines restlichen beitrages waere....
schon wieder einer, der Bill und Ted nicht kennt.
volle kanne!
gruß,
def
Is ja erdbeer-cremig, Hoschi....
"Hoschi" nicht etwa mit dem prolligen "eyh alter" gleich zu setzen.
Vielmehr sind mir tatsächlich Bill und Ted in den Sinn gekommen, die auch mal einen Blick in die Zukunft werfen konnten.
So wie eben wir hier mit dem release des neuen kOffice.
also : volle Kanne
/*
geschrieben von cosmo der sich langsam ernsthafte Gedanken um die kleinkarierten Bemerkungen und die herschende Intoleranz macht.*/
Ich bin sehr gespannt auf Kexi. So wie das klingt, könnte das ein richtig gutes Argument werden, um Leute, denen Access für Linux fehlt, zum Umstieg zu überreden. ;-)
MfG,
0xdeadbeef
umfasst SQL99 nicht auch solch lustige dinge wie Transaktionen, Stored Procedures, Integrität, Subselects und co?
Das alles will diese Datenbank schaffen? IMHO untersützen nichtmal DB2 und Oracle mehr als SQL92 + zusätzen. Wenn mich nicht alles täuscht gibt es keine Datenbank die 100% SQL99 kompatibel ist.
"The CQL++ implementation includes the ANSI 1989 syntax, ODBC extensions, and CQL++ extensions."
SQL 89 (neunundachtzig)!!
Das Frame-Konzept von Koffice finde ich nicht übel...
http://docs.kde.org/en/HEAD/koffice/kpresenter/
http://docs.kde.org/en/HEAD/koffice/kspread/
usw.
Kspread kommt leider beim Drucken auf DIN A4 zB. mit den Seitenrändern nicht zurecht. WYSI_N_WYG :-(.
Aber trotzdem Danke an das koffice-team für die gute Arbeit - und wenn jemand weiss, wie man das mit dem drucken richten kann - dann freue ich mich auf antwort.
gruesse
plü
WYIWYG ist nichts fuer ein Bugfix - es ist ein neues Feature und kommt mit 1.3.
Philipp hat schon vieles dahingehend eingebaut.
Ansonsten werden wir natuerlich versuchen, die Bugs zu beheben, die uns gemeldet werden (bugs.kde.org), sowohl im 1.3 branch als auch im alten 1.2.X.
Danke für die antwort :-)
Bei mir funktioniert alles so wie es soll, allerdings haben wir auch den Bugreport: http://bugs.kde.org/show_bug.cgi?id=52894
Mein Problem nun: Ich kann es nicht nachvollziehen und alles was ich nicht reproduzieren kann, kann ich nicht fixen.
In dem BR stehen auch ein paar Angaben, was gehen sollte und was wahrscheinlich nicht die Ursache ist.
Ich bitte Dich daher auch Dich an dem BR zu beteiligen, damit wir den Bug fixen können.
Ich denke es hat entweder was mit der Distribution zu tuen (ich verwende Debian) oder mit dem XServer bzw seinen Einstellungen. Kann natürlich auch die QT Bibliothek sein, oder der verwendete Druckertreiber. Es kann halt an vielem liegen.
Philipp
Als wir vor einem Jahr die Datenbank getestet haben, war es einfach nicht brauchbar.
z.B.
- update von zahlen was falsch: 6.0074 wurde upgedatet in 6,74
- feld ergänzen (ALTER COMMAND)-> segmentation fault
- drop table zeigte gar keine auswirkung
- create index - keine reaktion
ist es alles jetzt ok ??- sonst der bursche hinter der Datenbank ist schon nicht schlecht (Seth Kurtzberg) - zumindest antwortete er immer prompt - dass er die sache anschauen wird!?
ersteinmal entschuldigung wegen den den 92/89 verwächslungen man hört SQL92 so oft, dass man es automatisch schreibt :)
ja, du hast recht, seth entschuldigt sich bei dir, dass er vergessen hat sich darum zu kümmern, er sagt aber dass diese bugs innerhalb von diesem wochenede -- wenn nicht vorher -- gefixt werden sollen
ciao
lucijan
/* kexi developer & maintainer */