In recent Lazarus trunk versions it happens that translations marked as "fuzzy" are ignored, and the untranslated string is shown.

Is this a bug to be notified, or a "feature"?

If it's a feature I find it rather questionable, because a fuzzy translation is in most cases much better than no

http://bugs.freepascal.org/view.php?id=26619

Mattias

Il 04/09/2014 00:20, Mattias Gaertner ha scritto:

Yes it's related, but in the wrong direction, IMHO.

I've investigated and it turns out to be a "feature". Quoting unit lcl/translations.pas line 820:

   //Load translation only if it exists and is NOT fuzzy.
   //This matches gettext behaviour and allows to avoid a lot of crashes related
   //to formatting arguments mismatches.
   if (Itemnil) and (pos('fuzzy', lowercase(Item.Flags))=0) then begin
   [....]

What has happened in recent past is that there was a change of policy for handling quotes and all translation files were submitted to a substantial revision. Because of the consequent formatting argument mismatches there was a lot of crashes, and the problem was raised.

But this was an exceptional situation, which may occur one or two times in a decade, and which should never condition everyday activities. The normal situation is that someone may correct a spelling error in a string, or provide an extra detail, and this causes the translation to become fuzzy.
What would have happened up to now was that the translation would have still been the old one, what will happen from now on is that the translation won't be used, and the untranslated string will be shown.

Lazarus attempts to provide professional quality, but can take advantage only of voluntary work. One should take this fact into account when making decisions. What would be perfectly reasonable in an enterprise environment, becomes quite impractical in our reality.

Therefore my point is: please let live fuzzy translations, less we provide too many untranslated strings which will discourage new (and existing) users. When a Lazarus Foundation will exist, with a lot of money to spend, and someone will be in charge of keeping translations updated, I'll be the first to support a different policy.

Giuliano

IMO it makes no difference. Translators should search for the fuzzy lines sometimes and fix them.
On the other hand I don't understand what caused the crashes. All the params were %s, there were no mixed %d and %s. The number of real params was reduced, the old fuzzy strings provided enough placeholders. Can somebody explain this? Maxim maybe?
Yet, if Format function throws an exception, it should be caught in a try-except block and the problem would be solved (?)

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140904/1dba7c82/attachment.html>

Il 04/09/2014 13:03, Juha Manninen ha scritto:

IMO it makes no difference. Translators should search for the fuzzy lines sometimes and fix them.

Yes, but with the recent change until they don't fix, the translation doesn't show anymore, which is quite annoying.

Here you have a very good point. There's no valid reason why a Format exception of this sort (less or even more parameters than expected) should crash the Application. IMO It could be just silently ignored.

Giuliano

OTOH now you easily spot (in IDE) that a string has become untranslated.

Every disadvatage has it's advantage (Johan Cruijff)

Bart

Il 04/09/2014 19:45, Bart ha scritto:

But in that case it would be an advantage for developers (few) and a disadvantage for users (many).
Questionable by democracy point of view. ;-)

Democracy is the worst form of government, except for all those others that have been tried (Winston Churchill).

Giuliano

Giuliano Colla wrote

But in that case it would be an advantage for developers (few) and a disadvantage for users (many).

No, it would be an advantage for the users because they don't get inferior quality or incorrect translations...
Rather, it makes it painfully clear that the translator has not finished 100% of the translation.

