Hi,

I am trying to implement TTrayIcon for the Qt widgetset, but some things just don't work, and I don't know why ...

You can test this by using the lazarus/components/example/wndtray.lpi test project. The test project doesn't require installing the package to be used (the package is visual, and rebuilding the ide is time consuming, so I decided for this way).

Basically you assign a icon and a popup menu to the trayicon, and it maps this to the widgetset. The qt implementation is on wsqttrayicon.pas

On this same file, on this function, I get a crash, because QPixmapIsNull according to the message. But debugging I see that Pixmap isn't nil. The Icon is loaded from a icon.ico image file.

function TWidgetTrayIcon.CreateIcon: QIconH;
var
  Pixmap: QPixmapH;
begin
  if Self.Icon.Handle  0 then
  begin
    QPixmap_fromImage(Pixmap, TQtImage(Self.Icon.Handle).Handle);
    Result := QIcon_create(Pixmap); // Crash here
  end
  else
    Result := QIcon_create();
end;

I also get a crash when setting the popup menu:

  IconHandle := CreateIcon;
  SystemTrayIcon := TQtSystemTrayIcon.create(IconHandle);
  Text := UTF8Decode(Hint);
  SystemTrayIcon.setToolTip(Text);
  if Assigned(PopUpMenu) then
   if TQtMenu(PopUpMenu.Handle).Widget  nil then
    SystemTrayIcon.setContextMenu(QMenuH(TQtMenu(PopUpMenu.Handle).Widget));
// Crash

The TTrayIcon example works on Windows and on Gtk, so I would say that the LCL side is correct, and the icons and popup menus are assigned.

Sorry for such a generic report, but I have no idea what is going wrong ....

The SystemTrayIcon class is a simple mapping of the QSystemTrayIcon methods, so it doesn't influence much here.

thanks,

Felipe Monteiro de Carvalho wrote:

[skip]

You forget to allocate QPixmapH and deallocate it after. I fixed and checked under windows it works now. Btw, under windows there are other problems with compilation - check your ifdefs for windows case.

No crash here after fixing first problem (maybe it was crash because of IconHandle pointed to empty icon?)

Please retest after commit.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

You forget to allocate QPixmapH and deallocate it after. I fixed and checked under windows it works now. Btw, under windows there are other problems with compilation - check your ifdefs for windows case.

Ah, I thougth that QPixmap_fromImage would allocate the pixmap for me, and you are right, it's perfectly working now =)

I think it's working good enougth for a preview release for Mac when the next version comes out.

I fixed the ifdefs for windows, by the way.

thanks,

Felipe Monteiro de Carvalho ?????:

Why not to include it to LCL?

Best regards,
Paul Ishenin.

Paul Ishenin wrote

> I think it's working good enougth for a preview release for Mac when > the next version comes out. Why not to include it to LCL?

Ah, my fault. In this paragraph I was talking about the magnifier.

TTrayIcon is of course already in Lazarus.

In Lazarus but not in LCL.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

In Lazarus but not in LCL.

Ah ... ok.

Sure, but it will need a bit of redesigning. The current implementation is a bit chaotic in the sence that it is reimplemented on some widgetsets once and on others once per windowing system. I did it that way to get it working, as some version (like X11) are very hard to implement.

TTrayIcon deep down isn't dependent on the widgetset, but really on the windowing system, so it should theoretically be possible to have only 4 version (X11, win32, wince, carbon), and map anything else to them.

This is quite hard currently because you need to get the handle from each widgetset and then transform it into a native windowing system handle for each widgetset for each windowing system. It would be easier if we had a GetOSHandle or something similar along with the Handle property, as is planned, and stablish rules about what this should return for all widgetsets.

So the main obstacle that I see is that LCL is created around a design where each component is implemented once per widgetset, and what TTrayIcon really needs is to be implemented once per windowing system.

Felipe Monteiro de Carvalho ?????:

gtk and gtk2 = X11 (some other parts of gtk widgetset uses same assumption) win32 = win32
wince = wince
carbon = carbon
and qt has own implementation.

What I forget? FpGUI - dont take it into account.

Best regards,
Paul Ishenin.

If you think of it this way, it can actually be implemented once per widgetset.

But some combinations theorically possible would be left out, like gtk2 in Mac OS X, which even thougth having X11, doesn't have a X11 tray.

You can propose this on lazarus-dev