Hi Everybody

I don't want to rehash stuff that's already been discussed at length, but I missed that part...

According to the blog (lazarus-dev.blogspot.com) Gtk is just so complicated. Why don't we just decide on Qt4 as it is now gpl, and focus all our energies on getting qt 4 stable. Then we can have 1 very cool looking stable widget set that has scalability, and pretty much will be able to satisfy 99% of the users needs (and that 1% isn't likely to be fulfilled by GTK anyway).

Regards,
-Reenen

Reenen Laurie wrote

According to the blog (lazarus-dev.blogspot.com) Gtk is just so complicated. Why don't we just decide on Qt4 as it is now gpl, and focus all our energies on getting qt 4 stable. Then we can have 1

And that means we can only develop GPL applications. Unless you don't mind paying the $2500 per developer (x3) license for Qt so our company can continue using Lazarus.

Alternatively, all stop developing other widget sets for LCL and everybody work on fpGUI to get it as good as Qt4. ;-) The possibility of that happening is just as good as Qt becoming the only LCL widgetset.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Ahhh... I forget about non-gpl programmers...

fpGUI sounds like a plan. :-)

I second that,

I have not taken much look at the fpGUI architecture but if it is made so it can also serve as a low level Qt/Gtk wrapper then the LCL can be made purely to rely on fpGUI and the complexity in it will be reduced. As I said I have not looked too deep into the underlying architecture but if the platform/framework specific stuff is all placed into as tiny layer (fpGUI) as possible, the LCL can really be made more portable, and the platform/framework specific functionality will become well insolated. This will make it (in theory) both easier to support and port to other environments. It also will allow for more native implementations of the fpGUI and probably it becoming a framework of its own right. Personally I would put my vote on fpGUI ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Why qt? Why not fpgui? Or write a cool widgetset using opengl?

As long as some people support a widgetset it will be supported.

Mattias

My concern is the amount of work that goes into making something "work" on Gtk1, Gtk2, Windows, Carbon, Qt, etc.

Some of the older widget sets doesn't support cool (or even basic) user interface stuff like docking... The gimp still makes me shudder.

You can "get it to work" on those widget sets, but with weeks of coding - working "around" the lack of support. Sometimes breaking support for other widget sets.

Boian's idea of a "thin layer" sounds like a decent enough solution.

Regards,
-Reenen

Reenen Laurie wrote:
[..]

Boian's idea of a "thin layer" sounds like a decent enough solution.

For a different kind of project... yes.

Marc

Reenen Laurie wrote

Ahhh... I forget about non-gpl programmers...

Yup, there are a few of us actually using FPC & Lazarus to make a living. :)

I believe five out of four people have a problem with fractions.

:-) Good one!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reenen Laurie napsal(a):

Hello all,

Well, I'm new to this group but I think that the difficult stuff of unifying many widgetsets under one interface, thus creating an universal, multi-platform widgetset, is great in result - from the point of view of the end-user developer. If others made the work in place of the Lazarus Team (fpGUI team, if I understand good), yes, it would be great to rely on that. But don't forget that the used unifying code of fpGUI goes then out of control of the Lazarus/LCL Team. Or am I wrong with that?

Regards,
Pavel

Or write a cool widgetset using opengl?

Because there are not many OpenGL programmers and most good ones don't like to write boring widgetsets. ;)

I am calling basicEventCreate in a project. In Windows it works fine in Linux it throws exception. Is it expected?

basicEventCreate( NIL, False, False, '' );

What are the alternatives if I need an event that is autoclear and another that is manually cleared in Linux?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Reenen Laurie wrote / nap?sal(a):

Well I played with Gtk2 a bit lately (that is the native thing, not via LCL) and I think that later versions (2.10+ and especially 2.12) are actually becoming usable.

The thing is, our biggest problem is missing features and "2.6+" support which holds us back. I agree with it somewhat but I think we need to look into the future too so I started a "gtk2ext" unit which contains lazy linked Gtk2.8+ stuff.

Each new component can be checked with Available_componentname_2_x(). So say something (like tray icon) was added in 2.12 you can do if Available_GtkStatusIcon_2_12() then ...

