I find any and all forms in a running Laz program can not be reduced in size below the original startup size. (neither height nor width can be reduced)
It is possible to increase the size, but can only be reduced back to the original.

To be clear: if I grab the edge of a running form, I can not make the form wondering if anybody else has similar issues before calling a bug ?

Lazarus 1.7 r51734M FPC 3.0.0 i386-linux-gtk 2

Thanks - SteveG

No form resizing issues with Lazarus 1.7 r51739 FPC 3.0.0 using win32/gtk2 widgets on Windows 7.

Can you reproduce it with a new & clean application?

Denis

I reported an issue (related to .Constraints) that seems to be similar: http://bugs.freepascal.org/view.php?id=29563
Unfortunately no one else of the commenters could reproduce it yet.

2016-02-28 01:41 keltez?ssel, steveg ?rta:

Running a newly created Laz program shows the same effect - unable to reduce the form size below the initial startup size. I can make the form larger, and reduce again, but only to the original startup sizing.

Lazarus 1.7 r51734M FPC 3.0.0 i386-linux-gtk 2
Lubuntu 15.10

Not too sure if its the same here. Mine seems to be only limited to not resizing 'below' the original size.
Other than that, all works fine

CONFIRMED here!

I just tried with a very small test program I have made for checking GPIO handling with FreePascal on a Raspberry Pi.

Same issue:
I run the application from the file manager and when I try to resize the form it allows me to make it bigger in both directions, but it will not resize down below the initial size.
It is as if there were Constraints set on the minimum size in X and Y but I just checked and there are none.

My setup is:
FreePascal 3.0.0 release
Lazarus 1.6 release
Both built from svn sources.

Hardware: Raspberry Pi2
Operating system: Raspbian Jessie from Feb 9, 2016 (arm-linux-gtk2)

steveg wrote

Not too sure if its the same here. Mine seems to be only limited to not resizing 'below' the original size. Other than that, all works fine

I would say you have accidentally set Constraints. It now has local menu entries to set the Min and Max values.
Could that "accident" happen in all new tests? Ok, maybe not.

P?ter, did you bisect for the guilty revision of your bug?

P.S.
Please people quote only relevant text and then write your reply under it. Mixing different quote styles makes it difficult to follow the thread.

Juha Manninen wrote

I would say you have accidentally set Constraints. It now has local menu entries to set the Min and Max values.

Do you mean that if I select the form and use Object Inspector to set Constraints I am getting to the wrong place?
If so exactly how do I reach this new local menu?
As I stated in my reply a short while ago I also have this behaviour.

Bo Berglund wrote

Do you mean that if I select the form and use Object Inspector to set Constraints I am getting to the wrong place? If so exactly how do I reach this new local menu?

Object Inspector is the right place to set Constraints, yes. Select the Constraints title and then right-click. The entries for setting Min and Max values has been there since Lazarus 1.4.x IIRC, so they are not really new any more.

As I stated in my reply a short while ago I also have this behaviour.

I don't. Just tested again.
Somebody please bisect the guilty revision that caused the bug for you.

Regards,
Juha

Juha Manninen wrote

Object Inspector is the right place to set Constraints, yes. Select the Constraints title and then right-click. The entries for setting Min and Max values has been there since Lazarus 1.4.x IIRC, so they are not really new any more.

I always just clicked the + before the title and it expands into the 4 boxes for min and max X and Y.
Now when I rightclick the title I get a pop-up where the two top items are:
Set MaxHeight=280, MaxWidth=532
Set MinHeight=280, MinWidth=532

Activating either of tehse moves tghese numbers into the property boxes and then disables the popup menu item.

In my case all the property boxes were set to 0 but tghe application behaves like the property has been set to Min these numbers.

I also checked my formmain.lfm file to see if there were hidden properties there but no:

