LazPaint (alpha-blending, antialiasing, filters)

[circular]

Yes, it is not as simple as that. There are minor differences, for example in the way controls behave.

But isn't that what the abstraction layer (LCL) is supposed to hide from the developer? A developer is supposed to simply code for the LCL API, and internally LCL will take care of the different backends.

Yes, that is the goal and if that were true, that would make things easier.

That is how fpGUI works - 99.99% of all fpGUI based applications have no IFDEF's needed in the application code.

Are you suggesting to change the GUI of LazPaint and to use fpGUI?

If I set LazPaint to fpGUI, I get the following error:
fpgui\fpguiwsdialogs.pp(39,3) Fatal: Can not find unit fpg_base used by FpGuiWSDialogs.

I am not sure if BGRABitmap works with fpGUI either.

I like the idea of having a single widgetset, and at the same time, I like that the program interface blends into the operating system. With the mac version, it looks like mac interface and I am happy with that. The problems that cannot be solved are related to components that do not provide some features or that are buggy. A part from that, the tweaks work fine. Also some things are not purely a matter of widgetset. For example, on mac, OK and Cancel buttons are switched.

If fpGUI provides everything that is needed, it could be used for MacOS to avoid the following problems: ComboBox not providing ownerdraw, save dialog returning an invalid path.

Are there example applications running with fpGUI?

Another solution is to use custom drawn controls when there are some compatibility problems. For now, the combobox of CustomDrawn package does not seem to work.

For FreeBSD, if it is similar to linux, it is possible that it would not be much work to adapt and compile LazPaint. Maybe just by doing the following:

Code: [Select]

{$IFDEF LINUX}{$DEFINE LINUXLIKE}{$ENDIF}
{$IFDEF FREEBSD}{$DEFINE LINUXLIKE}{$ENDIF}And then by replacing IFDEF LINUX by IFDEF LINUXLIKE.

Again, it works exactly like Linux. FreeBSD uses the exact same Xft/FreeType to render fonts. So hinting etc can also be tweaked to the user preference, just like under Linux.

Ok. I have looked at some screenshot using google search, it looks indeed like Linux. So I will apply the same level of antialiasing.

I haven't tried for a while. I'll update my local copies of BGRAControls, BGRABitmap and LazPaint and see how far it currently gets and let you know.

Ok, but please try BGRABitmap separately. Test programs are provided on LazPaint code repository.

[Graeme]

Are you suggesting to change the GUI of LazPaint and to use fpGUI?

No, just stating the pitfalls with LCL and the false promises of write once, compiler everywhere. Other toolkits seem to manage that better than LCL.

If I set LazPaint to fpGUI, I get the following error:
fpgui\fpguiwsdialogs.pp(39,3) Fatal: Can not find unit fpg_base used by FpGuiWSDialogs.

That's the LCL-fpGUI widgetset interface which I don't work on. Yes I contribute a patch here and there, but I prefer to use fpGUI directly (no LCL involved). This greatly reduces the executable size and has faster performance.

I am not sure if BGRABitmap works with fpGUI either.

I've never looked at the BGRABitmap code so don't know the internal design or dependencies. I can add that I, and many others, have easily ported LCL and VCL components to fpGUI.

But thinking about it, if BGRABitmap has a similar clean design as AggPas, then it shouldn't be a problem. AggPas is totally toolkit independent. There is just a small unit that brings AggPas+fpGUI or AggPas+LCL together (to convert the AggPas image buffer to the toolkit's TfpgImage or TImage), but they have no impact on the workings of AggPas itself. eg: I use AggPas easily for console apps too, like for generating graphs via a CGI app.

Are there example applications running with fpGUI?

DocView (help viewer), UI Designer (visual forms designer), Maximus IDE (demo IDE) etc. fpGUI also has a lot of demos included.

Another solution is to use custom drawn controls when there are some compatibility problems. For now, the combobox of CustomDrawn package does not seem to work.

The LCL-CustomDrawn is still pre-alpha stage as far as I'm concerned. It is definitely not in a usable state at the moment and still needs a lot of development work. Even the basic TEdit is still incomplete with mouse support, no default popup menu etc.

