Lazarus
Announcements => Lazarus => Topic started by: felipemdc on November 11, 2011, 06:40:20 am
-
Hello,
I'd like to announce that I have been advancing a lot with the Lazarus Custom Drawn Controls Package in the last days, so now the following controls are already basically functional (but not feature complete):
TCDButton, TCDCheckBox, TCDGroupBox, TCDScrollBar, TCDEdit, TCDPageControl, TCDTrackBar, TCDProgressBar
One of my near term goals is adding at least the Report style of TCDListView, so I am working a lot on this control too (and on TCDScrollBar which is uses).
This set of controls allows a full customization of the look and full reliability on the look and behavior of the control across all Lazarus widgetsets.
For screenshots and for more information please see the wiki:
http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls#How_do_these_components_work.3F
The custom drawn controls can be found in the Lazarus source tree in the directory lazarus/components/customdrawn, although I plan on moving them to the LCL in the future when they will be utilized by the future customdrawn widgetset of Lazarus.
Patches are welcome =)
thanks,
Felipe Monteiro de Carvalho
-
You're the master of custom controls.
Edit: So when you add those to the LCL we can use it to make new controls using the existing code without a package dependency?
-
You're the master of custom controls.
Patches are welcome ;)
Edit: So when you add those to the LCL we can use it to make new controls using the existing code without a package dependency?
Yes.
-
I was looking the wiki page, and it's a nice work!!!
I can't wait to test them
/BlueIcaro
-
Patches are welcome ;)
Great work. Looks promising!
Not a patch, but you probably should add PrepareCurrentDrawer(); to the end of TGroupBox.Create.
I can't get TEdit to work. If I click on it, and type anything, the text goes blank. No caret is shown either.
Both are tested on Ubuntu.
-
Nice work. :)
I noticed some black pixels on some controls, sometimes the rendering is not perfect apparently.
When you finish some elements, they could be added to BGRAControls with some adjustments if it gives more possibilities. 8-)
-
I noticed some black pixels on some controls, sometimes the rendering is not perfect apparently.
Which controls exactly and which widgetset?
When you finish some elements, they could be added to BGRAControls with some adjustments if it gives more possibilities. 8-)
I think that the best would be if you instead rebase to implement BGRAControls as a drawer of Lazarus Custom Controls.
This way we can share all the generic non-drawing code. Think about it: 2 implementations of caret, 2 implementations of selection of text, 2 implementations of button click handling, etc, why? We can share the non-visual code completely.
BGRAControls could be implemented as a drawer for Lazarus Custom Drawn Controls. Remember that the Lazarus Custom Drawn Controls will be inside the LCL, so it will be in the core of Lazarus.
Let me know what you think =)
-
I can't get TEdit to work. If I click on it, and type anything, the text goes blank. No caret is shown either.
Umm, there were some regressions on TCDEdit ... I am fixing them.
Caret drawing is fixed in rev 33502
The text dissapears in LCL-Qt and LCL-Gtk2 when you type ... no idea why yet. It does not do that in LCL-Carbon and LCL-Win32 which are the widgetsets I tested the most sofar.
Edit: I fixed a bunch of stuff in TCDEdit, but there is still a bug in GetTextExtentExPoint in LCL-Qt and LCL-Gtk2 which I am fixing. After fixing this then it should work normally like in other widgetsets.
Edit2: Already fixed GetTextExtentExPoint in LCL-Qt and LCL-Gtk2
-
I pulled the latest Lazarus source from svn an hour ago. TCDEdit works well in both gtk2 and qt. Great work :-)
-
I think that the best would be if you instead rebase to implement BGRAControls as a drawer of Lazarus Custom Controls.
Can you explain how this would work exactly ?
-
Can you explain how this would work exactly ?
Can your library render the final image to a TCanvas?
-
Yes.
-
So it is very easy, just write a drawer unit and class just like any other drawer:
See for example the WinCE drawer:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/customdrawn/customdrawn_wince.pas?view=markup&root=lazarus
-
I see. Well this cannot be merged with BGRAControls, but this can provide an alternative look for CD controls. But it is not really adapted to BGRABitmap, because the principle of it is to render everything in a TBGRABitmap and then draw it on the screen. Here each part is drawn separately. The drawer interface could be adapted, but anyway, I'm not sure it would bring anything new. BGRABitmap is not a style, it's a rendering system, so it can render many different styles. It is possible to add some styles to custom drawn controls which use specific BGRABitmap functions, but this would be some extra developpement that would be parallel to BGRAControls.
-
Do you need support for setting a different style for each control or only setting the style for all controls would be enough?
If limiting to the same style for all controls then it would be quite easy, just add whatever you need to your drawer class, only 1 instace of it exists in the system, so at program startup you can configure it to whatever you want.
If you need support for a different style for each control, then a possible solution would be simply implementing many DrawStyles, not only 1. Make 1 basic and then other styles which just inherit from the basic one and set your sub-style properties.
What is the size of your style information? Only a couple of choices or do you need it extremely detailed? Which information it includes exactly?
-
Well, for example, the class TBGRAButton has gradient styles, round corner radius, text shadow option... Some other controls have less properties like TBGRAFlashProgressBar, which has only one color property.
-
Well, for example, the class TBGRAButton has gradient styles, round corner radius, text shadow option... Some other controls have less properties like TBGRAFlashProgressBar, which has only one color property.
Ok, now I see, in this case I just came up with a different idea: Inherit your controls from the ones in custom drawn controls and then override anything you need, add properties, make sure to completely override the Paint method.
If your button is extremely different it might be of no use basing it on TCDButton, buttons are so simple anyway. What I really wanted to share here was code for complex controls. For example code for creating the popup of a TCDComboBox is something which I lack, but it seams that you have already, so I would be very happy to accept a patch on that ;) And then you can inherit from TCDComboBox and changed what you need and add your drawing options.
Similarly I already have an advanced TCDPageControl which might be useful for you to base on (no idea if you already have that).
-
Just we're using TBGRAButton as combobox with a TPopupMenu in testbgracontrols main form =)
The way we style the buttons with different looks is in testbgracontrols. Procedures to change all properties in a TBGRAButton in the bgrasamples unit.
BGRAButton has that kind of drawing with a lot of property for each state (because that, the control is fully customizable), other components like TWin7ToolBar use BGRAButtons and style them with a DrawStyle (TBGRASampleStyle).
BTW if I want to create a 100% equal to for example Win7Button i can't. Some buttons has an' inner shadow' when button is pressed. Some buttons hasn't the offset in the text when you press the button and some other things.. so it is customizable, but if we create separated procedures to draw the buttons those can look as you want.
ToolBars are drawn with a different procedure for each style, for example this to draw an iOS ToolBar
procedure DrawiOSToolBar(ABitmap: TBGRABitmap);
begin
DoubleGradientAlphaFill(ABitmap, Rect(0, 3, ABitmap.Width, ABitmap.Height - 6),
BGRA(172, 185, 201), BGRA(134, 153, 178, 255),
BGRA(125, 147, 175, 255), BGRA(110, 132, 162, 255),
gdVertical, gdVertical, gdVertical, 0.5);
with ABitmap do
begin
// Top Bevel
SetHorizLine(0, 0, Width - 1, BGRA(201, 210, 221, 255));
SetHorizLine(0, 1, Width - 1, BGRA(173, 184, 200, 255));
SetHorizLine(0, 2, Width - 1, BGRA(179, 190, 205, 255));
// Bottom Bevel
SetHorizLine(0, Height - 6, Width - 1, BGRA(107, 129, 158, 255));
SetHorizLine(0, Height - 5, Width - 1, BGRA(116, 139, 170, 255));
SetHorizLine(0, Height - 4, Width - 1, BGRA(48, 54, 62, 255));
// Bottom Shadow
SetHorizLine(0, Height - 3, Width - 1, BGRA(0, 0, 0, 75));
SetHorizLine(0, Height - 2, Width - 1, BGRA(255, 255, 255, 50));
SetHorizLine(0, Height - 1, Width - 1, BGRA(0, 0, 0, 10));
end;
end;
For some things like shadow we need to use BGRABitmap filters, like blur. BGRAImageButton uses BGRABitmap alpha and resample (fine resample).
-
@felipe
I undestand. Yes it is a good idea to derive from your controls. Nevertheless, for a matter of dependency, this will be possible to achieve only when your controls are part of LCL. Otherwise we may share abstract classes in units that are in duplicated in both packages.
-
This is my test for custom button drawing,
this button has only normal and mouse enter states,
see image attached,
using bgrabitmap, bgracontrols (only bgrasamples), customdrawn:
unit Unit1;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, customdrawncontrols, Forms, Controls, Graphics,
Dialogs, BGRASamples, BGRABitmap, BGRABitmapTypes, types,
{ custom drawn }
customdrawn_common, customdrawndrawers;
type
{ TLainzDrawer }
TLainzDrawer = class(TCDDrawerCommon)
public
procedure DrawButton(ADest: TCanvas; ADestPos: TPoint; ASize: TSize;
AState: TCDControlState; AStateEx: TCDControlStateEx); override;
end;
{ TForm1 }
TForm1 = class(TForm)
CDButton1: TCDButton;
private
{ private declarations }
public
{ public declarations }
end;
procedure RegisterDrawerLainz;
var
Form1: TForm1;
implementation
procedure RegisterDrawerLainz;
begin
RegisterDrawer(TLainzDrawer.Create, dsExtra1);
end;
{$R *.lfm}
{ TLainzDrawer }
procedure TLainzDrawer.DrawButton(ADest: TCanvas; ADestPos: TPoint;
ASize: TSize; AState: TCDControlState; AStateEx: TCDControlStateEx);
var
temp: TBGRABitmap;
s: TSize;
begin
// Bkg
if csfMouseOver in AState then
temp := DrawiOSElement(ASize.Cx, ASize.Cy, iOSBar)
else
temp := DrawiOSElement(ASize.Cx, ASize.Cy, iOSBackground);
// Font
temp.FontQuality := fqSystemClearType;
temp.FontHeight := AStateEx.Font.Height;
s := temp.TextSize(AStateEx.Caption);
temp.TextOut(Round((ASize.Cx - s.cx) div 2), Round((ASize.Cy - s.cy) div 2),
AStateEx.Caption, BGRA(0,0,0,255));
// Draw
temp.Draw(ADest, ADestPos.x, ADestPos.y);
temp.Free;
end;
end.
I've put the register of the style in the lpr because I don't know if there is other place to put it
Application.CreateForm(TForm1, Form1);
RegisterDrawerLainz;
-
Tell me, rendering component uses a library or something which is completely based on the source code? The fact is that I want to write OpenGL application that would use less third-party libraries such as GTK and QT. I just want TFrom and TCustomControl.
Since this is a cross-platform application will be no additional installation is necessary libraries in the platform causing the problem.
Скажите мне, отрисовка компонентов использует ли какую нибудь библиотеку или полностью основана на исходном коде? Дело в том что я хочу написать OpenGL приложение которое бы меньше использовало сторонние библиотеки такие как GTK и QT. Мне всего лишь нужен TFrom и TCustomControl.
Так как это приложение будет кроссплатформенным то дополнительная установка не нужных библиотек в эту платформу вызывает проблему.
-
Tell me, rendering component uses a library or something which is completely based on the source code?
I'll assume you are talking about Lazarus Custom Drawn Controls here: It uses standard basic elements from the LCL: TCanvas, TBitmap, and friends.
Some drawers use TLazIntfImage too.
The fact is that I want to write OpenGL application that would use less third-party libraries such as GTK and QT. I just want TFrom and TCustomControl.
Since this is a cross-platform application will be no additional installation is necessary libraries in the platform causing the problem.
That's one of the objectives of the Custom Drawn Widgetset of Lazarus:
http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface
But it is very initial, only the Cocoa backend already supports most basic parts of TForm.
Until it gets ready (patches are welcome) you can use the fpGUI widgetset:
http://wiki.lazarus.freepascal.org/fpGUI_Interface
-
I want a widget with a pure X Server window, is it possible to add a Custom Drawn Widgetse opportunity?
Or there are other widgets that are able to implement it?
Мне требуется виджет с чистым X Server окном, возможно ли добавить в Custom Drawn Widgetse такую возможность?
Или есть другие виджеты которые способны реализовать это?
-
Really nice :)
procedure TLainzDrawer.DrawButton(ADest: TCanvas; ADestPos: TPoint;
ASize: TSize; AState: TCDControlState; AStateEx: TCDButtonStateEx);
var
Str: string;
lGlyphLeftSpacing: Integer = 0;
lTextOutPos: TPoint;
lGlyphCaptionHeight: Integer;
begin
with ADest do
begin
Pen.Color := RGBToColor(163, 166, 168);
Pen.Style := psSolid;
Rectangle(0, 0, ASize.cx, ASize.cy - 1);
GradientFill(Rect(1, 1, ASize.cx - 1, ASize.cy - 2), RGBToColor(235, 239, 242),
RGBToColor(213, 217, 220), gdVertical);
Pen.Color := clWhite;
Line(1, 1, ASize.cx - 1, 1);
Line(0, ASize.cy - 1, ASize.cx, ASize.cy - 1);
end;
if csfSunken in AState then
with ADest do
begin
Pen.Color := clSilver;
Brush.Style := bsClear;
Rectangle(1, 1, ASize.cx - 1, ASize.cy - 2);
end
else if csfHasFocus in AState then
with ADest do
begin
Pen.Color := clWhite;
Brush.Style := bsClear;
Rectangle(1, 1, ASize.cx - 1, ASize.cy - 2);
end;
// Position calculations
ADest.Font.Assign(AStateEx.Font);
Str := AStateEx.Caption;
lGlyphCaptionHeight := Max(ADest.TextHeight(Str), AStateEx.Glyph.Height);
lTextOutPos.X := (ASize.cx - ADest.TextWidth(Str) - AStateEx.Glyph.Width) div 2;
lTextOutPos.Y := (ASize.cy - lGlyphCaptionHeight) div 2;
lTextOutPos.X := Max(lTextOutPos.X, 5);
lTextOutPos.Y := Max(lTextOutPos.Y, 5);
// Button glyph
if not AStateEx.Glyph.Empty then
begin
ADest.Draw(lTextOutPos.X, lTextOutPos.Y, AStateEx.Glyph);
lGlyphLeftSpacing := AStateEx.Glyph.Width + 5;
end;
// Button text
lTextOutPos.X := lTextOutPos.X + lGlyphLeftSpacing;
lTextOutPos.Y := (ASize.cy - ADest.TextHeight(Str)) div 2;
ADest.Brush.Style := bsClear;
ADest.Pen.Style := psSolid;
if csfSunken in AState then
begin
Inc(lTextOutPos.X);
Inc(lTextOutPos.Y);
end;
ADest.TextOut(lTextOutPos.X, lTextOutPos.Y, Str);
end;
procedure TLainzDrawer.DrawProgressBar(ADest: TCanvas; ADestPos: TPoint;
ASize: TSize; AState: TCDControlState; AStateEx: TCDProgressBarStateEx);
var
lProgPos, lProgMult: TPoint;
lProgSize: TSize;
lProgWidth, i: integer;
begin
with ADest do
begin
Pen.Color := RGBToColor(163, 166, 168);
Pen.Style := psSolid;
Rectangle(0, 0, ASize.cx, ASize.cy - 1);
GradientFill(Rect(1, 1, ASize.cx - 1, ASize.cy - 2),
RGBToColor(213, 217, 220), RGBToColor(235, 239, 242), gdVertical);
Pen.Color := clWhite;
Line(1, 1, ASize.cx - 1, 1);
Line(0, ASize.cy - 1, ASize.cx, ASize.cy - 1);
end;
// Preparations to have 1 code for all orientations
lProgSize := Size(ASize.cx - 4, ASize.cy - 4);
if csfHorizontal in AState then
begin
lProgPos := Point(ADestPos.X + 2, ADestPos.Y + 2);
lProgMult := Point(1, 0);
lProgWidth := lProgSize.cx;
end
else if csfVertical in AState then
begin
lProgPos := Point(ADestPos.X + 2, ADestPos.Y + ASize.cy - 2);
lProgMult := Point(0, -1);
lProgWidth := lProgSize.cy;
end
else if csfRightToLeft in AState then
begin
lProgPos := Point(ADestPos.X + ASize.cx - 2, ADestPos.Y + 2);
lProgMult := Point(-1, 0);
lProgWidth := lProgSize.cx;
end
else
begin
lProgPos := Point(ADestPos.X + 2, ADestPos.Y + 2);
lProgMult := Point(0, 1);
lProgWidth := lProgSize.cy;
end;
lProgWidth := Round(lProgWidth * AStateEx.PercentPosition);
// Draws the filling
ADest.Pen.Color := RGBToColor(213, 217, 220);
ADest.Pen.Style := psSolid;
ADest.Brush.Color := RGBToColor(213, 217, 220);
ADest.Brush.Style := bsSolid;
ADest.Rectangle(
lProgPos.X,
lProgPos.Y,
lProgPos.X + lProgWidth * lProgMult.X + lProgSize.cx * Abs(lProgMult.Y),
lProgPos.Y + lProgWidth * lProgMult.Y + lProgSize.cy * Abs(lProgMult.X));
end;
-
I want a widget with a pure X Server window, is it possible to add a Custom Drawn Widgetse opportunity?
Or there are other widgets that are able to implement it?
Yes, LCL-CustomDrawn has a direct X11 backend: http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface
But it is not yet ready for usage, it is under construction.
I already implemented the major infra-structure elements for it. We have a non-native Canvas, we have a powerful support for regions which are utilized to clip both painting and input events, and also support for non-native TWinControl and even non-native TForm for Android.
Until now I have already finished basic support for TApplication, TForm, TWinControl, TBrush, TPen, OnPaint, OnMouseDown, OnMouseUp, OnMouseMove in the following backends:
*Android
*X11
*Windows
*Cocoa
You can follow the status advance here:
http://wiki.lazarus.freepascal.org/Roadmap#Status_of_features_on_each_widgetset
I expect the visual controls to advance very fast because they will all be based on the lazarus custom drawn controls
-
I just had my first look at the Custom Drawn Controls. Very nice :) One of the things I noticed was that BiDiMode is not implemented yet and that makes sense. I think that may take a while. The TPageControl that is in Lazarus now is not able to mirror the tabs so that they start from the Right. Do you know if the plan is to make TCDPageControl so that it can do this? Anyway, I'm looking forward to using the new controls.
-
I am trying to understand how all these pieces fit together so that I can use FPC and Lazarus to build applications for Android devices (because I have tried using the native java method and java is not nice :D) Please correct me if I am wrong:
The idea is to use the Custom Drawn Controls to build applications for Android and other platforms. Each platform will provide a low level abstraction layer (drawer ?) to facilitate the rendering of the Custom Drawn controls. That way the controls will draw the same on all platforms.
For Android the Custom Drawn Controls will be drawn using OpenGL because this is a method supported by Google.
Am I correct or am I totally of base ?
Johan
-
Do you know if the plan is to make TCDPageControl so that it can do this?
I implement what I feel like, or what I get paid for, so I can't say for sure, but BiDi is not in my plans at the moment.
-
I am trying to understand how all these pieces fit together so that I can use FPC and Lazarus to build applications for Android devices (because I have tried using the native java method and java is not nice :D) Please correct me if I am wrong:
You can already start testing it, the example in lazarus/examples/androidlcl works for Android 2.2+
The idea is to use the Custom Drawn Controls to build applications for Android and other platforms. Each platform will provide a low level abstraction layer (drawer ?) to facilitate the rendering of the Custom Drawn controls. That way the controls will draw the same on all platforms.
For Android the Custom Drawn Controls will be drawn using OpenGL because this is a method supported by Google.
Am I correct or am I totally of base ?
You are correct except for the OpenGL, I tried going for OpenGL but I disliked it so now I am using jnigraphics + SurfaceView which very efficient too and is the alternative to OpenGL provided in Android. It can be changed to OpenGL in the future if ever required, or even made selectable.
About the Custom Drawn Controls they can currently be put into the form directly, but in the future besides that they will also be used internally to implement LCL basic controls like TButton, TPageControl, etc, in LCL-CustomDrawn.
-
I think I am close to getting the "androidlcltest" application to compile. I had to use version r7 of the android ndk as I cannot find version r5 as described in the demo. I also had to change the libraries path to
/home/jkotze/android-ndk-r7/platforms/android-8/arch-arm/usr/lib/;
/home/jkotze/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3
as the paths seem to have changed between version r5 and r7.
I have compiled LCL-Base without issues and when I try to compile androidlcltest I get the following errors:
androidlcltest.lpr(17,3) Error: Identifier not found "Java_com_pascal_lclproject_LCLActivity_LCLOnTouch"
androidlcltest.lpr(17,53) Error: The symbol can't be exported from a library
androidlcltest.lpr(18,3) Error: Identifier not found "Java_com_pascal_lclproject_LCLActivity_LCLDrawToBitmap"
androidlcltest.lpr(18,58) Error: The symbol can't be exported from a library
androidlcltest.lpr(19,3) Error: Identifier not found "JNI_OnLoad"
androidlcltest.lpr(19,14) Error: The symbol can't be exported from a library
androidlcltest.lpr(20,3) Error: Identifier not found "JNI_OnUnload"
androidlcltest.lpr(20,16) Error: The symbol can't be exported from a library
I think it has to do with the NDK, but what is wrong ? Will it only work with r5 of the NDK and if so, where can I find that older version.
-
Are you using the very latest Lazarus source code from SVN?
-
Yes, checked it out today.
-
Ok, I found a problem with the defines, it should work now if you svn update.
-
We can use alpha in Canvas?
Not yet in TCanvas but in the future it will also support it, at least in LCL-CustomDrawn. Although it is not a priority for me.
In TLazCanvas I so far added only this 1 routine with alpha blending. It copies a piece of another Canvas while executing alpha blending. It will only work if the rawimage attached to the source canvas has an alpha channel, which is always the case in LCL-CustomDrawn except for a Canvas attached to the computer screen, such as a Canvas obtained from a Form or a visual control. In this case it uses the native format and only the Android native format has Alpha from what I know. I added it for font support, because I wanted to make a transparent bitmap, draw the text to it and then alpha blend it to the destination canvas. But now I found out that Cocoa does not support drawing text to a bitmap with non-premultiplied alpha =( In Android it should work fine. But in general I am getting annoyed by those native fonts drawing routines and I'm considering checking how much work it would be to shappen up pasfreetype into being useful here.
All other existing drawing routines like polygon, line, rectangle don't execute alpha blending in TLazCanvas AFAIK, but we could add alpha blend versions of them in TLazCanvas.
PS: Strange, the message from Lainz disappeared...
-
We can use alpha in Canvas?
Not yet in TCanvas but in the future it will also support it, at least in LCL-CustomDrawn. Although it is not a priority for me.
In TLazCanvas I so far added only this 1 routine with alpha blending. It copies a piece of another Canvas while executing alpha blending. It will only work if the rawimage attached to the source canvas has an alpha channel, which is always the case in LCL-CustomDrawn except for a Canvas attached to the computer screen, such as a Canvas obtained from a Form or a visual control. In this case it uses the native format and only the Android native format has Alpha from what I know. I added it for font support, because I wanted to make a transparent bitmap, draw the text to it and then alpha blend it to the destination canvas. But now I found out that Cocoa does not support drawing text to a bitmap with non-premultiplied alpha =( In Android it should work fine. But in general I am getting annoyed by those native fonts drawing routines and I'm considering checking how much work it would be to shappen up pasfreetype into being useful here.
All other existing drawing routines like polygon, line, rectangle don't execute alpha blending in TLazCanvas AFAIK, but we could add alpha blend versions of them in TLazCanvas.
PS: Strange, the message from Lainz disappeared...
Ok. Sorry I've deleted the message I thought I had made a silly question ::) (perhaps in the very moment you were responding)
Nice to hear this, specially can be usefull for loading bitmaps with alpha to theme all the controls from bitmaps.
I've updated TBGRAImageButton now it works like the Windows themes, from a single image the control get each button state. Then resize image borders and image center separately, this causes the control to be resizable from bitmaps and not have to program the graphics in a complex way.
I think that code also can be used for other controls, also can be ported to work with TBitmap.
If you have some time check the code in custombgraimagebutton.inc (in BGRAControls), I will try to port it to TBitmap.
In the image attached at the top a TButton, in the bottom a TBGRAImageButton with 'BitmapOptions' border width and height set to 5.
-
Check this the same with TBitmap.
-
Are you doing pixel-by-pixel access? If yes, then TBitmap is a terrible choice. It is ridiculously slow in LCL-Gtk2 because it is a native Bitmap and in Gtk2 native bitmaps are extraordinarely slow.
Lazarus offers 2 versions of almost everything: 1 native and 1 non-native.
The non-native equivalent of TBitmap is TLazIntfImage+TRawImage. To draw on it use TLazCanvas which is the non-native equivalent of TCanvas.
LCL-CustomDrawn implements almost all it's objects with the non-native equivalents (it will implement TBitmap with TLazIntfImage) so when it evolves we will have a very fast TBitmap in X11.
-
Are you doing pixel-by-pixel access?
this is the code:
unit bitmapthemeutils;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Graphics, types, IntfGraphics;
type
TBmpArray = array of TBitmap;
TBmpArrays = array of TBmpArray;
function GetBitmap(Filename: String; Number: integer): TbmpArray;
function GetBitmapPart(Source: TBitmap; BorderWidth, BorderHeight: integer): TbmpArray;
function GetBitmapElements(Filename: String; Number, BorderWidth, BorderHeight: integer): TbmpArrays;
function DrawBitmap(Source: TBmpArray; DestWidth, DestHeight, BorderWidth, BorderHeight: integer): TBitmap;
implementation
function GetBitmap(Filename: String; Number: integer): TbmpArray;
var
bmpArray: TbmpArray;
temp: TBitmap;
i: integer;
s: TSize;
begin
temp := TBitmap.Create;
temp.LoadFromFile(Filename);
s.cx := temp.Width;
s.cy := temp.Height div Number;
SetLength(bmpArray, Number);
for i:= Low(bmpArray) to High(bmpArray) do
begin
bmpArray[i] := TBitmap.Create;
bmpArray[i].Width := s.cx;
bmpArray[i].Height := s.cy;
bmpArray[i].Canvas.Draw(0, -s.cy * i, temp);
end;
temp.Free;
result := bmpArray;
end;
function GetBitmapPart(Source: TBitmap; BorderWidth, BorderHeight: integer): TbmpArray;
var
bmpArray: TbmpArray;
begin
SetLength(bmpArray, 9);
{ Top Left }
bmpArray[0] := TBitmap.Create;
bmpArray[0].Width := BorderWidth;
bmpArray[0].Height := BorderHeight;
bmpArray[0].Canvas.Draw(0, 0, Source);
{ Top Right }
bmpArray[1] := TBitmap.Create;
bmpArray[1].Width := BorderWidth;
bmpArray[1].Height := BorderHeight;
bmpArray[1].Canvas.Draw(BorderWidth - Source.Width, 0, Source);
{ Bottom Left }
bmpArray[2] := TBitmap.Create;
bmpArray[2].Width := BorderWidth;
bmpArray[2].Height := BorderHeight;
bmpArray[2].Canvas.Draw(0, BorderHeight - Source.Height, Source);
{ Bottom Right }
bmpArray[3] := TBitmap.Create;
bmpArray[3].Width := BorderWidth;
bmpArray[3].Height := BorderHeight;
bmpArray[3].Canvas.Draw(BorderWidth - Source.Width, BorderHeight
- Source.Height, Source);
{ Center }
bmpArray[4] := TBitmap.Create;
bmpArray[4].Width := Source.Width - BorderWidth * 2;
bmpArray[4].Height := Source.Height - BorderHeight * 2;
bmpArray[4].Canvas.Draw(-BorderWidth, -BorderHeight, Source);
{ Top }
bmpArray[5] := TBitmap.Create;
bmpArray[5].Width := Source.Width - BorderWidth * 2;
bmpArray[5].Height := BorderHeight;
bmpArray[5].Canvas.Draw(-BorderWidth, 0, Source);
{ Left }
bmpArray[6] := TBitmap.Create;
bmpArray[6].Width := BorderWidth;
bmpArray[6].Height := Source.Height - BorderHeight * 2;
bmpArray[6].Canvas.Draw(0, -BorderHeight, Source);
{ Right }
bmpArray[7] := TBitmap.Create;
bmpArray[7].Width := BorderWidth;
bmpArray[7].Height := Source.Height - BorderHeight * 2;
bmpArray[7].Canvas.Draw(BorderWidth - Source.Width, -BorderHeight, Source);
{ Bottom }
bmpArray[8] := TBitmap.Create;
bmpArray[8].Width := Source.Width - BorderWidth * 2;
bmpArray[8].Height := BorderHeight;
bmpArray[8].Canvas.Draw(-BorderWidth, BorderHeight - Source.Height, Source);
result := bmpArray;
end;
function GetBitmapElements(Filename: String; Number, BorderWidth, BorderHeight: integer): TbmpArrays;
var
bmpArrayStates: TBmpArray;
bmpArrayParts: TBmpArrays;
i: integer;
begin
bmpArrayStates := GetBitmap(Filename, Number);
SetLength(bmpArrayParts, Number);
for i:=Low(bmpArrayStates) to High(bmpArrayStates) do
begin
bmpArrayParts[i] := GetBitmapPart(bmpArrayStates[i], BorderWidth, BorderHeight);
end;
result := bmpArrayParts;
end;
function DrawBitmap(Source: TBmpArray; DestWidth, DestHeight, BorderWidth, BorderHeight: integer): TBitmap;
var
dest: TBitmap;
begin
dest := TBitmap.Create;
dest.Width := DestWidth;
dest.Height := DestHeight;
result := dest;
//top left
dest.Canvas.Draw(0, 0, Source[0]);
//top right
dest.Canvas.Draw(DestWidth - BorderWidth, 0, Source[1]);
//bottom left
dest.Canvas.Draw(0, DestHeight - BorderHeight, Source[2]);
//bottom right
dest.Canvas.Draw(DestWidth - BorderWidth, DestHeight - BorderHeight, Source[3]);
//center
dest.Canvas.StretchDraw(Rect(BorderWidth, BorderHeight, DestWidth - BorderWidth, DestHeight - BorderHeight), Source[4]);
//top
dest.Canvas.StretchDraw(Rect(BorderWidth, 0, DestWidth - BorderWidth, BorderHeight), Source[5]);
//left
dest.Canvas.StretchDraw(Rect(0, BorderHeight, BorderWidth, DestHeight - BorderHeight), Source[6]);
//right
dest.Canvas.StretchDraw(Rect(DestWidth - BorderWidth, BorderHeight, DestWidth, DestHeight - BorderHeight), Source[7]);
//bottom
dest.Canvas.StretchDraw(Rect(BorderWidth,DestHeight - BorderHeight, DestWidth - BorderWidth, DestHeight), Source[8]);
end;
end.
The non-native equivalent of TBitmap is TLazIntfImage+TRawImage. To draw on it use TLazCanvas which is the non-native equivalent of TCanvas.
LCL-CustomDrawn implements almost all it's objects with the non-native equivalents (it will implement TBitmap with TLazIntfImage) so when it evolves we will have a very fast TBitmap in X11.
I will try.
-
this is the code:
Indeed I don't see pixel-by-pixel access in that code (usage of the property Pixels[x, y]), so what I said doesn't apply here.
But you are using something else dangerous: TCanvas.StretchDraw In my experience TCanvas.StretchDraw can cause problems because the performance and resulting image varies between platforms, and that's why I have written a non-native stretch which stretches like Windows in lazcanvas. I'll document this...
Edit: But maybe in your case TCanvas.StretchDraw will work fine. In any case I documented a lot of stuff here:
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Working_with_TLazIntfImage.2C_TRawImage_and_TLazCanvas
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Introduction_to_the_Graphics_model_of_the_LCL
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Using_the_non-native_StretchDraw_from_LazCanvas
-
Your links are very usefull and easy to understand thankyou.
-
I'm doing something wrong, i want to stretch draw Source[4] (TBitmap) in dest (TBitmap)
function DrawBitmap(Source: TBmpArray; DestWidth, DestHeight, BorderWidth, BorderHeight: integer): TBitmap;
var
dest: TBitmap;
image, temp: TLazIntfImage;
imagecanvas: TLazCanvas;
begin
dest := TBitmap.Create;
dest.Width := DestWidth;
dest.Height := DestHeight;
image := TLazIntfImage.Create(dest.Width, dest.Height);
image.LoadFromBitmap(dest.Handle, 0);
imagecanvas := TLazCanvas.Create(Image);
imagecanvas.Interpolation := TFPSharpInterpolation.Create;
//center
temp := TLazIntfImage.Create(Source[4].Width, Source[4].Height);
temp.LoadFromBitmap(Source[4].Handle, 0);
imagecanvas.StretchDraw(BorderWidth, BorderHeight, DestWidth - BorderWidth, DestHeight - BorderHeight, temp);
temp.Free;
imagecanvas.Free;
image.Free;
...
-
You are forgetting to reload the destination IntfImage back into the TBitmap:
DestBitmap.LoadFromIntfImage(DestIntfImage);
I have rewritten the wiki example to be more complete and more clear:
http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Using_the_non-native_StretchDraw_from_LazCanvas
-
With TFPSharpInterpolation I'm losing a pixel in 'top', 'left', 'right' and 'bottom' borders.
-
Is it fixed now in rev34037?
I do still experience a problem with the top-left pixel in LCL-CustomDrawn, and only sometimes, but no idea so far what the problem is. But for sure it is not in the sharp interpolation.
-
Is it fixed now in rev34037?
Yes now works fine.
-
Are there plans to add Windows7 theme in Custom Drawn Controls like for Windows XP?
-
Are there plans to add Windows7 theme in Custom Drawn Controls like for Windows XP?
Not by me, since I don't even have a Windows 7 computer, but the whole idea of the skins is that users should participate in writting them. Patches are welcome =)
-
Are there plans to add Windows7 theme in Custom Drawn Controls like for Windows XP?
Well I was working of loading from bitmap here is the code both for TBitmap (native and non native stretch) and TBGRABitmap:
Try this code to read images from bitmap and then use as 'theme' like in Windows.
https://sourceforge.net/p/bmpthemeutils/home/Home/
It has both codes for TBGRABitmap and TBitmap. Currently has no objects only functions and procedures.
-
How to install Custom Drawn Controls? There is no info on wiki pages. I have latest Lazarus 0.9.31 from SVN, so can I just install Custom Drawn package from Package -> Configure installed packages -> customdrawn 0.0? This is current version?
-
How to install Custom Drawn Controls? There is no info on wiki pages. I have latest Lazarus 0.9.31 from SVN, so can I just install Custom Drawn package from Package -> Configure installed packages -> customdrawn 0.0? This is current version?
Yes, then you have the 'Custom Drawn' tab with all the controls. Next you need to create a Drawer and register it
something like this
http://lazarus.freepascal.org/index.php/topic,15209.msg81603.html#msg81603
-
I added some info about that here:
http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls#How_start_using_these_components.3F
-
Hi there.
Although i am an old Delphi user, i am completely newbie in Lazarus, so forgive me in advance for my stupid questions.
I would like to make some custom drawn edit controls that are platform free, but without to rewrite all that code concerning the scroll, text selection, cursor etc handling. Could i use the custom drawn controls to do so, and if the answer is yes, then how could i create an edit control that uses a thick frame for example ?
Thank you in advance.
-
Could i use the custom drawn controls to do so,
Yes, althought TCDEdit is not fully complete yet. It is already functional, however.
and if the answer is yes, then how could i create an edit control that uses a thick frame for example ?
Create a new drawer class, register it and override any methods that you want.
Read these source code files to know how to do it:
lazarus/components/customdrawn/customdrawn_winxp.pas
lazarus/lcl/customdrawn_common.pas
Your new drawer would be something like customdrawn_winxp.pas which bases on customdrawn_common.pas
-
felipemdc,
I 've installed the customdrawn.lpk package, but neither the Custom Drawn tab appeared, nor the TCDEdit control. The controls that were installed in Common Controls Tab are, TCDButton, (which creates black marks at corners), TCDTrackBar, TCDPageControl and TCDGroupBox. Unfortunately there are no such files under the directories you 've mentioned. I 've downloaded them from http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/customdrawn, but there is no TCDEdit control in any file.
Thank you once more. :)
-
felipemdc,
My bad. I 've found the problem and corrected it. Now the TCDEdit control exists. No customdrawn_common.pas file though. Anyway, I don't understand how could anyone create an edit control that has a 7 px thick frame without covering the text, or how could i create a combobox with 2 or more custom drawn buttons, which responds differently when the mouse is over them. In Delphi, all i had to do was to define the client area of the windowed control and then draw or add other controls outside of it. Could you help me understand please ?
Thank you so much. :)
-
No customdrawn_common.pas file though.
For sure it exists, nothing works without it. lazarus/lcl/customdrawn_common.pas in latest lazarus svn
Anyway, I don't understand how could anyone create an edit control that has a 7 px thick frame without covering the text
The TCDEdit can have any size. If it is covering the text make it bigger.
In Delphi, all i had to do was to define the client area of the windowed control and then draw or add other controls outside of it. Could you help me understand please ?
You can also add other controls inside your own, although that's not what the drawers are suposed to do. If you need that much customization you might want to write your own control, either basing on the CD ones (by creating a class which inherits from one of them) or not.
-
felipemdc,
I do make the edit control bigger, but the problem is that although i define border spacing big enough, the text inside the edit does not allocate to the middle of the control, so if i draw a thick frame, or if i place another control inside the edit area, then the text hides behind it. Is there a way to define the client area of the control, in order to make enough space either around the text, or to the right of it, in order to design a thick frame, or to place another control, without using APIs, so the entire edit control to be platform free ? The BorderSpacing property does not seem to work, with or without the Autosize set to true.
I have no problem to write my own control based on the CD ones. That is what i had in mind from the begin.
Thank you so much for your patience. :)
-
I do make the edit control bigger, but the problem is that although i define border spacing big enough, the text inside the edit does not allocate to the middle of the control
You can make a bug report about this. A patch would be even better. It should be very easy to fix, just look at the code in customdrawn_controls.pas method DrawEdit or something like that ... but I have a huge ToDo list
, so if i draw a thick frame, or if i place another control inside the edit area, then the text hides behind it. Is there a way to define the client area of the control, in order to make enough space either around the text, or to the right of it, in order to design a thick frame, or to place another control, without using APIs, so the entire edit control to be platform free ?
Adding extra spacing bellow or on the top is not really desirable, but adding an extra spacing to the right or left is a must have feature which is required for example for TCDComboBox implementation... again you can either bug report or send a patch.
-
I get "no registered drawers were found". I just added a TCDButton in a form.
-
I get "no registered drawers were found". I just added a TCDButton in a form.
At design time or at runtime?
Try adding customdrawn_common to your uses clause.
-
I get "no registered drawers were found". I just added a TCDButton in a form.
At design time or at runtime?
Try adding customdrawn_common to your uses clause.
At runtime. That solved the problem, thanks.
-
I've updated bitmapthemeutils v0.0.0.3, now you can test the windows 7 button in a TCDButton with the customdrawn_win7. It's using TBitmap, but you can change it to use TBGRABitmap, just change
win7button: TBitmapThemeUtil;to
win7button: TBGRABitmapThemeUtil;when needed.
If you want other style just change the bitmap file =)
Grab it here:
https://sourceforge.net/projects/bmpthemeutils/
PD: Seems that the drawer has flickering with themes disabled in Windows. There is a memory leak somewhere but I can't find it. Is left to implement the glowing effect that is present when you enable the effects in Windows..
PD2: How I can draw the Enabled := False state?
-
PD2: How I can draw the Enabled := False state?
In the Drawer class in the drawbutton routine you get two parameters: State and StateEx.
To check if the control is enabled do:
if csfEnabled in AState then ...
else ....
Check all posible enum State information in customdrawndrawers.pas type TCDControlStateFlag
Advanced state information goes into StateEx which is different for various controls.
-
Thankyou! it's working now.
The only problem in the CDControls is the flickering when you use it with themes disabled under Windows.
-
The only problem in the CDControls is the flickering when you use it with themes disabled under Windows.
All of them flicker or only using your drawer?
This is very strange, because in customdrawncontrols.pas there is:
{$if defined(LCLWin32)}
{$define CDControlsDoDoubleBuffer}
{$endif}
Maybe I got the define wrong somehow?
-
All of them.
Can be the define because when I use
CDButton1.DoubleBuffered:= True;
CDEdit1.DoubleBuffered := True;
The flickering dissapear.
-
Is it fixed in rev 34449 ?
-
Is it fixed in rev 34449 ?
Doesn't works. The controls starts with DoubleBuffered set to false.
This works:
{$IFDEF WINDOWS}
{$define CDControlsDoDoubleBuffer}
{$endif}
Another thing, in the controls TCDCheckbox and TCDRadioButton in AState csfSunken is always present, I want this only when the mouse is down, like in TCDButton.
Also I have a problem in the Object Inspector selecting the property State in TCDCheckbox. I select one and other is selected.
Another thing is when is enabled AllowGrayed the states are wrong drawed (see image attached, the red rectangle). Are ok when AllowGrayed is set to false (the other CheckBoxes).
You can grab all the code here https://sourceforge.net/projects/bmpthemeutils/ in the git repo.
-
Doesn't works. The controls starts with DoubleBuffered set to false.
This works:
{$IFDEF WINDOWS}
{$define CDControlsDoDoubleBuffer}
{$endif}
Thanks, hopefully fixed now in rev 34452
Another thing, in the controls TCDCheckbox and TCDRadioButton in AState csfSunken is always present, I want this only when the mouse is down, like in TCDButton.
Also I have a problem in the Object Inspector selecting the property State in TCDCheckbox. I select one and other is selected.
Another thing is when is enabled AllowGrayed the states are wrong drawed (see image attached, the red rectangle). Are ok when AllowGrayed is set to false (the other CheckBoxes).
I would recommend sending patches. All issues look easy to fix, but I have 1 zillion things to do... or you can create bug reports and I'll put somewhere in my ToDo.
-
TCDEdit has some issues on drawing the selected text...
:)
-
Thanks, hopefully fixed now in rev 34452
It's working.
I would recommend sending patches. All issues look easy to fix, but I have 1 zillion things to do... or you can create bug reports and I'll put somewhere in my ToDo.
Ok I will try to fix them.
-
I know that I should solve as many problems sending a patch, but I prefer doing it this way to not make mistakes.
This is the patch to fix this: in the controls TCDCheckbox and TCDRadioButton in AState csfSunken is always present, I want this only when the mouse is down, like in TCDButton.
PD: why we can't upload .patch files in the forum?
-
PD: why we can't upload .patch files in the forum?
It has a white list to check for allowed extensions ... probably a black list would be better if all we want is blocking .exe
Please try again, I added .diff and .patch to the allowed extensions
-
It's working now we can upload .patch
-
Try rev 34475, I did a slightly different approach for the fix.
-
Try rev 34475, I did a slightly different approach for the fix.
I'ts working.
-
I've found the memory leak is in TCDButton destroy. There is a bitmap that need to be free. I've added a patch.
I've uploaded BitmapThemeUtils 0.0.0.5. Try it with TBitmap or TBGRABitmap (usefull to load from png files with alpha) but not required.
https://sourceforge.net/projects/bmpthemeutils/files/?
There is a nice thing in the CheckBox, you can use a 'v' tickmark or the hidden and never used in Windows 'x' tickmark. :o
Just change the line 159 in customdrawn_win7.pas
from
number := 4;to
number := 16;
Try the controls with the mouse and keyboard, everything works fine.. but there are a lot improvements to do of course.
See image attached ;)
-
thanks, I applied the memleak fix and added a new dsWindow7 style to the enum in rev34481
-
Thankyou.
There is another memory leak in TCDTrackBar but I can't find where..
In the git of bitmapthemeutils I've added ProgressBar code and images, both bmp and png. The bmp ones has an unwanted white line, the png are ok.
-
Here is the patch for TCDPositionedControl memory leak.
PD: I've seen that there are more memory leak, maybe some of the others are for the same reason.
-
Thanks, applied in rev34545.
> maybe some of the others are for the same reason.
No, this was the only occurence of this particular error.
-
No, this was the only occurence of this particular error.
I see.
Here is another memory leak fix. Now the heaptrc show me 0 unfreed memory blocks in the project 'cd_test_all'
-
Thanks, applied in rev 34569
-
A custom drawn TMenu would be nice. I will take a look into these components code.
-
Hi!
After install customdrawn.lpk it doesn't appeared on Component Pallete.
I tried svn for new a revision...
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/customdrawn ... I get "404 Not Found"...
Someone can help? Thank you!
PS. I am using Release candidate 2 of Lazarus 0.9.30.2 (DATE 2011-11-04 * FPC 2.4.4 * SVN Revison 33306 * i386-win32/win64) on Win64 Seven.
-
customdrawn is for Lazarus 0.9.31+ only, not 0.9.30.2
Downloading some pieces is not recommended. Download instead the entire lazarus trunk svn:
http://wiki.lazarus.freepascal.org/index.php/Getting_Lazarus
-
Ok Felipe.
I installed the
Lazarus-0.9.31-34252-fpc-2.5.1-20111230-win64.exe from "Daily Snapshots"
and now it's there in the Component Palette.
Thanks.
-
Felipe, there is a way to set all controls property DrawStyle?
of course this doesn't works because the property is published in the descendant controls
var
i: integer;
begin
for i := 0 to ControlCount - 1 do
TCDControl(Controls[i]).DrawStyle:= dsWindows7;
-
in customdrawndrawers.pas:
TCDDrawStyle = (
// The default is given by the DefaultStyle global variable
// Don't implement anything for this drawer
dsDefault = 0,
.....
var
DefaultStyle: TCDDrawStyle = dsCommon; // For now default to the most complete one, later per platform
If you change DefaultStyle it will affect all controls with dsDefault style, which is the initial one.
-
Thanks.
Here is attached a fix to cd checkbox:
- Now if you set the state from code or from the object inspector the control set that state and not other.
- Checkboxes that don't has enabled 'AllowGrayed' and you set state as cbGrayed it will be always cbCheched (because if you set it to cbGrayed the control will not work).
See it working in the image.
Edit: please add 'Enabled' property in most CDControls it's working fine, not in the default drawer but as you can see in the image works =)
-
Thanks, applied in rev34890 and I also add Enabled to all controls (I could have forgotten one or two, however).
The only issue with the patch was the identation. It started with 4 spaces in the first level, please keep all patches in the standard LCL identation: 2 spaces for each level. thanks =)
-
This looks great !
-
The way this is developing it seems to me that Lazarus might be able to create apps for even more platforms using custom drawn controls. Perhaps even for DOS ;)
-
The way this is developing it seems to me that Lazarus might be able to create apps for even more platforms using custom drawn controls. Perhaps even for DOS ;)
The Java way. Portable to all systems, but native on none. Maybe we can translate SWING :-)
-
The way this is developing it seems to me that Lazarus might be able to create apps for even more platforms using custom drawn controls. Perhaps even for DOS ;)
Mmm. I WANT my Linux/FreeBSD ncurses+Windows CMD.EXE custom drawn labels, edit boxes, comboboxes, radiogroups and buttons ;)
(Yes, FreeVision/Novell Netware style programming ftw :)
-
The Java way. Portable to all systems, but native on none. Maybe we can translate SWING :-)
You are exagerating, probably based on lack of knowledge. I assume you never actually tested LCL-CustomDrawn. It does almost exactly the same as what Qt does, which is not exactly same as what Java with for example Swing does. Swing is slow, does not work in any mobile platform and looks like crap everywhere, but Qt is skinnable and imitates native widgets so good that you can't tell the difference. CustomDrawn is also skinnable and I already immitate pixel-by-pixel Windows 2000 controls. Lainz is doing a good job with a Windows 7 look and I already started the Android and Windows CE looks.
If it looks exactly the same, pixel-by-pixel why do you say it isn't native? The native API also draws the same pixels on the screen. What difference does it make if the native API draws them or if the LCL draws them?
And to complete: I wonder if you also have the same oppinion of Qt? That it is the same as Swing?
-
felipemdc, I suppose you did not understand what marcov was saying. If you draw a component by yourself, it is not native. BGRAControls are not native, anything that is not already there in the operating system is not native.
About Swing, I suppose marcov means hat we could program the same rendering as Swing, so that a Java user interface could be cloned. In your way of thinking, it would be just another drawer.
Of course, there is another difference about Java and Framework.NET, which is the virtual machine.
-
Mmm. I WANT my Linux/FreeBSD ncurses+Windows CMD.EXE custom drawn labels, edit boxes, comboboxes, radiogroups and buttons ;)
(Yes, FreeVision/Novell Netware style programming ftw :)
Well, why not create FreeVision visual runtime+designtime components for Lazarus? ;)
This might sound crazy at first, but it would be a doable project...
-
The Java way. Portable to all systems, but native on none. Maybe we can translate SWING :-)
You are exagerating, probably based on lack of knowledge. I assume you never actually tested LCL-CustomDrawn.
No, but I have reacted the same to msegui, fpgui (both iterations and fpgtk), and all others attempts. I've wasted enough time on them.
The problem is that not being native is not being rendered (and have the "feel") the way that the user expects. That includes all parameterization based on systems settings.
Of course you can just say "you can emulate all that too, since the native lib also has to implement it", but then you are back at the same problem you balk at in the LCL. A need to go deep.
It does almost exactly the same as what Qt does,
... and on the *nix platforms Qt (or GTK) is what the users expect.
Qt is skinnable and imitates native widgets so good that you can't tell the difference.
Only for platforms they actually invested a crazy amount of work. If you really believe that this can work, why not simply use QT :-)
CustomDrawn is also skinnable and I already immitate pixel-by-pixel Windows 2000 controls. Lainz is doing a good job with a Windows 7 look and I already started the Android and Windows CE looks.
I've never seen a customdrawn UI that didn't fail within one minute of testing. Customdrawn has its place, and it is perfect for less popular targets, but for the tier 1 ports (OS X,Linux or Windows) it is IMHO not an option. I've some doubts on WinCE too.
If it looks exactly the same, pixel-by-pixel why do you say it isn't native?
It is not themable, the feel is not the same, it doesn't respect system font settings. the list goes on. It is only pixel by pixel the same in a simplistic case.
The native API also draws the same pixels on the screen. What difference does it make if the native API draws them or if the LCL draws them?
See above.
And to complete: I wonder if you also have the same oppinion of Qt? That it is the same as Swing?
Outside the core platforms (Linux, FreeBSD etc): yes. I use pgadmin daily, and it isn't exactly close to a native windows app. The minute I can change it for something native I will.
-
In fact such custom draw controls and complete controls ecosystem should be base and entry point for implementing specific native components. Than CustomDraw could be called "native to Lazarus/FPC" or sort of. And all other platform specific widgetset should be implemented after as second phase as more suitable and "native to platform" solution but harder to maintain.
There is possibility to draw CustomDraw on HTML5 canvas in "native to LCL" way and after that implement "native to HTML" layer which would be specific better looking controls.
So custom drawn components are welcomed for fast migration to future platforms.
And custom draw widgetset can offer advanced controls which aren't present on other supported widgetset. FireMonkey show such possibility.
-
I've updated the bgracontrols customdrawn_win7 drawer with the 'luna' theme (Windows XP theme).
luckily the windows xp msstyles had High DPI images so it was easy ;D
You can download it with bgracontrols latest svn or git.
(I've not updated the bitmapthemeutils one because I'm lazy to know how to use the lazarus png graphics loading and manipulation. Feel free to 'port' the TBGRABitmapThemeUtil / TBitmapThemeUtil to the graphic library you want).
If someone want I've all the png of the three themes (luna, aero and aero lite), 1.68 MB 7zipped file.
-
Btw. what happens when the XP Luna theme is changed to MCE/Energy/Royale or Zune or Embedded?
-
Btw. what happens when the XP Luna theme is changed to MCE/Energy/Royale or Zune or Embedded?
Also what happens when the Windows XP theme related dll are patched with uxpatcher and the user download and install between thousands of non-microsoft digitally signed user made themes?
You get the Custom Drawn XP Luna, wathever the theme is being used by the os in the controls supported by the drawer and those supported by custom drawn. Also you get XP Luna in Linux, MAC OSX and other compatible OS's (in this drawer, compatible with custom drawn and bgrabitmap).
-
Answering to Marco:
I think you have no idea how much effort it is to write a new LCL widgetset. To write a new LCL-Cocoa interface because some asshole in Apple killed Carbon is aprox. 5 years of a lot of dedication, a huge lot of work. Do you know how much pain we went through migrating from Gtk to Gtk2??? Who here wants to spend the next 25 years of his life in wasted effort? Reimplementing the LCL again and again and again because some big shot executive has a new favorite "new way of reinventing the whell"? I don't. That's why I am writing LCL-CustomDrawn instead. But be my guest to send patches for LCL-Gtk3. Just don't tell me I didn't warn you when it becomes obsolete and your years of effort go down the toilet.
On top of that, have you ever seen our features list? It is *huge*. Every single control has tons and tons of features. And the native controls come very, very short of being able to implement our features. So then it starts the huge hack work of trying to hammer controls which were never written to implement LCL APIs into doing that. Seriously, why do you think that the native widgetset will have a list view which fits TListView? They don't have! Or have a buggy one. Apple is specially nasty here that they have a powerful list view for their own use but offer only a crippled one for 3rd parties to use. And you have no way to work around bugs in the native library. And then it starts the waste of time. It wastes my time when I have to reimplement the same features 5 times. It wastes my time when Apple kills Carbon and Microsoft kills WinCE. It wastes my time when I am working on a program, test it in Linux and it does not work perfectly out of the box in Mac due to widgetset differences. LCL-CustomDrawn will work perfectly. Implement all features perfectly. And work perfectly the same in all platforms. The look is irrelevant, you can change it to anything you want.
Why not use Qt? You know very well. The C++ connecting library is a serious problem and Qt is a huge library. Not to mention mobile platforms where you want to keep your size down. My Android APK is currently 1,6MB and it could be even smaller if FPC smartlinking worked better in libraries. And on top of that I have enough balls to eat my own dog food. LCL-CustomDrawn is implemented with the LCL. And that is very powerful, the ultimate test for my sub-window and drawing system is the fact that all controls are implemented on it, so they all test it extensively
Outside the core platforms (Linux, FreeBSD etc): yes. I use pgadmin daily, and it isn't exactly close to a native windows app. The minute I can change it for something native I will.
I hope that you are aware that "Windows native" is obsolete. Microsoft changed it for Ribbons. Ops, but Ribbons are already obsolete too! They changed it for Metro. So how native will your native app be when Ribbons come to your desktop? How native will it be when Metro comes to your desktop?
-
Btw. what happens when the XP Luna theme is changed to MCE/Energy/Royale or Zune or Embedded?
Colors are respected if you are using a custom drawn drawer in its native environment, for example Win2000 drawer in any desktop Windows will respect the hi-contrast color choices and this is important for accessibility.
As for themes themselves they are completely banned from custom drawn because we have our own system for themes. And I don't know anyone which uses them anyway. And anyway those themes are futile and iTunes, Microsoft Media Player and tons of other software don't respect those themes anyway. In the long run we can add a themes configurator which can change all LCL apps in a given computer.
People that want controls which will follow the current Windows theme should stick with LCL-Win32. I never said that LCL-CustomDrawn will be the only widgetset available.
-
Felipe there is a way to access all properties of a control?
Because I'm trying to add new buttons in the same drawer.
I already added:
type
TWin7ButtonStyle = (bsNone, bsArrowLeft, bsArrowRight);
TCDButton = class(customdrawncontrols.TCDButton)
public
property Win7Style: TWin7ButtonStyle;
end;
To use in this way:
CDButton5.Win7Style := bsArrowLeft;
But in the drawer I can't acces the property =)
-
There is a separation to make the drawers independent from changes in the controls. To add more info do like this:
TMyCDButton...
protected
procedure CreateControlStateEx; override;
procedure PrepareControlStateEx; override; // <-- Check how controls in customdrawncontrols.pas do those overrides
TMyCDButtonStateEx = class(TCDButtonStateEx) // TCDButtonStateEx comes from customdrawndrawers.pas
public
whatever extra info
end;
And in the drawer you can use the is operator to check if the stateex is your extended version and then cast to it.
-
Thankyou.
ok this will be useful to create a custom drawn bgrabutton.
since those special buttons do not use caption I chose not to make a new control and left them in extra1 =) changing from one style to other with caption (for now).
-
First of all, customdrawn lcl is great beginning.
IMO when it will be mature enough, there just will be no
need it other widgetsets.
I hope to see lazarus drawn with it some day.
Close buttons on editor tabs, that's what I wanted under win :)
My question is:
Can controls be rendered with hardware support (where available) ?
I mean like FireMonkey in Delphi ? What's better way to implement it ?
-
Can controls be rendered with hardware support (where available) ?
I mean like FireMonkey in Delphi ? What's better way to implement it ?
The architecture was created thinking about this, but is not currently implemented. New backends would be required for this, for example a backend for OpenGL, OpenGL ES and/or DirectX.
-
The architecture was created thinking about this, but is not currently implemented. New backends would be required for this, for example a backend for OpenGL, OpenGL ES and/or DirectX.
Can you please describe just brief steps how this can be done or link to wiki.
I'd like to try myself to create some h/w accelerated controls.
Need a point to start from.
-
Can you please describe just brief steps how this can be done or link to wiki.
I'd like to try myself to create some h/w accelerated controls.
Need a point to start from.
You have to read and familiarize yourself with the source code of LCL-CustomDrawn:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/customdrawn/?root=lazarus
There is a define for each backend. You need to add a new backend and implement everything necessary.
-
Можно ли на форму с Custom Draw Widget рисовать openGL окно или нужно создавать свое окно?
Is it possible to form with Custom Draw Widget drawing openGL window or need to create its own window?
-
Support for a sub-window with OpenGL support is possible but currently not implemented.
-
Hi Felipe, how I can enable the debug VerboseCDPaintProfiler? And how I can read the output of that.
And here debug information defines:
VerboseCDPaintProfiler - Adds profiling information to indicate how fast the paint event is processed
-
Define it in the file lcl/interfaces/customdrawn/customdrawndefines.inc
-
It's already defined, but how I can read the output of that?
-
In the console, like always. If you are in Windows uncheck the option "win32 graphical program" (or similar name) in the Project Options dialog
-
Hello, I'm testing TCDPageControl, when I use nboShowCloseButton the close button placed incorrectly if TCDTabSheets caption length are not equal.
Any one realize this?
-
Please create a bug report about this in our bug tracker. Even better if you could come up with a solution and attach a patch which fixes the issue ;)
-
Issue reported: http://bugs.freepascal.org/view.php?id=21707 :)
-
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.
-
This is alive?
-
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.
-
Coming from MSEide+MSEgui (another custom drawn widgetset which I develop), I can confirm. It is a task of at least 10'000 hours.
-
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.
-
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.
-
Why don't the 3 of you join forces and make one Custom Drawn widget set for Lazarus?
Just wondering.
-
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.
-
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.
-
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!
-
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.
-
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. :-)
-
- 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...
-
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?
-
I tried to install MSEgui some time ago but could not install (compile) on Linux Ubuntu 64 bit, FPC 2.7.1. I
Sure, FPC trunk is not supported because it is not ready for use for MSEide+MSEgui, some things are "not yet decided". Please use FPC 2.6.2 or fixes_2_6.
-
Hi,
How it is done? Do you draw everything yourself or does MSEide and fpGUI something like Themes and ThemeServices, where you can dig image from system (i.e. you request image of button and underlaying widgetset will paint it itself for you).
Thanks.
-
MSEgui and AFAIK fpGUi too draw everthing without help of external services beside of X11 on Linux and gdi32 on Windows. MSEgui also has an experimental OpenGL backend and can produce Postscript.
-
i like MSEgui , i've wrote some apps with it , but i'll vote for mseide as the best ide for fpc only if focuse more to ( code complition , documentation , avoid sepatated windows , reduce the number of properties of controls and let only the useful ones , provide a valide instalation file ..) and if possible a mac version
-
avoid sepatated windows
'View'-'Panel'-'New Panel', now you can dock the windows in the panel. In main window below the main menu there is a dock area too.
-
i can't dock vertically , the fact that every project has its own IDE layout is annoying . how can i make a layout that will not be changed whenever open new project ?
-
I am working on a much different design then all of the above. nothing like the delphi model at all. built on a custom linked list design where all things are connected and container classes don't exist. it has a scripted frontend which is built into the core and touches all parts of the framework even the shaders. the goal of the Explorer model is to create an easy to learn easy to use 2d/3d framework. not for the business model but for creative minds who want to explore the future. game engine design,graphic tool development,education software all of these are poorly repesented with the current model and in most cases to bloated.
I am only using a very minimum dependency. xlib which provides only the very minimum window interface so eventually it will require little work to expand to sdl or others. opengl 3.0+, openal,freetype2. the explorer will be pure orignal design. things like xml and others will not exist except to import or export to an from. the gui is scripted of course and very minimal, more like containers with purpose. expansion will be done by child objects and the scripted interface so you don't get stuck fighting with someone elses code every time you try to do something new. the canvas area is completely seperate from the gui so one can create as many different looks as desired. of course some are more expensive then others and all texturing is done by the cpu at this point. this is not a big problem since these textures only get redrawn when something actual changes and the canvas area is quite capable of pre-rendering the more expensive stuff aside from that it is quite powerful and getting better all the time.
-
@Carver413 - sounds interesting. Do you have any preview? Most of my projects are non business, like chats programs, etc where nice unconventional interface is most important (attached screen of one of my app based on BGRA Controls). So your framework fits perfect for my needs
-
@Dibo
http://www.pascalgamedevelopment.com/showthread.php?13312-Carver-Explorer
if you follow the thread to the end you can see some of the more resent stuff. I have alot of example renders that I haven't posted. still alot of refactoring going on so it hard to do alot of themes yet because they end up being broken with all the changes. I am working on a new brush system to make it more theme friendly currently you have to rebuild the brush every time you want a new brush so much time is wasted on that. it will also group things in a much safer way. brushes often have a few pieces that make up a brush so it would be better to contain them within the bush so the go away together. I like the Bgra but it just didn't fit my design model so I didn't use is.
-
i can't dock vertically
Drag the grip to the opposite window edge in order to switch tiling horizontal-vertical. Drag the grip to the center of the window in order to switch to tabbed docking. Click on the small button in the window corner with the circle symbol in order to show the grips of the docked windows.
, the fact that every project has its own IDE layout is annoying . how can i make a layout that will not be changed whenever open new project ?
You can load a layout of another project by 'View'-'Load Window Layout'. Make a new project template by 'Project'-'Save as', save it in your template directory (normally apps/ide/templates). Project templates are normal *.prj files, there is no difference.
Tips for your form: tcaptionframe has the property "caption" which can be used instead of additional tlabels.
-
Most of my projects are non business, like chats programs, etc where nice unconventional interface is most important (attached screen of one of my app based on BGRA Controls).
Such things can be done with MSEgui too:
http://almin-soft.fsay.net/index.php?multimedia/xelplayer/xelplayer-screenshots
-
any plans when mse or fpgui will target mobile? if we miss this we miss the next decade...
the same way that delphi missed web 10 years ago ...
-
I made experiments with an OpenGL backend. It is not easy to achieve good performance on all devices because there are so many different implementations all with different extensions, limitations and bugs. ;-)
I don't think it is a good idea to use an universal tool for mobiles anyway. Possibly it is the best to use the native tools of the mobile platform.
On desktop computers it is another story, there it is possible to build high quality applications with an universal tool like MSEide+MSEgui or fpGUI or Lazarus.
-
so for uniform mobile apps we must migrate to js +html + css + phonegap ? >:D
-
Probably. :-)
-
let's continue this talk on your forum :)
i just subscribed ... i have an idea i i will be happy to share with you ...
-
Please use the mailing list:
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
NNTP gateway is here:
nntp://news.gmane.org/gmane.comp.ide.mseide.user
Archive:
http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/
-
now it's time to escape from the shadow of delphi and work on gui that si simple to use across platforms
And with that, you will not convince the core Lazarus team. They live and breath Delphi. They only wish to be a clone. Unfortunately it seems FPC wants to do the same.
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
fpGUI checks all those boxes already. fpGUI already has an AggPas backend - simply compile the framework with 'AggCanvas' compiler define enabled. After the next release I'll start paying more attention to this backend, and probably make it the default backend - instead of X11 or GDI.
But once again lazarus must be the fundation of all this process
As Martin keeps asking..why? LCL is buggy, that is why I moved away from it. fpGUI already does everything you described as requirements... MSEgui probably too. So why must we leave your years of work and start from scratch. No chance. The best you will get from me is LCL-fpGUI, but that is not a high priority for me, so I only occasionally supply patches.
Anyway, to get back to the actual message thread. I got an update from Lazarus Trunk to test LCL-CustomDrawn. My most basic application using LCL-CustomDrawn couldn't even run. I had to hack some LCL widgetset code (color palette code) to get it to just run. Most basic components don't work. No popup menus in edit box, cursor blinking inconsistent (then in blinks damn fast, then in stops blinking for 10 seconds etc). PageControl and Tabsheets are totally useless. Tabs don't scroll, content in tabsheets appear over tabs. only the first tabsheet's controls appear, even if I click on other tabs. etc. So hence my earlier statement... LCL-CustomDrawn is still in Alpha state, and years away from being usable. I'm sure Felipe would welcome any contributes in this regard.
-
@Graeme: I agree with you but do you plan to target mobile platforms?
-
Exactly, I support strongly the idea of own drawn controls and can't wait for new fpGUI release with Agg. This is the future..
Thanks Dibo. As for your list of issues... as you guessed, I am already working on all of them. fpGUI with AppPas backend doesn't painting on all supported platforms very well in general. Still one or two minor issues to fix, and then the font name resolution (translating fpGUI style font descriptions to font file names).
-
BTW: What is tiopf in fpgui? Why it is related to fpGUI?
There shouldn't be any tiOPF code in fpGUI any more. I use and maintain tiOPF (Object Persistente Framework) for all my commercial [and lots of personal] work - it manages my Business Object mapping to Database Servers. Years ago I implemented the Model-GUI-Mediator (MGM) design pattern - something very similar to Model-View-Controller or Model-View-Presenter. MGM allows any standard widget to become "object aware" - thus I don't need DB-aware copies of all my widgets. My MGM implementation in tiOPF supports Delphi VCL, Lazarus LCL and fpGUI - called mediators. For a while I kept the tiOPF fpGUI mediators in the fpGUI repository, but since moved all mediator code into the tiOPF repository. Having them inside the tiOPF repository makes more sense.
-
Thanks Graeme for explanation. Could you say how much work left to do to the next release? Do you have any date for release?
-
any plans when mse or fpgui will target mobile?
Currently I limit fpGUI to desktop and embedded systems (WinCE, Linux-ARM like Raspberry Pi, handheld scanners etc). I welcome contributions in that direction though. But like Martin, I think for mobile phones and tables, it is better to use the native design tools and frameworks. Cross-platform frameworks never work very well on such mobile devices.
-
Could you say how much work left to do to the next release? Do you have any date for release?
I should have released in January, but keep finding more things I want to add first. ;) I really should just push out a release and if needed push out more in 2-3 months time. Once a year is too long to wait. Alternatively, I recommend developers simply use the code repository directly. I use fpGUI in my commercial work, so I try to keep it always in a stable and buildable state.
-
I think for mobile phones and tables, it is better to use the native design tools and frameworks
Exactly. That's why I learned java and eclipse to write native applications for Android. Never tried, but seems that FPC JVM could be a good alternative. It can use native android API and interface with pascal syntax
-
Here an image in order to show some of the possibilities MSEgui provides out of the box.
-
Alternatively, I recommend developers simply use the code repository directly
I will do when it include fixes for transparency :P . Two questions:
1. What is a stage of miglayout? I saw some commits in git log, but can't find any demo in examples
2. Do you using Agg render in your comercial products also? Can it draw on X11 and GDI (32 and 64 bit)?
-
Here an image in order to show some of the possibilities MSEgui provides out of the box.
Is there documentation for controls styling? I'm trying to open facedemo, can compile but source editor doesn't show any files, it's empty
-
Please ask MSEgui issues on the MSEgui mailing list, links are above.
http://www.lazarus.freepascal.org/index.php/topic,15209.msg117974.html#msg117974
In order to edit the form: 'File'-'Open', select "main.pas".
-
1. What is a stage of miglayout? I saw some commits in git log, but can't find any demo in examples
No demos yet. I'm still working on implementing the layout engine. Once done, it should work and behave exactly like the Java counterpart. For now you can take a look at the Java demos to see how it will work.
2. Do you using Agg render in your comercial products also? Can it draw on X11 and GDI (32 and 64 bit)?
We do some graphics rendering on a specialised canvas - using the AppPas API directly. I haven't switch any of our products to using only the fpGUI AggPas backend - though I have done many tests by enabling it. Except for font handling, everything works like it did before (mostly at least). Once completed, and if I did my job correctly, all existing fpGUI apps should continue to work as normal, just with better graphics support, anti-aliased drawing, alpha support in images etc. DocView, fpGUI UI Designer, Sprite Demo etc all work as expected - bar the font handling.
-
Here an image in order to show some of the possibilities MSEgui provides out of the box.
looks good, i think this is the deference between lazarus and mseide/msegui , msegui gives too much possibility to the designer . make the interface design much fun , ppl just don't realize the power msegui.
but thats because of the lack of documents and good demos .
-
so for uniform mobile apps we must migrate to js +html + css + phonegap ? >:D
Since when is anything "web" uniform? Just set the font a bit higher in a browser, and most already screw up the layout.
-
Since when is anything "web" uniform? Just set the font a bit higher in a browser, and most already screw up the layout.
We seldom agree, but with that we definitely agree. :-D The web is anything but uniform or standardised.
-
oh! ok! so, we do not need do write mobile apps at all -?pascal will stick to desktop until his dead ;))) come on! where did i wrote that mobile app = web app? just the oposite ... we need a mobile framework to avoid phonegap ... 10 years ago lazarus desktop was not uniform - remember? so a little efort to build a mobile lazarus?
-
oh! ok! so, we do not need do write mobile apps at all -?
I don't know. I think it depends on why you are writing mobile apps.
pascal will stick to desktop until his dead ;)))
Your words, not mine. Personally I think the current form and business models of mobile computer will be dead sooner than the current form of desktop computing.
come on! where did i wrote that mobile app = web app? just the oposite ... we need a mobile framework to avoid phonegap ... 10 years ago lazarus desktop was not uniform - remember? so a little efort to build a mobile lazarus?
You call something little effort and 10 years in one sentence ?:-)
If you feel so strongly, start working on it? Personally I don't believe the current mobile platforms are stable enough for such long term crossplatform developments as Lazarus.
-
If you feel so strongly, start working on it? Personally I don't believe the current mobile platforms are stable enough for such long term crossplatform developments as Lazarus.
Ideally, a "mobile platform" should simply be a light weight distro of Linux, with a window manager made for small screens. That would be ideal.
-
Currently I limit fpGUI to desktop and embedded systems (WinCE, Linux-ARM like Raspberry Pi, handheld scanners etc).
With more then a million Raspberry Pi devices out there, Pi App Store becomes an attractive target. Maybe you can pack fpGUI for it? Seeing how other non-Pascal tools are slow and limited on Pi, I am sure it could be a win-win.
http://store.raspberrypi.com/projects?category=all&sort-by=price-high&status=finished&store=pi&sku-type=all&category=dev-tools
I welcome contributions in that direction though. But like Martin, I think for mobile phones and tables, it is better to use the native design tools and frameworks. Cross-platform frameworks never work very well on such mobile devices.
Smart Mobile Studio has an interesting approach in targeting mobile devices. Not for all usage scenarios, but still interesting.
http://smartmobilestudio.com
-
Just started to experiment wiuth custom drawn Controls.
I placed a tCDButton on a form, and the button renders ok.
When I run the application it renders much differently, ie I get a dotted line as a bevel.
is there a way to change this?
i was assuming that custom control would give my access to all drawn parts, ir change the border color, width and style as well as background and text.
Am I missing something.
Win 10 64, laz 1.8rc5
uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs,
CustomDrawnControls,customdrawn_common;
-
That looks like the indicator that the control is selected (in focus). Nothing to do with the bevel. Try tabbing away from it, or click on something else.
-
Hi Eric,
Thanks, I had noty thought of that. That indeed what was causing that.
Can I stop that?
-
Can I stop that?
It's called the Focus Rectangle. In fpGUI (another custom drawn toolkit) you can modify how the focus rectangle renders. Maybe the same can be done in the LCL Custom Drawn widgetset.
Alternatively, use a TSpeedButton which doesn't allow keyboard focus - so you can only activate it with a mouse. This is often used in application toolbars. fpGUI's TfpgButton supports everything in one control..... Images, non focusable state, embedded button state, group state (when combined with more buttons), multi-line captions etc. That's the beautif of custom drawn controls - there really is no limit in what they can do.