object frmMain: TfrmMain
Left = 236
Height = 280
Top = 166
Width = 532
Caption = 'GPIO port testing utility'
ClientHeight = 280
ClientWidth = 532
OnActivate = FormActivate
OnClose = FormClose
OnCreate = FormCreate
LCLVersion = '1.6.0.4'
object LogMemo: TMemo

I even went as far as setting the MinWidth and MinHeight to 100 each and then I rebuilt the application and again I could not reduce the starting width or height from the first value.

And talking about the Object Inspector:
I cannot reduce its size either! It stays as a pretty narrow value but still a bit too wide for my real estate. I can widen it but not reduce it. Same as with my test program.

> As I stated in my reply a short while ago I also have this behaviour. I don't. Just tested again. Somebody please bisect the guilty revision that caused the bug for you.

I don't know how I can get the revision number for Lazarus, but Help/About shows FPC 3.0.0 as svn rev 51666

I checked out the release tag for 1.6 when I installed Lazarus 1.6. That should be what you need to find the revision number.

NOTE: I reported this same issue on Feb 24 in a thread named: "Lazarus 1.6 Object Inspector width, how to reduce?"

At the time I had not yet discovered that the problem affected any program compiled in my Raspberry Pi2 environment. I thought it was a Lazarus IDE problem only.
But your post widens the scope a bit to ALL programs compiled using this particular combination of FPC, Lazarus and Operating system environment (possibly the OS widgetset as well).
My RPi2 runs Raspbian Jessie from Feb 9 2016.

Bo Berglund wrote

I checked out the release tag for 1.6 when I installed Lazarus 1.6. That should be what you need to find the revision number.

I didn't quite understand you but for bisecting you need trunk. Then use the binary search algorithm, O(log2(n)). Go back to an old revision that works. Split the rev range in half, checkout the middle rev, build and test. Then split the remaining area either backward or forward depending on the test result, and so on ...

The process is error prone, one wrong jump spoils it. Git has a bisect command which lets you do "git bisect good" or "git bisect bad" eliminating the range calculations and making the process easy.
You can use either the Lazarus Git mirror or the SVN repo directly using "git svn" link.

Juha

did you bisect for the guilty revision of your bug?

Yes! I'm updating mantis with the information immediately...

P?ter G?bor wrote

Yes! I'm updating mantis with the information immediately...

Most likely a GTK2 library version dependent issue.

Juha

Juha Manninen wrote

On Tue, Mar 1, 2016 at 11:44 AM, P?ter G?bor wrote: > Yes! I'm updating mantis with the information immediately... Most likely a GTK2 library version dependent issue.

I've fixed that issue (gtk3 also).

z.

Does this mean I should switch to Lazarus trunk (1.7.xxx) from release to be able to fix this in my 1.6 release.
Or is there a simple patch I can apply to the release revision?

I guess I can make a test by checking out trunk and make a "Trunk" Lazarus...

And this is what I did too...
I got Lazarus using this command:
svn co http://svn.freepascal.org/svn/lazarus/trunk trunk

Result after building bigide:
The same sizing issue as before. Not possible to make window smaller than the startup size. This includes the Lazarus IDE itself....

Lazarus Help/About shows SVN rev 51768 but I don't know if this is for FPC 3.0.0 or Lazarus trunk...
However Lazarus Release 1.6 shows SVN 51666 when I check it so I guess 51768 is the Lazarus revision.

Another observation (bug?):
I put a button on the empty form of the default project. Then I doubleclicked it hoping to get to the OnClick event handler in code editor (which normally will be created), but nothing at all happened.

I had to go to Object Inspector in order to create the OnClick event. Is this how it is supposed to work now?

Because it works as expected in release 1.6, one is brought to the event handler when doubleclicking in the form.

Bo Berglund wrote

Lazarus Help/About shows SVN rev 51768 but I don't know if this is for FPC 3.0.0 or Lazarus trunk... However Lazarus Release 1.6 shows SVN 51666 when I check it so I guess 51768 is the Lazarus revision.

Issue was opened about constraints. If there's another issue with gtk2 forms please open issue and attach example project.

