OpenRPT development

Hi,

first i'd like to thank you (the OpenMFG team) to have LGPLed OpenRPT, it's a nice move. I'm the software manager for a small software company (40 people, 10 in my developpement team).
We're currently porting our applications to Qt (from MFC), and we're dropping our internal document editor/engine in the process. It's similar to OpenRPT in the spirit, but the code base is quite messy.
We're considering using OpenRPT for the new documents, and the first priority for that is:

[1] a french translation (because we're french)
[2] word wrap support for fields

We can do both ourselves (i've tested [2] in the renderer, it's a one-liner + managing a check box in the writer), but would it be possible to send patches for inclusion in the main OpenRPT code base ?

Best regards,

Ilya

Hi, Ilya:

Yes, it is possible to send patches. The best way to do this is to create an issue in our issue tracker system, label it a patch submission, and attach the patch to the issue. You can find a link to the issue tracker in the left-hand navigation of our site.

As far as the French translation goes, this sounds very interesting. I am curious to know your thoughts on how you would approach it. For obvious reasons, we would be most interested in a solution which would make it possible for other translators to also translate into their language.

If you have looked at our PostBooks product http://sourceforge.net/projects/postbooks, then maybe you have seen how we are using the concept of Locales in the application. A locale links a translation file to a user, so when the user logs into the application s/he sees the text localized for them. We have been generating a .ts file from the PostBooks source code. We then translate the .ts file into target languages using Qt Linguist. Then we use Qt Linguist to convert the .ts to .qm--which PostBooks reads in at run time.

Currently, OpenRPT doesn't have a concept of Locales. So, again, I'm curious to hear your ideas on how to approach this.

Best regards,
Pierce

Hi Ilya,

Thanks for your note and the kind words. I'd add to Pierce's points as follows:

1) In the Mantis issue report form, you'll see a link to our copyright assignment agreement. We ask that patch submitters assign copyright to us so we can have the ability to dual-license commercial versions of the products now or in the future. But we do commit to having an OSI-licensed version containing submitted code available at all times.

2) You'll also note in the Mantis system that we have multiple "projects" - it sounds like most of the code you'd be interested in submitting would fall under the OpenRPT project (the system defaults to xTupleApps - the container for PostBooks and OpenMFG).

Thanks again,
Ned

As far as the French translation goes, this sounds very interesting. I am curious to know your thoughts on how you would approach it. For obvious reasons, we would be most interested in a solution which would make it possible for other translators to also translate into their language.

If you have looked at our PostBooks product http://sourceforge.net/projects/postbooks, then maybe you have seen how we are using the concept of Locales in the application. A locale links a translation file to a user, so when the user logs into the application s/he sees the text localized for them. We have been generating a .ts file from the PostBooks source code. We then translate the .ts file into target languages using Qt Linguist. Then we use Qt Linguist to convert the .ts to .qm--which PostBooks reads in at run time.

Currently, OpenRPT doesn't have a concept of Locales. So, again, I'm curious to hear your ideas on how to approach this.

For our current versions (MFC), we're using a similar concept: language-dependant ressources are stored in .dlls that are loaded at run-time using language info from the user profile. We intend to implement something equivalent in the new Qt client, something like a .ts file sent by the server to the client at login.
For the OpenRPT writer, i think it's not necessary to have a login process, so registering the language in the preferences might be sufficient (with a dialog to select language at first launch). It would maybe be best to compile the .qm files into the OpenRPT executable ?

Are the OSI-licensed versions identical to the commercial versions ? If yes, what would be the motives to buy a commercial version, beside support ?

For the near future, yes, we'll only be interested in submitting to OpenRPT.

For OpenRPT, we don't currently have a separate commercial version at all, other than what's embedded in PostBooks and OpenMFG. We originally dual-licensed OpenRPT under GPL and commercial, but were convinced that LGPL would be as good an option, since we didn't intend to build a product business around selling OpenRPT licenses.

