UpdateFact DBus-Method not callable #671
Comments
aquaherd
changed the title
|
If it worked and no longer does, it's a bug. |
|
Should work (blind guess, untested). Please do ask for guidance if anything is unclear. |
|
thank you. will check. |
|
Confirmed: Works for me. Please merge to upstream. |
It depends on your plugin. If it has only a single cmdline, then users expect it to match the terminal command line, and Otherwise, |
|
Working with Json from C is another dependency on top of GVariant-wrapped DBus that I would rather avoid. Reading hamster code just got me the best solution: if (!strcmp("fact", type))
fact = hview_get_fact_by_activity(view, val);
else if(!strcmp("date", type))
duration = val;
if (hview_span_to_times(duration, &start_time, &stop_time))
{
// hamster #671 merged upstream?
if (hamster_call_update_fact_sync(view->hamster, id, fact, start_time, stop_time, FALSE, &id, NULL, NULL))
{
DBG("UpdateFact worked: new id=%d", id);
}
else
{
DBG("UpdateFact did not work: remove, then add fact #%d", id);
hamster_call_remove_fact_sync(view->hamster, id, NULL, NULL);
hamster_call_add_fact_sync(view->hamster, fact, start_time, stop_time, FALSE, &id, NULL, NULL);
DBG("UpdateFact worked: %d", id);
}
}
else
{
DBG("Duration '%s' did not parse.", duration);
}It looks like UpdateFact just does this inside a DB-Transaction:
Did not understand the UpdateFactJSon difference, though. I rather expected an old/new comparizon and then the usual I was not able to confirm #482 with my panel plugin.
|
Understandable. I'd rather construct the Json string "by hand", indeed (it should be easy). And your workaround looks good, indeed (clever !).
This one I do not understand. Did you mean that #590 is fixed instead ? Otherwise, would you please elaborate ? |
|
Yeah sorry I meant #590 since I only deal with today's facts. Never worked the midnight shift so can't tell really how it behaves when a fact leaks onto the next day. Btw., I have a hamster-DB that goes all the way back to October, 2013. I stuck to the gtk+2 versions of both until it was no longer possible, when xfce4.16 finally dropped gtk+2 support. Only since then I am slowly making inroads to gtk+3... The port is rather stable and I am trying to get it into Void Linux (together with Hamster) and would like to see both in Alpine Linux, too. For me, Hamster always delivered as is. The only thing I would ask of it is to drop the 'Gnome' in its name since I am using it under every desktop I use, e.g. dmenu-driven under i3, sway and bspwm; xfce4-driven under vmWare and WSL1 and so on. I would also like to see a Windows/Mac OS/iOS port one day - none of the platforms I would expect to gnome to run at. And from how I experience it, python actually excels at being cross-platform. |
Thank for the confirmation that at least it does not seem to break anything.
The "midnight shift" is not the core issue. It's just where other "fixes" failed. Mine succeeds, but it's secondary.
Great !
Indeed, and I'm using KDE 🙂
#89 (comment) #222 (comment) |
This method was written to handle either a Fact object or a string
description of a fact. However, the string-to-Fact conversion happened
too late in the method, after `check_fact()` was called, which requires
a Fact object, leading to an error like:
AttributeError: 'dbus.String' object has no attribute 'start_time'
This happened in particular when using the DBus UpdateFact method, which
always passes a string to `update_fact()`.
This commit ensures that the string-to-Fact conversion is done
immediately, so the rest of the method can just assume there is a Fact
method.
This fixes projecthamster#671.
This method was written to handle either a Fact object or a string
description of a fact. However, the string-to-Fact conversion happened
too late in the method, after `check_fact()` was called, which requires
a Fact object, leading to an error like:
AttributeError: 'dbus.String' object has no attribute 'start_time'
This happened in particular when using the DBus UpdateFact method, which
always passes a string to `update_fact()`.
This commit ensures that the string-to-Fact conversion is done
immediately, so the rest of the method can just assume there is a Fact
method.
This fixes projecthamster#671.
Thanks to ederag for this commit, and to Hakan Erduman for submitting it
in a PR.
#671: convert str to Fact before check
I am in the process of adding in-place edits to the xfce4-hamster-plugin but I am hitting a block:
If I call UpdateFact like this:
9241, "chores@homeoffice", 1615451700, 1615455000, FalseI get the following:
Version 3.0.2. Everybody else seems to use the
UpdateFactJsonmethod. Should I stick to it instead or is there some way to make this API work?The text was updated successfully, but these errors were encountered: