Home Forums Wiki Doc Install Extras Screenshots Source Code Projects Blog Users Groups Register
Glx-Dock / Cairo-Dock List of forums Applets | Applets Golang API and applets
The latest stable release is the *3.4.0* : How to install it here.
Note: We just switched from BZR to Git on Github! (only to host the code and your future pull requests)
Applets | Applets

Subjects Author Language Messages Last message
Golang API and applets
SQP English 15 SQP [Read]
26 August 2015 à 00:12

SQP, Friday 28 February 2014 à 16:33


Subscription date : 03 July 2010
Messages : 1081
Hi, here are some news for the golang DBus API.

I switched to another DBus API and reworked and tested everything to be sure it was fine. I have all the Cairo-Dock DBus API wrapped nicely into two libs
  • dbus: Interaction with cairo-dock. So far I only have problems with the AddMenuItems function.
  • dock: Applet management and helpers for common things needed by applets: config loading, poller, templates, window monitoring...

The goal of this API is to have a nice environment to build applets as easily as possible. So it will continue to evolve and regroup things needed by several applets. I think it's already in a good shape with some interresting features:
  • Automatic loading of applet configuration. You just have to declare your config struct, with only a comment on lines where you need to use a key name other than field name.
  • Poller activated in two lines (create+handle poller and set interval) for monitoring or data polling applets.
  • Minimum code to write. All the applet management and events should be between 50 and 200 lines with comments: easy to get started, better for maintenance.

Code on github (for now)
Documentation (still really light for now, it will improve as it is auto-generated from code).

Applets
  • GoGmail: Simple Gmail checker. Almost no visible change since last advertised version (dropped the libnotify option).

  • Update: Applet with shortcuts to compile the dock and applets. And poller on the dock sources to know when a new commit is available for devs and testers.

And as it seem my Disks applet in C will never reach a stable version, I've rewritten it in two applets of less than 280 lines each (can't have multiple instance of external):

  • DiskFree: Disk usage monitoring. Improved with auto-detect partitions.

  • DiskSpeed: Disk activity monitoring.

Works the same, with a few more options for interaction. I wasn't sure what was the best way to do it and thought it was simplest to give the user the choice:
Options for left and middle click (plus an entry for the location/command and one for the class):
  • None
  • Open location: using xdg-open, it allow to open an url, a file or a dir.
  • Open program: default open command action.
  • Monitor program: open program and monitor its window. (not available for middle click)


Planned evolutions

I have no real plan to expand more those applets ATM, they're doing their job, but if you have ideas, feel free to share.

I'm working on a new applet with UPnP support to control and play media on UPnP renderers devices. There's no good application for UPnP control on linux and I need one I can use with the dock, so I'll have to do it.
I already have an alpha version that control the volume of my TV like the sound applet and the GUI that only allow to select the renderer for now. It will require more work on my gupnp binding to allow to select movies, and parse the query answers to enable interactivity.
If anyone want to test or help improve it, I could push it too.

Note that even if UPnP is mostly used to play distant media, I can still control my TV volume when used only to watch a good old TV broadcast: mute ads with one click or shortcut (got some unused media keys? <3 ).

On my TODO for later:
GoGmail and Update could get some sort of (common?) small GUI to display details about their polled data.
Update need to be expanded to pull directly a bzr tree to compile and pull further commits (up to auto pull,rebuild and relaunch maybe).

Need testers
It would be cool if you can test it and give some feedback, working or not <3 . I'd like to be able to add this language as a new official binding for the dock. And for your next applet need, try to give it a GO, this language is really great. It has become my main language and I'll continue to use it for almost all my next devs (besides when I'm forced to hack into the dock core).
I'm not sure what go version will be needed.

Install
You will need to have golang installed and a dir to download go sources, and set it to the GOPATH variable like this:
mkdir $HOME/go
$ export GOPATH=$HOME/go

Download, build and install to your Cairo-Dock external applets dir:
go get -d github.com/sqp/godock/applets/DiskFree # download applet and dependencies.

cd $GOPATH/src/github.com/sqp/godock/applets/DiskFree
make # compile the applet.
make link # link the applet to your external applet directory.


replace DiskFree with one of the other module name to test them.

Devs

Test to filter valid partitions. Let me know if you think I dropped something that could be good, or if I miss something.
    dropped := fs.DevName == "none" ||
        fs.SysTypeName == "proc" || fs.SysTypeName == "sysfs" || fs.SysTypeName == "cgroup" ||
        fs.SysTypeName == "tmpfs" || fs.SysTypeName == "devtmpfs" || fs.SysTypeName == "devpts" ||
        (len(fs.DirName) > 5 && fs.DirName[:5] == "/run/") ||
        (len(fs.DirName) > 6 && fs.DirName[:6] == "/proc/")

    
@matttbe: I will need a write access on the wiki please <3
    
    

SQP, Friday 28 February 2014 à 17:07


Subscription date : 03 July 2010
Messages : 1081
And I know it will be cool to have those sources packed with the other bindings, but go sources must live in a specific tree. Here is the tree of the $GOPATH/src after install of the 4 applets. You can see that external deps have been downloaded next to the dock libs. It takes one line to install everything, and this is common practice in golang development. I could move to launchpad (same as github for the install tool), but I think it would be better in a separate tree as there is no point to package this lib into a .deb or other.

- github.com
. .- cloudfoundry
. . . .- gosigar

. .- guelfey
. . . .- go.dbus

. .- kr
. . . .- pretty

. .- robfig
. . . .- config
. .- sqp
. . . .- godock
. . . . . .- applets
. . . . . . . .- DiskFree
. . . . . . . .- DiskSpeed
. . . . . . . .- GoGmail
. . . . . . . .- Update
. . . . . .- libs
. . . . . . . .- cdtype
. . . . . . . .- config
. . . . . . . .- dbus
. . . . . . . .- dock
. . . . . . . .- log
. . . . . . . .- packages
. . . . . . . .- poller
. . . . . . . .- ternary


Applets are good candidates to be packaged though, let me know if you want to try to do something about it

matttbe, Friday 07 March 2014 à 11:58


Subscription date : 24 January 2009
Messages : 12573
Hello SQP!

It seems great

I'd like to be able to add this language as a new official binding for the dock
Me too!!

I just have not so many time right now to test everything but I have one question for the moment: What is needed to use these applet? If users download a binary for the right architecture, is it enough? Or do they need more dependences?

@matttbe: I will need a write access on the wiki please <3
Oh sorry, I don't know why you was not in this list

SQP, Wednesday 02 April 2014 à 14:40


Subscription date : 03 July 2010
Messages : 1081
Oh sorry, I don't know why you was not in this list

no problem, I wasn't very active at the time of the change.

What is needed to use these applet? If users download a binary for the right architecture, is it enough? Or do they need more dependences?


Sorry I took so long to answer but I wanted to be able to give more complete answers.

As far as I know, everything needed is packed in the binary, that's why they are so big. Each applet binary takes between 10 and 25 MB on disk, depending on what it includes (biggest are with GTK). And as they are different programs, they don't share memory space either.

I was a little annoyed by the total space used by my applets for a large release (74 MB for 6 applets binaries) so I tried a different method with a single binary handling multiple applets. I wanted to test this for a long time and I'm very happy with the result. Applets can be compiled and loaded as easily with the packed method. And you can as easily switch between the single and the multiple version. The command line also provides a few helpers to start and stop the dock and applets.

Here is the first version released with this new method: cdc-0.0.1-1-amd64.tar.xz

This includes a 29 MB binary with a few command lines option and the ability to handle the following applets:
  • GoGmail: Simple Gmail checker.
  • Update: Applet with shortcuts to compile the dock and applets. And poller on the dock sources to know when a new commit is available for devs and testers.
  • DiskFree: Disk usage monitoring. Improved with auto-detect partitions.
  • DiskActivity: Disk activity monitoring (renamed from DiskSpeed).
  • NetActivity: This is a merge of NetSpeed and DropToShare. Their job is related and their actions not conflicting, works fine like this.
  • TVPlay: control DLNA/UPnP devices like network TV and radio. With keyboard shortcuts and a GUI to control your network devices.

Install:
  • Copy or link the applets data to your external applets dir.
  • Copy or link the cdc binary somewhere in your $PATH.


If you're interested in one or more of those applets, or want to help with the development of this new generation of applets, please test and report whether it work or not

http://pix.toile-libre.org/upload/original/1395702580.png TVPlay Gui.

    cdc command [arguments]

The commands are:

build build a cairo-dock package (need rework / tests)
install install external applet
list list external applets
restart restart the dock or one or more applet
service start service with the dock or an applet


and as a still hidden feature, you can test the WIP version of the new config GUI (read only except for the install/remove external applets).
cdc service config

http://pix.toile-libre.org/upload/original/1396442053.png

SQP, Thursday 10 April 2014 à 22:32


Subscription date : 03 July 2010
Messages : 1081
Not a lot of new features this week, just two new actions to the cdc command. They are based on the idea that cdc can connect to a running cdc instance and try to do something with the applets launched (by wrapping dbus commands and sending them to his brother with the dbus server).

I really like the applet pack idea, with its Dbus server and client, it allow me to easily add new unexplored features and make them easy to use.

We can access the dock with Dbus, now we can also access applets with Dbus <3 and extend their utility and actions to other scripts or applets (and why not applets interaction). On the Todo: rush to make a nautilus script to send files to my uptoshare before the nautilus script option is removed.

  • Upload: send data to the uptoshare service of the NetActivity applet. This allow to upload files (or raw text) as if you dropped them on the icon (with history and alert...).
This still need the NetActivity applet to be active, I need to figure out what to use as default backends if the applet isn't configured. (TODO: I could start to work with the conf file if found)
cdc upload "sorry for the flood" # upload text
cdc upload /path/to/file # upload file


  • Debug: Change the debug state of an active applet. The debug is an option provided to all
It's still possible to activate the debug in the config file of every applet, to have more information and detect start-up problems.
Note that the live changes to the debug variable aren't saved to the config.
cdc debug Update # start debug
cdc debug Update 0 # stop debug (you can use 0 or no or false)


This also forced the start of the needed rewrite of the logger (since it couldn't handle well the multi-applets) that will continue in the next patches.

A lot of work was also made on the doc. It should now explain better how applets are build and their running process.

Homepage for godock
How to build an applet
Options for cdc command line

Needed:
Besides tests, I'll also really need some comments with multiple point of view: user, dev and maintainer.
  • Do you think those ideas and their implementations seem to fit well with the future of the dock?
  • Can this be easily deployed and installed? (maybe need some external dir in /usr/share to remove the need of links in the home dir)
  • I'm thinking it would be nice to have a better name for the project, for now my best idea is goldock, some mix of gold and dock, which seem simple, short, keeps "dock" (and also the optional go), sound maybe a little marketing but has a related idea of rich and shiny like our dock. It seem unused with only 3880 google answer (and best of all, sounds really like an old favorites of mine, Grendizer was aired as Goldorak in France)
  • And now I have the applet pack and covered most of my needs (unless you have some ideas), I still have two almost unexplored areas of evolution:
    • compile my shared libs in go to let the dock load them as others C shared object. It's a hard one for now as it isn't supported and marked as "would be cool in the future, but not planned". But it seem to work with gccgo. I found some example and managed to build some .so from go sources. Didn't tried to use them yet.
    • load the dock from a go launcher. I can't load easily go from C, but I can load C from go. So if I create the dock instance from a go binary, I'll be able to declare and hack everything I need afterwards. Maybe remove the Dbus dependency to communicate with my packed in applets. One of the goal would be to create new versions of those "internal" applets like dock views or icon renderer (like better (themed) graphs [1] or progressbar).


Note on file size: 29 MB binary that provides everything is the best I can do ATM to provide all the features I want, but it's by far the least of any other combination that use 2 or more binaries. Applet TVPlay is 24.5 MB alone. When I add all other applets it increase to 27.5 MB, and with the cdc command, Dbus server and client and the huge (lib and codewise) config GUI, I have the 29MB bin.
What takes a lot of space is the "base" (http, dbus, with xml crypto and co) and GTK. The "active" part of applets don't add much as most of their job is also done with those libs (there's just that curl lib (AND binary) dependency that I'd like to remove or switch to some go native counterpart, but I guess the dock also relies on that C libcurl (and binary too?)).
Another benefit of the huge binary, is that once I have GTK packed for an applet, I can activate it almost for free in all the applets I want.
So far I don't see any drawbacks, besides the "crash one crash all" effect, but I could try to secure that with an exception catch, and I provide the multi-reload applet command: cdc restart DiskActivity DiskFree GoGmail NetActivity TVPlay Update

Code example. I found almost cheated how easy it was to convert my "generic applet" interface to one I could use to upload my data. Just declare an interface with the method you need to use. Recast your object. Done. (no need to know what the object is as long as it can Upload).

type Uploader interface {
    
Upload(string)
}

// Upload send data (raw text or file) to a one-click hosting service.
//
func (load *LoaderUpload(data string) *apiDbus.Error {
    if 
uncast := load.GetApplet("NetActivity"); uncast != nil {
        
net := uncast.(Uploader)
        
net.Upload(data)
    }
    return 
nil
}


[1] Screenshot of my updated C graph theme. This patch update experience was enough to confirm it will be faster and safer for me to rewrite it in go than trying to finish the C version.
http://pix.toile-libre.org/upload/original/1397150635.png

TO Update: add link to new file.

matttbe, Thursday 01 May 2014 à 22:20


Subscription date : 24 January 2009
Messages : 12573
Hello and sorry for the delay... very (very (very (v...))) busy right now

I'll have a look to this long answers ASAP but all of that looks promising!

BTW: thank you for all answers in the other topics

SQP, Sunday 11 May 2014 à 20:33


Subscription date : 03 July 2010
Messages : 1081
I need to post more info but here are a few updates:

External applet dir in /usr
I found the location for system installed applets in /usr/share/cairo-dock/plug-ins/Dbus/third-party/
I updated what I needed to have my applets work in that system dir, so I think that could now be easily packaged: I just have one binary and a bunch of applets data files.

Callback declaration for applets
I found a way to autodetect methods declared by the applet and can now use something closer to other language bindings. I think this is a little improvement, even if it will look like magical callbacks. Let me know if you prefer the old code without magic or the new one that is shorter (both are enabled for now).

Before (it was declared in the mandatory DefineEvents() method):
app.Events.OnClick = func() {
    [...]
}

or
the new method code and this declaration:
app.Events.OnClick = app.OnClick


After: (nothing declared nowhere, no DefineEvents(), you need to know (read the doc) that a method with this name and args will be called)
func (app *Applet) OnClick() {
    [...]
}


The new method is used in the new pulseaudio applet. This one is interesting because it also use this magic callback system for the pulseaudio events. Besides my separators, there's no way to know whether a method will be used as a callback or not.
I want to be sure everyone is OK before I confirm that change. As I learned when I started to play with Drupal that undeclared hooks are sometimes hard to figure out.

Wiki page
I think this page now contains too much informations that I should gather on an up-to-date wiki page. Same problem as before, I need some help with the name . Maybe a page called cdc like the command I provide would be OK for now.

BTW: thank you for all answers in the other topics

trying to do my best to help you when I can

matttbe, Sunday 19 October 2014 à 02:59


Subscription date : 24 January 2009
Messages : 12573
Hey,

Just a quick idea: now that we just switched from BZR to Git, we could maybe add your git repository inside cairo-dock-plug-ins(-extras?) as a Git' submodule. What do you think about that?

SQP, Sunday 19 October 2014 à 10:31


Subscription date : 03 July 2010
Messages : 1081
Hey, I saw that github migration, and I think it would be cool to have my code next to yours, but go code needs to live in a dedicated tree (see second post).

So I could change the path from
$GOPATH/src/github.com/sqp/godock


to something like
$GOPATH/src/github.com/Cairo-Dock/godock


But I don't really see how merging my code into extras would help.

I was also wondering if my old test applets are still usefull in the tree (CairoBzr and disks, replaced by Update, DiskFree and DiskActivity in the go version)

And I have tons of things to discuss and announce about this code, like the archlinux automatic patch and build. (really nice to test my commits)
I may need your help for someting similar for Debian based users so we could add it to the repo.

- github.com
- andelf
-   - go-curl
- atotto
-   - clipboard
- clbanning
-   - mxj
- cloudfoundry
-   - gosigar
- conformal
-   - gotk3
- fatih
-   - structs
- godbus
-   - dbus
- robfig
-   - config
- sqp
- - godock
- -   - applets
- -   - cmd
- -   - dist
- -   - libs
- -   - services
- -   - widgets
- - gupnp
- - pulseaudio
- - vte


Last version of my source tree after a fresh pull, notice the 3 new libs next to godock.

In the next days I may add the first commits of the config GUI code, almost as good as the real one to configure applets (I still miss some infos for some main config widgets).
After something like 10 patchs on GTK, I still need to make 3 or 4 for my config needs.

http://pix.toile-libre.org/upload/original/1413706529.png

matttbe, Sunday 19 October 2014 à 11:34


Subscription date : 24 January 2009
Messages : 12573
I think it would be cool to have my code next to yours
Good idea! I didn't think about that!
I just added you to the organisation!

but go code needs to live in a dedicated tree
Yes, it was just to have a link to your code.

I was also wondering if my old test applets are still usefull in the tree (CairoBzr and disks, replaced by Update, DiskFree and DiskActivity in the go version)

And I have tons of things to discuss and announce about this code, like the archlinux automatic patch and build. (really nice to test my commits)
I may need your help for someting similar for Debian based users so we could add it to the repo.

We should see how to integrate them... Maybe if we can have binaries for amd64 and i386, it can help. (but it's not a small binaries )

Last version of my source tree after a fresh pull, notice the 3 new libs next to godock.

In the next days I may add the first commits of the config GUI code, almost as good as the real one to configure applets (I still miss some infos for some main config widgets).
After something like 10 patchs on GTK, I still need to make 3 or 4 for my config needs.
Thank you for all your work!

SQP, Sunday 19 October 2014 à 13:28


Subscription date : 03 July 2010
Messages : 1081
with go 1.3, the binary size dropped to 24.5 MB with 10 applets and the config.
package size is around 4 MB (3.8 in xz)

The all in one method is the best I can do considering the size of the GTK dependency. It seem better than a bunch of 10-20 MB applets (which can still be compiled or packaged that way)

I'd also like to mention that I'll have to "eat" the dock at some point (just started yesterday with the new 3.4 branch) so I could have access to everything as if I were an internal or even a system applet.

As the goal is to give the best experience I can, this go wrapper around the dock is the last logical step to break all limits I encountered with the external access. (config with custom applets widgets is the hardest one I guess)

So far, I can start the dock and insert a custom view before loading the theme. (used it to test my changes on panel, I use go to add an ATM pure C code).

This document shows some evolutions that go would require to give different options. Be able to be used as system library is a huge demand, but isn't expected to happen soon.

A go binding for the C dock sounds cool, and I think this can benefit the huge work fabounet made over the years to split the gldi lib. With my config, I may be able to reach the state of "second gldi client" (not counting the demo cairo-desklet).

PS: go binary with the dock is 2.7 MB. ldd output seems to be the same as with the dock binary (92 lines). Adding the gotk3 dependency just to gtk.Main() from go adds 10 MB to the binary.

HaroldNHulsey, Thursday 01 January 2015 à 10:27


Subscription date : 01 January 2015
Messages : 1
I'm a spam but happy new year !

SQP, Monday 08 June 2015 à 09:20


Subscription date : 03 July 2010
Messages : 1081
Hello, I know I'd have to write a lot more about my devs but here's a quick list:

I pushed the rewrite to the point where I really have a new gldi client: loader, menu, GUI, applets manager (for go as internal).

It's far from being finished, or debugged, but as it's doing the job for my daily work, it has become my only dock for quite some time.

The GUI layout looks more like what I had in mind for the dock, but can still change if you have better ideas, it's more flexible now it's splitted in widgets.

Go 1.5 (expected in august) should have the ability to build as shared library, both for C (with C limits) and for go. This could fix my binary size issue, and open plugins ability. This may also allow me to write plugins directly for the dock (applets or renderers), exporting functions is easy when data types are already known

I'll need testers, so I worked on the packaging, and I'm happy to announce I have made repositories for Archlinux and Debian 8 (also working on Ubuntu 15.04 and Mint 17 (trusty, which has only GTK 3.10 when Deb has 3.14, but I limited the binding to 3.10 so it could work))

  • cairo-dock-goapplets: my applets pack (10) for cairo-dock.
  • cairo-dock-rework: same applets but packed for the new provided dock (command = cdc)


Debian and related:
/etc/apt/sources.list.d/cairo-dock-go.list
deb http://download.opensuse.org/repositories/home:/SQP:/cairo-dock-go/Debian_8.0/ ./


Archlinux:
/etc/pacman.conf
[home_SQP_cairo-dock-go_Arch_Extra]
SigLevel = Never
Server = http://download.opensuse.org/repositories/home:/SQP:/cairo-dock-go/Arch_Extra/$arch


Packages are available for 32 and 64 bits. (2 packages x 2 distro x 2 arch = 8 packages )

Thanks to the openSUSE Build Service - project page

NEO595, Sunday 23 August 2015 à 05:04


Subscription date : 08 September 2013
Messages : 1
Hi,
I'm trying to install your new applets.
I'm on Ubuntu 15.04 / 64b with cairo 3.4.1
I'm downloading the .deb, then install it.
I have to fix access file right as mention in FAQ of cairo
Then I can access to the new applets in the configuration panel.
The problem is that any applet is replaced by the icon, no matter which setting you're doing. No message in console.

What is wrong ?

regards.

SQP, Monday 24 August 2015 à 09:42


Subscription date : 03 July 2010
Messages : 1081
Hi, and thanks for the report.

I worked on the packaging in the last patches to help ensure this would be possible to install, but left it in a somehow broken state.

I'm not sure which one you tried, but AFAIK, both should have paths problems to start my applets.
I should have pushed a patch a few days ago, but didn't took time to validate all changes.
It will be done today, and I'll update the packages.

I have to fix access file right as mention in FAQ of cairo


I'm not sure which doc you're referring to.

The problem is that any applet is replaced by the icon, no matter which setting you're doing. No message in console.


I think you mean that you can only see a default icon for each new applet.

If there is only 2 entries in the menu when you right click an applet, chances are that the applet program is missing (not started or crashed)

(If you start an applet, there will always be its icon, whether there's really an applet behind or not)

I'd be happy if you could help me with some tests to help with that install process.

SQP, Wednesday 26 August 2015 à 00:12


Subscription date : 03 July 2010
Messages : 1081
I just published the version 0.0.3.4 which should fix loading problems.

My release process seems to improve, so I'll be able to be more responsive with small fixes when needed.
(so much shit required to package for Debian...)

Feel free to test and report

http://pix.toile-libre.org/upload/original/1440547907.png

Applets | Applets

Subjects Author Language Messages Last message
Golang API and applets
SQP English 15 SQP [Read]
26 August 2015 à 00:12


Glx-Dock / Cairo-Dock List of forums Applets | Applets Golang API and applets Top

Online users :

Powered by ElementSpeak © 2007 Adrien Pilleboue, 2009-2013 Matthieu Baerts.
Dock based on CSS Dock Menu (Ndesign) with jQuery. Icons by zgegball
Cairo-Dock is a free software under GNU-GPL3 licence. First stable version created by Fabounet.
Many thanks to TuxFamily for the web Hosting and Mav for the domain name.