Hello,

I’m new to FPC and researching about different GUI options available to write open-source multi-platform desktop app using FPC…

Based on what I’ve found there are mainly three options:

a) Lazarus and LCL

b) fpGUI

c) MSEgui

Afaict, a) support all three main OS-es - Linux, Mac & Windows by providing native look’n’feel although, iirc, Cocoa supprt for Mac is not finished yet.

MSEgui works on Linux and Windows, while fpGUI works on all three OS-es but on Mac support is done via X11 libs.

Now, let me say that Linux (Debian) is my native platform which I use and will develop on it, but would like to provide versions for Mac & Windows.

Does it automatically eliminates c) or there is plan to add support for Mac?

Is b)’s support for Mac via X11 good-enough or is b) more suitable, as I read somewhere, for embedded platforms?

What about learning curve of each one?

I probably do not need full power of GTK2(3) or Qt toolkit, but need some database support - app would use sqlite3 as storage backend.

Another concern is that, afaics, both b) and c) are mostly one-man project, while a) has much larger community behind.

Any advice is helpful?

Sincerely,
Gour

Gour wrote

Is b)’s support for Mac via X11 good-enough or is b) more suitable, as I read somewhere, for embedded platforms?

As I mentioned in a private email, I have written commercial software using fpGUI for the Mac. The client I worked for was not at all phased by the fact that it used the X11 support included with OSX. Neither were they bothered by the fact that it doesn't look 100% native (many of Apple's own software doesn't adhere to their own interface guidelines). My client's main concern was that the software is stable and that it works by delivering the functionality they required - which it did.

Having the same look and feel between OSX, Linux and Windows was also a plus for them, as it reduced the amount of staff training on the software.

What about learning curve of each one?

LCL and fpGUI has pretty much the same learning curve I think. MSEgui might be slightly harder. But my observations could be skewed because I came from a Delphi/Kylix background, and fpGUI and LCL is similar to those.

but need some database support - app would use sqlite3 as storage backend.

Database support is obviously supported by all three toolkits you mentioned. Database support shouldn't be tightly tied to a GUI toolkit anyway - that is just bad design.

If you have the time I suggest you take a look at another open source project called tiOPF (TechInsite Object Persistence Framework). It abstracts the data persistence (saving/loading), so you simply concentrate on designing your business objects. The tiOPF framework then takes care of the rest and allows you to switch where you store your data (XML, Firebird, MySQL, SQL Server, SQLite etc), without needing any code changes.

For displaying and interacting with data in a user interface, tiOPF uses a design pattern called Model-GUI-Mediator (MGM) and allows standard user interface widgets to become "object aware" without needing additional custom DB-aware widgets. tiOPF already supports the most frequently used widgets and has MGM mediators for Delphi's VCL and FMX, Lazarus's LCL and fpGUI.

I've personally used tiOPF for over 15 years in commercial software, and highly recommend it for Client/Server or 3-tier database development work.

http://www.tiopf.com

Another concern is that, afaics, both b) and c) are mostly one-man project, while a) has much larger community behind.

As I already explained in the Lazarus mailing list. I might be the driving force behind fpGUI, but it certainly has had many many contributions over the last 10 years.

A smaller development team doesn't make a project any less useful. eg: The Free Pascal Compiler development team is minute compared to say the Qt project. Yet I [and many others] find FPC immensely useful, and more importantly what allows us [as developers] to make a living.

Regards,
- Graeme -

The first option would be a pure Pascal one, driving either a graphical or a text-based (curses etc.) UI. However in practice I think you'll find that the majority in here who have any interest in GUI support use Lazarus.

I tend to use the FPC+Lazarus combination on (Debian) Linux targeting x86 (including -64), SPARC, PPC and sometimes ARM, MIPS is also getting there slowly. Sometimes also x86 Windows and SPARC Solaris, and other people regularly target OSX etc. There is a bit of a problem in that all of us tend to test the less popular combinations somewhat sporadically, and at present some of these really do require careful choice of compiler version and- if using Lazarus- widget set.

fpGUI and MSEgui definitely have their good points, they're lean and are only mean in self-defence :-)

Graeme, could you update us on the extent to which Lazarus or an equivalent IDE supports form design etc. for fpGUI these days?

Mark Morgan Lloyd wrote

