Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2006-08

Free Pascal widget set

20 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

As I mentioned before, I starting working on a Free Pascal widget set not relying on any large GUI libraries like Qt, GTK, etc... It uses Xlib (Linux) and GDI (Windows) directly. My second rewrite is based on the dormant fpGUI and fpGFX projects, so you can say it will become the next version of fpGUI.

Long term goal is to add it as a new widget set option in Lazarus, though the API will be developer friendly (something like Qt) so that a GUI could be created without a GUI Builder and minimal lines of code.

The fpGUI development team [ Me, myself and I ] is looking for developers willing to join this project. I have made the source available on my sever using SubVersion. The documentation will be online over the weekend. fpGUI is not yet ready for usage in a application, but is is rapidly getting there. My company has a deadline to get it at such a point before the end of the year.

For more details about the project and the ever growing todo list, point your browser at:
http://opensoft.homeip.net/fpgui/

Download the Source from:
svn co svn://opensoft.homeip.net/fpgui/trunk fpGUI svn co svn://opensoft.homeip.net/fpgfx/trunk fpGFX

Regards,
- Graeme -

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 27 lines
Hi, As I mentioned before, I starting working on a Free Pascal widget set not relying on any large GUI libraries like Qt, GTK, etc... It uses Xlib (Linux) and GDI (Windows) directly. My second rewrite is based on the dormant fpGUI and fpGFX projects, so you can say it will become the next version of fpGUI. Long term goal is to add it as a new widget set option in Lazarus, though the API will be developer friendly (something like Qt) so that a GUI could be created without a GUI Builder and minimal lines of code. The fpGUI development team [ Me, myself and I ] is looking for developers willing to join this project. I have made the source available on my sever using SubVersion. The documentation will be online over the weekend. fpGUI is not yet ready for usage in a application, but is is rapidly getting there. My company has a deadline to get it at such a point before the end of the year. For more details about the project and the ever growing todo list, point your browser at: http://opensoft.homeip.net/fpgui/ Download the Source from: svn co svn://opensoft.homeip.net/fpgui/trunk fpGUI svn co svn://opensoft.homeip.net/fpgfx/trunk fpGFX

Out of curiosity: why not use the FPC server for this ?

Michael.

memsom
to Graeme Geldenhuys
> Why not using GDI+ instead of GDI? It used FPC's windows.pp unit and whatever API's are defined in it.

GDI has a wider audiance. GDI+ is not an "out of the box" option for most legacy (i.e. prior to XP) systems.

Using GDI, it has the possibility to run under ReactOS and WINE too.

Graeme Geldenhuys
to memsom: GDI has a wider audiance. GDI+ is not an "out of the box" option for most legacy (i.e.…
memsom wrote
GDI has a wider audiance. GDI+ is not an "out of the box" option for most legacy (i.e. prior to XP) systems. Using GDI, it has the possibility to run under ReactOS and WINE too.

That's correct. The Win32 demo apps run fine under WINE. It should also be interesting to see how portable it is to mobile devices (PocketPC, etc...). Once I have the Win32 and Linux platforms covered, I would like to give PocketPC a go. I know nothing about PocketPC development at the moment though. :-(

Regards,
- Graeme -

Graeme Geldenhuys
to Alexandre Leclerc: It looks like a very nice job. I like the auto-size for translation. I wish you success…
It looks like a very nice job. I like the auto-size for translation. I

Yeah the layout managers are great!! I always liked the idea looking at Glade and Qt.

wish you success in this project. :) It might become the default widgetset of lazarus one day :)

That would be nice - consistent dialogs (button sizes and order come to mind). Baby steps though... :-) fpGUI is still far away from that dream.

Regards,
- Graeme -

Darius Blaszijk
to Graeme Geldenhuys
> It looks like a very nice job. I like the auto-size for translation. I Yeah the layout managers are great!! I always liked the idea looking at Glade and Qt.

Just a note, but the "auto-sizing" of components as depicted in the fig2. example is perfectly possible with Anchoring already. There's no need for a layout manager for that functionality.

Darius

Show quoted text 13 lines
> wish you success in this project. :) It might become the default > widgetset of lazarus one day :) That would be nice - consistent dialogs (button sizes and order come to mind). Baby steps though... :-) fpGUI is still far away from that dream. Regards, - Graeme - _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Graeme Geldenhuys
to Darius Blaszijk
Darius Blaszijk wrote 5 lines
Just a note, but the "auto-sizing" of components as depicted in the fig2. example is perfectly possible with Anchoring already. There's no need for a layout manager for that functionality. Darius

Lazarus has much better anchoring support that Delphi, I have to admit. But "auto-sizing" is just one of the things the Layout Managers do. It also aligns the components, positions them, prevents them from being clipped (setting minimum allowed size) when the form is resized, etc... All this by just creating a layout manager and inserting widgets into it.

Take a look at the attached screenshot. This is how most of the dialogs in Lazarus look to me. It is compiled with Gtk1. Most of the captions are clipped, group boxes don't align... It doesn't resize the controls when the dialog resizes. Those problems will never happen in fpGUI, no matter the language, resolution, dpi setting, etc. Yes, I have tried to recreate that exact screen using Lazarus with all its anchoring features and alignment features. I never got it to work 100% and it wasn't news is, if you don't like the Box and Grid Layouts, you can always use the Fixed Layout, which then allows you to place component anywhere without auto-align and positioning.

Regards,
- Graeme -

Krishna
to Graeme Geldenhuys: As I mentioned before, I starting working on a Free Pascal widget set not relying on any…
Graeme Geldenhuys wrote 7 lines
The fpGUI development team [ Me, myself and I ] is looking for developers willing to join this project. I have made the source available on my sever using SubVersion. The documentation will be online over the weekend. fpGUI is not yet ready for usage in a application, but is is rapidly getting there. My company has a deadline to get it at such a point before the end of the year.

