Re: [Lazarus] Children Forms (MDI)

[Kostas Michalopoulos via lazarus]

On 5/12/24 9:00 PM, zeljko via lazarus wrote:
Yes, but only qt,qt5 and qt6 have fully implemented MDI (on linux, 
windows and mac).


I implemented full MDI support on the Win32 backend some time ago. I 
haven't tested it recently, but it should still work (the only thing i 
remember not working fully was shortcuts from merged menus).


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus and Wayland display manager

[Kostas Michalopoulos via lazarus]

On 1/2/24 17:46, John Landmesser via lazarus wrote:

I had issues with the Lazarus IDE itself: instead of a form it showed a
fullscreen white window and at next lazarus boot asked me if to open
this broken project again or begin a new project.


Hm, perhaps it was some botched configuration? Out of curiosity i 
downloaded and tried "Nobara 39 Official" (latest version from their 
site, it uses KDE), installed FPC from the repository and Lazarus from 
git (trunk) and it worked fine (wonky theme aside):


https://i.imgur.com/S1gld6B.png

I did try it in a VM though (and everything was very sluggish), but this 
shouldn't affect anything related to Wayland. Also i didn't try the 
Gnome-based version, was the one you tried Gnome or KDE?


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus and Wayland display manager

[Kostas Michalopoulos via lazarus]

On 12/31/23 15:35, John Landmesser via lazarus wrote:

Just trying lazarus on new distribution nobara ( Fedora clone ) with
wayland, but it seems that the IDE sometimes get in trouble with this
display manager wayland. Changed back to x11 that is much better.


What are the issues you face? Sadly it seems the Gtk2 LCL widgetset does 
some weird stuff on its own and it sometimes has issues even with X11 
window managers.


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus and Wayland display manager

[Kostas Michalopoulos via lazarus]

On 1/1/24 09:47, Juha Manninen via lazarus wrote:
I don't think GTK2 should be used with Wayland. GTK2 was made before 
Wayland existed.


Gtk2 works fine with Wayland using XWayland (basically a rootless Xorg 
that uses Wayland to manage windows) which pretty much all desktop 
environments ship and support (and AFAIK there are no plans in the 
foreseeable future for XWayland to be dropped). In fact when i tried a 
Gtk2 program under KDE Wayland on a small laptop even scaling worked as 
expected (KDE allows X11 programs to handle scaling themselves instead 
of having the compositor scale the windows as a bitmap).


There is some functionality that is not supported because Wayland itself 
doesn't support it - e.g., IIRC you can't change the cursor's position 
and i think trying to grab a screenshot gives you a black image - but 
that'd affect toolkits that use Wayland directly too.



Do distros that use Wayland by default still include GTK2 applications?
The stable version of GIMP is still using Gtk2 and i think this is 
included by distros that use Wayland by default.


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Window Position

[Kostas Michalopoulos via lazarus]

On 9/22/23 15:26, Mattias Gaertner via lazarus wrote:
The gtk has such default position. It should be possible to support 
poDefault there.


From a quick look in the Gtk2 widgetset code, the position could be set 
(or actually, not set for poDefault and poDefaultPosOnly) via 
SetWindowSizeAndPosition *however* because this is called both during 
form creation and to make the form visible, somehow it needs to only be 
done the first time (after creation) since after that the program should 
be able to change the position programmatically and a call to Hide 
followed by a call to Show should place the window at the last position 
set programmatically instead of ignoring the bounds properties (which is 
what it should do for the first time based on the Position property's 
value).


I didn't make a thorough search but i couldn't find where the size is 
set as even commenting out all the code in SetWindowSizeAndPosition as 
well as setting some random values for the allocation during creation 
the form still seems to be set at the design-time size. LCL seems to try 
very hard to ensure the size and position are set :-P.


(actually in general it seems to try hard to override what the window 
manager does - sometimes i have an issue with Window Maker where Lazarus 
somehow brings all of its windows above other windows when alt-tabbing 
away to another program... i haven't figured out why that happens though 
as it hasn't crossed yet my "too much annoyance" threshold to 
investigate :-P)


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC

[Kostas Michalopoulos via lazarus]

On 3/17/23 15:19, Sven Barth via lazarus wrote:
Depending on the used units static linking is simply not an option. E.g. 
the database units load the database libraries dynamically and thus the 
C library must not be linked statically then.


glibc officially highly discourages static linking anyway.

As a sidenote, with gcc it is easy to cherry pick which libraries will 
be linked statically and which dynamically, but from what i can tell FPC 
doesn't seem to provide such an option - there is only an all or nothing 
approach as FPC generates its own linker scripts. It'd be useful if 
there was a way to explicitly specify (e.g. via command line options) 
which libraries are meant to be linked statically (and/or the opposite) 
regardless of $linklib usage (as libraries can come through unit you 
depend on indirectly - e.g. i might want to statically link SDL but not 
X11 or glibc).


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC

[Kostas Michalopoulos via lazarus]

On 3/17/23 01:36, Bo Berglund via lazarus wrote:

I do not know what the library libc.so.6 even does


It is the C library that one or more of units/libraries you are linking 
against require.


The issue is that you are making a binary on a newer version of glibc 
(the C library) than the system you want to run it - glibc (and most 
libraries really) is *backwards* compatible but not *forward* 
compatible: you can only run binaries on a system that uses the same or 
older versions of the library/libraries but not newer.


The solution is very simple: build the binary on the oldest version of 
libraries you want to support - with the easiest approach being to 
download an ISO of some older version of a distro that has the oldest 
versions you want to support. For example AppImage suggests using at 
most the oldest still supported version of Ubuntu (e.g. Bionic Beaver 
from 2018).


This is not unique to Lazarus or FPC, BTW, it is the same for any 
language and program that links against shared libraries on Linux.


Kostas

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 2.2.6

[Kostas Michalopoulos via lazarus]

On 3/16/23 19:46, Bo Berglund via lazarus wrote:

But it also seems like on each system there is only one version of fpc that can
be "active" (at least on Linux) because its config is stored outside of the pcp
dir in a user global fashion.
How can I make the fpc compiler versions co-exist and be recognized by the
respecive versions of Lazarus?


You can tell Lazarus which binary to use for FPC.

For the config file, you can use the same for all. The ~/.fpg.cfg is 
just a text file containing parameters to give to the compiler, same as 
the command like, but with some additional preprocessing. You can use 
something like


#IFDEF VER
parameters just for that FPC
#ENDIF

But note that the default configuration should work fine with most FPCs 
as long as they are installed in the same prefix since they use 
$fpcversion and $fpctarget macros instead of hardcoding things. For 
example personally i have both stable and git versions of FPC installed 
in ~/Apps/fpc for various targets and each uses its own set of units, etc.


If you have FPCs placed in different prefixes you might need the IFDEF 
for those though - or perhaps just add directories for both prefixes and 
as long as the $fpcversion macro is used for the units it'll work.


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Linux apps and gtk version choosing

[Kostas Michalopoulos via lazarus]

On 2/26/23 14:25, Mgr. Janusz Chmiel via lazarus wrote:

Where to change GTK version from 2.0 to 3.0?

IIs it possible from Lazarus IDE, Form window or only from source code 
of app?


Project -> Project Options -> Additions and Overrides (under Compiler 
Options near the bottom of the sidebar on the left) -> Click Set "LCL 
WidgetType" -> Pick one of the available options (not that not all 
options will work, but gtk2 and gtk3 should work and qt5 will work if 
you have libqt5pas installed).


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Using packages for often used units across projects?

[Kostas Michalopoulos via lazarus]

On 2/12/23 15:44, Bo Berglund via lazarus wrote:

It seems not so good to copy the files into each project. In Delphi they were
accessed from one location by several projects by using search path settings
(not available in Lazarus).


You can set per-project unit search paths. This is available from 
Project -> Project Options -> Compiler Options (in the tree at the left 
side) -> Paths (below Compiler Options -> the "Other unit files" entry 
(you can use the ... button to edit the paths individually).



So now I wonder if one can put several really non-related units in a common
package such that they will be available in every application from Lazarus?
I.e. package lazcommon containing 5+ different units defining various classes
and compiled by the package handler.


Yes you can also use packages for this. Simply make a new package, click 
the "Add" button, click "Add Files from File System" and select the 
files you want to add to the package. Save, compile and the package is done.


To use the package from a project, either a) open the package itself and 
click "Use" and then "Add to project" or b) open the project's inspector 
from Project -> Project Inspector, click "Add", click "New requirement" 
and find the package name in the dialog box.


You don't need to have any components or GUI in the package (though if 
you want it is possible to have components, GUI and forms in them).


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] More Gtk3 Status

[Kostas Michalopoulos via lazarus]

On 7/15/22 14:47, Anthony Walter via lazarus wrote:

Denis,

I will attempt the big design flaws [...]
Now here is the first big problem with the Gtk3 widgetset 
as implemented. Somehow someone decided it would be a neat idea to add a 
4th piece just for Gtk3. [...]


This isn't a flaw, the approach the Gtk3 backend has makes sense if you 
consider that it is trying to avoid all the special case functionality 
for what essentially mimicing the Win32 API in an increasingly (in every 
major version) weird and "non-Win32-like" API.


In a way the Gtk1 and Gtk2 widgetsets do it too but if anything they do 
it in a messier way because for anything non-trivial they allocate a 
separate TWidgetInfo object (a record) that they map between the 
Gtk1/Gtk base widget and the LCL functionality/data that needs to 
emulate the Win32 behavior all the time when that data is needed with 
the source code being littered with calls like 
"GetOrCreateWidgetInfo(handle)".


The Gtk3 widgetset instead of doing that uses the OOP functionality that 
Free Pascal had for decades now :-P to avoid doing that runtime mapping 
and put widget-specific functionality in its own class. Otherwise that 
functionality would need to be spread all over the place - especially 
for calls that assume that a call with HWND would apply to all widgets 
the same way.


Also about that "just for Gtk3", in fact it isn't just the Gtk3 backend 
that takes the OOP approach with a custom class per control - from a 
quick look, the Qt, Qt5, FPGUI, Carbon and MUI widgetsets take that 
approach too.


Just make the control handle an actual reference to 
the underlying system toolkit handle, and please DO NOT attempt to 
recreate another object hierarchy
While it can be a minor surprise, in practice you are already dealing 
with widgetset-specific functionality anyway and you should always keep 
the widgetset itself "in the loop" - meaning that even if you try to 
bypass it, you still need to know what the widgetset does. And again, if 
anything, the Gtk3 approach still seems better because control has its 
own class for the underlying widgets which makes it easier to find what 
is going on.


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Trayicon popup menu no longer showing images

[Kostas Michalopoulos via lazarus]

On 2/16/22 16:56, Michael Van Canneyt via lazarus wrote:

With this workaround it works. Thank you.


Perhaps you could try spinning up an Ubuntu VM and see if the bug 
persists there - in which case it'd be a Gtk2 backend bug, otherwise it 
is probably a bug with how Cinnamon implements app indicator.


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Trayicon popup menu no longer showing images

[Kostas Michalopoulos via lazarus]

On 2/16/22 15:22, Michael Van Canneyt via lazarus wrote:

I recompiled an older tray application. It used to show images in the tray
icon popup menu, but after compilation, the tray popup menu no longer 
shows the

images; just a small rounded square where an image should appear.

Linux mint, today's lazarus, GTK2 widgetset.


There was some change recently in the tray backend to use a "new" one by 
default:


https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/99e4bd2515fc118abebc58f7e7f3d7ac385e6d63

From a quick look at the code there seems to be a way to force the 
"traditional" backend by using LAZUSEAPPIND=NO environment variable, so 
try to launch your program as


  $ LAZUSEAPPIND=NO ./yourprogram

...and see if that fixes it. If so then it might be a bug in the app 
indicator backend or an issue with Cinnamon's app indicator 
implementation (i remember reading it had some issues some time ago).


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Kostas Michalopoulos via lazarus]

On 2/13/22 23:41, Maxim Ganetsky via lazarus wrote:
But I still can't understand, why you put so much an effort into an 
ancient and obsolete widgetset. 


I only spent 2-3 days, including getting Gtk 1.2 itself to compile and 
tracking down a gdk_pixbuf version that was compatible with Gtk 1.x, it 
wasn't that big of an effort. As to why, as i wrote in the comment in 
the merge request, i was curious about the Gtk 1.2 state, noticed that 
it didn't work and decided to fix it. I just simply like it when 
software doesn't drop support for old stuff just because they are old. I 
am into retrocomputing and various retrocomputing communities and i like 
being able to use modern software in retro environments (if anything i'd 
like to see what it'd take to bring back Win9x support to both FPC and 
Lazarus as in a game i made for a gamejam a couple of years ago i had to 
use several year old versions of FPC to make a Win9x version that would 
work with graphics cards on my older computers - like 3dfx Voodoo - and 
couldn't make the editor available for it because it wouldn't compile on 
the last Lazarus that supported Win9x - at least i was able to use the 
latest FPC for the DOS version, which is great).


Beyond that, as i wrote in the merge request, MUI is even more "ancient" 
and yet Lazarus added support for it recently. I do not see why it being 
called obsolete by its original developers means that one couldn't work 
on it if they want, it is open source after all, the entire point is 
having the freedom to do things like that.


Also i do not see why this is such an issue, the code is there and 
doesn't bother anyone - it isn't like i as a user who mostly works with 
win32 and gtk2 am bothered about the existence of 
gtk3/gtk4/cocoa/carbon/mui/fpgui/customdrawn/whatever. The worst that 
happens is that it takes a couple of MB of disk space in the source 
checkout.


