← Back to team overview

syncany-team team mailing list archive

Re: Tray in Unity via Appindicator script in Python

 

On Wed, Jan 1, 2014 at 5:42 PM, Philipp Heckel <philipp.heckel@xxxxxxxxx>wrote:

> Hello Vincent,
>
> I tried to fiddle something together for the Unity "appindicator" tray. It
> conflicts with your changes in the "gui" branch, and it's not completely
> working:
>
>
> https://github.com/binwiederhier/syncany/commit/d772bdae76fee8b3f12cd9ed23c9c25d876c6719
>
> Since Unity removed SystemTray support entirely now, this solution is
> (like in 2011) using an additional Python script to instantiate the tray. I
> added a TrayIconFactory to create a tray depending on the desktop
> environment (Linux/Unity -> UnityTrayIcon; others: DefaultTrayIcon).
>

Ok sound good.
I changed TrayIcon from interface to abstract class in order to handle
common function such as show website, preferences etc. ...


>
> The DefaultTrayIcon is your code; the UnityTrayIcon starts the python
> script. The communication between the python script and the Java code is
> via the daemon websocket, so:
>
> 1) unitytray.py (WS client) -> daemon WS Server (forwards) ->
> UnityTrayIcon (WS Client)
>  --> e.g. for events {'action': 'tray_menu_item_clicked', 'command': 'NEW'}
>
> 2) and UnityTrayIcon (WS Client)  -> daemon WS Server (forwards) ->
> unitytray.py (WS Client)
>  --> e.g. for events {"text":"All files in
> sync","action":"update_tray_status_text"}
>
>
ok : another option would be to start a web socket server in gui and make
python script connect to it ?


> *Issues:*
> *a) Python:* Introducing a new language (Python) usually comes with
> issues (deployment, dependencies, IPC, etc.). Any pure-Java alternatives
> for Appindicator support are welcome. I have not found any back in 2011,
> and I couldn't find any now... Ideas?
>

could not find anything ....
one solution in the future could be to use java-gnome library and jython
once java-gnome would have implemented gtk appindicator API


>
> *b) Indirect communication: *The code is nowhere near stable, but the
> communication works quite well. However, I'm not sure that the indirection
> via the daemon WS Server is such a good idea. Any thoughts? Maybe the
> UnityTrayIcon should simply start its own WS Server and let unitytray.py
> connect to it.
>

see above :)
unitytray is only linked to gui ans it make sense to let UniTray handle
this (I switched the code to implement a webserver on another port)


>
> *c) Deployment: *The Python script obviously must be put somewhere when
> deploying the application (e.g. in "bin/"). This is currently not done. The
> script only works if "Launcher.java" is started from Eclipse.
>

or extracted at runtime to random temp folder and deleted when application
exits ?


>
> *d) Python script resources*: The Python script needs the same resources
> (tray.png, etc.) as the DefaultTrayIcon, but it cannot access the resources
> from a JAR. That means the deployment must include the extracted resources
> somewhere.
>

or resources could be sent to python script through web socket


> *e) Event abstraction: *Both DefaultTrayIcon and UnityTrayIcon should
> fire events to a central source, such that onExitClicked(), etc. only has
> to be implemented once.
>

see above / use of common abstract parent class

>
> @Vincent: You obviously don't have to take my entire code, but I hope it
> helps with the Tray stuff.
>

yes, but what you did is good.
just need to strengthen python script and find a clean way to install
python dependencies (web socket, appindicator)


> Best
> Philipp
>
>
>
> --
> Mailing list: https://launchpad.net/~syncany-team
> Post to     : syncany-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~syncany-team
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Vincent Wiencek
vwiencek@xxxxxxxxx

References