IDE: Tips of the Day

[Blaazen]

* "read more.." link to web page. Using TLabel ?

See Lazarus: Help -> About Lazarus -> tab About , there are two labels used as links.

What do you expect as container of the tips?

Textfile.

[Martin_fr]

A tip of the day would be a good thing. It has to be a package though. And optional (can be switched off, without unistalling the package)

It can be installed and on by default.

But as it stands today, it seems it needs someone to contribute it.

You said that, Martin. Thanks you. I hope it will be integrated within IDE soon or later.

If a contribution is made... (This may include the contribution being adapted to some requests, how to implement some details. / Not going to be picky, don't worry, but maintaining some standard.)

Okay guys, it seem it is more promising now. (Martin is a member of Lazarus Team).

So is Juha. (and a few others on the forum)

I will get a chance to realize "Tips of the day" in a package plus a demo application .
Perhaps, this will also useful for other application outside the IDE project, too.
For first prototype, it would be:
* shows after splash-screen hides

Imho, it should wait until the IDE  has opened all windows (that is as soon as main-ide bar, src edit, messages window are there.
So people already see the IDE, and know they are there.

Otherwise it would be a lonely window, like the setup screen

Code: [Select]

lazarus.exe --setup

* provides a "Never show tips at startup" inside the dialog. Using a checkbox or combobox.

Very good

* a close button.
* "next tip" button
* "read more.." link to web page. Using TLabel ?

Keep the options open, maybe there will be a tips_of_day.chm help file one day.

Tips's source:
AFAIK the best we can provide is HTML based (*.htm), as this standard is well known format.
Because it allow attaching picture / screenshot / animated gif of how the tips works.

If you implement it, then that is your decision. I think TurboPowerIPro works well.

Please note, that by default the tips  database comes with the installer. Downloading new tips (based on IDE version) can be added as option, but should not happen without user consent.

The tips must be organised in a reasonable way (also SVN friendly). First thought would be one file, and images should go into a folder. (and should not be too many large images, I hope to one day reduce the size of the installer, not the opposite)

I would not think of 1 file (text) per tip being a good solution. Though that can be argued.

XML format is possible. Maybe fpdoc can be used? Then there was an editor already.

Alternatively is Mark-down hyper text (*.md) which is easier to edit.
But for this early stage, we can use plain text (*.txt). That doesn't require any parse to display the contents.


My furthest plan is to fetch RSS/HTML online; which is might not set the default behavior of Tips of the Day.
-------------


Well, I have question:
What do you expect as container of the tips?
A. TLabel or TMemo
B. TRichEdit
C. TWebBrowser (embeded).
E. anything else: ..... please tell the component's class name.[/font]

Not TWebBrowser.

Also there will be individual controls for header and content.
Look at TurboPowerIPro

[Blaazen]

I meant this: tips must be managed somehow and also translated. It would be nice to have them i array but AFAIK resourcestrings cannot be arrays.
So my idea is to have textfiles like tips.txt.en, tips.txt.de etc. Each line is one tip. I hope there exists tools to easy translation of plain (UTF8) text files.

[Martin_fr]

I meant this: tips must be managed somehow and also translated. It would be nice to have them i array but AFAIK resourcestrings cannot be arrays.
So my idea is to have textfiles like tips.txt.en, tips.txt.de etc. Each line is one tip. I hope there exists tools to easy translation of plain (UTF8) text files.

Good to mention that. But if you just have one file per language, then outdated translations are not detected.

It will be a minor issue if a tip is simply not available in one language, but tips may have been changed, as the IDE may have been changed. Then translations show an outdated tip.

resource strings have an ID. If a resource string has such big changes, the name of it should change, and therefore all translations will be missing, but none will be outdated.

But resource strings do not work well here.

Yet we can take the idea of an ID. Each entry in the master file (linebased, xml, or fpdoc) should have an ID.
Translation files have the same ID. So tips can be searched.

BTW line based is imho not suitable, a tip consists of at least
- an id
- a header
- a body (may contain image-refs, links,... ) may be very long, and on its own hard to read on one line.
- one (or more) reference to a "read more" (http / chm / ...)
optional
- group tags, such as beginner, expert. Or Designer, Editor, Debugger, ...

[Blaazen]

Yes, it's not so simple after all.

[Martin_fr]

Well yes. It must be thought of.

Same issue exists for the chm help. Only afaik no one translated that yet?
Or fpdoc, and even help hint, that are from comment in source code?

But of course that does not mean we should ignore it when creating something new.

Yet my approach here would be to say, I do not want to burden that entirely on a contributor, if someone wants to contribute it.

I would accept a contribution, that *can* be extended, based on the way it is designed.

For example an xml based, or paragraph based, or ini file format, that includes the concept of an translation ID [1]

Writing a tool, that then generates stub for translations, and/or removes no longer existing entries, is not a condition for acceptance. (It be nice if it was supplied / but if not, I'd still accept the contribution).



[1] A translation ID is supposed to change, if the content changed, because the old content was no longer valid.
This may differ from an ID, used to store "tip was already displayed". The latter may not change.