fpGUI Toolkit v1.0 release for FPC 2.6.2

[Graeme]

So here is question to Graeme. Is it possible to create some mechanism which let you quickly merge updates from original fpGUI to LCL fpGUI?

LCL-fpGUI uses whatever version of fpGUI you point it too. So that part already works.

My issue is the mess that LCL backend widgetset design is in. It is so damn Windows API centric - nothing you would expect from a cross-platform toolkit. I commit things every now and again, but it is a huge battle, because there are no documentation, every LCL-xxx backend is implemented totally different to the others, and nobody is willing to offer any help.

[Graeme]

Does it exist a LCL2fpGUI converter, who convert my LCL code into fpGUI code.

No, sorry.

[Fred vS]

In topic :
http://www.lazarus.freepascal.org/index.php/topic,19829.msg113398.html#msg113398

It is noted that the audio-latency is very dependent of the widgetset used.

Im very interested about the result with your fpGUI widgetset.
I gonna (try to) translate some simple audio-app into fpGUI and compare the result with other widgetset.

fpGUI is maybe a challenger for Qt, who knows...

[Graeme]

It is noted that the audio-latency is very dependent of the widgetset used.

I'm by no means a audio expert, but I can add that one of our products strings together lots of individual sound clips to build a complete sentence. We use SDL for this, because SDL works cross-platform and automatically takes advantage of each platforms audio sub-system (be that ALSA, PulseAudio, Windows etc). Not to mention that SDL was developed for games, so I think it's audio support is pretty good. But then, as I said, I am no audio expert.

For video we translated the VLC 2.x library interface from C to Object Pascal. In both SDL and VLC we created simple classes to give use a more developer friendly interface to the multimedia backends. All our apps are build with fpGUI of course.

[itmitica]

I return to the topic.
I don't want to leave the impression I'm talking out of my ass.

Here is a screencap with LCL and fpGUI side-by-side: http://postimg.org/image/hn5je1mc3/

You can see clearly how fpGUI fails in the user experience.
I'm not talking about the ugliness, this could be a matter of visual taste.
I'm talking about cut-off  text on radio button labels.

And this goes for every example provided in the examples\gui folder that I've tested.
Overlapping elements, cut-off text.
Serious stuff, that the paying customer will not fail to notice once he changes his settings.

And it will blame it all on you, the developer. For not educating him, from the get-go.

--
Mitică

[Fred vS]

And this goes for every example provided I've tested.
Overlapping elements, cut-off text.

That is a detail, maybe Graeme have to take more care about the examples he gives.
If you only increase the width of the component, everything gonna fit.

With that kind of argument, sorry but,

I don't want to leave the impression I'm talking out of my ass.

my impression still remain...

[Dibo]

I return to the topic.
I don't want to leave the impression I'm talking out of my ass.

Here is a screencap with LCL and fpGUI side-by-side: http://postimg.org/image/hn5je1mc3/

Yes, most of fpGUI widgets don't have autosize support yet. But what I read on fpGUI news group, this problem will probably solve miglayout which is actually rewritten from java

[jmpessoa]

 fpGUI news group? some link?

Thanks!

[Dibo]

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

[jmpessoa]

 
Ok, but the

fpgui.development 

fpgui.support

there are not link at all ! 

Thanks!

[itmitica]

That is a detail, maybe Graeme have to take more care about the examples he gives.
If you only increase the width of the component, everything gonna fit.

The key here is to no go over the interface every time something like this appears, and certainly not performing very loose and approximate manual adjustments on the "as encountered" basis.

With that kind of argument, sorry but,

I don't want to leave the impression I'm talking out of my ass.

my impression still remain...

My impression is that you're just talking, or at the very least, you're talking at a completely different level then me.
What I've showed represents a key, I repeat, a key flaw in user experience.

There is no quality control for the fpGUI, clearly, yet the product is sold commercially.

As a client, I would form myself a most unfavorable opinion if I was to test case fpGUI as a product and if I was find out it only stands its ground in a very controlled environment.

On a side note, I would recommend you to have a honest attitude about the products you test and the quality of your testings. Being partisan doesn't serve anyone, not even yourself. My personal opinion, is that you seem to be missing some training when it comes to real world user interfaces.

--
Mitică

[sfeinst]

So if the person wants polka dots, you, the developer, are to blame if he gets it, and then fails the user with it.

That, my friend, i TOTALLY NOT agree.

Like it or not, it's the truth. You, the developer, will get the full blame, when things go sideways.

The client may be asking something from you he doesn't quite grasps.
The same as with going to the dentist and making decisions you shouldn't.

Anyway, google for "educating your customers".

--
Mitică

I fully agree with Mitică on this item.  Quite a few years ago, a user requested that I show blinking text in an application to make it stand out.  This was a Windows app and one of the user's first ones.  They were used to seeing blinking text in DOS apps.  I told them (nicely) that it was possible, non-standard, not recommended and there were other options (using fonts, colors, location, etc).  Basically, I refused.  They were very happy with the final product.

A few years later when web sites got bigger, the same exact thing happened (different customer).  They wanted blinking text.  I gave them the same response and the same refusal.  They were also happy with the result.

Basically, the job of the developer is not to just give what the user wants by their statement, but give them what they want based on what they really need while also giving them good advice about standards, support, usability, etc.  After all, we are the experts, not them.

On a side note.  Someone wants to throw a ridiculous amount of money at me to code something in a dumb manner, I'll be happy to.   

[sfeinst]

Yes, most of fpGUI widgets don't have autosize support yet. But what I read on fpGUI news group, this problem will probably solve miglayout which is actually rewritten from java

Your mention of MigLayout reminds me of so many similar arguments going back and forth about native vs in-language..no reliance on external libs..consistent appearance in relation to using Java and Swing.  All the messages I see in topics like that are almost identical in their arguments from both sides (native is better, no building in language, not relying on external libs and consistent appearance is better).

It amuses me 

[Fred vS]

@ sfeinst : yes, everything is binary, even computing...

[Fred vS]

The key here is to no go over the interface every time something like this appears, and certainly not performing very loose and approximate manual adjustments on the "as encountered" basis.

I develop (also) sharewares for Windows/Linux/OSX.
Trust me, my friend, the auto-size feature never worked well for me.

With same code developed on Lazarus/GTK2/Linux if i compile with GTK or Qt or Win32 or Carbon, the result are never ok for all system with auto-size.

That is the reason why i never code any-more with the auto-size feature, i prefer use my own width/height and always, for label  or edit, i use

Code: [Select]

label.autosize := false
So, for me, auto-size should be the last feature needed...