> IMHO finishing fpGUI widgetset makes much more sense.

AFAIK fpGUI hasn't seen a release in years now and i think the 
development version has several incompatible changes, meaning that if 
anyone works on it now they may have a Gtk2->Gtk3->Gtk4 situation where 
they'll need to go and spend time getting the code base in a working 
state. TBH i am not a fan of APIs that break themselves - i'd rather 
make a Motif backend (it is technically still developed :-P and even 
theoretically an IEEE standard - or, well, it was at some point) as its 
API has a stability that goes back to the early 90s. While it'd be neat 
if there was support for it, it isn't something i personally find 
interesting.


Also why fpGUI specifically and not the custom drawn widgetset instead? 
It does seem have some issues but at least this one seems to be 100% on 
Lazarus instead of relying on an external project to remain working.


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Kostas Michalopoulos via lazarus]

On 2/13/22 21:33, Sven Barth via lazarus wrote:

Bart means the internal, private Lazarus developer list.


I see, but then why tell me? :-P

Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Kostas Michalopoulos via lazarus]

On 2/13/22 16:49, Bart via lazarus wrote:

On Sat, Feb 12, 2022 at 6:25 PM Kostas Michalopoulos via lazarus
 wrote:

This is currently being discussed on the devel ML.



Isn't this the development mailing list? Most of the discussion seems to 
be about Lazarus' development and can't find any other list mentioned in 
https://lists.lazarus-ide.org/


Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Gtk 1.2 fixes (again)

[Kostas Michalopoulos via lazarus]

Sending this mail again since it didn't arrive last time (can't even see 
it in the archives).


This is actually my third attempt, using my gmail account now (i tried 
my own email - not sure if it didn't pass through because the other one 
wasn't subscribed or due to some configuration issue... the mailing list 
page mentions that i only need to be subscribed to receive messages, not 
to send them too so i assumed it'd work - in the former case, i wonder 
how many of my replies were ignored since i switched to my own domain's 
account).


---

Hi all,

I submitted some fixes for the Gtk 1.2 LCL backend here that should 
bring it in working state (as it is right now it doesn't build due to 
some procs being moved to other units and even after adding those it 
barely works, windows get moved to 0,0, changing desktops or shading 
windows is broken, opening various dialogs crashes the program and other 
nice stuff :-P).


https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/69

With the patch applied the IDE seems to work fine for the most part. 
There are some glitches (e.g. the main window doesn't get the proper 
height at first try but shading/unshading it or changing desktop and 
coming back or even just changing active tab in the component palette - 
basically anything that causes it to recalculate the height after it has 
been visible for a bit - fixes it so it is more of an annoyance than a 
blocker) but it works. Similarly it seems to use the wrong mouse cursor 
in some cases.


I've also tried a bunch of examples as well as some of my own projects 
and anything that didn't need functionality that wouldn't exist in Gtk 
1.2 anyway seemed to work fine.


I might check those at some point but for now i wanted to fix the more 
broken things, like windows not being positioned correctly, the IDE 
getting minimized when switching desktops and crashing when trying to 
open some forms like the console output or the Lazarus build 
configuration. Especially that last one since i spend the whole day 
trying to track it down (and turned out to be a bug in Gtk 1.2 that is 
only triggered in specific creation order for notebook pages - which i 
had to work around).


There are a couple of hacks in there that might have been done better 
(but still beats the current state of not working at all :-P):


1. The Gtk 1.2 LCL backend treats the unmapping as if it was a minimize 
event but that isn't strictly correct since unmapping can also happen 
when a window is shaded or when the current desktop changes. In either 
case you do not want all application windows to be minimized (which is 
what normally happens for a minimize event). There was some code to 
check for the desktop change case but there is a race condition which 
triggers with modern fast desktops (i guess it was written a long time 
ago) where the unmap event happens before the window manager switches 
desktops. I added a check for the shaded state and... a hacky Sleep for 
100ms (happens only once even with multiple unmapped windows) to avoid 
the race condition :-P. Even at 10ms seemed to work but i put it at 
100ms which seem safe.


2. The ScrollWindowEx function was not implemented at all and some 
controls, like the tree widget seem to rely on it for visual updates 
when scrolling, which in practice means that nothing scrolls when you 
use the scrollbar or the mouse wheel over the control. With my patch it 
still doesn't work, but i made it invalidate the control that requested 
the scroll which causes it to fully draw itself (and adds the ironic 
twist where the control uses ScrollWindowEx to optimize draws but ends 
up doing more work instead :-P). The call still returns False (ie. it 
failed) so it shouldn't break anything as the invalidation could 
theoretically come from anything - ie. some overzealous window manager 
or something. In theory some control could rely on scrolling to display 
partial animations but that control would have been broken in Gtk 1.2 
anyway.


I have also tried the OpenGL control but it doesn't seem to build. I've 
spent very little time on it though but i'll try to fix it in a separate 
patch.


Note that the link above also contains a link to the Gtk 1.2 libraries 
(source code) that the LCL backend relies on that should compile with 
current Linux OSes (though there will be some warnings). Gtk and glib 
are from Slackware and with its patches applied with some minor mod and 
Gdk_pixbuf (which Slackware doesn't seem to carry - or at least not the 
version needed by the Gtk 1.2 backend since there is the Gtk 2.x verson) 
is from an old Red Hat source distribution (might not be the latest 
version but LCL doesn't seem to use it much - it might be possible to 
remove the current dependency so that things work in Slackware out of 
the box as it seems to be one of the very few distributions that still 
ship with Gtk 1.2) that i have fixed to build and install without (much) 
problem. So if you want to test 

Re: [Lazarus] FPC and WebAssembly

[Kostas Michalopoulos via lazarus]

Hello,


I'm glad to anncounce that FPC now covers working with webassembly in the
browser.


Sounds great. I did a quick compile for the wasi target and seemed to 
work fine with a simple helloworld-style test. So i decided to try and 
port a game i made last year[0] - initially made for an MS-DOS game jam, 
but added a bunch of ports later and wanted to make a web-based one too.


I decided to go with a similar approach to the one i used for Android, 
with the game compiled into a library (or a wasm file for here) and a 
"stub" that loads the library and passes events, etc to it.


However no matter what i try, it always seems to fail when (i guess) 
tries to link or assemble the first unit (the unit doesn't do anything, 
just defines an entity class).


By default it gets this error which happens after it compiles everything 
(SndEmit.o is the object file for the unit, it is just the first unit it 
tries to link/compile):


wasm-ld: error: ./Engine/SndEmit.o: invalid relocation function index
Error: Error while linking

If i pass -Awabt to use the wasa assembler (thinking that there might be 
something wrong with the object files), it then has the error:


SndEmit.pas(171) Fatal: Internal error 2019093001

(The unit is 171 lines long)

Also there are a bunch of "steam read error" errors, often after 
"assembling someunitname" (though not all "assembling someunitname" have 
such an error after them).


If i pass -Allvm-mc to use LLVM's assembler, i get a bunch of errors 
from a different unit (Misc):


Compiling ./Engine/Misc.pas
Assembling misc
./Engine/Misc.wat:5082:3: error: symbol 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing 
.functype
call 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT

^
./Engine/Misc.wat:5412:3: error: symbol 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing 
.functype
call 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT

^
./Engine/Misc.wat:5606:3: error: symbol 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing 
.functype
call 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT

^
./Engine/Misc.wat:6023:3: error: 3 superfluous return values
end_function
^
./Engine/Misc.wat:6272:3: error: 1 superfluous return values
end_function
^
./Engine/Misc.wat:6496:3: error: 1 superfluous return values
end_function
^
./Engine/Misc.wat:6681:3: error: 1 superfluous return values
end_function
^
Misc.pas(150) Error: Error while assembling exitcode 1

Note that i have LLVM 13 installed but also tried removing it and 
installing LLVM 11 and didn't make any difference. Also FWIW i'm calling 
the ppcrosswasm32 executable directly and have it installed in 
~/Apps/fpc, though it shouldn't make a difference (and the simple hello 
world code compiled anyway so the compiler setup should be fine).


Is there anything i am missing/not setting up correctly (e.g. i didn't 
tried with the "embedded" target - i tried to build FPC with it first 
but got some errors so i didn't explore further and went with "wasi" 
instead that seemed to work)? AFAIK i do not use any of the 
functionality that isn't implemented in the Roadmap page in the wiki.


Kostas

[0] https://bad-sector.itch.io/post-apocalyptic-petra
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus on Linux, which desktop environment?

[Kostas Michalopoulos via lazarus]

On 11/21/21 11:45, Juha Manninen via lazarus wrote:

LCL-QT5 works better than LCL-GTK2 now IMO.


What are the issues on Gtk2 that are fixed in Qt5?

Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 2 of 2.2.0

[Kostas Michalopoulos via lazarus]

On 11/3/2021 12:11 AM, Maxim Ganetsky via lazarus wrote:

Please create a bug report.


Sure, here it is:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39454

Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 2 of 2.2.0

[Kostas Michalopoulos via lazarus]

On 11/2/2021 2:54 PM, Mattias Gaertner via lazarus wrote:

The Lazarus team is glad to announce the second release candidate of
Lazarus 2.2.


Neat. I did a bit of testing with some of my projects and everything 
that worked in the last stable version i had (2.0.6) seems to work fine 
with 2.2.0RC2.


I also did some testing with the MDI functionality that was implemented 
in Win32 last year, which BTW...



Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2


...isn't mentioned in the Lazarus changelog (the first non-trunk version 
to have it was 2.2.0RC1, at least from a quick look in the source code 
of 2.2.0RC1 and 2.0.12).


The MDI stuff seem to work mostly fine, however there is an issue i 
noticed with paint and form resize events. I used this doodle app 
(perhaps i can modify it and have it part of Lazarus tests or something 
to test MDI support in other widgetsets?):


http://runtimeterror.com/pages/badsector/nyan/gimme/mdidoodlesrc.zip

This builds with Delphi 2 (which is the only Delphi i have access to and 
what i used as the behavioral basis for my Win32 MDI patch) and Lazarus 
(make sure to clean everything between builds).


The difference is between Delphi 2, an older SVN-based build of Lazarus 
i have (Lazarus 2.1.0 r64351M FPC 3.3.1 x86_64-win64-win32/win64) and 
2.2.0RC2:


In Delphi 2 the program receives only a single resize event in the MDI 
child form for the final form size (notice how the both the main form 
and the MDI child form use the default size which lets windows place it 
as it wants) followed by a paint event. The app uses a bitmap to store 
the doodle which is setup during resize events and is drawn on the form 
itself during paint events.


In r63451M the program receives two resize events, one for some initial 
(stored during design time, i think) size followed by the larger (due to 
my large monitor) form size that is shown when it is in MDI - both are 
fine as long as the final size event is correct, IMO, so no problem 
here. Then a paint event follows.


In 2.2.0RC2 however the paint event comes between the initial and second 
resize events which means that the background bitmap is not set up properly.


Now of course it'd be trivial to work around the change by adding an 
Invalidate call to the resize event, but IMO this is a regression. There 
should either be a second paint event or the paint event should be 
delayed until sizing is settled. This would be both consistent with how 
size and paint events seemed to work in previous version of Lazarus as 
well as Delphi and also consistent with how Windows (from where most of 
the VCL and LCL behavior comes from) behaves with WM_SIZE and WM_PAINT 
(WM_SIZE always comes before WM_PAINT and WM_PAINT is always sent if a 
window is enlarged to paint the new area).


Beyond the above i couldn't find any other issues with 2.2.0RC2.

Kostas
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] The Problem with the Linux Desktop

[Kostas Michalopoulos via lazarus]

IMO the problem of Linux desktop (or at least "a" problem) is the lack of
backwards compatibility for pretty much anything above the X server (and
now with Wayland some people want to compromise that too). If you stick
with the X libraries, the C library (glibc is generally very good when it
comes to backwards compatibility and one of the very few userland projects
that do so) and kernel interfaces, you can have many years of stability. As
an example check this screenshot:

https://i.imgur.com/YxGNB7h.png

