The way to follow

[lainz]

Hi, so I've finished to think a bit more about what's next. The final idea I have is a mix of ideas, that are better for the simplicity of coding and to reuse existing code.

First we can use JSON to style, but as well the object inspector. So we can choose between using one or the other, not to be forced to use JSON or forced to use the object inspector. Both can be compatible.

The second point is that I was creating new controls in BGRAGUI instead of just porting to MSEgui. I was duplicating controls for LCL and for MSEide. That will change.

What I will do next: I will first refactor BGRAControls. Separating the drawers from the logic on the controls like was the first idea, but not creating new controls for the LCL like I was doing in BGRAGUI. So then I need to create the controls only in MSEide and BGRAControls will remain the same functionality but better structured. The drawers can be shared between both systems (LCL / MSEide) if possible.

To resume, first refactor BGRAControls, separate control logic from the UI using drawers. Keep all the same properties in the object inspector (backward compatible). Add methods to load the styles from JSON files in the controls that has style properties (mostly all of them). Then port these controls to MSEide, reusing the drawers from BGRAControls.

So, I will be working in my spare time in BGRAControls first, then in MSEide controls.

About the CSS package: I tried to use BGRABitmap on it and it was somewhat working, replacing the Polygons function with the PolygonsAntialias that's part of BGRABitmap. The author was notified and he says that will test BGRA, so I think is a good project to look at as well. About my idea of making our controls using his package, is not a good idea because that package is a whole system that works better the way is proposed by the author, like HTML and CSS for Pascal, not as standalone controls.

Thanks for reading =)

[fredvs]

Hello Lainz.

It seems very good.

About JSON, would it not be simpler to have a simple text file and store the data your own way? But maybe using JSON is at the end more easy (but needs dependencies).

[fredvs]

About using JSON, could you check if the memory leak using the fpc json unit is fixed?

For this, add -ghl parameter in compiler options, compile the app, run the application, do some use of json and close the application.

What say the terminal about memory leak when the app is closed?

[lainz]

Hi, maybe we can use a third party JSON parser, I'm using at work this one https://github.com/sysrpl/JsonTools Is a single unit and I think is the best one.

[fredvs]

Ha ok, (but try please with -ghl if there is no memory leak with this one).

I would recommend also to use -ghl for debugging and check the result after each big modif you do.

This because finding memory leak could be a huge horror if you wait to long to check if no memory leak is produced.

[lainz]

Ok I will take that into consideration.

I've finished adding the drawer for BGRAFlashProgressBar. The control has the same properties in LCL and MSE. Both are using the same drawer unit.

But I made a copy of the same drawer file in the BGRAGUI package so you don't need to add into path. The drawer goes in the same folder as the control both in BGRAControls and BGRAGUI.

I've mapped the existing properties into the drawer, so the user will keep working with the same properties. But If we need to change the drawer, only in a single file for both projects.

As well can be used for OpenGL or anything else. It receives a TBGRABitmap where to draw.

[fredvs]

When you are ready, please advice, I will test it for MSEgui with pleasure.

About LazPaint and memory leak...

Perfect, good boys, 0 memory leak, I Iike it.

[lainz]

Ok. The progressbar is done. I think I will add the json support when all controls are done. You can already try progressbar with mseide. Now transparency works fine.

[lainz]

And finally I thought it better and will try to follow @circular17 idea of having a single unit for both systems, so I avoid the problem of duplicating filenames. In the end we will have only bgracontrols package that will work with both systems. And sorry I'm changing the way too much instead of coding but I'm trying to do it well. I will keep this repository open for now until I migrate the 2 controls I have here into bgracontrols. Then this will be gone. How fred says sorry for the noise. Good night.

[lainz]

Knowing both systems saves time. I learned that the two are not so different and that redoing the controls is not needed at all.

[fredvs]

Hello.

OK, I did try your last commit and all seems perfect. Congrats!

In ideU source is added ideU_BGRA.prj, this to compile ideU with BGRAgui widgets in MSE Components Palette.

[EDIT] You may check the project-option in ideU_BGRA.prj, option 1 and 2 is set for Unix, 3 and 4 for Windows and before compilation choose the option number that you need. Check also in project-option-make-directories if your macros are defined ok. [EDIT2] And if you use ideU to compile ideU_BGRA.prj, please check project-option-make-compilerused. For Windows (option 3 and 4) it is not set as default compiler. So, if you are in Windows, set it as default. [EDIT3] If you use last commit of ideU, ideU_BGRA.prj is updated for Windows so you may ignore EDIT and EDIT2.

[circular17]

Cool, that looks great!