Code für Listen überarbeitet

[seife]

Mir waren die gefühlt zehntausend Stellen, an denen Hoch/Runter/Seite Hoch/Seite Runter im Listenkontext behandelt wird (Kanalliste, Bouquetliste, Timerliste, ...) schon lange zuwider.

Heute habe ich deswegen mal ein praktisches c++-Feature, nämlich Templates benutzt um das aufzuräumen.

Code: Alles auswählen

~/src/neutrino-mp > git diff --stat 572de2bb...HEAD
 src/gui/bedit/bouqueteditor_bouquets.cpp | 43 +++-------------
 src/gui/bedit/bouqueteditor_bouquets.h   |  3 +-
 src/gui/bedit/bouqueteditor_channels.cpp | 42 +++------------
 src/gui/bedit/bouqueteditor_channels.h   |  3 +-
 src/gui/bouquetlist.cpp                  | 42 +++------------
 src/gui/bouquetlist.h                    |  3 +-
 src/gui/channellist.cpp                  | 30 +++--------
 src/gui/channellist.h                    |  3 +-
 src/gui/eventlist.cpp                    | 27 ++--------
 src/gui/eventlist.h                      |  3 +-
 src/gui/timerlist.cpp                    | 62 +++++------------------
 src/gui/timerlist.h                      |  7 +--
 src/gui/upnpbrowser.cpp                  | 37 +++-----------
 src/gui/upnpbrowser.h                    |  3 +-
 src/gui/widget/Makefile.am               |  1 +
 src/gui/widget/listbox.cpp               | 32 +++---------
 src/gui/widget/listbox.h                 |  3 +-
 src/gui/widget/listhelpers.cpp           | 87 ++++++++++++++++++++++++++++++++
 src/gui/widget/listhelpers.h             | 38 ++++++++++++++
 19 files changed, 198 insertions(+), 271 deletions(-)

Schön finde ich nicht nur die eingesparten Zeilen Code (wenn man die Kommentare in listhelpers.* nicht mitzählt, dann sind es noch mal über 80 mehr), sondern daß es nur noch eine Stelle gibt, an der fixes wie z.B. dieser https://github.com/neutrino-mp/neutrino ... 9e9396e3e0 gemacht werden müssen
Mal schauen, was man noch so vereinfachen könnte.

[svenhoefer]

Schöne Sache. Werde ich heute abend mal probieren. Die vielen Stellen mit identischem Code sind wirklich total unpraktisch.

[svenhoefer]

Llläuft.

[seife]

Sehr gut.
Das format-string Problem ist übrigens bei mir keines, weil neutrino-mp 64-bit safe ist (und deswegen neutrino_message_t eben kein int32 sondern ein long, der auf allen relevanten Plattformen äquivalent zur Größe eines Pointers ist).

[Tann]

seife deine alte Basis die passt noch nicht - stehen Pfade von Gitourios drin u.s.w.
kannst du die bitte noch anpassen das man damit kernel 217 bauen kann, das wäre echt lieb
Danke

[seife]

Welche "alte basis"?
Im ganzen neutrino Code kommt das wort "gitorious" nur in Kommentaren vor und die Patches für den Listencode haben das nicht angefasst.
Und abhängigkeiten auf irgendeinen Kernel gibts da auch nicht.

[Tann]

https://github.com/seife/historic-buildsystem die

[seife]

Achso, das hat also mit diesem Thread genau gar nichts zu tun

Das liegt nur dort, daß wenn mein Rechner explodiert das noch irgendwo im backup ist. Nicht umsonst steht dort "It should not be used anymore and is just deposited here for education and archiving."

Benutze openembedded / yocto, dann hast du auch einen reproduzierbaren build (für spark ein yocto < 2.0 nehmen, ich nehme momentan noch dizzy, das meta-spark muß ich für jethro und neuer erst apassen).

Das alte buildsystem macht so viele Sachen nicht richtig, das ist nicht zu empfehlen, und für mich nicht zu supporten.

Der einzige Grund es noch zu benutzen ist evtl. wenn man für Tripledragon bauen will, weil es relativ schwierig ist, die steinalte Toolchain mit einem aktuellen OE zu bauen (für die TD kann man momentan kein yocto neuer als daisy, 1.6 nehmen), aber die User die das evtl. tun wollen wissen was sie tun und brauchen keinen Support von mir.

[Tann]

gibts für yocto ne anleitung wie wo clonen starten etc.?

wäre trotzdem schön wenn die alte basis noch verwendbar wäre...

[seife]

Im alten Thread http://www.tuxbox.org/forum/viewt ... 77&t=50446 war's eigentlich schon erklärt, aber ich habe nochmals eine Anleitung gemacht: http://www.tuxbox.org/forum/viewt ... 77&t=50472

Niemand hindert dich daran, die "alte Basis" zu maintainen. Ich steige von toten Pferden lieber ab
Nein, im Ernst: das ist zu kaputt als daß man das verwenden will und den Aufwand das zu fixen will keiner bezahlen.
Und selbst wenn es gefixt werden würde, ist es featuremäßig immer noch weit hinter OpenEmbedded her.