Hi,

I had a look at PasDoc today. The first time in about 5 years. I see they have this neat search feature built into their generated HTML output. It uses Tipue [http://www.tipue.com/] which is two JavaScript files and one big keyword file.

Could we add this to fpdoc's feature request list? It will come in really handy for FCL or LCL!

Regards,
- Graeme -

We have had this option since day 1 (I used IDKSM from Michael Hess), I just never enable it.

You can very easily enable this option yourself:

fpdoc --html-search=searchpage

If you provide the searchpage + a script to generate the index file, then I'll include it in FPC's docs by default.

Michael.

Ah brilliant. Just did a 'fpdoc --help' and it doesn't mention the --html-search option. I'll have a look in the code.

Graeme.

Michael Van Canneyt wrote

If you provide the searchpage + a script to generate the index file, then I'll include it in FPC's docs by default.

OK, so fpdoc has no notion of creating a index file of any sorts. All that the --html-search parameter does is tell it where to find the search page and to enable the Search link at the top of each page.

If so, I think I almost have Tipue working. I might have to switch from a JavaScript data file to a XML data file. Not sure how well the JavaScript data file will perform on a huge site. I'll do some testing and let you know.

Regards,
- Graeme -

Yes. The rationale being that if we must create an index file, we're tied to 1 type of search engine...

If so, I think I almost have Tipue working. I might have to switch from a JavaScript data file to a XML data file. Not sure how well the JavaScript data file will perform on a huge site. I'll do some testing and let you know.

Thanks !

Michael.

I think it isn't hard to create an index file. We thought about it some years ago, but discussion stopped due to lack of time at my side, and we couldn't find a good file format.

Did you have a look at the content files FPDoc creates for inter-package linking?

Regards,
Sebastian

To be honest, I never even thought of looking in that file. I'll do so way Tipue works (new versions), it can read
from XML files, so I was thinking of creating a simple program to read the FPDoc's xml files and generate a Tipue xml data file. The Tipue xml format is very simple (described on their website) and I've checked, all the information can be gathered from the FPDoc's xml files.

Like Michael said. Keeping the indexing outside FPDoc is not a bad idea. It makes it more flexible to support other existing or future search products.

PS:
Are you the Sebastian that originally wrote fpGUI and fpGFX?

Regards,
- Graeme -

This was another reason why development stopped. There are some old plans about online editing of documentation, real good indexing (especially for HTMLHelp output) and so on, but within the last years I simply had no time for further development, but this will change in the future.

PS: Are you the Sebastian that originally wrote fpGUI and fpGFX?

Yes.
I stopped development after GTK 2.0 has been released, and new developments such as XUL (Mozilla), SWT (Eclipse), AJAX/DHTML and announcements like Microsofts WPF (Windows Presentation Framework) aroused. It wasn't clear at all what major direction general development will follow. Now we know that there is no clear favourite. By now I'm more in favourite of a higher-level framework which can utilize GTK, Qt, Win32, WPF, XUL, DHTML or even fpGUI/fpGFX in a modernized fashion. The toolkit itself isn't as important anymore, IMHO.

Regards,
Sebastian

Sebastian Günther wrote

(especially for HTMLHelp output) and so on, but within the last years I simply had no time for further development, but this will change in the future.

That's always good to here...

> Are you the Sebastian that originally wrote fpGUI and fpGFX? Yes.

In that case, I have to give you a BIG thanks! :) Your idea with fpGUI is what is paying my salary now. I continued development of your code for about a year, just as a hobby. About two months ago we evaluated fpGUI for use in our commercial software. I got the go ahead and started active development working full time on it for the last two months now. I rewrote fpGUI (and the fpGFX backend) from scratch, implementing new design ideas and basing the widgets on a 'windowed' design. Every widget has a window handle. Things are looking great at the moment. :)

will follow. Now we know that there is no clear favourite. By now I'm more in favourite of a higher-level framework which can utilize GTK, Qt, Win32, WPF, XUL, DHTML or even fpGUI/fpGFX in a modernized fashion. The toolkit itself isn't as important anymore, IMHO.

For my employer, being able to have a GUI framework looking and working identical on all platforms was the major selling point. The Lazarus LCL did not work for us. Being able to customize everything, having a very small 3rdParty library requirement and being implemented in Object Pascal (the only language we now use) was another big bonus.

fpGUI has been revived and lives on! :-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

The Lazarus LCL did not work for us.

That's too bad !

What was the problem ? (I'm asking, as I might want to use Lazarus <or a modification of same> for an embedded project which could need a remote GUI access sometimes, but not permanently)

Is the revived version publicly available ? What are it's advantages over the older version and over the Lazarus RTL in detail ?

Thanks for enlightenment !

-Michael

[...this is maybe not the best list to discuss this...]

Let me make one thing clear. The IDE is great, it's just the LCL we have a issue with.
If you develop for a single platform you shouldn't have any issue. Our products need to run under Windows and Linux, and this is where the problems started.

1) We have experienced events firing in different order depending on the platform. This makes event handling very difficult.

