Custom Drawn Controls advances

[Fahmy Rofiq]

Issue reported: http://bugs.freepascal.org/view.php?id=21707 

[kilon]

I am very interested in making a OpenGL backend for this. I am very new with Lazarus and FP (though I used Delphi for a couple of years 15 years ago) but I love messing with GUIs and Live coding. And I have started a project in python that already implements a very modular Opengl GUI (from inside the 3d application Blender)

https://github.com/kilon/Ephestos

I am browsing through the wiki and the pdfs and hopefully I will be able to help you out in a couple of months or who knows even earlier.

Great work people and thank you.

[lainz]

This is alive?

[Graeme]

I think development has stalled a bit. Last I tested (few months back), there was still stacks of issues with the components, and the component looked and behaved rather odd. Still Alpha state. Don't get me wrong, I'm not trying to be rude, but coming from fpGUI (another custom drawn widgetset which I develop), I know exactly what a lot of work it is to implement fully functional set of components. I don't think Felipe relised this when he started - many don't (when I started fpGUI, I didn't either). :-)

I'll pull the latest code this weekend and test again.

[mse]

Coming from MSEide+MSEgui (another custom drawn widgetset which I develop), I can confirm. It is a task of at least 10'000 hours.

[felipemdc]

to Graeme:

Nothing to do with the amount of work. It is only a question of motivation. In the beginning I was very motivated, then I lost all motivation (and you contributed a lot to it) and did nothing for 6 months or so. Now a new motivation appeared, so I am planning to restart work in the second quarter of this year and advance the Android support.

About the state of the components, I don't care what people think, but in your particular case, since you insisted so hardly that I not comment on fpgui, then I will insist that you not comment anything about LCL-CustomDrawn. If you insist on breaking this rule, I will enforce it.

[Graeme]

Nothing to do with the amount of work. It is only a question of motivation.

Oh, I think they go hand-in-hand in this case. Starting something new is always exciting with lots of motivation. But once you realise what a lot of work something might be, that is in directly relation to a drop of motivation. Especially if you have to do all the work - no outside contributions. This happens to everybody.

About the state of the components, I don't care what people think

Good for you, and I feel the same. My work is totally driven by my personal needs.  PS: I wasn't bashing your work, just answering a post about the last known state of the CustomDrawn package. Please chill.

[snorkel]

Why don't the 3 of you join forces and make one Custom Drawn widget set for Lazarus?
Just wondering.

[mse]

Why don't the 3 of you join forces and make one Custom Drawn widget set for Lazarus?

Why of all things for Lazarus? Please explain.

[Graeme]

Why don't the 3 of you join forces and make one Custom Drawn widget set for Lazarus?
Just wondering.

Lazarus is way to bloated, riddled with bugs, and the widgetset backend is a design mess. Also we have very different design and usage goals. Not to mention that I don't believe in the idea of being a second rated product - simply copying Delphi VCL and nothing more. A clone. Martin and I have always felt strongly that custom drawn widgetsets are the way to go, and gives us the freedom to innovate with the API and features. The Lazarus developers for years fought against that [custom drawn] approach, and diverging from the VCL. Funny how now suddenly custom drawn LCL is accepted - but that is only because Felipe is part of the core team. I don't have the patience to "prove" myself to those guys. I know what I want and need - am good at software design, and just get the work done.

[Blestan]

Please All - Chill !!!!
Let's join forces and make and better ide for fpc based on the strong sides of lazarus/vcl, fpGUI and mse.

for long years the lazarus way of cloning delphi behaviour was the driving force to behind the success of fpc and the only possible step to attract programmers  .. not to mention that many of the changes in the early days  to the compiler itself has proposed by the lazarus team.

now it's time to escape from the shadow of delphi and work on gui that si simple to use across platforms and that targets mobile devices with ease..
it's crutial to avoid any deps on external libs and widgetsets  and  frocus to implement a powerful drawing backend using the best approach on paticular  platform ( OpenGL, DirectX, AggPas, etc etc)
then on top of it to build a clear and  simple gui with a designer ... an abstract multithreaded message loop is the base to all of this

But once again lazarus must be the fundation of all this process

i propose to start a discution to write down all the steps needed and to start a real work!

[Dibo]

Martin and I have always felt strongly that custom drawn widgetsets are the way to go, and gives us the freedom to innovate with the API and features

Exactly, I support strongly the idea of own drawn controls and can't wait for new fpGUI release with Agg. This is the future. Just look how Qt has evolved and I don't know any other library which can draw widgets by own engine, not OS API, so fpGUI have big chance on this field. I'm working on project based on Qt interface (could not use fpGUI due to issues listed below) and I can say that fpGUI is going right way. I tested fpGUI some time ago and I'm just amazed. Small exe (because no LCL), free pascal syntax, amazing efficient, styling, no external libs. Maybe fpGUI could have more people in team, but rather more volunteers which create new controls and styles. fpGUI core and API is big enough to create fancy controls, Graeme is doing very well with core stuff. I'm contributor of BGRA Controls and I'm trying to find some time to create something for fpGUI too.

Things on which fpGUI should focus to get more contributors:

• Controls transparency. It is basis in these days if we want to create modern looking interfaces. Simple example: rounded button with smoth shadow placed on toolbar which has gradient. I know fpGUI transparency situation from newsgroups and know trick how to do it, but on X11 it is very inefficient solution (Graeme you know this GetPixel issue) and should be built in base fpGUI control (as option/switch/object property)
• Layouting. Anchoring is not enough. It fault in some situations where control is autosize and has translation. But I see that in git repo fpGUI implementing mig layout
• Actual documentation. I know that you working on it

With things above + Agg, only our imagination will be the limit

Regards.

[mse]

But once again lazarus must be the fundation of all this process

I ask again why? MSEide+MSEgui is operable and used in production since many years, same applies to fpGUI. There is almost no chance to reach a similar goal with Lazarus as base, believe me. :-)

[mse]

• Controls transparency. It is basis in these days if we want to create modern looking interfaces. Simple example: rounded button with smoth shadow placed on toolbar which has gradient. I know fpGUI transparency situation from newsgroups and know trick how to do it, but on X11 it is very inefficient solution (Graeme you know this GetPixel issue) and should be built in base fpGUI control (as option/switch/object property)
• Layouting. Anchoring is not enough. It fault in some situations where control is autosize and has translation.
  

It seems you never looked in MSEgui. It has all this possibilities, please check the twidget properties frame and face and the components tframetemplate, tfacetemplate and tskincontroller. In order to make a twidget transparent set the color property to cl_transparent. tface supports semi transparent fades and pixmaps, it is even possible to fade out the widget itself...

[Dibo]

I tried to install MSEgui some time ago but could not install (compile) on Linux Ubuntu 64 bit, FPC 2.7.1. I don't remember what was the error

BTW: What is tiopf in fpgui? Why it is related to fpGUI?