For PostBooks and OpenMFG, it's a different story. PostBooks is dual-licensed under the CPAL, which is the new OSI-certified Mozilla+attribution license, and a commercial license option. OpenMFG, which is only available under a commercial license (albeit a community-source one), adds additional functionality to the same code base.

People can opt for the commercial license to PostBooks and have the option to sell a closed source, perhaps verticalized or specialized derivative product without being bound by the terms of the CPAL. The same would go for OpenMFG, as well.

But contributions made by open source community members to OpenRPT or PostBooks will always be available in the open source releases of those products.

Does that make sense?

Yes it does, thanks for the info.

I've read-only access, i can't create issues (or i'm missing something).

Ilya.

Your access is all set.

Thanks,

Perry Clark

Ilya,

I think the idea of just having a preferences dialog makes the most sense for the writer. In addition I think having some "default" functionality is good as well where on startup if a default.qm exists it loads that and then loads any user prefernces on top of it if they exist as well.

I have never looked at embedding qm files into a binary. I am not sure if that makes sense as it would reduce the flexibility of translations. When embedding the tools however you will need to implement some means for loading the translations as part of your application so that would not affect the core project and you embedding the qm files may make sense.

Chris

Perry Clark

Thanks,

concerning the issue:
* text wrap option within Text Area objects... (SF #1556118)

I've made a patch (still need to do some testing) to allow text wrap for Text and Field objets. It seemed natural at first to also allow it for Field objets, but after coding it i realized i didn't fully understand the differences between these two types of objets:
- is it consistent to extend word wrapping to Fields ?
- by the way, there's a lot of duplicated code between these 2 types (Field and Text), would it be possible to somehow merge the two types ?

I'm not sure i understand that part. What are the "tools" and the "core project" ? What i was thinking of was to embed the .qm files into the application ressources, and loading them more or less the same way as if they were separate files. It would just be a different way to distribute the translations, i don't see how it would affect the core project more ? Sorry if i seem dense, i'm not a Qt guru, i don't know your project very well, and english is not my native language, that's not helping

Ilya.

Ilya,

OpenRPT was designed primarily as a library for embedding inside other applications. The two largest components of this are the renderer and writer. For convenience and flexibility the project also includes stand-alone applications that use these libraries. If you are embedding the report writer into another application then it is that applications responsibility to load the translation. As such our stand-along application for the report writer could be implmented in a simple preferences method that loads the .qm file locally and your application with the embedded writer could load it from a resource file.

Regarding the field and text field objects it does not make sense to add word wrapping functionality to the text field object. A field in this case represents an area that text can be printed in. That text is cropped with no additional work done to it. Adding the wrap flag would be easy enough to do and add greatly to the useability of the field. The text field however is designed already to be a multi-line object but is implemented in a way that is not readily apparent. When using a text field you specify the area of a single line of text. When the renderer is generating output it replicates this line down the page as much as needed to print the entire string. By doing this the renderer can modify the size of each individual section when it is printing to be as big as necessary.

I am more than happy to explain things further if you need it.

Chris

ok - the stand alone application could perhaps also use the Qt resource system and the user's locale as suggested in the Qt doc (http://doc.trolltech.com/4.3/resources.html)
...?

ok - i'll send a patch with the wrap only for the field objects

That makes sense after some consideration however I believe to be the most flexible that a means for having an external translation loaded should be present. This way users can use alternate translation for languages that are already provided or to use translation that are not provided by default.

The french translation is done for the writer (separated .ts for standalone and embedded writer). The writer defaults to the system locale, and the user can force another language that will be then stored in the settings. I've also coded a mecanism that allows an application other than the standalone writer to force the language used by the embedded writer, and to add other translations.
What you meant by "a means for having an external translation loaded", is, i gather, also to allow a user to add some external .qm without recompiling and with the standalone writer (the extra .qm would not be provided by an external application, they would be "discovered" by scanning a particular directory). Should i add that mecanism ? The simplest thing would be to scan a predefined directory (i.e. /translations) at runtime for .qm, and using the file name (without .qm) as the language title.

I've also a question related to the translations: i've discovered some small bugs while modifying and testing the writer, should i sent some patches separatly from the main "language managing" patch ?

This is great. Thank you! Is there any chance you could provide some some user documentation (including examples) so people will have some ideas about how to implement the new functionality?

If you want to add a mechanism for scanning .qm files at run time, that would make sense. As you know, we have a similar process for loading translation files in our other xTuple applications: PostBooks and OpenMFG.

Yes, please send alternate patches separately. We prefer to keep issues separate as much as possible, as this makes it easier for us (and everyone) to keep track of issues and fixes.

Yes i will.

OK, I'll maybe add that in a future patch. The main translation patch is more or less ready (still have to add some doc and add a translation for the standalone renderer), if i have time to wrap it up i'll send it later today.

Going back to the list in the first post, i'd like to know if xTuple has some kind of roadmap for OpenRPT, or a workload assessment for the listed issues.
I'm asking because we could take charge of some of them, and also might want to create features not listed.
Here's a personnal (and rough) categorization:

Don't quite understand

As is, OpenRPT will happily connect to any database supported by Qt, unsupported ones can be accessed via ODBC (i've connected a report to Pervasive SQL for instance) ...?

Rather easy (or difficulties are not obvious to me :-)

NB:
(3) and (4) are more or less the same feature, from an external (non-xTuple) point of view. Restriction: previewing only through pdf (?)
(8) is only easy for Windows! QPrinter::PaperSource does'nt work on other platforms

Seems hard or difficult to assess

Bugs or issues specific to xTuple applications

Already planned (2.3.1)

To comment specifically on some of the issues above:

(1) and (2) Were from before we had the ODBC support and are probably no longer really needed now.

(3) Should be relatively straight forward with the document/render changes that were made in recent versions. The document is generated as meta information and then any number of renderers can be used to render that document. Currently the only one we have now is a print renderer. A preview renderer should be easy enough to implement. The trick would be just doing so in a way that would be flexible enough so that it's usable by several applications. I have some ideas on this specifically if this was something any one was interested in following up on.

(5) With the changes to the document/render model adding new primitives should be pretty straight forward. As it is now the document/render module supports the rectangle primitive but there is no support in the writer or the report definition format for it yet.

(7) is already completed
(10) is already completed

If you, or anyone, were interested in any of these items then we could discuss them and I could give any thoughts I have had about them as part of the discussion.

- I'm interested in discussing (3), perhaps i could start a separate topic for it ?
- If nobody is working on it, we volunteer to implement the rectangle primitive from (5) as we often use rectangles in our documents.

Idiallo,
The road map for xTuple applications on the www.xtuple.org site is generally limited to high level functionality.  If there was a significant change pending that affected OpenRPT, we'd post it up there.  If you started work on 3 & 5, I think that would definitely be worthy of the Road Map list!

Otherwise the issue tracker on www.xtuple.org has all the detail regarding outstanding bugs and feature requests, and which are staged for or currently in development.

If you would like to get involved in OpenRPT development, we agree here that your code contribution history merits including you in the  development circle.  If you haven't already, register an account on www.xtuple.org and forward your user account name directly to me.  I'll get you access to assign issues to yourself for development.  I will also then give you commit privileges to OpenRPT CVS on Source Forge.

Thank you again for your contributions and interest.

Kindest Regards,

John Rogelstad
xTuple
119 West York StreetNorfolk, VA 23510

john@xtuple.com ([email:36129ctt]john@xtuple.com[/email:36129ctt])
(757) 461-3022 ext. 106

On Jan 8, 2008, at 11:00 AM, idiallo wrote:

Don't quite understand
Quote:(1) Additional supported databases (SF: To-Do)
(2) Firebird Support (SF #1218569)
As is, OpenRPT will happily connect to any database supported by Qt, unsupported ones can be accessed via ODBC (i've connected a report to Pervasive SQL for instance) ...?

Rather easy (or difficulties are not obvious to me
Quote:(3) Print/preview feature (Mantis #3387, #3024; SF #1276427; SF: To-Do)
(4) Ability for OpenRPT to call RPTrender in order to test a report
definition for proper results (SF: To-Do)
(5) Additional drawing primitives (e.g., boxes, circles, etc.) (SF: To-Do)
(6) Support for color fonts
(7) Add support to open files for editing from command line (SF #1230590)
(8) Printing to Multiple Trays (SF #1195629)
NB:
(3) and (4) are more or less the same feature, from an external (non-xTuple) point of view. Restriction: previewing only through pdf (?)
(8) is only easy for Windows! QPrinter::PaperSource does'nt work on other platforms

Seems hard or difficult to assess
Quote:(9) Add support for columns (Mantis #4923; SF: To-Do)
(10) Add X of Y pagination support (Mantis #3613)
(11) Auto read tables to create SQL and report definition objects (SF: To-Do)
(12) Auto create SQL and MetaSQL (SF: To-Do)
(13) Visually define table joins (SF: To-Do)
(14) Add a cross tab object to the report writer (Mantis #5013)

Bugs or issues specific to xTuple applications
Quote:(15) Custom label sizes not working as expected (Mantis #3615)
(16) % in SQL statement errors the renderer (SF #1637998)
(17) native encoding in Report Writer (SF #1213385)
(18) Expand custom reporting capability (Mantis #4959)
(19) Hard-code label printer output from certain reports, bypassing printer
interface (Mantis #3385)

Already planned (2.3.1)
Quote:(20) Line Item overflow on checks (Mantis #3788)

Post generated using Mail2Forum at xTuple forums

Yes, i've started work on 3 (integrating print and print preview to the Writer). I've some questions about it and need advices, i'll start a separated thread for that. Thanks for your (past and future) help with the development.

Idiallo,
I gave you developer privileges on the OpenRPT project in the Issue Tracker at www.xtuple.org.  You can go ahead and create and assign issues to yourself there now. It would be great if you did so we have an idea of what you've got in the pipe.

Regards,

John

On Jan 10, 2008, at 1:43 PM, idiallo wrote:

Post generated using Mail2Forum at xTuple forums

I've created issues #6219 and #6220. Issue #6219 is duplicating the previous #3024 and #3387, but i don't have write access to these since they are not in the OpenRPT project. May you close them or mark them as duplicates ?

Done!

Post generated using Mail2Forum at xTuple forums

For the items primitives you can see from looking at the rectangle stuff I did that I try and basically make the interface match Qt's in as best as possible while keeping it simple.

For the preview I have always thought the best way to implement it would be as a two part piece. The first part would be a renderer class, like the print renderer is implemented, that has an api and allows different functions to be called that would render the document to a widget. This could be things like page x at a specific dpi (zoom) setting rendering a rectangle of the source document on to the widget. This would allow the second part to be created which would be a front-end of sorts that an application would use to allow the user to interact with.

These are some of my basic thoughts. If you wanted to know more or talk about other possible solutions then please start a new thread and we could continue there about a particular subject.

Yes, and the preview renderer could maybe share code for the rendering of the individual page with the print renderer, for instance by moving the rendering code of the page from ORPrintRender::render() to the OROPage class ...?
We'll continue that discussion in the thread dedicated to the subject (http://www.xtuple.org/phpBB2/viewtopic.php?t=1288).

Waiting for a response on the PostBook italian port...
I have done the OpenRPT Italian Translation (based on the _fr.ts found in SVN repo)
If somebody would enable my account to submit an issue, I'll upload the .ts and .qm (are the latter needed?) files.

Also, what would you think about a PHP render app for openrpt? This way one could include the reports on a web page...

Alessandro

Hi, Alessandro:

This is great news about the OpenRPT translation. Thank you very much for working on that! You should have report privileges in the issue tracker now. Submit away!

You are not the only one waiting for a response on the PostBooks Italian port. I have also been waiting for someone else to reply. If there are any Italian translators reading this forum, please consider joining Alessandro on that project. You can read more here:

http://www.xtuple.org/phpBB2/viewtopic.php?t=1994

That PHP render app for OpenRPT sounds interesting. But I'll let somebody else comment further on that.

Regards,
Pierce

Hi Pierce,
submitted the "patch", let me know if it's good.

Alessandro

Hi, Alessandro:

I did run into some questions when launching your translation file. Please see my request for feedback on the issue you submitted:

http://www.xtuple.org/mantis/view.php?id=6587

Regards,
Pierce

Pierce,
I have answered the question about it. I'm copying it here so it gets more visibility and maybe it can be discussed with others.

See: http://doc.trolltech.com/4.3/resources.html
I personally would change the way that the languages are included, to have a separate language file, and load it at run time. Having it included in the app has only the advantage of not having issues with paths and so on.

I can provide an example if needed.
There is one in postbooks source: xtuple/trunk/guiclient/main.cpp line 138

Regards,
Alessandro

Hi, Alessandro:

I also like the idea of a separate language file loaded at run time--namely a .qm file in the executable directory. This is how language files are handled by PostBooks. You define a Locale linked to a language file in the application, then assign the Locale by user.

Regards,
Pierce

In the issue tracker I have posted a proposal patch for the translation handling.
This patch is basic, probably adding the locales to the app would be best, so the user can select which to use.

For more details see the README.txt
http://www.xtuple.org/mantis/view.php?id=6133

Regards,
Alessandro

Hi, Alessandro:

I think you meant for people to go to the following link instead:

http://www.xtuple.org/mantis/view.php?id=6587

Regards,
Pierce

For more details see the README.txt
http://www.xtuple.org/mantis/view.php?id=6133

Regards,
Alessandro

oops, yes. I did a cut and paste of the wrong issue.
Thanks.
Alessandro

Hi All,

I want to translate OpenRPT to spanish, finally, before i made the job, can i use the method used by Alessandro or another ?

Thanks.
Manuel Soriano.

Until my suggested modifications are not accepted, I'd suggest you to translare the single .ts files
Merging them together is a pretty straight forward operation.

To create the translation add your i.e. common_es.ts to the common.pro (and the other .pro files accordingly) to the TRANSLATIONS
then run lupdate common.pro
this will produce the common_es.ts file. then translate and release either with qt linguistic or with lrelease common.pro
To use it in the actual code, you'll also need to change the .qrc files to add your translation qm files.

Alessandro

I've applied the changes for the Italian translation using the existing method of embedding the files into the executable. We need to keep this functionality as there was a requirement for it to work that way. I agree and do think that an alternate/additional method of dropping translations into a directory is a good idea as well. Something along the lines of load the translation as they are now and then check for any additional translation files in the application path.

For now as tsdogs suggested just copy the .ts files making the appropriate changes to the the .ts files and the resource files to add the language.

I have "reopened" issue [1] with a new proposed patch which adds the possibility to override translations.
Let me know if this can be a solution.

Alessandro

[1] http://www.xtuple.org/mantis/view.php?id=6587

Hi, Alessandro:

Thanks for bringing this up again--and thanks for the patch you submitted. We have been busy preparing the 3.2.1 release of xTuple ERP. But once that's done we'll review the work you did and give you feedback on it.

Regards,
Pierce

I would like to be able to nudge items using keyboard when designing report.

Yes, i've heard several similar user complains. I've created an issue for that request (0008491).