2) We experienced events firing multiple times on one platform, but not on another (OnClick or OnSelect events come to mind).

3) One platform supports changing the background color of a Form, the other platform doesn't.

... the list goes on, but I think you get the idea.

Now in some case we could create workarounds and sometimes wrap code with IFDEF's (which defeats the point of Lazarus LCL). This all worked fine until one of those issues where fixed, which means our code breaks again! We got tired of going back and forwards.

Now as I mentioned, if you target a single platform, these issues should go away.

> fpGUI has been revived and lives on! :-) > Is the revived version publicly available ? What are it's advantages over the older version and over the Lazarus RTL in detail ?

Yes it's publicly available. The project is hosted on SourceForge. For more details on the project, advantages and features, have a look at the project website.

http://opensoft.homeip.net/fpgui/

In summary. The new fpGUI is much faster and also uses less code because we take advantage of what the underlying windowing system was designed to do - handle windows, events, clipping etc. No need to rewrite all of that again. We also needed consistency across platforms (which the LCL lacked) as our products will run in 250+ centres which have a mixed install base (Windows and Linux in the same centre, slowly converting some to Linux only). Some of our products also target school kids so tend to be more visual (graphical) and need lots of customization. All these and more are addressed in the new fpGUI.

Thanks for enlightenment !

Always a pleasure. ;-)

Regards,
- Graeme -

I am a bit disappointed to hear this.

1) We have experienced events firing in different order depending on the platform. This makes event handling very difficult.

It is hard to get right, but we make are best attempts to fix these kind of inconsistencies, if they are reported.

2) We experienced events firing multiple times on one platform, but not on another (OnClick or OnSelect events come to mind).

See 1.

3) One platform supports changing the background color of a Form, the other platform doesn't.

I guess you are only limited by the windows backend, while the LCL is also limited by the widget set.

I hope you don't blame us for making bug fixes ;-)

Now as I mentioned, if you target a single platform, these issues should go away.

Single platform LCL kind of defeats the purpose of the LCL.

Vincent

Graeme Geldenhuys wrote

Now in some case we could create workarounds and sometimes wrap code with IFDEF's (which defeats the point of Lazarus LCL). This all worked fine until one of those issues where fixed, which means our code breaks again! We got tired of going back and forwards.

It surprises me you didn't consider fixing the LCL, while you are now writing a complete widgetset yourself. The LCL seems complex, but with some answered questions you may have, it's not exactly rocket science either.

Micha

And so were we experiencing it. :-)

Oh I don't argue that and yes I have reported many bugs already! Even fixed a few. I think all the LCL developers have done an amazing job so far. I can only imagine how difficult it must be to even out all the widget set differences and get a common set of functionality in the LCL - _plus_ make it as Delphi compatible as possible. That is no small task! I think the design choice to use native widget sets was a very ambitious one. Not realizing how different widget sets can be and that maybe implementing their own Lazarus widget set would have been a much easier and quicker task. Just see how much I have accomplished in only 6 weeks (though I'm not near the feature list of LCL yet).

I hope you don't blame us for making bug fixes ;-)

:-) fixes are always welcome, as you know.

Regards,
- Graeme -

I have fixed a few bugs but no matter how much you fix, their will always be some issues. The underlying (native) widget sets are a moving target as they are constantly developed as well.

Also you have other issues to consider:

* Maybe we had bad luck with timing. We used GTK1 because GTK2 was unusable at that stage. Then development started on GTK2 and broke very frequently the GTK1 widget set. We couldn't change to GTK2 at that stage, because it was heavily under development. We had to revert to older Lazarus version where GTK2 didn't break anything and couldn't take advantage of bug fixes available to GTK1.

* What if you find a bug in a Windows component, and that same component under GTK or Qt doesn't have that issue. More workarounds in the Windows layer, because you can't actually fix the bug at hand.

* Then lets talk about native widgets limitations. A simple thing like changing the background color of a button. Not possible under Windows (without a custom button component) but is under GTK.

Reported back in 2005 and still not resolved. Still being discussed (last postings on mailing list dated 18 July 2007) http://www.freepascal.org/mantis/view.php?id=1188

The same I believe was true (but opposite way around in GTK) with Form background color.
Not sure if this was resolved yet. Last time I was told I am not supposed to change the Form's background color, but should let the desktop theme control that. Tell that to WinAmp style apps. We would like to control the look of our applications.
These are _not_ supposed to be complex problems! Using a custom written widget set, such issues could have been fixed in minutes and work on all platforms.

Sorry for the long post... :)

