native-tray-adapter
native-tray-adapter copied to clipboard
Qt4/EFL
It would be nice if you could make the tray backend "configurable". I mean, something like
TrayIconAdapter trayIconAdapter = trayAdapter.createAndAddTrayIcon(
imageUrl,
tooltip,
popup
"QT4"
);
So this way the tray code will try to load QT4, and if not possible fall back to AWT. Or maybe even better, pass an array as last argument, something like [QT4, GTK, EFL], so this way the tray will try to load QT4, then GTK, then EFL and finally AWT if none if the other worked.
Regards
As you probably know, the library already fallbacks to AWT if GTK is not found. I like the idea of having several backend implementations, so the library could fallback to other native implementations if gtk is not installed, but I don't think it is very appropriate to put in the code the order of the implementations.
Whoever uses the library will be using a JAVA library, and letting a place to state the loading order in the java code breaks the principle that it should be cross-platform.
Anyway, GTK implementation works fine under Gnome and Kde. Is there any reason for the programmer would prefer one library over the other?
Hi,
First of all thanks for the fast reply. Being able to load qt4 (or another graphic framework implementation) is really important for some pure-distros like Chakra(QT4 only libs), Elivecd(EFL only libs) or some other distros that refuse to use mote than one graphics framework. As of this, using this lib would require the instalation of GTK. In other words, the deployment process gets kind of more difficult.
I'm currently on vacations so I can't have a look at the code, but it shouldn't be difficult to implement an abstract interface and make the trayicon related code for each framework.
Also, I can think atleast of one app that will be really interested in this lib when atleast QT4 code is implemented: JDownloader. Think about all the platforms that QT4 supports that GTK doesn't.
Regards!
Like I said, I like the idea of trying other backends and my proposed solution would work, because it would try some library (it doesn't matter the order) and would eventually try Qt4. The only thing that I disagree is the need to specify the order in java code.
It is very simple to try other native implementations, the tray icon implementation is already abstract because it has already two implementations, gtk and awt.
Thanks