Hi,

Has anybody studied or tried to implement the Java 'Document' model yet? Every text Swing component (JTextArea, JTextEdit, JTextPane etc) uses the Document class internally to represent the text content. Is seems very easy to use and extend like they did for the Styled Document (HTML, RTF etc...). It also supports document/text filters for things like Tab Stops, Elastic Tabstops, Spell Checking, Syntax Highlighting etc.. Quite a powerfull component which can be used for simple one line text components like TEdit and scale to complex text components like text editors or HTML, RTF viewers/editors.

I'm researching the posibility of implementing the Document, Elements, Position, AttributeSet etc interfaces in Object Pascal for use with the text components (TextEdit, Memo, ComboBox etc) in fpGUI. The above classes will be toolkit indepenent, but builds a very flexible base to use in any text based components.

I thought I would first ask here if anybody has done something like this already? I don't want to duplicate work if it's already done by somebody else and freely available.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I forgot to add a link for those that don't know what I'm talking about. ;-)

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/AbstractDocument.html http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/PlainDocument.html http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/DefaultStyledDocument.html

Graeme.

2008/6/25 Graeme Geldenhuys :

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I have the feeling that Swing uses this wherever text is used. This is why you can set a JLabel's caption to "<html>This is <b>some bold test</b> near an image <img src='foo.png'>" and having it working. This provides a lot of flexibility. And this is one of the reasons why Swing is *so* slow :-). In a program of medium size i did in Java which was in Swing, i used this feature only once. Yet i could do without it if the toolkit was a little more faster.

Please don't bring stuff like this to LCL. Or at least make them so optional one can throw them out completelly if not needed. Anything more elaborate than:

Canvas.TextOut(X, Y, FCaption);

for a pushbutton is a waste of resources in most cases.

2008/6/26 Kostas Michalopoulos :

OK, you are understanding the Document Interface incorrectly. But I think you are correct about any Swing component that stores text, using the Document Interface. The Document Interface is where the content (text) is stored, it's nothing visual. Think of the Document as a String/TStringList replacement. It's up the the individual component to decide how to paint the content.

The Document Interface has some nice advantages. Because the data/text (content) is abstracted, it's easier to implement things like Model-View-Controller. Different behavior is very easily added to the Document via filters (eg: auto spell check, uppercase all text, filter out tab characters or other not printable characters etc..). And these filter can be reused with other components supporting the Document Interface. The other really nice benefit is that different components can share the same Document. Hence they will always be in sync and only have a single instance in memory. This could be very handy for SynEdit if it supports multiple views into the same document (eg: Editor window is split in two and each part is viewing different sections of the same text document. Edit one and the other is automatically in sync.).

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

While this is all certainly true, it's simply overkill for 99% of the cases, and adds a lot of memory and parsing overhead. Simplicity is a virtue in design.

Michael.

Maybe you should try to create a synedit that implements the document interface? I'm sure it works for trivial components, but only if you try it will real components you know if it makes sense.

There are some downsides to this approach I can imagine (though some apply less to owner draw widgets sets as afaik Swing i):

- You have one datastructure for all widgets, and are stuck with it by design. No ability to have your own design of datastructure if needed (e.g. the gap buffer you mentioned yourself)
- You can't use widgetsets datastores. (admitted, those are rare) This partially also is like the first one, if the interface of the datastructure of the widgetset and the document model don't match in philosophy you'll
have to twist yourself to get it done.
- You have to call a lot of methods/handlers that won't be overriden that often, just in case. Performance bottleneck.
- Java String is OOP, but a Pascal string is not. The fully OOP paradigm thus might not translate as well. (otoh, the java string might be mostly final, and then it is not that much of a problem. Java has been too long ago for me to reproduce that from memory)
- You have to rework all existing source to match your new interface.
- Lazarus doesn't allow reworking the datastructures in the first place because of Delphi compat.
- If Lazarus is to be built on top of fpgui, and fpgui has/requires its own datastructures that might create a double datastructure problem. Most widgetsets only require callbacks that govern what is in the current view, not the whole data.

All of this is stuff you usually only find out in practice. Hence the remark to try it out with a few non trivial components before you decide to force it on (fpgui) programmers globally. In general I think this is more something for a 2.0 or even 3.0 release, when the consequence are more clear, and there has been lots of experimenting.

2008/6/26 Marco van de Voort :

You raise some valid points. I was planning to implement it for one component first. A styled document viewer. Something to view HTML, XML, RTF etc... After that, I would start experimenting with other text based components.

BTW:
In Swing there are two implementations of the Content interface: GapContent and StringContent. GapContent is the optimized one. StringContent simply holds the values in a string array. The latter is handy for debugging, but slow on large text. The Content implementation classes are interchangable in any Document type component. So the datastore can I said, the Document Interface is very flexible. :-) No wonder most institutions use Java as a teaching language. They use design patterns and good OOP techniques often.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I understand what Document is, as i said i've used it before. It is just one of the cases where too much flexibility is as bad (or worse) as no said in other branches of this thread, this can be ok for some cases but in most cases you won't need this extra complexity. Nothing is simpler and faster than

DocData:='sometext';
...
TextOut(X, Y, DocData);

for *most* cases, at least. The cases where a simple approach is not efficient enough, can have a different implementation. But these are special cases you don't see used often in a GUI (as also mentioned, in the whole Lazarus IDE only SynEdit could benefit from it and the rest of the GUI would only have increased memory/cpu requirements because of the extra abstractions to make these things work).

Kostas Michalopoulos wrote

for *most* cases, at least. The cases where a simple approach is not efficient enough, can have a different implementation. But these are special cases you don't see used often in a GUI (as also mentioned, in the whole Lazarus IDE only SynEdit could benefit from it

I agree that a TLabel or TEdit using a Document Interface, might be overkill. I'll do performance tests with those when I get there...

As for SynEdit being the only component that could benefit from it. I think not. :) SynEdit, TMemo, TRichView, THTMLView (or whatever it's called to display HTML like in the CHM Help Viewer), LazReport could also use it. ListBox, ComboBox could use it (though I personally think it's madness to have 100's or 1000's of items in those. StringGrid is another posibility.

But in the end, it comes down to trying it out with a basic implementation like SimpleDocument and getting a feeling of how it works. Then later implement the StyledDocument if things go well.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I think it's not that easy. The HTML viewer will have to be very flexible to support this kind of stuff. Let's say it just stores in memory what you are currently viewing, and there is a <b> in the start of the html document that goes all the way down to the end. How will the HTML component parse it if that <b> isn't in memory? Since we are storing pure text, it needs to parse in real-time.

Also in SynEdit the biggest unit I have ever seen is FPCMacOSAll with 100.000 lines, and even there SynEdit works nicely.

The only use I see would be for turning TMemo into a notepad capable of viewing huge files, but then maybe we should have another component for this.

My point is: Don't optimize unless you have actually tested and this is a bottleneck, or else you will probably just make things worse.

About Java use in education what I see most is Java use in my university in places where it is absolutely not a good choice. Some example. They made a 3D Game library in Java in a laboratory. Surprisingly their biggest problem is that its't so slow it's unusable <g>

Also they were trying to teach us to build a assembler, a relocator and a linker in Java. Which sane person would do this kind of low-level tasks in Java? So the operating system needs to relocate a software in the next 10 milisseconds? Just wait until the virtual machine starts ...

2008/6/26 Felipe Monteiro de Carvalho :

I think it's not that easy. The HTML viewer will have to be very flexible to support this kind of stuff.

It clearly is, because sun.java.swing.text package contains an HTML and RTF viewer and editor. :-) They seem to work very well actually. Then there was also the Java based web browser from ages ago, but I think that was before Swing, so don't know what they used there.

Also in SynEdit the biggest unit I have ever seen is FPCMacOSAll with 100.000 lines, and even there SynEdit works nicely.

And one of the Qt and Java tests, for reasons beyond me, is to paste 1Mb of text in a TextEdit component. No slow down in painting, moving the cursor or scrolling the text is experienced. So it scales very well.

My point is: Don't optimize unless you have actually tested and this is a bottleneck, or else you will probably just make things worse.

Good point. I'll test this by implementing a styled document viewer (and possibly editor) for HTML and RTF and see how it goes.

university in places where it is absolutely not a good choice. Some example. They made a 3D Game library in Java in a laboratory. Surprisingly their biggest problem is that its't so slow it's unusable

I cannot say what is the cause of the slowness in Swing or AWT. But I must say, I have seen very impressing 3D demos using Java and they where silky smooth. How they did it is beyond me, but I was very impressed! Pitty those developers couldn't help speed up the Java GUI components.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

1Mb = 1 mega byte?
That's not very impressive.
Or do you mean 1Mb = 1 million blocks?
Please try something like fpc/packages/univint/src/MacOSAll.pas. Jump to the end of the file and see what happens to the highlighting and your CPU.

Do you mean you want to write a complete HTML viewer?

The trick of many 3D programs is to let the graphic card do the work. This is language independent and says nothing about the compiler.

Mattias

And one of the Qt and Java tests, for reasons beyond me, is to paste 1Mb of text in a TextEdit component. No slow down in painting, moving the cursor or scrolling the text is experienced. So it scales very well.

I just dumped 100mb of (generated) pascal source code in SynEdit. There is no slow down in painting or moving around and syntax highlighting seems to work perfect. In fact i can scroll from the top to the bottom and back without any slowness. I tried the same file in jEdit and scrolling beyond a few thousand lines had a delay of a couple seconds. Modifying the code is instant and we're talking about 5 millions of lines. Although i doubt any sane unit will reach that point, it shows that even if it does, Lazarus can edit it.

Kostas

Le vendredi 27 juin 2008 ? 01:20 +0200, Mattias Gaertner a ?crit :

> Good point. I'll test this by implementing a styled document viewer > (and possibly editor) for HTML and RTF and see how it goes. Do you mean you want to write a complete HTML viewer?

I'm really interested by this, as I red in this list that integrating a mozilla based html viewer 'd be tricky!

Mattias Gaertner wrote

1Mb = 1 mega byte? That's not very impressive.

I meant 1 mega byte into a TEdit. It's actually amazing howmany toolkits can't handle that.

Please try something like fpc/packages/univint/src/MacOSAll.pas. Jump to the end of the file and see what happens to the highlighting and your CPU.

That is impressive. SynEdit handles a 10.2Mb file without problems. Even Gnomes gEdit slows down on that file, but it's way better that KDE's Kate or KWrite editors. The latter two are quite slow, until it's all caches. Even Midnight Commanders internal 'mcedit' editor works quicker than KDE's ones. That's clearly something the KDE developers screwed up - seeing that Qt rates performance quite high.

Do you mean you want to write a complete HTML viewer?

A basic HTML viewer yes - no CSS etc. What I am interrested in at the moment is something that can display styled text (be that HTML, RTF or something custom). At the moment I'm only interested in text attributes like bold, italics, underline and different fonts and different size characters. That will do - all the others features will be bonus extras. Something simple I can use to display basic help to users - better than plain text.

The best solution would obviously be to embed Mozilla into a Free Pascal application. I still don't have success with that, but continue trying. If anybody has had success, please let me know.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Mattias Gaertner wrote

Please try something like fpc/packages/univint/src/MacOSAll.pas. Jump to the end of the file and see what happens to the highlighting and your CPU.

This brings up another point. The thumb button size in scrollbars. Why the hell must the thumb button be 7 pixels in size. My laptop has a 1600x1200 display, that means I need to *precision click* on something 0.43% (horizontal) or 0.58% (vertical) of my screen size. That's 7 pixel big!!! Even my mouse cursor is bigger than that! See attached screenshot.

Why can't the minimum size of the scrollbar thumb button be something like 50-70 pixels. It will have no affect on the scrolling ability. I'm sure it's another native widgetset limitation, but something fpGUI has already overcome. fpGUI can dynamically resizes the thumb button based on the parents content size, but will not go smaller than the set minimum size (definately not 7 pixels).

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scrollbar.gif
Type: image/gif
Size: 3904 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080627/d4d57e2b/attachment-0001.gif

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080627/b4149877/attachment.pl

It's the same for some commercial editors.

ok.
And the concurrency support?

The best solution would obviously be to embed Mozilla into a Free Pascal application. I still don't have success with that, but continue trying. If anybody has had success, please let me know.

Ask Michael VC.

Mattias

FWIW:

I tried that in JEdit (a Java editor having pascal syntax highlighting using the swing toolkit). It appears that:

- I had to increase the java heap size to get that file loaded (in a session having 15 or so other files, some small, some big) from 32MB to 64 MB - other programs would not have this limit but suck in system memory at will

- loading the file took some time (~1-3 seconds) amongst all other files

- when hitting CTRL-Down the first time the CPU usage goes up a noticable step and a short pause occured (~2s)

- when browsing around by keyboard after the first move to the eof I did *not* note any slow down or extraordinary load

- when scrolling the file using mouse and scrollbar the cpu load does go up, but it works without delay

Concluding I'd say JEdit handles this file without problems.

Marc

I have a problem building the last SVN (15674).
The error is:

C:\lazarus\components\codetools\PPUGraph.pas(442,33) Error: Identifier not found "SharedSuffix"
C:\lazarus\components\codetools\PPUGraph.pas(808) Fatal: There were 1 errors compiling module, stopping

The problem is into the function UpdateLoader (object TPPUGroup)

Note: I use FPC 2.2.0 on Windows XP Professional

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw_dept.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080704/8a65d6e7/attachment.vcf

I added an IFDEF VER2_2_0.

Fixed?

Mattias