Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Bart]

On 9/27/14, Giuliano Colla  wrote:

> If Bart, who is the author and rightful "owner" of Pochecker, doesn't
> like the idea of making it too bloated, then creating a new tool becomes
> an option to be considered.

First of all, this is a community driven project, so extending the
PoChecker tool to have editing/fiximg/sanitizing capabilties is an
option, if so desired by the community.

I just did not envision this sort of tasks for the tool at all when I
started out creating it.
I already stated why I don't think extending it this way is a good
idea earlier in this thread.

About the scattering of tools/code for these tasks:

I created the SimplePoFiles, which basically is a rip-off of the
Translations unit (I cut out all parts I did not need) because:
- I needed line support (on which line does a PoItem start in the Po
file), and could not get this working using the Transations unit
(which uses PChars everywhere (PChars still creap me out), so I
translated all that code to be using Strings)
- My version then turned out to be 4 times faster loading a Po file
than the Translations unit, but that has been fixed in the mean time.
- I did not want to drag in the lconvencoding unit (all Lazarus po
files are UTF8, and lconvencoding drags in a whooping 1MB of static
data). Later on somebody added i18n capabilities to the tool, so this
argument now is not relevant anymore...

Maybe extra the capabilities that SimplePoFiles has can be ported back
to the Traslations unit. This would cut down on maintemance.

Bart

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Giuliano Colla]

Il 27/09/2014 21:58, Vincent Snijders ha scritto:



2014-09-27 17:59 GMT+02:00 Bart >:


On 9/27/14, Giuliano Colla mailto:giuliano.co...@fastwebnet.it>> wrote:

> Do you mean the procedures in /ide/idetranslations and
/lcl/translations
> or what?

Maybe he means in the updatepofiles tool
($Lazarus)/tools/updatepofiles.lpi ?


That is the one I meant, but I guess the IDE uses the same routines 
nowadays.




Yes, I checked, and currently updatepofiles in ($Lazarus)/tools is 
little more than a wrapper around the Translations unit, the same unit 
used by the IDE to manage translations.


To summarize, for translations currently there's a number of scattered 
tools, providing each one a limited number of functions, with some 
amount of overlap and with some functions missing.


In an ideal world

1. a maintainer would have a tool to quickly verify the state of the
   translations of the project he maintains, in order to possibly alert
   translators.
2. a translator would have a tool which quickly shows him the state of
   the translations he's responsible of, and is capable to perform a
   clean up, to edit the translations and to validate them, without
   being obliged to jump from one tool to another.

Pochecker provides point 1. Nothing at the moment provides point 2. This 
can be achieved either extending Pochecker functions, or by creating a 
new tool, which could take advantage for a large extent of existing 
units and components, but assembling them having in mind translator needs.


If Bart, who is the author and rightful "owner" of Pochecker, doesn't 
like the idea of making it too bloated, then creating a new tool becomes 
an option to be considered.


Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Mattias Gaertner]

On Sat, 27 Sep 2014 21:58:14 +0200
Vincent Snijders  wrote:

> 2014-09-27 17:59 GMT+02:00 Bart :
> 
> > On 9/27/14, Giuliano Colla  wrote:
> >
> > > Do you mean the procedures in /ide/idetranslations and /lcl/translations
> > > or what?
> >
> > Maybe he means in the updatepofiles tool
> > ($Lazarus)/tools/updatepofiles.lpi ?
> >
> >
> That is the one I meant, but I guess the IDE uses the same routines
> nowadays.

Yes, both use the routines of the LCL unit "translations".

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Vincent Snijders]

2014-09-27 17:59 GMT+02:00 Bart :

> On 9/27/14, Giuliano Colla  wrote:
>
> > Do you mean the procedures in /ide/idetranslations and /lcl/translations
> > or what?
>
> Maybe he means in the updatepofiles tool
> ($Lazarus)/tools/updatepofiles.lpi ?
>
>
That is the one I meant, but I guess the IDE uses the same routines
nowadays.

Vincent
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Option to allow fuzzy translations (Re: Fuzzy translations ignored)

[Péter Gábor]

I am working on the translations of Lazarus IDE and components.
Sometimes I need to see also fuzzy translations to check the followings:
- do they appear in the correct context
- do they fit in the space
- are the words used consistently
- etc.
I think that an option to allow displaying fuzzy translations would be
welcome for translators. This checkbox would be in good place below the
list of languages in Environment/Desktop/Language. And if it is enabled
a message box may warn the user that it's risky (program crash/bad
translations/etc.). This message would appear on the IDE startup or this
one option not to be saved to avoid unwanted effects in the future.

