Hi BeanzMaster,
When the component is stable enough let me know so I can add it to OPM.
PS: I ran a few test and works fine.
[...] Translated internal messages thrue PO files (use a modified TGVTranslate component from Gilles Vasseurs's french tutorial : https://gilles-vasseur.developpez.com/tutoriels/lazarus-traduction/Why do you introduce a new translation system here? Lazarus has good built-in translation support, you only must activate the i18n option and define a language folder in the package settings, as well as declare the message strings as resource strings.
Why do you introduce a new translation system here? Lazarus has good built-in translation support, you only must activate the i18n option and define a language folder in the package settings, as well as declare the message strings as resource strings.
My problem is that you seem to stuff too much unrelated material into the gifviewer package which is not absolutely needed or which could have more general use.LCLTranslator have not really the same purpose. LCLTranslator need more work to be use as is and quickly
What do you want?
Provide a gifviewer? Then the units
- gvTranslate (similar stuff is in LCLTranslator)
- Typeshelpers (large overlap with type-helpers built into fpc now)I've included it because one of tester. Use an old version of lazarus but can be easly remove by replacing "ToString" by "IntToStr" instead, or move to the gifview demo 's folder
Or do you want to provide a general-purpose package with translation utils, fast bitmap, additional type helpers and - of course - gif viewer? Then you should name the package differently and emphasize its multi-use character.
A few other comments:
- I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.
- and probably even uFastBitmap (because I am rather sure that you can paint the gif also with the routines of fcl-image (http://wiki.freepascal.org/fcl-image))
are not needed.
- Did you know that, unlike Delphi, fpc already has built-in gif support (unit fpreadgif in source folder packages/fp-image/src of the fpc installation)? I did not compare, but I am rather sure that there is a lot of overlap with your unit. Why write the same again when it's already there?
Please don't misunderstand these critical word - I really think your units are great work.
LCLTranslator have not really the same purpose. LCLTranslator need more work to be use as is and quicklyAs I already wrote you don't need any translation unit at all for providing multi-language support for a package. Just
Lazarus creates a po template for each unit which contains at least one resourcestring declaration. In otder to have a single po file for the translators, you just should pack all resource strings into a single unit and "use" this in the package and in the application. The single resource string unit will correspond to a single po file. Look at Lazarus' lclstrconsts: it contains all the strings used by some unit of the LCL - this is for the LCL package. The application, Lazarus, has another translation unit, lazaruside, which collects all the strings used by the Lazarus application somewhere.I see two .po files in your locale folder. Translaters don't like this. Usually they prefer a single po file per package.I don't know that. Lazarus generate automatically One PO file for One Unit. Where i can set this option ? and how to manage it for translation ?
I just want to share my work.Great!
FPReadGIF not take in charge animationAgreed, and this is a good reason for your work.
I think the FPC and LAzarus graphics solution be must be rethinking. Just see a little part in my code why i can't manage transparency correclty with TBitmap (just under linux) and must use TLazIntfImage instead ? Lazarus have bigs problems with Bitmap management. Not FCL directly, but i'm think it was not a good choice to manage color as 64 bit (TFPColor) by default. FCL-Image is not enough optimized, error management is not good, many bug are present between and with LCL RawImage/TBitmap.I don't agree. The FPC/Lazarus graphics units are more general than yours. Your gif viewer can only display gif images. The TImage of the LCL, on the other hand, can display any graphics format if it is registered. And FPC-Image can work with images even without the LCL. It took me quite some time until I understood this. In addition FCL-Image is rather difficult to use, and it is easy to make mistakes - therefore, it appears to be buggy. It is not, at least not more than any other software. Using FPC-Image it is possible to paint a transparent GIF for sure - transparent png is working too (all the icons of the IDE are transparent pngs). But of course, if you feel better with your fastbitmap - no problem.
You can test, you'll see with FPC's many many GIF in the Imagetestsuite cannot be read correctly with FCL-Image.Which ImageTestSuite do you mean? I guess FPC's GIF reader does not support all features defined in the specification. The same with other formats. But usually the most important features are supported (in case of GIF, of course, except for animation).
I think the teams should focus on all these small details and small persistent bugs from version to version, for giving more something more stable, especially to be able to cross compile properly without having to shield the code of {$ IFDEF} on basic things (I think of the TListView for example, or like here with the use of TLazIntfImage under Linux), rather than wanting to look like Delphi.I don't understand what you want to say here. As far as I know the graphics formats are not on the focus of the current development. But they are certainly maintained. So, if you find a bug please report it to bugtracker and somebody will take care of it. Also, if you find some pieces of your gif code which could be merged into the code of fpreadgif you should submit it to bugtracker.
What would have been the problem to call "IntToStr" instead of "ToString" and adding an entire unit for it? In all the packages that I am maintaining I try to be as conservative as possible and avoid all new features in order to be able to allow old Lazarus and fpc versions.- Typeshelpers (large overlap with type-helpers built into fpc now)I've included it because one of tester. Use an old version of lazarus but can be easly remove by replacing "ToString" by "IntToStr" instead, or move to the gifview demo 's folder
As I already wrote you don't need any translation unit at all for providing multi-language support for a package. Just
- declare all string constants as resourcestring
- activate i18n in the project options
- and define a folder for the po files created by the LCL.
You do exactly this in the gifviewer unit, and this is correct.
Things are different in an application, like your demo gifview. The application must know which version of the translated po files will have to be used, and it will have to switch between translations. For this purpose, translation support units are required. The key building blocks are contained in units such as "Translations" and "LCLtranslator", but I agree that there is a need for more ready-to-use routines.
Lazarus creates a po template for each unit which contains at least one resourcestring declaration. In otder to have a single po file for the translators, you just should pack all resource strings into a single unit and "use" this in the package and in the application. The single resource string unit will correspond to a single po file. Look at Lazarus' lclstrconsts: it contains all the strings used by some unit of the LCL - this is for the LCL package. The application, Lazarus, has another translation unit, lazaruside, which collects all the strings used by the Lazarus application somewhere.
I don't agree. The FPC/Lazarus graphics units are more general than yours. Your gif viewer can only display gif images. The TImage of the LCL, on the other hand, can display any graphics format if it is registered. And FPC-Image can work with images even without the LCL. It took me quite some time until I understood this. In addition FCL-Image is rather difficult to use, and it is easy to make mistakes - therefore, it appears to be buggy. It is not, at least not more than any other software. Using FPC-Image it is possible to paint a transparent GIF for sure - transparent png is working too (all the icons of the IDE are transparent pngs). But of course, if you feel better with your fastbitmap - no problem.
Which ImageTestSuite do you mean? I guess FPC's GIF reader does not support all features defined in the specification. The same with other formats.This GIF-ImageTestSuite : https://github.com/jdelauney/GIF-ImageTestSuite. and for BMP https://github.com/jdelauney/BMP-ImageTestSuite
But usually the most important features are supported (in case of GIF, of course, except for animation).
I don't understand what you want to say here. As far as I know the graphics formats are not on the focus of the current development. But they are certainly maintained. So, if you find a bug please report it to bugtracker and somebody will take care of it. Also, if you find some pieces of your gif code which could be merged into the code of fpreadgif you should submit it to bugtracker.
What would have been the problem to call "IntToStr" instead of "ToString" and adding an entire unit for it? In all the packages that I am maintaining I try to be as conservative as possible and avoid all new features in order to be able to allow old Lazarus and fpc versions.No problem with that, just happy sharing ;). I'll remove it in next update
You can mail me to personal-messages your patches, and I ll post them to bugtracker.
The BZApplicationTranslator looks interesting. A few comments, though:
- I think automatically restarting the application when the language changes is not good. Are you absolutely sure that the user isn't in the process of editing something when he suddenly decides to switch language? He won't be happy that his text will be gone when the app comes back.
Do you know that language can be changed by just re-translating the resource strings? In LCLTranslator this is just using another language in SetDefaultLang. Probably you have the problem that you cannot switch back to the default language because there is no correct po file for it.
Assuming that your default language is "en" just copy the "program.po" to "program.en.po". - see attached demo.[/li]Thank you for your advice I'll take a look at all this. Just a question if my default language is fr it's the same, i'm right ?
- Multi-language does not only mean translation. You should also take care of FormatSettings. Please look at the demo in examples/translation of your Lazarus installation for some more ideas.
Assuming that your default language is "en" just copy the "program.po" to "program.en.po". - see attached demo.[/li][/list]
I've tested and added one PO file for fr. At start IHM is in english i can change to DE or FR no problems. But I can never go back to EN. It is normal ?I thought this has been fixed. Anyway: Open the .en.po file (which is a direct copy of the template .po file) in peedit - you'll see untranslated items. Go to every untranslated line and press CTRL-B to copy the original string into the translated column. Of course, both strings are the same here.
if my default language is fr it's the same, i'm right ?What exactly is "default language"? I think for the purpose of preparing multi-language applications it is the language in which you add resource strings. You seem to add resource strings in French. Therefore the template file .po contains French strings. Copy it to .fr.po and copy all untranslated strings to the translated column by pressing CTRL+B in poedit. Create an English file .en.po, have someone add the english translations, etc. So "default language" does not matter here much, except for the language file which contains the originally untranslated texts.
if my default language is fr it's the same, i'm right ?What exactly is "default language"? I think for the purpose of preparing multi-language applications it is the language in which you add resource strings. You seem to add resource strings in French. Therefore the template file .po contains French strings. Copy it to .fr.po and copy all untranslated strings to the translated column by pressing CTRL+B in poedit. Create an English file .en.po, have someone add the english translations, etc. So "default language" does not matter here much, except for the language file which contains the originally untranslated texts.
The next time when "default language" comes into play is when your program starts. LCLTranslator looks up in the OS and finds that your OS is in french. Therefore it picks the .fr.po file as default at start.
As for the FormatSettings, default language should not be important at all. The problem with the translation project in the Lazarus examples folder is that there does not seem to be a cross-platform way to detect the correct FormatSettings for all OSs. Therefore, the code is mostly IFDEFed with {$IFDEF Windows}
Your English translation file is empty.
Well then maybe the "default language" is English - as I said I don't know what this means here... Copy the project1.po to project1.en.po and open that in poedit. Click in every line and press CTRL+B to copy each original resource string into the translated column. Now the english po file has translations, and everything must work.
See also attached demo.
Hi, can you pls, create component for PNG Animated?https://github.com/pjde/ultibo-png
https://en.wikipedia.org/wiki/APNG
This link doesn't help, no component.good learn to program first
Hi, can you pls, create component for PNG Animated?Hi Alex, yes i'll can, i not many time actually. I'll take a look, PNG and APNG is on my todo list ;)
https://en.wikipedia.org/wiki/APNG
This link doesn't help, no component.good learn to program first
irrelevant. Comments like "Its not a component so I can't use it" come only from laziness.This link doesn't help, no component.good learn to program first
Before write a comment like this, have you see who is Alextp ? surely not ! so please don't be so casual.
[EDIT] for informations from your "utilbo" it's don't work,Not my code.
don't compile anyway. Missing unit, and only support PNG but not APNG completely so....
don't compile anyway. Missing unit, and only support PNG but not APNG completely so....Good write your own. What am I your daddy to help you learn how to walk.
Hi BeanzMaster
Thank you for this great component. I am new to Lazarus, and have been searching for a couple of days for a way to show an animated gif. All the other answers I found were incomplete or impossible for me to work out how to implement. Your instructions are very clear and worked first time.
One thing I found is that the gif file has to be present in the users file system. This is not a problem for me.
Cheers
One thing I found is that the gif file has to be present in the users file system. This is not a problem for me.
Hum i never has this problem, i have many gif on differents folders or on usb sticks, all works
The application is a simple form with one animated gif, specified in the TGIFViewer FileName property as C:\development\images\loading18.gif. See attached.
GIFViewer.LoadFromFile(ProgramDirectory + 'myimage.gif');Hi BeanzMaster and lucamar
As a Newbie I didn't explain my point very well. Now I have learnt a bit more about Lazarus, I guess I meant that TGIFViewer doesn't act like TImage. I have used TImage on my form, and this appears to load its image in actual code into main.lfm , as opposed to TGIFViewer that just keeps a reference to the image in the user file system (see snapshots attached).
This is not a problem to me, (and thanks for the suggestions), it is just different.
Cheers Rusty