On 2017-12-04 09:31, Michael Schnell via Lazarus wrote:
> After mastering OOP and Object Persistence, the next thing
> developers need to conquer is how to present their business objects
> in the GUI ...
Quoted out of context. That article was part of a series on Design
Patterns published in a p
On 2017-12-05 07:06, Martin Schreiber via Lazarus wrote:
This also is your opinion, I don't think you are so absolutely right as your
statements allways sound.:-)
At least I sound good. ;-)
In MSEgui the DB-components work very well, are convenient and fast and
I'll have to take your word f
On Tuesday 05 December 2017 13:01:43 Michael Schnell via Lazarus wrote:
> On 05.12.2017 12:16, Martin Schreiber via Lazarus wrote:
> > What is wrong with TDBGrid???
>
> As I quoted, Graeme claims it's slow.
>
I doubt it. At least the MSEgui DB-grids are not slow. DB-grids get the data
from dataset
On 05.12.2017 12:16, Martin Schreiber via Lazarus wrote:
What is wrong with TDBGrid???
As I quoted, Graeme claims it's slow.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
On Tuesday 05 December 2017 09:41:30 Michael Schnell via Lazarus wrote:
>
> While for perfect performance / clearness / portability / ... , DBGrid
> supposedly should not be used in a production release, it might be very
> helpful when designing an application.
>
What is wrong with TDBGrid???
Mart
On 05.12.2017 00:50, Graeme Geldenhuys via Lazarus wrote:
DBGrid behaves slightly different to TStringGrid, and is slow.
While for perfect performance / clearness / portability / ... , DBGrid
supposedly should not be used in a production release, it might be very
helpful when designing an appl
On Tuesday 05 December 2017 00:50:19 Graeme Geldenhuys via Lazarus wrote:
> On 2017-12-02 14:48, Marcos Douglas B. Santos via Lazarus wrote:
> > I think you misunderstand me. I said "RAD is the best way to code a
> > GUI", the visual part, not the business rules.
>
> For that you just need a visual
On 2017-12-02 14:48, Marcos Douglas B. Santos via Lazarus wrote:
I think you misunderstand me. I said "RAD is the best way to code a
GUI", the visual part, not the business rules.
For that you just need a visual form designer. RAD normally entails a
whole lot else like hooking into events (in
On 01.12.2017 20:43, Graeme Geldenhuys via Lazarus 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
The article start
On Fri, Dec 1, 2017 at 5:43 PM, Graeme Geldenhuys via Lazarus
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
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 w
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
On Fri, Dec 1, 2017 at 6:49 AM, Giuliano Colla via Lazarus
wrote:
>
> I don't believe you can give a general rule. The tool must be appropriate
> for the application. The word "programming" includes an universe of non
> compatible things. Something like "mechanical design". Designing a watch is
>
On Friday 01 December 2017 09:47:04 Michael Schnell via Lazarus wrote:
> On 01.12.2017 08:22, Martin Schreiber via Lazarus wrote:
> > For me Delphi is not the best RAD environment and therefore
> > developments made with Delphi should not be used to disqualify RAD as
> > a whole.
>
> Which are ther
On Fri, Dec 1, 2017 at 5:22 AM, Martin Schreiber via Lazarus
wrote:
> On Friday 01 December 2017 08:01:06 Graeme Geldenhuys via Lazarus wrote:
>> On 2017-12-01 06:42, Martin Schreiber via Lazarus wrote:
>> > That is your opinion, my opinion is that RAD is the most productive
>> > development techn
On Fri, Dec 1, 2017 at 5:01 AM, Graeme Geldenhuys via Lazarus
wrote:
> On 2017-12-01 06:42, Martin Schreiber via Lazarus wrote:
>>
>> That is your opinion, my opinion is that RAD is the most productive
>> development technology for most of the projects if done right,
>
>
> And your last 3 words is
Il 01/12/2017 08:01, Graeme Geldenhuys via Lazarus ha scritto:
And your last 3 words is the most important part - "if done right". In
my 20+ years of using Delphi, I can count of one hand how many company
products I've seen "done right" using the RAD style approach. And I've
worked at plenty of
On 01.12.2017 08:22, Martin Schreiber via Lazarus wrote:
For me Delphi is not the best RAD environment and therefore
developments made with Delphi should not be used to disqualify RAD as
a whole.
Which are there other than Delphi and its siblings ?
-Michael
--
__
On 01.12.2017 07:42, Martin Schreiber via Lazarus wrote:
separating of GUI and business logic is perfectly possible with RAD.
Yep. But you need to apply this discipline to yourself right from start
of the project, as doing this afterwards is tedious.
Unfortunately many projects arise from slop
On Friday 01 December 2017 08:01:06 Graeme Geldenhuys via Lazarus wrote:
> On 2017-12-01 06:42, Martin Schreiber via Lazarus wrote:
> > That is your opinion, my opinion is that RAD is the most productive
> > development technology for most of the projects if done right,
>
> And your last 3 words is
On 2017-12-01 06:42, Martin Schreiber via Lazarus wrote:
That is your opinion, my opinion is that RAD is the most productive
development technology for most of the projects if done right,
And your last 3 words is the most important part - "if done right". In
my 20+ years of using Delphi, I can
On Friday 01 December 2017 00:30:05 Graeme Geldenhuys via Lazarus wrote:
> On 2017-11-30 11:46, Michael Schnell via Lazarus wrote:
> > Nonetheless, IMHO RAD is a great way to start programming, as you
> > immediately and painlessly can see (visualize) what your "business
>
> RAD should only be used
On 2017-11-30 11:46, Michael Schnell via Lazarus wrote:
Nonetheless, IMHO RAD is a great way to start programming, as you
immediately and painlessly can see (visualize) what your "business
RAD should only be used for prototyping. ie: once the prototype is done
and not needed, bin the code. And
On 30.11.2017 12:09, el es via Lazarus wrote:
It is not easy to break free from old, ... programming practices
Nonetheless, IMHO RAD is a great way to start programming, as you
immediately and painlessly can see (visualize) what your "business
logic" software does and easily set parameters an
On 29/11/17 23:02, Graeme Geldenhuys via Lazarus wrote:
> On 2017-11-28 09:02, Michael Schnell via Lazarus wrote:
>> and support for Delphi-typical RAD-style development.
>
> RAD style development is highly overrated - I wish you can see the
> mess I'm looking at (not my code). Each form are 1000
On 30.11.2017 10:04, Michael Schnell via Lazarus wrote:
e.g. a small embedded device or to allow running them as a service..
Of course another important "headless environment" is server
applications with built-in Web server or sitting behind a standard
WebServer.
-Michael
--
On 30.11.2017 00:02, Graeme Geldenhuys via Lazarus wrote:
RAD style development is highly overrated...
I do know that very exactly, been there often enough.
RAD is great to create "small" applications, but with huge projects, you
will very likely hit a limit where you wish you would not have
On 2017-11-29 13:27, José Mejuto via Lazarus wrote:
I can spend some time, again, improving LCL-fpGUI but I need the help of
somebody expert in fpGUI, as I'm not a fpGUI user at all, and one with
good skills in the LCL widget bindings internals, because the last
I'll gladly help where I can, r
On 2017-11-28 09:11, Michael Schnell wrote:
Is implementing TLabel really that hard ?
In LCL yes, because it isn't a widget in the normal sense (unlike in
fpGUI). Instead LCL uses Windows-like API calls to render what TLabel
represents. The LCL-fpGUI widgetset doesn't have all those Windows-l
On 2017-11-29 10:08, Sven Barth via Lazarus wrote:
Correct (though GTK and Qt are also rather OS independent).
The plus point of fpGUI is that when you compile LCL-fpGUI, you compile
(or could recompile) the underlying toolkit too. So bug fixes or
improvements can be applied instantly (to LCL
On 2017-11-28 09:02, Michael Schnell via Lazarus wrote:
and support for Delphi-typical RAD-style development.
RAD style development is highly overrated - I wish you can see the mess
I'm looking at (not my code). Each form are 1000's of lines long with
tons of database logic hard-coded, busin
El 27/11/2017 a las 19:59, Graeme Geldenhuys via Lazarus escribió:
Then my I suggest you take a look at the LCL-fpGUI widgetset. It has all
the basic components working (except for TLabel), and many of the other
Windows like API's and dialogs etc. It desperately needs a maintainer -
I don't ha
Am 29.11.2017 09:41 schrieb "Michael Schnell via Lazarus" <
lazarus@lists.lazarus-ide.org>:
On 28.11.2017 11:28, Sven Barth via Lazarus wrote:
Why should they? They are two completely different projects. From the LCL's
point of view fpGui is a black box like GTK, Qt or the Windows API.
OK, so in
On 28.11.2017 11:28, Sven Barth via Lazarus wrote:
Why should they? They are two completely different projects. From the
LCL's point of view fpGui is a black box like GTK, Qt or the Windows API.
OK, so in the end fpGUI *is* an external Widget set, only that it comes
more independent of the OS di
Am 28.11.2017 10:02 schrieb "Michael Schnell via Lazarus" <
lazarus@lists.lazarus-ide.org>:
On 27.11.2017 20:07, Graeme Geldenhuys via Lazarus wrote:
>
> Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI
> widgetsets get some more attention.
>
Is there any chance to unify them to
On 27.11.2017 19:59, Graeme Geldenhuys via Lazarus wrote:
(except for TLabel)
To me TLable seems like very important to allow easy "porting" of
applications from an other widget Type to fpGUI/LCL.
Is implementing TLabel really that hard ?
-Michael
--
___
On 27.11.2017 20:07, Graeme Geldenhuys via Lazarus wrote:
Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI
widgetsets get some more attention.
Is there any chance to unify them to a single Widget Type implementation
that uses a low level graphics API (without an external Widg
On 2017-11-27 19:04, Graeme Geldenhuys via Lazarus wrote:
Just so inform everybody. fpGUI has the ability to switch between "alien
windows" (only a top level window handle) or "each widget has a handle"
during compile time.
I forgot to mention, the latest stable release of fpGUI Toolkit (v1.4.x
On 2017-11-27 06:52, Sven Barth via Lazarus wrote:
The custom drawn widget set is independent of
the fpgui widgetset and completely resides inside the LCL.
It's state is also way worse than the LCL-fpGUI widgetset. It is still
in a very early Alpha state as far as I'm concerned. Either way, i
On 2017-11-26 17:32, Kostas Michalopoulos via Lazarus wrote:
Also AFAIK fpGUI doesn't use the native window system beyond the toplevel
windows, which i think would make OpenGL support and interfacing with
external stuff (e.g. calling an external library where you pass a HWND/X11
Window directly)
On 2017-11-23 02:23, Kostas Michalopoulos via Lazarus wrote:
My main motivation is wanting to get away from the modern madness of
GTK3+/Qt5+/Wayland and all that stuff and their dependencies
Then my I suggest you take a look at the LCL-fpGUI widgetset. It has all
the basic components working (
On Mon, 27 Nov 2017 19:45:42 +0200
Kostas Michalopoulos via Lazarus wrote:
>[...]
> 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,
@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
On Sun, 26 Nov 2017 19:32:21 +0200
Kostas Michalopoulos via Lazarus 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
On 26.11.2017 18:32, Kostas Michalopoulos via Lazarus wrote:
i am already working on a widget toolkit for a few years now which is
written in C ... Most of my code is LCL specific
This seems like a very peculiar combination to me.
-Michael
--
___
La
On 26.11.2017 17:13, Sven Barth via Lazarus wrote:
Lazarus already contains a custom drawn widgetset that supports X11. I
don't know its current state, but maybe it would be best to bring that
up to speed and form instead of starting a new one.
Some time ago I did play with the custom drawn Wi
On Sunday 26 November 2017 18:32:21 Kostas Michalopoulos via Lazarus wrote:
>
> Also AFAIK fpGUI doesn't use the native window system beyond the toplevel
> windows, which i think would make OpenGL support and interfacing with
> external stuff (e.g. calling an external library where you pass a HWND/
Am 26.11.2017 18:32 schrieb "Kostas Michalopoulos via Lazarus" <
lazarus@lists.lazarus-ide.org>:
@Stephane:
@Sven:
I know about fpGUI (Sven i assume you mean that), but i am already working
on a widget toolkit for a few years now which is written in C and if i'm
going to work on a custom widgetset
@Stephane:
@Sven:
I know about fpGUI (Sven i assume you mean that), but i am already working
on a widget toolkit for a few years now which is written in C and if i'm
going to work on a custom widgetset might as well make it target the one
i'm already working on which is used by some other stuff i a
Am 26.11.2017 14:23 schrieb "Kostas Michalopoulos via Lazarus" <
lazarus@lists.lazarus-ide.org>:
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
On Sunday 26 November 2017 14:53:54 Stéphane Aulery via Lazarus wrote:
> Hello,
>
> On Thu, Nov 23, 2017 at 04:23:19AM +0200, Kostas Michalopoulos via Lazarus
wrote:
> > My main motivation is wanting to get away from the modern madness of
> > GTK3+/Qt5+/Wayland and all that stuff and their depende
Hello,
On Thu, Nov 23, 2017 at 04:23:19AM +0200, Kostas Michalopoulos via Lazarus
wrote:
>
> 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 wrot
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 g
53 matches
Mail list logo