2014-09-06 00:28 keltezéssel, Giuliano Colla írta:
> 
> Il 05/09/2014 09:35, Reinier Olislagers ha scritto:
>> On 04/09/2014 23:34, Giuliano Colla wrote:
>>> But in that case it would be an advantage for developers (few) and a
>>> disadvantage for users (many).
>> No, it would be an advantage for the users because they don't get
>> inferior quality or incorrect translations...
>> Rather, it makes it painfully clear that the translator has not finished
>> 100% of the translation.
> A change from "Exit" to "Quit" (it happened) marks the translation
> fuzzy, and this may go unnoticed by many translators. Is it a good
> reason not to show the old translation?
> I'm afraid that users unfamiliar with Latin alphabet (such as Chinese,
> Russians, arabs, etc.) will hardly agree with your opinion.
>> Apparently not showing fuzzy translations is the standard way in other
>> open source projects. I remember a bug report that probably kicked off
>> the change referring to that (but don't know the mantis number).
> msgfmt provides the flag -f to accommodate the need to show fuzzy
> translations.
>> Regardless of the setting, fuzzy strings will have to be dealt with and
>> (as both a developer and translator) I'm happy that Laz now aligns with
>> general practice.
> On this point I fully agree with you. It would be nice if the steps
> before any release did include a quick check to the po files just to
> verify the amount of fuzzy and untranslated strings, in order to alert
> translators accordingly.
> Pochecker might be improved to provide a more user friendly quick full
> view of the status of all the translations in a folder, sort of what
> KBabel provided in the past. I'll look into it.
> 
> Giuliano
> 
> 
> -- 
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
> 
> 

-- 
Péter Gábor
p...@freemail.hu

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Bart]

On 9/27/14, Giuliano Colla  wrote:

> Do you mean the procedures in /ide/idetranslations and /lcl/translations
> or what?

Maybe he means in the updatepofiles tool ($Lazarus)/tools/updatepofiles.lpi ?

Bart

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Panel Visibility on QT/Win/Trunk

[Michael Thompson]

Ah, so it's always been that way.New to the ways of QT am I :-)

Thanks

Mike

On 27 September 2014 17:46, zeljko  wrote:

> On 09/27/2014 05:40 PM, Michael Thompson wrote:
>
>> G'day,
>>
>> I've just got today's latest.  I'm now seeing an issue with Panels under
>> QT/Win7.  Panels underneath other panels are now visible.
>> Buttons/Labels/Arrows underneath panels are being hidden.
>>
>> Problem is, I've gone through SVN, and I can't see anything even
>> slightly related.
>>
>> So, before I run and report anything - wondering if it's only me that's
>> seeing this?  I might have "wobbled" my system somehow...
>>
>> Anyone seeing this?
>>
>
> Panels are transparent under Qt by default (if color=clDefault). Dunno
> about win.
>
> zeljko
>
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Panel Visibility on QT/Win/Trunk

[zeljko]

On 09/27/2014 05:40 PM, Michael Thompson wrote:

G'day,

I've just got today's latest.  I'm now seeing an issue with Panels under
QT/Win7.  Panels underneath other panels are now visible.
Buttons/Labels/Arrows underneath panels are being hidden.

Problem is, I've gone through SVN, and I can't see anything even
slightly related.

So, before I run and report anything - wondering if it's only me that's
seeing this?  I might have "wobbled" my system somehow...

Anyone seeing this?


Panels are transparent under Qt by default (if color=clDefault). Dunno 
about win.


zeljko


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Panel Visibility on QT/Win/Trunk

[Michael Thompson]

G'day,

I've just got today's latest.  I'm now seeing an issue with Panels under
QT/Win7.  Panels underneath other panels are now visible.
Buttons/Labels/Arrows underneath panels are being hidden.

Problem is, I've gone through SVN, and I can't see anything even slightly
related.

So, before I run and report anything - wondering if it's only me that's
seeing this?  I might have "wobbled" my system somehow...

Anyone seeing this?

Mike T
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[zeljko]

On 09/27/2014 04:01 PM, Luca Olivetti wrote:

El 27/09/14 14:32, zeljko ha escrit:

On 09/27/2014 12:26 PM, Luca Olivetti wrote:

El 27/09/14 12:23, Luca Olivetti ha escrit:

El 27/09/14 12:09, Luca Olivetti ha escrit:


I'm puzzled: with a test program I see no difference in the size in
both
cases (right after showing the form and after pressing the button)
*and*
the size is the right one (in FormShow is always 1,1 btw).
I must be doing something else wrong (though the tiling is the correct
on under windows, mmmh..).


Found it, nothing wrong on my part: the test program used an auto
created form, the real application creates the form at run time *and*
right after creating the form, after the show GetWindowRect only returns
the client size. I have to introduce a delay for it to return the whole
window's size (and even then, from time to time, it only returns the
client size), so you were correct and this is insane.


And, for the record, with qt it's the same (only it seems the delay have
to be bigger).


Under X11 nobody knows exact window size (except client size setted up
by LCL or widgetset) until window is decorated by wm (read mapped -
shown on screen). See
http://qt-project.org/doc/qt-4.8/application-windows.html#x11-peculiarities


Yes, I understand, the "insanity" I referred to was about the underlying
environment, not Lazarus.
Anyway, I tried with this snipped of code to measure the decoration

procedure TForm1.Button1Click(Sender: TObject);
var f:TForm;
 i:integer;
 wr: TRect;
 h: Integer;
 w: Integer;
begin
   f:=TForm.Create(nil);
   f.top:=1;
   f.left:=1;
   f.width:=100;
   f.height:=100;
   f.show;
   i:=0;
   while true do
   begin
 Application.ProcessMessages;
 GetWindowRect(f.Handle,wr);
 h:=wr.bottom-wr.top;
 w:=wr.Right-wr.left;
 if (w<>f.width) and (h<>f.height) then
   break;
 i:=i+1;
 if i>1000 then
   break;
   end;
   Label1.Caption:=format('%d  w:%d h:%d',[i,w-f.width,h-f.height]);
   f.free;
end;


The f.top and f.left assignment was a (futile) attempt to avoid flashing
the form on screen.
With gtk2 2 I consistently get the result at the first iteration (i=0),
while with qt it takes at least 2 cycles, on occasions i counted up to 20.
Just FYI.


I know about it. It's explained at the mentioned link, also gtk2lcl puts 
size events in queue and process it via Application.ProcessMessages, qt 
provides such event when it's ready.


zeljko

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Luca Olivetti]

El 27/09/14 14:32, zeljko ha escrit:
> On 09/27/2014 12:26 PM, Luca Olivetti wrote:
>> El 27/09/14 12:23, Luca Olivetti ha escrit:
>>> El 27/09/14 12:09, Luca Olivetti ha escrit:

 I'm puzzled: with a test program I see no difference in the size in
 both
 cases (right after showing the form and after pressing the button)
 *and*
 the size is the right one (in FormShow is always 1,1 btw).
 I must be doing something else wrong (though the tiling is the correct
 on under windows, mmmh..).
>>>
>>> Found it, nothing wrong on my part: the test program used an auto
>>> created form, the real application creates the form at run time *and*
>>> right after creating the form, after the show GetWindowRect only returns
>>> the client size. I have to introduce a delay for it to return the whole
>>> window's size (and even then, from time to time, it only returns the
>>> client size), so you were correct and this is insane.
>>
>> And, for the record, with qt it's the same (only it seems the delay have
>> to be bigger).
> 
> Under X11 nobody knows exact window size (except client size setted up
> by LCL or widgetset) until window is decorated by wm (read mapped -
> shown on screen). See
> http://qt-project.org/doc/qt-4.8/application-windows.html#x11-peculiarities

Yes, I understand, the "insanity" I referred to was about the underlying
environment, not Lazarus.
Anyway, I tried with this snipped of code to measure the decoration

procedure TForm1.Button1Click(Sender: TObject);
var f:TForm;
i:integer;
wr: TRect;
h: Integer;
w: Integer;
begin
  f:=TForm.Create(nil);
  f.top:=1;
  f.left:=1;
  f.width:=100;
  f.height:=100;
  f.show;
  i:=0;
  while true do
  begin
Application.ProcessMessages;
GetWindowRect(f.Handle,wr);
h:=wr.bottom-wr.top;
w:=wr.Right-wr.left;
if (w<>f.width) and (h<>f.height) then
  break;
i:=i+1;
if i>1000 then
  break;
  end;
  Label1.Caption:=format('%d  w:%d h:%d',[i,w-f.width,h-f.height]);
  f.free;
end;


The f.top and f.left assignment was a (futile) attempt to avoid flashing
the form on screen.
With gtk2 2 I consistently get the result at the first iteration (i=0),
while with qt it takes at least 2 cycles, on occasions i counted up to 20.
Just FYI.

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[zeljko]

On 09/27/2014 12:26 PM, Luca Olivetti wrote:

El 27/09/14 12:23, Luca Olivetti ha escrit:

El 27/09/14 12:09, Luca Olivetti ha escrit:


I'm puzzled: with a test program I see no difference in the size in both
cases (right after showing the form and after pressing the button) *and*
the size is the right one (in FormShow is always 1,1 btw).
I must be doing something else wrong (though the tiling is the correct
on under windows, mmmh..).


Found it, nothing wrong on my part: the test program used an auto
created form, the real application creates the form at run time *and*
right after creating the form, after the show GetWindowRect only returns
the client size. I have to introduce a delay for it to return the whole
window's size (and even then, from time to time, it only returns the
client size), so you were correct and this is insane.


And, for the record, with qt it's the same (only it seems the delay have
to be bigger).


Under X11 nobody knows exact window size (except client size setted up 
by LCL or widgetset) until window is decorated by wm (read mapped - 
shown on screen). See

http://qt-project.org/doc/qt-4.8/application-windows.html#x11-peculiarities
It's almost same for gtk2 and other X11 widgetsets.
Problem is that you cannot query wm for eg. title bar height,form 
borders separately so then it will be easy to calculate everything.

Hope that wayland will address this problems.

zeljko


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Alt + tab IDE Windows

[Václav Valíček]

While I was using ubuntu, I had one virtual desktop + shortcuts 
(Ctrl+Alt+Arrow) to change desktop. Now, I'm using combination of 
anchordocking and virtual desktop for maximal "performance". There is 
also way to use hotcorners AFAIK in Unity and Cinnamon enviroments.


Václav Valíček
vac...@valicek.name

Dne 26.9.2014 v 22:36 Vojtěch Čihák napsal(a):


Hi,

when you are on Linux, why not have Lazarus on different virtual 
desktop than other apps (since there are more multi-windowed apps 
(like GIMP), it makes life easier).


I use KDE4 and I switch by Ctrl+F1, Ctrl+F2 ... instead of Alt+Tab.

KDE4 is probably the most configurable in this regard but Gnome or 
Mate should know it too.


Vojtěch

__
> Od: "\"Leonardo M. Ramé\"" 
> Komu: Lazarus mailing list 
> Datum: 26.09.2014 15:09
> Předmět: [Lazarus] Alt + tab IDE Windows
>

Hi, on GTK2, when I alt+tab from another app, I would like to bring to
front all Lazarus windows, instead I hav to alt+tab several times until
each window (editor, menu, Object Inspector, etc.) comes to front.

Is it possible to "link" all lazarus windows in a way that when alt+tab
they work as one app, instead of separated windows?.

Regards,
--
Leonardo M. Ramé
http://leonardorame.blogspot.com

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Pochecker (was Fuzzy traslations ignored)

[Giuliano Colla]

Il 27/09/2014 08:06, Vincent Snijders ha scritto:



2014-09-26 22:49 GMT+02:00 Maxim Ganetsky >:


26.09.2014 20 :53, Bart ?:

I propose to add two optional files sanitization/cleanup
features:

1. Make all entries that have formatting errors fuzzy.

2. Remove PreviousMsgId (comments starting with "#| ")
from entries
which are not fuzzy (in this case such comments are no
longer relevant,
but translation tools don't remove them themselves when
removing fuzzy
flag).


No, I'm not going to, and I strongly feel we should no go that
way.
The tool is for checking.


It's a pity. These features ease translations maintenance work and
are not covered by PO file editors.


Maybe it is better to add these feature to updatepofile?



Do you mean the procedures in /ide/idetranslations and /lcl/translations 
or what?


--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Luca Olivetti]

El 27/09/14 12:23, Luca Olivetti ha escrit:
> El 27/09/14 12:09, Luca Olivetti ha escrit:
>>
>> I'm puzzled: with a test program I see no difference in the size in both
>> cases (right after showing the form and after pressing the button) *and*
>> the size is the right one (in FormShow is always 1,1 btw).
>> I must be doing something else wrong (though the tiling is the correct
>> on under windows, mmmh..).
> 
> Found it, nothing wrong on my part: the test program used an auto
> created form, the real application creates the form at run time *and*
> right after creating the form, after the show GetWindowRect only returns
> the client size. I have to introduce a delay for it to return the whole
> window's size (and even then, from time to time, it only returns the
> client size), so you were correct and this is insane.

And, for the record, with qt it's the same (only it seems the delay have
to be bigger).

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Luca Olivetti]

El 27/09/14 12:09, Luca Olivetti ha escrit:
> 
> I'm puzzled: with a test program I see no difference in the size in both
> cases (right after showing the form and after pressing the button) *and*
> the size is the right one (in FormShow is always 1,1 btw).
> I must be doing something else wrong (though the tiling is the correct
> on under windows, mmmh..).

Found it, nothing wrong on my part: the test program used an auto
created form, the real application creates the form at run time *and*
right after creating the form, after the show GetWindowRect only returns
the client size. I have to introduce a delay for it to return the whole
window's size (and even then, from time to time, it only returns the
client size), so you were correct and this is insane.

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Luca Olivetti]

El 27/09/14 11:48, Hans-Peter Diettrich ha escrit:
> Luca Olivetti schrieb:
> 
>> Strange, on mageia 4, kde, lazarus 1.2.4 it doesn't work. What I'm
>> trying to do is to tile windows one next to the other. Using
>> GetWindowRect under windows I can do it properly, while on linux gtk the
>> windows overlap (i.e. with this layout
>>
>>
>>  A  B  C
>>  D  E
>>
>> A overlaps D and B overlaps E, the amount of overlap seems to be equal
>> to the height of the title bar).
> 
> IIRC the Linux (X11) window managers communicate only the size of the
> client area to the widgetsets, so that attempts to derive the total
> window extent from this information are subject to assumptions about the
> extent of the window "decoration" (caption, theme...). They also don't
> allow (offer no means for) ownerdraw of the NC area of a window.

Yes, but see my other mail to Giuliano: GetWindowRect seems to be
finding the correct total size (including decoration).

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Luca Olivetti]

El 27/09/14 00:05, Giuliano Colla ha escrit:
> 
> Il 26/09/2014 22:47, Luca Olivetti ha scritto:
>> El 26/09/14 22:45, Luca Olivetti ha escrit:
>>> Strange, on mageia 4, kde, lazarus 1.2.4 it doesn't work. What I'm
>>> trying to do is to tile windows one next to the other. Using
>>> GetWindowRect under windows I can do it properly, while on linux gtk the
>>> windows overlap (i.e. with this layout
>>>
>>>
>>>   A  B  C
>>>   D  E
>>>
>>> A overlaps D and B overlaps E, the amount of overlap seems to be equal
>>> to the height of the title bar).
>> Oh, and there's also a slight overlap between A-B, B-C and D-E
>>
> 
> Something which could affect your results is the timing. The window
> manager takes a time to add the decorations. Different window managers
> take different time. It's meant for human observers, which don't
> perceive a delay of some tens of milliseconds. Therefore it's given a
> low priority (and the mechanism is quite different from Windows to
> Linux). If you ask the size too early, you get a size which has not yet
> been adjusted.
> 
> You may verify if the function works properly by adding somewhere in
> your form a button and a label, and with the onClick of the button write
> in the label caption both the result of GetWindowSize and of
> GetWindowRect. You can't possibly push the button faster than the time
> it takes the window manager to decorate your window!

I'm puzzled: with a test program I see no difference in the size in both
cases (right after showing the form and after pressing the button) *and*
the size is the right one (in FormShow is always 1,1 btw).
I must be doing something else wrong (though the tiling is the correct
on under windows, mmmh..).
Oh, well, this program has to work in windows only, so I'll just
consider it a documentation error and go on with my life ;-)

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] GetWindowSize misleading documentation or bug?

[Hans-Peter Diettrich]

Luca Olivetti schrieb:


Strange, on mageia 4, kde, lazarus 1.2.4 it doesn't work. What I'm
trying to do is to tile windows one next to the other. Using
GetWindowRect under windows I can do it properly, while on linux gtk the
windows overlap (i.e. with this layout


 A  B  C
 D  E

A overlaps D and B overlaps E, the amount of overlap seems to be equal
to the height of the title bar).


IIRC the Linux (X11) window managers communicate only the size of the 
client area to the widgetsets, so that attempts to derive the total 
window extent from this information are subject to assumptions about the 
extent of the window "decoration" (caption, theme...). They also don't 
allow (offer no means for) ownerdraw of the NC area of a window.


On Windows instead the owner of a form can paint the entire area of a 
window (in WM_NCPAINT), so that the Windows window manager allows access 
to the full extent of a window. Also note that Windows uses distinct 
windows for every TWinControl, while these are ordinary controls in X11, 
under exclusive management of the widgetset.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus