Re: [lazarus] New help doc format?
On 10/05/06, L505 [EMAIL PROTECTED] wrote: browsing around. I would NOT want all my HTML files compiled into one file because I want to look into each html file and see how it is designed - plus single files are more prone to corruption than multiple files. I think you are one of a selected few. CHM is basically compiled html files into one file. Why would I want to see the code of each help file I am viewing. All I want in the content. A single file is great for distribution (smaller and easier to copy) compared tho say a 1000 html pages with there external images in the mix. Also the corruption comment makes no sence. How often does CHM files get corrupt? It's never happened to me (maybe I am just lucky) Why would any other single compressed file be any different? That would be like saying any .zip or .rar or tar.gz file is not a good idea. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
On 10/05/06, L505 [EMAIL PROTECTED] wrote: Does Apache Server work on Windows CE? So I shouldn't use Apache for a webserver, just because it isn't truly cross-platform? Sometimes people get carried away with the whole cross platform advantage - when really there would be no advantage of having Dude, you are missing the point completely!! Apache run on Windows CE. I don't know why anyone would write or read documents on a small Windows CE computer. Maybe if you are on an airplane and you only have your GameBoy with you - how will you read the Docs? Windows CE is just like any other platform!! Windows, Linux or OS X. Just because it's a small form factor makes no difference. Loads of people make a living writing software for the PDA market. I have helped develop a Time Sheet software package for a 2000+ employees company in the UK, and yes the application needed a help file (as does any good software application)! Why may the PDA market not have help files? It is a software application that should be shipped with help. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 10/05/06, Vincent Snijders [EMAIL PROTECTED] wrote: Not a new format, but a portable format: CHM, with a viewer built with fpc/lazarus. Just to clear things up... When you say CHM, do you mean something like what CHM does, or the exact CHM format? Isn't CHM a proprietary / patented format from Microsoft and we would get into trouble using the exact CHM format? Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Graeme Geldenhuys wrote: On 10/05/06, Vincent Snijders [EMAIL PROTECTED] wrote: Not a new format, but a portable format: CHM, with a viewer built with fpc/lazarus. Just to clear things up... When you say CHM, do you mean something like what CHM does, or the exact CHM format? Isn't CHM a proprietary / patented format from Microsoft and we would get into trouble using the exact CHM format? Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Michael Van Canneyt wrote: Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Open Standard or 'de facto' Standard ? Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On 10/05/06, Al Boldi [EMAIL PROTECTED] wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. 1) Please do not forget, that then you will be able to Search / Replace on component properties if they are in code! Currently the Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you do a normal search. 2) As anybody accidently deleted a component from a form. Afterwards, you don't have a clue as the what custom options where set and what other components it linked to. Have then is lines of code minimizes this issue (yes Source Control software does help in such cases, but not everybody uses source control software - poor folks). dfm format is compatible with Delphi, so I can build the same software with both. Yes, so keep a compatibility option. Why bother! If it is in code, Delphi will be able to build that code just fine! Delphi will not be able to view the form, but building is not an issue at all. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
On Tue, May 09, 2006 at 05:05:18PM +0200, Giuliano Colla wrote: Graeme Geldenhuys ha scritto: [...] What does Qt offer in help formats? Qt provides standard html files, and a navigation program called assistant, which provides a sidebar, and other navigation tools, but they specify that a standard browser can be used instead. No particular file format, hyperlinks to navigate, very simple and effective. You can bookmark, remember the history, and exploit all the features of a browser without any particular effort. Building help files requires the same work as for wiki pages. As a user I found it much better and faster than most of the other help systems. As compared to Delphi/Kylix help system, IMHO it's significantly faster and more stable. Giuliano I'm actually the italian gimp and gimp manual translation team manager. GIMP help system is based on DOCBOOK source format, is inherently multilingual, multiple output format ready and has a context sensitive search that works on the HTML result files, creating the pdf indexies too. My suggestion is to: - use HTML as the target format (so user can always use any HTML file browser he/she likes) - start with multilanguage translation in mind. IMHO an docbook only solution is clumsy without some form of source language control/revision system. I see better a system like the following: gettext/po files-xml(docbook?)-output(html/pdf/hlp in order of priority) But _please_, use HTML as the final format and do enable the textual ide to use it! bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Overview Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. The man pages are not the only help format in Unix. In Linux/Unix there are also the info pages , which do support links. Some info pages also have an index ( i'm not sure when this index is generated) . The program is called 'info' . Info can be used to acces the regular man pages, too. (plus you can go to the related items in SEE ALSO by simply going on the item and pressing enter). By googling for more info about info, i've found that Info is in fact the official documentation format of the GNU project : http://www.gnu.org/software/texinfo/ Info might be really interesting : it is possible to generate several help formats from a single source : html, pdf, info, dvi, xml . Adrian Maier _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Adrian Maier wrote: On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Overview Windowze has 2 help system versions (*.hlp files and *.chm files). Un*x based systems have man (doesn't have links, discarted, sorry). I heard that *Linux (GNU/Linux, and others) doesn't have one. The man pages are not the only help format in Unix. In Linux/Unix there are also the info pages , which do support links. Some info pages also have an index ( i'm not sure when this index is generated) . The program is called 'info' . Info can be used to acces the regular man pages, too. (plus you can go to the related items in SEE ALSO by simply going on the item and pressing enter). By googling for more info about info, i've found that Info is in fact the official documentation format of the GNU project : http://www.gnu.org/software/texinfo/ Info might be really interesting : it is possible to generate several help formats from a single source : html, pdf, info, dvi, xml . This info is generated from texinfo, a variant of TeX/LaTeX. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). .po is not suitable for translation of documentation. translations should be done completely separate. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). .po is not suitable for translation of documentation. translations should be done completely separate. Michael. Good point. It seems that we are closer to consent. XML is fine , we only need : 1. a tool to export to various formats (HTML,PDF,CHM - all with index if possible) 2. a tool to index XML (full text search-help index) - for IDE usage (context help and others) Regards Boguslaw _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 11:08:15AM +0200, Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). po is not suitable for translation of documentation. translations should be done completely separate. Seems that both kde gnome folks do not know that what they are doing is not possible :-) http://l10n.kde.org/docs/translation-howto//doc-translation.html#doc-conversion so po2xml tool what is for about? -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Michael Van Canneyt wrote: On Thu, 11 May 2006, Micha Nelissen wrote: Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. My opinion too. Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. Remember, the DFM thing is really a copy-cat of VB's FRM format. So from a modularization POV it's great, but from an implementation POV it feels like someone who has no-clue (script-addict) implemented it. GExperts has an expert 'Components to code' which could be easily ported to Lazarus. This can create a procedure which recreates (in code) a number of selected components. This can be a useful addition. I agree, but remember that this should be 2-way, so some design time plugin would be necessary. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Al Boldi wrote: Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. It is not a language, let alone a scripting language. It's just PROP = VAL basically, but in OO-style. Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/11, Michael Van Canneyt [EMAIL PROTECTED]: On Thu, 11 May 2006, Micha Nelissen wrote: Michael Van Canneyt wrote: Whatever the answer, I'd rather go for the OpenOffice format: it's an open standard. Open Standard or 'de facto' Standard ? Open, I would say ? Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). OASIS / ISO http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43485scopelist=PROGRAMME More info: http://en.wikipedia.org/wiki/OpenDocument (In all url, change 'en' for 'fr' to get the french version. Might work for other languages as well.) I'm very much for the open document format, but I don't know if it can serve a help file very easely. But I suggested that format in another thread :) Regards. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, 11 May 2006, Marco Ciampa wrote: On Thu, May 11, 2006 at 11:08:15AM +0200, Michael Van Canneyt wrote: On Thu, 11 May 2006, Marco Ciampa wrote: On Wed, May 10, 2006 at 10:41:22AM -0500, [EMAIL PROTECTED] wrote: So, the file format must be an Open Standard. Definitely! Comments Please feel free to add any missing requirement. Source file must be thought to be easy for nationalization (i. e. use .po files in the source). po is not suitable for translation of documentation. translations should be done completely separate. Seems that both kde gnome folks do not know that what they are doing is not possible :-) http://l10n.kde.org/docs/translation-howto//doc-translation.html#doc-conversion so po2xml tool what is for about? I didn't say 'possible', I said 'suitable'. Looking at the website: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Changing 1 letter in the documentation text would completely kill your po2xml output, since it is based on textual search. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006, Al Boldi wrote: Michael Van Canneyt wrote: On Thu, 11 May 2006, Micha Nelissen wrote: Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. My opinion too. Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. Remember, the DFM thing is really a copy-cat of VB's FRM format. I think exactly not: VB's frm files contain the code as well. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Source file must be thought to be easy for nationalization (i. e. use .po files in the source). Maybe a source format file combination of *.po files and a XML file: xml title path= title.po / contents path= contents.po / /xml So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. Sounds fine. -- Marco Ciampa - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
XML is fine , we only need : 1. a tool to export to various formats (HTML,PDF,CHM - all with index if possible) 2. a tool to index XML (full text search-help index) - for IDE usage (context help and others) It's seems we're getting to something similar to a html source file format and an open source chm destination file format that supports indexes... - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
2006/5/11, Michael Van Canneyt [EMAIL PROTECTED]: On Thu, 11 May 2006, Al Boldi wrote: Michael Van Canneyt wrote: On Thu, 11 May 2006, Micha Nelissen wrote: Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. My opinion too. Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. Remember, the DFM thing is really a copy-cat of VB's FRM format. I think exactly not: VB's frm files contain the code as well. I totally agree. The code must be separated from the interface. I'm currently coding in a language that combines both, even the object encaptulation. It is a nightmare. As for the binary aspect of files, yep, the form files could be code a little bit more, and binary data escaped. But asside that the actuel structure is very good: code / form / ressources. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
As an answer just look into way in which wxWidgets framework is developed - XML based dialogs in zip file and totally separate source code (with only some functions to load and initiate dialogs). Completely separated GUI and logical code! This is positive,and Lazarus is not too much behind this fashion. Regards Boguslaw _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. 1) Please do not forget, that then you will be able to Search / Replace on component properties if they are in code! Currently the Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you do a normal search. You can still search and replace - you just store all the design time components in an include file. Instead of design time components via an DFM object file, you use an include file with true Pascal code, not DFM object code. When you search for stuff in your code, the include file is not searched - just as the DFM file is not searched when you search in Delphi. The include file hides all the design time code so it does not bloat up your code logic with design code. There are real world examples out there that uses this exact system. KOL/MCK does it inside the Delphi IDE, and there is no difference between editing a property of a MCK component from editing a property with a DFM component - the only problem was that Delphi is designed highly around a DFM system - so KOL/MCK had to implement tricks to get it working in Delphi. But with an IDE that is not proprietory, no tricks would be needed. Back when I started using delphi, I wondered what black magic was creating my forms for me? Why couldn't I see and tap in to the code that created my forms? I guess curiosity kills the cat. 2) As anybody accidently deleted a component from a form. Afterwards, you don't have a clue as the what custom options where set and what other components it linked to. Have then is lines of code minimizes this issue (yes Source Control software does help in such cases, but not everybody uses source control software - poor folks). You still use a component pallette and visual design. You still delete and link components together. All components are still linked to each other the same way. You just link the components through the code instead of through an object format. Take Synedit for example: Synedit1.highlighter:= SynPasHighlighter; Your highligher is linked to your synedit component. Instead of unlinking it and linking it within the DFM file, you do so in the include file with real code in it. There's no difference from an end user perspective who is using the IDE - components being dropped on the forms will act just the same as if you were using a DFM file. There are advantages and disadvantages of using real code versus using DFM files. DFM files are a cleaner format than actual Pascal code. Real code is easier to peak into and copy/paste than DFM files (but a DFM to code converter can be made). DFM files make the exe bigger in size than run time code, generally speaking. Now the question is: what does Java do this in its Visual ide's? Does it create an include file with component properties stored as real Java code - or does Java dump all the code into your Java source files and not modularize it? I'm interested because I haven't tried any visual Java ide's. Or does Java use some JFM format in some ide's ? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006, [UTF-8] BogusÅaw Brandys wrote: As an answer just look into way in which wxWidgets framework is developed - XML based dialogs in zip file and totally separate source code (with only some functions to load and initiate dialogs). Completely separated GUI and logical code! This is positive,and Lazarus is not too much behind this fashion. Not too much behind ? It was first :-) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006 12:03:59 -0600 L505 [EMAIL PROTECTED] wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. 1) Please do not forget, that then you will be able to Search / Replace on component properties if they are in code! Currently the Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you do a normal search. You can still search and replace - you just store all the design time components in an include file. Instead of design time components via an DFM object file, you use an include file with true Pascal code, not DFM object code. When you search for stuff in your code, the include file is not searched - just as the DFM file is not searched when you search in Delphi. The include file hides all the design time code so it does not bloat up your code logic with design code. There are real world examples out there that uses this exact system. KOL/MCK does it inside the Delphi IDE, and there is no difference between editing a property of a MCK component from editing a property with a DFM component - the only problem was that Delphi is designed highly around a DFM system - so KOL/MCK had to implement tricks to get it working in Delphi. But with an IDE that is not proprietory, no tricks would be needed. Back when I started using delphi, I wondered what black magic was creating my forms for me? Why couldn't I see and tap in to the code that created my forms? I guess curiosity kills the cat. You can edit the .dfm. Just not the form and the dfm at the same time. 2) As anybody accidently deleted a component from a form. Afterwards, you don't have a clue as the what custom options where set and what other components it linked to. Have then is lines of code minimizes this issue (yes Source Control software does help in such cases, but not everybody uses source control software - poor folks). You still use a component pallette and visual design. You still delete and link components together. All components are still linked to each other the same way. You just link the components through the code instead of through an object format. Take Synedit for example: Synedit1.highlighter:= SynPasHighlighter; Your highligher is linked to your synedit component. Instead of unlinking it and linking it within the DFM file, you do so in the include file with real code in it. There's no difference from an end user perspective who is using the IDE - components being dropped on the forms will act just the same as if you were using a DFM file. Binary properties can be difficult to set in code. There are advantages and disadvantages of using real code versus using DFM files. DFM files are a cleaner format than actual Pascal code. Real code is easier to peak into and copy/paste than DFM files (but a DFM to code converter can be made). DFM files make the exe bigger in size than run time code, generally speaking. DFM make the exe smaller. It is the streaming code, that needs quite a lot of code. But this is a rather fixed amount. So for big applications or if the library is in a .dll/.so the DFM mke the exe smaller. Now the question is: what does Java do this in its Visual ide's? Does it create an include file with component properties stored as real Java code - or does Java dump all the code into your Java source files and not modularize it? I'm interested because I haven't tried any visual Java ide's. Or does Java use some JFM format in some ide's ? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
Does Apache Server work on Windows CE? So I shouldn't use Apache for a webserver, just because it isn't truly cross-platform? Sometimes people get carried away with the whole cross platform advantage - when really there would be no advantage of having Dude, you are missing the point completely!! Apache run on Windows CE. I don't know why anyone would write or read documents on a small Windows CE computer. Maybe if you are on an airplane and you only have your GameBoy with you - how will you read the Docs? Windows CE is just like any other platform!! Windows, Linux or OS X. Just because it's a small form factor makes no difference. Loads of people make a living writing software for the PDA market. I have helped develop a Time Sheet software package for a 2000+ employees company in the UK, and yes the application needed a help file (as does any good software application)! Why may the PDA market not have help files? It is a software application that should be shipped with help. You are right - I thought we were purely talking about the documentation for the FP compiler and the Lazarus IDE itself. When I am a developer I usually have a LCD/CRT monitor and would never ever read freepascal compiler documentation on a Windows CE computer or Lazarus Documentation. If we are talking about a generic help system for applications that are generated with Lazarus - then it is a different story. Although, like I pointed out - SQLite does appear to be available for Windows CE - so my case doesn't change. But then again, I'm not really advocating SQLite - it would be nice to use a Pascal based help system. What I'm mainly trying to point out is that if we are going to be doing indexing and sorting, are we not reinventing the database - since databases do all these things for us? Why would we want to index XML files if we can dump the content into the database and have it indexed for us by the database? In otherwords - does the developer really want to spend time reinventing an indexing system when someone has already done that for us in the database? In some cases, we must reinvent a bit in order to have a nice custom solution. So would everyone please point out the reasons we cannot make use of a database and why we really need to invent our own help database - if there are plenty of databases out there. Also - will the custom database solution like CHM (I consider CHM basically a reinvention of a database - a custom one) be web ready? i.e. can I upload the CHM file to the internet and create a web program that allows users to search the documents on my website? With a real database you can upload your help documents to a web server and create a web program that searches your docs. Then your company will get much more promotion if your help files are online in addition to you offering an off-line doc system. So can CHM be searched, indexed, etc. online on the web, too - and not just offline? with several people querying it at once? I think CHM is mainly designed for one person querying it. With a real database I would ship a small embedded database to the user - which one user can query comfortably. But then use a full fledged firebird/mysql style database on the web server to serve the docs to hundreds of people. Can CHM some how be uploaded to the web and have multiple people querying it with reasonable speed? Or must a real database be used? If a real database must be used - it means that you will then have to convert that CHM file to a real database anyway - so you now have double the work instead of just using a database in the first place. Are there enough advantages of NOT using a database. That's what needs to be decided. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
I think you are one of a selected few. CHM is basically compiled html files into one file. Why would I want to see the code of each help file I am viewing. All I want in the content. A single file is great for distribution (smaller and easier to copy) compared tho say a 1000 html pages with there external images in the mix. Well I like having the HTML available that I can edit in a source file in case I need to print the documents and the current format is not good for my printer. Sometimes I change the font size of the documents so I don't waste as much paper. I don't like having the file hidden in some CHM file that I can never have access to with my bare hands. If there is a CHM decompiler that is legal to use and not illegal then that would be good. Or if you offered HTML and CHM that would be good - can you extract all the HTML out of CHM legally? Because one time I tried to decompile a HLP file and it turned out to be a huge mess. Also the corruption comment makes no sence. How often does CHM files get corrupt? It's never happened to me (maybe I am just lucky) Why would any other single compressed file be any different? That would be like saying any .zip or .rar or tar.gz file is not a good idea. Well when I back up my hard drive I do not dare put it into one zip file. I've had 3GB zip files damaged before. Instead I use several zip files instead of one big one. But in the case of a CHM file corruption is not much of an issue since it probably won't be written to often, and the user can redownload the CHM file any time he wants. I've also had several microsoft formats go corrupted on me such as giant email files that are stored in binary form in one big file. Losing all your email is not fun. But for CHM format, again, it is not as big of an issue since you could always download the CHM file again. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Back when I started using delphi, I wondered what black magic was creating my forms for me? Why couldn't I see and tap in to the code that created my forms? I guess curiosity kills the cat. You can edit the .dfm. Just not the form and the dfm at the same time. The DFM never told me when the components were created and freed, was what I was getting at. I wondered, as a beginner, what black magic allocated and freed the memory to create those forms. Long ago I was learning about run-time component creation and I wanted to modify my design time forms to be run time, by finding the actual code that freed and allocated the design time forms. I was looking for the code so I could turn my components into run time ones without writing all the run time code myself. I wanted to peak into the code and find out where form1 was created and freed.. couldn't do it. (could have maybe if I knew about GEExperts component to code tool). 2) As anybody accidently deleted a component from a form. Afterwards, you don't have a clue as the what custom options where set and what other components it linked to. Have then is lines of code minimizes this issue (yes Source Control software does help in such cases, but not everybody uses source control software - poor folks). You still use a component pallette and visual design. You still delete and link components together. All components are still linked to each other the same way. You just link the components through the code instead of through an object format. Take Synedit for example: Synedit1.highlighter:= SynPasHighlighter; Your highligher is linked to your synedit component. Instead of unlinking it and linking it within the DFM file, you do so in the include file with real code in it. There's no difference from an end user perspective who is using the IDE - components being dropped on the forms will act just the same as if you were using a DFM file. Binary properties can be difficult to set in code. Like images/resources? There are advantages and disadvantages of using real code versus using DFM files. DFM files are a cleaner format than actual Pascal code. Real code is easier to peak into and copy/paste than DFM files (but a DFM to code converter can be made). DFM files make the exe bigger in size than run time code, generally speaking. DFM make the exe smaller. It is the streaming code, that needs quite a lot of code. But this is a rather fixed amount. So for big applications or if the library is in a .dll/.so the DFM mke the exe smaller. You say DFM make the exe smaller, period. But you should say - DFM make the exe smaller in some cases only. : Because I've never seen a DFM exe smaller than a non-DFM exe myself, but I'll take your word for it. All the applications on my hard drive are several small and only some medium size programs - I make a lot of small utilities with only 1-5 forms in them. I don't make many large applications that exist all inside one exe - most of the time I make a bunch of small programs - then if I have one large program where I think a small add-on would be useful, I make a plug in system. So it depends what the threshold is where the DFM does make the EXE smaller, I guess. If it requires that 5-10MB exe size exist before you start seeing gains in exe size - that doesn't really affect me.. with the work I do. I generally like to make the program have a plug-in system once it gets that large anyway, so it would actually be more advantageous for me to have a lower threshold. Do you know generally what the threshold is before you have seen the exe become smaller from using DFM? 5MB? 6MB? Lazarus is quite a nice and big application and is only 6MB. I would think lazarus would be maybe 10MB in size, but it is only 6MB. So maybe we are seeing the threshold kick in here? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006 13:36:23 -0600 L505 [EMAIL PROTECTED] wrote: [...] There are advantages and disadvantages of using real code versus using DFM files. DFM files are a cleaner format than actual Pascal code. Real code is easier to peak into and copy/paste than DFM files (but a DFM to code converter can be made). DFM files make the exe bigger in size than run time code, generally speaking. DFM make the exe smaller. It is the streaming code, that needs quite a lot of code. But this is a rather fixed amount. So for big applications or if the library is in a .dll/.so the DFM mke the exe smaller. You say DFM make the exe smaller, period. But you should say - DFM make the exe smaller in some cases only. : Because I've never seen a DFM exe smaller than a non-DFM exe myself, but I'll take your word for it. All the applications on my hard drive are several small and only some medium size programs - I make a lot of small utilities with only 1-5 forms in them. I don't make many large applications that exist all inside one exe - most of the time I make a bunch of small programs - then if I have one large program where I think a small add-on would be useful, I make a plug in system. So it depends what the threshold is where the DFM does make the EXE smaller, I guess. If it requires that 5-10MB exe size exist before you start seeing gains in exe size - that doesn't really affect me.. with the work I do. I generally like to make the program have a plug-in system once it gets that large anyway, so it would actually be more advantageous for me to have a lower threshold. Do you know generally what the threshold is before you have seen the exe become smaller from using DFM? 5MB? 6MB? This depends on how you are doing the non DFM part. For example setting 'Left' to 30 needs 9 bytes in DFM. OTOH for a pascal statement 'AControl.Left:=30' the compiler creates code to push the integer on the stack and call the SetLeft method, which certainly needs more than 9 bytes, but I never measured if this is 2 times or 10 times as much on average. Lazarus is quite a nice and big application and is only 6MB. I would think lazarus would be maybe 10MB in size, but it is only 6MB. So maybe we are seeing the threshold kick in here? The IDE contains all components and does not use half of them. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] patch: encloseselectiondlg
Patch generated in source directory: /lazarus/ide/ Description: Small patch for better keyboard working: - correct tab order - correct default/cancel buttons -- Alexandre Leclerc enclosesekectiondlg.patch Description: Binary data
Re: [lazarus] Lazarus Help System Requirements
On 5/11/06, Vincent Snijders [EMAIL PROTECTED] wrote: I mean exact CHM format, for which a freely available help compiler (HTML workshop) exists on windows. The compiler is non-portable. There are no open tools to create CHM files and the free tools I saw that can read it state on their web pages that using them is illegal because it´s considered a circunvention tool by the DRM or something like that. CHM-like is nice, but there is no help compiler for that, so it is useless. There already other CHM-like formats with already working compilers and viewers. One example is the wxWidgets format. Apparently there are others, like for Gimp, Qt, etc. We could just choose one of the open formats and go with it. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Where is code completion function?
I would like to patch the procedure but cant' fin it. When we invoke code completion, it trims the line feed before the code template. I do not want this behaviour. But it does not trim at the end, which is good. Template Example: === my template | blabla === I do want the free line before and after when I invoke code completion. *Example* procedure abc; begin mytemplate //invoke code completion end; *Actual result* procedure abc; begin my template | blabla end; *Desired result* procedure abc; begin my template | blabla end; -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
Hello, On 5/11/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). Ok, Open Document is good, but it has some problems: 1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. 2 - Whatever the format is, I would like to be able to write my own viewer for it. It may be very hard to write a viewer for odt. For viewing HTML (or HTML extracted from a CHM or CHM-Like file) there is a lot of stuff ready. thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
On 5/11/06, Andrew Haines [EMAIL PROTECTED] wrote: In your lazarus directory /components/chmhelp/packages/chm/ there is a unit called chmreader. It is simple to get a list of any of the files in the chm and extracting them: Some questions: 1 - Does that use any external dll or other dependency? 2 - How hard would it be to create chm files? There is also the problem of a cross-platform viewer. thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
2006/5/11, Felipe Monteiro de Carvalho [EMAIL PROTECTED]: Hello, On 5/11/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Yes, odt files al. are open format. And as of 1 may 2006 it is now an official ISO 26300 approved format (as other format like PDF and HTML who are also ISO approved). Ok, Open Document is good, but it has some problems: 1 - We cannot just get dependent on Open Office. It´s a huge dependency, and won´t work on wince for example. 2 - Whatever the format is, I would like to be able to write my own viewer for it. It may be very hard to write a viewer for odt. For viewing HTML (or HTML extracted from a CHM or CHM-Like file) there is a lot of stuff ready. Indeed, I think the idea would be a by-product just as a pdf in that case. A viewer would not be simple to do, but the format is simple. The file is actually a zip file with xml stuff files in it. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Where is code completion function?
On Thu, 11 May 2006 18:46:13 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: I would like to patch the procedure but cant' fin it. When we invoke code completion, it trims the line feed before the code template. I do not want this behaviour. But it does not trim at the end, which is good. Template Example: === my template | blabla === I do want the free line before and after when I invoke code completion. *Example* procedure abc; begin mytemplate //invoke code completion end; *Actual result* procedure abc; begin my template | blabla end; *Desired result* procedure abc; begin my template | blabla end; Right. It works only with code macros enabled. If you want to fix it: ide/codemacroprompt.pas ExecuteCodeTemplate Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] TXMLpropstorage section
Hello All,
Quick Question, relating to using the propstorage components in Linux... how
do you handle the fact that normal users should be able to store their
preference files in their homedirectory ?
I mean it's easy enough to get that,
Filename := GetEnvironmentVariable('HOME')+'.myapplication.xml'
Or something like that - but that is not a value that can be compiled in - you
can only get that at runtime.
Is there a way to set TXMLPropStorage.Filename at runtime so it still works ?
I have for testing tried setting it at form creation as well as in the
savingproperties and restoringproperties events.
So far it doesn't seem to be saving, and certainly not creating the file.
Any suggestion on how this could be approach to be truly multi-user safe ?
Ciao
A.J.
--
there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
Michael Van Canneyt escreveu: sqlite is good candidate too (multiplatform,single file,fast, only one dll/so required) Sorry, but no: - No external dependencies, please. - Specifically: sqlite is a horrible database for use in Pascal. Based in what you say that? In fact the TDataset descendant has better performance (see http://www.geocities.com/camara_luiz/sqlite4fpc/benchmarks.html) than sqldb (Mysql,Postgresql, firebird). This is so true that recently the sqldb internal data handling schema was changed borrowing some ideas from TCustomSqliteDataset. Of course, you are invited to try to replicate the benchmarks and/or post new benchmarks (with the sources) you did. It also has some extra features like Master/Detail, Lookup,Locate, LocateNext, Auto Increment. Any way you can use sqlite using the plain interface (sqlite, sqlite3 units) that directly call the sqlite dll. Exactly how a C program does. So the problem is not the pascal language or implementation. And very slow for complex queries, in general. Again, post benchmarks/tests. Notice that to keep code small the sqlite SQL optimizer only handles the common queries and let the corner cases to hand optimizations. Finishing, sqlite is not for all uses neither mysql, postgres. See http://www.sqlite.org/whentouse.html. Luiz _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RES: [lazarus] Icons
Try this Windows Resource Manager at: www.lazarus-resource.com Henrique. -Mensagem original- De: Arí Ricardo Ody [mailto:[EMAIL PROTECTED] Enviada em: quinta-feira, 11 de maio de 2006 09:17 Para: Lazarus Mailing List Assunto: [lazarus] Icons 1. How do I can associate an icon to a project in the way it appears in the desktop? 2. How do I can associate an icon that will be show in the top left corner of the Form window? (I'd try to load a picture in the Icomn property of the Form but nothing happen) Greetings from São Paulo - Brazil Ricardo _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Where is code completion function?
2006/5/11, Mattias Gaertner [EMAIL PROTECTED]: Right. It works only with code macros enabled. If you want to fix it: ide/codemacroprompt.pas ExecuteCodeTemplate Yep, I see in the code that the problem is not there. I feel the pattern is trimmed before it reaches this funciton. But i can't find where the function is called at all. The Windows find in file crap finds nothing. Any pointer from where the code is actually called and where the patern is loaded? There is also another problem: If I add the macro flag in a pattern $(EnableMakros), when I reload the patern in the patern editor, the macro flag is not showed any more... it is stripped (just as these functions are doing). So you have no choices to edit manually the .dci file to remove it. Regards. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Where is code completion function?
2006/5/11, Alexandre Leclerc [EMAIL PROTECTED]: There is also another problem: If I add the macro flag in a pattern $(EnableMakros), when I reload the patern in the patern editor, the macro flag is not showed any more... it is stripped (just as these functions are doing). So you have no choices to edit manually the .dci file to remove it. Ok, I saw that there is a check box for this. But the rest of my previous questions still need answers :) -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 03:33:02PM +0200, Michael Van Canneyt wrote: I didn't say 'possible', I said 'suitable'. Looking at the website: I think the po2xml is just used to translate the program strings which appear in the docs (used to refer to button captions etc), not for the actual documentation text. Changing 1 letter in the documentation text would completely kill your po2xml output, since it is based on textual search. Ok, I see. But for my experience in translation, having a revision control like that offered by the gettext/po file, for multilingual translation is really paramount. And .po strings are not limited in size so they can easily fit in the paragraph size for documentation source. During the translation of some big GPL programs I found that all pages of the manual are divided in paragraph size chunks, suiteable for .po strings substitution/upgrade. The update/upgrade process and the inherently interesting features needed are the most important factor here. The use of .po files is IMHO a really A VERY COOL thing for a multilanguage manual, especially if you plan to translate it and in the meantime it grows up... Then the gettext utility programs comes really useful and I cannot see any other intrument able to manage such things as good as the gettext suite (and the so many .po files editors are really something). For example I use emacs in po-mode but I know of many vi (gosh) users too. -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus Help System Requirements
On Thu, May 11, 2006 at 08:15:32AM -0500, [EMAIL PROTECTED] wrote: Source file must be thought to be easy for nationalization (i. e. use .po files in the source). Maybe a source format file combination of *.po files and a XML file: xml title path= title.po / contents path= contents.po / /xml yes, sort of... So IMHO: source file: several .po chapters merged into an xml/docbook file output file: HTML primary then PDF, txt, CHM, hlp, etc. Sounds fine. It would be great for mantainers of a multilingual manual suitable of changing every now and then... -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Help Framework proposal
Hello, We had some talks about file formats for the help system, but I´m still uncertain how the framework will actually work, so I gathered some information and ideas here. My idea is to develop a help system agnostic framework, so the software does the same calls to display help independently of the file type. The idea is quite simple. Just add some Delphi help methods to TApplication, like: function HelpContext(Context: Integer): Boolean; function HelpCommand(Command: Word; Data: Longint): Boolean; property HelpFile: string; function HelpJump(const JumpID: string): Boolean; The developer will use this functions (and only them) to access the underlying help engine. But only implement them as calls to a object set by a property, like: TApplication.HelpEngine: THelpEngine; This would be like a DataSet in the sence that on the startup of your application you set that property to the HelpEngine of your preference, be it CHM, CHM-like, sqlite, or whatever. So now people can develop their engines. One of the engines could be WinHelp, and that one would be compatible with Delphi =) The default could be empty help (nil), and engines are on their own units, so filesize is preserved =) Another option is not to have this on TApplication, but rather on a component you can drop on the form. Then you can link that to other components that are the help engines. I also have some doubts: * The Help context is a integer on Delphi. Is this good enougth? Or some help systems would we rather have a string for help context? Also contribute your own ideas for a framework =) Ah, and remember this is specifically targeted for apps created on Lazarus, not particularly for the IDE Help. thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
On 5/11/06, Andrew Haines [EMAIL PROTECTED] wrote: Sigh. :) Have a look in the components/chmhelp directory. In that directory is a program written entirely in pascal that uses the LCL to view chm files using the TurboPowerIpro HTML component and a package to integrate that program in the IDE. Are you trying to impress me? You did it. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New help doc format?
Andrew Haines wrote: Felipe Monteiro de Carvalho wrote: On 5/11/06, Andrew Haines [EMAIL PROTECTED] wrote: In your lazarus directory /components/chmhelp/packages/chm/ there is a unit called chmreader. It is simple to get a list of any of the files in the chm and extracting them: Some questions: 1 - Does that use any external dll or other dependency? No 2 - How hard would it be to create chm files? As Vincent said somewhere in this thread there currently is only the option of a free program from microsoft that can create chms. There are of course other programs as well that can make chms but I am not familiar with any of them. A Crosslinked HelpFile (chm) is around somewhere(FCL-RTL-LCL). There is also the problem of a cross-platform viewer. Sigh. :) Have a look in the components/chmhelp directory. In that directory is a program written entirely in pascal that uses the LCL to view chm files using the TurboPowerIpro HTML component and a package to integrate that program in the IDE. The code in /components/chmhelp looks like it's either GPL or LGPL. For code that would need to be used in target application, could these be changed to the Modified LGPL? Also the license headers refer to COPYING.LCL which I can't find anywhere ?? George _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
