fpGUI Toolkit v1.0 release for FPC 2.6.2

[Graeme]

Are you going to release the cross platform installer as open source?

Yes, that is the plan.

The installer is based on the specifications (not code) of  the Loki Installer, which was used by Loki Games for Quake, SimCity4000, Age of Empires etc for Linux, the Kylix installer by Borland, or the current ATI/AMD proprietary graphics driver installer by AMD.

Here is an old screenshot of where we converted the Kylix 3 setup to use our installer instead.
  http://opensoft.homeip.net/~graemeg/installer.png

We plan to support a GUI and Console installer in one, single file deployment (eg: install.exe) etc. The nice thing of using fpGUI, is that because we don't have 3rd party library requirements, you don't need Java, Qt, GTK or .NET simply to run the installer. fpGUI is also very good at backwards compatibility - current apps normally have no problem running on 10+ year old Linux distros, Windows 98 etc.

[Graeme]

As far as I can tell (Win8 64bit, WinXp SP3, openSUSE 12.4), it works.

Thanks for testing.

However, the widget sets are not truly native.

It was never the design goal of fpGUI to look native. It was designed to look and behave consistent across platforms. Saying that, fpGUI has theme support, so you can make your widgets look as pretty, ugly or native as you like. I have a bitmap based theme where it makes our apps look exactly like Win XP, I am also working on a "almost" OSX Mountain Lion theme (see the AggPas Canvas demo screenshot). So be creative! 

I did get a request this week for fpGUI to read current system / theme colors. Windows was easy to support, but once again GTK2, GTK3 and Qt are tricky. I'm also planing on creating a fpGUI Config application, where you can define fonts, color etc, and it can be applied (optionally) to all your fpGUI based apps at runtime (not just compile time). This should give end-users more control over the look, without hard-coding it into the app. Though most fpGUI apps already support the --style runtime parameter to choose different themes.

[Fred vS]

We needed to be able to deploy on Linux and Windows, and our franchisees needed to be able to run a Linux and Windows system side by side, without the user interface of our applications looking different. LCL couldn't do that - and to a large extend still can't.

This is exactly the main bemol i have seen with Lazarus project. ( and that i never have dare say  ).
For Linux you can choose or Qt or Gtk2, for Windows win32, for Mac Carbon. All that widget set are really very different.

I develop (also) sharewares for many platforms and it is the reason why i try to use a minimum of the components ( in fact i use only the files/directory dialogs and stringgrids). All the button that i use are designed by my self ( no Tbutton ) so all buttons seems equal on each platform.

But now that i discover the fpGUI-bomb, time is changing...

Does it exist already a  TfpGUI-files/directory dialogs and TfpGUI-stringgrid ?

PS : im very impresed and excited by this TfpGUI-treasure...

[Graeme]

I develop (also) sharewares for many platforms and it is the reason why i try to use a minimum of the components ( in fact i use only the files/directory dialogs and stringgrids). All the button that i use are designed by my self ( no Tbutton ) so all buttons seems equal on each platform.

Sounds like fpGUI might be a good fit for you then.

Does it exist already a  TfpGUI-files/directory dialogs and TfpGUI-stringgrid ?

Yes, and much more.

Here is an old list of components implemented in fpGUI. Currently there are even more components  implemented.

Code: [Select]

Available components (and growing):

    Button (with image and flat look and grouping support)
    Label
    Bevel
    Panel
    Group Box
    Radio Buttons
    Check Boxes
    Track Bar (aka Slider)
    Track Bar Extra (variation in look and function of standard track bar)
    Page Control (aka Tab Control)
    List Box
    Color List Box (with predefined color schemes)
    Scrollbars
    Memo
    Forms (windows): Normal, Modal and Popup.
    Dialogs
        ShowMessage()
        Font Selection dialog
        File Open...
        File Save As...
        Directory Select
        Color Select
        About Dialog
        Message Dialog (info, question, error, general)
        Input/Prompt dialog
        New Directory dialog
        Database Login dialog
    Text Edit
    Currency Edit
    Integer Edit
    Float Edit
    Combo Box (aka Choice List)
    Edit Combo Box
    Grids (aka Tables)
        Base Grid
        Custom Grid
        Draw Grid
        String Grid
        File Grid
    Progress Bar
    List View (partially implemented)
    Main Menu bar and Popup Menus
    Treeview
    Calendar control
    Calendar Combo Box
    Gauge (pie, needle, horizontal, vertical, text and dial)
    Splitter
    Color Wheel
    Value Bar (normally used with color wheel)
    TextEdit (something like SynEdit but still work-in-progress)
    Splitter
    Basic Theme/Style manager (Windows 2000 is currently the default style used)
    Animation control (something like animated gifs)
    HyperLink label
    MRU (most recently used files) Manager
    DBLabel (just as a demo that DB components can be created)
    Spin Edit
    Spin Edit Float
    Hint window (customizable including drop shadow)


[itmitica]

Well, for me it's a huge minus.

For me, fpGUI hinders the user experience, dare I say, while LCL does well when it doesn't try to dictate to the user by tying to steal control from the platform.

