[lazarus] FPC 2.1.1 and spaces in output path
i dont know if this is a known problem, and if its a lazarus problem or fpc i have setup an fpc 2.1.1 from yesterday and use the fpc.exe as compiler to use crosscompiling. works fine but when spaces are in the output path ppc386.exe has an problem example: Output Path : c:\fpc test\ ppc386 says : cant write to c:\fpc permission denied Christian _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch: Target CPU
@Yury ok, first steps seems to be ok but i think some things schould be documented in the wiki when i use your wiki steps to produce the lcl-wince it dosend work because the fcl isnt build in fpc-wince wiki are only described how to build an rtl so make fcl_install OS_TARGET=wince CPU_TARGET=arm PP=ppcrossarm.exe schould added to your batchfile first when i try to build the lcl for i386-wince (emulator) ill get an error that the makefile dont support this target havent you used the emulator bevore ? Christian - Original Message - From: Yury Sidorov [EMAIL PROTECTED] To: lazarus@miraclec.com Sent: Saturday, March 11, 2006 2:52 PM Subject: Re: [lazarus] Patch: Target CPU From: Christian U. [EMAIL PROTECTED] nice, that means i can use the wince interfaace now without crapping my options ? what fpc version is needed to use fpc instead ppc386 ?? Yes. Compile fpc from latest svn branch. Also add the following lines to fpc.cfg #IFDEF FPC_CROSSCOMPILING -XP$FPCTARGET- #ENDIF Yury Sidorov. _ 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] Unit output directory vs Target file name
On Sun, 12 Mar 2006, Mattias Gaertner wrote: On Sat, 11 Mar 2006 20:36:21 +0100 (CET) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 11 Mar 2006, Mattias Gaertner wrote: Here is the november mail: On Tue, 8 Nov 2005 20:16:21 +0100 (CET) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] This is correct. Revision 1698 contains this fix. The behaviour is now: - If -o contains a path, it overrides any previous -FE. If -o does not contain a path, it leaves any -FE setting intact. - If -FE is specified after -o, it will override the output path. So -FEdir1 -odir2/binfile outputs in dir2 -FEdir2 -obinfile outputs in dir2 -odir1/binfile -FEdir2 outputs in dir2 It seems, the description is nice, but the examples demonstrates the reality. ;) ? Do you think it's not correct ? home: ppc386 -iD 2005/11/28 home: ls dir2/ p.pp home: ppc386 -FEdir1 -odir2/binfile p.pp home: ls dir2/ p.pp home: ls dir2 binfile* p.o home: rm dir2/binfile; ppc386 -FEdir2 -obinfile p.pp home: ls dir2 binfile* p.o home: rm dir2/binfile ; ppc386 -odir1/binfile -FEdir2 p.pp home: ls dir2 binfile* p.o home: ls dir2/ p.pp So, unless the compiler was changed afterwards, the behaviour is exactly as described, so it seems to me ? I admit to being sloppy from time to time, but I tested the behaviour extensively that time... I'm sure you did. But -o overrides the whole -FE, not only the output of the exe, but the unit output too. FPC 2.0.2 and 2.0.3 (a few days ago) do this: ppc386 -FEdir1 -odir2/binfile p.pp ls -l dir1 dir2 dir1: dir2: binfile p.o uni1.ppu unit1.o Ah. OK, I see. Note that my remarks were for 2.1.1, not 2.0.2 or 2.0.3 In 2.1.1/2.0.3 the used variables for unit output path and exe output path are totally different: OutputUnitDir only set by -FU OutputExeDir set by -FE and -o OutputFileonly set by -o I don't see any other code (Checked today's code) I diffed 2.1.1 with todays 2.0.3 and the code handling these options is exactly the same. Peter, Florian, any suggestions ? Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
From: Darius Blaszijk [EMAIL PROTECTED] I suggest you take a look here: http://wiki.lazarus.freepascal.org/index.php/GUI_design. Although it needs some cleanup and reordering and a lot of adding to, it is a good start. OK. I have learned over time that picking just some interface guide is simply not sufficient. It depends on the widgetset how the form will showup. So implementing a look and feel should work for all widgets, unless we implement some mechanism that will enable a look per widget. I think the main problem is font sizes in different widgetsets. It can be solved by implementing UI scaling depending on current screen/font DPI. UI guidelines will consider 96 dpi of the screen. Does UI scaling work in Lazarus? But before we go there there's a bunch of other more important stuff to do. For instance, there are still a lot of forms that are hardcoded (see at the bottom of the wikipage) we need to do them first. Second step is redoing some of the forms that are just too crowded. Yes. That's why I am talking of UI guidelines now. Such guidelines are needed for forms to lfm conversion and redesigning pages. - Images on regular buttons (OK, Cancel, etc) That's subject to taste. But generally cosidered all standard icons are equiped with a glyph to make the form more intuitive. At least it need to be configurable - disable/enable images on buttons. - Different size of buttons. They must be the same size, except some special cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
On Sun, 12 Mar 2006, Yury Sidorov wrote: - Different size of buttons. They must be the same size, except some special cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Most buttons in my programs need to be 100x25. Dutch texts tend to be longer. It's hard to make a 'beautiful' design; what's more, the rules differ on all platforms. Not to mention that it is very much a matter of taste. All you can hope for is that the design is consistent: i.e. the same design rules in all dialogs in a program. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
From: Michael Van Canneyt [EMAIL PROTECTED] On Sun, 12 Mar 2006, Yury Sidorov wrote: - Different size of buttons. They must be the same size, except some special cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Most buttons in my programs need to be 100x25. Dutch texts tend to be longer. It's hard to make a 'beautiful' design; what's more, the rules differ on all platforms. Not to mention that it is very much a matter of taste. All you can hope for is that the design is consistent: i.e. the same design rules in all dialogs in a program. I am trying to create such design rules :) Speaking about button sizes I want to prevent the situation when every button has different size. For example OK button is 30px with and Cancel button is 60px with. They must have the same width: 75px or 100px - it can be discussed. We need to find some button width, which is good for every language in most cases. And use this width as default. Yes, UI is matter of taste. But there will be no nice looking and consistent UI without some documented UI guidelines. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Cross Lazarus Release
On Sun, 12 Mar 2006 03:34:22 +0100 [EMAIL PROTECTED] wrote: Are there plans to release a Cross Lazarus Release? e.g. Host: Win32, Target: Win32/Linux/Mac/etc... similar to CrossFPC There is an rpm for cross linux to win32. For other crosses we need volunteers. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
On Sun, 12 Mar 2006 12:39:08 +0200 Yury Sidorov [EMAIL PROTECTED] wrote: From: Michael Van Canneyt [EMAIL PROTECTED] On Sun, 12 Mar 2006, Yury Sidorov wrote: - Different size of buttons. They must be the same size, except somespecial cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Most buttons in my programs need to be 100x25. Dutch texts tend to be longer. It's hard to make a 'beautiful' design; what's more, the rules differ on all platforms. Not to mention that it is very much a matter of taste. All you can hope for is that the design is consistent: i.e. the same design rules in all dialogs in a program. I am trying to create such design rules :) Speaking about button sizes I want to prevent the situation when every button has different size. For example OK button is 30px with and Cancel button is 60px with. They must have the same width: 75px or 100px - it can be discussed. We need to find some button width, which is good for every language in most cases. And use this width as default. Yes, UI is matter of taste. But there will be no nice looking and consistent UI without some documented UI guidelines. We can set a minimum width of buttons. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch: Target CPU
From: Christian U. [EMAIL PROTECTED] ok, first steps seems to be ok but i think some things schould be documented in the wiki when i use your wiki steps to produce the lcl-wince it dosend work because the fcl isnt build in fpc-wince wiki are only described how to build an rtl so make fcl_install OS_TARGET=wince CPU_TARGET=arm PP=ppcrossarm.exe schould added to your batchfile first I added FCL building instructions to fpc-wince wikik. when i try to build the lcl for i386-wince (emulator) ill get an error that the makefile dont support this target havent you used the emulator bevore ? i386-wince target is abandoned currently because ARM WinCE emulator is available: http://msdn.microsoft.com/mobility/windowsmobile/downloads/emulatorpreview/default.aspx Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
From: Mattias Gaertner [EMAIL PROTECTED] Yury Sidorov [EMAIL PROTECTED] wrote: From: Michael Van Canneyt [EMAIL PROTECTED] On Sun, 12 Mar 2006, Yury Sidorov wrote: - Different size of buttons. They must be the same size, except somespecial cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Most buttons in my programs need to be 100x25. Dutch texts tend to be longer. It's hard to make a 'beautiful' design; what's more, the rules differ on all platforms. Not to mention that it is very much a matter of taste. All you can hope for is that the design is consistent: i.e. the same design rules in all dialogs in a program. I am trying to create such design rules :) Speaking about button sizes I want to prevent the situation when every button has different size. For example OK button is 30px with and Cancel button is 60px with. They must have the same width: 75px or 100px - it can be discussed. We need to find some button width, which is good for every language in most cases. And use this width as default. Yes, UI is matter of taste. But there will be no nice looking and consistent UI without some documented UI guidelines. We can set a minimum width of buttons. OK. I think 90x25 will be good default/minimum button size. Please test the following common button captions on your native language: Cancel, Add, Insert, Default, Remove, Delete, Apply, Retry, Load, Save. For russian and ukrainian 90x25 is good. Yury. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Cannot build Lazarus
Vincent, thanks for your help! I decided to use 2.0.2 from now on. I did some fooling around with files and downloads etc. Maybe it's a good idea to put my solution in the Lazarus svn wiki??? Btw I already solved the problem friday, but for my job I used almost the whole friday evening and the saterday to solve a huge problem. During that I made great use of Lazarus! I will post that in a seperate thread. Thanks again! Jouke - Original Message - From: Vincent Snijders [EMAIL PROTECTED] To: lazarus@miraclec.com Sent: Friday, March 10, 2006 4:31 PM Subject: Re: [lazarus] Cannot build Lazarus Jouke Rensma wrote: Please advice then: is it better to use 2.0.2? Also when I'm developing for Lazarus itself (or at least try to :-) )? Yes, I think so. Less things to worry about. If you want to develop for lazarus itself you do need *Lazarus* from SVN. Vincent _ 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] Cannot build Lazarus
Jouke Rensma wrote: Vincent, thanks for your help! I decided to use 2.0.2 from now on. I did some fooling around with files and downloads etc. Maybe it's a good idea to put my solution in the Lazarus svn wiki??? Feel free to add it. (I don't know what you mean by solution, but I will read it). Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
From: Darius Blaszijk [EMAIL PROTECTED] I suggest you take a look here: http://wiki.lazarus.freepascal.org/index.php/GUI_design. Although it needs some cleanup and reordering and a lot of adding to, it is a good start. OK. I did already the reordering. I have learned over time that picking just some interface guide is simply not sufficient. It depends on the widgetset how the form will showup. So implementing a look and feel should work for all widgets, unless we implement some mechanism that will enable a look per widget. I think the main problem is font sizes in different widgetsets. It can be solved by implementing UI scaling depending on current screen/font DPI. UI guidelines will consider 96 dpi of the screen. Does UI scaling work in Lazarus? Not only the size differs, but I believe in gtk bold does not show up as in windows. But before we go there there's a bunch of other more important stuff to do. For instance, there are still a lot of forms that are hardcoded (see at the bottom of the wikipage) we need to do them first. Second step is redoing some of the forms that are just too crowded. Yes. That's why I am talking of UI guidelines now. Such guidelines are needed for forms to lfm conversion and redesigning pages. I agree with you, I was just pointing out that converting to LFM should have priority as we can finally make a consistent look throughout lazarus. The guidelines are very welcome indeed, I have made some attempts in the past, but never got to finisihing it. Please add to the wiki. - Images on regular buttons (OK, Cancel, etc) That's subject to taste. But generally cosidered all standard icons are equiped with a glyph to make the form more intuitive. At least it need to be configurable - disable/enable images on buttons. We could use the sessionproperties property of a form (http://wiki.lazarus.freepascal.org/index.php/TXMLPropStorage). This way we could ship different XML files with lazarus that hold different look and feel settings. This needs to be discussed first with a core member like Vincent or Mattias. - Different size of buttons. They must be the same size, except some special cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. We could use the minimum size like Mattias offered. Darius _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
Yury Sidorov ha scritto: From: Mattias Gaertner [EMAIL PROTECTED] Yury Sidorov [EMAIL PROTECTED] wrote: From: Michael Van Canneyt [EMAIL PROTECTED] On Sun, 12 Mar 2006, Yury Sidorov wrote: - Different size of buttons. They must be the same size, except somespecial cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. Most buttons in my programs need to be 100x25. Dutch texts tend to be longer. It's hard to make a 'beautiful' design; what's more, the rules differ on all platforms. Not to mention that it is very much a matter of taste. All you can hope for is that the design is consistent: i.e. the same design rules in all dialogs in a program. I am trying to create such design rules :) Speaking about button sizes I want to prevent the situation when every button has different size. For example OK button is 30px with and Cancel button is 60px with. They must have the same width: 75px or 100px - it can be discussed. We need to find some button width, which is good for every language in most cases. And use this width as default. Yes, UI is matter of taste. But there will be no nice looking and consistent UI without some documented UI guidelines. We can set a minimum width of buttons. OK. I think 90x25 will be good default/minimum button size. Please test the following common button captions on your native language: Cancel, Add, Insert, Default, Remove, Delete, Apply, Retry, Load, Save. For russian and ukrainian 90x25 is good. Please do not try to create unnecessary constraints: each field of application has different requirements. Default size is not much relevant, minimum size is a horrible constraint. Default size: you may easily set all buttons to the same size in a form, if you wish to do so, just by selecting all at the same time and setting just once Width and Height as required. But there's no all-purpose default size. You may have touch screen application, where button size isn't related to the caption, but to finger size, plus calibration drift. Or application where BitButtons are used with only the glyph and no caption, etc, etc, Whichever default size you select, it's only good for some fields of application. 75x25 is as good as any other choice. Minimum size: it's senseless. See above. Why shoud I use a 90x25 button just to show a + sign which doesn't get translated? It appears as ugly as a button with a truncated caption! The look of the form is Lazarus user responsibility, not Lazarus responsibility. You may provide guidelines for inexperienced users, tools to help reaching the result needed, but that's all. Once Qt interface is operational, you may easily provide Style, which is much more important to provide a better, user defined look. Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
On 3/12/06, Giuliano Colla [EMAIL PROTECTED] wrote: The look of the form is Lazarus user responsibility, not Lazarus responsibility. You may provide guidelines for inexperienced users, tools to help reaching the result needed, but that's all. We are talking about the way the IDE looks, not about software created with Lazarus. You got it all wrong. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Lines in TMemo
I use a TMemo for displaying some information on my programs. I use empty lines to separate paragraphs. Like I do now in this text. Unfortunately when I reopen the project, in the design the empty lines are gone, but they are there when I run the program. In the lfm-file there is an empty line, so I suppose that when loading the project again this empty line is ignored, but that during runtime the information is taken from the lrs-file where the empty line is stored. I cannot finde a hint when looking at the source of TMemo, so I suppose I have to delve deeper into Lazarus to find a solution to make sure that an empty line will be stored correct in the lfm-file. Where do I have to look for that?
Re: [lazarus] User interface design guidelines
From: Darius Blaszijk [EMAIL PROTECTED] From: Darius Blaszijk [EMAIL PROTECTED] I suggest you take a look here: http://wiki.lazarus.freepascal.org/index.php/GUI_design. Although it needs some cleanup and reordering and a lot of adding to, it is a good start. OK. I did already the reordering. I will add some info to that page based on this discussion. I have learned over time that picking just some interface guide is simply not sufficient. It depends on the widgetset how the form will showup. So implementing a look and feel should work for all widgets, unless we implement some mechanism that will enable a look per widget. I think the main problem is font sizes in different widgetsets. It can be solved by implementing UI scaling depending on current screen/font DPI. UI guidelines will consider 96 dpi of the screen. Does UI scaling work in Lazarus? Not only the size differs, but I believe in gtk bold does not show up as in windows. Bold is rarely used in dialogs. I think it is not big problem. But before we go there there's a bunch of other more important stuff to do. For instance, there are still a lot of forms that are hardcoded (see at the bottom of the wikipage) we need to do them first. Second step is redoing some of the forms that are just too crowded. Yes. That's why I am talking of UI guidelines now. Such guidelines are needed for forms to lfm conversion and redesigning pages. I agree with you, I was just pointing out that converting to LFM should have priority as we can finally make a consistent look throughout lazarus. The guidelines are very welcome indeed, I have made some attempts in the past, but never got to finisihing it. Please add to the wiki. Sure. I want to convert some forms and opened this topic to discuss how things need to look :) - Images on regular buttons (OK, Cancel, etc) That's subject to taste. But generally cosidered all standard icons are equiped with a glyph to make the form more intuitive. At least it need to be configurable - disable/enable images on buttons. We could use the sessionproperties property of a form (http://wiki.lazarus.freepascal.org/index.php/TXMLPropStorage). This way we could ship different XML files with lazarus that hold different look and feel settings. This needs to be discussed first with a core member like Vincent or Mattias. Hmm. As I see only images need to be changed. They can be handled by some sort of global image list, which can hold different set of images. - Different size of buttons. They must be the same size, except some special cases where caption is long. I think this is not good practice. How do you decide when the caption is too long seing the captions are translated too. I can say based on my experience only small number of buttons need to be wider due to translated text size. I always use 75x23 px buttons if possible. 75x23 buttons is default in all MS programs. We could use the minimum size like Mattias offered. I agree. We must decide that size :) I propose 90x25. Yury Sidorov. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
Felipe Monteiro de Carvalho ha scritto: On 3/12/06, Giuliano Colla [EMAIL PROTECTED] wrote: The look of the form is Lazarus user responsibility, not Lazarus responsibility. You may provide guidelines for inexperienced users, tools to help reaching the result needed, but that's all. We are talking about the way the IDE looks, not about software created with Lazarus. You got it all wrong. Sorry for the misunderstanding. Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Patch To NewDialog
Patch To NewDialog... Yahoo! Acesso Grátis Internet rápida e grátis. Instale o discador agora! newdialog.diff Description: 3010491862-newdialog.diff
Re: [lazarus] FPC 2.1.1 and spaces in output path
i dont know if this is a known problem, and if its a lazarus problem or fpc i have setup an fpc 2.1.1 from yesterday and use the fpc.exe as compiler to use crosscompiling. works fine but when spaces are in the output path ppc386.exe has an problem example: Output Path : c:\fpc test\ ppc386 says : cant write to c:\fpc permission denied I think I've seen some note before saying to not use spaces for the install directory _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lines in TMemo
On Sun, 12 Mar 2006 16:35:57 +0100 Marien van Westen [EMAIL PROTECTED] wrote: I use a TMemo for displaying some information on my programs. I use empty lines to separate paragraphs. Like I do now in this text. Unfortunately when I reopen the project, in the design the empty lines are gone, but they are there when I run the program. In the lfm-file there is an empty line, so I suppose that when loading the project again this empty line is ignored, but that during runtime the information is taken from the lrs-file where the empty line is stored. I cannot finde a hint when looking at the source of TMemo, so I suppose I have to delve deeper into Lazarus to find a solution to make sure that an empty line will be stored correct in the lfm-file. Where do I have to look for that? What widgetset? gtk, win32? What line endings? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch To NewDialog
On Sun, 12 Mar 2006 14:04:40 -0300 (ART) Júnior Gonçalves [EMAIL PROTECTED] wrote: Patch To NewDialog... Thanks. I moved the code to UpdateDescription, so it is only updated once per click. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch for Smart Hint
On Sun, 12 Mar 2006 17:35:25 +0100 Tomas Gregorovic [EMAIL PROTECTED] wrote: Hi, I have enhanced smart hints little bit by adding the class name before properties and othe class members. I have also fixed some typos. Thanks. Applied. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] User interface design guidelines
On Sun, 12 Mar 2006 17:42:41 +0200 Yury Sidorov [EMAIL PROTECTED] wrote: [...] 75x23 buttons is default in all MS programs. We could use the minimum size like Mattias offered. I agree. We must decide that size :) I propose 90x25. I added in dialogs.pp; var MinimumDialogButtonWidth: integer = 90; MinimumDialogButtonHeight: integer = 25; Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Synedit patch
On Sat, 11 Mar 2006 20:01:26 -0700 L505 [EMAIL PROTECTED] wrote: Implemented GetHighlighterAttriAtRowColEx from looking at Delphi synedit. Better token sniffing available. See attached. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch for 1851
On Sat, 11 Mar 2006 16:17:24 +0100 Matthijs Willemstein [EMAIL PROTECTED] wrote: Enclosed patch should fix 1851 1. BeginDrag is defined 2 times in TControl in controls.pp Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] patch for TextOut in UTF8
On Fri, 10 Mar 2006 19:12:39 +0100 darekm [EMAIL PROTECTED] wrote: repair patch Applied. Thank you. Mattias Darek Mattias Gaertner wrote: 2. When I test my Delphi application, I noticed that function with any strings operators work longer, even if then not reach that line (Delphi make longer preamble to that functions) , enough to move that code to subfunction - in FPC is the same (if somebody understand me) That's because of the hidden exception frame. AFAIK using string constants without operators do not create such frames. That's why the lazarus code at all time critical places works without string operators. Thanks for explain!! Darek PS. What with my last patch about tComboBox I will search ... Mattias _ 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] findreplace patch
On Tue, 07 Mar 2006 22:43:23 +0800 Funky Beast [EMAIL PROTECTED] wrote: combobox.zip:- Added RetainPrefixCase capability for AutoCompleteText to preserve the original case that the user typed. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] findreplace patch
On Tue, 07 Mar 2006 22:43:23 +0800 Funky Beast [EMAIL PROTECTED] wrote: combobox.zip:- Added RetainPrefixCase capability for AutoCompleteText to preserve the original case that the user typed. findreplace.zip:- -Added accelerator for Replace All button and Yes to All button -Enabled AutoComplete for find and replace comboboxes (Needs above combobox patch applied first for RetainPrefixCase feature). -When there are selected text in the source editor, invoking findreplace function automatically enables the Selected Text radiobutton in findreplace dialog, which will be restored to its original state after the findreplace function is completed. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch for TBitmap Mask proposal
On Fri, 10 Mar 2006 14:15:44 +0100 Tomas Gregorovic [EMAIL PROTECTED] wrote: Hi, finally I have finished my long battle around bitmap masks. I have implemented method CreateBitmapMask, which creates mask according to transparent color. The white pixels stand for opacity and black for transperency (I have found out that this is in contrary to Delphi). I hope this routine will function under all supported OSes - I have tested it on win only. Next, I had to change btimap and image transparent* properties to behave like Delphi equivalents. The difficult problem was how to keep transparency built in source of bitmaps such as *.xpm. This I have solved by creating new seperate mask accessible throught AlphaMaskHandle, which stores alpha channel data that were previously stored in MaskHandle object. I have attached small test project, which nicely illustrates right mask functioning. You added an AlphaMaskHandle, but I don't see when we need both MaskHandle and AlphaMaskHandle. Why not use the MaskHandle for the Mask? And btw: Not all widgetsets use separate Handle and MaskHandle. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] IDE component icons
Here are some modified existing component icons which have been changed to have a blue accent. Personally I think they look better. Hopefully other people agree with me :-) . Regards, George
Re: [lazarus] IDE component icons
George Lober wrote: Here are some modified existing component icons which have been changed to have a blue accent. Personally I think they look better. Hopefully other people agree with me :-) . Please disregard the tlabelededit_blue_mod.ico, I shouldn't have sent that one. Thanks, George _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Compiler Option Dialog
For now, its not really a restructure! Its just an issue with the GUI layout (clipping of text). I am busy looking at the available options for resizing and anchor properties. The major thing I want is not to clip any text, or at least resize the component when you resize the dialog, so I can see all the text. I made a dummy copy of the dialog for a test app, so I can play around with the different options, without having te recompile Lazarus after every change. Regards, - Graeme - On 3/11/06, Mattias Gaertner [EMAIL PROTECTED] wrote: On Sat, 11 Mar 2006 19:09:19 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: Hi, Does anybody mind if I make some changes to the Compiler Options Dialog. I want to enable some alignment settings. Resizing this dialog doesn't resize the Group Boxes, etc... I am using Linux (Ubuntu 5.10). Under Windows 2000 it doesn't look this bad though. Please go ahead. This dialog has grown over the years. It needs a clean up. How will you restructure it? Mattias _ 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
[lazarus] tesing and setting read-only on files
Hi, Does Lazarus or FPC have a cross platform routine to set file attributes (eg: ReadOnly), or test for file attributes. Regards, - Graeme - _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lines in TMemo
Win 32 in the LFM-file I have: object Memo1: TMemo Lines.Strings = ( 'regel 1' 'regel 2' 'regel 3' 'regel 4' ) TabOrder = 0 Left = 13 Height = 275 Top = 13 Width = 366 end in the lrs-file: +'eight'#3','#1#3'Top'#3#239#0#5'Width'#3#144#1#0#5'TMemo'#5'Memo1'#13'Lines.' +'Strings'#1#6#7'regel 1'#6#7'regel 2'#6#0#6#7'regel 3'#6#7'regel 4'#0#8'TabO' +'rder'#2#0#4'Left'#2#13#6'Height'#3#19#1#3'Top'#2#13#5'Width'#3'n'#1#0#0#0 So when I want to make an emty line I cannot hit the Enter-key twice (like in Delphi) I have to enter at least a space to get an empty line. I supposed two times Enter would result in something like ' ' in the LFM-file. MarienOn 3/13/06, Mattias Gaertner [EMAIL PROTECTED] wrote: On Sun, 12 Mar 2006 16:35:57 +0100Marien van Westen [EMAIL PROTECTED] wrote: I use a TMemo for displaying some information on my programs. I use empty lines to separate paragraphs. Like I do now in this text. Unfortunately when I reopen the project, in the design the emptylines are gone, but they are there when I run the program. In the lfm-file there is an empty line, so I suppose that when loading the project again this empty line is ignored, but that during runtime the information is taken from the lrs-file where the empty line is stored. I cannot finde a hint when looking at the source of TMemo, so I suppose I have to delve deeper into Lazarus to find a solution to make sure that an empty line will be stored correct in the lfm-file. Where do I have to look for that?What widgetset? gtk, win32?What line endings?Mattias_ To unsubscribe: mail [EMAIL PROTECTED] withunsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: tesing and setting read-only on files
Sorry I found it in SysUtils = FileGetAttr and FileSetAttr PS: I should learn to use Grep more often! :-) Regards, - Graeme - On 3/13/06, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Hi, Does Lazarus or FPC have a cross platform routine to set file attributes (eg: ReadOnly), or test for file attributes. Regards, - Graeme - _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] TScrollbar and TTrackbar
I noticed a different behaviour of TScrollbar under MSWindows and Linux. In MSWindows the stand alone Scrollbar acts like a Trackbar, but when you compile a program with a scrollbar on a Linux machine the sliding part covers the whole area of the Scrollbar. Is it possible (yes, but is it desirable) to let a standalone scrollbar behave like a Trackbar, In that way a program written with Delphi (where the Scrollbar is used instead of the Trackbar) and converted to Lazarus will have the same behaviour under MSWindows and Linux Marien
Re: tesing and setting read-only on files
Graeme Geldenhuys wrote: Sorry I found it in SysUtils = FileGetAttr and FileSetAttr PS: I should learn to use Grep more often! :-) Search - Find in files - Search in directories is my favourite. :-) Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: tesing and setting read-only on files
Search - Find in files - Search in directories is my favourite. :-) What can Lazarus NOT do? ;-) Graeme. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Images in imgviewer
In the examples there is a program Imgviewer. When I load a picture in it and I make the picture smaller, the colors get blurred. It doesn't matter if the picture is a BMP or JPG. Is this a Lazarus question or a Free-pascal question? It would be nice if it could be cured, because I am working on a foto-cataloguing program in which you can also see the picture in a smaller format. Marien