Regards,
- Graeme -

TSpeedButton should be able to do this, since it's custom drawn ?

The same I believe was true (but opposite way around in GTK) with Form background color.

This is an unfortenate one indeed. I'd hardly call it a show stopper though; even can be worked around on LCL level by perhaps implementing some 'OnPaint' or a panel or graphic control on top that draws the requested color. If you want background pictures, which is not a very big step from just a color, you need something like that always.

Micha

It can't be fixed by Lazarus developers because the Windows component lives in the Common Controls DLL? This is just an example by the way, they same could be said for Qt or Carbon.

Graeme.

Graeme Geldenhuys wrote

It can't be fixed by Lazarus developers because the Windows component lives in the Common Controls DLL? This is just an example by the way, they same could be said for Qt or Carbon.

Ah yes. This is indeed a limitation one has to work with.

Micha

I think that in general, this means you simply should not do that, as it will make your program look out of place and not fit in the other apps and the rest of the OS. It will probably make your program harder to use rather than easier, because it doesn't look like people expect it to look.

This distracts for the utility: the automatisms a user has acquired by using many programs suddenly disappears and he'll become conscious of the UI, thinking about decisions on the UI-level (where/what do I click, and what kind of button is this?) instead of only at the action level (what do I want to do).

The only case in which it might help somewhat is for people coming from one platform to another, but the majority of the users will not be in that situation.

Jonas

I agree with you in principle, but I do want to point out that I (and thereby, I assume Graeme also) was talking about bugs in the general sense, not the 'missing feature' sense.

Especially on the Windows platform, where Office does not abide by any Windows GUI rule at all it seems, and everybody follows Office, that surely blurs the distinction between genuine bugs and missing features.

And there are also the features that work orthogonally, that can be added without compromising 'default feel', which is ok to be added in general if wanted, IMHO.

Micha

Micha got it correct on both counts. We were talking about bugs in OS shipped DLL's. If the widget set is based on those GUI dll's, the widget set has to live with them (bugs). My issue was that there could be a bug in the Treeview component of Windows, but not in GTK. If it wasn't detected by the LCL developers, if could be annoying for users (or application developers).

As for the look and feel compared to the OS look and feel. I think that is over exaggerated by *way to many* people and is not that Micha stated, lets take MS Office as an example.
Word, Excel and Outlook does NOT adhere to the normal OS GUI components and style. Yet every body (as in millions of users) are just fine with using Office that looks different compared to any other Windows based app. Now what about the most popular media players - WinAmp and Windows Media Player. Again they do not adhere to the normal GUI look, yet is the most popular players around. The list goes on, but you get the point.

As for fpGUI's look and feel. Currently we are basing the look on Windows 2000 (or Win XP classic). The users color scheme will be detected and used as well (on all OS's). Other themes will also be built into fpGUI in due time. Themes like a native XP Luna or Silver look or ClearLook under GTK2, BlueCurve and Motif (just like Qt did). Image based themes will follow later which will give a unlimited amount of looks (like WinAmp does).

My employer already stated that they want a different look to standard Windows apps when we deploy to our 200+ centres, so that the application can stand out a bit. Just the look though, not how the components (application) works.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Micha got it correct on both counts. We were talking about bugs in OS shipped DLL's.

I only read something about not being able to set the color of a button. That may be an OS bug of course, but it may also be intentional.

As for the look and feel compared to the OS look and feel. I think that is over exaggerated by *way to many* people and is not that guess this may depend on the platform. On Windows, a lot of

applications may indeed go their own way anyway, so there may not be much of a standard look&feel at all which people expect. OTOH, there are definitely some things which people do not want at all, given the large outcry which occurs any time Apple tries to emulate half of the Mac OS X look&feel in Windows ports of its applications (and not just because of the slowdown this causes).

To be honest, I know few people who consider MS Office easy to use (except for the things they know because they have done it so many times already) or an example of good usability. That's obviously not just because of the way it looks, but that doesn't help either.

Now what about the most popular media players - WinAmp and Windows Media Player. Again they do not adhere to the normal GUI look, yet is the most popular players around. The list goes on, but you get the point.

Such applications can be special cases. They emulate a special purpose (electronic) device, and in that case there is no problem with also emulating interface conventions of such devices (again, because it is something that people are used to). The same goes for e.g. a calculator or a video editing app. Similarly, games often can have a completely custom interface without any problems because it enhances the immersion factor, which is much more important there than interface conventions.

My employer already stated that they want a different look to standard Windows apps when we deploy to our 200+ centres, so that the application can stand out a bit. Just the look though, not how the components (application) works.

At least not in the OS versions you are basing the operation of your component on. And often things like accessibility functionality for e.g. the visually and hearing impaired come free with OS components, while they may require special purpose (and OS-specific) code in your own components.

Jonas