Apparently not showing fuzzy translations is the standard way in other open source projects. I remember a bug report that probably kicked off the change referring to that (but don't know the mantis number).

Regardless of the setting, fuzzy strings will have to be dealt with and (as both a developer and translator) I'm happy that Laz now aligns with general practice.

Il 05/09/2014 09:35, Reinier Olislagers ha scritto:

A change from "Exit" to "Quit" (it happened) marks the translation fuzzy, and this may go unnoticed by many translators. Is it a good reason not to show the old translation?
I'm afraid that users unfamiliar with Latin alphabet (such as Chinese, Russians, arabs, etc.) will hardly agree with your opinion.

Apparently not showing fuzzy translations is the standard way in other open source projects. I remember a bug report that probably kicked off the change referring to that (but don't know the mantis number).

msgfmt provides the flag -f to accommodate the need to show fuzzy translations.

Regardless of the setting, fuzzy strings will have to be dealt with and (as both a developer and translator) I'm happy that Laz now aligns with general practice.

On this point I fully agree with you. It would be nice if the steps before any release did include a quick check to the po files just to verify the amount of fuzzy and untranslated strings, in order to alert translators accordingly.
Pochecker might be improved to provide a more user friendly quick full view of the status of all the translations in a folder, sort of what KBabel provided in the past. I'll look into it.

Giuliano

Another good reason to use tools to check translations as you mention below.

Yes, good idea. So presumably the i18n pages on the wiki will need to be updated??!?

Pochecker might be improved to provide a more user friendly quick full view of the status of all the translations in a folder, sort of what KBabel provided in the past. I'll look into it.

Hmmm, I think Bart updated pochecker regarding fuzzy strings but can't remember what he did.... and my memory may be incorrect anyway ;)

BTW, I have good experiences with virtaal; it shows all untranslated items which includes fuzzy strings IIRC.

Reinier Olislagers wrote

> Pochecker might be improved to provide a more user friendly quick full > view of the status of all the translations in a folder, sort of what > KBabel provided in the past. I'll look into it.

POChecker can show statistics on all po-files.
Just check the appropriate checkboxes.

Feel free to suppy patches for further improvement (preferrably in bgtracker).

Hmmm, I think Bart updated pochecker regarding fuzzy strings but can't remember what he did.... and my memory may be incorrect anyway ;)

It has an option to exclude strings marked as fuzzy for certain tests (for now this option only affects the forat arguments checking).

Bart

Il 06/09/2014 14:08, Bart ha scritto:

I was thinking of a general overview of the translations, similar to the one provided by kde-thumbnailer-po which provides a folder preview like this:

http://www.bononiadocta.it/Lazarus/kde-thumbnailer.png

As you may easily guess, green means translated, blue means fuzzy, red means untranslated.

It's true that the same data are already provided by POChecker, but I've found this graphic preview quite useful to quickly judge the state of translations, as opposed to a list of percentages. As soon as I'll have some time, I'll look into it, to verify if it's not so hard to implement as an added option of Pochecker, as I believe, or if there's some hidden catch.

Giuliano

Nice idea - very useful!

Well, the info is already there.

It's true that the same data are already provided by POChecker, but I've found this graphic preview quite useful to quickly judge the state of translations, as opposed to a list of percentages.

That maybe true.
As a first step (when I have time), I'll see if I can summarize the Statistics at the end of the report.
This will make it easier to ranslate it into a graph of some kind.

As soon as I'll have some time, I'll look into it, to verify if it's not so hard to implement as an added option of Pochecker, as I believe, or if there's some hidden catch.

Can you please open a bugreport for this feature (and put a link to this discussion in it).
I'll assign it to me.
This way it won't be forgotten...

I appreciate your input.

Bart

Il 07/09/2014 11:38, Bart ha scritto:
[...]

Can you please open a bugreport for this feature (and put a link to this discussion in it). I'll assign it to me. This way it won't be forgotten...

Done:

http://bugs.freepascal.org/view.php?id=26685

Giuliano

Giuliano Colla wrote

I was thinking of a general overview of the translations, similar to the one provided by kde-thumbnailer-po which provides a folder preview like this: http://www.bononiadocta.it/Lazarus/kde-thumbnailer.png

Looks nice. How did you install it for KDE?
I also use KDE 4.13 with Mint 17. The servers don't have thumbnailer-po. I only found a source package from the net and it was old. Maybe this is not maintained any more. A pity.

Yes, PoChecker should have such graph.
PoChecker has some usability problems that should be addressed, too. Namely it now behaves like an independent application although it integrates itself into the IDE. It does not use information from the current project or any session info. The logical thing would be to list all translations under the current project and let the user choose from them.
In fact I planned to do it long time ago, after Bart had made this package, but I had other priorities.
I then left separate GUIs for the stand-alone version and for the IDE-integrated version. The idea was to modify the integrated version later. Now they seem to use the same GUI but it can be separated again if needed.
I don't believe anybody really uses the stand-alone version without Lazarus. The integrated version is more important.

Regards,
Juha

Giuliano Colla wrote

Done: http://bugs.freepascal.org/view.php?id=26685

Thanks.

In r46150 I refactored the statistics routine, the stats are now shown at the very end of testing, in semi-graphical way. The results are available after the tests have run, so it should be possible to show them from a button on the log-form.

TPoFamilies now has a property PoFamilyStats of type TPoFamilyStats. This holds all the relevant data after running the tests.

I will need help thoug with the creation of the new graphical summary (it should be a new form IMO).
I graphical summary form should also not depend on components that are not available in a minimal IDE (built with "make clean all"), but that is just a requirement to make my life (as maintainer of this component) easier.

Bart

Il 07/09/2014 15:45, Bart ha scritto:

custom component I have developed in the past.
That's the beauty of open source: each one can contribute with his experiences to fill the picture!

I was thinking of a button "Show Thumbnails" which may open a form with po state thumbnails.

The graphical summary form should also not depend on components that are not available in a minimal IDE (built with "make clean all"), but that is just a requirement to make my life (as maintainer of this component) easier.

My code descends directly from TGraphicControl, so no worries on this side.

Now a question. Looking into the code of the kde thing (no use to reinvent the wheel), i found that it provides *four* categories: Translated, Untranslated, Fuzzy, and *Obsolete*. I've never met that Obsolete thing before. Did you? Is it of some use for us?

Giuliano

Juha Manninen wrote

I don't believe anybody really uses the stand-alone version without Lazarus. The integrated version is more important.

I only use the standalone version.
I don't have it installed as a package/integrated in the IDE (not sure how that is done).

Also, please do not separate the interface (main form etc). It will be a maintanance nightmare.

Bart

Il 07/09/2014 15:22, Juha Manninen ha scritto:

I got a source from KDE-Apps.org which didn't appear too old (updated Apr 17 2012), and compiled from that source:

http://kde-apps.org/content/show.php/KDE+PO+Thumbnailer?content=142036

I found two problems:

1) I had to adjust the installation path, because it defaults to /usr/local which isn't appropriate for my KDE 4 installations (Fedora 14 and CentOs 6). Sort of:

cmake -DCMAKE_INSTALL_PREFIX=/usr CMakeLists.txt

2) I had to edit the header file pocreator.h adding an

#include <QWidget>

to make it compile. Apparently a difference between the included header files of my distros with respect to the ones used by the developer.

After that a make and a sudo make install were all required

I'd suggest that you open a bugtracker issue on that subject, so it won't be forgotten. Having as a guideline the way editortoolbar integrates in the IDE, and on the source editor, it shouldn't be too hard to adapt it to POChecker needs. But it's better to make one change at a time, not to create some confusion...

Giuliano

Il 07/09/2014 17:25, Bart ha scritto:

Main IDE menu: Package->Install/Uninstall Packages ... Select PoChecker 1.0 from the "Available for installation" panel, then click "Install selection" and "save and rebuild IDE" and you're done. After that you'll find PoChecker in the Main Ide Menu among "Tools".

Also, please do not separate the interface (main form etc). It will be a maintanance nightmare.

There should be no reason to induce such a nightmare.

Giuliano

Bart wrote

I only use the standalone version.

Really? Ok.

I don't have it installed as a package/integrated in the IDE (not sure

how that is done).

How come, you have made the package after all. It can be installed from Package -> Install/Uninstall packages.

Also, please do not separate the interface (main form etc).

It will be a maintanance nightmare.

It must be separated somehow if the GUIs have different controls. The integrated version would have a list of translations belonging to the project. The standalone version would not have it. Two separate GUIs are not bad if you have a clear separation between GUI and logic. Refactoring may be needed for that.
The other choice is to hide and move controls in code but that can become clumsy with many differences.

The usability now is poor also because the window is modal. All other IDE windows are modeless and support certain things like persistent resize/location and maybe docking.
This must be fixed, too. Then the integrated PoChecker would be a "first class citizen".

I am not planning to do any of this now but I am happy if someone does.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140907/96dc544f/attachment.html>

You maybe misunderstood. I don't want to integrate PoChecker in the source editor.
It has its own window which is ok but it does not use the potential offered by IDE integration anyhow. Typically we want to check translations of a Lazarus project, right. The most logical thing would be to offer translations belonging to the current open project for checking.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140907/bcad4938/attachment.html>

Giuliano Colla wrote

There should be no reason to induce such a nightmare.

Copying the code that implements logic for PoChecker would be a nightmare but I did not suggest such thing.
I suggested having 2 separate GUIs which is ok.
It is possible to modify a single GUI by code of course. It is ok for me, too.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140907/634a1263/attachment.html>

Now I remember what happened. You provided the first version of PoChecker application. I committed it but also extended it to be a IDE package.
I copied the GUI. I planned to modify it more and improve the IDE integration but I did not. Then somebody united the GUIs.

Juha

Il 07/09/2014 18:39, Juha Manninen ha scritto:

I wasn't thinking about integrating the PoChecker in the source Editor. I was thinking of obtaining the information we need from the IDE, such as current project files, currently open files and such, the same way as editortoolbar obtains them (i.e. via IdeIntf etc.). It seems to me that we could have a set of choices similar to the "Find in files" dialog: current project files, open files, and directory.