Same goes for PARTS of components. There are new functions added each major release to older components too. I'm slowly mapping that and adding them, with same checking mechanism. So if you do Available_SomethingOld_2_10() you check if all the new 2_10 functions of that component are there (logically 2.12+ should be true as well).

Those who thing gtk2 needs help can help me with this as it's not a trivial task. It seems our old gtk2 2.6 binding is missing a lot of things. I'm currently going "down by the docs" and filling in stuff, but if someone wants to help, tell me which part you want to work on so we don't collide.

The structure is rather simple and very h2pas friendly:

unit gtk2ext (inside fpc/packages/gtk2/src/gtkext) contains include files for header and implementation parts named after the components they include/extend. If you want to extend an old component or add new one, just add the 2 new include files.

Adding new ones is especially easy, because gtk2 has header files in this exact fashion (this is very nice of them). So you can just h2pas them and then fiddle with the result (most work is making the macroes into inline functions).

After this is done, the unit can be added to lazarus too (under different name) until next fpc version which has it (2.2.4) and we can do "if xxx then" to e.g: use proper tray icon for example (the gtk2 native tray icon works better, it doesn't "get missing" on gnome boot etc.)

Ales

Boian Mitov wrote

I am calling basicEventCreate in a project. In Windows it works fine in Linux it throws exception. Is it expected?

If you don't use cthreads, it is expected yes :-)

Hi Marco,

Thank you!
How I can get it to work? I have TThread classes in the project.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hi Marco,

Is there a setting I have to make in order for this to work? Or do I need to write a bit of code in the project?
Please help!
Any suggestion?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Hello Boian,

Friday, August 8, 2008, 10:36:55 PM, you wrote:

BM> Is there a setting I have to make in order for this to work? Or do I need to BM> write a bit of code in the project?
BM> Please help!
BM> Any suggestion?

Do you really need basicEventCreate ?

http://www.freepascal.org/docs-html/rtl/system/basiceventcreate.html

Basically:

BasicEventCreate
Obsolete. Don't use

:-?

Hi JoshyFun,

I get the same error when I use TEvent.
TEvent uses basicEventCreate in Linux internally. Is TEvent also obsolete? What it is replaced with? I have no problems using alternative signaling, but I can't figure out which one I should use.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

2008/8/8 Boian Mitov :

To use "cthreads", just include it as the very first unit of your program, susch as

<code>
    program sample;
    {$mode objfpc}{$H+}
    uses
      {$IFDEF UNIX}{$IFDEF UseCThreads}
      cthreads,
      {$ENDIF}{$ENDIF}
    ....;
    begin
      ...
    end.
</code>

Hope this help.

Hi Inoussa,

Thank you!
I am actually writing Lazarus component packages. Will this work in the package? I guess it should, but just to make sure. Also where I should put the uses section in the package unit, or in the component units?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

2008/8/8 Boian Mitov :

As the "cthreads" use is application wide, I think that it is up to the application to include "cthreads" unit.

Hi Inoussa,

Thank you!
The problem is that the components are multithreading, and as soon as I drop the component on the form in Linux it crashes Lazarus. The components have thousands of thread locks in them. The Lazarus in this case is the application. I apparently will have to add this to the component packages somehow. Obviously any application that includes the components will have to use the "cthreads" in this case. The components are for real time video audio and signal processing, and they have to be multithreading in order to process the streams without interfering with the GUI. This is a large set of over 200 components I am porting from Delphi to support Lazarus. So far they work fairly well in Lazarus under Windows, but I am having the TEvent problem in Linux.
What is the best approach? I can write my own TEvent if it is needed, but I hope there is a better approach.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I added it to the first unit of the package but now after rebuilding I can start Lazarus:

I am getting:

Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. Runtime error 211 at $08651EFA
$08651EFA
$087B99ED

Please help! How to use thread synchronization inside Lazarus components in Linux? Do I need to write my own TEvent class for that? Is there alternative event that I can use and will work?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

May this help you:
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Units_needed_for_a_multithreaded_application

Mattias

Hi Mattias,

Exactly what I need :-) .
It seems to works so far :-) .
Thank you!

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------