Graeme, could you update us on the extent to which Lazarus or an equivalent IDE supports form design etc. for fpGUI these days?

I'm not sure I fully understand the question, but I'll try answering it. fpGUI was design so it doesn't dictate what development tools you need to use to work with it. For that reason the tools included with fpGUI are stand-alone tools. So you can use the UIDesigner (fpGUI Forms Designer) (or DocView) as stand-alone from a desktop icon or command line, or integrate it with any IDE or Editor that support "external tools" functionality.

eg: I develop fpGUI applications with both Lazarus IDE and MSEide. In both cases I have setup context sensitive help (via F1 key press) which launches DocView and displays the appropriate help based on the cursor position. The same is done with the UIDesigner, where I launch the form designer and load the current file using the Ctrl+Shift+F12 shortcut because both Lazarus IDE and MSEide hard-codes F12 (or used too) for its own usage.

I've done the same with my favourite text editor, EditPad Pro.

Here is some instructions on how to set this up using Lazarus, MSEide, Delphi 7 and EditPad Pro.

http://fpgui.sourceforge.net/docview_ide_integration.shtml

Even using fpGUI's UIDesigner is optional, but it does make the process of designing a form faster. The UIDesigner generates pure Object Pascal code, as if a human typed it. It doesn't use external *.lfm or *.dfm files, so the true full change history is easily seen in a code repository. This also has some other benefits like supporting multiple forms in a single *.pas unit, properties can quickly be changed directly in code (without needing to launch the Forms Designer), Searching for properties or even Search & Replace can be done on code, widgets or properties.

I hope this answers your question.

Regards,
- Graeme -

Graeme Geldenhuys

Interesting…I was looking at this page
(http://wiki.lazarus.freepascal.org/tiOPF) and wondered why there is no support for Sqlite3. :-)

I've personally used tiOPF for over 15 years in commercial software, and highly recommend it for Client/Server or 3-tier database development work.

Thanks. It’s bookmarked now.

A smaller development team doesn't make a project any less useful. eg: The Free Pascal Compiler development team is minute compared to say the Qt project. Yet I [and many others] find FPC immensely useful, and more importantly what allows us [as developers] to make a living.

Thank you very much for your input.

Sincerely,
Gour

Mark Morgan Lloyd

The first option would be a pure Pascal one, driving either a graphical or a text-based (curses etc.) UI.

Here you mean fpGUI & MSEgui?

I tend to use the FPC+Lazarus combination on (Debian) Linux targeting x86 (including -64), SPARC, PPC and sometimes ARM, MIPS is also getting there slowly. Sometimes also x86 Windows and SPARC Solaris, and other people regularly target OSX etc.

Nice set. ;)

fpGUI and MSEgui definitely have their good points, they're lean and are only mean in self-defence :-)

:-)

And fpGUI is very easy to try:
http://www.turbocontrol.com/easyfpgui.htm

No, more than anything I mean going directly to the relevant APIs. Using fpGUI etc. is a potentially-useful shortcut, particularly if their form designers are adequate.

Gour wrote