The {$IFDEF PoCheckerStandalone}, which is already there, can easily provide the appropriate options only to the integrated version.

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140907/7def262a/attachment.html>

Juha Manninen wrote

> I only use the standalone version. Really? Ok.

Yes, really.

No I did not. I built the stand-alone version.
IIRC you made it into a package.

This would be a list of (master) .po files?

The standalone version would not have it. Two separate GUIs are not bad if you have a clear separation between GUI and logic.

Could be ifdef-ed in the main form perhaps.

Someone else must do that then.
I haven't got a clue on how to achieve this.

With help of others I will start making the graphical summary form (yet another modal dialog).
This wee I don't really have the time for it though.

Bart

Juha Manninen wrote

> It can be installed from > Package -> Install/Uninstall packages.

I think I would rather configure it as "external tool" if I wanted to have access to it from the within IDE.

The tool was set up to run tests on a "family of po-files", the only thing the user needs to do is select the .po and seect the test. All of these can be automated using commandline options. This may be a scenario on how to uses it as a package: it selects the (master) .po file of the project automatically?

Yep.

Bart

Bart wrote

I think I would rather configure it as "external tool" if I wanted to have access to it from the within IDE.

There is no IDE integration with external tools.

The tool was set up to run tests on a "family of po-files", the only

Yes, if the project has only one .po file it should be selected. If the project has more .po files they should all be listed. For example when I am checking the numerous .po files under Lazarus project the usability is very poor. I have the project open but still I must first locate the .po files using a file manager and then open them separately in PoChecker.
This package could potentially benefit from IDE integration more than many other packages.

The .po files are not part of a project. We would need to select all of them below the project directory. They are almost surely needed by the project.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140907/f23048c6/attachment.html>

Juha Manninen wrote

There is no IDE integration with external tools.

I know, it's just that I'm used to working with the stand-alone tool. Also, personally I would not want to test a whole bunch of (master) .po files when working on a project.
I'ld go one by one, fixing all translated .po's from one unit, then go to the next.

The .po files are not part of a project. We would need to select all of them below the project directory. They are almost surely needed by the project.

That would be the easy part.

Should there be a GUI for the user to select what tests to run, or how should this be configurable?

Bart

Testing all files at one go may not be necessary, although it could be an option.
Offering the available files in a list is more important.

Now that I think of it, the stand-alone version could have a similar list of files, found under a directory selected by user.

[from the other msg:]

From my POV the result window is a dialog and hence modal.

Indeed, the main PoChecker window is already modeless. I can maybe look at the IDE integration later.

Should there be a GUI for the user to select what tests to run, or how should this be configurable?

The current GUI for selecting the tests is quite ok. Finding all relevant .po files is the biggest usability issue for me.

There are more ways to improve the IDE integration. The modal results dialog is good for the stand-alone version, but the new shiny IDE message window could be used with the integrated version. Clicking on a warning would open the .po file in editor and place the cursor in the error spot.
In fact I use Lazarus editor for .po files. Maybe it is a dummy thing to do but it works for me.

I am not pushing you to implement this, I only think how it would be in a perfect world. I must learn a proper message window integration myself for the Delphi converter, maybe I can look at this later. Or, maybe Giuliano Colla wants to implement it, he already knows IdeIntf. :)

Regards,
Juha

Sounds do-able.

We can add another button to select a directory and the find all pofiles and put them in a list.
We could also provide a recent-file-history.
My idea would be to split that list in master files and translated files, otherwise it's gonna be hard to find a given master file amongst the many translate ones.

, but the new shiny IDE message window could be used with the integrated version. Clicking on a warning would open the .po file in editor and place the cursor in the error spot.

In the past there was a request to integrate editing in the tool (like you describe: click on an error and goto the .po file). After discussing it, this idea was rejected.
The main purpose of the tool is to check for errors. No reason to bloat it.

But then again, offering to open the file in IDE (when run from IDE) sounds like a nice idea.

In fact I use Lazarus editor for .po files. Maybe it is a dummy thing to do but it works for me.

Well, I use my own editor (LazEdit (CCR) was based on it)

I don't feel pushed.
The ideas are good, I simply now nothing about IDE integration, and I'm currently lacking the drive to dive into that.

Bart

Il 08/09/2014 08:53, Juha Manninen ha scritto:
[...]