By not being native fpGUI faults the user while trying to apply a cross-platform corporate symmetry.

LCL strides to respect users and platforms, while fpGUI confines itself with its rigidity within its own limits.

Take a look at a fpGUI interface on a larger resolution with a larger DPI. Not a pleasant experience, not for me anyway.

--
Mitică

[Fred vS]

Here is an old list of components implemented in fpGUI. Currently there are even more components  implemented.

Ooops, mama mia, all what i need 

For me, fpGUI hinders the user experience, dare I say, while LCL does well when it doesn't try to dictate to the user by tying to steal control from the platform.

Hum, it seems that exists a battle between LCL vs fpGUI ( i have to be prudent what i say  )

Take a look at a fpGUI interface on a larger resolution with a larger DPI

With my way of develop ( using bitmap for lots of visual components ) it is really important that bitmap images are looking well.

So, i gonna try that fpGUI widgetset, sure you gonna see me back with my impressions...

[Fred vS]

Hello.

Have installed the package fpGUI package : OK

Done as said in readme.txt :

<fpGUI dir>/src/gui ⇒ lazarus/lcl/interfaces/fpgui/gui
<fpGUI dir>/src/corelib ⇒ lazarus/lcl/interfaces/fpgui/corelib
<fpGUI dir>/src/VERSION_FILE.inc ⇒ lazarus/lcl/interfaces/fpgui/VERSION_FILE.inc

Compiled the designer and assign as external tool.

Then i do :

1) from Lazarus : Open File > fpgui/uidesigner/test/tabsheet_design.lpi : OK

2) open with fpui-designer : tabtest.pas : OK, i see the form and component in it 

3) from Lazarus : Run > Compile :

tabsheet_design.lpr(9,12) Fatal: Can not find unit fpgfx used by tabsheet_design.

 

What is wrong ?

PS : If you explain me, i gonna do a wiki for dummies like me :
How to create your first 100 % pure FPC application with fpGUI 

[Graeme]

By not being native fpGUI faults the user while trying to apply a cross-platform corporate symmetry.

Such statements always makes me laugh. Lets be realist, if the person that pays me to develop their app wants pink polka dots on their user interface, then they WILL get pink polka dots. Who are you, me, some OS or some open source project to dictate to the paying customer what he or she may or may not get.

LCL and fpGUI cater for different needs - simple as that.

On a side note:
Web Apps - no native look (yet millions of Internet users have no problem with that) , Qt (most popular gui toolkit around) - not a native toolkit - all custom drawn, Microsoft Office (most popular office suite) - lots of custom components, Media Players - lots and lots of custom components, Mobile Devices - lots of non-native components and apps.

People and companies want their products to stand out above the rest, that is why Microsoft makes Office, Visual Studio, IE etc look different to the rest of Windows. Same goes for Mac OS X. It's all about branding! LCL stifles this, and that is why I was asked to develop fpGUI (at least that was one of many reasons).

Take a look at a fpGUI interface on a larger resolution with a larger DPI.

That depends on the app. Our commercial apps scale perfectly with DPI changes, but we added that functionality ourselves - it doesn't come as standard with fpGUI yet. Same applies to LCL. Lazarus IDE  (compiled for GTK2), among many other apps, don't scale well on my system either.

Bottom line... if fpGUI doesn't suite your needs, simply don't use it.

[Fred vS]

Graeme, im totally by your side and if i had discover fpGUI before, sure i had work on it.

I respect the LCL vision, but you must agree that many times widget-set use C libraries and C headers for that than really pure pascal libraries.

Graeme i really appreciate what you do and trust me, you get a new fan.

I have try a other example : fpGUI/examples/gui/splashscreen/test.lpi.

This one compiles and runs. 
Hum, the size of binary ( 6.4 megas ) is almost = with Qt or GTK2 ( is it normal ?)

[Graeme]

Done as said in readme.txt :
<fpGUI dir>/src/gui ⇒ lazarus/lcl/interfaces/fpgui/gui
...snip...

Those instructions are not needed for pure fpGUI apps. Those instructions are for LCL-fpGUI, something I don't really develop or support. Those instructions are also out of date for Lazarus 1.1.

If you are using Lazarus IDE, all you need to do is open the fpgui_toolkit.lpk package in the fpgui/src/corelib/(x11 or gdi)/ where x11 is for Linux, FreeBSD, Solaris etc, and gdi is for Windows or WinCE.  That will let Lazarus IDE know where to find fpGUI. Then simply open any of the fpgui/examples/ projects and click Run.

3) from Lazarus : Run > Compile :
tabsheet_design.lpr(9,12) Fatal: Can not find unit fpgfx used by tabsheet_design.

Wow, are those still in there! The fpgui/uidesigner/test/ directory was not meant to be runnable apps, but simply test cases (from years ago) for the form designer. I'll delete them immediately from the repository - thanks for bringing this to my attention.

If you want to look at examples, look at the <fpgui>/examples/ directory - that is what they are there for. The 'gui' directory contains more simple and to the point examples. The 'apps' directory contains slightly bigger apps (some even useful like nanoedit or the debugserver), and the 'corelib' examples tests some core framework functionality.

[Fred vS]

Yep Graeme, all ok now    (the debug info options where enabled in the option project  )

Perfect, now the binary is only 1.4 mega, whaow.

Im totally converted.

Lots of congratulations. 

[EDIT]

If you want to look at examples, look at the <fpgui>/examples/

Super, all are working for me 

[Graeme]

...many times widget-set use C libraries and C headers for that than really pure pascal libraries.

There are no technical reasons that say gui toolkits must be implemented in C - they can be implemented in COBOL for that matters. C/C++ based toolkits are popular simply because there are so many more damn C/C++ programmers out there.

> I have try a other example : fpGUI/examples/gui/splashscreen/test.lpi.

All fpgui/example/* projects should compile and run without problems. The only trick one is the core/aggcanvas/ example that needs an extra compiler define enabled - but AggCanvas is after all an experimental feature in v1.0 release.

Hum, the size of binary ( 6.4 megas ) is almost = with Qt or GTK2 ( is it normal ?)

The same old answer as for LCL apps.... Go to "Project -> Compiler Options" and then disable debugging, enable smartlinking, add level 2 opimisation, and enable strip debug symbols. With those changes, here on my 64-bit FreeBSD, the splashscreen demo executable ends up 1.4Mb in size. On a 32-bit system in will probably be around the 1Mb range. That's considerably smaller than what LCL will give you.

Code: [Select]

[splashscreen (develop)]$ ls -lh
total 473
-rw-r--r--  1 graemeg  graemeg     2k 12 Apr 14:01 commands.pas
-rw-r--r--  1 graemeg  graemeg    48B 12 Apr 14:01 extrafpc.cfg
-rw-r--r--  1 graemeg  graemeg   5.2k 12 Apr 14:01 frm_main.pas
-rw-r--r--  1 graemeg  graemeg   2.4k 12 Apr 14:01 frm_splashscreen.pas
-rwxr-xr-x  1 graemeg  graemeg   1.4M 22 Apr 23:28 test
-rw-r--r--  1 graemeg  graemeg   344B 22 Apr 23:23 test.compiled
-rw-r--r--  1 graemeg  graemeg   2.3k 22 Apr 23:23 test.lpi
-rw-r--r--  1 graemeg  graemeg   690B 12 Apr 14:01 test.lpr
-rw-r--r--  1 graemeg  graemeg   1.1k 22 Apr 23:23 test.lps
drwxr-xr-x  2 graemeg  graemeg    14B 22 Apr 23:23 units

I consider examples or demos as meant to be studied (debug, step through code etc) - so there is no benefit in enabling optimisation for them. If I create "release"  binaries (like for DocView or our commercial products), then I obviously strip all debugging support, and enable lots of compile optimisations.

Unfortunately Lazarus IDE doesn't make switching build modes (Debug, Release etc) very easy - other IDE's do a much better job. Luckily fpGUI is IDE independent. ;-)

[Fred vS]

With those changes, here on my 64-bit FreeBSD, the splashscreen demo executable ends up 1.4Mb in size.

PS : Look at my earlier post 

[Fred vS]

many times widget-set use C libraries and C headers for that than really pure pascal libraries.

I think you did not understand. It seems to me that Qt and GTK widget-set for Lazarus are in fact only linkers to C libraries ( for example Qt4pas ), not really real pascal widget-set.

Fortunately there is fpGUI, proud to be pascal.

[jmpessoa]

Code: [Select]

Available components (and growing):
    Button (with image and flat look and grouping support)
    Label
    Bevel
    Panel
    Group Box
    Radio Buttons
    Check Boxes
    Track Bar (aka Slider)
    Track Bar Extra (variation in look and function of standard track bar)
    Page Control (aka Tab Control)
    List Box
    Color List Box (with predefined color schemes)
    Scrollbars
    Memo
    Forms (windows): Normal, Modal and Popup.
    Dialogs
        ShowMessage()
        Font Selection dialog
        File Open...
        File Save As...
        Directory Select
        Color Select
        About Dialog
        Message Dialog (info, question, error, general)
        Input/Prompt dialog
        New Directory dialog
        Database Login dialog
    Text Edit
    Currency Edit
    Integer Edit
    Float Edit
    Combo Box (aka Choice List)
    Edit Combo Box
    Grids (aka Tables)
        Base Grid
        Custom Grid
        Draw Grid
        String Grid
        File Grid
    Progress Bar
    List View (partially implemented)
    Main Menu bar and Popup Menus
    Treeview
    Calendar control
    Calendar Combo Box
    Gauge (pie, needle, horizontal, vertical, text and dial)
    Splitter
    Color Wheel
    Value Bar (normally used with color wheel)
    TextEdit (something like SynEdit but still work-in-progress)
    Splitter
    Basic Theme/Style manager (Windows 2000 is currently the default style used)
    Animation control (something like animated gifs)
    HyperLink label
    MRU (most recently used files) Manager
    DBLabel (just as a demo that DB components can be created)
    Spin Edit
    Spin Edit Float
    Hint window (customizable including drop shadow)

What about PaintBox?

Thanks!