(http://wiki.lazarus.freepascal.org/tiOPF) and wondered why there is no support for Sqlite3. :-)

I can confirm that SQLite3 is supported via the SqlDB database components. That wiki page is simply a bit out of date.

Regards,
- Graeme -

Paul Breneman wrote

And fpGUI is very easy to try: http://www.turbocontrol.com/easyfpgui.htm

Ohh, this is a good one. Thanks.

Sincerely,
Gour

Graeme,

can you give a short explanation how the pattern is implemented or show a documentation link, please?

TIA,
Marc

Graeme Geldenhuys

I can confirm that SQLite3 is supported via the SqlDB database components. That wiki page is simply a bit out of date.

Thank you.

Sincerely,
Gour

Marc Santhoff wrote

can you give a short explanation how the pattern is implemented or show a documentation link, please?

Model-GUI-Mediator is a combination of the Observer and Mediator design patterns working together.

Follow the URL shown below, and view the second article from the top.

It is an introduction to Model-GUI-Mediator, but the implementation found in tiOPF goes far beyond what is covered in that article. Needless to say the one found in tiOPF is much improved, easier to use and way more powerful. The underlying idea is the same though.

http://geldenhuys.co.uk/articles/

Regards,
- Graeme -

Gour wrote

I probably do not need full power of GTK2(3) or Qt toolkit,

I would advise anyway against using LCL (Qt) on Linux at the moment. I understand its based on Qt4, and Qt4 is being dropped in favour of Qt5. At the very least, check how long your distribution will be supporting Qt4.

http://perezmeyer.blogspot.co.uk/2014/11/early-announce-qt4-removal-in-jessie1.html

I don't think you will get a complete GTK3 in the LCL either at the moment. Its 'alpha' status according to the wiki.

fpGui, while it has far fewer features, is independent of these widget sets and their major version transitions.

I suggest, check what features you need. Does fpGui have them? If not, use LCL-GTK

I have not used Lazarus for a while, but I think you can use it as an IDE, while using fpGUI as a component set. Perhaps someone can confirm?

MSE stuff has a following, but last time I looked, there wasn’t much documentation to help get started with it.

Peter

Peter wrote

I have not used Lazarus for a while, but I think you can use it as an IDE, while using fpGUI as a component set. Perhaps someone can confirm?

I believe I answered that in an earlier reply.

http://lists.freepascal.org/pipermail/fpc-pascal/2015-August/044795.html

Regards,
- Graeme -

Hi, I am the author of MSEide+MSEgui.

MSEgui works on Linux, FreeBSD and Windows. A port for OSX with X11 backend is probably doable with not much effort. I would prefer to interface to Quartz directly, such a solution needs a sponsor because of the rather big expenditure and I don't need OSX myself.
Though I often read that Mac people never will accept something which is not made and sold by Apple so a toolkit like MSEgui on Mac is useless and Apple tries to lock out "alien" solutions.

MSEide+MSEgui is no Delphi clone, so if you are experienced to work with Delphi and don't like to learn something new you probably would have a hard time with MSEide+MSEgui at the beginning.
If you don't know Delphi or you think that Delphi not necessarily is the only possible way to make a GUI toolkit and IDE, MSEide+MSEgui can be easily learned because of its orthogonal architecture and most things "simply work", also difficult things like visual form inheritance, frames and docking - BTW since many years already.
I started development of MSEide+MSEgui in 1999 and invested about 20'000 hours up to now. Because of the small team the software architecture, quality and strictness is very good. MSEgui probably is the most versatile GUI toolkit you will find on the market.
License of MSEide is GPL, license of MSEgui is LGPL with static linking exception, so you are free to fork the projects if you don't like my development direction .

I probably do not need full power of GTK2(3) or Qt toolkit, but need some database support - app would use sqlite3 as storage backend.

MSEide+MSEgui has excellent database support, please take a look in the MSEide component palette tabs 'DB', 'DBe', 'DBl', 'DBf', 'Rep' and 'ifi' . Please take the recommendation of tiOPF design patterns by Graeme with a grain of salt, it is not the only possibility to build high quality database applications and he is a little bit biased. ;-)

Please ask questions about MSEide+MSEgui on the mailing list: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Mail archive:

NNTP gateway:
nntp://news.gmane.org/gmane.comp.ide.mseide.user

Martin

That's going to be a problem. On x86 and x86-64 Jessie, my experience so far is that GTK2 doesn't work and that Qt is the only viable option.

GOK what it's like on other platforms that might not have such a well-tested Qt etc.

Peter wrote

I would advise anyway against using LCL (Qt) on Linux at the moment. I understand its based on Qt4, and Qt4 is being dropped in favour of Qt5. At the very least, check how long your distribution will be supporting Qt4.

That’s helpful hint.

I don't think you will get a complete GTK3 in the LCL either at the moment. Its 'alpha' status according to the wiki.

Another one. ;)

fpGui, while it has far fewer features, is independent of these widget sets and their major version transitions.

I must admit I’m heavily leaning towards it at the moment having some very welcome features and less bloat.

I have not used Lazarus for a while, but I think you can use it as an IDE, while using fpGUI as a component set. Perhaps someone can confirm?

Well, ability of fpGUI to use one’s preferred editor is another ’plus’.

Sincerely,
Gour

Mark Morgan Lloyd

That's going to be a problem. On x86 and x86-64 Jessie, my experience so far is that GTK2 doesn't work and that Qt is the only viable option.

That’s another ’pro’ argument to use fpGUI or MSEgui…

Sincerely,
Gour

Martin Schreiber

Hi, I am the author of MSEide+MSEgui.

Hiya!

MSEgui works on Linux, FreeBSD and Windows. A port for OSX with X11 backend is probably doable with not much effort. I would prefer to interface to Quartz directly, such a solution needs a sponsor because of the rather big expenditure and I don't need OSX myself.

I also personally do not need OSX neither I used it ever - just would like to provide, if possible, version of my app for it.

Though I often read that Mac people never will accept something which is not made and sold by Apple so a toolkit like MSEgui on Mac is useless and Apple tries to lock out "alien" solutions.

:-)

Is Windows (e.g. V10) better in this regard?

I plan to write open-source app using Linux/BSD platform so there is no comercial pressure to have Win/Mac version, just simple convenience.

MSEide+MSEgui is no Delphi clone, so if you are experienced to work with Delphi and don't like to learn something new you probably would have a hard time with MSEide+MSEgui at the beginning.

No Delphi experience at all…

I’ll check it out.

I started development of MSEide+MSEgui in 1999 and invested about 20'000 hours up to now. Because of the small team the software architecture, quality and strictness is very good. MSEgui probably is the most versatile GUI toolkit you will find on the market.

What about docs? Someone mentined lack of it.

License of MSEide is GPL, license of MSEgui is LGPL with static linking exception, so you are free to fork the projects if you don't like my development direction .

I’ll probably have to use some 3rd party C lib which is GPLV2+, so license is not a problem here.

:-)

Please ask questions about MSEide+MSEgui on the mailing list:

Will visit the place, for sure…

Thank you for your input.

At the end, after deciding to use FPC, there is no more lack of viable options which was the case before when evaluating other languages. :-)

Sincerely,
Gour

In our previous episode, Peter said:

The whole point of the LCL is that you only start worrying about widgetset when you are close to deployment, and need to do widgetset specific things.

In our previous episode, Gour said:

(don't forget to ask Martin about the language he is creating, I tried to plug some M2 features, maybe you can drive the message home :-)

(don't forget to ask Martin about the language he is creating, I tried to plug some M2 features, maybe you can drive the message home :-)

Hmm…nothing in public yet?

I believe that using FPC is giving me more confidence considering the community behind…

Sincerely,
Gour

https://gitlab.com/mseide-msegui/mselang/wikis/home

Martin

I think so.

What about docs? Someone mentined lack of it.

Some usefull links are here:
http://mseide-msegui.sourceforge.net/
Wiki:
http://wiki.freepascal.org/MSEide_&_MSEgui
Examples are here:
https://gitlab.com/mseuniverse/mseuniverse/tree/master/samples and here:
https://gitlab.com/mseuniverse/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials

and feel free to ask on the mseide-msegui-talk mailing list.

Martin

Qt4 may be deprecated but it will not be removed any time soon. Was the announcement April? No it wasn't.
Anyway the major distros will support QT4 for a long time. Right now I am using OpenSuse Tumbleweed rolling distro with KDE Plasma 5 desktop. KDE is the biggest project using QT. They still need QT4 for many applications in Plasma 5.
After many years when QT4 is removed, Lazarus LCL will already support QT5 bindings. Alpha version of the bindings already exist. The maintainer of LCL-QT, Zeljko, uses it for his own business. I am pretty sure this is a safe path for anybody.
The sentence "I would advise anyway against using LCL (Qt) on Linux at the moment" is plain FUD and nonsense.

I don't think you will get a complete GTK3 in the LCL either at the moment. Its 'alpha' status according to the wiki.

LCL-GTK3 is alpha, yes. It needs contributors. Anybody?

Juha

Hi

my two cents as a long term user of Macs, fpc and lazarus.

This is quite a twisted view, which cries for correction. Apple has put up guide lines for developers, for example the Human Interface Guidelines

(https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html#//apple_ref/doc/uid/20000957)

But there are more, for example about the application bundles and where to put preference files and similar things.

Contrary to the claim above there are plenty freeware and shareware programs, which are well received by mac users. Whether they are sold by apple or not, is not the point. iTunes from Apple, for example, has received quite some critics, because it does not really follow the guide lines and therefore feels „strange“.

Mac users have a low barrier to install and try something, but their barrier to ditch something to the trashcan is also very low. For a real Mac application without any fishy smell, i guess one needs to take the full dive and develop the interface with Xcode and use ObjectivePascal for the code. It is probably the only way to get the application into the AppStore, but i think that this is not your option.

Whether Apple locks out alien solutions is not the point, because this has been the case even before the App Store. However, you can still install and run applications, like Lazarus, alien or not ;-)

The carbon-lcl is probably the best compromise at the moment regarding features and mac-like appearance, at least until the cocoa-lcl does everything you need. Qt4-lcl is another option, but also needs quite some tweaking. For the majority of Apple users all X11-derived solutions are very alien and they are only accepted by techie nerds like me. Therefore, the question about your potential customers/users is quite important. If you have never used a Mac, it might be difficult to understand the critics of Maccies about the strange feeling and only sound arrogant. Things like the top priority of mouse activities and the corresponding user guidance and the much lower importance of application specific short keys. On the other hand a number of default short keys are expected to work. Ctrl-W for closing the active window is often missing in ported programs. But in many cases, the number of little things is so large, that the answer to the question „What is wrong?“ is „Oh my god, where should i start!“ I am surely exaggerating, but actually hoping to prepare you of what might come. There is a good chance that it is not so bad. Since you seem to have little experience with a Mac, it might be good to team up with a Maccie. Maybe try the mac-pascal mailing list.

I have put together a small utility for the conversion of the voltage from a thermocouple to temperature in lazarus. It runs on Mac OS X, Linux and windows. Besides Lazarus, i also use a Makefile for some of the tweaks. Link: https://sourceforge.net/projects/heatwizard/

MiSchi.

Schindler Karl-Michael wrote

This is quite a twisted view, which cries for correction. Apple has put up guide lines for developers, for example the Human Interface Guidelines

And even Apple can't adhere to their own HIG details. Such arguments about Mac users praising the consistency of OSX and its applications is a joke. If you want examples, use Google - it will list plenty of inconsistencies for iOS and OSX.

As for Mac users not wanting to use applications that don't blend in perfectly.... well then I guess those same users never use the Internet or any web apps either? After all, websites look "alien" on every platform and has no HIG to speak off (weird looking buttons, menus all over the place, odd animations and hover effects, modal forms etc etc). Yet everybody on any platform seems to navigate websites and web apps just fine. Personally I don't think the majority of end-users are that stupid as some people make them out to be. If they see a button (on a web page or "alien" application) they know how to use it. The same goes for all other UI widgets too. The important things is, is the application stable, and does it provide a useful function that the end-user needs.

Case in point, I wrote a commercial application for a client using fpGUI
- a 100% custom drawn toolkit. fpGUI using OSX's X11 support to run. The client didn't give a damn if the application didn't look 100% native. They only cared that the application was stable and did what they needed. In fact, they were quite happy that it looked and behaved exactly like the Linux and Windows versions because it saved them extra effort and money when training the staff using the software.

Regards,
- Graeme -

Juha Manninen wrote

when QT4 is removed, Lazarus LCL will already support QT5 bindings. Alpha version of the bindings already exist.

Well, thats good news then. I couldn't find any mention of QT5 in the wiki.

Peter.

Marco van de Voort wrote

(don't forget to ask Martin about the language he is creating, I tried to plug some M2 features, maybe you can drive the message home :-)

If I'm reading his wiki page properly, at least he's got the bit of M2 that matters- resolution of the dangling else problem- which had already been recognised as sufficiently important to be in ALGOL 68.

I think that the one thing I'd suggest to everybody is that it would be highly desirable if the dangling else fix were guaranteed to break Pascal syntax. As such end if; etc. might be a better choice.

Peter wrote

Well, thats good news then. I couldn't find any mention of QT5 in the wiki.

The QT5 binding libs can be found in section "V2.6Alpha (Qt 5.1.X)" at page http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html

In fact I recently asked in lazarus-qt list about how to test it. I guess Zeljko and Den are on holidays and will answer later.

Juha

In our previous episode, Mark Morgan Lloyd said:

I think that the one thing I'd suggest to everybody is that it would be highly desirable if the dangling else fix were guaranteed to break Pascal syntax. As such end if; etc. might be a better choice

If you start a different language, yes, the block system would be number one. Do away with oneline vs multiline blocks ambiguity in general. (and not just because of ELSE).

Second would be a different procedure-block ending from just "end;" though the M2 way of end "procedurename" is unnecessary hard to maintain. end proc; or end function would be just fine.

As usual that doesn't mean I want to micromanage. I don't have to end every block in a specific way. As usual, bounding the major problem (don't let an unterminated block spill over function bounderies) is enough.

If you want to merely extend pascal, my fav feature would be qualified vs unqualified import/export control I guesst.

You mean something like Ada?

while true loop

    if false then
        --whatever
    else
        --ditto
    end if;

end loop;

(although functions/procedures are terminated using `end <functionname>;` as well)

Extra feature: inherent concurrency support. I don't know about classes or generics, those will probably be in an newer standard. But who needs those?

I came across an odd thing in a paper about ALGOL 60 the other day: "Any character between the symbol end and the first semicolon or end or else following this end is [comment] text." I've never ploughed through the original documents and presume it's in there somewhere, but it does seem like an attractive facility.

If you want to merely extend pascal, my fav feature would be qualified vs unqualified import/export control I guesst.

In our previous episode, Ewald said:

No, that is what I considered micromanaging, and per saldo worse than what Pascal does. (IOW Pascal is a problem, but the Ada cure is worse than the problem). Ada has that tendency a lot.

The sweet spot is what Modula2 did by only adding to the end of the procedure block.

Unfortunately, Modula2 ruined it by adding the function name there so it became

procedure xxx;
begin
  ... code
end xxx;

which meant that if you renamed the function you had to modify the procedurename twice, without much added benefit. That I would want to avoid, so just "end proc;" or something similar.

Extra feature: inherent concurrency support. I don't know about classes or generics, those will probably be in an newer standard. But who needs those?

IMHO generics are more important than concurency. One can get pretty far without in language concurency and just using them as library concept. But one can't get typesafe container that way.

Gour wrote

Hum, if i may, ...

a) => for Linux and FreeBSD => needs X11 + (Gnome or KDE) + (GTK or Qt) + many other libraries.
b) + c) => for Linux and FreeBSD => needs only X11.

-----
Many thanks ;-)

I understood the principle, which is OK for now.

http://geldenhuys.co.uk/articles/

Many more articles worth reading, especially reagarding patterns. thanks a lot!

fredvs wrote

Hum, if i may, ...

Sure!

a) => for Linux and FreeBSD => needs X11 + (Gnome or KDE) + (GTK or Qt) + many other libraries. b) + c) => for Linux and FreeBSD => needs only X11.

Thank you, it confirms my conclusion that I’ll skip over a) and probably use b). ;)

Sincerely,
Gour

Hi Graeme,

Your earlier reply contains a link about docview. I was unsure how to get Lazarus to use fpgui in the first place. Anyway, its here, for anyone interested.

http://wiki.freepascal.org/fpGUI_Interface#Creating_your_first_LCL_application_with_fpGUI

Regards,
Peter

Peter wrote

I was unsure how to get Lazarus to use fpgui in the first place. Anyway, its here, for anyone interested.

Correction. Those instructions mentioned in the URL you posted is to create a LCL-fpGUI application. The LCL-fpGUI widgetset is not feature complete, and not nearly ready for real usage.

It is recommended that you create fpGUI applications using fpGUI directly (no LCL involved). For that you follow these simple steps:

Lets configure Lazarus to have a new project type: --------------------------------------------------
1. Run Lazarus and open the fpgui_toolkit.lpk package found in the fpGUI code: <fpgui>/src/corelib/[x11|gdi]/fpgui_toolkit.lpk Click "Compile".

2. Now open the IDE add-on package, compile and install. Open <fpgui>/extras/lazarus_ide/fpgui_ide.lpk
Click "Compile" & "Install".
Lazarus will rebuild and restart itself.

Now to create a fpGUI application:
----------------------------------
1. Run Lazarus

2. Select "Project -> New Project..." and select "fpGUI Toolkit Application".

All done, you have create your first fpGUI Toolkit application using Lazarus IDE as your editor! :)

I also recommend you integrate the fpGUI UIDesigner (forms designer) and DocView as external tool items in Lazarus IDE. It is just a convenience, not a requirement. For that you can follow the instructions found in this page. The page describes the process for docview, but the same process is used for the UIDesigner.

http://fpgui.sourceforge.net/docview_ide_integration.shtml

For more available options see the INSTALL.txt file found in <fpgui>/docs/ directory.

Regards,
- Graeme -

Graeme Geldenhuys wrote

1. Run Lazarus and open the fpgui_toolkit.lpk package found in the fpGUI code: <fpgui>/src/corelib/[x11|gdi]/fpgui_toolkit.lpk Click "Compile".

It was brought to my attention that the above is somewhat ambiguous.

I meant for the text [x11|gdi] to mean "x11" or "gdi" depending on your platform.

So if you run Windows, open the following package: <fpgui>\src\corelib\gdi\fpgui_toolkit.lpk

And if you run any X11 or OSX system, open this packages instead: <fpgui>/src/corelib/x11/fpgui_toolkit.lpk

Regards,
- Graeme -

i found that out ;)

thanks for the clarification!

On Uto, 2015-08-04 at 16:35 +0000, Mark Morgan Lloyd wrote:

I must admit that I spent some time exploring some other possible options in regard to the choice of programming language to be used for my desktop GUI project, just to come to the conclusion, even stronger than before, that FPC is the best option. :-)

That's going to be a problem. On x86 and x86-64 Jessie, my experience so far is that GTK2 doesn't work and that Qt is the only viable option.

I've started working with Object Pascal Handbook to learn the language, but still have to make definite choice in regard to GUI...so I wonder what did you find problematic with GTK2 on Debian? (I'm using openSUSE TumbleWeed.)?

Sincerely,
Gour

-- 
Even a man of knowledge acts according to his own nature, for everyone follows the nature he has acquired from the three modes. What can repression accomplish?

Saša Janiška wrote

On Uto, 2015-08-04 at 16:35 +0000, Mark Morgan Lloyd wrote: I must admit that I spent some time exploring some other possibleoptions in regard to the choice of programming language to be used formy desktop GUI project, just to come to the conclusion, even strongerthan before, that FPC is the best option. :-) > That's going to be a problem. On x86 and x86-64 Jessie, my experience> so far is that GTK2 doesn't work and that Qt is the only viable> option. I've started working with Object Pascal Handbook to learn the language,but still have to make definite choice in regard to GUI...so I wonderwhat did you find problematic with GTK2 on Debian? (I'm using openSUSETumbleWeed.)?

GTK2 has problems on Debian Jessie.

Mark Morgan Lloyd wrote

Saša Janiška wrote: > On Uto, 2015-08-04 at 16:35 +0000, Mark Morgan Lloyd wrote:

Hi,

Unfortunately, the original poster didn't mention that he wasn't subscribed to the list, but I'd suggest keeping him in Cc: of potential answers.

As an additional comment, please note that discussions about general advantages and disadvantages/issues of external GUI libraries and/or their implementation on a particular platform should be better discussed on the fpc-other list. Obviously, advantages and disadvantages specifically related to use of these libraries with FPC are perfectly on topic in this list. I mention this because it wasn't clear from the question of the original poster which of the cases he was asking about.

Thanks

Tomas
(one of FPC mailing lists moderators)

Mark Morgan Lloyd wrote

GTK2 has problems on Debian Jessie.

But that is not problem with Lazarus itself, right?

Sincerely,
Gour

I'm the original poster (merged two of my email addresses into new one) and I'm subscribed to the list, although posting from Gmane or do I miss something?

As an additional comment, please note that discussions about general advantages and disadvantages/issues of external GUI libraries and/or their implementation on a particular platform should be better discussed on the fpc-other list.

I did explore fpc-other archives up to the year 2010 and could not find anything which would resemble the topic.

Obviously, advantages and disadvantages specifically related to use of these libraries with FPC are perfectly on topic in this list.

Let me reassure you that I'm thinking in regard to FPC.

I mention this because it wasn't clear from the question of the original poster which of the cases he was asking about.

I'm a bit surprised considering that my original post was started with:

"I’m new to FPC and researching about different GUI options available to write open-source multi-platform desktop app using FPC…" ?

Sincerely,
Gour

On Wed, December 2, 2015 10:08, Saša Janiška wrote:

Hi,

Sorry, my fault, forget it (your post went to the moderation queue, but the reason was different and fixed now).

.
.

> Obviously, advantages and disadvantages specifically related to use of > these libraries with FPC are perfectly on topic in this list. Let me reassure you that I'm thinking in regard to FPC.

.
.

Very good.

Tomas