[Lazarus] Using event driven components in console application

JuuS JuuS at mykolab.ch
Thu Nov 5 19:42:09 CET 2015



On 11/05/2015 07:05 PM, JuuS wrote:
> 
> 
> On 11/04/2015 12:30 PM, Mark Morgan Lloyd wrote:
>> JuuS wrote:
>>> On 11/04/2015 09:48 AM, Mark Morgan Lloyd wrote:
>>>> When building the IDE you'd normally use  make bigide  or similar which
>>>> would use the platform defaults, but depending on what libraries etc.
>>>> were available you could also use e.g.  make LCL_PLATFORM=qt bigide
>>>>
>>> Hi,
>>>
>>> This question / discussion is also very interesting to me (warning
>>> possible dumb questions ahead).
>>>
>>> I am still very vague on the widget type/set in my gnu/linux education.
>>> I'm kub14.04, the ide then uses gtk2, all automatic.
>>
>> If that's Kububtu, I'd expect it to be using KDE which implies you've
>> already got Qt. Assuming that you have- or can add- libqt4pas-dev then
>> you can build the Lazarus IDE etc. for Qt.
>>
> 
> Ahhhh. Thank you for the insight! Yes, I can now compile qt as well as
> gtk2.
> 
> So simple!!...when you know what is needed...
> 

Just FYI for others that may be in my position:

This insight (using a qt version) just solved the problem I was having
with a later install version of kub 14.04 and kub 15.04 and 15.10 where
a simple progress bar from the comp. palette showed fine in my
development computer (earlier install v. of 14.04) but would NOT show in
those other two versions. Ouch.

Thanks again, you just solved a headache for me (but one needs to
install the libqt4pas5 library on the destination machines, even so
problem solved).

> 
>>> But my questions are:
>>>
>>> Why would I want to use qt, gtk3, etc? Yes, of course for different
>>> platforms but which platforms (Fedora? Debian? ?? ).
>>
>> Depends massively on the version of whichever distro you've selected,
>> since these will typically bundle different versions of Gnome and it's
>> this that drives GTK forwards. I'm sure you've seen Torvalds' rants on
>> the issue.
>>
>> It also depends on the version of Lazarus you're using since of
>> necessity this tracks GTK and Qt, and to a much lesser extent on the
>> version of FPC for the same reason.
>>
>> In general, Debian "Lenny" is OK for GTK and GTK2. Debian "Squeeze" and
>> "Wheezy" are OK for GTK2 and Qt. My experience with Lazarus "Jessie" is
>> that Qt is somewhat more reliable than GTK, although I'm sure I'll take
>> flak for saying so.
>>
>> Can't remember where I've got to with "Stretch". Recent versions of
>> Lazarus have started making demands of Qt that are no longer satisfied
>> by the one with "Squeeze".
>>
>>> Does this mean then that what I have developed in gtk2 will ==NOT== run
>>> properly in some gnu-L flavours? Which ones? How do I tell?
>>
>> Yes. Pass. Badly.
>>
>>> I guess setting up VMs for my targets is a good solution to find out if
>>> there is a problem but I can't always tell which widgetset is right for
>>> which flavour...?
>>>
>>> I have googled this before but have found nothing that has enlightened
>>> me.
>>
>> The first problem to solve is pairing up which version of FPC works best
>> with a given version of Lazarus. After experimentation, I've got
>>
>> /usr/local/bin/lazarus-0.9.24+2.2.4
>> /usr/local/bin/lazarus-0.9.26+2.2.4
>> /usr/local/bin/lazarus-0.9.28+2.4.0
>> /usr/local/bin/lazarus-0.9.30+2.4.4
>> /usr/local/bin/lazarus-1.0.0+2.4.4
>> /usr/local/bin/lazarus-1.0.0+2.6.0
>> /usr/local/bin/lazarus-1.0.8+2.6.2
>> /usr/local/bin/lazarus-1.0.14+2.6.4
>> /usr/local/bin/lazarus-1.2.6+2.6.4
>> /usr/local/bin/lazarus-1.4.2+3.0.0
>> /usr/local/bin/lazarus-gtk1-compatible
>>
>> The last of those is actually 0.9.24.1 with FPC 2.2.4, which is about as
>> old as is viable. I can't say without significant digging in my build
>> scripts which of those are also good for Qt. I really can't say which
>> are good for different versions of Windows (except that if you really do
>> have to build for NT you'll need something like 0.9.26.2 + 2.2.4) or for
>> OS X. Anybody into SPARC Solaris should find 1.4.2 + 3.0.0 OK.
>>
>> The best thing to do, in my opinion, is to build as many variants of
>> your binary as possible for a given platform, and then find out what
>> doesn't work. To try to keep that doable I've got a script set up which
>> points each of the combinations listed above at its own configuration
>> file, so that I don't find myself chasing shadows because the underlying
>> FPC version is suddenly wrong.
>>
> 
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
> 




More information about the Lazarus mailing list