Nice nice nice.

Show quoted text 8 lines
For more details about the project and the ever growing todo list, point your browser at: http://opensoft.homeip.net/fpgui/ Download the Source from: svn co svn://opensoft.homeip.net/fpgui/trunk fpGUI svn co svn://opensoft.homeip.net/fpgfx/trunk fpGFX

I have problems building the thing. Executing make in the topdir of fpGFX is exiting with an error like 'Can't find unit GFXImpl...' . fpGUI also fails to build with an error like 'Can't find unit DOM...'

Cheers,
Krishna

First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
Graeme Geldenhuys
to Krishna
Krishna wrote
I have problems building the thing. Executing make in the topdir of fpGFX is exiting with an error like 'Can't find unit GFXImpl...' . fpGUI also fails to build with an error like 'Can't find unit DOM...'

The Makefiles are still work-in-progress. I had them working a couple of weeks back, but might have broken them again. I develop using Lazarus and normally compile fpGUI and fgGFX using the packages (*.lpk files).

DOM is part of FPC located in /fcl/xml/
GFXImpl is part of fpGFX and depending on the OS it is located in /src/linux/ or /src/win32/

I have to admit, I am very new to Makefiles, but will see what happens when I try and compile it here using them. Otherwise, if you use Lazarus, compile the *.lpk files.

Regards,
- Graeme -

Krishna
to Graeme Geldenhuys
Graeme Geldenhuys wrote 14 lines
On 8/19/06, Krishna wrote: > I have problems building the thing. Executing make in the topdir of > fpGFX is exiting with an error like 'Can't find unit GFXImpl...' . > fpGUI also fails to build with an error like 'Can't find unit DOM...' The Makefiles are still work-in-progress. I had them working a couple of weeks back, but might have broken them again. I develop using Lazarus and normally compile fpGUI and fgGFX using the packages (*.lpk files). DOM is part of FPC located in /fcl/xml/ GFXImpl is part of fpGFX and depending on the OS it is located in /src/linux/ or /src/win32/

OK, now I've compiled fpGfx but the examples do not compile - helloworld's compilation exits with 'TSize... illegal qualifier etc.'

-Krishna

First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
Mattias Gaertner
to Graeme Geldenhuys: Lazarus has much better anchoring support that Delphi, I have to admit. But…
Show quoted text 18 lines
On 8/18/06, Darius Blaszijk wrote: > Just a note, but the "auto-sizing" of components as depicted in the > fig2. example is perfectly possible with Anchoring already. There's > no need for a layout manager for that functionality. > > Darius Lazarus has much better anchoring support that Delphi, I have to admit. But "auto-sizing" is just one of the things the Layout Managers do. It also aligns the components, positions them, prevents them from being clipped (setting minimum allowed size) when the form is resized, etc... All this by just creating a layout manager and inserting widgets into it. Take a look at the attached screenshot. This is how most of the dialogs in Lazarus look to me. It is compiled with Gtk1. Most of the captions are clipped, group boxes don't align... It doesn't resize the controls when the dialog resizes.

Right. This dialog is not using all LCL abilities.

Show quoted text 9 lines
Those problems will never happen in fpGUI, no matter the language, resolution, dpi setting, etc. Yes, I have tried to recreate that exact screen using Lazarus with all its anchoring features and alignment features. I never got it to work 100% and it wasn't easy at all. Good news is, if you don't like the Box and Grid Layouts, you can always use the Fixed Layout, which then allows you to place component anywhere without auto-align and positioning.

yes, both approaches have their pros and cons. The rule based Box/Grid layout is never overlapping, but more work to setup and is more difficult to change. While the 'fixed' layout is quite the opposite: Easy to learn, easy to setup, easy to change and easily overlaps. The never overlapping feature is important for platform/theme independent software, while the other approach is more comfortable for the rapid application goal.
The LCL has already Boxes and simple Grids. Complex Grids are missing. You can use the autosizing properties to prevent overlapping, but then you loose the ability to easily change the layout. I think, best would would be the 'fixed' layout editing plus automatic anti overlapping and some properties to fine tune the automatic. Delphi has Scaling, which is easy to implement, but does not work for different languages.
It should more work like: If a control overlaps, then the overlapped controls must be moved and maybe the parent enlarged.

Mattias

Krishna
to Cesar Romero
Cesar Romero wrote 7 lines
Why not wxWidgets? Linux map to GTK - GTK 2.0 alread done Windows to Native widget set Mac to Cocoa Serious, I still dont undertande why not, is a licence issue?

Too many layers perhaps... pascal -> wx -> gtk2 -> xlib

Also the need to setup message maps which are plain ugly. Object Pascal's bound method pointers rock!

Cheers,
Krishna

First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
Michael Van Canneyt
to Cesar Romero: Why not wxWidgets? Linux map to GTK - GTK 2.0 alread done Windows to Native widget set…
Cesar Romero wrote 6 lines
Why not wxWidgets? Linux map to GTK - GTK 2.0 alread done Windows to Native widget set Mac to Cocoa Serious, I still dont undertande why not, is a licence issue?

Because no-one has started it yet.

And on Linux, I think it would be a very bad choice indeed:

- LCL
- Pascal import (wxWidgets is C++, and cannot be used directly)
- wxWidgets
- GTK
- X11

That is 4 libraries on top of X !

Graeme's stuff is directly on top of X, which means 3 libraries less.
- Faster.
- Less resource usage.
- No workarounds for different quircks of different libraries

Michael.

Jeff Pohlmeyer
Why not wxWidgets?

I'm not too familiar with wxWidgets, but
the headers sure look like C++ to me.

- Jeff