feature/barcode feedback sought ...

[Lionel Elie Mamane]

On Wed, Jan 28, 2015 at 01:01:02PM +0000, Michael Meeks wrote:
> On Wed, 2015-01-28 at 08:33 +0100, Lionel Elie Mamane wrote:

>>> 	Fair cop. Of course the problem is really a bit larger than this
>>> though: we want to be able to have 'field' or other equivalent
>>> functionality that lets people easily automate / populate QR codes via
>>> scripting / database'y bits (I guess).

>> That sounds useful indeed. From the user's POV it would come as a "QR
>> code" form control, I presume?

> 	Right - I guess so :-) question is; given that (almost certainly) I
> built this on the wrong base ;-) where should I re-build it ? Lionel -
> which form control would you think it should be most like ? [ so I can
> build on that ] ;-)

I'm not yet committed to being there, partially because other things
calling on my time. But maybe part of the first (and second?) day (of
the Hackfest).

I'll be at FOSDEM itself only on the second day (of FOSDEM). We can at
least speak there and/or in the evening (I'm guaranteed to be in
Brussels until Monday morning, where I have another appointment at
10:00am), if you are not too awfully busy.

Anyway... I wrote my previous email without thinking it through; with
"stuff coming from database", we have essentially two modes of
handling them, and two (disjoint) groups of widgets.


Mode 1 is "view ON SCREEN and modify database contents", meaning forms.

Mode 1 is implemented by form controls, and AFAIK they are 100% shared
between Writer and Base; Base "just" uses embedded Writer (Text)
documents. The only difference I know is that in Base, the form (the
database access abstraction that a control is "attached" to, is a
child of) is necessarily attached to the current database, while in
Writer the form is attached to an arbitrary database. Note in passing:
there should be a note-quite-that-easy EasyHack that suggests to make
it "by default the current database" in Base instead of "necessarily
the current database".

It is technically possible to print this screen view (and since it is
on an OpenDocument Text "canvas", not only as a pure screenshot), but
my understanding is that is not a design goal. I've heard of people
using this possibility in production, and filing bugs because it is
made harder than it has to be by the UI.

These controls are "islands" with a fixed position on the ODT canvas
(ocean); they don't insert themselves in the flow of text.


Mode 2 is "view only for printing", meaning reports.

In Writer, that "view only for printing" is the mail merge fields. I
don't have a good idea how those are implemented, but I have a basic
working knowledge of how to use Mail Merge. A hard limitation of this
system is that values from different rows in the database are
necessarily on different pages. These fields seem to be something that
is "character level" and inserts itself in the flow of text.

In Base, there are... two systems for mode 2.

One is the "legacy" report designer, which I'm not quite clear how it
works on general principle, but I've fixed the odd bug in it
sometimes; rarely but sometimes.

The other is the rebuild builder. Since it completely preempts any
possibility in the UI to create a "legacy" report (although existing
legacy reports can still be run, edited, copied, etc) as soon as it is
merely installed in LibreOffice, I expect that for most users (and
especially for myself), it is for all practical purposes the only
"mode 2" system available in Base.

Report builder works by having *Java* *code* create an OpenDocument
Text file COMPLETELY BY ITSELF by generating the XML, by processing an
existing "template" ODT structure in which it "only" replaces some
tags that are not OpenDocument Text by tags that are. By itself means
NOT BY USING UNO / ANY WRITER/LibreOffice API. (The "template"
structure is created by GUI which is not in Java.) That generated ODT
is then opened in Writer (and tends to bump against the limits of
which parts of ODT Writer implements, and its bugs, ...).

"Normal" stuff (like text, numbers, dates, ...) is generated by
placing the actual value in the value attribute of a cell of a table,
and the cell is equipped with a suitable style, so that *WRITER* does
the actual pretty-printing, that is, going from the abstract value
"the 145554th day after 31 December 1899" to the string "5 July 1954"
or "1954-07-05" or "5/7/1954".

There is also e.g. charts, which are done by embedding some kind of
chart tag/object in the ODT document, but frankly we'd have to look
together exactly how it is done because I don't have this in working
memory.



Now, about your barcode stuff.


1) Do you have any plan / hope / ... to have barcodes treated in mode
   1 (forms)?

   If not, then nothing to do with form controls.

   If yes, then... I guess it would be similar to an image control?


2) As to mode 2 (reports), for a complete story, we should at least
   implement it in the Writer mail merge and in the Base Report
   Builder.

   For the Base report builder, I don't foresee much difficulty in the
   actual ODT file generation, as long as we can put some tag with the
   data as attribute; maybe a bit more work if the data is to be put
   as child (CDATA/PCDATA) of the tag. E.g. if we can just replace the
   "date-value" attribute of a table cell by "barcode-value", then
   we'll be in business very, very fast. Or if we can just apply a
   style to a cell that has a "string-value" or a numeric "value"
   attribute. Else, I imagine it would be similar to what happens with
   charts, so still doable.

   But we also have to add the concept of "barcode control" to the UI
   that creates the templates. That's more work, but I don't foresee
   any reason it would not be doable. I have very little experience in
   the implementation of this UI. That "barcode control" does not need
   to actually display any barcode, "just" collect the parameters:
   position where to put the barcode, size, style of barcode, colour
   of barcode, ... Again, the image control looks the most similar?

-- 
Lionel