I am not pushing you to implement this, I only think how it would be in a perfect world. I must learn a proper message window integration myself for the Delphi converter, maybe I can look at this later. Or, maybe Giuliano Colla wants to implement it, he already knows IdeIntf. :)

I find your general ideas on the IDE integration of POChecker in full agreement with my view, therefore I'm ready to jump on the bandwagon. I had never used before the IDE editor for translations, but, from a quick test I saw that the proper highlighter is already there, and it already does its job. Maybe it can be improved with a few minor additions such as "Find next fuzzy" or "Find next untranslated", which are rather trivial, or with the escaping of quotes, also not so hard to implement.
Another possible way would be a small po-editing package, on the same line of the HTML editor, providing a number of useful options, and taking advantage of a number of functions of POChecker.

But I'd like to face one thing at a time.

1) I've just posted a last minor update to editortoolbar package, which, if survives user test, should be more or less in a "production" state. See http://bugs.freepascal.org/view.php?id=26692
Will you or someone else take care of applying?

2) Now I'll face the thumbnail view of po files, as a first upgrade to POChecker. This way I'll familiarize with the component, which, up to now I've just blindly used.

3) In the meantime we may let the ideas settle down, and decide a roadmap to a better handling of translations: editing translations, checking them, etc.

Giuliano

On 9/8/14, Giuliano Colla wrote:
....

2) Now I'll face the thumbnail view of po files, as a first upgrade to POChecker. This way I'll familiarize with the component, which, up to now I've just blindly used.

This how I would set it up:

The graphical summary should be invoked from the results dialog. This therefore needs a new button, which is visible only if statistics are calculated.
(Any suggestions for a nice glyph on this button?)

To have access to the statistics, the results dialog should get access to the PoFamily.PoFamilyStats property of the mainform of pochecker. This should be passed on to the resultdialog form (the form should get a public property of type TPoFamilyStats (and maybe in trun pass this on to the graphical summary form, which then can do the calculations)).

The TPoFamilyStats class already has a method to write statistics to a TStrings (TPoFamilyStats.AddStatisticsToLog(ALog: TStrings)). The class should be extended to draw the graphs on a TCanvas (or some other component):
TPoFamilyStats.ShowGraphicalSummary(ACanvas: TCanvas);

@Giuliano: what kind of parameter should it have: TCanvas, TImage, something else?

I can easily set up this "infrastructure", so Giuliano can concentrate on the actual calculations/drawings.
I can hide all this behind a compiler directive, so the empty implementation doesn't bother other users.

(It will have to wait a few days, the next few days I am busy with a postgrad study, and I won't have access to my Lazarus machine)

Bart

I started a graphical smmary in r46230.

Please check it out and comment on it.

Bart

Thank you.
Now it's me causing some delay, because I have some other matters to deal with.
ASAP I'll look into it and come back to you.

Giuliano

Il 14/09/2014 16:26, Bart ha scritto:

I compiled, and that's how your graphs look like under Linux (both Gtk2 and Qt WS, it doesn't make a difference):

http://www.bononiadocta.it/Lazarus/Pochecker.png

It would appear that FloodFill is rather broken under Linux!

I had in mind a different approach (components instead of just pictures, to be able to operate on them) so I implemented an alternative, which at first sight was not so bad, under Linux, with Qt WS:

http://www.bononiadocta.it/Lazarus/Pochecker1.png

But, to my dismay, that's how it looks both under Linux Gtk2 and Windows:

http://www.bononiadocta.it/Lazarus/Pochecker2.png

It would appear that at the moment we don't have a reliable multiplatform way to draw our pies.

If nobody else is interested (I saw that some graphic things date back from 2002!) I can take care of revising the basic tools needed to display proper pies. After all it's a common way to show data, and Lazarus should provide professional looking pies.
Later I'll open a new thread on lazarusdev on that subject. Then, when we have the proper tools available, we may continue.

Giuliano

Il 14/09/2014 16:26, Bart ha scritto:

Are you saying, that Canvas.Pie is broken?

Mattias

Mattias Gaertner wrote

Are you saying, that Canvas.Pie is broken?

Since I am unfamilliar with graphics and I did not get how to use Canvas.Pie, I tried to "emulate" it myself.

I calcuate where the lines need to be drawn using basic goniometry, then fill in the sections I created with FloodFill. I couldn't get a grip on Canvas.Pie, Canvas.Arc, Canvas.RadialPie etc. etc.

If Canavs.Pie is the way to go, then all the better.

However, how to do that then?

I start of with a circle with radius Radius, and with origo Origo (TPoint).

Now if I want to draw a Pie-slice of fraction X, starting from the X-axis: (OrigoX+Radius, Origo.Y)
and going counter clockwise to:
(Origo.X + Round(Cos(X * (2 * pi)) * Radius, Origo.Y - Round(Sin(X * (2 * pi)) * Radius)

what do I need to do to make that work using Canvas.Pie And the same Q for a fraction Y, starting of from section X?

PS. You'll note the code for the GraphStat form is rather clumsy. Currently I'm about to convert it by using a ListView with an ImageList and create will make anchoring/aligning that much easier.

Bart

Il 18/09/2014 14:55, Mattias Gaertner ha scritto:

Are you saying, that Canvas.Pie is broken?

In short, yes.

Canvas.RadalPie on GTK2 and Windows works only clockwise, but provides a very poor image (more like a portion of an octagon that a portion of a circle).
Counterclockwise it generates the image of my previous e-mail.

Only on Qt I provided a patch to take advantage of the native QT_Painter, and RadialPie works properly, but by overriding Canvas.RadialPie (or, to be precise, TWidgetset.RadialPie).

Plain Canvas.Pie works differently for each widgetset: it is offset with respect to an Ellipse with the same parameters, but by a different amount depending on the widgetset. This is rather annoying, if you want to show the full circle, as it's usual.

I'd like to avoid code like this:

{$IFDEF LCLQt}
         Pie(PaintRect.Left, PaintRect.Top, W-2, H,
         Integer(Round(MiddleX * (1 - Cos(Angle)))),
         Integer(Round(MiddleY * (1 - Sin(Angle)))), MiddleX, 0);
{$ELSE}
        Pie(PaintRect.Left, PaintRect.Top, W-1, H-1,
        Integer(Round(MiddleX * (1 - Cos(Angle)))),
        Integer(Round(MiddleY * (1 - Sin(Angle)))), MiddleX, 0);
{$ENDIF}

What I'd like to do, if nobody else wants to take care of the matter, is to try to put things in order, and achieve a consistent and predictable behavior with all widgetsets, starting from GraphMath.

Most likely it happened a number of time what I've done recently: RadialPie wasn't working in a satisfactory way, and I've just taken advantage of the native Qt implementation, but maybe I've broken something else in the process, because Pie was just using RadialPie.

I'm not a fan of Delphi compatibility, but in that case, as there a number of arbitrary decisions to take, I'd take Delphi look as a guideline: a Pie, RadialPie, Arc, etc. should just look, with the same parameters, the same as it looks in Delphi.

Another thing that I'd like to do is to add to Canvas support for antialiasing, which provides a more pleasant look to lines, circles, ellipses etc. as expected by modern users, accustomed to modern graphic look.

Of course, unless someone else wants to do it.

Giuliano

Giuliano Colla wrote

Canvas.RadalPie on GTK2 and Windows works only clockwise, but provides a very poor image (more like a portion of an octagon that a portion of a circle). Counterclockwise it generates the image of my previous e-mail.

On Windows here, Pie (RadialPie) works counterclockwise well, using the following code example.
I'm sure if you added anitaliasing to improve the rendering quality this would be welcomed.

Howard

== code ==

unit Unit1;
{$mode objfpc}{$H+}
interface
uses
   Classes, SysUtils, Forms, Controls, Graphics;
type
   { TForm1 }
   TForm1 = class(TForm)
     procedure FormCreate(Sender: TObject);
     procedure FormPaint(Sender: TObject);
   private
   end;
   TPieRec = record
     percentage: integer; // give pie segments as percentag of whole pie
     color: TColor;
   end;
   TPieArray = array of TPieRec;
   procedure DrawPie(aCanvas: TCanvas; aCircleRect: TRect; pa: TPieArray);
var
   Form1: TForm1;
implementation
procedure DrawPie(aCanvas: TCanvas; aCircleRect: TRect; pa: TPieArray);
var
   angles: array of integer;
   lastAngle: integer = 0;
   i: Integer;
begin
   SetLength(angles, Length(pa));
   for i:=0 to High(pa) do begin
     angles[i]:=trunc(pa[i].percentage * 57.60);
     aCanvas.Brush.Color:=pa[i].color;
     aCanvas.RadialPie(aCircleRect.Left, aCircleRect.Top,
aCircleRect.Right, aCircleRect.Bottom,
                       lastAngle, angles[i]);
     Inc(lastAngle, angles[i]);
   end;
end;
{$R *.lfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
end;
procedure TForm1.FormPaint(Sender: TObject);
var
   example: TPieArray;
   circleRect: TRect;
begin
   circleRect:=Rect(10,10,110,110);
   SetLength(example, 4);
   example[0].percentage:=30; example[0].color:=clBlue;
   example[1].percentage:=10; example[1].color:=clRed;
   example[2].percentage:=20; example[2].color:=clYellow;
   example[3].percentage:=40; example[3].color:=clMoneyGreen;
   DrawPie(Canvas, circleRect, example);
end;
end.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pieExample.png
Type: image/png
Size: 8312 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140918/10f1ea7c/attachment.png>

Il 18/09/2014 19:16, Howard Page-Clark ha scritto:

Sorry, my mistake. I mixed up my clocks! It's the opposite: it works only counterclockwise.
To sort things: it works properly with positive values, it doesn't work (makes a mess) with negative values.
Please test again just changing the sign of your angles.

Giuliano

Il 18/09/2014 16:00, Bart ha scritto:

what do I need to do to make that work using Canvas.Pie And the same Q for a fraction Y, starting of from section X?

Pie and RadialPie are quite easy to use.

RadialPie works with resolution of 1/16 degree (meaning that a full circle is 360*16 = 5760).
Takes as parameters the coordinates of the top left (x1,y1) and bottom right of the rectangle containing you ellipse (circle), the starting angle and the angular length (both in units of 1/16 degree).

Here are some fractions of code, just to see in practice how to use it:

   Total := FTranslated + FUntranslated + FFuzzy;
   Circle := 360 * 16;
   TranslatedAngle     := FTranslated * Circle div Total;
   UntranslatedAngle   := FUntranslated * Circle div Total;
   FuzzyAngle          := FFuzzy * Circle div Total;
   ObsoleteAngle       := FObsolete * Circle div Total;
   if FuzzyAngle > 0 then begin
     Canvas.Brush.Color:= FFuzzyColor;
     if FFuzzy = Total then
       Canvas.Ellipse(FPieRect)
     else Canvas.RadialPie(FPieLeft,1,FPieRight,FPieHeight,0,FuzzyAngle);;
   end;
   if UntranslatedAngle > 0 then begin
     Canvas.Brush.Color:= FUnTranslColor;
     if FUntranslated = Total then
       Canvas.Ellipse(FPieRect)
     else Canvas.RadialPie(FPieLeft,1,FPieRight,FPieHeight,FuzzyAngle,UntranslatedAngle);;
   end;

And, for Pie, that's the Lazarus Help description:

/ procedure TCanvas.Pie(EllipseX1, EllipseY1, EllipseX2, EllipseY2,// // StartX, StartY, EndX, EndY: Integer); //
////
// The pie is part of an ellipse between the points EllipseX1, EllipseY1, EllipseX2, EllipseY2.//
// The values StartX, StartY and EndX, EndY represent the starting and ending//
// radial-points between which the Bounding-Arc is drawn.// /
and here a portion of code using it, where /PercentDone/ is a value between 0 and 100, /MiddleX/ and /MiddleY/ are the coordinates of the center, /W/ and/H /are Width and Height of the Paint Rectangle.

         Angle := (Pi * ((PercentDone / 50.0) + 0.5));
         Pie(PaintRect.Left, PaintRect.Top, W, H,
         Integer(Round(MiddleX * (1 - Cos(Angle)))),
         Integer(Round(MiddleY * (1 - Sin(Angle)))), MiddleX, 0);

I hope that it helps.

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140918/0d81c8ba/attachment.html>

Il 18/09/2014 16:00, Bart ha scritto:

Just for your reference (it's work in progress) I enclose a patch which includes what I've done. The Button in the main page does nothing, while the one added in the stats form shows a thumbnails form. You should undefine COUNTER_CLOCKWISE in pothumbnails.pas to see reasonable images.
You'll see that a hint is shown with the relevant numbers. Clicking on a tumbnail just changes its size, but the idea would be to open the file in an editor.

Giuliano

I forgot to enclose the patch. Getting old!

Here is it.

Giuliano

Il 18/09/2014 20:27, Giuliano Colla ha scritto:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pochecker.zip
Type: application/zip
Size: 9803 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140918/d840a771/attachment.zip>

I've got thiscode now (from your example).
It creates a bitmap.

After that I add the bitmap to an imagelist that is set as the largeIcons properties of a TListView.

function TForm1.CreateBitmap2(AStat: TStat): TBitmap;
const
  FullCircle = 16 * 360;
var
  Bmp: TBitmap;
  Translated16Angle, UnTranslated16Angle, Fuzzy16Angle: Integer;
  PieRect: TRect;
begin
  Bmp := TBitmap.Create;
  Bmp.SetSize(BmpWH,BmpWH);
  //Bmp.Width := BmpWH;
  //Bmp.Height := BmpWH;
  //PieRect := Rect(1,1,BmpWH-1, BmpWH-1);
  PieRect := Rect(0,0,BmpWH, BmpWH);
  with Bmp do
  begin
    //Draw background
    Canvas.Brush.Color := clBack;
    //Canvas.FillRect(0,0,BmpWH,BmpWH);
    Canvas.FillRect(PieRect);
    Canvas.Pen.Color := clBack;
    //All angles in 16th of a degree
    Translated16Angle     := Round(AStat.FracTranslated *
FullCircle);// div Total;
    UnTranslated16Angle   := Round(AStat.FracUntranslated *
FullCircle);// div Total;
    Fuzzy16Angle          := Round(AStat.FracFuzzy * FullCircle);// div Total;
    //writeln('TranslatedAngle   = ',Translated16Angle:3,'
[',Translated16Angle div 16,']');
    //writeln('UnTranslatedAngle = ',UnTranslated16Angle:3,'
[',UnTranslated16Angle div 16,']');
    //writeln('FuzzyAngle        = ',Fuzzy16Angle:3,' [',Fuzzy16Angle
div 16,']');
    //writeln('TotalAngle        =
',Translated16Angle+UnTranslated16Angle+Fuzzy16Angle:3, '
[',(Translated16Angle+UnTranslated16Angle+Fuzzy16Angle) div 16,']');
    //writeln('FullCircle        = ',FullCircle,' [',FullCircle div 16,']');
    if Translated16Angle > 0 then
    begin
      Canvas.Brush.Color:= clTrans;
      if Translated16Angle = FullCircle then
        Canvas.Ellipse(PieRect)
      else
        Canvas.RadialPie(PieRect.Left,PieRect.Top,PieRect.Right,PieRect.Bottom,0,Translated16Angle);;
    end;
    if UnTranslated16Angle > 0 then
    begin
      Canvas.Brush.Color:= clUnTrans;
      if UnTranslated16Angle = FullCircle then
        Canvas.Ellipse(PieRect)
      else
        Canvas.RadialPie(PieRect.Left,PieRect.Top,PieRect.Right,PieRect.Bottom,Translated16Angle,UnTranslated16Angle);;
    end;
    if Fuzzy16Angle > 0 then
    begin
      Canvas.Brush.Color:= clFuzzy;
      if Fuzzy16Angle = FullCircle then
        Canvas.Ellipse(PieRect)
      else
        Canvas.RadialPie(PieRect.Left,PieRect.Top,PieRect.Right,PieRect.Bottom,Translated16Angle+UnTranslated16Angle,Fuzzy16Angle);
    end;
  end;
  Result := Bmp;
end;

I attached one of the resulting images.

Some antialiassing code would be very nice though!

Bart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test2.1.po.bmp
Type: image/bmp
Size: 10854 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140918/15b8fe2c/attachment-0001.bin>

I refactored the GraphStat form using a TListView and a TImageList. See r46256.

Bart

Il 19/09/2014 22:30, Bart ha scritto:

I refactored the GraphStat form using a TListView and a TImageList. See r46256.

I open a new thread, with "pochecker" subject because this one is becoming uncomfortably lengthy.
See my comments there.

Giuliano

I am working on the translations of Lazarus IDE and components. Sometimes I need to see also fuzzy translations to check the followings:
- do they appear in the correct context
- do they fit in the space
- are the words used consistently
- etc.
I think that an option to allow displaying fuzzy translations would be welcome for translators. This checkbox would be in good place below the list of languages in Environment/Desktop/Language. And if it is enabled a message box may warn the user that it's risky (program crash/bad translations/etc.). This message would appear on the IDE startup or this one option not to be saved to avoid unwanted effects in the future.

2014-09-06 00:28 keltez?ssel, Giuliano Colla ?rta:

27.09.2014 22:19, P?ter G?bor ?????:

I don't think that it is a good idea to bloat IDE with options which are needed only by some (not all) translators and are rather dangerous (because they lead to "crashes"). Personnaly I don't need it, for example.

If you need a way to distinguish these uncertain translations from others you can leave comment in the entry instead of relying on fuzzy flag.