Re: [gtkmm] Touch screens and Point of Sale

[Ian Michell <ian michell hanzi co uk>]

That sounds great, I like the ideas you had to implement your database
class, sounds interesting, I have taken a much more simplistic approach,
I have provided a database class that will (eventually) provide blocking
and non-blocking queries, i.e. Queries executed in the main thread (or
current thread) and queries that are executed in another thread to allow
for shorter wait times when one needs results as they come. We used this
approach in a CCTV application written in QT to view the cameras, as
they were all stored in a database, (potentially thousands of cameras)
we had a camera browser and had a thread waiting for the preview images
and teh data, even when the camera browser dialog was closed (hidden)
data was being fed to it :-D I liked this approach as it had some uses.

The POS I am writing itself started off as not quite proprietry, because
it was going to be purpose built for the client (was a favour for the
old man). But because I am not getting paid to do it, I decided that it
would be a much better thing to open it up. Its quite fast and pretty
stable, although its just a shell at the moment, I still have a lot of
work to do on it.

The model is as such:
Plugable: The entire application is plugin based (save core libraries
such as the login screen, dbaccess modules, pluginloader, configuration
reader etc). The plugins are loaded on a user group basis. Each
plugi/module is loaded according to what the user/group is allowed to
load. So it allows for customisation of forms. :)

Database independant: I am trying to make it fit onto any database, so
possibly (if the app is good enough as you said of course) you could use
your experience with postgres to bind it to my dbaccess library. Unless
I take a note from Murray (which I am going to, I want to use libgdamm
as much as possible, possibly help him get it going until it is stable
then depreciate my current librarie until it is not needed). All results
within the database library are cached, they are stored in lists for
quick access, as they say it is better to use memory and swap than to
keep relying on a socket connection (Well I think so anyways!).

Scriptable: I want to bind a python/scripting module into the
application so that we can script forms and the like, whilest using
plugins as extensions to the scripting (when the need arises!), which is
far more efficient and easier for developers to work with, than having
to use C++!

Multiple bindings, like implementing the python stuff, I want to allow
for linking to java applications in both directions (this is way down
the road map). This will help java developers write plugins for the
application too, by using form bindings from the application or writing
stuff for the scripts to use.

Authentication: I want to add more integration with PAM, currently the
only code I had for pam has been depreciated and removed. At the moment
I am using database based authentication, but I want a more secure
environment than that. I rather a user access the database with his/her
own credentials and it will sort of help with single sign on stuff.

Now to answer the biggest question of them all. Accounting packages, I
have no current plans to implement it with GNU Cash, but the idea is
that the system is completely extensible, so you could possibly write a
plugin for it for example. But I do plan to look into big accounting
packages, which SME - Large Enterprises will be using to manage their
finances. Packages like Sage CS3, but the idea here is to possibly build
a business model around it, although totally opensource I wouldn't mind
being contracted by Sage to make the POS work with their package as I am
sure you wouldn't either, whilst hopefully keeping the entire thing 100%
opensouce of course!! :)

Rights I can ramble on all night but I need to write the code for it as
well! I am going to apply to sourcefore/ novell forge for space on their
servers for this project, then will upload what I have to there. Only
question is: What the heck do I name it? lol

Rgds

Ian



On Tue, 2004-03-30 at 17:32, Roger Leigh wrote:
> Ian Michell <ian michell hanzi co uk> writes:
> 
> > Just following up on the discussion I started on Linux Point of Sale and
> > the state of touch screen devices. I have found that Touchscreens work
> > quite well with Linux, (within the limitations of X!).
> 
> I'm also working on the same as part of my job, though the PoS part is
> proprietary, unfortunately.  However, I will be releasing all of the
> widgets under the LGPL.  A GPL/LGPL PoS application would be very
> cool.
> 
> Have you considered tying it into an accounting backend such as
> Gnucash or GNUe?
> 
> > I want to know if anyone wants to do a project based on this, as I have
> > some cool POS code I am going to release under either the GPL or LGP, so
> > obviously I would like comments on the license etc.
> 
> I probably wouldn't have time to contribute to it myself, but if it
> would be possible to make the project usable as an LGPL library, I may
> be able to get work to use it, and be able to contribute in work time.
> It depends on how capable it is, and what features it provides.  If
> it's better than what I've currently written, it might be possible to
> open our source and fold it into your project.
> 
> > The POS application is based on GTKMM and is not complete (unless
> > you count all the libraries: Plugin Loader (not complete), Database
> > Library (multi database support -> not fully implemented) and a few
> > other bits and bobs.
> 
> I've also written a database library, since I didn't find libgda
> mature enough at the time I evaluated it--not well documented, and not
> functional enough.  At the expense of being tied completely to
> PostgreSQL, I've used libpqxx (Pg C++ binding) and written a library
> to work on top of this called libpqxx-object.  libpqxx-object has some
> neat features:
>   . based on libpqxx and all classes derive from SigC::Object and emit
>     changed signals for hooking into e.g. UI code.
>   . Implements "object rollback".  All database operations occur
>     within transaction blocks and work in a 2-stage process:
>     1. Database work with checkpointing of all affected objects.
>     2. commit -> all affected objects are refreshed from the database
>        to update their state as required, or
>        abort -> all affected objects are rolled back to their state
>        prior to the transaction.  Then an exception is thrown.
>   . All database tables and rows in tables are implemented as classes
>     deriving from pqxxobject::table<> and pqxxobject::row<>.
>     Checkpointing is implemented in pqxxobject::row<>.
>   . I'll be writing some Gtkmm widgets for viewing/manipulating data.
>   . PostgreSQL BSD-style licence.
>   . Because it uses Postgres natively, you can make use of all the
>     extra features: all the PG datatypes, sequences, table
>     inheritance, views, triggers and stored procedures.  Table
>     relationships can be expressed directly in C++ using inheritance
>     and containment.
>   . serialisation of whole object hierarchies using INSERT/UPDATE
>     or the reverse using SELECT statements (checkpointing occurs at
>     the root).
>   . convenience classes insert_query and update_query for constructing
>     queries from row and field objects.
> I'll probably get a project going on GBorg.postgresql.org at some
> point.  Some older versions are available at
> http://people.debian.org/~rleigh/
> 
> 
> Regards,
> Roger