Ok, but please try BGRABitmap separately. Test programs are provided on LazPaint code repository.

I'll let you know as soon as I have a moment.

[circular]

No, just stating the pitfalls with LCL and the false promises of write once, compiler everywhere. Other toolkits seem to manage that better than LCL.

Well it is a compromise to use the widgetset of the system.

If I set LazPaint to fpGUI, I get the following error:
fpgui\fpguiwsdialogs.pp(39,3) Fatal: Can not find unit fpg_base used by FpGuiWSDialogs.

That's the LCL-fpGUI widgetset interface which I don't work on. Yes I contribute a patch here and there, but I prefer to use fpGUI directly (no LCL involved). This greatly reduces the executable size and has faster performance.

I understand, however without this, it is much work to adapt an application to fpGUI. I see you did a great job with fpGUI and it would get much more recognition and usage with a seamless integration in LCL.

I am not sure if BGRABitmap works with fpGUI either.

I've never looked at the BGRABitmap code so don't know the internal design or dependencies. I can add that I, and many others, have easily ported LCL and VCL components to fpGUI.

But thinking about it, if BGRABitmap has a similar clean design as AggPas, then it shouldn't be a problem.

BGRABitmap depends on the LCL. So you would say it is dirty?

For me, it provides a bridge between different technologies: TBitmap, TCanvas, TFPImage, TFPImageCanvas and of course TBGRABitmap, TBGRACanvas, TBGRACanvas2D.

