Page MenuHomePhabricator

eldbus blockers
Open, HighPublic


This is a collection of issues which continue to make eldbus more difficult to use than just using the libdbus API, which was supposedly the reason why eldbus was taken in to replace e_dbus.

  • eldbus-codegen
    • Has zero examples
    • Has zero documentation
    • Has zero tests
    • Until today would easily generate code which would not compile
      • May still generate uncompileable code; lack of tests means that there's no way to know
    • Generates insane and difficult-to-use method calls for simple methods
      • Try a method with the signature "ai" (simple array of ints) on input or output: you are now working with eina_value for no reason
    • Relies on heavily eina_value but does not provide any useful utilities for it
      • Converting large structs to/from eina_value is still the worst process in all of EFL
    • Still crashes
    • Does not allow specifying an output directory for files
  • library
      • Has zero tests
      • Uses unrealistic and incomplete example cases which are of no use to any potential user
      • Has unclear/incomplete documentation
      • Outputs errors constantly for things that should not be errors
        • Manually canceling a method call results in console error output?
    • Requires use of eina value for many EAPI function parameters

At present, a developer writing any sort of complex EFL application which relies upon dbus should honestly use libdbus. It may take slightly longer, but at least they have the guarantee of using a well-tested, well-documented, functional API instead of struggling to get things working with our effectively unsupported (does anyone at all maintain/develop this anymore???) wrapper API.

zmike created this task.Nov 4 2014, 3:31 PM
zmike updated the task description. (Show Details)
zmike raised the priority of this task from to High.
zmike added a project: efl.
zmike added a subscriber: zmike.

If a specification has a signal and property with the same name eldbus-codegen will generate 2 different callbacks with the same name, is a example of such a specification. One of the callbacks should probably be renamed, this shouldn't cause to many issues as the callbacks are only used internally mostly to call the callbacks that were passed in externally.

zehortigoza added a comment.EditedFeb 3 2015, 5:04 PM
  • lib
    • at the time it was write, EFL was separated libs yet so we did not have many tests on most of the libs and we don't have any tests running on the server. But if someone with admin access and knowledge on tests help me, I would be glad to write some test cases.(We need to find a way to run an application as dbus server another as dbus client and make then talk all this inside of the test environment)
    • about the examples it have some simple and complex examples, also the eldbus API is used in several libs of EFL and on E, so we have real world examples, maybe they are not on the better place to EFL users.
    • all the main APIs have documentation, the ones that do not have are simple enough. Until today very very few question about eldbus was made on IRC on the mail list until today. And I know several people that had write application/libs beside me with eldbus.
    • On the last 6 months only one bug was open and an API was add(that I had help fix the API add)
  • eldbus-codegen
    • there is no documentation because it should be as simple as a edje_cc if you use the --help.
    • about the eina_value, I don't remember why this 'ai' need to go complex mode and use eina_value, but for cases like 'a(is)' is complete necessary. Whenever you use a code-generator the performance is not optimal, look at gtk and qt dbus generator it uses something like our eina_value.
    • the bigger example if the music player module of E.

I don't work anymore on EFL on my working hours, but on my free time I try to keep track of the mailing list.

stefan_schmidt lowered the priority of this task from High to Normal.Jan 7 2016, 7:33 AM
stefan_schmidt added a subscriber: stefan_schmidt.
zmike raised the priority of this task from Normal to High.Feb 19 2016, 3:29 PM
zmike updated the task description. (Show Details)
zmike added a comment.Feb 19 2016, 3:32 PM

This is a genuine high priority issue. At present, it's impossible to use most of this library for anything worthwhile, meaning that EFL effectively lacks a sane dbus integration. This means people can't write applications.

Anything requiring eina value will never be used by users. Ever. Even the people who wrote eldbus refused to use it: the ported E modules manually create method calls and signal handlers and manage arguments with the args api, just like libdbus, instead of using generated code or using the "helper" functions which take eina value params: for all this hassle, it's legitimately easier to just use libdbus.

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
bu5hm4n edited projects, added efl: system integration, efl: networking; removed Restricted Project.Jun 11 2018, 7:55 AM
zmike edited projects, added Restricted Project; removed efl (efl-1.21).Jun 14 2018, 6:08 AM

Realistically this requires way too much work to be resolved before 1.21.

zmike changed the visibility from "All Users" to "Public (No Login Required)".Jun 14 2018, 6:08 AM