Probably because of recent mouse clicks changes by Ondrej.

zeljko

Yep, fixed in r51790. I forgot that the design time needs special treatment. Thanks for reporting.

Ondrej

No, it was opened because forms could not be resized down from initial size (see subject of thread) and it was NOT caused by constraints being accidentally set (I have checked both in the IDE and in the form file itself, there is none). This suggestion was done some way down this thread, but was not the cause.

I added comment about revision in order to say what state my trunk version is in. I was asked to do that here...
It has nothing to do with why this particular revision was created. I just downloaded trunk today in order to check the solution to the resizing issue that was purported to be done.
Either that fix is not part of that revision or the fix does not work.

Maybe I've wrongly connected this thread and issue http://bugs.freepascal.org/view.php?id=29563 in my head. So if you have any issue about form sizing with gtk2 then please: point me to the right issue at the bug tracker, or open new one with example project.

zeljko

steveg has Lubuntu with LXDE. I guess Raspbian also has LXDE. This may be a LXDE related issue.
Please confirm.
Then you guys should find which revision broke it for LXDE or if it was always broken.

Juha

I don't know how to raise bugs, and I cannot pinpoint the reason for a particular bug either (internal code or operating system widgetsets etc).

However I do know how to make it happen:
1) Install Raspbian Jessie on a Raspberry Pi2 unit
2) Install FreePascal 3.0.0 on same
3) Check out Lazarus 1.6 release from svn and make bigide
4) Start Lazarus and set the fpc source path etc
5) Now the default project appears (empty form 240x360 pixels)
6) Add a button and put ShowMessage('Hello world*) into the clock event (not really needed but will show that the program works).
7) Start the program running
8) Try to grab the border and resize, will only make the form bigger and not smaller.

I have tried this on 1.6RC2, 1.6 release and trunk rev 52768 and they all work the same.
In fact one does not even need to compile the default project, the Lazarus IDE is likewise afflicted. Cannot reduce width of Object Inspector, Code editor or the main top window. Only possible to make them bigger.

I have not installed Lazarus from any downloadable binary, always compiled via make bigide.

I do not know what widgetset Raspbian Jessie uses but it has been suggested it is gtk2, others may know better. I am not a Linux master by a long stretch...

Updated my trunk Lazarus and checked the state.
Now the doubleclick on the button brings me as expected to a newly created OnClick event handler ready to be filled in. Thanks!

But the Form resizing issue persists. :(

Bo Berglund wrote

In fact one does not even need to compile the default project, the Lazarus IDE is likewise afflicted. Cannot reduce width of Object Inspector, Code editor or the main top window. Only possible to make them bigger.

I have now obtained a RPi3 unit and installed from scratch. FPC and Lazarus from svn release sources.
With this I have found that Lazarus IDE windows show this behaviour:

A) The main Lazarus top window with menus etc: Can be resized both ways on first start.
But once it has been resized to a smaller size and restarted it will no longer allow resizing height, which is about twice the needed height when it starts up the first time. It still shows the double height on startup but if I grab the bottom border to move it then it snaps to the normal height and can then only be resized sideways.

B) Object Inspector, Source Editor, Messages: Can only be enlarged, not reduced.

C) The Form view of the application main form: Can be fully resized

I do not know what widgetset Raspbian Jessie uses but it has been suggested it is gtk2, others may know better. I am not a Linux master by a long stretch...

I looked at Lazarus Tools/Configure "Bild Lazarus" I see that the LCL widget type is set to gtk2.
That is the same as in my Linux Mint 17.3 Mate installation.

"Bo Berglund" wrote

I looked at Lazarus Tools/Configure "Bild Lazarus" I see that the LCL widget type is set to gtk2. That is the same as in my Linux Mint 17.3 Mate installation.

Yes, the widgetset is obviously GTK2 unless you have explicitly configured it for QT.
Could you please confirm that the problems happen only with LXDE, as I asked earlier.
You have apparently tested with other desktops, too, for example Mate. Then could you please find the revision that broke things under LXDE. Raspberry may be too slow for bisecting, you must do it using a faster computer.
Explaining the same problems here repeatedly does not help. We believe the problems are real.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160305/3679e158/attachment.html>

I have no idea what you mean by this statement...
What is LXDE and how do I test Lazarus for LXDE?

You have apparently tested with other desktops, too, for example Mate.

That happened to be the case since I decided I should get me a more powerful computer so I installed the latest Mint - Mate in a virtual machine on my laptop.
In this environment the gtk2 is still selected but the form sizing issue is not apparent.

Then could you please find the revision that broke things under LXDE. Raspberry may be too slow for bisecting, you must do it using a faster computer.

Now you are talking mystery again. I do not understand how I could do this...

I have used svn cook-book style to retrieve a specific tagged revision of FPC and Lazarus and used make to build them. Apart fromn that I have no idea how to use svn, which I assume you mean I should do.

Il 06/03/2016 18:27, Bo Berglund ha scritto:
[...]

I have no idea what you mean by this statement... What is LXDE and how do I test Lazarus for LXDE?

[...]

Apart fromn that I have no idea how to use svn, which I assume you mean I should do.

A general hint: whenever you don't know what an acronym means (such al LXDE = Lightweight X11 Desktop Environment, which btw is most likely the desktop you're using), or how to take advantage of a popular control version program like svn, just type its name in a Google search, and you'll get all the information, tutorials and discussions you might wish, in order to understand what is it, get acquainted with it, use it and be aware of its features and bugs.

Just my 2 cents,

Giuliano

2016-03-06 19:47 GMT-03:00 Giuliano Colla :

According to a previous message he is using Mate

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160306/f8948c04/attachment.html>

Luiz Americo Pereira Camara wrote

According to a previous message he is using Mate

Not in his Raspbian in Raspberry Pi2. It most likely has LXDE although he has not confirmed it.

Juha

Bo Berglund wrote

I have no idea what you mean by this statement... What is LXDE and how do I test Lazarus for LXDE?

Bo, I have a strong feeling that you are playing dummy. Why do you do it? You must know the concept of desktop environments since you tested many distributions already. A simple google search would reveal that LXDE is a desktop environment.

In this environment the gtk2 is still selected but the form sizing issue is not apparent.

Yes, the widgetset is GTK2 unless you have explicitly configured it for QT, as I wrote in my previous mail.
Anyway, the problem is quite surely LXDE dependent.

I explained the bisect process in an earlier mail in this same thread. I will not repeat it here.
Bo, do you read the replies from other people? Sometimes you seem to ignore them completely.

Juha

Assuming that Bo's running Raspbian and going back to my notes, I think that the default desktop (window manager) is OpenBox with KXDE as an alternative. Frankly, I found both to have issues and prefer running pukka Debian with KDE, although it's unclear whether the RPi will ever be a fully-supported target.

When I last tried the combination, Lazarus and Debian "Jessie" were uneasy companions on all platforms. I strongly suggest trying Qt as an alternative target.

Seconded.

OK, I grant you that I formulated this rather poorly...

But nevertheless, I do not know how to test Lazarus on an RPi3 (or RPi2) with the Raspbian distribution using anything but what the distribution provides. So therefore I failed to get the connection between Lazarus and LXDE....

I have located the release document for Raspbian Jessie here: https://www.raspberrypi.org/blog/raspbian-jessie-is-here/ A little bit down they write the following:

<quote>the appearance of Raspbian is now based on version 3 of GTK+, the user interface toolkit used for the LXDE desktop environment. The older version 2 of GTK+ is slowly being replaced with version 3 </quote>

If this means that Raspbian is using LXDE is beyond me but it seems like it is using gtk3 by this wording.

When I try to find a gtk3 setting inside Lazarus I only do so in the dialog Tools/Configure_BuildLazarus, where it is contained in a dropdown box labelled "LCL widget type" and named "gtk3 (alpha)".

There seems to be no way to build an *application* with gtk3 without rebuilding the whole Lazarus environment first, is this the case?

PS:
I only started writing in this thread because I also fond the same behaviour as the original poster did and it seemed like that report was shunned as being bogus.
So I wanted to chip in with my observations to help *the developers* to nail down and fix the problem, but now I find I am being flamed for doing so so I will stop this.
I did not originate the thread.
DS

No I am not, I only want to report observations to help you to find and fix the bug. But it seems like I am being flamed for doing so so I will stop that now.
I did not start this thread, but wanted to chip in observations. No more...

Let's try to clarify the overall architecture one last time.

i) Underlying the entire system is the Linux kernel which provides at least partial support allowing other libraries and subsystems to access the screen and other peripherals. In general, the precise version of this isn't relevant.

ii) Assuming that you get a login dialog(ue) when you power up the system, that is being presented by the display manager running on top of an initial X11 session. the display manager also implements the XDMCP protocol which facilitates remote X11 sessions.

iii) Example display managers are xdm, gdm, kdm, LightDM and so on.

iv) When you present a valid userID and password, the display manager shuts down the original X11 session and starts up a new one using the identity of the validated user. Programs running in the context of this session are given a DISPLAY shell variable identifying it.

v) The new X11 session is immediately available for programs that know the DISPLAY value, but if run like that they won't have title bars and other window "furniture" (note that this is a significant architectural difference from Windows).

vi) Each X11 session has special provision for a window manager which is normally started automatically. It is this that displays the title bar etc.

vii) These days, it is common for the window manager to also implement (portions of) a desktop environment. Most of these have some sort of menu button or a list of installed programs, and frequently display special entities like a trash can on the desktop background.

iix) Example window managers are Gnome, KDE, OpenBox, LXDE and so on.

ix) Most programs aren't bothered about what window manager is running.

x) The window manager usually uses a widget set for convenience, rather than being coded directly on top of the X11 API. Example widget sets are gtk, gtk2, gtk3 and Qt.

xi) You can't easily change the widget set that the window manager (desktop environment) uses, although in most cases it's possible to add alternatives.

xii) As a result, you can easily find yourself in a situation where the window manager (AKA desktop environment) and programs supplied with it use one widget set, while programs that you've installed yourself use a different one: this is generally of little consequence.

I strongly suggest that you make sure the Qt widget set is installed on your Raspbian, and try using Lazarus to build a program for it. My experience is that there are "rough edges" in the interaction between Lazarus and (the widget set etc. supplied with) Debian and Raspbian "Jessie", I believe that at least some of these have been discussed as bugs.

I'll leave somebody else to comment on the current status of GTK3, which I think would be of general interest.

That's not true. You can build lazarus for qt or gtk2 and build gtk3 app without problem. Note that gtk3 is really alpha, most of winapi isn't implemented yet.

zeljko

Are you saying you still don't understand the difference between a widgetset and a Linux desktop environment, after building Lazarus under many Linux distros and after participating in many mailing list discussions? I am not sure if I will believe you.

No, the complaint was that you ignore replies from other people, then repeat the same issues and questions that were explained and answered already.
It is unpolite.

Juha

Mark Morgan Lloyd wrote

I'll leave somebody else to comment on the current status of GTK3, which I think would be of general interest.

It would need somebody to finish the implementation and to maintain it. Anybody?

The design made by Zeljko is easier to maintain than the current GTK2 binding is, but there is still a lot to do.

Juha

In the past, Bo's said that he's not seen all messages that were posted. However I also get the impression that I'm not the only person who's had to repeat himself.

Bo: just because you don't understand something that somebody's put in an answer doesn't give you an excuse to skip that bit of his reply. I admit that I used to do that sort of thing during my earliest days of learning maths ("what's this ! supposed to mean? Let's ignore it for the moment") and it didn't exactly make me popular with my teachers.