AggPas is totally toolkit independent. There is just a small unit that brings AggPas+fpGUI or AggPas+LCL together (to convert the AggPas image buffer to the toolkit's TfpgImage or TImage), but they have no impact on the workings of AggPas itself. eg: I use AggPas easily for console apps too, like for generating graphs via a CGI app.

That would be great to have an independent version of BGRABitmap as well. However I would like it to be one library. So maybe this could be possible with compiler directives.

There is some challenge here, to do text rendering without LCL. For now, BGRABitmap uses TBitmap to render text.

DocView (help viewer), UI Designer (visual forms designer), Maximus IDE (demo IDE) etc. fpGUI also has a lot of demos included.

Congratulations, that looks great.

[Graeme]

BGRABitmap depends on the LCL. So you would say it is dirty?

Yup.

That would be great to have an independent version of BGRABitmap as well. However I would like it to be one library.

It should be possible as AggPas shows. If you can get BRGABitmap independent of a GUI toolkit, I would even add it as an optional software rendering layer for fpGUI too. I've actually had requests for that before.

There is some challenge here, to do text rendering without LCL. For now, BGRABitmap uses TBitmap to render text.

AggPas accomplishes that without problem. The code is there if you want to take a peek.

[circular]

BGRABitmap depends on the LCL. So you would say it is dirty?

Yup.

So we see things differently!

That would be great to have an independent version of BGRABitmap as well. However I would like it to be one library.

It should be possible as AggPas shows. If you can get BRGABitmap independent of a GUI toolkit, I would even add it as an optional software rendering layer for fpGUI too. I've actually had requests for that before.

I take a note of that.

EDIT: Conversation continued in BGRABitmap thread

[j0x]

i do not know if this is asking too much but would it be possible for LazPaint to make the text tool editable after its been entered? at the moment the changes to the text you input seems permanent or rasterize, and also is it possible to have Layer Effects/Styles and Adjustment Layers on LazPaint similar to Photoshop? i know this will be a hard request since even GIMP does not have this 2 features of Photoshop yet

thanks for the awesome work as always sir circular!

[circular]

That's a good idea. I am not sure however how to make this compatible with OpenRaster. Text layers can still be rasterized when saved in OpenRaster. For adjustments layers, that seems less obvious.

[j0x]

this is how Layer Effects/Styles is on Photoshop

(http://i.imgur.com/L5jt3wA.jpg)

as for Adjustment Layers being hard to do, its just a suggestion you can ignore it if its too hard, even GIMP does not have those 2 features yet (Adjustment Layers and Layer Effects/Styles) so i can understand if it will not be implemented

[circular]

Well I can probably do many of those things. Some things may be hard to do, but many of them are simply a matter of taking some time to do it. But I am more talking here about the compatibility with OpenRaster. Basically there is a special LZP format for LazPaint, that could contain those effects, however images can also be saved as OpenRaster, which is an open source format for layered images. But then some features could not be saved in this format. That's not so important, but still it would be better to make it as much compatible as possible.

[j0x]

ah ok, and ye i do not expect LazPaint to copy all the features of Photoshop when it comes to Layer Effects/Styles and Adjustment Layers, in the Layer Effects/Styles for example i just want the Stroke, Drop Shadow, Color Overlay and Gradient Overlay to be copied if possible but if either of them is not compatible with OpenRaster then you can ignore any of those

[circular]

I looked up what layer effects/styles are, and it seems that it transforms the layer in itself, without interacting with other layers. So in that case, if such a feature is not available in OpenRaster, it would be possible to store the resulting layer in OpenRaster.

For example, if you draw a disk, and add a emboss effect, in the LazPaint file, it would be saved as a layer containing a disk and an emboss effect to be applied, but in the OpenRaster file, it would be saved as a embossed disk (not as an effect). So that's compatible, even if when loading the OpenRaster file, it would not possible to remove the emboss as it would be rasterized.

In fact I don't know all the effects you mentionned because I don't have Photoshop, but I will have a look at it.

[j0x]

thank you for considering it! and also can i suggest you add opacity option to layers?

i just look at OpenRaster on wikipedia too and it says the following about Layers

Layers
storage of adjustment layers
storage of layer effects
http://en.wikipedia.org/wiki/OpenRaster#Layers

so i guess its possible

[circular]

Well those are proposed enhancements of OpenRaster. They are not really implemented yet as far as I know. This could be an opportunity to extend the format.

About Stroke and Shadow, this can only be done as effects.

About Color and Gradient Overlay, this could be done with additional blend modes and layer groups. For example a Color Overlay is equivalent to create a group of layer, with the target layer at the bottom and on top a layer filled with the color, and with a blend mode "mask".

I don't know if that would be convenient instead of having a property of the layer. This at least requires to implement layer groups. But I guess it would make it more compatible, because layer groups and blend modes are rather well defined.

[j0x]

glad to know there are workarounds

and if you do not mind more suggestion can you add
- opacity strength option for layers
- changing font of text tool
- changing font to either bold, italic, normal depending on a font's capability
- font preview like this - http://i.imgur.com/aVxwnvJ.jpg

basically i like for LazPaint to have features like in FotoGrafix particularly this

Layers: Support for multiple layers, including non-destructive adjustment layers, masks and editable text layers

you can check out FotoGrafix here - http://lmadhavan.com/fotografix/ its only less than 1mb file size

sorry for a lot of suggestions i have made, you can ignore the suggestions that you do not like

EDIT 1:

i miss this comment

That's a good idea. I am not sure however how to make this compatible with OpenRaster. Text layers can still be rasterized when saved in OpenRaster. For adjustments layers, that seems less obvious.

im fine with that, as long as when im not saving an image or project yet then i like to have that editable text layers

EDIT 2:

ah ignore the editable text layer feature i suggested, since that one looks hard to implement because its not supported by OpenRaster

[Chronos]

deb package can be downloaded from sourceforge but it can't install on my system. First of all Software center complains about:
Lintian check results for /tmp/lazpaint6.2_x86_64-linux_gtk2.deb:
E: lazPaint: arch-independent-package-contains-binary-or-object usr/share/lazpaint/lazpaint
E: lazPaint: bad-package-name
E: lazPaint: package-not-lowercase

Then it looks like installing package but then package is not installed. But manual installation works ok. sudo dpkg -i lazpaint6.2_x86_64-linux_gtk2.deb
My system is:
$ uname -a
Linux george 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.04
DISTRIB_CODENAME=vivid
DISTRIB_DESCRIPTION="Ubuntu 15.04"

Also I wonder if you use some "daily build" system for testing?

Also there is known problem that under Gtk2 widgetset Screen.PixelsPerInch reports just 96 even I have DPI set to 144. So it would be good to allow user to select DPI also manually. I am using Xfce as desktop environment.