Re: [lazarus] Who is the controlling 'native' widget set in LCL?
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 07/02/2008, Paul Ishenin [EMAIL PROTECTED] wrote: In summary. TButton.Color is not available in LCL because Win32 doesn't allow a button face to change color without custom drawing. Yet other widget sets do like Qt and GTK1. That problem has been havily discussed in lazarus-dev list and we came to the conclusion that such properties should be in LCL, but on the other hand they must be marked some way in object inspector as non cross platform. My apologies. I didn't know of a 'lazarus-dev' mailing list. When was this decided, in the last 7 days? Because from your comment in he mantis bug report dated 2008-02-01 (7 days ago), your clearly stated that it _shouldn't_ be supported. Here is a small abstract about the current state of the discussion: Some properties can not be supported on some widgetsets, because it would require a lot of work, which no laz devel wants to do. OTOH some native features are so great, that the LCL should support them, but only on a subset of the widgetsets. The main problem is how can the programmer see, what property/method is available on what platform. The documentation is a good place, but not sufficient. It should be marked in the OI and identifier completion as well. The information can not be stored in the LCL alone and must be readable when cross designing. So one solution could be a xml file in each widgetset. This kind of information is needed by other libs as well. For example database front/backends. So maybe a more generic solution is needed. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] IDE createds unwanted dependencies
Zitat von Giuliano Colla [EMAIL PROTECTED]: I'm trying to implement an usable port of CLX to Lazarus. So I've created a CLX package which declares to provide the same as LCL. So far it works as expected, but unfortunately CLX unit names are different from VCL/LCL: QForms instead of Forms, QButtons instead of Buttons etc. Unit names can't be changed less changing them in all applications, which impairs easy porting. The obvious consequence is that if a component is added on a form from IDE, the IDE adds the unit it knows (e.g. STdCtrls) instead of the one from the package (QStdCtrls). This is unavoidable, unless IdeIntf is properly hacked. But it happens on the unit one is working with, so it's easy to fix, at least temporarily. All what is required is to remove the unit if it's already there with the Q prefixed name, or to prefix a Q to the name if it wasn't there. Correct. I'm not sure how this should be solved. Hacking IDEIntf has the drawback, that switching to a LCL project will not work. I guess a the provides page must be extended with alias components. OTOH the next problem are the properties. You need some other property editors to show/hide the correct properties. And they must be loaded/unloaded whenever a CLX project is loaded/unloaded. What's more annoying is that also the LCL dependency is added to the project requirements although the CLX package declares to provide LCL. I found the bug. I will commit the fix tomorrow. Is this unavoidable too, hardcoded because of the different unit names, or it's just a matter of incorrect syntax of my provides? I'd thankfully accept advice before attempting any possible variation: provides LCL*, provides LCL 1.0, provides LCL =1.0 ..etc. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Search paths
Zitat von Marius [EMAIL PROTECTED]: Vincent Snijders wrote: Create a package for the units. Should i create a (dummy) package to add search paths to lazarus??? Installing and recompiling the whole ide just to add a few paths sounds kind of stupid. (The tools do not contain any design stuff). Then again if this works it saves me a lot of typing The package system of lazarus is different from Delphi. You don't need to install a package to use it. Just create a package, add your shared units to the package and 'use' the package in every project, that should be able to use your shared units. Read here: http://wiki.lazarus.freepascal.org/Lazarus_Packages and here http://wiki.lazarus.freepascal.org/Install_Packages Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I still have an ifdef request
Zitat von Peter Vreman [EMAIL PROTECTED]: Yesterday I posted a request for a way to improve ifdef handling, but the discussion was led astray by my example, and turned into widgesets, which was not the real issue. So I repeat my request: Sometimes ifdefs are unavoidable, as when they're used to turn on and off customer options. But IDE and fpc are unaware of conditional dependencies, so changing a conditional doesn't force a recompile of some units as it would be required. Of course a Build All is the solution, but if one forgets, one may end up with a program which compiles properly, but has a number of inconsistencies sometimes hard to detect. Is there a way to overcome this problem? Am I the only one to see it as a problem? I would gladly contribute an upgrade to implement this feature, but advice from experts on where to start from, what to look at, if hooks are already available in .lpi or in .ppu or .o files, etc. would be highly appreciated. It has been tried in the past. And it created very confusion situations so it was disabled. There are no plans to re-add this feature because it will cause more questions and problem reports than it solves. And also how often is a define changed. In those couple of cases you can simply press the Build All or use the command line option -B. Ok, then plan a. The IDE should add the -B automatically. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I still have an ifdef request
Zitat von Giuliano Colla [EMAIL PROTECTED]: Yesterday I posted a request for a way to improve ifdef handling, but the discussion was led astray by my example, and turned into widgesets, which was not the real issue. So I repeat my request: Sometimes ifdefs are unavoidable, as when they're used to turn on and off customer options. But IDE and fpc are unaware of conditional dependencies, so changing a conditional doesn't force a recompile of some units as it would be required. Of course a Build All is the solution, but if one forgets, one may end up with a program which compiles properly, but has a number of inconsistencies sometimes hard to detect. Is there a way to overcome this problem? Am I the only one to see it as a problem? I would gladly contribute an upgrade to implement this feature, but advice from experts on where to start from, what to look at, if hooks are already available in .lpi or in .ppu or .o files, etc. would be highly appreciated. The codetools are already conditional aware. If a flag has changed units are automatically reparsed. The IDE saves the whole flags to the .compiled files and recompiles if something changed. But it does not automatically pass the -B option. The missing part is the compiler. At the moment it only checks file dates and source checksums. Not the flags. Solutions: a) The IDE automatically passes the -B option if flags has changed. IMHO this is a semigood solution, because it leads to too much rebuilds. b) The compiler is enhanced to check for changed flags too. This has the advantage that it can optimize the rebuild. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Found serious bug in win32 interface #2
Zitat von Andrey Gusev [EMAIL PROTECTED]:
--- interfaces/win32/win32callback.inc (revision 13905)
+++ interfaces/win32/win32callback.inc (working copy)
@@ -504,7 +504,7 @@
if (ControlDC = 0) or not needParentPaint then
begin
DCIndex := Windows.SaveDC(PaintMsg.DC);
- MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
+ MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
{$ifdef DEBUG_DOUBLEBUFFER}
Windows.GetClipBox(PaintMsg.DC, ClipBox);
DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
with
clipping rect (',
I can provide application that's confirm my rightfulness.
But i don't wish to do it, until all child-control negative effects will
debugged (by me), it need to LazReport designer functionality.
If wished, try to place oversized TPaintBox on TScrollBox and try it to
scroll (with above patch applied).
It might improve the situation, but I guess it will not fix the whole problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] FPDoc tooltip
Zitat von ik [EMAIL PROTECTED]: Hi, I noticed that I can view comments that where added above a function on lazarus as FPDoc, however, it ignores line breaks inside the comment, and does not wrap text. It is a new feature and not yet complete. I will fix the line breaks. So I wonder if there is a way to configure this, and/or if there is (like in Eclipse) a tab/window that can display it properly inside ? The default viewer is a simple TLabel. When you install the package TurboPowerIProDsgn you get a HTML control. The hint not only shows comment, but fpdoc help too and fpdoc help can contain HTML. I'm not sure about how to handle wordwrap. With working line breaks it may not be needed. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [fpc-pascal] Re: FCL-DB/SQLDB docs started
Zitat von Chris Kirkpatrick [EMAIL PROTECTED]: Hi Mattias - I note from the bug report 0010686 that you have fixed the immediate problem, and on re-building Lazarus from SVN this morning I find that I can now save short descriptions from LazDoc in the IDE, and also things that I type in other boxes such as description. :) bug #1 fixed However the LazDoc Description panel does not show text that pre-exists in the XML file, and we run the risk of overtyping anything that may already be there by using LazDoc, as entries made using LazDoc do get saved; similarly, it fails to display the existing contents of seealso fields in the XML file. bug #2 As noted before, LazDoc doesn't display formatted text (such as underline, italic or bold, marked by iword/i), bug #3 and I find that if I try to copy inherited short titles I don't copy the italic etc words. Probably bug #4 For examples see the first few entries in the public/published section for TComboBox and TCustomComboBox in stdctrls. Thanks. I was searching for some good examples. Where can I find a list of all possible nodes that lazde/ladoc creates? Or can you give me some examples, where I can see all flavors? Should I raise a new Bug report, or add this to the existing one? Please create a new one (or more if you like). Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] FPDoc tooltip
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 25/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: The default viewer is a simple TLabel. When you install the package TurboPowerIProDsgn you get a HTML control. The hint not only shows comment, but fpdoc help too and fpdoc help can contain HTML. Does the HTML control in tooltips work already, or is it still a wish list item? If it already works, do I simply need to install the TurboPowerIProDsgn package into Lazarus? You can install it. I already tested it to load sub files like images and css files. So the turbo power ipro part is complete. The missing piece is that the IDE must correctly extract the html from the fpdoc xml nodes. This should be easy once I found out, how lazde stores the html in the xml files. So, at the moment it only passes some text to the viewer. Then a nice css file must be added. And then I have to find out, what is needed to get links/seealso tags working. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [fpc-pascal] Re: FCL-DB/SQLDB docs started
Zitat von John [EMAIL PROTECTED]: Chris Kirkpatrick wrote: Hi John, Joost and Adrian - snip So I should very much like to collaborate with you guys in improving the documentation of sqldb and fc-db, as well as the stuff in the LCL. I agree we should try to use the FPDoc approach as suggested by Joost. snip _ I agree with FPDoc in principle, but I haven't been able to get any sort of handle on how it works. And I HAVE downloaded the documentation for it and tried to read it. It was a while ago, but my memory is that, like most IT documentation, it assumes you know basically what you are trying to do, and just need to be reminded of the details. I am also confused about the difference/connection between fpdoc, lazdoc and lazde (have I even got the names right ? I think there have been others mentioned as well on this list). lazdoc and lazde are now the same (since two weeks). fpdoc is a command line utility. lazdoc/lazde is a graphical editor for fpdoc files. I'll try to have another read. :-) Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Zitat von Paul Ishenin [EMAIL PROTECTED]: Damien Gerard wrote: On Jan 22, 2008, at 9:24 AM, Michael Van Canneyt wrote: On Tue, 22 Jan 2008, Graeme Geldenhuys wrote: On 22/01/2008, Paul Ishenin [EMAIL PROTECTED] wrote: Whoever broke it, would you mind taking a look at fixing it Please update your svn version and retest once again. That was already fixed. Sorry, but I don't think so. :-( Just got a update. Now running r13826. Did a Build All (with a Clean All). Editor Toolbar and Todo List dialogs which contain toolbars are still broken. I'm run on Ubuntu 7.10. See attached screenshot... This is quite strange, because I submitted a bug report about this, and Paul fixed that. I tested his fix a couple of days ago, and the toolbar now actually paints the background. (I used and tested GTK 1) GTk2/ Ubuntu Not always. If you only put a TToolBar on a new form of a new project it works indeed. However if you put a TListView and you choose to directly edit columns from the IDE the toolbar remains transparent. And you can not select an item in this form. Ok, I understand :) I moved some old code in gtk, gtk2 widgetsets and forget about toolbar and toolbutton (they are ownerdrawn conrols and I thought it is not needed to create special widget for them). Later I found toolbar transparency issue and restore widget creation code. Now I see that toolbutton is also needs special widget. I only dont understand exactly why GtkApiWidget (special widget for drawing) is not enought for them. GtkApiWidget is a special widget for custom controls, which do everything themselves. It is not for regular LCL controls. AFAIK Marc wanted to replace eventually TToolBar/TToolButton with real widgets (not LCL drawn). Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The code trees can be used (with other constants). Then some ctags functions should be added to the TCodeToolManager for easy handling. Finally some IDE features could use the ctags information. e.g. method jumping and code explorer. Of course ctags is a pretty simple parser and can not be used to parse macros correctly. And of course the file interdependencies can not be handled neither, as this requires a C IDE, which is not the goal of lazarus. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Michael Van Canneyt ha scritto: On Mon, 21 Jan 2008, Giuliano Colla wrote: Florian Klaempfl ha scritto: Lord Satan schrieb: [...] That's correct. And if they had used OpenGL for it, it would be hardware accelerated, cross plattform and good looking, too. And we would need no stupid Aero or Compiz or other composition managers. And we could do things other widgetsets could only dream of. And porting to OpenES would be easy, too. Stupid Lazarus developers. That's simply not the aim of the lazarus developers. They are interested in native gui support and high vcl compatibility, no more, no less. That's the real catch. They're not stupid, but they're faced with an impossible task: to implement conflicting specs. vcl implies a number of precise, consistent specs, which dictate component behavior. They're the real value of Delphi. Native widgetsets implies a number of specs (often vague and loosely defined) which are different from vcl, and don't map into them. The VCL doesn't dictate anything, it's a wrapper around Win32 native controls, so at least that widgetset should work. It provides properties and methods which are in most cases self-explanatory. The Color Property of a Form or of a Button dictates its color. Well, try just to set this property to clRed, or clButtonFace with different widgesets, and compare the behavior. This is a question of priority. Some widgetset developers and some lazarus developers think that changing the 'color' is seldom a good solution and so they don't invest time on this. So it is up to those who think, that this property is useful to implement and maintain it. If the implementation breaks other features then the developers have to decide what is more important. I doubt Borland went as far as to specify a set of consistent specs. At least I never saw them. And the behaviour changed (subtly) over the versions of Delphi/Windows as well. You can discuss forever about this. The only thing that the Lazarus people can try to do is make the widgetset behave as consistent as possible over all widgetsets, without sacrificing the native look they get by using native widgets. Or they could achieve native look just by using a Bitmap, and consistent behavior with code in LCL, with less duplicated work, less bugs, and better results. Instead of putting a lot of time in such mostly useless debates (its not the first, and probably not the last) it would have been better to report possible bugs or - better yet - provide patches to improve the behaviour. When you're told that the feature can't be implemented because the widgetset doesn't support it, you stop reporting. When you see that the development line is to move the implementation from LCL to widgetset, instead of the opposite, (and breaking what was already working in the process), you stop providing patches, and start whining. :-( Breaking is bad, but sometimes inevitable. For example Drag and Drop was improved in the LCL/gtk, but without a proper threshold, so treeviews become unusable on some machines. I will not complain, because the general direction is right and if no one fixes it I will fix it myself. Even though I already fixed it in the past. About: move from LCL to widgetset That was the goal of lazarus from the beginning. If you want a visual component library with a minimal backend, then use fpGUI or msegui. Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). So basically every drawing should be avoided in the LCL or at least use only high level drawing functions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 22/01/2008, Mattias Gärtner [EMAIL PROTECTED] wrote: About: move from LCL to widgetset That was the goal of lazarus from the beginning. OK, I get that and respect the choice. I'm simply wondering (from a personal point of view) if it's still the right way of doing things? Considering you have years of experience with Lazarus development... If you could do it (Lazarus LCL) over again, what would you change? I would optimize it for smart linking and a console widgetset. Hindsight is a awesome thing. :-) Keep in mind that using the native widgets has several advantages: - native look. Even when user switches theme or OS. As I mentioned before. This is very easy to achieve - Trolltech has proved this. Simply ask the native widget to draw itself on a memory bitmap. All native toolkits send out a message when the theme changes, so it's very easy to detect that as well. Why should qt render a native button, if they can draw a qt button with a 'native' looking theme? Are you sure, that qt uses native widgets? - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). All this can be implemented in a custom drawn toolkit. Yes, by reinventing the wheel. At least that way all platforms will have these features. Currently only GTK Notebook has tab menu for example. A Mac user will be confused if she sees this menu. A disabled person wants to use his OS features and not setup this for each program. LCL now needs to support a basic set of features which are common to all widget sets - nothing more otherwise it's not compatible across widget sets. Only the API is limited to the common features. The program is not limited. As said above: You get extra features of the widgetset. And if a programmer needs uncommon things, he can write a specific control. See for example the printers4lazarus or the lazopenglcontext package. They started on one platform and nowadays they run on all majors. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gärtner wrote: Zitat von Al Boldi [EMAIL PROTECTED]: Mattias Gaertner wrote: Al Boldi [EMAIL PROTECTED] wrote: Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Partially. The codetools already support three 'languages': pascal (delphi, objfpc, parts of macpas, parts of tp), lfm and pascal directives. The file caches could and should be used (for speed and for integrity with the other IDE tools). The problem with the caches is that they are somewhat misleading when you start changing the code, and then forget to reindex. So doing it on-the-fly should be much safer and faster for large trees. I can't follow you here. I was talking about the caches for files. For example the cache for the file unit1.pas. The pascal parser reads and creates a code tree. This code tree is cached as well, but this is another cache and can not be used by the ctags. I only said, that the plugin should use the file caches instead of accessing the files on disk directly. The code trees can be used (with other constants). Then some ctags functions should be added to the TCodeToolManager for easy handling. Finally some IDE features could use the ctags information. e.g. method jumping and code explorer. Of course ctags is a pretty simple parser and can not be used to parse macros correctly. And of course the file interdependencies can not be handled neither, as this requires a C IDE, which is not the goal of lazarus. I think the least we should handle are the #include's, otherwise the on-the-fly ctags may not work. Parsing the files for #include's should be easy, right? I'm no ctags expert. I don't know if ctags has a preprocessor. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Lord Satan [EMAIL PROTECTED]: [..] - widgetset specific goodies: e.g. tab menu of gtk notebook, unicode input method, assistive technology, hardware acceleration, network support (X client/server modell). @Mattias: What hw acceleration are you talking about? I don't know of any hw accelerated widgetset. For example: -gtk on embedded devices can render directly to the framebuffer. -trolltech advertises hardware accelerations on their website, but I don't know if this available for free. -afaik carbon uses some opengl hw acceleration -And all widgetsets use some hand tuned graphic libs using vector libs or sse instructions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Zitat von Giuliano Colla [EMAIL PROTECTED]: [...] Well, Lazarus is intended to develop commercial applications, not GPL utilities to be added to Gnome desktop. Oops. Sorry, I didn't know. Commercial applications take care to provide their own specific look. If we look at some widely known multiplatform applications, we find that Red Hat created it's specific Bluecurve style, in order to avoid the native look of gtk, and provide uniform RedHat style to Gnome and Kde desktops. ... and RedHat achieved that, because the programs follow the system settings. OpenOffice, Mozilla, Gimp, Acrobat Reader (to some extent), Qt Designer, not to speak of players like Winamp or XMMS provide the same look in all platforms, with OpenOffice and Acrobat going to the point of using only their own fonts. Mozilla is using gtk under linux. OpenOffice descended from StarOffice, which look much more the same on all platforms. With every new version OO is becoming more native looking on all platforms. Gimp - it invented gtk. ... Moreover multiplatform doesn't mean adding up all limitations of the supported platforms, but rather providing a consistent look and behavior in different platforms, with minimal programmer extra work. We are trying to improve the LCL to minimize the programmer work. But we don't have the man power of Graeme and Martin, so either be patient or use fpGUI/msegui/qt/gtk/wxWidgets/... . Of course, I can take a different path for myself (fpGUI, msegui, MyOwnGui), but I feel belonging to Lazarus community, I see a lot of work being done, a lot of impressing achievements whenever the sacred cows of Delphi compatibility and widgetset compliance are forgotten, such as in component anchoring or in IDE conception. Therefore, backed by my personal experience, I feel it right to raise doubts on the priorities you clearly indicated, and humbly suggest that it could be the time to reconsider them with open mind. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Exception for codehelp
Zitat von Vincent Snijders [EMAIL PROTECTED]: Mattias Gaertner schreef: On Mon, 21 Jan 2008 09:27:27 +0100 Damien Gerard [EMAIL PROTECTED] wrote: On Jan 21, 2008, at 9:22 AM, Vincent Snijders wrote: Damien Gerard schreef: I have got this when using Lazarus : TApplication.HandleException In Stream (line 2955 pos 63): Unmatching element end tag (expected /seealso) docs/xml/lcl/forms.xml On first look the line looks ok. Fixed: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/docs/xml/lcl/forms.xml?root=lazarusr1=13820r2=13819pathrev=13820 e a :) So, someone is still editing the xml code directly instead of using lazde. What is wrong with lazde? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] ToDo List not working in IDE
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: Hi, Is anybody currently busy working on the ToDo List feature in the IDE? It's not currently working (v0.9.25 r13293M i386-linux-gtk) - no items get displayed and sometimes even crashes the IDE (no error message output - a direct terminate to the command prompt). The last time I checked it, about 2 or so months ago, it was working. I'll try and get a svn update and try again (this morning I couldn't connect to svn repository). It works here, but the scope has changed. See http://wiki.lazarus.freepascal.org/IDE_Window:_ToDo_List I know the gtk toolbar bug, but the crash is new to me. I do not use the todo list much, so probably that's the reasons why I didn't know it. Maybe you can provide some test cases. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question about packages and units
Zitat von Joost van der Sluis [EMAIL PROTECTED]: Hi al, If you install the fpWeb package, create a new cgi-application with a TFPWebModule. You can drop a THTMLEntityProducer on that module. So far so good. Then you can add an OnWritePage event, but thereafter the program will nog compile anymore, because you have to add the 'htmlwriter' unit to your uses clause manually. Question is: how can I do this automatically? Thus that when you drop a THTMLEntityProducer on a module, add the 'htmlwriter' unit automatically? The IDE should do this automatically. What package installs THTMLEntityProducer? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Back to 0.9.22
Zitat von Arí Ricardo Ody [EMAIL PROTECTED]: I wasn't talking about someone find errors, but I was thinking that if the trouble with some legacy code will be fixed... I sent yesterday a project of mine that has problems when compiled in 0.9.24. I think it would help you with the cause(s). On a quick glance I didn't find your project in the mails. Can you send it to my address or upload it to the bugtracker? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Primitive classes in fpc/lazarus
Zitat von Marco van de Voort [EMAIL PROTECTED]: On Tue, Nov 27, 2007 at 12:42:28PM +0100, Vincent Snijders wrote: It would be nice if the fpcdoc xml files could be easily installed via packages. What do you mean? What is missing? For example: I don't see any of the xml files in the debian packages. I see. I thought you were talking about lazarus packages with .lpk files. And I thought fppkg :-) All three should be improved. :) That reminds me of fppkg+lcl ... Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Adding AllowFractionalPositioning to TCarbonDeviceContext
Zitat von Giuliano Colla [EMAIL PROTECTED]: Mattias Gaertner ha scritto: On Mon, 05 Nov 2007 01:40:06 +0100 Giuliano Colla [EMAIL PROTECTED] wrote: Font size can only be given in either an integer number of pixels, or in Point Size, which (currently) gets rounded to an integer number of pixels, and therefore, given usual font metrics, fpFixed should never give rise to a fractional width. Not right. For example: Character Size 10 (10 pixels long and 7 pixels wide). Now use Size 9. The Height is integer and width must be rounded or using fractionals. For most applications rounding is ok. For layout programs it is not. Then an extra TFont property (such as FractionalAllowed), could make sense, to let the widgetset know that the application is unable to deal with fractional values, and font should be set accordingly. Yes, but without a TCanvas scale factor or float type positions you can not use it. So my conclusion is: fractionals are needed in some rare cases, but supporting them requires a lot of work. Coming back to the origin of the thread: Especially porting a Delphi application should not need it, because the VCL does not support them. The LCL carbon intf must be fixed, not the LCL. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] [R1259x][GTK2][Ubuntu] SegV in APPLYMASK
Zitat von Paul Ishenin [EMAIL PROTECTED]: Milipili Houbi wrote: I have found a way to demonstrate the problem. here is the protocol to reproduce the error with the last rev of lazarus (12641). I have not test with previous one. - Env: Ubuntu 7.10, GTK2 - Create a new project - Put a TImage, align alTop, strech = true - Using the inspector, load the attached image - This will produce a SegV Should I open a new Bug report ? I can confirm under windows gtk2. Please, create a new bug report. I attached a possible patch to the bug report. Marc, can you review it? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [Lazarus] project options - version info (on a linux program)
Zitat von Alvise Nicoletti [EMAIL PROTECTED]: Mattias Gaertner ha scritto: On Thu, 25 Oct 2007 17:52:42 +0200 Alvise Nicoletti [EMAIL PROTECTED] wrote: Hi... Configuring a program into project options I have a application.title:= 'title' added after the begin of my program... Also, a resource is added for the compiler (PoolPatrol.res). After that, when I try to compile, I get both a identifier not found Application and a can't open resource file applicationname.res. Application is the central object of an LCL program. It is defined in lcl/forms.pp and requires one of the provided widgetsets. I'm not sure about res file problem. What kind of resources do you want to store in your linux daemon? Is that feature working only on visual applications? Yes, because at the moment the current widgetsets are all visual. Is it possible to make it work someway on a linux program? (I'm using it as linux service). windows: 'service' ~ linux: 'daemon' Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives Ok, so it's not working on RTL. The feature I wanted to use was the versioning of the program, setting the main versions plus an automatic increase of the build labeling. Is it possible on a linux DAEMON? Not like windows, because afaik linux programs do not have a standard for storing the version number in the binary. So even you store it somehow in the binary, no program will show it. Under linux normally the version is shown in the help message, when starting a daemon with the '-v' or '-h' switch. And it is written in the documentation. The auto increasing of the version number is not yet implemented in lazarus and it is also not yet implemented to pass somehow the version to the compiler and/or source code. So you have to increase/add it manually. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Zitat von Razvan Adrian Bogdan [EMAIL PROTECTED]: On 10/8/07, Luca Olivetti [EMAIL PROTECTED] wrote: En/na Luca Olivetti ha escrit: You have to go through the string for UTF-8 and UTF-16 encodings so the advantages are at least questionable... Yes, but my (wrong) premise is that you could assume all characters are 2 bytes wide, so the Nth character would be at N*2 byte. BTW, using strings as arrays of char to get at individual characters is risky business with utf-8. It's the same with UTF-16 and with treating UTF-16 as UCS-2. UTF-32 is almost there. (some languages combine characters. I dont know the relevance.) For most string operations, like computing the byte length or comparing strings ASCII case insensitive, UTF-8 is 100% compatible. Because of the UTF-8 encoding, you can even start in the middle of string and find out if the byte is the first, second, third or fourth byte of a character. So, existing algorithms don't need to change at whole to work with UTF-8. Same is true for UCS-2 code and UTF-16. Or will be they converted to (pseudo) properties and (slowly) do the (slow) right thing? I also suppose that the functions in strutils are not utf-8 aware, so what should we be using in its place? For single character processing UTF32 (4bytes) would be nice :), i think functions to count UTF8 chars inside a string and getting each char would be nice too, maybe even implemented in FPC for UTF8string such as Lenght(utf8string) or indexing utf8string[1] to return the char not the byte as UTF32. See lcl/lclproc.pas search for UTF8. Some of these functions already exists in the RTL. The others may be moved eventually. Since FPC uses ANSI strings, a lot and most text is in latin1 without any diacritics using UTF8 in Lazarus is a good choice, if the right functions are provided it can be a great choice unless apps become too slow. In lazarus most UTF-8 code is in synedit. The synedit slow down from ASCII to UTF-8 was hardly measurable. Even if ignoring the fact that 90%-98% of the time is spent in the widgetset. Since the web uses mostly UTF8 for minimizing transfered data and also most databases for minimal storage size it becomes clear that UTF8 is a better choice if helper functions exist to assist with it's management. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Zitat von Vincent Snijders [EMAIL PROTECTED]: Razvan Adrian Bogdan schreef: The delphi gnu gettext project has a tool that does a lot of things, allows translating forms, strings, etc, it could be used a a model for something similar in Lazarus and why not integrate something like POEdit directly http://dybdahl.dk/dxgettext/ See here for the Lazarus port of dxgettext: http://wiki.lazarus.freepascal.org/DxGetText - it has one drawback: it translates any string and you have to maintain all the exceptions. This might be good for compatibility, but the already existing lists of exceptions show that this approach means a lot of work. That's why I prefer the current approach with the TTranslateString type. - an integrated poedit might be a good idea, but why reinvent the wheel? There are already good open source, free po editors with lots of features, like thesauri, spelling checks and dictionaries. This is too mighty for a sub component in the lazarus source. If someone wants to start a po editor in pascal, then IMHO it should start as separate project. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Zitat von Luis Rodrigues [EMAIL PROTECTED]: Just tried to being implementing this for but it to work there would have to be a function TLRSObjectReader.GetStackPath(Root: TComponent): string; for me to use in procedure TDefaultTranslator.TranslateStringProperty to get the component path Ideias? please I can try to implement it, but I have question about the usage. See below. On Mon, 2007-10-08 at 01:39 +0100, Luis Rodrigues wrote: ... Good questions. In big project using third party packages you will easily get value clashes. And the same value must be translated differently depending on the context. So merging would be fatal. I'm not sure, how the lcltranslator should know, where to lookup up the translations for each unit. Maybe the IDE should create lists which unit belongs to which package/project and put this for example into an include file. Is some languages are already translated how should that be handled? There is the tools/updatepofiles tool. It is not yet integrated into the IDE. Has anybody ideas, suggestions, remarks? Just a taught, maybe we could store the translation String in the .po as msgid FORM1.LABEL1.Caption=hello I'm Luis msgstr Ola eu sou o luis then the LRSTranslator would search for the translation of FORM1.LABEL1.Caption=hello I'm Luis and not hello I'm Luis. With ths solution we would never the problem of value clashes. I also don't think it would create a problem for the translators. There are some practical drawbacks with this solution: 1. The translators will see the string and might accidentally change the prefix. For example the po editors with built in translations will try to auto translate it. This means more work for translators and hard to find bugs. 2. What is the correct translation? With the prefix or without or both? Most po editors have a nice feature: They copy the msgid to the msgstr and use dictionaries to translate them. Would also have to find a solution of the .rst conversion since this one is only good for the forms. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 08/10/2007, Razvan Adrian Bogdan [EMAIL PROTECTED] wrote: char would be nice too, maybe even implemented in FPC for UTF8string such as Lenght(utf8string) or indexing utf8string[1] to return the char not the byte as UTF32. In fpGUI I have a few helper functions for UTF-8 strings (Length, Copy, Delete, Insert, Pos etc). Some of the code I got from LCLProc unit and some written myself. Anybody know how I can access UTF-8 characters via a index? eg; MyString[2] returns the string containing the 2nd character. I say returning a string, because a UTF-8 characters can be between 1-4 bytes so a Char type will not do. If you want an array, then you can convert the string to UTF-32 or create an array of PChar pointing to each character. If you just want the n-th utf-8 character, then you can use UTF8CharStart. If you need the n-th visible character (including BIDI and combined characters) then you must use functions from the iconv lib or the winapi. Same for UTF-16 and UTF-32. There is no encoding for random access to an unicode string. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Zitat von Luca Olivetti [EMAIL PROTECTED]: En/na Mattias Gärtner ha escrit: For most string operations, like computing the byte length or comparing strings ASCII case insensitive, UTF-8 is 100% compatible. but not if you need char length, say limiting a text to 40 characters and indicating there that the text has been truncated with '..': if length(s)40 then s:=copy(s,1,38)+'..'; or maybe faster if length(s)40 then begin s[39]:='.'; s[40]:='.'; setlength(s,40); end; would break with utf-8 (and with utf-16 too if you use characters outside the bmp). There are probably utf-8 equivalents of the above, but old habits die hard if UTF8Length(s)40 then s:=UTF8Copy(s,1,38)+'..'; Maybe for internal processing utf-32 is better and only use utf-8 for input/output and/or interface with other systems? :) Speed: Depends on what you do: UTF-8, UTF-16, UTF-32 Memory: UTF-8 or UTF-16. Compatibility: UTF-8 (VCL) Easy coding: UTF-32 There is no absolute winner. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Zitat von Luis Rodrigues [EMAIL PROTECTED]: Basically you enable the experimental LRT code *and* remove the working and used RST code. So it breaks existing packages/projects. This must be improved. See below. I didn't remove the RST code, .rst is generated by fpc so it still gets generated. I only updated the generation of the PO files, I just replaced TMainIDE.ConvertProjectRSTFiles by a UpdateProjectPO At the moment the IDE converts the .rst files to .po files for packages and projects into the RST Out directory, which can be setup by the user. This is what I meant with RST code. The new code must at least provide something similar, otherwise it is a regression bug. It collects the .rst and .lrt file for each project file - even if the file does not belong to the project. Add a check (Project1.Files[i].IsPartOfProject). thanks done It puts them all together into one stringlist and checks with a linear search for doubles. That's too slow for the several thousand strings. You are right. just rewrote it, but the insert into .po is still O(n*m) where m=number of items in .po and n number of total strings in forms Do you think as is is acceptable or should I implement a better method? I did it like this so I would not overwrite whatever the user as already changed in .po between compiles. Too slow. For example the IDE has more than 3000 strings for 70 forms. Other projects have hundreds of forms. So, it should work with m=10.000 and n=10.000. So, goal is O((n+m)*log(m)). It always recreate the .po file, even if nothing changed. It should at least check the .po file. Otherwise a readonly file will stop the update. It just updates the .po with the strings with are not there, now I added a check to only rewrite the file if changed. Maybe a check should be added, if any of the input files (.lrt/.po) is newer than the output file. If not then skip the update. Or even better: It should only read the changed input files to update the output file. Some error checks and dialogs are missing (e.g. failing to read/write a file). Should I check if the .rst .lrt were correctly opened and if could write the .po? You can enclose the TStringList.LoadFile/SaveFile with try..except dialog end; or use the functions of the ide/dialogprocs.pas unit. The .po file is created in the source directory and has the name of the project. This should be configurable. For example the .po file should have the same name as the target executable, and/or the .po files should be placed into a sub directory. It should at least check if the old 'RST/OutDir' config variable exists and use that as default. Ok now I respect RST/OutDir (if available) and save the .po as ExecutableName.po. Since DefaultTranslator.po checks for the existence of a ExecutableName.po file the .po file will always have to be called ExecutableName.po I forgot: What about packages? The old RST code works with packages too. If a package is compiled, the package files should be checked, not the project files. As stated above the RST is working. I will look into packages next. Great. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Zitat von Mattias Gaertner [EMAIL PROTECTED]:
On Mon, 01 Oct 2007 00:15:16 +0100
Luis Rodrigues [EMAIL PROTECTED] wrote:
Hi,
Attached there is a patch do implement app localization automatically.
If Enable 18n is checked in project options when an app is compiled a
appname.po file is generated with the forms strings and
resourcestrings.
Then create a languages/LANG in the program working directory (there
are other options, check defaulttranslator.pas), compile the po into
a mo file and place it there.
Is also necessary to add DefaultTranslator.pas do the main unit uses
clause.
This patch mainly cleans the existing code that was {IFDEFed
TRANSLATESTRING}.
Comments please.
I will take a look.
I think the direction is good, but there are some issues:
Basically you enable the experimental LRT code *and* remove the working and used
RST code. So it breaks existing packages/projects. This must be improved. See
below.
It collects the .rst and .lrt file for each project file - even if the file does
not belong to the project. Add a check (Project1.Files[i].IsPartOfProject).
It puts them all together into one stringlist and checks with a linear search
for doubles. That's too slow for the several thousand strings.
It always recreate the .po file, even if nothing changed. It should at least
check the .po file. Otherwise a readonly file will stop the update.
Some error checks and dialogs are missing (e.g. failing to read/write a file).
The .po file is created in the source directory and has the name of the project.
This should be configurable. For example the .po file should have the same name
as the target executable, and/or the .po files should be placed into a sub
directory. It should at least check if the old 'RST/OutDir' config variable
exists and use that as default.
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Zitat von Mattias Gärtner [EMAIL PROTECTED]:
Zitat von Mattias Gaertner [EMAIL PROTECTED]:
On Mon, 01 Oct 2007 00:15:16 +0100
Luis Rodrigues [EMAIL PROTECTED] wrote:
Hi,
Attached there is a patch do implement app localization automatically.
If Enable 18n is checked in project options when an app is compiled a
appname.po file is generated with the forms strings and
resourcestrings.
Then create a languages/LANG in the program working directory (there
are other options, check defaulttranslator.pas), compile the po into
a mo file and place it there.
Is also necessary to add DefaultTranslator.pas do the main unit uses
clause.
This patch mainly cleans the existing code that was {IFDEFed
TRANSLATESTRING}.
Comments please.
I will take a look.
I think the direction is good, but there are some issues:
Basically you enable the experimental LRT code *and* remove the working and
used
RST code. So it breaks existing packages/projects. This must be improved. See
below.
It collects the .rst and .lrt file for each project file - even if the file
does
not belong to the project. Add a check (Project1.Files[i].IsPartOfProject).
It puts them all together into one stringlist and checks with a linear search
for doubles. That's too slow for the several thousand strings.
It always recreate the .po file, even if nothing changed. It should at least
check the .po file. Otherwise a readonly file will stop the update.
Some error checks and dialogs are missing (e.g. failing to read/write a
file).
The .po file is created in the source directory and has the name of the
project.
This should be configurable. For example the .po file should have the same
name
as the target executable, and/or the .po files should be placed into a sub
directory. It should at least check if the old 'RST/OutDir' config variable
exists and use that as default.
I forgot:
What about packages?
The old RST code works with packages too. If a package is compiled, the package
files should be checked, not the project files.
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Default project source code.
Zitat von Michael Van Canneyt [EMAIL PROTECTED]:
On Wed, 19 Sep 2007, Vincent Snijders wrote:
A call for opinion on
http://www.freepascal.org/mantis/bug_view_advanced_page.php?bug_id=9605
A *.lpr file opens with
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms,
{ add your units here }
This suggests that you should add unit names manually here. This is
difficult
at best because the syntax must be exact, forms must be included, etc.
At worst, doing this probably leads to errors because the *.lpi file
is not modified accordingly.
Suggestions
1) Remove it completely
This is the best. It avoids confusion. As long as the user is allowed to
change it if he needs it...
Newbies tend to add their units at start, which should be avoided.
Maybe the comment should be replaced with 'add your units behind here'?
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Supporting Visual Form Inheritance in a GUI Designer
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: Hi, This is not really related to Lazarus, but only me asking for advice from developers that handled this issue before that I have now. I created (ported) a very basic GUI Designer for the fpGUI toolkit. Purely for the purpose of speeding up some form designs. It generates the Form and containing components as code in a source unit. Not as a external *.lfm file like Lazarus and Delphi does. The designer inserts Begin/End comment markers to know what section it maintains and supports multiple forms in a single source unit. I use Form Inheritance a lot in my applications. Currently my GUI Designer doesn't support Visual Form Inheritance, though it doesn't crash reading and building the form either. I would like to implement VFI in my GUI Designer, but have a few questions. What is the process flow Lazarus uses to build up a designer form that implements form inheritance? eg: * The order of loading the form into the gui designer form? It loads the ancestor first. They are created hidden if needed, so you may not see them. * How does it know which unit contains the parent class? Basically it parses the source and searches for the unit with the right class and .lfm file. It has some fallbacks in case of errors in code. * How does it track changes made to components implemented in the parent class? It does not yet. I already have some experimental code for this, but it needs completion and integration into the IDE. The MSEGUI seems to use its property hooks and always streams the complete form, which works good for small forms and normal property editors. * How does it know what components are from parent forms and what are newly introduced? It searches the component name in the ancestor instance. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] IDE, start once, open files
Is there already a cross platform component for applications to check if it is already running and if yes then pass some commands to the already application? For example clicking on files in the file browser should not open a second instance, but tell the already running instance to open the files. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Editor issues
Zitat von Lepidosteus [EMAIL PROTECTED]: [...] But the editor seems to 1 - lack some features For exemple, when typing begin, I've been used to delphi writing two new lines, end;, ans putting me on the middle line, just where I should type. I understand this is code templates or something like this, and there may even be a way to do it in lazarus yet. My issue is that you install, it doesn't do it. I have a question, how it should work 'automatically': Does this mean, you can no longer write 'beginning' in Delphi? Or is the IDE waiting a little, so it is only invoked if you type begin and wait? I guess the last, but who wants to wait? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus on one window (aka SDI)
Zitat von Luca Olivetti [EMAIL PROTECTED]: En/na Marc Weustink ha escrit: I've the same layout in separate windows. I never can get used to delphi versions where they are placed in one window, since whin I want to edit some properties in the object inspector, the whole is covering my form so I cannot see the visual imapact. This means that I've to switch everytime between OI and form to see if it is OK. So if you ask me, I won't invest time implementing a feature in Lazarus which I never would use. OTOH I find it really sweet to have the toolbar, the messages and the editor in the same window (I always seem to be chasing the messages and/or the toolbar when I move windows around or maximize the editor, ok, my fault but I'd still like to have those in the same window). I agree that the object inspector should be in a stand alone window. Maybe the interface could be dockable? I agree. I hope to find time to finish the LCL docking code. As soon as this works good enough it will be used in the IDE. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] arm-linux, system.ppu not found, when creating a new project.
Zitat von Bernd Mueller [EMAIL PROTECTED]: -Tlinux -XParm-linux- -FDc:\windows\app\lazarus0922\fpc\2.1.4_8169\bin\arm-linux -FuC:\windows\app\lazarus0922\fpc\2.1.4_8169\units\arm-linux\ -FuC:\windows\app\lazarus0922\fpc\2.1.4_8169\units\arm-linux\* -FuC:\windows\app\lazarus0922\fpc\2.1.4_8169\units\arm-linux\rtl Any hints, what could be the reason for the Lazarus error message? It means lazarus did not found either the system.pp for arm-linux or the system.ppu for arm-linux. Check: Where is the arm-linux system.ppu? in c:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\units\arm-linux\rtl Where is the arm-linux system.pp (your-fpc-src\rtl\linux\system.pp)? in c:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\source\rtl\linux What contains inputhistory.xml in the FPCConfigCache node? I made a fresh lazarus installation, started lazarus and filled in the environment options for the arm-linux crosscompiler, when I confirm the dialog, I get the error message for the first time. I confirmed the error message and closed lazarus. I did no further changes. This is the resulting inputhistory.xml: ?xml version=1.0? CONFIG InputHistory Version Value=1/ FileDialog InitialDir=C:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\ HistoryList Count=2 Item1 Value=C:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\/ Item2 Value=C:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\bin\arm-linux\/ /HistoryList /FileDialog /InputHistory FPCConfigCache CompilerPath=C:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\bin\arm-linux\ppcrossarm.exe CompilerDate=922452539 Items Count=1/ Item1 Options Value=-Twin32 -Pi386/ FPCSrcDir Value=C:\WINDOWS\app\lazarus0922\fpc\2.1.4_8169\source\/ /Item1 The 'SearchPath' entry is missing. The IDE calls the compiler and collects the unit paths to create the SearchPath entry. See below. /FPCConfigCache /CONFIG I changed then the Item1 Options Value to -Tlinux -Parm manually in inputhistory.xml, started lazarus and was able to create a new project without getting the error message. The IDE creates one 'Item' per used target. The IDE was started under target win32/i386, so it uses this as default for new projects. When you switch in the compiler options to another target like linux/arm, a new target is added to the list. The number of the Item is irrelevant. I changed target OS to linux and target processor to arm in Project/Compiler Options.../Code and was able to build a project successfully. That's the right way. But If I restart lazarus and want to create a new project, I get the error message again. The resulting inputhistory.xml is attached. When the IDE asks the compiler with the default target (win32/i386) it does not find the system.ppu. So the error message is correct: your compiler does not support the target, because the system.ppu is missing. ToDos: 1. Improve the message, which target was tested. 2. The IDE should start new projects with the default target of the compiler, instead of the target of the IDE. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What about a Lazarus church to raise money?
Zitat von Giuliano Colla [EMAIL PROTECTED]: David Lyon ha scritto: Felipe Monteiro de Carvalho wrote: I guess that the hard part will be finding a volunteer to make the legal paper work required by a foundation, not to mention reading the legislation about that and finding the best approach. I, for example, am absolutely not in great mood for doing legal peper work. It could be set up as a non-profit organisation. I have some experience in doing this. Is there a particular requirement on which country it needs to be setup in? It's fairly easy to do in the UK, Germany, Australia and United States... Let me know if there is a preference and I might be able to help... I hoped that someone with this sort of experience would pop up. I believe that the organization style and the country should be selected in accordance with the historical developers, such as Mattias, Vincent etc. which haven't yet expressed their opinion, BTW. There were similar threads in the past and every time it came down to: All core devels agree, but nobody wants to do it, because it does not sound like fun. When someone volunteers we will support it. That's why Michael answers with the funny mail - to skip the talk and come directly to missing thing: the volunteer. I guess, germany is ok. About the svn mails: That's a great idea. Although it means a lot of spam: laz 0.9.24 will contain about 900 changes. Maybe only send a mail a day or each week? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New User Friendly BuildLazDialog patch
Zitat von Giuliano Colla [EMAIL PROTECTED]: Felipe Monteiro de Carvalho ha scritto: could you post a screenshot? thanks, Second screenshot. That's how it looks if you've selected Advanced. Note: You can not use the space right of the checkboxes, because for example in the german version there is no space. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New User Friendly BuildLazDialog patch
Zitat von Al Boldi [EMAIL PROTECTED]: Graeme Geldenhuys wrote: On 25/07/07, Michael Van Canneyt [EMAIL PROTECTED] wrote: All in all I think it would be better to have a PageControl with 2 tabs Quick build and Custom. It's cleaner and more conform the other dialogs in the IDE. The jumping of the buttons is weird and disturbing. (to my taste). I agree. Jumping buttons are normally a GUI design NO-NO. Correct, but I was thinking we could have options folding instead of pages. 1. Folding should be done with a folding control, to allow easy designing. But because we don't have yet a folding control I vote for using a pagecontrol/notebook. 2. The Target OS/CPU/Dir and 'Options' are definitely advanced options. I think most people only need 'Clean up and build all', 'Build all', 'Build LCL', 'Build IDE with packages', 'Build IDE without packages', and the Interface radiogroup option. The components are built automatically anyway. The clean up makes only sense after an svn up. If you want to cross compile, you probably read the wiki and there the 'advanced' options are described. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: On 23/07/07, Mattias Gärtner [EMAIL PROTECTED] wrote: The lfm reader/writer was at hand at the time. Nowadays we could use the xml reader/writer too, although that is less human readable. Using pascal source as file format would be possible and has some advantages but some disadvantages as well. Mattias, these are the things I would like to find out. What are the advantages and disadvantages of using a single pascal unit for code and form designer information. Like I mentioned before, calling a private method from the constructor to build the GUI. The form designer maintains that private method's content. Lots of details. Here are some categories (this is not a complete list): - Sub components: You can do it with With or with full path. A With has the disadvantage, that if a property is removed from a class, the code can execute without error. - Custom data (e.g. TStrings, TBitmap). - creation of components. Have a look the TReader code to understand the problems. A simple Button1:=TButton.Create(Root); will not work. - Parent property - Usability: If the format is pascal, people might try some pascal things. But the IDE parser will probably not understand it or worse: misunderstand it. It will work at runtime, but not at design time, so people will blame the IDE. - But there is one big advantage: We might provide a LCL without RTTI. Then smart linking would work much better. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making Configure Build Lazarus more user friendly
Zitat von Al Boldi [EMAIL PROTECTED]: Giuliano Colla wrote: The configure build lazarus IDE provides a lot of options which the majority of us don't use, but we're however forced to check/uncheck. Therefore I've added a small Group Box, named Quick Configure Options with thre buttons: All, LCL, and Custom. The first two cover (in my opinion) the needs of the vast majority of users, while the third one can be handy. The All Button checks all the Build (or Clean+Build, if Clean All is checked), the LCL button unchecks everything, except LCL (which is set to Build or Clean+Build as above), while Custom unchecks everything. If the idea seems good, the attached patch can be applied, or someone can do it better. If not, I'll just keep it for me, because I find it handy. This is great, but there is one important option missing: Build Packages which would turn off everything, except IDE with Packages. Maybe there should be two pages: One with a simple radiogroup called 'Common' and the other with the current options called 'Advanced'. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Zitat von Al Boldi [EMAIL PROTECTED]: Michael Van Canneyt wrote: On Mon, 23 Jul 2007, Al Boldi wrote: Graeme Geldenhuys wrote: So again, what is the pros and cons between the two design choices when using the Object Pascal language? .dfm is good for beginners, who get confused looking at code they didn't write. .pas is good for pros, who need to take control of their project code. Obviously you are unaware of the real reasons the .dfm mechanism was used, otherwise you would not use such unappropriate demeaning tone. No offense meant. The .lfm is probably there for compatibility reasons. Well, using a similar system like Delphi makes porting easier. But it is not there for 'Delphi compatibility'. The .lfm is used because: - a separate file is independent of syntax errors in the source code - the file format should be easy to read/stream The lfm reader/writer was at hand at the time. Nowadays we could use the xml reader/writer too, although that is less human readable. Using pascal source as file format would be possible and has some advantages but some disadvantages as well. There are/were good reasons for it's use. These reasons may have been outdated, but at the time, they were certainly valid. It was (and is, in my opinion) a defendable choice. I have not seen you give any valid and objective reasons why code is better than resources. Unless you plan to give such reasons, I suggest you abstain from such demeaning comments. This really has nothing to do with resources. Resources should still be saved in its own .res file. This is about code init, and as such should not be mutilated into some obscure hardcoded code init translator, but instead be obviously exposed for code control. Well, it is exposed, because it is a simple text file. And you can edit it in the IDE (just make sure to close the designed form, while doing so). If we would switch the lfm file format to a more pascal like dialect you will not get more code control, because the parser will not understand your extensions. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Code Folding regions in Lazarus
Zitat von Graeme Geldenhuys [EMAIL PROTECTED]: Hi, Does Lazarus support some sort of code folding 'region' keyword like the Visual Studio IDE does? I know Lazarus automatically handle begin..end etc. But can the user add there own code folding regions around their code. Here is an example of regions used in the Visual Studio IDE for C# code #Region Windows Form Designer generated code ... System.Diagnostics.DebuggerStepThrough() _ Private Sub InitializeComponent() Me.components = New System.ComponentModel.Container ... Me.ImageList1 = _ New System.Windows.Forms.ImageList(Me.components) ... #End Region Just add that to the highlighter TSynPasSyn and it will support it. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] *.xml config files under Windows
Zitat von Marco van de Voort [EMAIL PROTECTED]: On Thu, Jul 19, 2007 at 01:06:36AM +0200, Vincent Snijders wrote: This is likely to change before 1.0 to the some applictiondata directory, as given by the sysutils.GetAppConfigDir (or what is that function name?). Keep it versioned, or you might loose the ability of having multiple independant lazarusses? It won't be different from the current situation in *nix: you have to use to pass the config dir on the command line if you want to use different config files. Well then I suggest that being fixed too. ( :- ) Can you elaborate, how such versioned directories should work? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] *.xml config files under Windows
Zitat von Marco van de Voort [EMAIL PROTECTED]: On Thu, Jul 19, 2007 at 06:00:55PM +0200, Mattias G?rtner wrote: Zitat von Marco van de Voort [EMAIL PROTECTED]: On Thu, Jul 19, 2007 at 01:06:36AM +0200, Vincent Snijders wrote: This is likely to change before 1.0 to the some applictiondata directory, as given by the sysutils.GetAppConfigDir (or what is that function name?). Keep it versioned, or you might loose the ability of having multiple independant lazarusses? It won't be different from the current situation in *nix: you have to use to pass the config dir on the command line if you want to use different config files. Well then I suggest that being fixed too. ( :- ) Can you elaborate, how such versioned directories should work? I can think of two possible solutions: 1 all files in a directory (versioned) in .lazarus or .lazarus-version 2 letting the name of the directory depend on the binary. In this case, renaming lazarus to lazarus-version would fix it. The first is easier, the second more flexible, however will probably be too problematic due to startlazarus and Lazarus self building properties. So that leaves us the first point, and a .lazarus/$lazversion is cleaner than .lazarus-$lazversion I think What about projects and packages? What should happen when a user starts a lazarus with a new version? Should the IDE automatically create copies? Is the lazversion enough? Maybe some users needs two different revisions of the same 0.9.23. If I understand it right, you want to keep several old lazarus versions. Somehow you distinguish them (e.g. icon). Why not simply use the command line parameter? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Ide doesn't find units in the fcl (or outside the project)
Zitat von Luca Olivetti [EMAIL PROTECTED]: En/na Mattias Gaertner ha escrit: On Mon, 16 Jul 2007 09:03:45 +0200 Luca Olivetti [EMAIL PROTECTED] wrote: En/na Mattias Gaertner ha escrit: Lazarus does not expand the unix shell ~ shortcut. And '*', '?' are normal characters. Ok, that explains (and solves) the problem with my units, but what about fpc standard ones? Can no fpc unit be found or only some? Try to find the Classes unit. (Find declaration on 'Classes' in the uses section). Yes, classes is found Good. If no fpc unit can be found, check the FPC path in the environment options. If only some units can not be found, then please rescan the FPC source. did that, many times :-( I know, just making sure ... If this does not work: What OS, distribution do you use? linux, mandriva 2007.1, and the not found units are definitely there, somewhere under /usr/share/fpcsrc What processor? 32 bit or 64 bit? What unit can not be found? Where is the corresponding .ppu? (Probably somewhere under /usr/lib/fpc/) I'm currently adding some more tests to Lazarus. I hope we find out the reason, so I can add a check for this and future users will not step into this. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Reducing Flickeron a TImage component
Zitat von A.J. Venter [EMAIL PROTECTED]: DoubleBuffered is a hint for the interface. The gtk2 intf always paints double buffered for each gdkwindow. That means paint events are double buffered, other painting not. The gtk1 intf has almost no doublebuffering. I'm not sure about the other interfaces. Aaah okay, that makes sense. I only did a small test: The gtk intf only paints once per Invalidate and there I see no flicker at all. That's because the bitbtn glyph handle is a memory handle and not an image on the screen. Maybe the win32 intf is creating a screen handle? That would explain the flickering. This is a GTK1 app. The catch is that if I don't call invalidate, the buttons go entirely blank instead of merely being grayed out, this includes the captions. If I DO call invalidate, I end up with a whole LOT of repaints all the time - which is... well ugly to say the least. I am still not sure how best to approach this. Shouldn't the buttons remain in their last state, repainted when damaged until such time as they are changed ? I'm not even moving anything here just painting some info onto SOME of the buttons and updating those periodically while setting the others disabled until such time as they are in use. And it's the DISABLED buttons which are giving me grief, the enabled once have a very slight flicker but it's actually almost nothing (again I don't know why that would be). I can reproduce the issue: gtk1 with enabled=false TBitBtn. I wonder, why only the flickering is only visible with a disabled bitbtn ... Mattias -- A.J. Venter CEO - OutKast Solutions C.C. http://www.outkastsolutions.co.za Cell: +27 83 455 9978 Fax: +27 21 413 2800 Office: +27 21 591 6766 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Powered by NetMail _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Problem with carbon apps
Zitat von Felipe Monteiro de Carvalho [EMAIL PROTECTED]: Hi, I created a trivial carbon-lcl app (just an empty form), compiled it successfully, but when I run it from the command line, it will refuse to receive focus. I mean, I click on it, but it doesn' t go to the top of z order, and doesn' t act like if it received focus. The maximize button works, but if I click on the main bar and drag it, it won' t move. Any ideas? See http://wiki.lazarus.freepascal.org/Carbon_Interface#Your_first_native_Carbon_app Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