This shows binaries from a GUI toolkit i wrote some time ago in C that only
uses the Xlib (it can also optionally use Xft but it isn't required). The
binaries were compiled in a (32bit, of course) RedHat Linux distribution
from 1997 and worked just fine in a 64bit Debian distribution from 2018
showing more than two decades of binary backwards compatibility. Note that
those binaries were *not* statically linked (which is what some suggest as
a "solution") - they linked against the system provided C and X libraries.

But that is by only relying on X and C. Anything above that has the long
term stability prospect of a sandcastle during a thunderstorm.

You can see that clearly with Lazarus' backends: the Gtk2 backend became
stable long after the Gtk1 library was obsolete and the Gtk3 backend is
still not capable to use the IDE itself when most Gtk development is
already on Gtk4. Back in late 2000s, the Gtk1 backend used to be very
stable and the Win32 backend used to be quite buggy but nowadays the Win32
backend is by far the most stable because over the years there wasn't any
need to throw away all the work that was done since the Windows API is
always backwards compatible whereas the Gtk library drops compatibility
every major version.

The only big toolkit i can think of that remained stable over the years is
Motif, but i think this is largely due to it not receiving any major
updates. Well, Tk is probably also ABI stable, but i'm not sure if it is
possible to use it without Tcl (Python bundles both just to access Tk).

It might be interesting to see if a backend for any of those can be made
since they are likely to exist and be updated for the foreseeable future.

On Sun, Mar 29, 2020 at 11:41 AM Anthony Walter via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Teresa, thank you for your considered opinion.
>
> I agree with most of what you said, but with regards to the option of
> moving back to Windows, for me that is a non starter. I don't use Linux
> rather than Window because of some technical benefit. The primary reason I
> use Linux because I don't want to worry around my privacy being
> compromised, either from malware or viruses which are a big problem with
> Windows or from software vendors themselves be it Microsoft telemetry or
> other spying features that now a days so commonly bundled with 1st, 2nd,
> and 3rd part software on Windows. These problems are pretty much non
> existent on Linux.
>
> I also value the efficiency of Linux. I have all processing speed and file
> system the room I need on a 2008 Core2Duo, 4GB or RAM, and a 60GB SSD using
> Linux, even with the newest distros. On the latest Windows 10, not so much.
> Just getting the OS installed is about 30GB. And yes this is a big deal for
> me because I always have 10 or more of these laptops on hand and use them
> to teach my students basic computers usage, online safety, and programming.
> Even if I wasn't using these machine for teaching, they still make for
> great everyday computers when running Linux. Using them with the most
> recent Windows, not so much.
>
> My complaints, as you expanded upon, center mostly around the fractured
> nature of the Linux desktop ecosystem. Even popular distros such as Ubuntu
> break things from release to release. Windows seems to always try to
> protect that backward compatibility, at least since they made the move to a
> true 32 bit OS. Of course with Windows upgrades some hardware is no longer
> supported (I can't use the Canon photo capture system on other than XP),
> but most of the time everything still works.
>
> Thanks again for your considerate thoughts.
> Anthony
>
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] MDI support for win32

[Kostas Michalopoulos via lazarus]

Hey,

Sorry for the delay, i just noticed this was merged :-P. I got the latest
version, compiled the MDI doodle test and did some testing and it seems
like it behaves like in Delphi 2, so it looks like it works fine :-).

I get an "oops, debugger error" dialog box when exiting but i'm not sure if
it is related (i get this in regular examples too).

Kostas

On Fri, Feb 28, 2020 at 9:34 PM Ondrej Pokorny via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Hello,
>
> I added MDI support for win32 based on patch by Kostas Michalopoulos:
> https://bugs.freepascal.org/view.php?id=36582
>
> Please report any regressions or problems.
>
> Ondrej
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] MDI implementation for Win32

[Kostas Michalopoulos via lazarus]

Hi all,

Recently i wanted to use MDI in some of my Windows tools and since Lazarus
seems to not support it with the Win32 widgetset, i decided to try and make
an attempt at implementing it.

You can find a patch at https://bugs.freepascal.org/view.php?id=36582

I have only implemented whatever i could find in Delphi 2 (the only Delphi
i have available). I wrote a small demo "MDI doodle" application that uses
all of the available APIs and tries to trigger various behaviors (e.g.
showing/hiding a toolbar/status bar to update the client area, creating MDI
children forms while existing ones are maximized, vetoing modifications via
MDI childrens' CloseQuery, merging menus using GroupIndex, etc). The demo
can be compiled in both Delphi 2 and Lazarus to compare the behavior of the
two and is attached in the bug report above too.

You can also see it in action here: https://i.imgur.com/GznF35A.png (at the
left side is the Delphi 2 version, at the right side is the Lazarus
version).

The patch is written against SVN trunk at revision 62555. There might be
some unnecessary tests in the code, but since i am not very familiar with
it i decided to be a more cautious. Also since there is already an MDI
implementation (AFAIK, didn't try it) for Qt, i decided to stick as much as
i can on the widgetset side (the two main changes i made on the LCL side
was to add an ArrangeIcons method in TCustomForm to mimic the Delphi one
and add Merge/Unmerge methods in TMainMenu, again to mimic the Delphi
methods and hopefully the functionality too :-P).

Feel free to remove any tests you think aren't necessary and make any other
changes you think are worth it.

Kostas Michalopoulos
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Cross-platform project. Font sizes not the same....

[Kostas Michalopoulos via lazarus]

I *highly* recommend to avoid changing font sizes, users select themes
because they want applications to use them, so it is better to stick
with their choices and use autosizing (the default setting for most
controls), the align property and the anchor editor.

Here is an old (but still valid) video i made ~6 years ago where i
quickly show the anchor editor in practice:
https://www.youtube.com/watch?v=neigk9Pt21o

Using the anchor editor you can create UIs that dynamically adjust
position and size based on the user settings and allow the user to
resize windows.

Generally speaking try to design UIs that use as little fixed
positioning as possible. Fixed positioning (that is, dragging and
dropping a control on the form and manually adjusting its position and
size there with the mouse) is fine for simple applications that will
only work on Windows or macOS that traditionally has kept font sizes
the same over the years (though even then on Windows you can use
different fonts and some people do), but on Linux you simply cannot
rely on anything to be constant and fixed positioning can only be used
as a starting point for your layout (ie. place the controls manually
in a fixed position+size and then open the anchor editor and start
stitching them together one by one - this is basically what i do in
the video above).

Kostas

On Thu, Aug 22, 2019 at 10:50 AM Bo Berglund via lazarus
 wrote:
>
> On Tue, 20 Aug 2019 23:47:39 +0200, Bo Berglund via lazarus
>  wrote:
>
> >I can go into the font property of affected controls and change the
> >font size to make it look better, but there are so many...
>
> In fact there are not that many controls so I tried to do the
> following on Windows:
>
> procedure TfrmMain.SetFontSize(S: integer);
> begin
>   // Set font size on load.
>   btnDec60.Font.Size := S;
>   btnDec30.Font.Size := S;
>   btnDec10.Font.Size := S;
>   btnDec1.Font.Size := S;
>   btnInc1.Font.Size := S;
>   btnInc10.Font.Size := S;
>   btnInc30.Font.Size := S;
>   btnInc60.Font.Size := S;
>   btnCutStart.Font.Size := S;
>   btnCutEnd.Font.Size := S;
>   btnAddCut.Font.Size := S;
>   btnJump.Font.Size := S;
>   btnShiftAudio.Font.Size := S;
>   speDelay.Font.Size := S;
>   stxCutStart.Font.Size := S;
>   stxCutEnd.Font.Size := S;
>   stxCutTime.Font.Size := S;
>   stxClipCnt.Font.Size := S;
>   gbxCut.Font.Size := S;
>   ckbLogin.Font.Size := S;
> end;
>
> procedure TfrmMain.FormShow(Sender: TObject);
> begin
>   SetFontSize(9);
> end;
>
> This  works just fine on Windows so I went to my RPi4 and opened the
> project there and added these two procedures also to that instance of
> the project, thinking it would at laset fix the font size temporarily.
> But when I run this I get an exception!
>
> -
> Debugger Exception Notification
> Project VideoPlayer raised exception class 'EReadError' with message:
> Invalid value for property
> At address C4920
>
> [] Ignore this exception type [Break] [Continue]
> -
>
> If I check the Ignore checkbox and contine I get another error:
>
> -
> Error reading frmMain.OnShow: Invalid value for property
> Press OK to ignore and risk data corruption
> Press Abort to kill the program
>[Abort]  [OK]
> -
>
> Strangely it did not manage to handle the integer value for font size
> so I redefined the SetFontSize procedure to be declared as follows:
>
> procedure TfrmMain.SetFontSize(S: shortint);
>
> With this in place the form in Linux became the same as on Windows
> size-wise regarding texts.
>
> Maybe a difference between the operating systems, I think Raspbian is
> still a 32 bit system whereas Lazarus on Window 7 x64 is a 64 bit
> program on a 64 bit OS.
>
> --
> Bo Berglund
> Developer in Sweden
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] It is a beautiful day...

[Kostas Michalopoulos via lazarus]

Sounds interesting. Can i have a package that installs
components/controls only available to the project group instead of
globally? I often want to have components (and sometimes controls)
available on the component palette but not for every project, but so
far i see packages need to be installed "lazarus-wide" to expose
components to the component palette.

On Thu, Jul 11, 2019 at 5:46 PM Michael Van Canneyt via lazarus
 wrote:
>
>
> Hello,
>
> For those of you that don't follow the SVN logs closely:
>
> The IDE now has proper support for Project groups.
> Project groups already existed for some time, but were crippled.
>
> With 2 additions they are now actually very useful:
>
> - You can let Ctrl-F9 compile the current target in a project group, and that
>includes for instance a package !
>(you can set this in Tools - Options - Project groups)
>
> - "Find in files" now has the option 'Search in project group'
>
> They now offer all functionality as in Delphi. In difference with the latter,
> their use is entirely optional...
>
> My heartfelt thanks to Mattias for completing the 'Project group' 
> functionality !
>
> Michael.
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] IDE Ctrl+W key

[Kostas Michalopoulos via lazarus]

Thanks, those two options seem to be exactly what i had in mind :-)

On Mon, Mar 25, 2019 at 12:30 PM Ondrej Pokorny  wrote:
>
> There is no need to discuss this. As I said before both your points are
> customizable.
>
> On 25.03.2019 11:40, Kostas Michalopoulos via lazarus wrote:
> > I always saw the cursor jumping due to a syntax error as a bug, not a
> > feature and has always been an annoyance that breaks my code flow.
> > Honestly, i do not see what the point is, i am trying to complete the
> > word, not find syntax errors (this is what Ctrl+F9 is for).
>
> IDE options -> Codetools -> Identifier Completion -> Miscellaneous ->
> Jump to error
>
>
> > I also
> > think Ctrl+Space should display word completion in addition to
> > parsed-based words - it could put an icon with a pair of question
> > marks or whatever in front of the "guessed" words to indicate where
> > they come from.
>
> IDE Options -> Codetools -> Identifier Completion -> Include words
>
>
> > Going back through the jump history is just a bandaid to a problem
> > that shouldn't exist in the first place.
>
> Does the problem persist if you change the options from above?
>
> Ondrej
>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] IDE Ctrl+W key

[Kostas Michalopoulos via lazarus]

I always saw the cursor jumping due to a syntax error as a bug, not a
feature and has always been an annoyance that breaks my code flow.
Honestly, i do not see what the point is, i am trying to complete the
word, not find syntax errors (this is what Ctrl+F9 is for). I also
think Ctrl+Space should display word completion in addition to
parsed-based words - it could put an icon with a pair of question
marks or whatever in front of the "guessed" words to indicate where
they come from.

Going back through the jump history is just a bandaid to a problem
that shouldn't exist in the first place.

On Tue, Mar 19, 2019 at 5:00 AM Martin Frb via lazarus
 wrote:
>
> On 19/03/2019 04:39, Dmitry Boyarintsev via lazarus wrote:
>
> On Mon, Mar 18, 2019 at 10:58 PM Martin Frb via lazarus 
>  wrote:
>>
>> History back should work after an codetools error. IIRC Ctrl-H, but I move 
>> it to Alt-Cursor-Left.
>
>
> The first time I hear about that thing. What's "History point"?  how is it 
> defined?
>
> View menu: jump history
>
> Everytime you jump to a declaration, method body, ... (and some others like 
> go to begin/end of file) a point is inserted. (except, if it is just 1 or 2 
> lines from where you were).
>
> You can navigate back and forward on those points.
> - mouse buttons 4 and 5 (like in webbrowesrs)
> - ctrl-h (IIRC.., I recommand mapping it to alt cursor left/right)
> - editor toolbar can provide buttons too
>
>
> The usual way is, that you look up the definition of some identifier (I 
> mapped "jump to declaration" to alt cursor up), maybe follow it forward, 
> follow another declaration inside it, and then jump back as far as you 
> need.
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Universal FontDialog for LCL

[Kostas Michalopoulos via lazarus]

On Fri, Mar 8, 2019 at 12:55 PM Juha Manninen via lazarus
 wrote:
> Everybody wants to include their custom components in LCL. Why?

Most likely because it is much easier to have a single "batteries
included" installer that provides everything you need out of the box
now and much more likely to be there and working in the future (since
it is part of the codebase that the Lazarus devs are compiling against
after every modification), than chase after packages provided by
others who may or may not keep them available and up to date (keeping
your own copies can solve the "available" part, but then you take
unofficial ownership of the package for the "up to date" part).

FWIW i tend to avoid anything that isn't part of Lazarus itself
personally. The only time i used an external package was with
multithreadprocs and i was very happy when i saw it become part of
Lazarus itself.

Besides, Lazarus already comes out of the box with a ton of packages,
it isn't weird to expect that you can add more to it.

Which makes me wonder, what is the goal with the bundled packages? Are
they going to transition to OPM with Lazarus only providing the "bare
bones", are they going to stay frozen in time or are they going to be
expanded and if so, what would be the criteria for expansion?

FWIW i think Python's approach sounds good here: the installers come
"batteries included" with stable APIs that you can generally rely on
being there in the future with no (or very minimal) changes (ignoring
the Python2-to-Python3 fiasco at the moment), but you can still get
more stuff through PIP and over time useful packages "migrate" from
PIP to the official distribution (as long as there aren't
functionality duplicates, but that is mainly because of Python's
"there should be only one way to do something" and Lazarus already has
several duplicates already).
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] alternative to web programming?

[Kostas Michalopoulos via lazarus]

