On 12/31/06, stas zytkiewicz <stas.zytkiewicz@...> wrote:
> On 12/31/06, Chris Van Bael <chris.van.bael@...> wrote:
> > - What exactly do you expect from such a tool? I would presume it's
> > only modifying/deleting the data (rows), not the database design
> > (tables, columns, ...)
> Correct, the design can't and shouldn't be changed of course, only deleting
> and modifying of rows are allowed.
> (We can't keep people from altering the dbase design but SP will crash if they
> do :-)
> The main purpose of such a tool would be to add data to the user table, like
> the full name etc, deleting rows from tables to cleanup the dbase a bit and
> export parts of the dbase as CSV lists. (comma separated values)
> > - Have you thought of using OpenOffice for the data reporting?
> > It seems it can open SQLite databases (see
> > http://documentation.openoffice.org/HOW_TO/index.html and search for
> > SQLite) and I think the data representation (graphs) will be better
> > than anything we can make.
> I've looked at it but as you mention below the creation of the ODBC drivers
> would be to difficult and perhaps a bit to much for regular users.
> I also didn't want to compile the drivers :-)
Well, I don't know: in the document linked above, it looks like the
ODBC are ready made packages. At work I've seen installers (for
Windows) that included ODBC packages that also set the ODBC settings.
Maybe it all can be done in one installer? If OOo is a sufficient
solution I can look into that.
> >The ODBC drivers can be difficult to
> > install (for Windows users that is) that is true. If we want to take
> > this route, I can take a look into that.
> > For using only data representation (no manipulation), and even simpler
> > way would be to export the data as a file, and import it in
> > OpenOffice.
> See above the CSV part, exporting the dbase tables into CSV list and
> importing them
> into OO, or even Excel, would be the preferred way.
Fine by my, but then the users cannot delete data from the database.
For home users this will not be a problem, but for schools maybe
because of size of the db? On Windows that is...
> >OOo is very easy controllable via Python! (see
> > http://www.oooforum.org/forum/viewforum.phtml?f=9)
> I didn't know that, I would certainly take a look :-)
> > - Do you know if the SQLite Browser guys plan on porting to QT4? If
> > so, that would solve your problem immediately ;-)
> Indeed, I will ask him but I don't know how active he is.
> But sqlbrowser is a GPL app, so perhaps it could be compiled against QT4 by
> you? I have no idea how difficult such a thing is on Windows.
> But as you are the guy with the official visual* stuff, perhaps it would be not
> to difficult :-)
One of my next projects was to look indeed into PyQT for QT4 on
Windows. Also I don't think Visual Studio is needed for it.
> > - How would you make the chart in SP (approach 0)? Would you use QT
> > for that?
> I already made a 'graph' class that creates a simple graph on a pygame surface.
> I'm now implementing it into SP.
> The idea is that the user could hit a 'graph' button which shows a simple graph
> showing him/her the scores for the level he/she is currently in.
> It's just something for the user, not as a tool for the teacher/parent.
> (I will add it to the screenshots I'm preparing for Robert)
> >In my opinion it would be best not to mix GUI toolkits in
> > SP itself. Keep it as simple as possible and the dependencies as low
> > as possible.
> Indeed, the reason for choosing ocempgui, which you found first :-) is to keep
> dependencies low and platform independent.
> Low dependencies and platform independents is the most important thing for me.
> We are not rich because of the things that we possess,
> but for what we can do without possessing them.
> -- Immanuel Kant