Graeme Geldenhuys schrieb:
As mentioned above, *every* dragmanager must have handles for all
involved components. An OS-wide dragmanager can only use OS-wide
handles, e.g. those of the OS-wide window manager.
Lets take Windows OLE drag-n-drop protocol as an example. It needs the
window
Lets agree to disagree, otherwise this back-and-forth messaging will go
on forever.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
--
___
Lazarus mailing list
On Mon, 10 Jan 2011 14:20:47 +0100 (CET), wrote:
This is not correct. People do strive to 100% the same everywhere.
But the 100% the same working on all platforms is hard to reach,
and takes time, it is an ambitious target. Rome also wasn't built on
a
day.
I don't think that 100% the same
Graeme Geldenhuys schrieb:
The determination of a closer target (e.g. control) is up to the
application or library, that manages the layout of a window. Every
application or library can freely define their own handles for every
Try and implement your own GUI toolkit, and we talk again.
On Thu, 2011-01-13 at 17:32 +0100, Hans-Peter Diettrich wrote:
* XDND protocol requires mouse enter, exit and window properties to
correctly get a source or target of a drag action. X11 Window
handles are required for this.
* Windows OLE drag-n-drop protocol requires window
Op 2011-01-09 20:24, Hans-Peter Diettrich het geskryf:
Where do you see problems?
The determination of a closer target (e.g. control) is up to the
application or library, that manages the layout of a window. Every
application or library can freely define their own handles for every
Try
Raving on...
IMHO, in a perfect world the API between the GUI-generating part of the
said Object Pascal layer (bad name ;-) ) and the Widget Set depending
part of the Widget Type code, would be a just bi-directional stream of
propriety codes (see Martin's ifi project). This would make
On 01/05/2011 11:39 PM, Graeme Geldenhuys wrote:In addition to nano-X
you might want to take a look at Wayland, too:
http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
-Michael
--
___
Lazarus mailing list
Op 2011-01-11 12:19, Michael Schnell het geskryf:
On 01/05/2011 11:39 PM, Graeme Geldenhuys wrote:
In addition to nano-X you might want to take a look at Wayland, too:
http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
I'm looking forward to testing Wayland (apparently Ubuntu
On 01/11/2011 12:23 PM, Graeme Geldenhuys wrote:
... like Mac ...
Interesting ! Does Mac not use X ? What do they use ?
Android does not use X, but (what ???)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Op 2011-01-11 13:41, Michael Schnell het geskryf:
On 01/11/2011 12:23 PM, Graeme Geldenhuys wrote:
... like Mac ...
Interesting ! Does Mac not use X ? What do they use ?
They have their own proprietary windowing server called Quartz or
something like that. OS X does ship with X11 support
Darius Blaszyk wrote:
FPC and Lazarus are, by and large, pretty simple to build. Middleware such as
SDL can be far more difficult because it can turn out to have a cascade of
requirements, and in the past I've found things like TrueType to be
particularly painful.
Hi Mark,
Can you explain
On 01/09/2011 11:44 AM, Michael Van Canneyt wrote:
I think it makes more sense to skip SDL and directly use the linux
framebuffer.
Someone might want to use SDL controls together with Lazarus generated
controls.
A friend of mine did this (using Delphi and later - as he did not get it
On 01/09/2011 03:45 PM, Darius Blaszyk wrote:
This is also the reason why I started on a GLut/OpenGL backend for
fpGUI. In the last weeks it has reached a point that some examples
already work perfectly.
So can we expect to - finally - see a lot new and fully functional (form
designer and
On Mon, 10 Jan 2011, Michael Schnell wrote:
On 01/09/2011 03:45 PM, Darius Blaszyk wrote:
This is also the reason why I started on a GLut/OpenGL backend for fpGUI.
In the last weeks it has reached a point that some examples already work
perfectly.
So can we expect to - finally - see a lot
On Jan 10, 2011, at 11:52 AM, Michael Schnell wrote:
On 01/09/2011 03:45 PM, Darius Blaszyk wrote:
This is also the reason why I started on a GLut/OpenGL backend for fpGUI. In
the last weeks it has reached a point that some examples already work
perfectly.
So can we expect to - finally
On 01/10/2011 12:00 PM, Darius Blaszyk wrote:
I added a new backend to fpGUI not to lazarus.
I see. Thanks for the clarification. Unfortunately a full integration
for fpGUI into Lazarus seems like a not easy task, so the other possible
Widget types I mentioned can't benefit from this :( .
On Jan 10, 2011, at 12:12 PM, Michael Schnell wrote:
On 01/10/2011 12:00 PM, Darius Blaszyk wrote:
I added a new backend to fpGUI not to lazarus.
I see. Thanks for the clarification. Unfortunately a full integration for
fpGUI into Lazarus seems like a not easy task, so the other possible
Michael Schnell wrote:
On 01/09/2011 11:44 AM, Michael Van Canneyt wrote:
I think it makes more sense to skip SDL and directly use the linux
framebuffer.
Someone might want to use SDL controls together with Lazarus generated
controls.
A friend of mine did this (using Delphi and later -
On 01/10/2011 12:15 PM, Darius Blaszyk wrote:
Is that so? I always thought it was a matter of resources.
Yep. I feel that a major consolidation of the many incarnations of the
Widget Type code is essential to enable the (then hopefully a lot
easier) creation of more Widget Types like fully
Op 2011-01-10 13:12, Michael Schnell het geskryf:
I see. Thanks for the clarification. Unfortunately a full integration
for fpGUI into Lazarus seems like a not easy task,
On the contrary, I think implementing LCL-fpGUI widgetset in Lazarus
would be the easiest widgetset from the lot (WinAPI,
On 01/10/2011 12:39 PM, Graeme Geldenhuys wrote:
I think implementing LCL-fpGUI widgetset in Lazarus
would be the easiest widgetset from the lot
Yep, but the API between the no-Widget-Type depending LCL parts and the
Widget set seems quite complex (using some kind of registration for the
Op 2011-01-10 13:57, Michael Schnell het geskryf:
Yep, but the API between the no-Widget-Type depending LCL parts and the
Widget set seems quite complex
Well that is all LCL internal design stuff and nothing related to fpGUI.
But yes, the LCL internals are rather daunting when you haven't
2011/1/10 Graeme Geldenhuys graemeg.li...@gmail.com:
Op 2011-01-10 13:57, Michael Schnell het geskryf:
Yep, but the API between the no-Widget-Type depending LCL parts and the
Widget set seems quite complex
Well that is all LCL internal design stuff and nothing related to fpGUI.
But yes, the
On Mon, 10 Jan 2011, Graeme Geldenhuys wrote:
Op 2011-01-10 13:12, Michael Schnell het geskryf:
I see. Thanks for the clarification. Unfortunately a full integration
for fpGUI into Lazarus seems like a not easy task,
On the contrary, I think implementing LCL-fpGUI widgetset in Lazarus
Op 2011-01-10 14:30, Vincent Snijders het geskryf:
It is not so odd, if you remember that the LCL was modeled after the
VCL, which has even more 'Windows-ism's.
Yes I understand the attraction towards VCL, but having the Windows API
(as an example) cloned for every widgetset of every platform
Op 2011-01-10 14:34, michael het geskryf:
Getting some controls to a more or less working condition will not be
difficult.
This is the point I was trying to make.
But going the full 100%, this is another task.
And I believe the latter is precisely the reason you abandoned LCL
Exactly.
On 01/10/2011 01:06 PM, Sven Barth wrote:
The design mediator API is only needed when one wants to design pure
non-LCL fpGUI applications. For LCL-fpGUI the normal LCL designer is
used.
Of course; but is this not what is needed to have an fpGUI widget Type
fully integrated in Lazarus,
On 01/10/2011 01:21 PM, Graeme Geldenhuys wrote:
No, that is incorrect.
Sorry for bothering you. I hope I can discuss on a more competent level
when I am able to try things out before chatting.
-Michael
--
___
Lazarus mailing list
On Mon, 10 Jan 2011, Graeme Geldenhuys wrote:
Op 2011-01-10 14:34, michael het geskryf:
Getting some controls to a more or less working condition will not be
difficult.
This is the point I was trying to make.
But going the full 100%, this is another task.
And I believe the latter is
Op 2011-01-10 15:18, Michael Schnell het geskryf:
Of course; but is this not what is needed to have an fpGUI widget Type
fully integrated in Lazarus, working at design time in the same way as
e.g. the gtk2 Widget Type works ?
No, it's not needed - just like there are no design mediator API
Op 2011-01-10 15:20, michael.vancann...@wisa.be het geskryf:
Rome also wasn't built on a day.
Do we know this for certain? I'm pretty sure aliens built the pyramids
in one day using that beam me up Scotty technology, so they might have
done the same for Rome. ;-)
Back to the point - I
On 01/10/2011 02:36 PM, Graeme Geldenhuys wrote:
No, it's not needed - just like there are no design mediator API
implementation for any of the other LCL widgetsets either.
Of course, This was my first idea, but I felt, that doing a full
completely compatible Widget Type that allows for the
On 01/10/2011 01:59 PM, Graeme Geldenhuys wrote:having the Windows API
(as an example) cloned for every widgetset of every platform is a bit
overboard I think.
Building a propriety, commonly agreed, and decently documented Object
Pascal layer in between would be a much more professional design.
2011/1/9 Zaher Dirkey parm...@gmail.com:
If you not use it, would you please make it as an option (new Platform).
Yes, it will definitely be a new platform. fpGUI would then have eg:
GDI, X11, SDL etc. as backends.
--
Regards,
- Graeme -
___
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
2011/1/9 Zaher Dirkey parm...@gmail.com:
If you not use it, would you please make it as an option (new Platform).
Yes, it will definitely be a new platform. fpGUI would then have eg:
GDI, X11, SDL etc. as backends.
I think it makes more sense
On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt mich...@freepascal.org
wrote:
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
2011/1/9 Zaher Dirkey parm...@gmail.com:
If you not use it, would you please make it as an option (new Platform).
Yes, it will definitely be a new platform.
On Jan 9, 2011, at 1:40 PM, Zaher Dirkey wrote:
On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt mich...@freepascal.org
wrote:
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
2011/1/9 Zaher Dirkey parm...@gmail.com:
If you not use it, would you please make it as an option (new
On 9 January 2011 12:44, Michael Van Canneyt wrote:
I think it makes more sense to skip SDL and directly use the linux
framebuffer.
The reasoning behind wanting to use SDL is so that I can target
multiple platforms with one backend. Maybe not ideal, but a quick fix
in supporting many
On Jan 9, 2011, at 4:16 PM, Graeme Geldenhuys wrote:
On 9 January 2011 12:44, Michael Van Canneyt wrote:
I think it makes more sense to skip SDL and directly use the linux
framebuffer.
The reasoning behind wanting to use SDL is so that I can target
multiple platforms with one backend.
2011/1/9 Darius Blaszyk :
I'm doing the development work on:
svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/
I checked out that branch and tried to compile the fpgui_toolkit.lpk
package in the 'gl' directory. Where do I find the freeglut unit
which the compiler
2011/1/9 Darius Blaszyk :
That's why we would need a common context library to be added to fpGUI in
the long term.
True. I guess if fpGUI still used a single handle per form design,
things would have been a bit easier in this regard, but that would
again make other things more difficult
On Sun, 9 Jan 2011, Graeme Geldenhuys wrote:
2011/1/9 Darius Blaszyk :
That's why we would need a common context library to be added to fpGUI in
the long term.
True. I guess if fpGUI still used a single handle per form design,
things would have been a bit easier in this regard, but that
On 9 January 2011 18:10, Michael Van Canneyt mich...@freepascal.org wrote:
Who said it was smooth ? =-)
By smooth, I meant the end-users (developers using Qt) did not notice
anything different from there perspective. Re-reading the Qt blog on
the subject, they do mention there was some black
On Sunday, 9. January 2011 17.24:03 Graeme Geldenhuys wrote:
Some days I still have mixed feeling about the move I made from
single window handle per form to window handle per widget. At the
time I was very new to X11 and GDI, and the original fpGUI code. Oh
well, what's done is done. :)
I
On 9 January 2011 18:34, Martin Schreiber wrote:
I warned you. ;-)
I did say mixed feelings, not regret. ;)
I still think both methods have their pros and cons - depending on
what you want to accomplish.
--
Regards,
- Graeme -
___
fpGUI - a
On Jan 9, 2011, at 4:47 PM, Graeme Geldenhuys wrote:
2011/1/9 Darius Blaszyk :
I'm doing the development work on:
svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/
I checked out that branch and tried to compile the fpgui_toolkit.lpk
package in the 'gl' directory.
On Jan 9, 2011, at 6:27 PM, Darius Blaszyk wrote:
On Jan 9, 2011, at 4:47 PM, Graeme Geldenhuys wrote:
2011/1/9 Darius Blaszyk :
I'm doing the development work on:
svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/
I checked out that branch and tried to compile
Michael Van Canneyt wrote:
Yes, it will definitely be a new platform. fpGUI would then have eg:
GDI, X11, SDL etc. as backends.
I think it makes more sense to skip SDL and directly use the linux
framebuffer.
Eliminate a layer. You already have direct support for all other
'platforms' that
FPC and Lazarus are, by and large, pretty simple to build. Middleware such as
SDL can be far more difficult because it can turn out to have a cascade of
requirements, and in the past I've found things like TrueType to be
particularly painful.
Hi Mark,
Can you explain what your problems
Graeme Geldenhuys schrieb:
On a side note: I still have no clue how Qt managed to
make a smooth transition from one handle per widget to single
handle per form design.
Where do you see problems?
The OS has to track some global notification targets, for e.g.
keyboard input or mouse capture.
On Thu, Jan 6, 2011 at 2:14 PM, Graeme Geldenhuys
graemeg.li...@gmail.comwrote:
The other idea was using SDL, which I
believe also works with Linux Framebuffer. The benefit of SDL is that it
will automatically work on other platforms too (eg: OS/2, Haiku, etc... any
platform that supports
Bo Berglund schrieb:
What is a widget and how does it relate to my aim of making a
cross-platform program?
IMO widgets are visual components, provided and managed by a widgetset
library. Many OS (except Linux/Unix) have native widgetsets, and allow
for user installable widgetsets as well
waldo kitty wrote:
On 1/5/2011 08:47, zeljko wrote:
On Wednesday 05 of January 2011 09:39:52 Graeme Geldenhuys wrote:
Op 2011-01-05 10:23, Bo Berglund het geskryf:
What is a widget and how does it relate to my aim of making a
cross-platform program?
widget = component
I'd say that widget
On Thursday 06 of January 2011 09:35:25 Mark Morgan Lloyd wrote:
That's OK in the context of FPC and Lazarus, but Widget and widget
set are generally-understood terms in the overall-context of unix-like
operating systems.
That's ok in any context. Widget = Visual control in any gui library (at
On 01/05/2011 02:23 PM, Bo Berglund wrote:
What about making a program for Linux? Do we have to compile the same
program in different versions for different desktop managers on Linux?
That depends on what you want to accomplish.
AFAIK, if you use the GTK or QT widget type, The program will
On 01/05/2011 02:47 PM, zeljko wrote:
I'd say that widget = TWinControl (and others derived from TWinControl of
course).
OK, but rater irrelevant regarding Lazarus.
Here *Widget Type* = TWinControl + all handling of External Events.
Handling of External (Main Thread) Events means: allowing
On 01/05/2011 11:39 PM, Graeme Geldenhuys wrote:
Adding a Linux framebuffer backend to fpGUI is already on my todo
list. I hope to get it done this year, so then fpGUI can compete on
that level too. :)
Did you consider Nano-X, too ? ( see http://microwindows.org/, download:
Op 2011-01-06 13:15, Michael Schnell het geskryf:
Did you consider Nano-X, too ? ( see http://microwindows.org/, download:
ftp://microwindows.org/pub/microwindows/microwindows-full-0.92.tar.gz,
mailing List nano...@linuxhacker.org )
Maybe you can use this instead of your own Framebuffer, as
Op 2011-01-05 10:23, Bo Berglund het geskryf:
What is a widget and how does it relate to my aim of making a
cross-platform program?
widget = component
Widget is a term often used in Linux (and maybe other OSes too) as a gui
component. Delphi calls them components, but then in Delphi how to
Bo Berglund wrote:
I am switching from Delphi7-BDS2006 on Windows to FPC-Lazarus on
Windows with the aim of making cross-platform programs.
I also want to make one program run on an embedded ARM board running
linux for ARM.
So I have read a lot of the discussions here and asked questions about
On 01/05/2011 09:44 AM, Mark Morgan Lloyd wrote:
It's not so much widgets as widget set, and it refers to whether
the intermediate layer between your program is based on Windows, Qt,
GTK (1 or 2) etc.
Widget Set is the more common term, but in Lazarus it's (mostly, e.g.
Project - Options -
Michael Schnell wrote:
On 01/05/2011 09:44 AM, Mark Morgan Lloyd wrote:
It's not so much widgets as widget set, and it refers to whether
the intermediate layer between your program is based on Windows, Qt,
GTK (1 or 2) etc.
Widget Set is the more common term, but in Lazarus it's (mostly,
Op 2011-01-05 13:38, Mark Morgan Lloyd het geskryf:
supports, i.e. Windows, and he's probably going to have to move onto
something like gtk v2; clearly this means that gtk etc. does have to
work on whatever ARM-based board he's chosen.
[promo hat on]
Obviously he can also move to something
Graeme Geldenhuys wrote:
Op 2011-01-05 13:38, Mark Morgan Lloyd het geskryf:
supports, i.e. Windows, and he's probably going to have to move onto
something like gtk v2; clearly this means that gtk etc. does have to
work on whatever ARM-based board he's chosen.
[promo hat on]
Obviously he can
Op 2011-01-05 14:24, Mark Morgan Lloyd het geskryf:
Yes, I was going to mention that but at present it's unclear whether
it's immediately usable from the Lazarus IDE.
fpGUI works with any IDE or editor - their are no dependencies to a
specific IDE.
If it is not, since Bo is
talking about
Graeme Geldenhuys wrote:
Op 2011-01-05 14:24, Mark Morgan Lloyd het geskryf:
Yes, I was going to mention that but at present it's unclear whether
it's immediately usable from the Lazarus IDE.
fpGUI works with any IDE or editor - their are no dependencies to a
specific IDE.
Right, so you're
On Wed, 05 Jan 2011 13:05:26 +, Mark Morgan Lloyd
markmll.laza...@telemetry.co.uk wrote:
Graeme Geldenhuys wrote:
Op 2011-01-05 14:24, Mark Morgan Lloyd het geskryf:
Yes, I was going to mention that but at present it's unclear whether
it's immediately usable from the Lazarus IDE.
fpGUI
On 05/01/11 13:23, Bo Berglund wrote:
The embedded card is a touch panel from Technologic Systems
(http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#),
which runs an embedded version of Debian Linux, I believe.
If it supports GTK (what is that?) or not I don't know but I
Op 2011-01-05 15:05, Mark Morgan Lloyd het geskryf:
Right, so you're saying that it's not integrated with Lazarus to the
same extent that the LCL is. If that is the case I'm not sure that it's
going to be a painless option for Bo.
Define integrated? Here I have registered fpGUI project
On Wednesday 05 of January 2011 09:39:52 Graeme Geldenhuys wrote:
Op 2011-01-05 10:23, Bo Berglund het geskryf:
What is a widget and how does it relate to my aim of making a
cross-platform program?
widget = component
I'd say that widget = TWinControl (and others derived from TWinControl
Am 05.01.2011 14:23, schrieb Bo Berglund:
So basically a widget set is a definition on what kind of graphics
environment is used on the target system then?
What about making a program for Linux? Do we have to compile the same
program in different versions for different desktop managers on Linux?
On 05/01/11 13:38, Henry Vermaak wrote:
On 05/01/11 13:23, Bo Berglund wrote:
The embedded card is a touch panel from Technologic Systems
(http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#),
which runs an embedded version of Debian Linux, I believe.
If it supports GTK
Bo Berglund wrote:
Bo, I suggest that you check that your board supports GTK etc. If it
doesn't support GTK but it does have basic X graphics then fpGUI might
be the least painful option.
Back again so I could read up on this thread...
So basically a widget set is a definition on what kind
Op 2011-01-05 15:23, Bo Berglund het geskryf:
So basically a widget set is a definition on what kind of graphics
environment is used on the target system then?
Correct. As standard, Windows only has the WinAPI (GDI etc), and Delphi's
VCL is a wrapper for that API. Under Linux you have more
Henry Vermaak wrote:
On 05/01/11 13:38, Henry Vermaak wrote:
On 05/01/11 13:23, Bo Berglund wrote:
The embedded card is a touch panel from Technologic Systems
(http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#),
which runs an embedded version of Debian Linux, I
On Wed, 05 Jan 2011 16:12:46 +0200, Graeme Geldenhuys wrote:
Note though that if you are creating commercial apps with Qt, you
need to
purchase a license (+-3500 US dollars per developer - last time I
checked).
fpGUI and MSEide are free, even for commercial apps.
That must have been over a
Hi Mark,
I've got slight reservations about KDE/Qt because my experience is that
the libraries required aren't compatible with the current (Stable,
Lenny) Debian, but only with the unreleased next version (SID,
Squeeze). And SID/Squeeze uses KDE v4, which is pretty alien to
anybody used to
On 05.01.2011 16:42, Paul Breneman wrote:
Yesterday I loaded the Win32 fpGUI zip into ReactOS in VMware and it
*mostly* worked. ReactOS has some good potential as a free embedded OS
but I doubt it will ever be good enough for general desktop use.
I know this is getting off topic, but how much
Hi Paul,
On 5 January 2011 17:42, Paul Breneman wrote:
I would very much like to get MSEide set up that way and into a minimal
distro for demonstration purposes. If you have this documented somewhere
please share a link! You may already have this and I've overlooked it.
Have a look at:
On 5 January 2011 17:50, Paul Breneman wrote:
would be interesting to see how well that could be done using Lazarus and
QT. The device is a bit underpowered but using framebuffer rather than X
probably helps.
Adding a Linux framebuffer backend to fpGUI is already on my todo
list. I hope to
On 5 January 2011 14:13, Mark Morgan Lloyd
markmll.laza...@telemetry.co.uk wrote:
It should not be necessary to use a tailored image, all you need to do is
get the development package from the Debian repository which should pull in
the libraries as well.
I'd usually expect embedded vendors to
Sven Barth wrote:
On 05.01.2011 16:42, Paul Breneman wrote:
Yesterday I loaded the Win32 fpGUI zip into ReactOS in VMware and it
*mostly* worked. ReactOS has some good potential as a free embedded OS
but I doubt it will ever be good enough for general desktop use.
I know this is getting off
On 1/5/2011 08:47, zeljko wrote:
On Wednesday 05 of January 2011 09:39:52 Graeme Geldenhuys wrote:
Op 2011-01-05 10:23, Bo Berglund het geskryf:
What is a widget and how does it relate to my aim of making a
cross-platform program?
widget = component
I'd say that widget = TWinControl (and
84 matches
Mail list logo
