Explain why you think it can't be integrated with other loops? Glib
has been synced with many things (libev, zeromq, qt, etc).
When thinking, over the weekend I, seem to now top have understood, that
I misread your suggestion and that it's vice-versa than I first go it:
GTK does not know
I see.
Thanks !
If the GTK3 Widget Type does not need for Pascal based queues for things
like TThread.Synchronize() or Application.QueueAsyncCall the GTK3
API would need to provide a way to insert user program created events in
the external queue (such as Windows does).
If so: good.
If
On 04/06/2012 03:56 AM, waldo kitty wrote:
so... noGUI? maybe... :?
User-code done with noGui definitely can't be event driven (I did do a
lot of research on that some time ago and I did hear that it has changed.)
-Michael
--
___
Lazarus mailing
On Thursday 05 of April 2012 17:15:42 Michael Schnell wrote:
Qt/GTK/X11 allow for this design as well.
So there is a possibility to feed user events to the queue in GTK ? If
so, I don't understand why the GTK Widget Type (other than the Windows
Widget Type) implements additional (an)
On 04/04/2012 10:20 PM, Alberto Narduzzi wrote:
True is that nowadays NON-GUY envs. tend to disappear; but you need to
remember that FP is meant to be portable to (any) environment,
including embedded systems; where this difference is still alive and
kicking.
Embedded stuff, CGI,
On 04/04/2012 10:20 PM, Alberto Narduzzi wrote:
Sorry, this one I cannot catch... :-O
CustomDrwan allows for intercepting the calls to the GUI at a layer
quite near to the system API. So you can (in a sick way, from behind, at
least technically) separate the business code from the GUI even in
On Thu, 05 Apr 2012 09:38:07 +0200
Michael Schnell mschn...@lumino.de wrote:
On 04/04/2012 10:20 PM, Alberto Narduzzi wrote:
True is that nowadays NON-GUY envs. tend to disappear; but you need to
remember that FP is meant to be portable to (any) environment,
including embedded systems;
On 04/05/2012 10:00 AM, Mattias Gaertner wrote:
And since years you are told that Lazarus adds GUI to the non GUI
stuff in FPC. No gui stuff was never the goal of the LCL.
I don't blame anybody on this, but it is as it is, and the fact that it
never was the goal does not mean that it does not
Michael Schnell schrieb:
On 04/04/2012 10:20 PM, Alberto Narduzzi wrote:
True is that nowadays NON-GUY envs. tend to disappear; but you need to
remember that FP is meant to be portable to (any) environment,
including embedded systems; where this difference is still alive and
kicking.
On 04/05/2012 02:05 PM, Hans-Peter Diettrich wrote:
AFAIR there exists a noGUI widgetset, which implements the message
processing (for Timer...) in a non-GUI application.
Last time I checked the noGUI Widget Type did not support TTimer or
Thread-generated Events (e.g. TThread.Synchronize(),
On 5 April 2012 09:38, Michael Schnell wrote:
Since years, I always advocated that it should be possible to do non-GUI
software in a decent way. But here, Lazarus is severely lacking support:
there is _no_ Widget type that allows for normal Delphi-Type event driven
programming style, without
On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 02:05 PM, Hans-Peter Diettrich wrote:
AFAIR there exists a noGUI widgetset, which implements the message
processing (for Timer...) in a non-GUI application.
Last time I checked the noGUI Widget Type did not support TTimer or
On 04/05/2012 02:37 PM, michael.vancann...@wisa.be wrote:
TThread.Synchronize works perfectly in any kind of application outside of
the LCL.
The main thread just has to call CheckSynchronize at regular intervals.
(which is what the LCL does for you).
Of course I do know this.
But regular
On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 02:37 PM, michael.vancann...@wisa.be wrote:
TThread.Synchronize works perfectly in any kind of application outside of
the LCL.
The main thread just has to call CheckSynchronize at regular intervals.
(which is what the LCL does for
On 04/05/2012 03:25 PM, Michael Van Canneyt wrote:
The LCL does just that: polling
With not embedded application (which of course is the main target for
LCL application) Latency and performance optimizing is not a real issue,
so this certainly is good enough.
But at least on Windows this
On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 03:25 PM, Michael Van Canneyt wrote:
The LCL does just that: polling
With not embedded application (which of course is the main target for LCL
application) Latency and performance optimizing is not a real issue, so this
certainly
On 04/05/2012 03:39 PM, Michael Van Canneyt wrote:
Events do not automagically appear in your application, even under
windows.
They are not interrupts.
AFAIK, in Windows, the Application main thread can call an API function
to wait for the next message. Here it uses no CPU cycles and when a
On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 03:39 PM, Michael Van Canneyt wrote:
Events do not automagically appear in your application, even under windows.
They are not interrupts.
AFAIK, in Windows, the Application main thread can call an API function to
wait for the next
On 04/05/2012 04:45 PM, Michael Van Canneyt wrote:
Exactly. That is called 'polling' windows...
...
You have a strange definition of polling.
Polling = Checking something at regular intervals.
Sorry for being tense, but what has been described (and acknowledged by
you) is _not_ doing
On Thu, 5 Apr 2012, Michael Schnell wrote:
On 04/05/2012 04:45 PM, Michael Van Canneyt wrote:
Exactly. That is called 'polling' windows...
...
You have a strange definition of polling.
Polling = Checking something at regular intervals.
Sorry for being tense, but what has been
On 05/04/12 16:15, Michael Schnell wrote:
So there is a possibility to feed user events to the queue in GTK ? If
Yes, you can add your own file descriptors for the gdk event loop to
watch. So you can have the loop wake up when there's input on a network
socket, for instance. You can add
On 04/05/2012 05:36 PM, michael.vancann...@wisa.be wrote:
Then try this:
Polling = Asking or checking something.
OK, if you want it that way, I'm with you now.
This is as opposed to 'interrupts', where you're not asking, but where
the
environment interrupts whatever you're doing and
On 04/05/2012 06:03 PM, Henry Vermaak wrote:
Yes, you can add your own file descriptors for the gdk event loop to
watch.
I did not know about this concept. Maybe this is a perfect solution. If
so, why does (or did when I checked quite a long time ago) GT2 implement
at least one additional
Am 05.04.2012 15:20, schrieb Michael Schnell:
On 04/05/2012 02:37 PM, michael.vancann...@wisa.be wrote:
TThread.Synchronize works perfectly in any kind of application outside of
the LCL.
The main thread just has to call CheckSynchronize at regular intervals.
(which is what the LCL does for
On 05/04/12 17:16, Michael Schnell wrote:
On 04/05/2012 06:03 PM, Henry Vermaak wrote:
Yes, you can add your own file descriptors for the gdk event loop to
watch.
I did not know about this concept. Maybe this is a perfect solution. If
so, why does (or did when I checked quite a long time ago)
Michael Schnell schrieb:
On 04/05/2012 04:45 PM, Michael Van Canneyt wrote:
Exactly. That is called 'polling' windows...
...
You have a strange definition of polling.
Polling = Checking something at regular intervals.
Sorry for being tense, but what has been described (and acknowledged
Graeme Geldenhuys schrieb:
On 5 April 2012 09:38, Michael Schnell wrote:
Since years, I always advocated that it should be possible to do non-GUI
software in a decent way. But here, Lazarus is severely lacking support:
there is _no_ Widget type that allows for normal Delphi-Type event driven
On 4/5/2012 20:06, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
On 5 April 2012 09:38, Michael Schnell wrote:
Since years, I always advocated that it should be possible to do non-GUI
software in a decent way. But here, Lazarus is severely lacking support:
there is _no_ Widget type
On 04/03/2012 04:26 PM, Bart wrote:
I have learned over the past years, that it makes sense to use
sepreate units (or ifdef them) for GUI (and thus possibly widgetset)
related code and pure pascal (as in: non-GUI non-LCL).
The separating GUI and business code paradigm is under permanent
Michael Schnell schrieb:
Unfortunately many projects start small and at some point get so
big that separating GUI and business code would be appropriate, but
with an advanced project, the effort is a lot harder to do.
Of course, it would always be better to do it right in the first place.
Separation is very advantages for large and/or professional projects.
separation, as you call it, is simply a good-design practice; no matter
whether the project is small or big.
I quite don't believe (allow me this simple paragon) you would mix your
winter and summer clothing in the same
On 4/3/12, Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
That's what I hoped so often with Lazarus but then yet another
peculiarity hit me. This is especially frustrating because I never use
the platform independend part of it. I only have the drawbacks but not
the benefit (yet). I just
Bart schrieb:
Your whole attitude in this thread is not very learnable.
What an arrogant attitude!
Imagine that people exist who cannot effort the time (as you propably
had/have) to spend theirs live on Lazarus only.
--
___
Lazarus mailing list
On Sun, 1 Apr 2012 16:09:22 +0200
Marco van de Voort mar...@stack.nl wrote:
On Sun, Apr 01, 2012 at 12:52:02PM +0200, Mattias Gaertner wrote:
OOP was already implemented in Borland Pascal.
AFAIK this was only the object syntax, not the class syntax. IMO
the object syntax is too limited
Martin schrieb:
Actually the basic concept of a unit is use it all or nothing.
This is not the concept of units but it seems to be a restriction of
interfaces (as I now read a bit more about them). Units were introduced
as libraries of functions and other declarations and that's the way I am
Hans-Peter Diettrich schrieb:
Many languages have problems with e.g. multi-platform issues or, in
case of Lazarus, with multiple implementations (of the widgetset),
selectable at build time. The same for (third-party) libraries, which
may or may not come with source code. That's why features
On 02/04/2012 16:51, Jürgen Hestermann wrote:
Martin schrieb:
So by using Grids, you should expect all the platform/GUI dependent
stuff to end up in your application.
I am not even aware of all the platform/GUI dependent stuff. I just
wanted to use TStringGrid types. Do I need to study
Do I need to study the whole LCL in detail to write programs with Lazarus? It
seems so.
no, you don't need indeed to study it all, but a little understanding
may help.
But how should I know that this is necessary? I used a simple unit in a
console application. And the error messages gave
Just forgot one simple thing:
If you code compiled and worked good under Delphi, that is because
Delphi is platform specific (that is, Windows specific) hence the unit
GRIDS already had its implementation completely done; and unit GRIDS in
Delphi may not be made of abstract classes at all.
On Mon, Apr 02, 2012 at 10:42:42AM +0200, Mattias Gaertner wrote:
AFAIK this was only the object syntax, not the class syntax. IMO
the object syntax is too limited to be called true OOP.
TP Object syntax was perfectly valid oop. It provided mechanisms for all
important OOP features:
Alberto Narduzzi schrieb:
You just hit the wrong unit at the wrong time; but at least now things
may begin to get easier.
That's what I hoped so often with Lazarus but then yet another
peculiarity hit me. This is especially frustrating because I never use
the platform independend part of it. I
Op 3 april 2012 07:10 heeft Jürgen Hestermann
juergen.hesterm...@gmx.de het volgende geschreven:
Alberto Narduzzi schrieb:
You just hit the wrong unit at the wrong time; but at least now things may
begin to get easier.
That's what I hoped so often with Lazarus but then yet another
Mattias Gaertner schrieb:
Each package has its own compiler options. For example the LCL units need
some flags like inlining and C style operators and some linker options.
Why isn't this simply added to the source files (compiler switches)? It
would be much easier, rock solid and would even
Mattias Gaertner schrieb:
AFAIR Turbo Pascal was pretty simple. I really liked it.
It supported only one target platform and the OOP came with Delphi.
OOP was already implemented in Borland Pascal.
Compare the compiler flags of TP and FPC. TP is a toy compared to FPC.
But what has all this
On Sun, 01 Apr 2012 11:04:23 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
Each package has its own compiler options. For example the LCL units need
some flags like inlining and C style operators and some linker options.
Why isn't this simply added
On Sun, 01 Apr 2012 11:20:49 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
AFAIR Turbo Pascal was pretty simple. I really liked it.
It supported only one target platform and the OOP came with Delphi.
OOP was already implemented in Borland Pascal.
Mattias Gaertner schrieb:
That's exactly what I did. I used Larazus to create a console
application. I then added my general purpose unit to the uses clause.
Then compile failed with an error message that had nothing to do
with my
program or unit.
A console application is for simple
On Sun, Apr 01, 2012 at 12:52:02PM +0200, Mattias Gaertner wrote:
OOP was already implemented in Borland Pascal.
AFAIK this was only the object syntax, not the class syntax. IMO
the object syntax is too limited to be called true OOP.
TP Object syntax was perfectly valid oop. It provided
On 01/04/2012 14:15, Jürgen Hestermann wrote:
Mattias Gaertner schrieb:
That's exactly what I did. I used Larazus to create a console
application. I then added my general purpose unit to the uses clause.
Then compile failed with an error message that had nothing to do
with my
program or
Jürgen Hestermann schrieb:
Compare the compiler flags of TP and FPC. TP is a toy compared to FPC.
But what has all this to do with the concept of packages? The concepts
used in TP where enough to allow arbitrary complex applications. And my
main critic about all this is, that even when new
Mattias Gaertner schrieb:
On Sun, 01 Apr 2012 11:20:49 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
AFAIR Turbo Pascal was pretty simple. I really liked it.
It supported only one target platform and the OOP came with Delphi.
OOP was already
Jürgen Hestermann schrieb:
Mattias Gaertner schrieb:
That's exactly what I did. I used Larazus to create a console
application. I then added my general purpose unit to the uses clause.
Then compile failed with an error message that had nothing to do
with my
program or unit.
A
On 4/1/2012 05:04, Jürgen Hestermann wrote:
Mattias Gaertner schrieb:
Packages allow to share ppu files. You don't have to recompile
the LCL for every project. Each package has its own directory where its
ppu files are stored.
That's the concept of units. I just wonder why this is/was not
I have my own general purpose unit with functions and procedures I often
use. There are also some routines that operate on TStringGrid types so I
had to add GRIDS to the uses clause in the interface part of this unit.
If I now write a very simple Hello World program that uses just one
simple
On Sat, 31 Mar 2012 13:51:28 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
I have my own general purpose unit with functions and procedures I often
use. There are also some routines that operate on TStringGrid types so I
had to add GRIDS to the uses clause in the interface part of
How should anybody know that this is required in this situation?
Why is the INTERFACES unit not required in the unit itself?
Grids is part of the platform independent LCLBase.
The unit 'interfaces' (i.e. package LCL) provides the
implementation.
How should I know this?
And why do I *not*
On 31-3-2012 15:08, Jürgen Hestermann wrote:
Hint: When you use Cody to add the grids unit to the uses section, it
will automatically add the LCL as dependency.
What is Cody?
http://wiki.lazarus.freepascal.org/index.php?title=Special%3ASearchsearch=codyfulltext=Search
--
Reinier Olislagers schrieb:
On 31-3-2012 15:08, Jürgen Hestermann wrote:
Hint: When you use Cody to add the grids unit to the uses section, it
will automatically add the LCL as dependency.
What is Cody?
On 31-3-2012 15:22, Jürgen Hestermann wrote:
Reinier Olislagers schrieb:
On 31-3-2012 15:08, Jürgen Hestermann wrote:
Hint: When you use Cody to add the grids unit to the uses section, it
will automatically add the LCL as dependency.
What is Cody?
On Sat, 31 Mar 2012 15:22:05 +0200, Jürgen Hestermann wrote about Re:
[Lazarus] Strange dependency of units:
http://www.ztw3.com/forum/forum_entry.php?id=114358 You answer sounds
like the Linux part ;-) Is Lazarus on the same way?
Hey! I run Gentoo Linux, so there is no step 2 on my machines
On Sat, 31 Mar 2012 15:22:05 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Reinier Olislagers schrieb:
On 31-3-2012 15:08, Jürgen Hestermann wrote:
Hint: When you use Cody to add the grids unit to the uses section, it
will automatically add the LCL as dependency.
Reinier Olislagers schrieb:
Just wanted to encourage you that there often is documentation about
concepts... even though it may not always be complete or correct.
Of course, if I *wanted* to get information about Cody I know that I
could use Google.
The question was: Do I *need* to know
Mattias Gaertner schrieb:
In the past the programs that used only parts of the LCL compiled, but
would then later fail at runtime at some strange place. Now you already
see at compile time that something is missing. That's definitely better.
Of course, you are right: It could be even worse.
On 31-3-2012 16:36, Jürgen Hestermann wrote:
Reinier Olislagers schrieb:
Just wanted to encourage you that there often is documentation about
concepts... even though it may not always be complete or correct.
Of course, if I *wanted* to get information about Cody I know that I
could use
Reinier Olislagers schrieb:
Of course, if I *wanted* to get information about Cody I know that I
could use Google.
The question was: Do I *need* to know about it to program with Lazarus?
vs
On 31-3-2012 15:08, Jürgen Hestermann wrote:
What is Cody?
Well, my question was a reaction to
On Sat, 31 Mar 2012 16:42:53 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
[...]
And the IDE has already some checks for common mistakes.
Mistake? Using a self-written unit is a mistake? Not knowing that GRIDS
requires INTERFACES is a mistake?
?
You
On Sat, 31 Mar 2012 17:04:16 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Reinier Olislagers schrieb:
Of course, if I *wanted* to get information about Cody I know that I
could use Google.
The question was: Do I *need* to know about it to program with Lazarus?
vs
On
On Sat, 31 Mar 2012 13:51:28 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
I have my own general purpose unit with functions and procedures I often
use. There are also some routines that operate on TStringGrid types so I
had to add GRIDS to the uses clause in the interface part of
Mattias Gaertner schrieb:
You made the mistake to use grids without an implementation (e.g. LCL
interfaces).
Implementation? What's this again? It's no longer enough to use a unit?
Sorry, but it seems that there is a very steep learning curve even for
former (Turbo..) Pascal programmers.
I
On Sat, 31 Mar 2012 19:41:02 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
The hint was about a tool that reduces the burden of knowing to
which package a unit belongs, search paths and dependencies.
Why is this at all necessary? I don't get it of
On Sat, 31 Mar 2012 19:41:05 +0200
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
Mattias Gaertner schrieb:
You made the mistake to use grids without an implementation (e.g. LCL
interfaces).
Implementation? What's this again? It's no longer enough to use a unit?
Sorry, but it seems
Hello,
On 2012-03-31 20:41, Jürgen Hestermann wrote:
Mattias Gaertner schrieb:
You made the mistake to use grids without an implementation (e.g.
LCL interfaces).
Implementation? What's this again? It's no longer enough to use a unit?
Sorry, but it seems that there is a very steep learning
72 matches
Mail list logo