The idea is interesting, but the implementation not so. All demos are
unusably slow and unless this spawns a VM for each instance, i
wouldn't trust any sort of "FS virtualization" they have to not be
broken - Win32 desktop APIs were not designed for applications to be
isolated from each other. This could make it only usable for
intranets, but even then the performance is so abysmal as to severely
impact any sort of productivity. And honestly, would you want to be
the poor clerk who'd have this sort of crappy responsiveness imposed
on them 8h/day?

There might be some very few uses for this, but i'm certain that there
are also better solutions for those few uses too (and some would be
solved with something like noVNC).

On Thu, Feb 14, 2019 at 9:56 AM Michael Schnell via lazarus
 wrote:
>
> There are application that require a „stylish“ GUI for optimum user 
> satisfaction, …. And there are applications that do their thing more or less 
> on their own, requiring human attention only for configuration and service.
>
>
>
> -Michael
>
>
>
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Order of OnCreate and OnActivate in Qt4

[Kostas Michalopoulos via lazarus]

I wouldn't rely on event order as anything between the creation to
Application.Run could call Application.ProcessMessages - including some
components/controls you may be using. As a rule of thumb you should assume
that after calling a control (or form) that it can start receiving events.

In Qt4 styling is done through native code (QStyle subclasses) and it can
alter widgets (QStyle::polish) so it isn't unthinkable that a theme could
do something that generates events.


On Sun, Nov 25, 2018 at 6:47 PM zeljko via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 11/25/2018 04:43 PM, Vojtěch Čihák via lazarus wrote:
>
> > CRASH, because code in OnActivate assumes that FrmContext already exists.
> >
> > So, Qt4+Plastique has different order of events than Qt4+QtCurve.
> >
> > Unfortunately, I cannot reproduce with simple demo.
> >
> > What I'm doing wrong? Do I rely on something that is not guaranteed?
>
> Try to disable usage of QtNativeEventFilter in qtdefines.inc if it's
> enabled.
>
> zeljko
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Building help files: the nitty-gritty

[Kostas Michalopoulos via Lazarus]

FWIW your post made me realize i have a few uncommitted changes (including
a very important one - outlines
https://coinsh.red/p/2018-08-30_20_27_48-Help_-_Welcome.png) for LazHelp
:-P. I'm not working on it much though, it is mainly on life support with
the rare addition of new stuff (mainly needed because i made it a target
for a document preparation system i work on and needed some features from
it).

On Sat, Aug 18, 2018 at 7:11 PM Marco van de Voort via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Sat, Aug 18, 2018 at 06:31:15PM +0200, Marco van de Voort via Lazarus
> wrote:
>
>
> > On Tue, Jul 10, 2012 at 05:39:05PM +0100, Graeme Geldenhuys wrote:
>^^^
>
> Well, that happens, when you try to be modern, and read your mail with mutt
> instead of elm :-)
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Test this please

[Kostas Michalopoulos via Lazarus]

Is this written in Lazarus/FreePascal? If it is a single-bin program (CGI?)
i can drop somewhere in my VPS it would be awesome because i was trying to
make something like that a while ago (but got bored :-P).

It seems to work fine, but my only request is to allow for "untyped" URLs,
ie instead of /texts/, /images/, etc use /files/ or something generic so i
can - for example - upload an HTML file that refers to other files. For
example i uploaded foo.html that tries to refer to foo.png (which i also
uploaded) but it doesn't work:

https://storage.codebot.org/tester/texts/foo.html

This could be an option. Also for bonus credits, add an option to upload a
zip file and have it being decompressed in a (sub)directory.



On Sat, Mar 31, 2018 at 3:17 PM, Anthony Walter via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> > pdf is not associated.
>
> I am not sure if pdf is previewable in a browser except maybe through a
> frame?
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Package filenames with _package

[Kostas Michalopoulos via Lazarus]

On Mon, Jan 8, 2018 at 11:38 PM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Then it seems Windows Explorer is right up your alley. :) They hide the
file extension by default. Users (like me) have to explicitly go into the
settings and enable "show file extensions" option.

I do the same as i dislike having the extensions hidden. I want them to be
short, not hidden. Also you see file lists in more places than a file
manager - a common one being version control programs.

> Even better, Linux and FreeBSD don't even need file extensions. File
Extensions are simply for [some] human benefit (unlike Windows that
requires them). Linux and FreeBSD OS's query the first 4-8 bytes of a file
to accurately determine the file type and use the appropriate application
to open them.

Not really. Linux, FreeBSD or any other Unix OS have no idea about file
types beyond executable files (and that is set via the executable bit).
Application association is something desktop environments concern
themselves with. KDE and GNOME back in the 90s decided to use MIME types
together with an association database based on globs and eventually they
decided to create a common database through the freedesktop.org project.
Today most (but not all) desktop environments tend to simply use this
shared database which does the association from file to MIME type using
several approaches, including globs and magic byte sniffing, depending on
each type. In fact the recommended approach is to first match by glob and
if that fails or produces conflicting results (e.g. two types claim a
single file) only then to try to check the file's contents.

You can read the full spec here:
https://specifications.freedesktop.org/shared-mime-info-spec/0.18/ar01s02.html#idm139750558222816

Although note that this is just a convention and not a standard
(freedesktop is not a standards body, it just happens to be popular enough
due to being made by KDE and GNOME during their most popular days) - other
desktop environments or programs do their own thing and more often than not
this thing is based on pattern matching filenames for their extensions. It
makes sense after all since opening a file to read its contents would be
much slower - especially when done through network filesystems - than
simply checking the filename, which is why the content checking part is
used as a fallback instead of the primary way to determine the file
contents (some file managers even ignore the magic part if they are
browsing a network FS). And magic data do not really help with multipurpose
file formats like containers - how are you going to tell the difference
between a Java JAR, Java WAR and a LibreOffice ODT file when all are ZIP
files? - or text files like JSON, Plist, INI and several others that are
used for special purpose storage. Hell, you don't even need to look much
further than Lazarus here: packages, projects and session files (and
perhaps other stuff) are simple XML files and all of them even have the
same root node and no namespace configuration, so you cannot really
separate them from each other from anything else than the extension.

This "extension isn't a unix thing" wasn't even true in the days of the
original Unix - extensions were used all over the place there too as they
often were useful for shell scripts. The only system (that i know of) that
really didn't need extensions was the classic MacOS which simply stored the
file type as metadata and used that to decide what to do with the file.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Package filenames with _package

[Kostas Michalopoulos via Lazarus]

On Sun, Jan 7, 2018 at 1:06 PM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> so why is everybody still limiting file extensions to 3 letters?? Some of
my fpGUI included applications use file extensions like *.project etc.
Hell, even Microsoft is catching up with that idea (although minor) and now
use 4 letter extensions like *.docx etc.

One reason is simply habit, but also because these extensions are visible
to the user more often than not and having long extensions in filename
lists (like, e.g, when using version control) become redundant noise and in
some cases it takes space (like in file managers). Up to 4 letters is fine
for me, 5 is stretching it and anything above that is only something i'd
use for file types that i wont see often in a list and even then only if i
can't avoid it (but really even just 4 characters gives you a lot of
variation).
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Embedding an X11 server as a component

[Kostas Michalopoulos via Lazarus]

On Tue, Dec 26, 2017 at 10:28 PM, Mark Morgan Lloyd via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
>
> Is it possible to embed the main window of another program into a pane in
something written using Lazarus, letting the Lazarus program provide the
"furniture" functionality that's usually handled by the window manager?
>
> The scenario I'm thinking about is putting multiple instances of
something non-trivial like Wireshark into an overall "wrapper".

Yes, and funny enough i was doing just that in a reddit argument i had
today (yes i spend my Christmas arguing with strangers on internet forums
:-P).

https://i.imgur.com/YvGyUVd.png

https://i.imgur.com/Rwp86U4.png

This is something X support natively, however you need to keep some things
in mind:

1. Your "container" need to have a proper X window. Some toolkits (like
recent versions of Gtk2) will "merge" child windows unless they are
necessary (very recent versions of Gtk2 will even use client side windows
and ignore X subwindows). Other toolkits ignore X subwindows altogether.
You need to somehow (ie. read the toolkit docs) ensure you have a native
window.

2. You need to ensure the embedded window gets the input focus when
necessary. Many toolkits implement and expect the XEmbed protocol (and you
need to implement the embedder/host side of this) to handle focus, tab
traversal, etc. Some older stuff might not need that though (XEmbed was
needed because many toolkits ignore how X handles input focus and
reimplement it themselves).

3. It should go without saying, but i'm gonna say it anyway: not everything
expects or is happy being embedded. Specifically applications using
client-side decorations expect to be in control and they can have
surprising behavior when you embed them. For example i could move gedit
around in the second shot using its "title bar" since that is implemented
by gedit itself instead of relying on the window manager to do it.

4. On the other hand some applications have an explicit mode for being
embedded into others, so look into that for the application you want to
embed (and perhaps ask the developers for help).

Kostas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 1.8

[Kostas Michalopoulos via Lazarus]

On Fri, Dec 15, 2017 at 1:41 PM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
>
> At compile time it is CP_NONE, at runtime it can be any codepage.
>

My understanding (which, if it is wrong, sorry but not my fault since the
docs are a bit vague and all the names involved are totally unintuitive
:-P) is that RawByteString has basically no codebase so it is treated as a
byte string pretty much the same way AnsiString was treated pre-FPC3. So
i'd expect the codebase to always be CP_NONE and to change it, i'd have to
assign the RawByteString to some string type with an associated codepage
(basically, making the RBS an "escape hatch" to the whole conversion
machinery).
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 1.8

[Kostas Michalopoulos via Lazarus]

On Sun, Dec 10, 2017 at 4:17 PM, Luca Olivetti via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> https://www.freepascal.org/docs-html/rtl/system/rawbytestring.html
>
> it's an ansistring.

This is IMO misleading since nowadays AnsiString has codepage information
and a plain AnsiString as shown in the page you linked can be any codepage
whereas RawByteString is always CP_NONE. RawByteString and AnsiString are
not equivalent.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 1.8

[Kostas Michalopoulos via Lazarus]

> I think I had this discussion before: I'm not going to use TBytes until
it offers the same convenience as an ansistring (i.e. easy concatenation,
insertion and deletion, not to mention search and replace, etc.).

Isn't RawByteString a more suited replacement then? In the few places i
relied on the bytes in a string when i was converting my code from FPC 2.x
to FPC 3.x i used a RawByteString and things seem to work fine.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] External/out-of-tree LCL widgetset

[Kostas Michalopoulos via Lazarus]

In my personal experience the "RAD" approach used by Delphi, Lazarus and
old VB (i'm not sure if proper RAD really was about what you see in those
products and not something Borland and Microsoft's marketing departments
decided to use because it was cool at the time) is the fastest and often
best way to create desktop applications. Yes, it can end up messy for
larger applications if you are not careful and i've written my share of
things i'd rather rewrite than fix (although they are fixable with the
right amount of effort), but i still consider it worth it and i see any
other approach as going backwards.

To put it simply, the only reason i use Lazarus and the only reason i
recommend it to others (mainly programmers who want to make desktop
applications) is its "RAD" features (and cross platform support, of
course). Creating a form, dropping a field and a button and double clicking
on the button to type something like "ShowMessage(Edit1.Text);" and press
Run to run it has been for many years my first test for separating Bad vs
Good desktop GUI development environments - and the one most fail at.
Simple things must be simple, complex things must be possible and Lazarus
allows for both.


On Fri, Dec 1, 2017 at 9:43 PM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 2017-12-01 13:33, Marcos Douglas B. Santos via Lazarus wrote:
>
>> I believe RAD is the best way to code a GUI
>>
>
> I'll even disagree with that - somewhat. :)
>
>http://geldenhuys.co.uk/articles/model-gui-mediator.pdf
>
> With Model-GUI-Mediator (think MVC or MVP design patterns but for modern
> GUI toolkits) you use RAD style to drop components on a form, but you DON'T
> hook into any events or Dataset properties using the form designer. Also,
> you DON'T use data-aware controls.
>
> Instead you use Mediators - a very thin layer of non-gui code (reusable
> and only implemented once) that links widgets and business objects.
> Bi-directional updates occur automatically via the Objserver design
> pattern. MGM was the reason FPC now has Observers built into classes like
> TStringList etc.
>
> The MGM implementation I described in the article is very basic - to get
> the idea across much easier. The MGM implementation inside tiOPF is *much*
> more advanced and improved - requiring *much* less boiler-plate coding too.
>
> MGM also allows you to switch your application from LCL to fpGUI to VCL in
> a blink of an eye. The mediators for all these toolkits are already written
> - so nothing new to implement. Switching a form design from using a
> TListView to TStringGrid (or vice-versa) is also a 2 second job.
>
> Creating mediators for new componentsFor example TChart ora DevExpress
> QuantumGrid is a 5 minute job at most. So suddenly you can use any of the
> free or paid for components - not just db-aware components.
>
> I've used MGM in multiple commercial projects for about 6 years now - it
> works brilliantly. You UI form units are almost empty, and good separation
> of UI, business rules and persistence. Plus I can use OOP and real
> "objects" in my code, not SQL queries and TField instances.
>
> Regards,
>   Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] External/out-of-tree LCL widgetset

[Kostas Michalopoulos via Lazarus]

@Sven:
Ah, i thought the custom drawn was built on top of LCL. Hm, regardless, it
doesn't solve my concern, since what i want is to reuse my widget toolkit.
Otherwise i'd probably work on fpGUI's Lazarus bindings since fpGUI seems
to be more mature.

