On Sat, 15 Jul 2006 13:54:21 +0200 Borut Maricic <[EMAIL PROTECTED]> wrote:
> Thank you Mattias! > > I will explore it further probably on Sunday and would like > to place a few additional questions right now, so that I > will maybe find the answers when I come back today late at > night: > > > Caption holds the value of the .lfm file, which will eventually be only > > UTF-8. But at the moment it is not guaranteed and will hold the value in the > > 'codepage' the creator of the .lfm used. > > It is planned that the interfaces translate strings on the fly and Caption > > will be UTF-8. So the above will probably replaced with > > StrCaption := > > PChar(UTF8StringToWindowsString(AWinControl.Caption)); > > or something like that. > > a1) > Since it is also possible that application programmer > assigns some value to the Caption property programmatically > (i.e. not only at design time in .lfm, which is then used in > PrepareCreateWindow): > > procedure TForm1.Button1Click(Sender: TObject); > begin Self.Caption:='123'; end; Of course the programmer is free to assign any value, even not UTF-8. But the LCL will eventually assume it is UTF-8. At the moment it assumes to be the local characterset. > I guess that the reader method of the LCL-control Caption > property should take care of possible necessity to convert > from some code page to UTF-8, before proceeding the value to > the widgetset (interface). In my view, it is only then that > we can say that the LCL-widgetset boundary is based on UTF8. > I guess this is the area you are saying needs to be done. > > If so, there might be many places that need that > check/conversion added and they are all in the LCL part that > is independent of the target platform. Do I get the idea > right here? Ehm. Maybe yes, maybe no. There are two parts: The .lfm files must be UTF-8 (eventually), because they are copied to other platforms (and because TReader/TWriter uses strings and the lfm does not contain characterset information). The widgetsets are platform dependent. Some even use 2-byte strings (UTF-16). Because the LCL use 1-byte strings the LCL interface must convert them anyway. That's why the conversion from/to UTF-8 right can be put into the LCL interfaces (gtk, win32, ...) and the LCL (TButton, TLabel, ...) stays unchanged. Advantage: Write once, run anywhere. So it is easier to write platform independent code. Disadvantage: When the programmer access platform specific functions and uses strings from the LCL, he is responsible for converting them. So it is harder to write platform dependent code. > a2) > > StrCaption := > > PChar(UTF8StringToWindowsString(AWinControl.Caption)); > > If you have the Unicode-enabling for Win32 here in mind > (which is my aim and therefore all the questions), as far as > I see it, the issue is not so easy. If we are not going to > have a separate WS win32w for that (I would personally not > be fond of separate WS), then there are lots of things to > change in WS win32. Yes. > As an example, since procedure > FinishCreateWindow will have to decide which winapi to call > (*A or *W), i believe we will for instance need an > additional TCreateWindowExParamsW (with PWideChars in it), > which would be used with *W-Winapi calls. Moreover, FCL is > now mapping (conditioned with $define UNICODE or the lack > thereof) to either *W, or to *A winapi-functions (as far as > I could see), while we will need both worlds to be available > to a WS/interface at the same time. I'm not a winapi expert. This decision is up to the windows devels. > a3) > An important and still opened architectural decision is: > Win32-Unicode support into WS Win32, or a new WS Win32w, > that would support only WinNT+ machines? Vincent proposed a > new WS: http://wiki.lazarus.freepascal.org/index.php/Talk:LCL_Unicode_Support > Here the application programmers are also asked for their > opinion - is it necessary to support all Win* with one exe, > or is it ok to have two, if need be? From the LCL point of > view, a new WS would be clearer and easier to develop, but > new Controls would then have to be supported in both (and in > WinCE too - Roozbeh wrote some ideas too). > > Mattias an others, I know many of you are very *nux oriented > but I would really appreciate any thoughts on these issues, > because I do not feel to have the necessary insight to make > an educated decision (and these decisions will determine the > whole further development of Unicode support for win, if it > really ever happens :( I don't know the TNT components mentioned on the wiki. 1. cyrillic or chinese will not work on all platforms. Especially on win9x. That's not the problem. The problem is, that the LCL should display cyrillic characters on all cyrillic systems, no matter, what encoding is used. It is up to programmer to provide translations. But he should only provide one translation per language, not one per language and encoding. 2. Win9x does not support the *W functions. Or more generally speaking: What, if the platform does not support unicode? In this case the UTF-8 string will loose information during conversion. And then converting the string back results in loss. For example: Open a form in the IDE, modify it and save it. Boom - all strings lost the foreign characters. That's a problem. 3. About a new win32u LCL interface: What will be the difference between win32 and win32u? Will the win32 loose information as in 2. and the win32u not? > > 1. Create a project (small test application). > > 2. Setup shortcuts for 'build lazarus' and 'configure build lazarus'. > > 3. 'configure build lazarus' to only build the LCL. > > 4. Change some things > > 5. compile lazarus (this only rebuilds the LCL, which automatically rebuilds > > the selected interface). > > 6. compile your project > > 7. run and debug program > > 8. On error, go back to 4. Otherwise to 9. > > 9. 'configure build lazarus' to build all. > > 10. test the IDE, on error go to 3. otherwise 11. > > 11. create a patch and send it. > > These are great cool news for me! Just two small stupid > questions: > > b1) What would be the appropriate wiki-page to copy this > there? Every interface need some specials. The above is already mentioned for the carbon, gtk2 and qt interface. Maybe it can be added to http://wiki.lazarus.freepascal.org/index.php/How_To_Help_Developing_Lazarus > b2) What is meant by the step 2 - what shortcuts? I can find > the menu items: Tools/Build Lazarus and Tools/Configure build > Lazarus, but have no clue about shortcuts in this respect. Keyboard shortcuts. Editor Options -> Keymapping. Mattias _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
