Dotaz: Time tracker pro desktop - doporucte

[polo23]

Ahoj,
chtel jsem se zeptat, zda tu mate nekdo zkusenosti s nejakym jednoduchym time trackerem. Predstavuju si to tak, ze tam jen zadam aktivitu, kliknu na play a dal se nestaram. Kdyz praci na dane aktivite prerusim, kliknu na pause.

Kdysi jsem pouzival Hamster, a byl jsem s nim spokojeny. Ted to ale vypada, ze projekt skoncil. Googlil jsem, ale na nic fakt jednoducheho jako byl Hamster jsem nenarazil.

OS: Fedora 33
DE: GNOME

Nechci pouzivat nic weboveho...

Odpovědi

[GeorgeWH]

gtimer - sleduje aj aktivitu, takze ak odides a zabudnes pauznut, tak sa spyta, co s tym.

[polo23]

Diky za tip. Tohle, ale vypada, ze bych si musel kompilovat - trochu hardcore :) Neco z repozitare by nebylo?

[klingger]

Prečo si myslíte že hamster skončil? Podľa commitov na githube mi to príde živé dosť, v manjare to je normálne v repozitároch a napr. plugin pre xfce mal novú verziu pred necelým mesiacom.

[polo23]

Asi jsem se unahlil v hodnoceni... No, mam to nainstalovane a podle me je to UI horsi nez bylo - neni to tak intuitivni. Ale to je asi vec nazoru.

[marbu]

Dívám se akorát, že člověk co ve Fedoře ten balíček udržoval s tím přestal, nikdo to po něm nepřevzal a tak se to bohužel nakonec vyhodilo. Ale už je to nějaký ten pátek, pokud se dobře dívám, tak poslední Fedora s tímto balíčkem byla Feodra 30.

[LarryL]

Nevím jak je bezpečné stahovat balíčky z Copru. Když kliknu na odkaz https://data.neteler.org/tmp/hamster-time-tracker-3.0.2-1.fc32.src.rpm tak to píše "Not Found", takže pokud nejde ověřit zdrojáky, tak to moc bezpečné asi nebude. Celkem by mě zajímalo jestli instalování Snap balíčku je bezpečnější než Copr.

[marbu]

U Copru záleží, kdo vytvořil source rpm (tj. napsal spec file, případné patche a jak ověřil tarball se zdrojákem), který pak Copr vzal a vytvořil podle něj binární rpm (na tento process už nemá autor specfile vliv). Balíček v Copru může podobně jako v Archlinux AURu nebo Ubuntu PPA vytvořit kdokoli. Zkontroloval bych si, kdo ten balíček vytvořil a pokud něco vím o balíčkování, můžu mrknout i na ten ten zdrojový rpm. Pokud to vypadá důvěryhodně, neviděl bych v tom problém.

Např. tady u toho copr buildu co linkuješ vidím, že jeho autor spravuje ve Fedoře balíčky a je zapojený do vývoje Fedory už nějakou dobu. To Package URL co odkazuje na neexistující url https://data.neteler.org/tmp/hamster-time-tracker-3.0.2-1.fc32.src.rpm používá copr při startu buildu, a pokud již neexistuje, ničemu to nevadí. K source rpm který byl použitý při překladu se dostaneš přes položku "Chroot name" v tabulce Results, např.: fedora-32-x86_64.

[LarryL]

Balíček v Copru může podobně jako v Archlinux AURu nebo Ubuntu PPA vytvořit kdokoli.

Na AURu jsem zvyklý jen zkontrolovat malý configurák PKGBUILD, ve kterém zkontroluji jestli je tam správný odkaz na zdroják (většinou github) a je to. U toho Copru se mi to zdá složitější a úplně jsem zatím nepochopil jak to funguje.

jak ověřil tarball se zdrojákem

Když se dívám na spec, tak tam vidím, že "Source0" odkazuje na github tvůrce Hamsteru a ostatní Patchy jsou zakomentované, takže tam mám jistotu, že to nemůže být podvržené, je to tak? To ověřování tarballu se zdrojákem o kterém mluvíš se týká situace kdyby tvůrce spec file neodkazoval přímo na github tvůrce Hamsteru, ale použil by odkaz na své vlastní zdrojáky? Případně kdyby uploadoval zdrojáky ze svého PC (pokud Copr upload zdrojáků umožňuje)?

pokud něco vím o balíčkování, můžu mrknout i na ten ten zdrojový rpm.

V tom tvém odkazu jsou 2 soubory RPM, ale ani jeden mi nejde otevřít v Engrampě a i kdyby to šlo, tak RPM neznám. Ale jestli to chápu správně, tak ověřovat tyto zdrojové RPM má smysl jen kdybych neměl důvěru k buildovací infrastruktuře Copru. Jinými slovy: ty zdrojové RPM si vytvořil Builder Copru ze zdrojáků, které jsou uvedeny ve spec file? Pokud buildování Coprem důvěřuji, tak mi stačí ověřit pouze zdrojové cesty v souboru *.spec, je to tak?

[tak toto]

Na AURu jsem zvyklý jen zkontrolovat malý configurák PKGBUILD, ve kterém zkontroluji jestli je tam správný odkaz na zdroják (většinou github) a je to.

A je to :D:D:D :O:O :(

[LarryL]

A je to nebo není? Vidíš v něčem problém?

[marbu]

Zkus gtimelog, balíček ve Fedoře pro to je. Funguje to tak, že do políčka dole napíšeš co děláš, a až jsi hotov nebo práci přerušíš, dáš enter. To políčko umí doplňovat, případně můžeš nadefinovat seznam úkolů co se ukazuje vpravo, abys je mohl vybrat s pomocí myši. Geniálně jednoduché.

[BFU]

https://taskwarrior.org/ , ma to normalne commandline interface.

[tlacenka]

Používám Superproductivity.Vyhovuje mi: - jednoduše použitelné - upozornění na neaktivitu - import tasků z Jiry/Gitlabu - reporty

asi je to elektron, ale žiju s tím

[Josef Kufner]

Jak moc to žere paměť, CPU a tak vůbec?

[tlacenka]

To jsem popravdě nikdy neřešil, ale jak na to koukám, tak to žere celkem dost.

PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 13,2g 718416 529708 S 13,3 4,4 260:05.59 /opt/superProductivity/superproductivity

[Josef Kufner]

No... třičtvrtě giga paměti zaplácnuté stopkama je poněkud... ehm... no... tu paměť potřebuju na ty užitečné věci, které ty stopky mají měřit. Ach jo.

[Vantomas]

Však to nevadí, když se ten naměřený čas podaří vyfakturovat jinam

[Josef Kufner]

To je právě ten problém. Aby se ten čas mohl vyfakturovat, musí se dělat něco užitečného a na to je potřeba ta paměť.

Navíc jsem v tom nikde nenašel možnost označit část naměřeného času jako vyfakturovaného, ať už podle data, nebo podle hotových úkolů.

[tlacenka]

tasky muzes tagovat, nebo k nim psat poznamky

[Josef Kufner]

Na to jsem koukal, ale neumí to hromadné operace. Označit práci za posledních pár týdnů a nastavit tag by asi stačilo, ale neumí to.

[rastos]

Napísal som si vlastný V jave. A som lenivý dotiahnuť tam integráciu s D-bus-om, aby to reagovalo na idle desktop.