@Martin:
No, it is tied to LCL :-P a lot of code uses LCL classes and i don't really
separate the "business logic" since i never planned (nor plan) to use that
code outside of LCL/Lazarus. This is mostly library code for
graphics-related utilities, common code for UI stuff like adjustments, etc.
Some code could work outside of LCL, but it is mixed with code that relies
on LCL and separating the two isn't worth the effort.

@Michael:
The "most of my code is LCL specific" part is about the code i work with on
Lazarus. Overall my code is pretty much even between Lazarus and C (with a
very tiny bit of LCL-free Free Pascal code). Generally for GUI heavy
desktop stuff i use Lazarus (and LCL) and for everything else i use C. For
some newer GUI stuff (currently light in GUI) i also use C with my toolkit.

@Mattias:
Thanks for the information. So in theory i could write a shell script that
creates a symbolic link lcl/interfaces/wsfoo that points to some external
(from Lazarus' source code dir) directory and adds (via sed, awk or
whatever) wsfoo to lcl/lclplatformdef.pas and then projects that override
the target widgetset (via the LCLWidgetType:=foo IDE macro) would work?

Kostas


On Mon, Nov 27, 2017 at 1:36 PM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Sun, 26 Nov 2017 19:32:21 +0200
> Kostas Michalopoulos via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>
> >[...]
> > As i said, i do not think this would be useful enough to others to be
> part
> > of the Lazarus tree. I ask because i remember a few months ago someone
> > having an Amiga widgetset pretty much in working condition and that was
> > something he worked on for a while, so i wondered if there was some
> > mechanism for that. I suppose just having a big patch would also work,
> > although it is kind of inconvenient.
>
> The Amiga widgetset is the 'mui'.
>
> You can add a new widgetset in folder lcl/interfaces/yourws and use it
> in your project.
>
> For some nicer integration you can add an enum to
> lcl/lclplatformdef.pas.
>
> The IDE checks only the sources listed in the lcl.lpk. Since your files
> are not listed there, changing any of your widgetset sources will not
> trigger building the LCL package automatically. So you have to click on
> the 'Compile' button in the LCL package.
>
> Mattias
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] External/out-of-tree LCL widgetset

[Kostas Michalopoulos via Lazarus]

Is there a way to have an LCL widgetset outside of the Lazarus tree? I'm
considering writing one for my Little Forms C toolkit at some point but i
don't think it would be very useful to others so i don't think there is
much of a value in having it as part of the Lazarus codebase (and TBH i
cannot guarantee i wont abandon it). Even better if it is possible for it
to exist as a package.

My main motivation is wanting to get away from the modern madness of
GTK3+/Qt5+/Wayland and all that stuff and their dependencies but i'd rather
not rewrite in C all the tools and library code i wrote in Lazarus, so a
custom widgetset that relies only on Little Forms (which itself makes an
effort to rely only on libX11 with an optional Xft dependency) sounds ideal.

However i'm not sure how extensible the LCL widgetset backend is and from a
quick look it seems like there is a ton of manual work just to introduce a
new one. Am i missing something?

Worst case, i'll maintain it as a patchset that needs to be updated with
the main code, but i'd rather not if there is a cleaner way (or can be
easily introduced, after all this isn't something i need immediately :-P
and i think there is value on this being a standard feature).
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] type IntegerList

[Kostas Michalopoulos via Lazarus]

That warning is misleading, makes too many assumptions about why the user
needs to do something (often a common mistake when trying to "correct"
others) and IMO wrong. Pointers and integers are separate things and a very
common reason PtrInt and PtrUInt are used are to reserve memory in cases
where you may want to store either an integer or a pointer but never both
and need enough memory to hold either one (similar reason why intptr_t and
uintptr_t exist in C). In that case, IntPtr is very useful when you want
the integer to be signed.

For example, TComponent uses that for the Tag attribute and it is sometimes
useful that you can store both unsigned integers and pointers in it.

Beyond that, it is also useful when interfacing with C code that accepts
intptr_t (for the same reasons).

The warning is really like having a "warning: dont use this because it is
dangerous" sticker to an industrial saw: the people buying the saw are
already in a position to know what they need to use it.

Summary: the IntPtr type was far from a mistake, the warning is misleading
and IMO it should be removed not only for the above reasons, but also
because AFAIK not all platforms treat pointers as linear addresses (let
alone signed or unsigned - for an example see i8086 pointers) and pointer
arithmetic should be done with the pointer types themselves instead of
converting them to integers (this is especially necessary for non-linear
addresses since IntPtr(Ptr+1) might not be the same as IntPtr(Ptr)+1).


On Mon, Nov 13, 2017 at 8:16 PM, Michael Thompson via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 14 November 2017 at 01:58, Alexey via Lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> shows it's useful. It supports Longint or PtrInt or PtrUInt? Or i need
>> another list for PtrInt
>>
>
> You may already be aware, but check out the warnings in this page
> https://www.freepascal.org/docs-html/rtl/system/ptrint.html
>
> "*The introduction of the ptrint type was a mistake. Please use ptruint
> ** instead*"
>
> Cheers
>
> Mike
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Code outline feature of the IDE

[Kostas Michalopoulos via Lazarus]

I think the problem is that the colors are too bright and saturated, just
desaturating the colors and making them darker would solve the issue.

Similarly with the lines, but with their brightness to be only a tad lower
than the background itself so they are mostly invisible (except perhaps the
innermost one where the cursor is). Also i'd make them dotted instead of
solid.

Beyond that i think it is a nice feature to have and - if the above issues
are addressed - i can see myself using it.


On Fri, Oct 20, 2017 at 3:38 PM, Werner Pamler via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Am 20.10.2017 um 14:05 schrieb Michael Van Canneyt via Lazarus:
>
>> On Fri, 20 Oct 2017, Vojtěch Čihák via Lazarus wrote:
>>
>>> I even didn't know this feature, but... so much colors, I almost
>>> collapsed :-)
>>>
>> Personally, I disabled it at once. I find it more disturbing than helpful.
>>
>
> This was my initial reaction, too. But later I decided to give it a try
> and forced myself to keep it on for some days. Once I got accustomed to the
> many colors it turned out to be very helpful in particular for longer
> routines written by somebody else using an indentation style different from
> mine.
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Converting all code to use UnicodeString

[Kostas Michalopoulos via Lazarus]

I do not see how it is a hack, when you have a function taking a null
terminated string of a specific character type (in this case PWideChar) and
you only have the generic string type you don't know what format the
underlying memory of the string is so you cannot pass it as a pointer to
the function. In this case you need to convert to the explicit type.

These are (potentially) two different types, they just happen to be
strings. You could think of it as if you had a function Foo(VP: PSingle)
and a variable V: Number where Number could be either Single or Double
depending on some macro - but you don't know which one, so to avoid passing
a Double you'd need to assign it to a temporary variable to convert it to
the right type.

There is nothing wrong or hacky with that approach, this is how working
with functions that accept pointers work in general - you need to make sure
that the pointer you pass in is of the correct type.


On Tue, Sep 26, 2017 at 4:37 AM, Marcos Douglas B. Santos via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Mon, Sep 25, 2017 at 9:52 PM, Juha Manninen via Lazarus
>  wrote:
> > On Tue, Sep 26, 2017 at 3:14 AM, Marcos Douglas B. Santos via Lazarus
> >  wrote:
> >> So, you mean that I cannot declare a constant without specify the
> >> type. The language allow me but it won't work?
> >
> > Yes you can declare a string constant without specifying the type.
>
> But according with this table, I shouldn't do that because so many
> problems could happen.
> http://wiki.freepascal.org/Unicode_Support_in_Lazarus#
> Without_.7B.24codepage_utf8.7D_or_compilerswitch_-FcUTF8
>
> >> 3.1. "When a parameter type is a pointer PWideChar,
> >> you need a temporary UnicodeString variable.
> >> ...
> >> That is a ugly hack. This code doesn't make any sense, if you don't
> >> know about these Unicode issues.
> >> We need do remember that trick when we are coding... not good.
> >
> > It is not so ugly. It is actually an elegant solution. Just one
> > assignment, using the FPC's automatic conversion in a clever way. No
> > explicit conversion functions or anything.
> > The "ugly" pointer typecast is needed always, also in Delphi.
>
> The "ugly" is because we need to remember to do that instead of just
> assign the variable.
> IMHO, both design are wrong. But I understand that the problem is in
> the compiler — or RTL.
>
> >> 4. "Reading / writing text file with Windows codepage"
> >> ...
> >> The text said: "This is not compatible with Delphi ".
> >> Examples on that page are hacks.
> >
> > The solution is to NOT use Windows codepages. They can be seen as a
> > historical remain with severe inherent problems which are solved by
> > Unicode already a long ago.
> > Windows has supported full Unicode since year 2000, and supported
> > UCS-2 before that.
> > Why would anybody still use the historical Windows codepages?
>
> So, no problems here and the page is outdated. OK.
>
> >> Summary:
> >> I know that was a huge work for who made that. Lazarus is more
> >> Unicode, more compatible with Delphi, and the team could move on.
> >> Great.
> >> But you might agree with me that this is far from a good design, right?
> >
> > IMO it is not far from a good design. From FPC's point of view it is a
> > hack but you can write 100% Delphi compatible code by following just
> > few simple rules (and dumping the historical Windows codepages).
>
> Like I said, it's a hack. But, again, it was|is a great job. No doubt.
>
> Best regards,
> Marcos Douglas
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Idea of TFormTitle

[Kostas Michalopoulos via Lazarus]

Why would you want that?

On Mon, Sep 11, 2017 at 11:19 PM, Alexey via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Maybe ok idea? make class TFormTitle. it is some small (by Y) form which
> is embedded into Form (form which has FormTitle property set). When prop
> FormTitle set, OS border hides and obj of FormTitle inserted into TOP of
> form (it looks like OS window caption).
>
> When this FormTitle is used, form has LCL border. default FormTitle can be
> simple (x, min, max +icon +title). OS border is hidden. It is ok idea?
>
> --
> Regards,
> Alexey
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] OpenGL 4.6 bindings and generator

[Kostas Michalopoulos via Lazarus]

Hi all,

After finding the OpenGL bindings that come with Lazarus a bit on the
ancient side of things (i think it only supports up to 4.0? Also there is a
4.3 version loading function but only seems to call 3.3's loader - ignoring
4.0 - and loads only a single extension) and never really liking the global
functions of pointers approach (if nothing else it makes the autocompletion
in the IDE a bit annoying) i decided to make some brand new bindings.

I wrote a parser for Khronos' XML spec (gl.xml) that generates the
appropriate interface and implementation. You only have to call LoadGLProcs
after you have a context ready and it tries to load everything it knows of.
Instead of Load_some_extension you get a global Has_some_extension variable
(these are initialized via LoadGLProcs too). As a bonus you get a
HasExtension function as well as an AllExtensions array of strings.

Btw it is not a drop in replacement for GL/GLext/GLotherstuff, although you
can use it with the OpenGL control that comes with Lazarus and most likely
it is compatible as long as you don't use it from the same unit (since all
they do is call the driver stuff anyway) and you initialize both using the
same context (since different contexts might give different functions).

You can find the code as well as a pregenerated "OpenGL" unit at:

http://runtimeterror.com/rep/gl2unit/index

At the moment only Windows is supported, but soon i'll add Linux and
eventually Mac OS X support (it should be around ~10 lines of code for each
OS, hopefully). Also i have done minimal testing so there might be bugs :-).

Kostas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] CodeTools knowledge about a project - find a class

[Kostas Michalopoulos via Lazarus]

Actually it works fine, after peppering the code with writelns to see the
flow, i figured out what was the issue: there is a 10 minute interval (by
default) between saves and the dictionary is only saved at the interval. I
expected it to be saved when exiting the IDE regardless of when the last
save was.

I added a Save; call right at the beginning of the OnIDEClose callback,
like this

procedure TCodyUnitDictionary.OnIDEClose(Sender: TObject);
begin
  Save; // Save the dictionary before closing the IDE
  fClosing:=true;
  FreeAndNil(fTimer);
end;

And it seems to behave as i expect it now. This way it wont lose any data
when i restart the IDE (which i do often when working with custom controls).

TBH i'm not sure the approach of only scanning what you have loaded is
enough since it still wont show anything from a unit i haven't already
loaded before. For example if i show the dialog looking for TGraphic it
will only show up after i have already used it at least once. So if i have
an empty database i get this:

1. Open the identifier db dialog (i have set it up as Alt+`)
2. Start typing TGraph
3. Nothing shows up
4. Press Ctrl+Space in a form code (e.g. Unit1 in the default empty project)
5. Start typing TGraph so that it shows in the completion dialog
6. Press esc to cancel the completion dialog
7. Open the identifier db dialog again
8. Start typing TGraph
9. Now TGraphic (and other stuff) show up

I think there needs to be a way for the dialog to also know whatever is or
can be known with the currently loaded packages and units, not just
whatever you have encountered so far. That information seems to already be
available in the IDE in other places.


On Fri, May 26, 2017 at 6:38 PM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Fri, 26 May 2017 18:24:12 +0300
> Kostas Michalopoulos via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>
> > > No. It stores all learned identifiers in a file:
> > >
> >
> > But then why does it behave as i mentioned? When i restart Lazarus it has
> > forgotten everything.
>
> What platform?
>
> What happens when you click on Tools / Options / Codetools / IDE
> Integration / Save dictionary now?
>
> Move the mouse over the button and wait for the hint to find out where
> it stores the file.
>
> Mattias
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] CodeTools knowledge about a project - find a class

[Kostas Michalopoulos via Lazarus]

> No. It stores all learned identifiers in a file:
>

But then why does it behave as i mentioned? When i restart Lazarus it has
forgotten everything.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] CodeTools knowledge about a project - find a class

[Kostas Michalopoulos via Lazarus]

This looks like a nice feature, but it only seems to know stuff you have
already open or opened in the current session. It doesn't know all
identifiers and whatever might be available from the currently loaded
project and packages. For example if you have a unit Foo (either in the
project or in one of the packages) but you don't have it opened at any time
in the current session, it wont be able to show you anything that Foo
exports. If you open Foo then it will, even if you close it after, but if
you restart Lazarus it will have forgotten everything.

Also i'd prefer if the Jump to button was default. It is trivial to change
this via code (i just set the button's Default property to true) but i'd be
nice if it was configurable in options.

Finally while it does seem to remember unit names, this is as a byproduct
of units being symbols and when you jump to a unit it puts the cursor to
the top of the file. It'd be nice if it had a special case for units that
only switched/opened the unit file without moving the cursor so you can
quickly jump between files with the same shortcut.

TBH i think such a "quick jump" would be a good thing to have in the base
IDE out of the box. Popular modern IDEs provide this functionality these
days and it is even included in some editors like Sublime. I think the
necessary low level functionality is almost there and it is mainly a matter
of tying everything together.


On Fri, May 26, 2017 at 2:11 PM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 2017-05-26 12:06, Ondrej Pokorny via Lazarus wrote:
>
>> Please share this feature with us when you implemented it! I miss it as
>> well (I do a simple Search in Files now).
>>
>
> It seems it already exists (as Mattias pointed out) - we just didn’t know
> about it. :)  All that remains is to assign a shortcut to it, if a default
> one doesn't exist.
>
> Regards,
>   Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Patch for fixing the window resizes when switching components

[Kostas Michalopoulos via Lazarus]

Yes the new code works perfectly fine here and is a better solution. My
original thought was to use pure Gtk but i forgot about gdk_ and only
looked for something like gtk_window_get_state - which i couldn't find :-).

On Thu, May 18, 2017 at 8:37 PM, zeljko via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 18.05.2017 13:38, Marc Weustink via Lazarus wrote:
>
>> zeljko via Lazarus wrote:
>>
>>> On 18.05.2017 01:43, Kostas Michalopoulos via Lazarus wrote:
>>>
>>> if GDK_IS_WINDOW(PGtkWindow(OurWidget)^.window) and
>>> (gdk_window_get_state(PGtkWindow(OurWidget)^.window) =
>>> GDK_WINDOW_STATE_MAXIMIZED) then
>>>   gtk_window_unmaximize() ...
>>> Same for unfullscreen and other "un" routines which we use inside that
>>> procedure.
>>>
>>> What other devels think about this ? Should I correct that patch in this
>>> way and fix future problems with eg gtk_window_unfullscreen() which
>>> isn't covered by this patch atm ?
>>>
>>
>> I prefer using the gtk/gdk functions and avoid getting (win)controls
>> from the widgetsets
>>
>
> I've removed workaround introduced in r54958 with pure gdk/gtk
> implementation in r54975.
> Please guys test, since I cannot reproduce problem here (even without any
> patch): Fedora 24 64bit, KDE Plasma (kwin is window manager).
> I need info from users from Mint 16..18 and Cinnamon DE which uses mutter
> or metacity if this finally fixes problem.
> Positive feedback = merge to 1.8RC2
>
> Important note: Gtk2 changes window state in async mode under x11, so
> statement like this won't work (it works ok under qt or win32) and you can
> expect problems with such code :)
>
> with TForm2.Create(Self) do
> begin
>   Show;
>   LCLIntf.ShowWindow(Handle, SW_SHOWMAXIMIZED);
>   LCLIntf.ShowWindow(Handle, SW_RESTORE);
> end;
>
>
> zeljko
>
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Patch for fixing the window resizes when switching components

[Kostas Michalopoulos via Lazarus]

Oops, indeed, i was tripped up by the not in "(not (Control is
TCustomForm)) or ..." part.



On Thu, May 18, 2017 at 10:28 AM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Thu, 18 May 2017 02:43:10 +0300
> Kostas Michalopoulos via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>
> > I see the patch was added and Lazarus seems to work fine now, but the
> check
> > was altered a little. The current check assumes that the Control will
> never
> > be nil, but is this the case?
>
> The "is" operator checks for nil.
>
>  if Assigned(Control) and (Control is TCustomForm) then
>
> <=>
>
>  if Control is TCustomForm then
>
>
> Mattias
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Patch for fixing the window resizes when switching components

[Kostas Michalopoulos via Lazarus]

I see the patch was added and Lazarus seems to work fine now, but the check
was altered a little. The current check assumes that the Control will never
be nil, but is this the case? I ask because i see in other places in the
same source code file that there are checks for that - almost all calls to
GetLCLObject either check for nil or use "if object is something then use
object" (with the "is" operator returning false for nil, essentially making
it an indirect test for nil).

This might be just an instance defensive programming, but i think it is a
good idea to bring this up.


On Thu, May 18, 2017 at 12:20 AM, Kostas Michalopoulos <
badsectorac...@gmail.com> wrote:

> Hi all,
>
> So i finally figured out why this happens and the reason is the
> ShowWindow(Handle, SW_SHOWNORMAL) call made when selecting components (this
> is done to activate the designer form).
>
> Under Gtk2 this call always calls gtk_window_unmaximize (among others) but
> Gtk2 seems to have a bug that always tries to unmaximize the window
> regardless of its status - with some window managers (like Window Maker)
> this can cause the window to be resized. The bug is most likely with Gtk2
> not ignoring the call for unmaximized windows, but since Gtk2's development
> has practically stopped (most recent changes are documentation and build
> fixes) and since Lazarus needs to work with 10+ year old versions of Gtk2,
> this needs to be addressed on the LCL side.
>
> Fortunately LCL already tracks the window state in the WindowState
> property, so at least for TCustomForm descendants (which would be almost
> all cases this is needed - 100% of the cases in design time where the bug
> is mostly visible) we can workaround this by not calling
> gtk_window_unmaximize for forms that aren't maximized.
>
> The description and patch can be found in Mantis here, as well as a video
> that shows the issue:
>
> https://bugs.freepascal.org/view.php?id=31832
>
> The patch was made against SVN but should apply with 1.8RC1 since i
> originally wrote it there.
>
> Kostas
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 1 of 1.8.0

[Kostas Michalopoulos via Lazarus]

I've noticed that the window shrinking bug in window maker with Gtk2 is
still there, but i finally managed to figure it out and made a fix. I
originally wrote the fix in 1.8RC1 so it should apply there, but the patch
is against SVN. I posted a more detailed email in the mailing list, but
here is the Mantis link https://bugs.freepascal.org/view.php?id=31832

I also see another issue with the form designer - when i have two forms
open, despite which one i activated last, the one i created something first
is always being focused even if i try to create something in the other
form. Note that this happens in 1.8RC1 and SVN with and without the patch i
mentioned above.

Kostas

On Thu, May 18, 2017 at 12:08 AM, Andreas Frieß via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> I see with the last patches something goes wrong after r54880 with frames
> and grid (specially TsWorkSheetGrid).
>
> Lazarus claims, the is no valid parent and didnot load and crash. It is
> only happen if you use frames ? The trouble is, i can only shutdown Lazarus
> with the Processmanger.
>
> Win10/64 with Lazarus 32/svn 1.9RC1
>
> Andreas
>
> Any hints ?
>
>
> Am 17.05.2017 um 14:39 schrieb Mattias Gaertner via Lazarus:
>
>> The Lazarus team is glad to announce the first release candidate of
>> Lazarus 1.8.
>>
>>
>>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Patch for fixing the window resizes when switching components

[Kostas Michalopoulos via Lazarus]

Hi all,

So i finally figured out why this happens and the reason is the
ShowWindow(Handle, SW_SHOWNORMAL) call made when selecting components (this
is done to activate the designer form).

Under Gtk2 this call always calls gtk_window_unmaximize (among others) but
Gtk2 seems to have a bug that always tries to unmaximize the window
regardless of its status - with some window managers (like Window Maker)
this can cause the window to be resized. The bug is most likely with Gtk2
not ignoring the call for unmaximized windows, but since Gtk2's development
has practically stopped (most recent changes are documentation and build
fixes) and since Lazarus needs to work with 10+ year old versions of Gtk2,
this needs to be addressed on the LCL side.

Fortunately LCL already tracks the window state in the WindowState
property, so at least for TCustomForm descendants (which would be almost
all cases this is needed - 100% of the cases in design time where the bug
is mostly visible) we can workaround this by not calling
gtk_window_unmaximize for forms that aren't maximized.

The description and patch can be found in Mantis here, as well as a video
that shows the issue:

https://bugs.freepascal.org/view.php?id=31832

The patch was made against SVN but should apply with 1.8RC1 since i
originally wrote it there.

Kostas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form resize to standard size in IDE.

[Kostas Michalopoulos via Lazarus]

Maybe it is also related to the problem i mentioned a few days ago? It does
sound kind of similar to what i demo in the video here:

https://webmshare.com/q78rb



On Mon, May 8, 2017 at 12:45 AM, Juha Manninen via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Sun, May 7, 2017 at 9:35 PM, Fabio Luis Girardi via Lazarus
>  wrote:
> > I (and others co-workers) have experienced the same behavior on Linux
> mint
> > cinnamon 17.3 when Lazarus is built using gtk2 (using Lazarus 1.4, 1.6,
> > fixes and trunk).
>
> I have seen similar reports but no common cause was found.
> Now it starts to look like a Cinnamon related issue. Somebody should
> debug it there.
>
> Juha
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Window Maker form resizes when selecting component

[Kostas Michalopoulos via Lazarus]

(for some reason i do not see the message to the mailing list so i hit
"Reply All" in case this is delayed)

GTK2, latest SVN (54709)

Note that this isn't new, i had it for at least a couple of years. I tried
to figure out at the time but failed and ignored it (i switched to another
WM when using Lazarus) but i decided again to see what is going on because
switching WMs is annoying.


On Mon, Apr 24, 2017 at 2:55 PM, zeljko <zel...@holobit.net> wrote:

> On 24.04.2017 13:50, Kostas Michalopoulos via Lazarus wrote:
>
>> Hi all,
>>
>> Does anyone know why the form (in design mode) resizes itself every time
>> i am selecting a component from the palette? Here is a small video
>> showing the issue:
>>
>> https://webmshare.com/q78rb
>>
>> This only happens with Window Maker and only in Lazarus. I suspect it is
>> either a Window Maker bug (since no other window manager has it, at
>> least none of those that i tried) or a Lazarus bug that doesn't
>> gracefully fail some missing extension from Window Maker (since no other
>> program has the issue) but i cannot find what causes it by looking at
>> the component palette code.
>>
>> Any ideas?
>>
>
> Widgetset ? Lazarus version ?
>
> zeljko
>
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Why lazarus is sorely needed: A plea for stability and backwards compatibility

[Kostas Michalopoulos via Lazarus]

Yeah, one thing i like with FPC and Lazarus is that there is a strong focus
on backwards compatibility. Of course it isn't perfect (with FPC 3 i had to
change some of my string code - e.g. i was loading files into strings by
setting the length and BlockReading the string directly - but that took
only a few minutes) but it is generally very stable.

On Thu, Apr 20, 2017 at 3:05 PM, Michael Schnell via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> +1 !!!
>
> The dream:
>
> Write and test a program using in a (partly) RAD way, of course in an
> Event-programming way, using the Lazarus IDE - say - in Windows.
>
> Now just by changing some settings, compile it for
>  - Win32
>  - Win42
>  - Win 32 or 64 as a service (hence also running on WIN IOT Core)
>  - MAC
>  - Linux Desktop (PC / ARM / ARM64 / MIPS / )
>  - Linux Headless (I do have done a working draft for an "active NoGUI"
> Widget Type)
>  - Android
>  - iOS
>  - with built-in Web Server,  the GUI shown on a browser
>  - As a Server based application (e.g. behind Apache or Microsoft IIS)
> with the GUI shown on a browser
>
> -Michael
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Alpha blending in GTK2 under Linux

[Kostas Michalopoulos via Lazarus]

Lazarus uses GDK instead of Cairo for most graphics stuff in GTK2 and GDK
simply wraps X11 which doesn't support alpha blending. AFAIK GTK2 was using
only GDK for graphics but at some point they switched to Cairo which does
all graphics operations in the CPU and allows for alpha blending in X11.
However Lazarus didn't switch (i suppose for binary compatibility with GTK2
versions that didn't have Cairo).

As a result practically all images from Lazarus to GTK2 had their alpha
channel dropped, including toolbar icons, messages, etc. I submitted a
patch for this a few years ago that handles the most common action -
drawing a bitmap to a widget or another bitmap. This is a special case and
doesn't fix the issue entirely, but at least allows toolbars, buttons,
timages, etc to do alpha blending.

A proper full fix would be to rewrite all GTK2 graphics code to use Cairo
instead of GDK, but that would take a lot of time, can break existing
applications due to unforeseen bugs and with GTK2 being obsoleted in favor
of GTK3 i am not sure if it is worth the effort.

For further details you can check bug 25491 here:

http://mantis.freepascal.org/view.php?id=25491


On Fri, Apr 14, 2017 at 10:23 PM, Valdas Jankūnas via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> 2017.04.14 22:02, Marc Weustink via Lazarus rašė:
>
> Why GTK2 "screen" not supports alpha?
>>>  It is strange because if I load PNG with transparency (image with
>>> gradient) into TImage then I clearly can see alpha blending effect on
>>> GTK2 when image is diplayed.
>>>
>>
>> Iirc (its long ago when i implemented it) the alphablending is done by
>> the underlying rawimage implementation
>>
>> Marc
>>
>
> I tried to put 32 bit image in to TImage (on GTK2) and alphablending
> works. Is this means that I can always put an image with 32 bit depth in to
> TImage when "GetDescriptionFromDevice(0)" says "screen" supports "Depth:
> 24"? If not always then how to know when I can?
>
>
> --
>   Valdas Jankūnas
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TPicture width questions (duplicate ways)

[Kostas Michalopoulos via Lazarus]

Of course the second part should have been Rect(0, 0, p.Jpeg.Width,
p.Jpeg.Height)? :-P

On Fri, Mar 10, 2017 at 7:01 PM, Kostas Michalopoulos <
badsectorac...@gmail.com> wrote:

> You can check yourself easily: Ctrl+Click on the p.Width to go to the
> definition of the property, then Ctrl+Click on the GetWidth getter,
> Ctrl+Shift+Down arrow to see the code for the getter and see that it simply
> gets FGraphic's property. So what is FGraphic? Ctrl+Home to move at the top
> of the source code (you'd be in picture.inc) and search for "FGraphic :="
> to see where it is assigned (the source code style in that file seems to
> put a space before := in assignments). You can see that it is used in a
> bunch of places, so you can see where those uses are. ForceType is the
> first one and if you search for that one, you'll find that it is used
> wherever a type-specific property (p.Jpeg, p.Bitmap, etc) is used -
> presumably to convert the underlying graphic to the requested type. So the
> FGraphic object is actually an instance of the TBitmap,
> TPortableNetworkGraphic, TJpegImage, etc (depending what you loaded and/or
> accessed last).
>
> So what p.Width gives you is the FGraphic's width or 0 if there is no
> FGraphic loaded (because a picture may have nothing loaded until you either
> load it directly or try to access any of the Bitmap, Jpeg, PNG, etc
> properties). So if you already have a picture loaded from a PNG file,
> p.Width, p.Graphic.Width and p.PNG.Width will give you the same number. If
> your picture doesn't have a graphic (e.g. it is a newly constructed object)
> then p.Width gives you 0, p.Graphic.Width will crash your program (FGraphic
> is nil) and p.PNG.Width will give you zero (because accessing the PNG
> property will call the ForceType function which will create a
> TPortableNetworkGraphic object that by default is undefined and gives you
> zero width).
>
> Question for the readers: what happens to the image if you load a PNG file
> with alpha values using TPicture's LoadFromFile, access the
> TPicture.Jpeg.Width property and then save the picture as a PNG file using
> TPicture's SaveToFile? Is the alpha component preserved? Do you get jpeg
> artifacts? Why?
>
> Bonus question: why is R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height) worse
> than R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height)? Why is R := Rect(0, 0,
> p.Width, p.Height) better than either of them?
>
> You can find the answers to those (and many more) using Ctrl+Click,
> Ctrl+Shift+Up/Down Arrow, Search and back and forward buttons (helps to
> have a mouse with those). Considering how big and complex LCL is, it helps
> to be able to navigate and familiarize yourself with its source code :-).
>
>
> On Thu, Mar 9, 2017 at 7:44 PM, Lars via Lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> On 2017-03-09 10:48, José Mejuto via Lazarus wrote:
>>
>>>
>>> AFAIK:
>>>
>>> TPicture.Width is the TGraphic container size.
>>> TPicture.jpeg.Width is the width declared in the jpeg image.
>>> TPicture.Bitmap.Width is the width of the bitmap in pixels.
>>>
>>> Mostly the 3 will have the same value but extracted from different
>>> sources.
>>>
>>>
>> If I start off using a bitmap, and all of a sudden start using jpeg, will
>> it automagically work or does one have to initiate the jpeg in some way?
>>
>> Example: you start off working with a classic BMP, but then 60 lines of
>> code later you want to work with it as a jpeg. Do you just magically start
>> working with a jpeg without any worry, or you have to take some precautions?
>>
>> Likely, this is explained in a article on the wiki somewhere, I don't
>> know :-)
>>
>> --
>> ___
>> Lazarus mailing list
>> Lazarus@lists.lazarus-ide.org
>> http://lists.lazarus-ide.org/listinfo/lazarus
>>
>
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TPicture width questions (duplicate ways)

[Kostas Michalopoulos via Lazarus]

You can check yourself easily: Ctrl+Click on the p.Width to go to the
definition of the property, then Ctrl+Click on the GetWidth getter,
Ctrl+Shift+Down arrow to see the code for the getter and see that it simply
gets FGraphic's property. So what is FGraphic? Ctrl+Home to move at the top
of the source code (you'd be in picture.inc) and search for "FGraphic :="
to see where it is assigned (the source code style in that file seems to
put a space before := in assignments). You can see that it is used in a
bunch of places, so you can see where those uses are. ForceType is the
first one and if you search for that one, you'll find that it is used
wherever a type-specific property (p.Jpeg, p.Bitmap, etc) is used -
presumably to convert the underlying graphic to the requested type. So the
FGraphic object is actually an instance of the TBitmap,
TPortableNetworkGraphic, TJpegImage, etc (depending what you loaded and/or
accessed last).

So what p.Width gives you is the FGraphic's width or 0 if there is no
FGraphic loaded (because a picture may have nothing loaded until you either
load it directly or try to access any of the Bitmap, Jpeg, PNG, etc
properties). So if you already have a picture loaded from a PNG file,
p.Width, p.Graphic.Width and p.PNG.Width will give you the same number. If
your picture doesn't have a graphic (e.g. it is a newly constructed object)
then p.Width gives you 0, p.Graphic.Width will crash your program (FGraphic
is nil) and p.PNG.Width will give you zero (because accessing the PNG
property will call the ForceType function which will create a
TPortableNetworkGraphic object that by default is undefined and gives you
zero width).

Question for the readers: what happens to the image if you load a PNG file
with alpha values using TPicture's LoadFromFile, access the
TPicture.Jpeg.Width property and then save the picture as a PNG file using
TPicture's SaveToFile? Is the alpha component preserved? Do you get jpeg
artifacts? Why?

Bonus question: why is R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height) worse
than R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height)? Why is R := Rect(0, 0,
p.Width, p.Height) better than either of them?

You can find the answers to those (and many more) using Ctrl+Click,
Ctrl+Shift+Up/Down Arrow, Search and back and forward buttons (helps to
have a mouse with those). Considering how big and complex LCL is, it helps
to be able to navigate and familiarize yourself with its source code :-).


On Thu, Mar 9, 2017 at 7:44 PM, Lars via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 2017-03-09 10:48, José Mejuto via Lazarus wrote:
>
>>
>> AFAIK:
>>
>> TPicture.Width is the TGraphic container size.
>> TPicture.jpeg.Width is the width declared in the jpeg image.
>> TPicture.Bitmap.Width is the width of the bitmap in pixels.
>>
>> Mostly the 3 will have the same value but extracted from different
>> sources.
>>
>>
> If I start off using a bitmap, and all of a sudden start using jpeg, will
> it automagically work or does one have to initiate the jpeg in some way?
>
> Example: you start off working with a classic BMP, but then 60 lines of
> code later you want to work with it as a jpeg. Do you just magically start
> working with a jpeg without any worry, or you have to take some precautions?
>
> Likely, this is explained in a article on the wiki somewhere, I don't know
> :-)
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] LCL High-DPI request for help adding images

[Kostas Michalopoulos via Lazarus]

SVN is not ideal for icon formats. Beyond being too big (it is a verbose
XML file after all), vector icons do not good at arbitrary sizes. IMO the
best approach for vector icons is what Haiku OS is doing by using a custom
icon format that is designed for small sizes and -more importantly-
different elements in an icon can have a LOD range so that some elements
will be hidden in small sizes and others hidden in large sizes.

Details and an example for LOD is here:

https://www.haiku-os.org/docs/userguide/en/applications/icon-o-matic.html

The icon with the four colored triangles only show numbers in large sizes
and in small sizes the outline is replaced with a thicker one that is still
visible despite the small size (the original outline would be a smudge at
the smallest size).

More technical details for Haiku's format can be found here:

http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html

Of course this is probably the hardest approach to take (at minimum one
would need to make an editor for such icons), but IMO if a DPI-agnostic is
to be made, it is better to go with the technically superior approach if
such a solution is to remain around for years.

(note that i do not think that using the haiku format directly is a good
idea by itself, i'm just giving it as an example)

AFAIK SVG itself does not support LODs, although it is possible to emulate
it if the SVG loader supports CSS and media queries so one could use
something like @media screen and (max-width: 32px) for selecting 32px and
below sizes. With multiple of these one can adjust properties like stroke
widths and hide elements. But i'm not sure if any non-browser SVG loader
even support CSS, let alone CSS with media queries.

Regardless if there is support for that, information can be found here for
LOD:

http://w3c.github.io/svgwg/specs/svg-authoring/

(search for 2.6. Responsive Images)

FWIW personally i think a dedicated format for vector icons (like what
Haiku uses) would be a better idea in the long term.


On Sun, Feb 26, 2017 at 11:13 PM, Ondrej Pokorny via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 26.02.2017 17:01, Donald Ziesig via Lazarus wrote:
>
>> I agree.  I just spent most of two days rescaling the icons with gimp,
>> then registering them.  It looks good, but I sure would not want to have to
>> repeat for 200%, etc.
>>
>
> Do you mean that you took Lazarus original 16px icons, scaled them up to
> 24px one by one and registered them for Lazarus?
>
>
> Ondrej
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Widget set definitions

[Kostas Michalopoulos via Lazarus]

The LCL package has this in custom definitions for dependent packages:

-dLCL -dLCL$(LCLWidgetType)

So Lazarus simply defines the LCL and LCL at compile time.
 is one of the subdirectories in lcl/interfaces.


On Mon, Feb 13, 2017 at 12:21 PM, Mark Morgan Lloyd via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 13/02/17 10:00, Mattias Gaertner via Lazarus wrote:
>
>> On Mon, 13 Feb 2017 09:23:35 +Mark Morgan Lloyd via Lazarus <
>> lazarus@lists.lazarus-ide.org> wrote:
>>
>>> I've got a bit of diagnostic code that I add to most programs that >
>>> retrieves things like Subversion revision numbers and link-time build > ID.
>>> It also contains> > (*$IFDEF LCLQT *)>   widV= 'Linked with the Qt
>>> widget set';>(*$DEFINE WIDGETSET *)> (*$ENDIF   *)> (*$IFDEF
>>> LCLFPGUI *)> widV= 'Linked with the FPGUI widget set';>(*$DEFINE
>>> WIDGETSET *)> (*$ENDIF   *)> > and so on.> > Presumably LCLQT and the
>>> rest are defined somewhere in the IDE or LCL, > but where can I find this
>>> so that I can make sure that my code's kept in > step?
>>>
>> uses InterfaceBase, LCLPlatformDef;
>> widV:='Linked with '+LCLPlatformDisplayNames[WidgetSet.LCLPlatform]+'widget
>> set';
>>
>
> OK, Thanks. So I can see how I can derive the names etc. from that, it
> appears to have been supported since the dawn of time, and linking to it is
> still going to be no more intrusive than some of the other stuff that's
> already in my diagnostic unit.
>
> But out of curiosity, I'd still be very interested to know how the
> compile-time definitions like the ones in my example are generated :-)
>
> --
> Mark Morgan Lloyd
> markMLl .AT. telemetry.co .DOT. uk
>
> [Opinions above are the author's, not those of his employers or colleagues]
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Run parameters

[Kostas Michalopoulos via Lazarus]

I think having a list for run modes (i assume you mean the settings you
specify in the Run -> Run Parameters dialog box) that you can select from a
popup menu near the "play" button and have different run modes apply, like
you can select the build mode from the "gear" button, is a good idea. Being
able to switch configuration files and working directories from inside
Lazarus for some of the tools i work with would be very nice.

The only thing i disagree with is to have them per build mode since chances
are you'd need them with different build modes (e.g. debug, release,
profile, etc would have the same run modes) and even if you could copy
them, it would still be an annoyance to make sure all are available.

Instead i'd say to have a table with a column per build mode and a row per
run mode, have checkboxes for those that will apply and those checkboxes
would be enabled by default.

Alternatively just use a global list that is the same across all build
modes, but then you may have run modes that do not apply in all build modes
and have them take up space (e.g. if one of your run modes causes a program
to load a 32bit DLL and you are in a build mode that explicitly targets a
64bit OS this run mode wouldn't apply - of course one case wouldn't matter
much, but the next thing i imagine after such a feature is available is
being able to generate run modes automatically though a script :-P).

Kostas


On Sat, Feb 11, 2017 at 1:15 PM, Michael Van Canneyt via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

>
>
> On Sat, 11 Feb 2017, Mattias Gaertner via Lazarus wrote:
>
> On Sat, 11 Feb 2017 11:22:23 +0100 (CET)
>> Michael Van Canneyt via Lazarus  wrote:
>>
>> Hello,
>>>
>>> Currently, the options specified in 'Run - Parameters' are stored in the
>>> project.lpi file.
>>>
>>> I have always found this a strange choice.
>>> What is the rationale for this decision ?
>>>
>>
>> Some projects need the same run parameters on all machines.
>> For example instantfpc projects can't run with the default run
>> params.
>>
>
> From my personal experience, I really think this is a minority...
>
> For example, testsuites. I keep setting the --suite=TestA.MethodXYZ. My
> collegue sets it to --suite=TestB.MethodC. It gives me conflicts every time
> I update from SVN.
>
> And in this case you almost never use the same command-line twice.
>
> Logically, I would I think these parameters belong in the .lps file ?
>>>
>>
>> I agree, there should be an option. Or even better would be a list
>> of run modes.
>>
>
> Don't get overenthousiastic. Keep it simple :)
>
> The trouble with a list is that you must maintain it, just as the build
> modes. I don't want that.
>
> So if you do decide to introduce it, please keep it optional, as the build
> modes.
>
> Not to say there is already a list, namely the history mechanism.
>
>
>> Some developers using build modes suggested to have different run
>> parameters per build mode. So it would be nice if the list and build
>> modes can be connected. For example when switching the build mode, the
>> IDE automatically switches the run mode too.
>>
>
> Well.  If you can give a global option
>
> Save "run parameter" settings in
> [*] .lpi file
> [ ] .lps file [ ] run modes
> [ ] build mode
>
> I will be satisfied. You could use the ones in .lpi as a fallback, in case
> they are not set in
> the .lps
>
> Michael.
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TDataModule for non-database non-visual components

[Kostas Michalopoulos via Lazarus]

Great.

But maybe that should be made clear in the docs like Embarcadero's docs
mention? Because both the wiki and the name imply a database orientation.

On Tue, Feb 7, 2017 at 12:15 AM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Mon, 6 Feb 2017 21:17:48 +0200
> Kostas Michalopoulos via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>
> > Hi all,
> >
> > A simple question, is it ok to use a TDataModule for non-visual
> components
> > that can be shared among forms (and generally contain app-wide stuff)?
>
> Yes. That's their purpose.
>
>
> >[...]
>
> Mattias
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] New high DPI features in 1.7

[Kostas Michalopoulos via Lazarus]

Looks like Visual Basic was onto something when they defaulted to "twips"
back in the 90s :-P

On Fri, Dec 9, 2016 at 12:52 PM, Erwin van den Bosch via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Thanks for the good work Ondrej! A big step forward. I will test it in the
> next few days and hopefully can give some feedback.
>
> Although this is a step forward I think working with pixels is something
> from the past as with the Sinclair ZX81 (where you have 64x48 pixels) or
> Commodore 64.  (320x200px!) :-) But today's computers still thinking in
> pixels not in size. And working with just pixels might work if our screens
> will always be 1024x768 pixels with size of 15".
>
> Erwin
>
>
> Op 9-12-2016 om 9:12 schreef Ondrej Pokorny via Lazarus:
>
> Hello,
>>
>> I have worked on high DPI features recently.
>>
>> If you want to play with high DPI support, follow this instruction:
>> http://wiki.lazarus.freepascal.org/High_DPI#High_DPI_in_
>> Lazarus_1.7_and_above
>>
>> For Lazarus IDE itself: Recompile the IDE with LCLScaleForms compiler
>> define before testing Lazarus IDE and reporting/fixing any layout bugs.
>> After some time of testing LCLScaleForms will become default.
>>
>> Ondrej
>>
>>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] DoomRL based of FPC now open sourced

[Kostas Michalopoulos via Lazarus]

And cue all the people in Reddit yet again reminiscing about their Turbo
Pascal days. And those are the best comments :-P.

Yesterday i wrote a rendering test for light clustering with forward
rendering (https://www.youtube.com/watch?v=MefoEXK1gUw). It has been a
while since i wrote something more advanced than early 2000s stuff in terms
of graphics and when it comes to Lazarus, it has been a while since i
worked on non-tool stuff (although, the math stuff in the demo was from my
tool package :-P).

I don't see FPC and Lazarus as lacking anything in terms of features or
performance for use in high end games. Well, except perhaps runtime support
for consoles, but that isn't unsolvable (and has already been done with
another low key compiled language - AFAIK Remedy used D for some parts of
their latest game and had to port the language's runtime to consoles).

And well, not everyone is interested in consoles anyway :-P.


On Thu, Dec 8, 2016 at 2:36 AM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 2016-12-07 17:44, Anthony Walter via Lazarus wrote:
> > DoomRL was written using Free Pascal.
>
> That's just awesome!  Thanks for sharing.
>
> Regards,
>   Graeme
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TPageControl OnChange calling issue

[Kostas Michalopoulos via Lazarus]

If the existing functionality differs from Delphi, i say to keep the
existing functionality as the default.

After all what is more important? Breaking existing Lazarus users' code or
potentially having a Delphi code migration become slightly harder because a
project will need to change a property (also isn't stuff like this why the
IDE has options to import Delphi projects/units/forms/etc?).


On Wed, Nov 16, 2016 at 11:35 AM, Michael Schnell via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 16.11.2016 10:33, Ondrej Pokorny via Lazarus wrote:
>
>> The mode settings have unit-scope. TPageControl/TCustomTabControl are in
>> unit ComCtrls that is always built with objfpc mode.
>>
> I see.
>
> Thanks,
> -Michael
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 1.6.2

[Kostas Michalopoulos via Lazarus]

The installer had an "Uninstall" button to uninstalled the previous
version. I used that then used Tools -> Build Lazarus with  option to
rebuild the IDE so that it'll have the packages i have installed and it
worked fine.

On Tue, Nov 15, 2016 at 11:10 PM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Tue, 15 Nov 2016 15:11:31 -0500
> Reggie Brooks via Lazarus  wrote:
>
> > Can this 1.6.2 release be installed over an existing 1.6.0 installation,
> or would I have to uninstall the 1.6.0 first?
>
> The dmg/deb/rpm/zip can be installed over an existing 1.6.0 without
> uninstall.
> I didn't try the Windows installer. Martin?
>
> Mattias
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 1.6.2

[Kostas Michalopoulos via Lazarus]

The main site seems to still serve the 1.6.0 download.

On Tue, Nov 15, 2016 at 8:42 PM, Luca Olivetti via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> El 15/11/16 a les 19:27, Ondrej Pokorny via Lazarus ha escrit:
>
>> Thank you for your efforts - please send the patch to mantis so that DB
>> maintainers don't oversee it!
>>
>>
>
> Done:
>
> http://bugs.freepascal.org/view.php?id=30931
>
> Bye
> --
> Luca Olivetti
> Wetron Automation Technology http://www.wetron.es/
> Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TColor and Alpha channel support

[Kostas Michalopoulos via Lazarus]

Yes, overloaded versions that take both TColor and TFPColor (with the
former calling the latter with conversion function) should be the best
approach both to preserve backwards compatibility (for existing code) and
consistency (for any new function).

On Mon, Sep 26, 2016 at 6:41 PM, Graeme Geldenhuys via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 2016-09-26 16:15, Kostas Michalopoulos via Lazarus wrote:
> > Is there a need for alpha *everywhere* a color is used?
>
> So how would functions that take TColor parameters work? For example,
> drawing a gradient with increasing Alpha value, say via a
> TCanvas.GradientFill() call. In the case of GradientFill() it has a
> Start/Stop TColor parameter. Also other functions like
> DrawGradientWindow() etc. So for each such cases, new overloaded
> versions will be implemented, replacing TColor with TFPColor?
>
> Regards,
>   Graeme
>
> --
> fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
> http://fpgui.sourceforge.net/
>
> My public PGP key:  http://tinyurl.com/graeme-pgp
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TColor and Alpha channel support

[Kostas Michalopoulos via Lazarus]

Is there a need for alpha *everywhere* a color is used? From my experience,
i've only really needed alpha for TCanvas (so i can draw, e.g. translucent
rectangles). I don't think there is a need to add more baggage in controls
by introducing yet another mostly redundant FPColor property. Controls that
need color with alpha could just provide a ColorAlpha property (for Color
property - if a Color property is named Foreground or SecondaryColor then
the alpha would be ForegroundAlpha or SecondaryColorAlpha).

If one doesn't care about compatibility with Delphi, a Color: TFPColor
property could be used and Lazarus be made (if it doesn't already) to
handle TFPColor similarly to TColor but with a custom dialog that can edit
the alpha.

For TCanvas, a TFPColor behind the scenes that is mapped to both TFPColor
and TColor properties on access should be enough. Yes, it is redundant, but
since most Canvas use is done via code (instead of a visual property
editor), i'd say that being able to access RGBA as a single value instead
of a value pair is cleaner.


On Mon, Sep 26, 2016 at 4:52 PM, Martin Schreiber via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Monday 26 September 2016 15:01:04 Graeme Geldenhuys via Lazarus wrote:
> > On 2016-09-26 13:52, Martin Schreiber via Lazarus wrote:
> > > Or:
> > > "
> > >  Alpha := ...; // property Alpha: TColor
> > > "
> > > for alpha per colour channel.
> >
> > In that case I would make it a record type with RedAlpha, GreenAlpha and
> > BlueAlpha: Byte. Why?, Because TColor's range is way to large, with most
> > of the acceptable values being meaningless.
> >
> Using TColor has the advantage that the same mechanism of RGB-lookup
> of "logical" colours as with normal TColor values can be used. TColor with
> the MSB = 0 is a special case where the lower bytes contain the RGB values.
> Simple and efficient.
> In MSEgui the MSB defines the kind of the logical color value, "functional"
> (cl_invalid,cl_default..), "mapped" (cl_dkshadow,cl_shadow...), "named RGB"
> (cl_black, cl_dkgray...) and "user".
>
> Martin
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Linux lazarus gtk2 look

[Kostas Michalopoulos]

This doesn't have to do with Lazarus, it is GTK's theme. The second
screenshot shows the Raleigh theme which is the default GTK+ 2 theme. I
don't know about KaOS to suggest packages and such, but the first
screenshot uses a popular theme which AFAIK is installed by default on
Debian when you choose to install the desktop.

You can look in KaOS's packages for gtk2 themes (or look in gnome-looks.org
and similar sites for other gtk2 themes) and use a tool like "GTK2 Change
Theme" to enable it.

If you are using a desktop environment like XFCE, it'll also have a bunch
of themes preinstalled and provide means for switching between them. XFCE
uses GTK2 for itself so you shouldn't need to mess much with it.


On Tue, Aug 30, 2016 at 9:02 PM, John Landmesser 
wrote:

>
> Is it possible to adjust the look of Lazarus _IDE (gtk2):
>
> Same PC, Lazarus trunk but two different KDE linux Desktops.
>
> This one is ok: Debian (Sid) KDE
>
> https://drive.google.com/file/d/0BwR9__ABsiOFaXlLU0VOc2N2dzg
> /view?usp=sharing
>
>
>
> That's bad: same PC but KDE on KaOS.
>
> https://drive.google.com/file/d/0BwR9__ABsiOFeHpfcXhzTGR0dk0
> /view?usp=sharing
>
>
> Where are these grey colors defined?
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Again an UTF8 mess!

[Kostas Michalopoulos]

Why not make the old functions simply call the new ones? Why break user
code?

On Wed, Jul 13, 2016 at 7:57 PM, Juha Manninen 
wrote:

> On Wed, Jul 13, 2016 at 7:32 PM, Giuliano Colla
>  wrote:
> > whatever is marked as deprecated, it's easily understood by anybody.
>
> They were deprecated for a long time in trunk and also in the 1.6 release.
> They will be deprecated forever in the fixes_1_6 branch and in 1.6.x
> dot releases.
>
> Juha
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] GTK 3.0

[Kostas Michalopoulos]

> People will stick on GTK2. And maybe after a some years in GTK3.
> People doesn't want to re-write their application. I don't think Gimp
> will be re-written for GTK3, and if it's re-written for GTK3 someday, it
> won't be re-written for GTK4 and latter for GTK5.
>

Yeah, personally i do not see a reason to move off GTK+ 2. If anything, in
my system GTK+ 2 programs look and behave better than GTK+ 3 programs
(which also tend to have a ton of visual glitches with broken themes). I
just hope that someone will fork GTK+ 2 to introduce new features for
working with the desktop environments and window systems (e.g. Wayland,
HiDPI, etc).
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] GTK 3.0

[Kostas Michalopoulos]

Sadly the GTK+ devs do not seem to care much about backwards compatibility
and love to break stuff every other version.

Check this blog post which summarizes the issues
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

IMO GTK+ 2 is the last good GTK+ version and hopefully someone (maybe the
MATE devs) will fork it and add support for the needed stuff. GTK+ 3.0+ is
not reliable.


On Sat, Jul 9, 2016 at 3:34 PM, Juha Manninen 
wrote:

> On Sat, Jul 9, 2016 at 2:16 PM, Erwin van den Bosch 
> wrote:
> > Do we need GTK 3 in Lazarus? Or is GTK 2 good enough?
>
> GTK 3 binding is needed.
>
> > Is someone working on the LCL implementation of GTK 3?
>
> Currently not. We need more contributions.
>
> > How difficult is it to implement GTK 3?
>
> Should be easier than GTK 2. The binding's design is better.
> Zeljko can answer detailed questions if you plan to improve it.
>
> Juha
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus