fpGUI Toolkit v1.0 release for FPC 2.6.2

[Graeme]

Here is a screencap with LCL and fpGUI side-by-side

And here is a quick example I created for you.

Each time I started X11 with 'startx -- dpi xyz' where xyz is the dpi I want to test. My system defaults to 107 dpi, though my monitor is actually higher than that.

http://opensoft.homeip.net/~graemeg/project2-80dpi.png
http://opensoft.homeip.net/~graemeg/project2-96dpi.png
http://opensoft.homeip.net/~graemeg/project2-107dpi.png
http://opensoft.homeip.net/~graemeg/project2-120dpi.png
http://opensoft.homeip.net/~graemeg/project2-140dpi.png

To get the sample project to scale fully (not just font, but widgets and the form itself), I had to include 2 lines of code in the OnShow event handler. And if I have a multi-form application (like our commercial apps which have around 150 forms), then I simply introduce these two lines of code in a descendant form - and not in each form.

Here are the two lines of code:

Code: [Select]

  if fpgApplication.Screen_dpi <> cDPI then
    ScaleDPI(self, cDPI); // cDPI is the dpi you designed the form at

As you can see from the code above, fpGUI has built-in ability to return the screen DPI value for you. The ScaleDPI() function is defined in a separate unit shared by our applications, which I'll merge into fpGUI - so as to finally get you off my case.

Like I said before: Clearly fpGUI is not for you, so simply stop testing or using it. I'm certainly not forcing you to use fpGUI.

ps:
I'm also working on a Layout Manager (a port of the Java layout manager called MiGLayout) - this completely make the "supposed" DPI issue irrelevant, and probably also make the UI Designer obsolete (at least for me). MiGLayout allows you to to define sizes in any style you want. points, cm, mm, inches, pixels etc. Please take a look at the Swing demo if you want to learn more. http://www.miglayout.com/

[Graeme]

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.

Indeed! Even Lazarus IDE suffers from this. That is why I am reluctant to add AutoSize properties to all controls in fpGUI. There are much better solutions to the problem, and those are the ones I will implement.

[Fred vS]

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.

Im not a partisan, im a positive.

What i have tested : a simple program showing jpg images :

Visual-Result : equal for  fpGUI vs Qt vs GTK2 vs Win32 vs Carbon.

Size of binary : 1 mega for fpGUI, others > 5 megas.

Speed of loading :  fpGUI much faster.

[jmpessoa]

@Graeme,

1. Please, put your project test DPI on  Attachments.....

2.Think on the good side. The challenges/contestations is a great opportunity to talk to us about some features of the fpGUI framework ... and we all learn from this!

Greetings!

[itmitica]

And here are more screencaps of fpGUI, as it is, out-of-the-box.

http://postimg.org/image/4phpzfl5t/

From these screencaps I conclude that fpGUI can't properly ensure a unified experience even on the same platform.


My 2¢:

1st ¢. Stop badmouthing LCL, at least until you have something truly better to show for.

2nd ¢. Stop badmouthing testers of your own publicly exposed work and examples. You should consider me a potential client, and, as you stated before, "the client is always right".

--
Mitică

[itmitica]

Im not a partisan, im a positive.

In my book, what you are right now is either naive or oblivious.

What i have tested : a simple program showing jpg images :

Visual-Result : equal for  fpGUI vs Qt vs GTK2 vs Win32 vs Carbon.

Size of binary : 1 mega for fpGUI, others > 5 megas.

Speed of loading :  fpGUI much faster.

Real tests have actual numbers backing them up.
What you're doing here is either marketing or gossip.

--
Mitică

[Fred vS]

From these screencaps I conclude that fpGUI can't properly ensure a unified experience even on the same platform.

From these screencaps I conclude that the fpGUI example-codes must be rechecked by Graeme. 

[itmitica]

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...

You keep repeating this and you expect me to take it as a virtue.
Well, no. Definitely not.

What you're doing is not the way to go, for a number of reasons. The most important one being the fact that you should not brutally "murder" the issue by setting in stone your own measures. It will still be a corpse and it will most certainly hunt you stink, like it or not. I'm mostly surprised it hasn't so far, I just can't explain that...

--
Mitică

[itmitica]

From these screencaps I conclude that fpGUI can't properly ensure a unified experience even on the same platform.

From these screencaps I conclude that the fpGUI example-codes must be rechecked by Graeme. 

Which will only fix (as in a fixed matches or a fixed horse races) the examples them selves. Because now, the width will be larger than needed on normal DPI, while the increase in width will be an arbitrary an blind method.

The issues remains for every new application created with the fpGUI code I downloaded today. Maybe new code will bring a proper fix.

--
Mitică

[Fred vS]

@ itmitica :
http://postimg.org/image/4phpzfl5t/

Look at the result on my Ubuntu 13.04 64 bit system. (in attachment)

What system do you use ?
For me the result is perfect and do not have word-cuted ?
( and i promise, i do not change anything from the original code  )

I use Lazarus 1.0.8 with fpc 2.6.2.

Ps : Graeme: for me your example-codes are ok.

[Graeme]

1. Please, put your project test DPI on  Attachments.....

No problem, see attachment.

[itmitica]

@ itmitica :
http://postimg.org/image/4phpzfl5t/

Look at the result on my Ubuntu 13.04 64 bit system. (in attachment)

What system do you use ?
For me the result is perfect and do not have word-cuted ?
( and i promise, i do not change anything from the original code  )

I use Lazarus 1.0.8 with fpc 2.6.2.

Ps : Graeme: for me your example-codes are ok.

It seems the essence of my testing completely escapes you still.
I'm on Win8 64bit. I've set the size of all items at 150%. You can do that even in Win XP and get the same crocked look for fpGUI there.

For you to replicate this behavior on Ubuntu, you should look into DisplaySize settings in xorg.conf:

Section "Monitor"
  Identifier "myMonitor"
  DisplaySize 223 125
EndSection

--
Mitică

[Graeme]

And here are more screencaps of fpGUI, as it is, out-of-the-box.

Ah, just beautiful. 

You should consider me a potential client, and, as you stated before, "the client is always right".

Thank goodness I'm not that desperate for money... so please don't consider yourself a "client" of mine - it will never happen.

For someone not interested in fpGUI, you sure are going to a lot of trouble to show the opposite. Also, I never stated anywhere that fpGUI is perfect. My original post was simply to announce another release - like many before - and like many to come.

[itmitica]

Thank goodness I'm not that desperate for money... so please don't consider yourself a "client" of mine - it will never happen.

For someone not interested in fpGUI, you sure are going to a lot of trouble to show the opposite.

I'm simply backing up my opinion. If it bothers you that much there has to be some truth to it. And if you can't stand true observations, how do you expect LCL contributors to take your, let's say, negative attitude.

Anyway, I've applied your "toolbox" dpi "fix". You'll notice there are issues still, this time not only with widgets but with form positioning on screen.

http://postimg.org/image/jqk24egff/

The way I look at it, you're right, I've no intention of using fpGUI as it is. But you should be thanking me for free testing and feedback. Only now I'm not interested anymore in helping you get fpGUI right.

--
Mitică

[Graeme]

Real tests have actual numbers backing them up.

Knock yourself out... Here is an independent test done showing image loading performance - compared to fcl-image (included with FPC and used by LCL), fpGUI is much faster.
  http://members.upc.nl/h.speksnijder4/software/fpGUI/imagesread.html

If you want to comment on those results, email the original author - I had nothing to do with those tests. If you want other tests, create them yourself. At least now you got some numbers.