About Carbon components development

[abb]

Hi, All,

I've reviewed the docs, suggested for newbies, related to Carbon widgetset, and now I have some suggestions.

As far as I've understood, each new Carbon component development should be started from a usual LCL component development. At least a "canvas" of such component should be created in order to have the ability to insert it into Component Palette. Then a widgetset component stub should be created. And finally a Carbon widgetset component itself can be developed.

Is the framework description above correct? If yes, then I have a question.

Can the LCL component be designed as an abstract class, having only the nesessary methods (like constructor, destructor, Paint) for its designtime usage only?

Am I correct in my understanding that "common widgetset stub" is required for compatibility only and can be done as pure abstract class? At least existing Carbon components like TButton have common widgetset units with empty implementations.

If all the above is correct, I beleave that it would be very helpful for new potential Carbon components developers (like me) to get a canvas for such new component, like TCustomControl, which would include both LCL, Common widgetset and Carbon widgetset units and could be easily installable into LCL palette with class name as "TCustomControl". Such component could do nothing but paint on its canvas something like "Custom Control" text, using its Paint method.

A supplied instruction is needed about how to install such component into LCL palette. Do not insert it into palette, but just _describe_ how to do it. Then a new developer could easily start his work from this unit  modification and attempt to insert this modified component into the LCL palette. I beleve it could simplify the startup process - the most dificult step of the introduction into Carbon development.

Also it would be helpful to have a list of links to a most important units, such as screen drawing, taking into account that main drawing library is changed in the last version. Having such links collected in one place would be a great help for beginners.

Of course, it is not nesessary to mention that all such samples may not use any deprecated/obsolete functions and libraries.

Is the above anything you, guys, could create for us?

[Marc]

Hi, All,

I've reviewed the docs, suggested for newbies, related to Carbon widgetset, and now I have some suggestions.

As far as I've understood, each new Carbon component development should be started from a usual LCL component development. At least a "canvas" of such component should be created in order to have the ability to insert it into Component Palette.

Having a canvas has nothing to do with the ability to show in hte component palette. The only requirement is that is a TComponent descendant which get registered.

Then a widgetset component stub should be created. And finally a Carbon widgetset component itself can be developed.

Yes, on order to offer an abstract interface to the LCL this stub is needed. Each widgetset can then fill in the empty methods

Is the framework description above correct? If yes, then I have a question.

Can the LCL component be designed as an abstract class, having only the nesessary methods (like constructor, destructor, Paint) for its designtime usage only?

No, since the LCL doesn't paint controls. The display of widgets is in control of the widgetset.

Am I correct in my understanding that "common widgetset stub" is required for compatibility only and can be done as pure abstract class? At least existing Carbon components like TButton have common widgetset units with empty implementations.

Are you refering to the carbon code bofore or after SVN revision 10753 ?

If all the above is correct, I beleave that it would be very helpful for new potential Carbon components developers (like me) to get a canvas for such new component, like TCustomControl, which would include both LCL, Common widgetset and Carbon widgetset units and could be easily installable into LCL palette with class name as "TCustomControl". Such component could do nothing but paint on its canvas something like "Custom Control" text, using its Paint method.

I'm loosing you here. Someting like TGraphicControl ?

A supplied instruction is needed about how to install such component into LCL palette. Do not insert it into palette, but just _describe_ how to do it. Then a new developer could easily start his work from this unit  modification and attempt to insert this modified component into the LCL palette. I beleve it could simplify the startup process - the most dificult step of the introduction into Carbon development.

Do you want to implement new controls, or existing carbon widgets ?

Also it would be helpful to have a list of links to a most important units, such as screen drawing, taking into account that main drawing library is changed in the last version. Having such links collected in one place would be a great help for beginners.

Keep in mind that most controls arent drawn by the LCL nor by the widgetset specific implementations. It is done by the widgetset libs/OS
Also, when adding custom controls, it means that the have to be implemented for gtk/win32/wince also

Of course, it is not nesessary to mention that all such samples may not use any deprecated/obsolete functions and libraries.

Is the above anything you, guys, could create for us?

Its not clear yet.

[abb]

Having a canvas has nothing to do with the ability to show in hte component palette. The only requirement is that is a TComponent descendant which get registered.

Does it mean that any TComponent descendant will be shown in the palette without extra code writing (but its registering code, ideed)?

No, since the LCL doesn't paint controls. The display of widgets is in control of the widgetset.

What is that we see at LCL palette? I thought the contents is just the same regardless to the widgetset chosen.... Is'nt it correct? When I choose Carbon as a target widgetset, I don't see any changes in the palette... At the same time not all components really have their Carbon implementations. Therefore we can't see widgetset-related components in the palette, right?

Are you refering to the carbon code bofore or after SVN revision 10753 ?

Sorry, I didn't use SVN. I have the 03/13 snapshot. Isn't it what I need to have?

I'm loosing you here. Someting like TGraphicControl ?

I'd say TCustomControl in Delphi terms, because TGraphicControl is a bit different substance -- it has no its own messaging and painting engines. It is drawn by its windowed parent. I have in mind full-featured control, having window and capable to contain other controls.

Do you want to implement new controls, or existing carbon widgets ?

Most of basic controls are already done. But there are no really useful advanced controls. To start anything really interesting I need at least anything like:
-- a TreeView component;
-- a plugin panel component (e.g. capable to contain Flash plugin);
-- a HTML displaying component like we have for Win32 at www.pbear.com

But for the start I need to learn how it all is working, therefore I need to train on a more simple components. And the most important are:
-- TCanvas
-- TBitmap
--TImage (capable display BMP, GIF, PNG and JPEG)
As I understand not all of such classes are installable components. E.g. TCanvas is an inner class. Nevertheless I'd like to know how to create such class and how to test/debug it. As I see the debugger is working only for GTK wdgetset, right?

Keep in mind that most controls arent drawn by the LCL nor by the widgetset specific implementations. It is done by the widgetset libs/OS

You're talking about native Carbon controls, like buttons, checkboxes, etc. But I had in mind some custom controls, completely created in code, though with use of standard drawing functions, mouse and keyboard event handling, etc.

Also, when adding custom controls, it means that the have to be implemented for gtk/win32/wince also

My goal is to implement them in Carbon. Can be some component first implemented in Carbon and then in other widgetsets?

Thanks.

[Phil]

Sorry, I didn't use SVN. I have the 03/13 snapshot. Isn't it what I need to have?

Get today's Lazarus snapshot. Another huge patch from Tom G. has been applied within the last couple days that adds a lot to the Carbon widgetset.

[abb]

Get today's Lazarus snapshot. Another huge patch from Tom G. has been applied within the last couple days that adds a lot to the Carbon widgetset.

Have got it. As I see, there are TCanvas and TBitmap classes. WOW!

OK, but it would be still good to have a sample or a tip of how to create TImage component. BTW, have anybody any experience in existing JPEG/PNG/GIF/BMP code portation from Delphi? As for BMP, does TCarbonBitmap support Windows BMP loading?

Also what you think about a possibility of Graphics32 (www.g32.org) library portation into Carbon?

Also it would be great to hear about Tom G. next plans in order do not try to invent a wheel...

Thanks.

[abb]

Get today's Lazarus snapshot. Another huge patch from Tom G. has been applied within the last couple days that adds a lot to the Carbon widgetset.

I've done a small test for TBitmap and TCanvas:

Code: [Select]

procedure TForm1.Button1Click(Sender: TObject);
var
  bm : TBitmap;
begin
  bm := TBitmap.Create;
  bm.PixelFormat := pf24bit;
  bm.Width := 100;
  bm.Height := 100;
  bm.Canvas.Pixels[0,0] := 0;
  StaticText3.Caption := 'Button 1 is clicked ' +
                                   IntToStr(bm.Width) + ' ' +
                                   IntToHex(bm.Canvas.Pixels[0,0], 8);
  bm.Free;
end;
But bm.Canvas.Pixels[0,0] is always $1FFFFFFF, though bm.Width is 100. Why?

As a rule I don't ask similar questions in Delphi forums, but unfortunately I have no idea of how to debug the "Carbonized" project in Lazarus, because inline debugger works only with GTK...

Am I wrong?

[Phil]

Also it would be great to hear about Tom G. next plans in order do not try to invent a wheel...

The plans are here:

http://wiki.lazarus.freepascal.org/Carbon_interface_internals

[Phil]

As a rule I don't ask similar questions in Delphi forums, but unfortunately I have no idea of how to debug the "Carbonized" project in Lazarus, because inline debugger works only with GTK...

You should be able to use the external debugger with your .app bundle:

  gdb project1.app/contents/macos/project1

[Marc]

or set the launching application to /full_path_here/project1.app/contents/macos/project1

[Marc]

Does it mean that any TComponent descendant will be shown in the palette without extra code writing (but its registering code, ideed)?

Yes

What is that we see at LCL palette? I thought the contents is just the same regardless to the widgetset chosen.... Is'nt it correct?

What you see in the componentpalette are the registered components. These are for all widgetsets the same set.

When I choose Carbon as a target widgetset, I don't see any changes in the palette... At the same time not all components really have their Carbon implementations. Therefore we can't see widgetset-related components in the palette, right?

You alway see all components, that is the whole idea of a widgetset independent IDE. Since carbon is still in development, you cannot add all components to a form.

Are you refering to the carbon code bofore or after SVN revision 10753 ?

Sorry, I didn't use SVN. I have the 03/13 snapshot. Isn't it what I need to have?

A SVN revision tells me more than a snapshot date, but since you already got the latest it isn't important anymore.

I'd say TCustomControl in Delphi terms, because TGraphicControl is a bit different substance -- it has no its own messaging and painting engines. It is drawn by its windowed parent. I have in mind full-featured control, having window and capable to contain other controls.

Now I understand. If there is already such component defined in the palette, you can implement it in the widgetset itself, preferely with native components and drawing (not using the overhead of a canvas and such)

Most of basic controls are already done. But there are no really useful advanced controls. To start anything really interesting I need at least anything like:
-- a TreeView component;
-- a plugin panel component (e.g. capable to contain Flash plugin);
-- a HTML displaying component like we have for Win32 at www.pbear.com

The LCL treeview is at this moment a LCL drawn control without native implementation. This will change someday however.

the other 2 can be added as package. see the Lazarus CCR for this. IIRC ipro can also render html.

But for the start I need to learn how it all is working, therefore I need to train on a more simple components. And the most important are:
-- TCanvas
-- TBitmap
--TImage (capable display BMP, GIF, PNG and JPEG)
As I understand not all of such classes are installable components. E.g. TCanvas is an inner class.

I guess you found them

Nevertheless I'd like to know how to create such class and how to test/debug it. As I see the debugger is working only for GTK wdgetset, right?

The debugger is widgetset independant, so you can also debug carbon apps.

You're talking about native Carbon controls, like buttons, checkboxes, etc. But I had in mind some custom controls, completely created in code, though with use of standard drawing functions, mouse and keyboard event handling, etc.

In theory those doesn't have to be done in the widgetset itself, they also can be drawn my the LCL (i've some plans to add a thememanage for this to allow themed drawing)

My goal is to implement them in Carbon. Can be some component first implemented in Carbon and then in other widgetsets?

that is possible, see how the widgets are implemented for carbon now.

But I think for those non standard components it is better (as a start) to add them to a package.

[abb]

The debugger is widgetset independant, so you can also debug carbon apps.

Could you please describe it to me in few words? I'm trying to launch the project in debugger (using IDE) but nothing happens -- it looks like IDE can't run my app. I think it is because it is just an executable but not the APP structure. You said that I need to set "launching application" to my executable within APP structure. If so, maybe it would be a solution to prepare APP structure with all nesessary files and assign the compiled application path in Lazarus settings to the Contents/macos/ subdirectory of this APP structure? Will IDE then be able to run my project? Or how do you prepare your Carbonized applications to debug them in IDE?

I've forgotten to say that "nothing happens" above means that my application appears on the screen, but all its controls are unavailable for mouse clicks, and the mouse cursor is "I" (as it is in the editor). I can press the Close/Minimize/Maximize buttons on my application window, so I can terminate it by such click as well as by IDE menu, but I just can't test my application because I can't click controls in its window. Therefore I can't debug it as I can't activate the piece of code with the breakpoint.

Thanks.

[Marc]

yes, you need some app structure (or one special compiled in resource)

for the structure, have a look at http://lazarus.dommelstein.net/examples/cursors/project1.app

inside MacOS, project1 is a symlink: project1 -> ../../../project1

[abb]

for the structure, have a look at http://lazarus.dommelstein.net/examples/cursors/project1.app
inside MacOS, project1 is a symlink: project1 -> ../../../project1

Thank you, but I already know how to create the app structure. What I don't know yet is how to point Lazarus to the target file to launch. It looks like the debugger uses just the same file as compiler. But compiler can't produce APP -- it produces just the executable itself. Could you let me know how to configure Lazarus to compile the executable, located somewhere on the disk, and assign the APP file to debugger?

Thanks.

[Marc]

look in Run -> Run parameters -> Host application
enter: /full_path_here/project1.app/contents/MacOS/project1