# Portato - A Portage GUI

## Necoro

WICHTIG: Projekt wurde umbenannt in Portato

[alt]

Vielleicht erinnern sich einige bzw haben es damals gelesen: Es gab/gibt mal das Genetic-Projekt, welches eine Remote-Zugriff für Portage zur Verfügung stellen wollte (damit auch ein GUI). Außerdem sollte das ganze plattform-unabhängig sein etc. Nun ja ... geworden ist es wie immer nix (immer mehr Leute hatten keine Lust mehr, bis nur noch ich übrig blieb) - weswegen ich beschlossen hab, das ganze als Single-User-GUI (das Remote-Zeugs kann man ja immer noch reinbauen, wenn der Rest da ist) unter dem Namen Genetic/One weiterzuführen. Es ist aber im Moment noch nicht sooo weit fortgeschritten - außer Emerge/Unmerge kann es noch nichts ... keine Use-Flags setzen und so... (kommt aber noch =P)

Vorteile gegenüber den GUIs die mir bekannt sind:

- klein  :Smile: 

- in Python (keine ewige Kompilierung notwendig)

- benutzt direkt die gentoolkit- & portage-funktionen (--> schnell)

Das wollte ich einfach nur kundtun und damit evtl den ein oder anderen zu finden, der es einsetzen/testen mag --- und evtl auch Mitarbeiter  :Wink: 

[/alt]

Homepage: http://necoro.eu/portato/

git branches: git://github.com/Necoro/portato.git git://github.com/Necoro/portato-overlay.git

"offizieller" engl. Thread im Forum: https://forums.gentoo.org/viewtopic-t-502350.html

Anmerkungen:

- Ja, ich weiß, dass es schon einige andere gibt - aber die gefallen mir nicht  :Wink: 

- Ja, ich weiß auch, dass es viele Leute gibt, die kein Portage-GUI mögen - die brauchen sich hier aber nicht zu Wort melden =P

/edit:

Aktuelle Version: 0.14.1

Features:

- emerge/unemerge (auch mit --oneshot)

- masking/keywording

- masking/keywording kompletter Queues

- ändern von useflags

- emerge --sync

- emerge --update [--deep] [--newuse] world

- interaktive emerges möglich

- interaktive suche

- Dialog zur Anzeige der updatebaren Pakete

- Abbruch des Emerge-Vorganges möglich

- ebuild-Anzeige mit Syntax-Highlighting

- Plugin-System

- GTK-Oberfläche

- Systray und Desktop-Menü-Einträge

----------

## Finswimmer

```
[08:44:52]|[root@tobi-rechner]|/home/tobi$geneticone

Traceback (most recent call last):

  File "/usr/bin/geneticone", line 14, in ?

    import vte

ImportError: No module named vte

```

Ich finde allerdings für python kein vte.

Oder soll ich x11-libs/vte nehmen?

Tobi

----------

## Necoro

Ups ... ja ... hab die Abhängigkeit vergessen  :Smile:  ... ist halt teilweise schwierig im Nachhinein die Dependencies  zu finden.. werde das nachher mal fixen

----------

## Necoro

--> neues ebuild  :Wink:  http://prdownloads.sourceforge.net/geneticone/geneticone-0.1_alpha-r2.ebuild?download

wenn noch mehr Dependency-Fehler da sind, bitte melden  :Smile: 

----------

## xraver

Hallo,

schön und gut das es immer wieder neue Projekte gibt.

Aber was ist an Kuroo so verkehrt? Ich persöhnlich finde emerge in der shell noch am besten, aber Kuroo bietet sehr viele brauchbare Optionen;

- Package Inspector (USE-Flags bestimmen, Versionen ändern)

- Progress bars (wers brauch)

- emerge and etc-update histories

- ..und und und

Gut, diese Programm muss man zwar kompilieren, bietet aber alle Optionen die dein Projekt auch bietet oder mal bieten soll.  Dafür ist es aber mittlerweile Recht stabiel und "it works".

Das Rad wird wie bei vielen Projekten neu erfunden - anstatt die Ressourcen zu sammeln.

----------

## Necoro

Naja ...: 

- kuroo ist mir zu KDE orientiert (zB erfordert die Hilfe unbedingt dieses kfmhelp oder wie das heißt) (bitte jetzt keine Flamewars über KDE/Gnome/etc)

- es verwaltet selber ne Datenbank --> Overkill / unnötig

- einige Funktionen fehlten (zu min damals als ich es testete)

- es gab noch so einige nachteile, die ich gerade nicht on the fly wiedergeben kann

- man muss es kompilieren ... und es dauert rel lange (12 min bei 1,6GHz)

----------

## Hilefoks

 *Necoro_dM wrote:*   

> - in Python (keine ewige Kompilierung notwendig) 

 

Das halte ich, nun ja, zumindest für eine grenzwertige Aussage. Die compile-Zeit wird ja schließlich nicht nur durch das Programm selbst bestimmt, sondern (u.U. vor allem) durch die Abhängigkeiten. Aber nix für ungut - viel Erfolg mit deinem Projekt!

MfG,

Hilefoks

----------

## Necoro

 *Hilefoks wrote:*   

>  *Necoro_dM wrote:*   - in Python (keine ewige Kompilierung notwendig)  
> 
> Das halte ich, nun ja, zumindest für eine grenzwertige Aussage. Die compile-Zeit wird ja schließlich nicht nur durch das Programm selbst bestimmt, sondern (u.U. vor allem) durch die Abhängigkeiten.

 

Nunja ... die einzige größere Abhängigkeit bei Genetic/One ist pygtk. Diese erfordert wiederum GTK. Sollte dieses noch nicht vorhanden sein, erhöht sich natürlich die Compilezeit... aber kuroo braucht kdelibs und qt ^^

 *Quote:*   

> 
> 
> Aber nix für ungut - viel Erfolg mit deinem Projekt!
> 
> 

 

Danke ^^ ... ich warte im moment darauf, dass ich an das pykeyword-projekt komme - denn kann ich mich ans USE/ACCEPT_KEYWORD/MASK-Flag setzen machen  :Wink: 

----------

## Necoro

So ... basis-suche ist auch drinne  :Wink: 

ansonsten (weswegen eigentlich der Post): hab die ebuild-version mal auf die offz Versionsnummer für svn-builds (9999) gesetzt:

http://prdownloads.sourceforge.net/geneticone/geneticone-9999.ebuild?download

----------

## Thargor

Wie sieht das ganze denn aus?

Könntest du (oder jemand der's grad antestet) mal nen Screenshot posten?

----------

## Necoro

Screenshots:

Hauptfenster mit was in der emerge-Queue

Paket-Fenster mit Details über ein Paket

Aber die Erscheinung kann und wird sich in Zukunft noch ändern. So ist zum Beispiel heute erst das Suchfeld da oben hinzugekommen ... und die Konsole werde ich wahrscheinlich auch irgendwann eher in weiß ändern.

----------

## think4urs11

genaugenommen ist das ja unsupportete Software, deswegen -> Diskussionsforum

----------

## Klaus Meier

Kuroo halte ich für absolut unbrauchbar, weil es die Konfigurationsdateien verändert. Jedenfalls so, daß danach kein ufed mehr geht. Ist schon etwas her als ich es probiert habe, habs danach nicht mehr angefaßt. Porthole gefällt mir da viel besser. Aber als Argument für oder gegen ein Paket die Kompilierzeit zu nehmen, halte ich gelinde gesagt, auch für sehr grenzwertig. Kuroo nehme ich nur, wenn ich sowieso schon KDE habe und porthole bei Gnome. Also fällt da doch qt oder gtk nicht mehr ins Gewicht. Und bei sagen wir mal 24 Stunden Kompilierzeit für ein ganzes System als Argument gegen ein Paket zu bringen, es würde 12 Minuten brauchen, dann darf man erst gar kein Gentoo benutzen.

Ansonsten finde ich solche grafischen Tools ganz nett, um mal zu sehen, was im Portage so alles drin ist. Als Normalnutzer hat man bestimmt erst 20% davon mitbekommen. Aber zum Arbeiten bleibe ich da lieber bei der Konsole. Man weiß dann, wozu welche Datei gut ist und was man wo eintragen muß. Wenn man immer nur mit so einem Tool arbeitet, dann lernt man das nicht. Und wenn die grafische Oberfläche mal streikt oder die ganze Kiste, dann hat man meistens nur eine Konsole zum reparieren.

Ist halt wie mit dem grafischen Installer. Da sagen auch viele, Installation per Hand muß sein, damit ich weiß, wie mein System aufgebaut ist.

----------

## Necoro

http://prdownloads.sourceforge.net/geneticone/geneticone-9999-r2.ebuild?download

Neue ebuild revision neues Glück =P ...

Habe rel viel dran rumgeschraubt ...  :Smile:  ... man kann jetzt u.a. suchen ... und USE-Flags editieren kann man auch  :Wink:  (aber achtung: ich schreibe diese beim emerge-Vorgang in die /etc/package.use - macht euch sicherheitshalber ein Backup ... es sollte nix passieren - aber man weiß ja nie) - und im Gegensatz zu kuroo lasse ich Comments und Reihenfolge und so unangetastet  :Wink: 

demnächst kommt denn noch package.[(un)?mask|keywords] dran ... =) --- und es müssen dringend Preferences eingebaut werden ... und so Standardsachen wie "emerge -NDu world" sind auch wichtig (aber schwer  :Confused:  )

Würde mich freuen, wenn sich der ein oder andere das mal anguckt - und vllt auch einen Wunsch oder einen Bug äußert =)

(und btw: wenn jmd mithelfen will, hätte ich auch nix dagegen  :Smile: )

----------

## firefly

ich hoffe du hast auch daran gedacht das die /etc/portage.* auch verzeichnisse sein können?

----------

## Necoro

Hab ich ...  :Wink: 

----------

## Necoro

So ... nu gibts Releases...  :Wink:  ... Version 0.3.1 ist da  :Smile:  ...

Für Details: https://forums.gentoo.org/viewtopic-t-502350.html

----------

## return13

wenn du so weiter machst probier ich es in den nächsten Relaises mal aus...

nice work   :Wink: 

----------

## Necoro

danke  :Wink: 

aber im moment stelle ich halt fest, dass da richtig Arbeit kommt:

- das mit dem Masken/Unmasken ist komplizierter als ich dachte ... im Gegensatz zu den USE-Flags kann ich die nicht on-the-fly ändern ohne in den Portage-Innereien zu wühlen ... was ich vorerst noch ein wenig herausschieben will, da meine Kentnisse über die Vorgänge noch zu begrenzt ist

- emerge --update world ... ich sehe noch keine Möglichkeit, die upzudatenden Pakte herauszubekommen ... außer den emerge-Output zu parsen ... was ich doof finde 

Also wird meine Roadmap erstmal so aussehen:

1. Preferences bauen ... ist relativ einfach und macht nich viel kaputt ^^

2.1 Optimieren ... kann schon eher was kaputt machen - bringt mir aber evtl mehr Einsichten in Portage ... vllt lös ich mich auch ein Stück von gentoolkit

2.2 Lade-Fenster bauen  :Smile:  - es lässt sich leider nicht alles wegoptimieren ... Portage ist nun mal nicht das schnellste =P

3. Unmasken & Co. einbauen

4. emerge --update world und so Spielereien

----------

## Necoro

Neues Release: 0.3.2

Nur eine Neustrukturierung des Sourcecodes vorgenommen und kleinere Bugs gefixed ... Preferences kommt demnächst (im Laufe der Woche?)

----------

## Klaus Meier

Mal ne Frage von einem Dummen. Was muß ich denn genau mit dem Ebuild machen, um das Programm zu erzeugen?

----------

## Necoro

Ganz einfach (alle folgenden Schritte als root):

wenn noch kein overlay vorhanden ist:

- mkdir /usr/local/portage

- echo 'PORTDIR_OVERLAY="/usr/local/portage"' >> /etc/make.conf

danach:

- mkdir -p /usr/local/portage/app-portage/geneticone

- das ebuild nach /usr/local/portage/app-portage/geneticone speichern

- ebuild /usr/local/portage/app-portage/geneticone/geneticone-0.3.2.ebuild digest

- emerge geneticone

Hinweise:

- /usr/local/portage ist nur ein Vorschlag - kann abgeändert/an vorhandene Overlays angepasst werden

- geneticone-0.3.2.ebuild ist natürlich durch das jeweilige ebuild zu ersetzen:)

- wenn das obige einmal gemacht wurde, reicht in Zukunft: ebuild /usr/[...] digest && emerge geneticone

----------

## Klaus Meier

Danke, werde es heute nachmittag mal testen.

----------

## Necoro

So ... ich habe das ganze mal in ein eigenes Overlay gebastelt:

das Overlay findet sich unter https://svn.sourceforge.net/svnroot/geneticone/overlay

das muss man denn nur noch auschecken  :Smile:  - das ebuild digest entfällt

noch einfacher: layman benutzen

```
layman -o http://portato.sf.net/layman.xml -S && layman -o http://portato.sf.net/layman.xml -a portato
```

und das Overlay ist auf dem Rechner  :Smile:  (und entsprechend by portage registriert)

----------

## Necoro

hmmm ... merke ... bei der "Konkurrenz" mal in den Sourcecode schauen lohnt sich  :Razz:  ... hab mir vorhin mal porthole (0.4.1 --- 0.5.0 ist masked und mir damit zu gefährlich) ... und siehe da: habe bemerkt, dass die portage-funktionen verwenden die um einiges schneller sind, als die, die ich benutze  :Wink:  (bzw sie reduzieren den Overhead) ... also diese mal schnell implementiert (und als ich denn auch noch mit der glorreichen "dir()"-Funktion durch die Portage-API gedüst bin hab ich auch noch einige andere kleine Gimmicks entdeckt) ... Außerdem habe ich manche - jetzt teilweise nicht mehr nachvollziehbare - Algorithmen-Sünden behoben --> Resultat: Das laden der Paketlisten ist ein ganzes Stück schneller gegangen ... Da überlege ich glatt, auf den "Lade"-Hinweis zu verzichten  :Smile: 

Diese Verbesserung gibts aber nur im SVN ... als Revision kommt sie mit dem nächsten größeren Update  :Wink: 

Außerdem durfte ich feststellen, dass mir Porthole auch nicht gefällt  :Wink:  (insbesondere bin ich ein Gegner von "Schonmal-im-Vornherein-alles-laden"  :Smile: )

----------

## franzf

Bin das grad mal am ausprobieren  :Smile: 

1) Es läuft unter amd64, ein keyword im ebuild wäre nett  :Smile: 

2) package.use / mask / etc:

Eine Option wäre schön in der Art (falls das alles Verzeichnisse und keine Dateien sind)

(default) use file geneticone

[ ] Use $package-category as storage file

(oder so in der Art)

Denn wenn jemand sich die Mühe macht und diese Sachen in einzelne Files zu schreiben (->Übersichtlicher) ist es kontraproduktiv wieder alles in einer einzigen Datei stehen zu haben.

Ansonsten gefällt mir das app nicht schlecht  :Smile: 

Werde auch mal die nächsten Versionen antesten.

Das einzige was ich schade finde ist die Verwendung von PyGtk - ich mag QT-Zeugs lieber  :Wink: 

Aber das ist eigentlich zweitrangig, hauptsache die Software läuft.

Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

> 1) Es läuft unter amd64, ein keyword im ebuild wäre nett 

 

Done  :Smile: 

 *Quote:*   

> 2) package.use / mask / etc:
> 
> Eine Option wäre schön in der Art (falls das alles Verzeichnisse und keine Dateien sind)
> 
> (default) use file geneticone
> ...

 

Ok - danke für den Hinweis  :Smile:  ... 

 *Quote:*   

> Ansonsten gefällt mir das app nicht schlecht 
> 
> Werde auch mal die nächsten Versionen antesten.
> 
> Das einzige was ich schade finde ist die Verwendung von PyGtk - ich mag QT-Zeugs lieber 
> ...

 

Das freut mich  :Smile:  ... 

Wegen QT: Gestern hatte ich kurz die Idee, ob ich nicht auch eine QT-Oberfläche dafür schreiben sollte (allein schon um QT zu lernen -- (GTK zu lernen war auch einer der Gründe, warum ich es hier verwende)) - hab das denn aber unter dem Punkt "unnötiger Overhead" fallen lassen ^^ ... vielleicht später mal, wenn der Rest läuft =)

----------

## Necoro

Ooops .. warum hat das niemand mitbekommen? - Unmerge funktionierte nicht -.- ... (man sollte nicht müde copy'n'paste machen)

Musste deswegen doch noch ne neue Revision fertig machen: 0.3.3 

Features:

- unmerge funzt jetzt =P

- bei weitem schneller (danke an Porthole für die Inspiration)  :Smile: 

----------

## Thargor

Ne qt Oberfläche wär schon ganz was feines.  :Very Happy:  Wäre echt super, wenn du sowas machen könntest

----------

## franzf

Ach ja, wegen dem package*-Optionen:

3) Mega-Monster-Algorithmus, der die Strategie bei der Wahl der Namen für die Dateien erkennt und diese logisch fortsetzt (  :Very Happy:  )

4) Ein weitere Option, bei der der User einzelne Kategorien auf Dateien mappen kann.

Eine sinnvolle Vorkonfiguration wäre für diesen Punkt sicher auch nicht schlecht.

Und was mir dazu heut auch noch eingefallen ist:

Wenn man schon eine gute Strategie anbietet wäre es nett, für alle faulen User eine Option anzubieten, die ganzen package.*-Sachen aufzuräumen.

Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

> Ach ja, wegen dem package*-Optionen:
> 
> 3) Mega-Monster-Algorithmus, der die Strategie bei der Wahl der Namen für die Dateien erkennt und diese logisch fortsetzt (  )
> 
> 4) Ein weitere Option, bei der der User einzelne Kategorien auf Dateien mappen kann.
> ...

 

Naja ... erstmal muss das alles laufen ^^ ... denn kann man sich darüber Gedanken machen ... weil das mit mask und keyword will noch nicht so richtig  :Wink: 

 *Quote:*   

> Und was mir dazu heut auch noch eingefallen ist:
> 
> Wenn man schon eine gute Strategie anbietet wäre es nett, für alle faulen User eine Option anzubieten, die ganzen package.*-Sachen aufzuräumen.

 

Das werde ich nicht einbauen  :Smile:  - weil mein Tool nicht dafür gedacht ist logische Arbeit des Benutzers abzunehmen, sondern nur Hilfestellungen zu bieten ... aber: es gibt schon so ein Tool: http://sourceforge.net/projects/gcac  :Wink:  ... das räumt die configs auf - weiß aber nicht, ob es auch mit "mehreren" Dateien (also /etc/package.use als Verzeichnis) klar kommt

Ach so: was QT angeht: Ich hab nix gegen Hilfe einzuwenden  :Razz: 

----------

## Thargor

Ne, damit kommt es blöderweise nicht klar (gibt auch irgendwo nen Thread zu dem Tool).

Eigentlich wollt ich das ja schon länger mal dahingehend verbessern, bloß kann ich halt kein c(++)   :Laughing: 

----------

## Necoro

Na wenn dem so ist ... vllt implementier ich das ja doch noch  :Smile:  - sind ja in Python nur so 10-20 Zeilen  :Wink: 

(wozu hab ich sonst ne Funktion "find_best_match (search_key, only_installed = False)") ^^ --- ich frag mich immer wieder, warum man Programme für Portage in C/C++/Java schreibt  :Wink: 

----------

## Necoro

So meine lieben  :Smile:  - Version 0.3.4 ist da:

Features:

- Preferences (wenn auch noch klein  :Wink: )

- noch ein Stück schneller als 0.3.3 (musste feststellen, dass ich am Anfang teilweise einfach nur Schwachsinns-Algorithmen gecodet habe  :Embarassed:  )

- Bug fix: wenn ein Paket noch nicht in der package.use stand und man mehr als ein Use-Flag änderte, wurde pro Flag eine Zeile in der package.use hinzugefügt

Die Preferences sind wie gesagt noch nicht sehr ausführlich. Im Moment kann man nur sagen, wie die Datei heißen soll, in die er die Useflags schreiben soll wenn package.use ein Verzeichnis ist und man kann steuern ob er die Useflags als "=cat/pkg-ver" oder allg als "cat/pkg" dort eintragen soll  :Smile: 

@franzf: Deine Vorschläge werden auch noch umgesetzt: Geht aber mit der bisherigen Struktur nicht so einfach  :Smile: 

Hinweis für die layman-benutzer:

```
layman -s geneticone
```

 synct den overlay  :Smile:  (bei Bedarf ist natürlich noch das -o http://geneticone.sf.net/layman.xml einzufügen  :Wink: )

/edit: @franzf: D'oh ... deine Vorschläge sind eigentlich doch total einfach umzusetzen: über Platzhalter ^^ ... *fragt sich warum er da nicht früher drauf kam*

----------

## Necoro

Also dem franzf seine Vorschläge habe ich inzwischen umgesetzt  :Wink: 

Ansonsten: habe das mit dem masking ans laufen bekommen ... mache dabei nur etwas, von dem ich nicht weiß, was das für (böse) Nebeneffekte haben könnte ...

vllt mag ja mal jmd drauf schauen, der Ahnung hat:

erstmal ist (schon in gentoolkit) definiert:

```
gentoolkit.settings = portage.config(clone=portage.settings)
```

so weit nicht dramatisch ... doch nun mach ich ein

```
gentoolkit.settings = portage.config(config_incrementals = copy.deepcopy(gentoolkit.settings.incrementals))
```

 (um die config neu zu bauen und die veränderten Masking-Stadi einzulesen)... und hoffe, dass dabei nichts böses passiert  :Wink: 

----------

## Klaus Meier

So, jetzt habe ich mir Geneticone auch mal angetan. Sehr schön finde ich das Feature, daß bei jedem Paket die Use-Flags angezeigt und erläutert werden. Ich habe dazu bislang immer ufed angeworfen. Porthole bietet diese Möglichkeit nicht.

Was man noch hinzufügen könnte: emerge --sync, emerge -uDN world als Buttons. Und vielleicht einen Schalter, wo statt emerge nightmerge oder ähnliches aufgerufen wird. Wo also nach einem abgebrochenem Paket weitergemacht wird.

----------

## SkaaliaN

ich werde es heute Abend auch mal testen! thx

LG

Scup

----------

## franzf

Ich finds klasse wie schnell das Projekt vorwärts geht  :Smile: 

Was mir spontan noch einfällt:

Übersichtlicher wärs wenn rechts die Queue nach unten wandert und sich mit der Console ein TabWidget teilt. Dann könnte man das rechteste ListView durch ein InfoWidget ersetzen. Beschreibung und Versionen hätten dann hier Platz.

Ein "install"-Button öffnet dann das Fenster, wofür man jetzt nen Doppelklick macht.

Da ich leider keinen Plan hab von wegen Python:

Hast du nen Link zu einer guten Einführung in Python? OOP ist kein Problem  :Wink: 

Aber da ich nur C++ / Java kenn...

Thx

Franz

----------

## Necoro

Erst einmal danke für das Feedback ^^ ... Noch ein kleiner Hinweis (nicht, dass jmd enttäuscht ist): Das, was ich da gestern nacht noch geschrieben habe (mit dem masking) findet sich nur im SVN  :Smile:  (wenn das unbedingt jmd ausprobieren will: geneticone-9999-r4 emergen  :Wink: )

 *Klaus Meier wrote:*   

> Was man noch hinzufügen könnte: emerge --sync, emerge -uDN world als Buttons. Und vielleicht einen Schalter, wo statt emerge nightmerge oder ähnliches aufgerufen wird. Wo also nach einem abgebrochenem Paket weitergemacht wird.

 

Wegen dem update world: Dieser Button kommt bestimmt - nur im Moment habe ich noch keinen Plan, wie ich die geupdateten Pakete ermitteln soll - und den emerge putput parsen tu ich nur im Notfall  :Wink: 

@franzf: Mal gucken, ob und wie ich deine Vorschläge umsetze(n kann)  :Smile:  - aber notiert sind sie erstmal

Wegen dem Python Tutorial: Also ich kenne (und benutz(t)e) nur das mit den Python-Docs mitgelieferte Tutorial. Denn es ist auch eine Stärke von Python, dass man es rasend schnell lernt ... und die Kniffe bekommt man denn während des Benutzens  :Wink: 

----------

## Thargor

Mir ist grad was aufgefallen:

Das "Detail-Fenster" also das, wo man USE-Flags einstellen kann, bzw Pakete zur Warteschlange hinzufügt ist bei mir oft entweder viel zu klein (so dass man die Paket-Description nichtmehr lesen kann) oder viel zu groß (so dass es über den Bildschirmrand ragt), je nachdem, wie lang die USE-Flag-Description ist.

Hier wäre eine Minimalgröße, bzw. eine Maximalgröße (z.b. Bildschirmbreite) sinnvoll.

Wollt ich nur mal loswerden, vielleicht kommts ja dann noch ins nächste Release  :Very Happy: 

----------

## Necoro

 *Thargor wrote:*   

> Das "Detail-Fenster" also das, wo man USE-Flags einstellen kann, bzw Pakete zur Warteschlange hinzufügt ist bei mir oft entweder viel zu klein (so dass man die Paket-Description nichtmehr lesen kann)

 

Screenshot bitte  :Shocked:  ... das sollte nämlich nie auftreten

 *Quote:*   

> oder viel zu groß (so dass es über den Bildschirmrand ragt), je nachdem, wie lang die USE-Flag-Description ist.
> 
> Hier wäre eine Minimalgröße, bzw. eine Maximalgröße (z.b. Bildschirmbreite) sinnvoll.

 

Das kann durchaus sein  :Wink:  ... werde mal ein "wrap" in die Use-Flag-Description einbauen

Ein Bug ist auch, dass die Use-Flag-Anzeige nach unten zu lang wird ... leider hab ich da noch keine Möglichkeit gefunden, dass einzustellen ... 

Anm.: Bis So abend ist Development-Pause ^^ ... RL ruft  :Razz: 

----------

## Thargor

Ok, tritt doch nicht auf...das Paket hat nur ne Description von 3 Wörtern  :Rolling Eyes: 

Aber die Description ist teilweise schlecht lesbar, wenn die so am Fensterrand klebt, da wäre ein Abstand recht praktisch.

(Ja ich weiß, ich bin ein ewiger Nörgler  :Wink:  )

----------

## Necoro

Hmmm ... schick mir mal einen Screenshot - und/oder den Namen des Paketes bei dem das auftritt ... weil eigentlich sollte es nicht  :Wink:  ... die beschreibung ist immer zentriert - und durch die 3 Checkboxen sollte das Fenster eigentlich auch eine Mindestbreite haben

----------

## Thargor

app-editors/scite

Bild: http://3141592653.31.funpic.de/geneticone.png

Btw: ksnapshot ist ganz was feines, wers nicht kennt, umbedingt mal ausprobieren  :Shocked: 

----------

## Necoro

puuh ... bei mir sieht das ordentlich(er) aus:

http://download.necoro.net/stuff/shots/geneticone_scite.jpg  :Wink: 

merke: es muss auch mal jmd am design rumspielen, der n anderes/n Theme/WM verwendet als ich ;D

----------

## Thargor

Sieht mir gewaltig nach gnome aus, vermutlich liegt's daran.

Ich verwnede kde, da ist das mit den gtk-apps sone Sache....

----------

## Necoro

Naaaa ... kein Gnome ... ich benutz XFCE  :Wink: 

----------

## Thargor

Läuft aber in dem Fall auf das gleiche raus, oder?

http://de.wikipedia.org/wiki/Xfce

 *Quote:*   

> ...Xfce verwendet Gtk+...

 

Und das ist unter kde irgendwie doof^^

Btw: wie sehen eigentlich qt-apps unter xfce aus (z.b. Amarok)?

Wirken die genauso deplaziert wie gtk-apps unter qt-Oberflächen?

Edith: Juhu, kein n00b mehr  :Very Happy: 

----------

## Vortex375

Ob die deplaziert aussehen, hängt ganz davon ab, welchen Style du bei gtk und Qt eingestellt hast. Wenn die beien Stile halt vom Aussehen her nicht zueinander passen, dann siehst natürlich komisch aus.

Ich benutze QtCurve, das ist ein Style für beides, Qt und gtk. Wenn man bei Qt und gtk QtCurve als Stil auswählt sehen alle Programme einheitlich aus. Die Einstellungen die man im kde-Kontrollzentrum macht wirken sich auch auf die gtk-Programme  aus (ja, ist ne feine Sache  :Wink: ).

----------

## Thargor

Klar, mit QTCurve sieht es schon besser aus (benutze das auch), aber vieles ist immernoch unterschiedlich (Symbole, "Speichern unter Dialoge", Menüs sehen imo leicht anders aus, etc.)

Außerdem sieht Firefox imo immer grau aus, egal was ich im kcontrol einstell.

Back to Topic: Wie schaut's aus, wirst du uns demnächst mit 'ner neuen Version beglücken? Was für Features gibt's?

Geneticone rockt  :Twisted Evil: 

----------

## Necoro

 *Thargor wrote:*   

> Geneticone rockt 

 

*ausdruck* *einrahm* *aufhäng*  :Razz:  ...   :Arrow:  *Motivationsschub*  :Cool: 

Was die neue Version angeht: da ich wie gesagt das WE über keine Zeit hab, werde ich wohl Software-Engineering- und KNT-Vorlesungen zum proggen nutzen  :Razz:  ... Ich denke Mitte bis Ende der Woche sollte was stehen ^^

----------

## Necoro

Also ... viel schneller als gedacht: Genetic/One 0.4.0 ist da  :Smile:  (die SWE-Vorlesung hat länger gedauert als gedacht  :Razz:  )

Features:

- korrektes masking/unmasking/keywording

- bei Testing-Paketen, deren Keyword gesetzt wurde, wird nicht einfach mehr das Häkchen entfernt, sondern "Testing" wird zu "(Testing)". Damit kann man besser zwischen Testing-Paketen mit Keyword und Stable-Paketen unterscheiden

- unmasking/keywording von Queues: sprich: ein Paket und alle Dependencies werden in den entsprechendes Status versetzt

- debug-meldungen lassen sich abschalten

- kleinere Änderungen / Fixes

Hinweise:

- Der Preference-Dialog sieht im Moment einfach nur schlecht aus  :Smile:  - aber er fuktioniert und ich hatte noch keine Lust mich mit Design auseinander zu setzen

- Es gibt teilweise noch Bugs (zB dass man Emerge klickt und nichts passiert) - leider konnte ich diese Bugs nicht reproduzieren (sie entstanden nach einiger Zeit des Rumspielens) und deshalb auch nicht fixen. Wer welche findet: entweder hier posten und/oder bei sf.net in den Bugtracker

ToDo:

- Doku

- Design : Ich denke dass ich das Paket-Info-Fenster überarbeiten werde - wie genau weiß ich aber noch net

- Code aufräumen  :Wink: 

- elog-Parser bauen  :Wink: 

----------

## return13

Auch von mir ein Lob für die Geschwindigkeit mit der es vorran geht.

Hab die aktuelle SVN Version nun ausprobiert... grafisch kann man sicherlich noch was machen, aber der Vorschlag

 *franzf wrote:*   

> 
> 
> Übersichtlicher wärs wenn rechts die Queue nach unten wandert und sich mit der Console ein TabWidget teilt. Dann könnte man das rechteste ListView durch ein InfoWidget ersetzen. Beschreibung und Versionen hätten dann hier Platz.
> 
> 

 

halte ich doch für recht sinnvoll... hab aufgrund des Projektes angefangen mich in python einzuarbeiten... vielleicht leiste ich dir bald Gesellschaft...

----------

## Thargor

Super Arbeit, unter xfce sieht's dann auch wirklich gut aus  :Very Happy: 

...damit komme ich auch gleich zum ersten bug:

Manchmal wird beim Wechseln zeischen zwei Paketversionen im Detail Fenster dieses auf einmal um einiges größer (z.B. xfce-base/xfce4 Versionen: 4.2.2 und 4.2.1.1 (Wobei egal ist, in welche Richtung man wechselt)) bei anderen Versionen von xfce4 bleibt alles normal. Wenn man von diesen Versionen auf die normalen wechselt passt sich die Höhe des Detail-Fensters an, die Breite bleibt aber so.

und noch ein Vorschlag: wäre es vielleicht möglich die "ge-keywordetes in Klammern" auch für das (un)masking umzusetzen? Das ist ja (wie man auf den Bildern sieht (xfce4-4.3.90.2) noch nicht so.

Hier noch ein paar Bilder dazu:

Alles ok/ unmasking nicht in Klammern: http://3141592653.31.funpic.de/geneticone/geneticone-bug_ok.png

Bug: http://3141592653.31.funpic.de/geneticone/geneticone-bug_schlecht.png

gleicher Bug: http://3141592653.31.funpic.de/geneticone/geneticone-bug_schlecht.png

Btw:

Hatte eigentlich auch vor, mir Python anzuschauen, aber wenn ich mir hier den Code anseh erschlägt es mich irgendwie^^

Werd aber weiter versuchen, da durch zu steigen

----------

## Necoro

Soo ... also: den Bug, den du da gefunden hast war ein mieser ... Hintergrund war, dass diese beiden Pakete USE-Flags haben, die nur leider nicht angezeigt wurden - hatte bei einer meiner Optimierungen (statt das Widget neu zu bauen wurde nur der Inhalt refreshed) vergessen, das Show-Flag zu resetten... als weitere Folge dieser Optimierung wurde das Widget nicht wieder kleiner ... aber zakarum sei dank hatte ich meinen SVN und die alte Version: an der Stelle wieder den alten Code eingebaut und es funktioniert wunderbar

 :Arrow:  Bug ist in SVN gefixed  :Smile: 

Wegen dem Masking: Ich hatte es auch noch vor - nur leider kann ich da (im gegensatz zum Testing) nicht auf portage-sachen komplett zurückgreifen  :Smile:  - macht einfach nur ein bissl mehr arbeit  :Smile:  - kommt aber

Wegen dem Python und dem Code: Zugegeben: mein code ist nur suboptimal kommentiert  :Smile:  - aber viel von den Zeilen in gui/ (insb gui/windows.py) ist nur "packe button A neben Label B unter Edit C" usw ^^ --- dat sieht nur unheimlich komplex aus - ist es aber net wirklich

Zum Schluss: Ist mir gerade aufgefallen: Soll das in deiner Sig wirklich "Cockies" heißen?  - Und nicht eher "Cookies"? - Ich sehe zwischen den beiden Sachen einen ... ähm ... Unterschied  :Laughing: 

edit:/ Bevor ich es vergesse: Kann/mag jmd ein Logo kreieren?

----------

## Necoro

So: Wer mag, kann sich mal das neuste SVN anschauen  :Smile: 

Habe ein wenig am Design rumgespielt (wie vorgeschlagen ist die Queue jetzt mit nach unten gewandert) - ich habe aber kein Info-Widget mit eingebaut ... diese müsste einen Großteil der Funktionalität des PackageWindows kopieren, was die Anwendung nicht wirklich schneller macht ... ich habe überlegt, vllt ganz auf das PackageWindow zu verzichten - hatte denn aber noch keine Lösung gefunden, wie ich dann die Use-Flag-Liste unterbringe  :Smile: 

Des weiteren habe ich jetzt die Möglichkeit integriert, bestimmte Pakete als "oneshot" zu markieren ... diese ist noch nicht komplett ausgereift  :Smile:  - sprich: sie funktioniert, so lange man nicht versucht exotische sachen mit ihr anzustellen (zB das Emerge-Label als oneshot zu markieren  :Wink: )

Ansonsten: Besteht Bedarf an einer Mailingliste? - Damit ich hier das Forum nicht so vollspamme  :Smile: 

Gute Nacht,

Nec

----------

## moe

 *Necoro_dM wrote:*   

> 
> 
> Ansonsten: Besteht Bedarf an einer Mailingliste? - Damit ich hier das Forum nicht so vollspamme 
> 
> 

 

Also mich interessiert zwar eine Portage-GUI nicht wirklich, aber ich finds trotzdem interessant hier mitzulesen wie ein Programm entsteht, bzw. wie es weiterentwickelt wird.

Und da es ja eh im Diskussionsforum ist, und hier Threads überleben die wesentlich mehr OT sind, dürfts in meinen Augen kein Problem sein.

Gruss Maurice

----------

## Necoro

Soooo ... um evtl Helfern  :Cool:  ein wenig zu helfen  :Wink:  habe ich heute mal eine große Doku-Session geschoben  :Smile:  ... es fehlen zwar noch einige Teile, aber n großes Stück ist fertig ...

Deswegen hab ich auch in den SVN-ebuild ein "doc"-Use-Flag mit eingebaut, welches m.H. von epydoc eine HTML-API-Doku erstellt (falls sie jmd brauchen sollte  :Wink: ) ...

Ach - und einn paar Bugs wurden auch ... gegangen  :Smile:  (Code Review rockt  :Razz:  )

In diesem Sinne,

Nec

----------

## Necoro

Und wieder was neues:

Habe mir mal erlaubt, zum einen "emerge --sync" zu implementieren (zu erreichen über das "Emerge"-Menü), als auch die erste Basisversion von "emerge --update world". Diese Basisversion kann noch kein "--deep" und "--newuse". Dies kommt vllt noch heute, vllt später  :Razz: 

Nutzungshinweis dazu:

"Update world" berechnet nur die Aktualisierungen und zeigt sie an - erst ein "Emerge" schmeißt sie auch ins System.

Viel Spaß  :Smile: 

----------

## Necoro

Also da bin ich denn doch gleich nochmal: Auch "--deep" funktioniert jetzt  :Smile:   (es lässt sich bei Preferences anschalten)... Leider ist es langsamer als das von emerge (emerge: 13Sek; Genetic/One: 18sek) -.- ...

Da ich aber diese Funktion nicht in aller Tiefe überprüfen konnte (gibt halt nicht so viel zu updaten im moment), frage ich jetzt euch um Mithilfe  :Wink:  ... testet mal bitte ob die verschiedenen Update-Modi im GUI die gleichen Ergebnisse bringen wie ein "emerge --update (--deep) --pretend world" in der Konsole  :Smile: 

(vllt posten danach wieder ein paar mehr Leute hier in den Thread - und net nur ich  :Wink:  )

Ach so: wenn mein --deep schon langsamer ist, so ist mein normales update denn doch schneller (emerge: 3,5sek; Genetiic/One: 0,8sek) ^^

----------

## return13

ok, hab jetzt erstmal das update World getestet... - schein gut zu funktionieren..

die Queue ist jetzt auch besser gelöst - das einzige was mir jetzt noch wirklich fehlen würde ist ein infofeld für die Pakete... damit man durch portage browsen kann und sich dabei die paketbeschreibungen durchlesen kann, um das richtige zu finden, oder bzw. erst mal zur hersteller seite zu kommen...

http://img141.imageshack.us/img141/889/screenshot20061016061550windowfp0.jpg

edit:

vielleicht noch zur Queue - wie wärs wenn die Queue beim emerge start nicht direkt geleert werden würde, sondern nach und nach die Pakete die bereits emerged sind verschwinden?

----------

## return13

Wollte gerade die neue Version emergen...

```

# emerge -auv geneticone

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     UD] app-portage/geneticone-9999 [9999-r5] USE="doc" 0 kB [3] 

Total size of downloads: 0 kB

Portage overlays:

 [1] /usr/local/overlays/local

 [2] /usr/local/overlays/gentoo-de

 [3] /usr/portage/local/layman/geneticone

Would you like to merge these packages? [Yes/No] y

>>> Emerging (1 of 1) app-portage/geneticone-9999 to /

 * checking ebuild checksums ;-) ...                                      [ ok ]

 * checking auxfile checksums ;-) ...                                     [ ok ]

 * checking miscfile checksums ;-) ...                                    [ ok ]

>>> Unpacking source...

 * subversion update start -->

 *      repository: https://svn.sourceforge.net/svnroot/geneticone/trunk

svn: PROPFIND Anfrage fehlgeschlagen auf '/svnroot/geneticone/trunk'

svn: PROPFIND von '/svnroot/geneticone/trunk': SSL negotiation failed: SSL disabled due to library version mismatch (https://svn.sourceforge.net)

!!! ERROR: app-portage/geneticone-9999 failed.

Call stack:

  ebuild.sh, line 1568:   Called dyn_unpack

  ebuild.sh, line 708:   Called src_unpack

  ebuild.sh, line 1261:   Called subversion_src_unpack

  subversion.eclass, line 274:   Called subversion_fetch

  subversion.eclass, line 195:   Called die

!!! subversion.eclass: can't update from https://svn.sourceforge.net/svnroot/geneticone/trunk.

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! This ebuild is from an overlay: '/usr/portage/local/layman/geneticone'

```

----------

## franzf

return13:

```
emerge subversion
```

 sollte helfen.

Hatte das auch schon manchmal.

----------

## return13

hatte ich bereits, aber half nicht...

```

# emerge subversion && /etc/init.d/svnserve start

```

svn läuft soweit, nur krieg ich das Paket nicht emerged

----------

## franzf

 *return13 wrote:*   

> 
> 
> ```
> 
> # emerge subversion && /etc/init.d/svnserve start
> ...

 

Nur musst du svn nicht starten um auf einen svnserver zuzugreifen  :Wink: 

Wart einfach mal, vllt ist es ja dann ein Server-Problem (wobei es bei mir grad funktioniert hat...)

Grüße

Franz

----------

## Necoro

@return13: das problem hatte ich auch mal ... bau mal openssl und svn neu  :Smile:  (und du musst keinen svn-server starten um auf einen solchen zuzugreifen) ...

btw: mein update world hatte noch probleme  :Smile:  die habe ich in der zwischenzeit gefixt (sind im svn) ... werde demnächst (am WE) daraus auch ein Release bauen (vllt ist denn sogar schon das newuse drinne - aber garantieren kann ich nix) ... muss nebenbei noch an einem zwar simplen Projekt für die BA arbeiten, aber wir haben uns einfach mal spontan entschlossen, für dieses Projekt Perl zu verwenden - und Perl kann ich noch net, deswegen geht jetzt erstmal n bissl Zeit dafür drauf ^^ --- und RL gibts ja auch noch;)

edit:/ ach so ... und bin genauso spontan (danke tek0 für den Tipp) auf zsh umgestiegen und arbeite mich auch da gerade noch ein  :Razz:  (*das auch zeit kosten tut*)

----------

## Necoro

Release 0.4.5 ist da ... Ist im Prinzip nur ein Snapshot des SVN - daher keine Änderungen (außer dass ich das "--newuse" aus den Prefs rausgenommen hat, damit niemand denkt, dass das schon funktioniert)

Wollte nur anmerken, dass ich wen suche, der sich an einem Qt-Frontend dafür versuchen würde  :Smile:  Auch jemand, der mehr Design-Ahnung hat als ich (also >0) würde sehr helfen, um das gtk-Frontend ein wenig zu optimieren  :Smile: 

So far,

Nec

----------

## return13

nachdem ich portage gefüttert hab läuft jetzt alles wieder....

```

#emerge -eat openssl

```

----------

## Necoro

Soo ... irgendwann die nächste Zeit habe ich noch vor die Unterstützung für "--newuse" zu implementieren. Wenn dies geschehen ist, und es funktioniert, würde ich es am liebsten für den offz Portage-Tree committen  :Smile: 

Bevor es aber noch so weit ist, habe ich anderes "Problem" - ich finde den Namen "Genetic/One" nicht gut  :Smile: .

Probleme:

- zu lang  :Wink: 

- mit sonderzeichen, was als unix-befehl wegfällt

- sollte ursprünglich mal die Verwandtschaft zu "Genetic" demonstrieren (ich hoffte, dass das wieder auf die Beine kommt) - aber da das inzwischen klinisch tot ist, kann ich auch auf den Aspekt verzichten.

Deshalb frage ich einfach mal nach Namensvorschlägen  :Smile:  - als eigenen hätte ich noch "Onod" anzubieten - das ist elbisch für Ent welches man wiederum mit "Baumwächter" (Daten von J.R.R. Tolkien  :Wink: ) übersetzen kann (eine netter Zusammenhang zum Portage-Baum, wie ich finde)  :Wink: 

----------

## return13

könntest es auch einfach Baum nennen...  :Wink: 

Ne jetzt mal im ernst Onod finde ich zwar blöd auszusprechen und trotz der kürze auch schwer zu merken... da find ich geneticone doch einfacher...

----------

## franzf

 *return13 wrote:*   

> Ne jetzt mal im ernst Onod finde ich zwar blöd auszusprechen und trotz der kürze auch schwer zu merken...

 

Solche Sätze find ich imer wieder geil zu lesen  :Very Happy: 

Ich find es zwar blöd -> nun erwartet man ein Argument, das doch für das Produkt spricht -> Pustekuchen, es ist auch noch schwer zu merken  :Wink:  (bzw der aber-Teil fehlt)

Zum Thema:

* genode

* viewport

* xport / gport / qport

usw...

(um mal ein paar Vorschläge zur Diskussion bezutragen)

Und gerade vorhin wo ich mich mal richtig fest mit Python beschäftigen konnte/wollte klingelt das Telefon und ich kann nicht weiter machen *BLABLABLA*

Grüße

Franz

----------

## Necoro

Ok ... *streicht onod von der Liste* ... franzf: nette Vorschläge ... ich stell mal noch "gmerge" dazu (wobei 'g' hier für "graphical" steht und nicht für "gtk"  :Wink:  )

----------

## Klaus Meier

So, ich möchte hier mal kurz meine ersten Erfahrungen mit KDevelop loswerden. Es unterstützt Pythonanwendungen für QT. Gefällt mir alles sehr gut. Wie sieht es da aus mit Linken? Kann ich eine QT-Oberfläche schreiben, welche dann die Funktionen von Geneticon dazulinkt oder müssen die im Paket integriert werden? Das Ziel sollten ja auch nicht zwei verschiedene Anwendungen sein, sondern eine, die je nach USE-Flag mit einer anderen Oberfläche auftaucht.

----------

## Klaus Meier

Irgendwie finde ich 90% aller Namen blöd. Entweder sie beginnen einfach mit G oder K oder sind extreme Ungetüme. Enlightenment oder sowas. Da vergißt man doch immer irgendwo ein h oder weiß nicht, ich welcher Reihenfolge man die ms und ns sortieren soll. Gerade Gnome zeichnet sich ja durch solche Ungetüme aus. Ok, Epiphany kennt man irgend wann mal, aber sonderlich Sinn macht es nicht. Und dann Brasero? Mußte ich fünfmal nachlesen, bis ich es mir gemerkt habe.

gmerge ist irgendwie nicht schlecht, aber da stört mich wieder dieses Gnome g. Supermerge, Topmerge, oder emergicon. Sowas in der Art. Da weiß man, um was es geht. Aber was passendes hab ich auch noch nicht.

Elbisch und Klingonisch ist ja ganz nett, aber da kommt doch keiner drauf. Finds immer Mist, wenn ich etwas über ein tolles Program gelesen habe,am nächsten Tag aber absolut nicht mehr weiß, wie er heißt.

----------

## Necoro

 *Klaus Meier wrote:*   

> Wie sieht es da aus mit Linken? Kann ich eine QT-Oberfläche schreiben, welche dann die Funktionen von Geneticon dazulinkt oder müssen die im Paket integriert werden?

 

Also es gibt zwei Möglichkeiten:

1.) man trennt backend und GUI - und je nachdem was für ein Useflag gesetzt wird, installiert man quasi ein anderes GUI. Diese Lösung finde ich aber nicht gut, da sie nur zur Verwirrung beiträgt. Und auch will mir nicht einleuchten, warum man bei einer GUI-Anwendung Backend und GUI getrennt ausliefern soll  :Wink:  (es soll trotzdem später auch möglich sein, das ganze komplett ohne Oberfläche zu installieren, wenn man nur die Funktionen zu Portage hin verwenden will)

2.) man baut beide GUIs direkt in das Paket mit ein... das hieße zB, dass man in geneticone/gui noch eine datei "qt_windows.py" (oder auch noch mehr) mit hereinbringt. 

Dies ist insofern eigentlich sehr sinnvoll, als dass die GUIs an sich so gut wie nichts selber berechnen sollen - da diese Algorithmen in  beiden auftauchen sollen und es nicht der OO-Theorie entspricht. Im Moment erledigen die Klassen in "geneticone/gui/gui_helper.py" ein Gros der Rechenarbeit - aber das ist noch nicht ausgegoren. Teilweise wird noch zu viel in den Windows an sich gemacht - und die Klassen in gui_helper erwarten teilweise auch explizit gtk.Widgets. Das müsste man denn kapseln (indem man zB eine abstrakte Wrapper-Klasse "Tree" baut, die quasi zwei Unterklassen hat: "GtkTree" und "QtTree", welche jeweils einige gängige Aufrufe (anhängen, löschen. position bestimmen etc.) wrappen.

Aber: an diese Arbeit werde ich mich wohl frühestens nächste Woche setzen (es sei denn ich habe vorher spontan Lust), da im Moment einige BA-Projekte anstehen.

ach zum Namen: noch was: pof ... - von Portage-Oberfläche  :Wink:  ... wiewohl ich emergicon auch interessant finde  :Smile: 

----------

## firefly

das problem, was du in deinem "2.)" ansprichst, kann man mit dem backend-frontend system lösen  :Wink: 

das backend beinhaltet die ganze funktionalität deines Programms und bietet eine Schnittstelle an, über diese eine UI die funktionalität in geregelter weise benutzen kann.

z.b. das backend bekommt den auftrag "emerge -pv world" auszuführen.

wenn das backend fertig mit dem auftrag ist, bekommt die aufrufende Instanze das ergebniss zurückgeliefert. Entweder über den Rückgabe wert der funktion (was aber in einem blocken der UI führen würde) oder die UI hohlt sich das ergebnis, des letzten auftrags, über eine andere Funktion/Methode.

Wenn dann das backend und die UI in seperaten Threads laufen, dann kann die UI z.b. eine Fortschritts-anzeige aktuallisieren, den auftrag abbrechen oder dem user die möglichkeit bieten in begrenzter art das Programm weiter zu nutzen (wenn die art des auftrags das zu lässt)

----------

## Klaus Meier

Genau so habe ich mir das eigentlich auch vorgestellt. Weil wir dann ja zwei Frontends haben. Das stelle ich mir so vor, daß die Funktionen von einem Backend bereit gestellt werden. Und diese Funktionen werden dann von einem GTK- und einem QT-Frontend aufgerufen. Kann mir nicht vorstellen, wie man das anders mischen kann.

----------

## Necoro

Nun ja - backend und GUI sind schon von einander gekapselt (und es ist sichergestellt, dass gui nur backend aufruft und nicht andersrum). Die Datei "gui_helper.py" ist aber Bestandteil des GUIs (wie der Name vermuten lässt) - und wäre daher auch bei einer Trennung in zwei verschiedene Pakete immer noch im GUI-Teil. Sicher bestände die Möglichkeit, dass der Qt-Part sich das selber schreibt, was aber aufgrund dessen was die Klassen machen nicht so sinnvoll ist. 

Nur zur Info, was in dieser Datei vorhanden ist - vllt kann man das denn besser verstehen, warum das ein GUI und kein Backend-Part ist:

- Config: eine Klasse zur Verwaltung der Konfiguration: da diese Config dem Backend ziemlich egal ist, fällt es nach meiner Meinung zu dem GUI Part (da es teilweise auch anzeige oder so steuert)

- Database: eine "Paket-Datenbank" um gerade nicht so häufig aufs Backend zugreifen zu müssen (diese könnte man in der Tat evtl ins Backend auslagern, da sie irgendwie zwischen beiden Welten lebt  :Wink: )

- EmergeQueue: der wichtigste Teil in dieser Datei: sie steuert die gesamte Logik hinter der Emerge-Queue in der Anzeige: dies beinhaltet Dependency-Berechnung (soll heißen: das Ansteuern der richtigen Backend-Funktionen), Löschen (das ist komplexer als man denkt), Hinzufügen usw. Da sie auch direkt aufs GUI zugreift, gehört sie nicht ins Backend.

Noch als Hinweis: Genetic/One zeigt nur an  :Smile:  - alle sachen die direkt ins Emergen gehn, werden direkt durch emerge gelöst (ergo: emerge wird direkt aufgerufen) - und das läuft komischer weise als thread  :Wink: 

edit:/ Da es scheinbar nicht offensichtlich ist: Backend enthält Sachen wie "zeige mir alle installierten pakete die einem muster entsprechen", "gib mir alle abhängigkeiten von X", "setze flag Y für X", "ist X installiert?", usw. - und das ist wie gesagt gekapselt

edit2:/ Noch was: Und das "Pseudo-Backend" für die Frontends ist gerade diese "gui_helper.py" - nur ist die noch nicht komplett gekapselt, da sie noch auf GTK beruht - was aber nicht viel Arbeit macht, das abzuändern... und theoretisch kann man auch von außerhalb auf sie zugreifen - aber ich fände es halt besser, wenn das Qt-Frontend direkt mit im Projekt ist  :Smile: 

----------

## Klaus Meier

Ich installiere mir jetzt erst mal wieder geneticone und schau mir den Code an. Hab meinen Rechner wegen KDevelop von Gnome auf KDE umgestellt und da läuft irgendwas nicht rund. Einige Sachen kacken ständig ab. Wenn ich das im Griff habe, dann geht es los. Sollten vielleicht am Wochenende mal telefonieren, wenn es dir paßt.

----------

## Necoro

Nun mangels Festnetz auf meiner Seite könnte das ein teures Vergnügen werden  :Wink:  (ich sollte mich endlich mal aufraffen und mir n Telefon besorgen) - würde eher IM vorschlagen - meine Kontaktdaten diesbezüglich stehen unter diesem Post  :Smile: . Muss aber erstmal sehen, ob ich dieses WE n Rechner zur Verfügung hab - kann das nicht garantieren.

----------

## firefly

 *Necoro_dM wrote:*   

> Nun ja - backend und GUI sind schon von einander gekapselt (und es ist sichergestellt, dass gui nur backend aufruft und nicht andersrum). Die Datei "gui_helper.py" ist aber Bestandteil des GUIs (wie der Name vermuten lässt) - und wäre daher auch bei einer Trennung in zwei verschiedene Pakete immer noch im GUI-Teil. Sicher bestände die Möglichkeit, dass der Qt-Part sich das selber schreibt, was aber aufgrund dessen was die Klassen machen nicht so sinnvoll ist. 
> 
> Nur zur Info, was in dieser Datei vorhanden ist - vllt kann man das denn besser verstehen, warum das ein GUI und kein Backend-Part ist:
> 
> - Config: eine Klasse zur Verwaltung der Konfiguration: da diese Config dem Backend ziemlich egal ist, fällt es nach meiner Meinung zu dem GUI Part (da es teilweise auch anzeige oder so steuert)
> ...

 

du könntest auch eine 3 schicht architektur machen, sprich ein backend, welches die grundlegenden funktionen anbietet, eine sog. "mittleware", welche die gesamte logic beinhaltet (z.b. EmergeQueue, Config, Database) und die (G)UI.

Achja die QT-Gui kann doch ruhig in selben projekt bleiben, die Backend-Frontend oder Backend-Middleware-Frontend architekturen erleichtern nur halt einiges und es verhindert zum teilen auch code-duplication, vorrausgesetzt man möchte mehrere Frontends anbieten.

Momentan hättest du code-duplication in gui_helper.py, wenn auch ne QT/ncurses/consolen UI vorhanden wäre.

----------

## Necoro

 *firefly wrote:*   

> du könntest auch eine 3 schicht architektur machen, sprich ein backend, welches die grundlegenden funktionen anbietet, eine sog. "mittleware", welche die gesamte logic beinhaltet (z.b. EmergeQueue, Config, Database) und die (G)UI.

 

Aber diese 3-Teilung gibt es doch schon  :Smile:  - gui_helper.py ist genau diese Middleware. Vllt habe ich das etwas doof ausgedrückt.  :Smile:  - Das einzige Problem, was sie noch hat, ist, dass sie zu GTK-Speziell ist. Aber das lässt sich wie gesagt leicht mit Wrappern ändern (die Wrapper hätten auch noch den Vorteil. dass sich einige gtk-aufrufe komisch verhalten, bzw nicht intuitiv sind und man das ja denn kaschieren kann  :Wink: ).

 *Quote:*   

> Momentan hättest du code-duplication in gui_helper.py, wenn auch ne QT/ncurses/consolen UI vorhanden wäre.

  Nach meiner jetzigen Vorstellung müsste man nur für jedes neue Frontend drei neue Wrapper schreiben (ein für ein Tree-Widget, ein für ein Tree-Iterator und einen für ein Konsolen-Widget) - also rel geringer Overhead.

----------

## firefly

dann habe ich dich etwas missverstanden  :Wink: .

----------

## Necoro

Soo ... zur besseren Vorstellung habe ich das gleich mal implementiert  :Smile:  - dabei habe ich (um das besser abzugrenzen) das gtk-Frontend in ein extra paket geschoben (es liegt jetzt in gui/gtk anstatt wie bisher direkt in gui).

Die abstrakten Wrapper sind in geneticone/gui/wrapper.py - die vom Gtk-Frontend implementierten residieren in geneticone/gui/gtk/wrapper.py. Und gui_helper.py benutzt nun nur noch die die Wrapper anstatt die konkreten gtk-Klassen. Damit ist es also auch möglich, dass es das Qt-Frontend ansteuern kann. Ein kleiner Punkt bleibt aber trotzdem noch: und zwar bestimmt gui_helper immer noch einen kleinen Teil Layout (eigentlich nur das konkrete Layout von der EmergeQueue) - das müsste man noch abändern - mache es aber in Abstimmung mit Klaus Meier, sollte er sich an das Qt-Frontend setzen wollen  :Smile: 

Ach btw: gibt nur noch 2 Wrapper: Tree und Console. Iterator machte keinen Sinn und habe es deswegen wieder fallenlassen  :Wink: 

(das update gibt es wie immer im svn)

----------

## Necoro

So dele ... "--newuse" sollte auch funktionieren ... ausgenommen sind geslottete pakete - aber mit denen habe ich allg noch ein kleines problem  :Wink: 

Wenn das soweit funktioniert würde ich das ganze denn in der nächsten Zeit (Mitte / Ende der Woche) in b.g.o eintragen um es in den offiziellen Portage-Tree zu übernehmen  :Smile:  Dort denn unter dem Namen Genetic/One ... ändern kann man den später immer noch  :Smile: 

----------

## Necoro

Auf den netten Hinweis von Klaus Meier hin, habe ich beschlossen, das GTK-GUI unter der Verwendung von Glade neuzubauen. Das beinhaltet nur das GUI an sich  :Smile:  - Logik muss nicht neu gebaut werden (zu min nur ein geringer Teil). Zum einen erhoffen wir uns davon ein schöneres GUI, als auch einen besser wartbaren Code (das GUI-Design ist denn in eine XML ausgelagert). Einen kleinen Haken hat das natürlich: es wird ein klein wenig langsamer  :Wink:  (sollte man aber eigentlich nicht merken)

----------

## Necoro

 *Necoro wrote:*   

> Wenn das soweit funktioniert würde ich das ganze denn in der nächsten Zeit (Mitte / Ende der Woche) in b.g.o eintragen um es in den offiziellen Portage-Tree zu übernehmen  Dort denn unter dem Namen Genetic/One ... ändern kann man den später immer noch 

 

Naja ... das braucht denn doch noch ein bisschen  :Smile: 

Aaaaaaber : ich habe den rebuilt mit glade fertig  :Smile:  - wer möchte, kann sich das mal antun  :Smile:  (ist die aktuelle Version im svn) - aber: bitte vorher layman syncen, da sich der svn-ebuild verändert hat

Folgende Veränderungen brachte glade mit sich:

- knapp 300 Zeilen weniger in windows.py (dafür knapp 1000 Zeilen mehr in der .glade  :Wink: )

- etwas langsamerer Start (0,05 sek langsamer)

- schönere (?) Oberfläche (vor allem in Preferences)

- PackageWindow (das Paket-Info-Fenster) wurde durch ein weiteres Tab unten ersetzt

- oneshot wurde erstmal wieder deaktiviert

- wahrscheinlich auch ein paar neue Käferchen  :Cool:  - wer einen findet, bitte zum örtlichen Greenpeace-Mitarbeiter oder mir melden  :Razz: 

In diesem Sinne - Nec

P.S.: Sorry, wenn das jetzt etwas länger dauerte - aber RL meldet immer mehr Bedarf an ... (und ich hatte auch zwischenzeitlich die Lust an Genetic/One verloren  :Wink: )

----------

## Necoro

So ... oneshot funktioniert auch wieder ... auch einige andere dinge, die ich übersehen habe  :Wink: 

da ich jetzt denke, dass ein gewisser Status damit erreicht ist, hab ich das ganze Ding denn 0.5.0 getauft und in ein Release gegossen  :Smile: 

/edit: ach - beinahe vergessen: Ich habe auch den Wrapper mächtiger gemacht und damit die gui_helper.py (hoffentlich) endgültig komplett Frontend-unabhängig gemacht  :Smile:  (sprich: sie mischt sich auch nicht mehr ins Design ein ;P)

----------

## Klaus Meier

Na prima, daß ich noch so lange gewartet habe. Mit nem Vesatreiber macht das keinen Spaß. Aber ich hab jetzt was passendes gefunden. Gegen Ende der Woche geht es los mit der KDE-Oberfläche.

----------

## Necoro

Hehe  :Smile:  ... sauber  :Smile:  ... ich muss auch inzwischen feststellen, dass GTK relativ langsam ist ... hoffen wir mal, dass das mit Qt schneller ist - denn würde ich sogar umsteigen ^^ 

Aber bitte nicht KDE-spezifisch bauen (und zB KDE-Dialoge einbinden), sondern halt "nur" Qt  :Cool: 

Ansonsten:

Ich habe vorhin mal einen config-parser from scratch geschrieben, der diesen in Python eingebauten ablöst. Denn der in Python mixt sich jedesmal die Config-Datei neu zusammen - und löscht Kommentare... -.- Deshalb also was neues (funktioniert sogar  :Wink: ). Natürlich wurde auch die Config-Datei jetzt mit Kommentaren versehen, damit man sie halt auch per Hand editieren kann  :Smile: 

Gruß

Nec

----------

## Necoro

So ... da ich jetzt so langsam doch denke, dass es reif für Portage ist, möchte ich noch einmal die Namensdiskussion anstoßen ... ersteinmal nur Vorschläge sammeln (sagen wir bis Samstag) ... denn bau ich einen Abstimmungsthread (ich bitte die Mods mir einen Hinweis zu geben, wenn dies nicht erwünscht ist  :Wink: ) - und denn sehen wir weiter  :Smile:  --- Fernziel: Ende nächster Woche g.b.o-Eintrag (Zeitpunkt ist aber kein Muss)

Ich bitte daher auch um Hinweise zu Fehlern, Designverbesserungen etc.  :Smile:  (evtl auch hier noch einmal Wiederholen auch wenn sie schon genannt wurden, weil ich nicht weiß, was noch aktuell ist).

In diesem Sinne

Necoro

Die bisherige Liste - mit Kommentaren im Stil (pro;contra)

 *Quote:*   

> - gmerge --- (klingt gut, gut zu merken; das "g" stört)
> 
> - djemerge --- (klingt wie "gmerge";die schreibweise ist schlecht)
> 
> - emergicon --- (klingt gut; zu lang)
> ...

 

----------

## giga89

Wie wärs mit "face" oder "faze" als "Gesicht" für Portage?

Da lässt sich natürlich auch noch was vorne- oder hintendran setzen.   :Wink: 

Interface ist aber langweilig meiner Meinung nach.

----------

## Polynomial-C

Hi,

hier mal ein paar spontane (teilweise relativ sinnfreie) Einfälle von mir:

portalportmasterE-GUIePYlogpoPYrus

So nun könnt ihr abstimmen  :Wink: 

Grüße

Poly-C

----------

## franzf

 *Necoro wrote:*   

> - portato --- (strange(!); strange(!))

 

 :Very Happy:  ist auch recht strange im Zusammenhang...

http://de.wikipedia.org/wiki/Portato

Oder wie wärs mit nem portaledge

(oder zweistöckig)

 :Very Happy: 

Ansonsten:

- mergo

- mergician

- genmerge

- gmt (kurz: gentoo merging tool -- eix wollen die Leute ja auch  :Wink: )

- snoopy (hätte zumindest das "py" wegen Python drin  :Wink: )

- (vieles mehr, will hier aber net des spammen anfangen, weil das meiste eh nur krampf ist... krankes Hirn  :Wink: )

Grüße

Franz

----------

## franzf

Spontan ist mir jetzt auch noch gems eingefallen:

graphical emerge systool

Die Gemse ist ja ein recht flottes, bewegliches (flexibles) Tier.

Außerdem ist es nicht schlecht zu merken.

Wegen merken/Länge:

Die meisten verwenden doch eh die Bash, welche eine Autovervollständigung mitbringt. Das entschärft die Prooblematik, wichtig sind dann eigentlich nur die ersten 3 Buchstaben, welche einprägsam sein sollten, die gem[...] gehören da sicherlich dazu  :Wink: 

Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

> 
> 
> Oder wie wärs mit nem portaledge
> 
> (oder zweistöckig)
> ...

 

OMG ...   :Shocked:  ... da wird mir ja schon anders, nur beim Bilder betrachten ^^ ... aber man muss aufpassen, dass der Name nicht impliziert, dass das Programm ab und zu mal hängt  :Razz: 

 *franzf wrote:*   

>  *Necoro wrote:*   - portato --- (strange(!); strange(!)) 
> 
>  ist auch recht strange im Zusammenhang...
> 
> http://de.wikipedia.org/wiki/Portato

 

ööh ... das kannte ich nicht  :Wink:  - hatte eher an die "Potato" gedacht  :Smile: 

Ansonsten danke für die Vorschläge  :Smile:  ... morgen abend oder am So bau ich denn mal was für die Abstimmung  :Smile:  ...

----------

## Necoro

also: nur als kleiner Hinweis: hab das jetzt umbenannt: daher: "emerge -C geneticone" und "emerge portato"  :Smile: 

leider sind die bei sf.net verdammt langsam und kriegen das Projekt net umbenannt -.- ... außerdem: mit portage-2.1.2_rc2-r1 scheint es ein Problem zu geben ... kann es aber leider noch net lösen, da ich leider mein Laptop-Netzteil auf Arbeit hab liegen lassen  :Sad:  - musste jetzt extra meinen alten Rechner mit ArchLinux reaktivieren -.- ... und: Ich hasse Binär-Distros  :Evil or Very Mad: 

----------

## Necoro

Also Jungs und Mädels: Sf.net hat es hinbekommen - d.h: ändert in eurer layman.cfg das "geneticone" ein ein "portato"  :Smile:  - ich werde denn mal auch jetzt wieder anfangen, daran weiterzuarbeiten  :Wink: . Außerdem werde ich diese Woche noch (denn nun endlich) versuchen, das ganze ins Portage zu bekommen ...

@Klaus Meier: was sagen deine Qt-Rumspielereien?

----------

## Necoro

Ich schon wieder ... also: ich habe gestern versucht das portato ebuild zu filen ... leider wurde es mit dem Hinweis

 *Quote:*   

> Let us know when this works w/ uptodate portage versions and reopen the bug
> 
> then. Thanks.

  abgelehnt -.- ... 

ergo: ich muss es erst mit portage-2.1.2 zum laufen bekommen. Dies ist leider ein relativ großer Haufen Arbeit, da eine Menge Internals (zu min scheint es so) geändert wurden ... (natürlich undokumentiert -.-) ... Kurz und gut: diese Woche wird das nix mehr mit dem In-Portage-Tree-kommen  :Sad: 

btw: Klaus Meier hat mir mitgeteilt, dass er kein Qt-Frontend entwickeln wird (Grund: allg Unzufriedenheit mit KDE). Stelle ist also wieder offen ;P

----------

## franzf

 *Necoro wrote:*   

> btw: Klaus Meier hat mir mitgeteilt, dass er kein Qt-Frontend entwickeln wird (Grund: allg Unzufriedenheit mit KDE). Stelle ist also wieder offen ;P

 

Ich möchte hier einfach mal Eric3 in den Raum werfen, in der Hoffnung jemanden zu treffen  :Wink: 

Das ist eine in PyQt3 geschriebene Python-Entwicklungsumgebung. Damit spart man sich das ganze kde3-Gekrempel (wenn ma es nicht mag), man benötigt nur Qt3+PyQt3...

Grüße

Franz

----------

## Necoro

hehe  :Wink: 

Also ich hab jetzt upstream einen workaround, so dass es auch mit 2.1.2 funktioniert. Dies ist aber nicht die endgültige Lösung. Beim Gespräch in #gentoo-portage habe ich mitbekommen, dass gentoolkit langsam aber sicher am absterben ist - daher werde ich wohl oder übel auf diese Abhängigkeit verzichten müssen  :Sad:  ... Deswegen muss ich den Part, den diese lib bis jetzt übernimmt, in Zukunft wohl selber implementieren  :Confused:  - dabei werde ich auch versuchen, die Neuerungen sauber einzuarbeiten ...

Eine Bitte - guckt mal ob dieser workaround irgendwelche Probleme verursacht (sowohl mit 2.1.2 als auch 2.1.1)

----------

## Necoro

Kurzer status-report:

- ebuild liegt nun schon seit 4 Tagen in b.g.o ... 

- aus dem svn-build wurde die gentoolkit-abhängigkeit entfernt

- die konsole zeigt nun den üblichen header an, der von emerge gesetzt wird  :Smile:  (was sich vorteilhaft auswirkt, wenn man mehr als ein paket emerget)

außerdem ist mir aufgefallen, dass die syncs seit der umbenennung von 15-20 auf ~4 gefallen ist ... wird zeit, dass das in portage landet  :Wink:  *wart*

----------

## franzf

 *Necoro wrote:*   

> außerdem ist mir aufgefallen, dass die syncs seit der umbenennung von 15-20 auf ~4 gefallen ist ... wird zeit, dass das in portage landet  *wart*

 

Ui, gut dass du das schreibst  :Wink: 

Hab jetzt mal nachgesehen, weil ich eigentlich täglich mein layman (blind) gesynct hab, und siehe da, layman meckert dass er nicht syncen kann  :Very Happy: 

War wohl etwas schnell mit dem "in der layman-config die geneticone durch portato ersetzen", und hab vergessen das directory umzubenennen. Habs dann trotzdem nochmal ganz entfernt und neu eingerichtet.

Ich hoffe deine syncraten normalisieren sich jetzt wieder  :Wink: 

Grüße

Franz

----------

## Necoro

So ... habe jetzt update_world kompatibel mit slots gemacht ... und auch das "--newuse" funktioniert jetzt besser (es reagiert jetzt genau wie das emerge pendant auch auf hinzugefügte flags)

Dabei musste ich aber feststellen, dass ich so viele portage-2.1.2-Features genutzt habe, dass das svn-ebuild jetzt 2.1.2 fest benötigt (ich werde es auch nicht einbauen, dass es mit 2.1.1 läuft) -- wer sich kein unstable portage holen möchte, muss denn leider die 0.5.1-version von portato nehmen

----------

## Necoro

Kurzer Report ... lebe noch  :Wink: 

leider gibt es keinen Maintainer für das ebuild ... metalgod hatte sich gemeldet - denn aber ohne Kommentar zurückgezogen ... 

neues Release kommt demnächst ... arbeite im Moment (ansatzweise) an einer ncurses-Oberfläche dafür  :Wink: 

----------

## Necoro

Neues Release: 0.5.2

- keine Abhängigkeit von gentoolkit mehr

- Konsolen-Status hinzugefügt

- Slots funktionieren

- Verbesserungen am "--newuse" und "--update world" allgemein

- einige Bilder in den Menüs  :Smile: 

- Möglichkeit hinzugefügt, einen Emerge-Prozess abbrechen zu können

Dieses Release funktioniert nur mit portage-2.1.2

Was den Curses versuch angeht:

Da ich urwid nicht mag, bin ich gerade dabei einen Wrapper für CDK zu schreiben  :Smile:  - kann also noch ein wenig dauern

----------

## Necoro

Soo ... der CDK-Wrapper nimmt langsam Formen an... ich durfte bereits das Projekt pyCDK übernehmen - sprich: der CDK-Wrapper wird nicht Teil von Portato sein, sondern als extra Projekt laufen. Denke aber, dass der in der nächsten Zukunft (ein Monat vielleicht noch) fertig ist - und daraus denn eine Basic-Oberfläche zu bauen, sollte denn auch nicht das Problem darstellen ...

Und danach habe ich mit dem Einbau von Paludis-Support ja auch wieder ein Ziel vor Augen ^^ (auch wenn das heißt, dass ich auch dort wieder einen Wrapper schreiben muss -.-)

----------

## Necoro

CDK suckt  :Razz:  ... aber wir bekommen das noch hin ... irgendwann  :Wink: 

Hab stattdessen mal wieder an der GTK-Variante gearbeitet und zum einen die Segfaults tot gemacht (hoff ich), die unerklärlicher Weise manchmal bei den Rechtsklickmenüs auftraten (auch wenn die Lösung unter "hässlicher Workaround" fällt).

Und zum anderen hab ich "Use-Tips" hinzugefügt. Das sind Tooltips, die für ein Paket in der Queue die Use-Flags anzeigen ... so sieht man auf Anhieb, ob man noch was ändern muss ...

Das sieht denn so aus: http://www.loz-treffen.de/stuff/shots/usetip.png (der Mauszeiger ist mir beim Screenshot leider abhanden gekommen  :Wink: )

Und wen das stört, der kann sie sich in den Optionen auch ausschalten   :Twisted Evil: 

----------

## Necoro

Und heute gleich noch mal was (ich sollte zwar eigentlich für Klausuren lernen ...  :Wink:  - aber egal)

Habe heute ein nettes Feature eingebaut: Anzeige des ebuilds ... so fern nicht spektakulär - aber es gibt das ganze gleich mit Syntaxhighlighting

Dieses Feature lässt sich über das neue Useflag "syntax" einschalten. Ist es nicht gesetzt, gibt es das ebuild nur simpel monochrom  :Wink: 

Wichtig: Da ich zwei der ebuilds, die für "syntax" benötige selber geschrieben habe, kann es sein, dass dort Abhängigkeiten nicht ganz hinhauen - dies bitte melden  :Smile:  (das heißt auch für euch: Overlay syncen  :Wink: )

----------

## franzf

 *Necoro wrote:*   

> Und heute gleich noch mal was (ich sollte zwar eigentlich für Klausuren lernen ...  - aber egal)
> 
> Habe heute ein nettes Feature eingebaut: Anzeige des ebuilds ... so fern nicht spektakulär - aber es gibt das ganze gleich mit Syntaxhighlighting

 

Wird aus der simplen Anzeige auch gleich ein Ebuild-editor?

Mit autoselect/inheritance von eclasses und automatischem ebuild xyz-123.ebuild digest nach dem Speichern?

Das wäre cool  :Wink: 

Ansonsten finde ich es echt klasse mit was für einer Hingabe du an dem Tool arbeitest.

Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

> Wird aus der simplen Anzeige auch gleich ein Ebuild-editor?
> 
> Mit autoselect/inheritance von eclasses und automatischem ebuild xyz-123.ebuild digest nach dem Speichern?
> 
> Das wäre cool 
> ...

 

*lach* danke  :Wink: 

der ebuild-editor wäre denn aber eher ein anderes projekt  :Wink:  (also dass man ändern kann, könnte ich einbauen (und das verwendete GtkSourceView-Widget stellt ja sehr viel zur Verfügung) - aber so abgefahrenere Sachen erstmal nicht ^^)

ach: Anmerkung: das Syntaxhighlighting war keine große Sache (das Widget gibts fertig - und das Syntaxfile bei b.g.o) ^^ - das anstrengende war, es aus dem gnome-python-desktop-ebuild zu extrahieren, welches das halbe gnome als dependency hat

----------

## Necoro

So ... ich habe mal hinter den Kulissen gewerkelt und Portato fit für den Einsatz alternativer Backends gemacht.

Deshalb besteht nun die erhöhte Chance, dass irgendwo irgendwelche Fehler auftreten  :Smile:  - ich habe zwar pychecker laufen lassen, aber wenn er nichts findet, heißt es ja nicht, dass dort nichts ist  :Wink: 

----------

## Necoro

Neues Release: 0.6.0

- Support für von Portage veschiedene Backends

- Endlich ein Image anstatt des "*" bei installierten Paketen

- Ebuild-Windows (auf Wunsch mit Syntaxhighlighting)

- Usetips

- Kopieren aus der Konsole heraus

- Tasten-Shortcuts hinzugefügt

(also alles, was in den oberen Posts verteilt stand  :Wink: )

----------

## Necoro

Soo ... ich hab mich jetzt mal an was ganz besonderes gewagt: Plugins  :Smile: 

Es ist nun möglich Plugins für Portato zu schreiben und diese vor oder nach einem "Hook" (zB "ebuild_open", "after_emerge", "cat_select") auszuführen. (Es ist auch möglich, die normal vorhandene Funktion zu überschreiben - aber das sollte man selten brauchen).

Auf die Idee kam ich als einer im engl Forum auf mich zu kam und fragte, ob ich etc-proposals integrieren kann. Wo ich da kurz überlegt habe, stellte ich fest, dass das dazu führt, wieder per Useflag in einer config-datei rumzueditieren und das Hauptprogramm mit unschönen "if"'s zu übersäen. Dies mag alles noch gehen bei zwei Sachen (ebuild-highlighting, etc-proposals) - aber danach schon nicht mehr.

Also... das Ebuild-Syntax-Highlighting liegt nun als Plugin vor  :Smile:  - und das etc-proposals-Dings wird folgen, so bald ich es fertig hab.

Als Nutzer sollte man diese Umstellung aber net mitbekommen  :Wink: 

----------

## Necoro

Sooo ... neues Useflag: "etcproposals", welches Support für etc-proposals implementiert  :Smile: 

----------

## Necoro

*gähn*

Neue Version (0.6.1) ... seit der letzten SVN-Version hat sich nur geändert, dass Plugins nun einen Menü-Eintrag bekommen können. - Ansonsten ist diese Version nur dazu da, um ein funktionierendes ebuild für b.g.o zu liefern.

Auflistung daher eigentlich nur der Vollständigkeit halber  :Smile: 

(btw: gibt es nicht einen lieben Dev der Portato als neues Blatt an den Portage-Baum nageln möchte? *liebguck*  :Very Happy: )

----------

## Necoro

 *Thargor wrote:*   

> Ne qt Oberfläche wär schon ganz was feines.  Wäre echt super, wenn du sowas machen könntest

 

Soo ...  :Smile:  nur knappe 6 Monate später steht sie in den Startlöchern  :Smile:  - Ab sofort gibt es auch ein Qt-Frontend - einrichtbar durch das qt-UseFlag. Anschließend muss portato mit portato qt gestartet werden.

Aber achtung: Im Moment kann dieses Frontend noch nicht mehr als die Daten über ein Paket anzeigen - also noch nix mit emergen, unmergen und den ganzen Spielchen ... kommt aber in den nächsten Tagen  :Smile: 

Sollte das Frontend dann komplett funktionieren wird es auch ein gtk-Flag geben, so dass man den gtk-Part komplett abschalten kann, wenn man will

----------

## franzf

Hi,

Boah, wegen den ganzen doofen (internationalen) Bugreports + feature requests usw hab ich grad angefangen das hier auf englisch zu schreiben...

Naja...

ALSO:

Super dass du eine Qt-Oberfläche anfängst. Hätte ich gewusst dass du jetzt doch gleich mit qt4 anfängst, und nicht, wie angekündigt, mit qt3, hätte ich mich damals in Python eingearbeitet  :Smile:  Naja, mal schaun, wenn ich Zeit hab mach ich gerne mit  :Wink: 

Und nun ein paar Anregungen, mal schaun wie sie ankommen  :Wink: 

Um sich dem Portage-Standard anzupassen (auch wegen Aufnahme in den offiziellen Tree) sollte das USE-Flag statt qt bitte qt4 heißen.

Perfekt wäre ein Systray-Icon, denn es passiert immer wieder mal, dass man auf diesen doofen Knopf mit dem "X" klickt...

Falls das zu viel ist, einfach bei nicht leerer Merge-Queue oder aktivem emerge-Vorgang nachfragen, ob man wirklich schließen will.

Besteht die Möglichkeit eines Queue-Managers? Ich weiß, portato soll _nur_ ein portage-Frontend sein, aber zusätzliche Funktionalität würde auch nicht schaden  :Wink: 

Es wäre doch möglich, bei Fehlern, Abbrüchen usw. die aktuelle Queue (bzw. die Pakete) in ein textfile zu schreiben, welche man über einen Dialog einzeln einsehen und ggf. restarten oder löschen kann.

Fänd ich sehr praktisch  :Wink: 

Es wäre auch schön, wenn immer nur das gerade (erfolgreich) installierte Paket aus der Queue entfernt würde, und nicht sofort mit klick auf Button die ganze Liste  :Wink: 

So, das wärs für den Augenblick  :Smile: 

Noch einen schönen Tag

Franz (mit der roten Nase von der vielen Sonne)

----------

## Necoro

 *franzf wrote:*   

> Super dass du eine Qt-Oberfläche anfängst. Hätte ich gewusst dass du jetzt doch gleich mit qt4 anfängst, und nicht, wie angekündigt, mit qt3, hätte ich mich damals in Python eingearbeitet  Naja, mal schaun, wenn ich Zeit hab mach ich gerne mit 

 

Hab ich mal gesagt Qt3 ..? -- *wunder* Kann sein, weil PyQt4 damals der Meinung war, das System zerschießen zu müssen ^^. Aber als ich am Mi der Meinung war, was neues zu machen, hab ich mich dann für das aktuellste entschieden  :Smile: . Würde mich freuen, wenn du irgendwann mal Zeit finden würdest  :Wink: 

 *Quote:*   

> Und nun ein paar Anregungen, mal schaun wie sie ankommen 

 

Anregungen sind immer toll  :Wink: 

Dann mal zu den Anregungen:

- qt-Useflag umbenennen: Nix leichter als das  :Smile: 

- Systray-Icon: Ist afaik nicht portabel zwischen verschiedensten DEs - also nein. Der Warnungs-Dialog ist aber machbar

- QueueManager: hmm ... netter Vorschlag .. mal genauer überdenken

- immer nur die aktuellen Pakete entfernen geht schlicht und ergreifend nicht  :Sad:  . weil ich nicht weiß, welches paket emerge gerade installiert hat (es sei denn, ich parse den Konsolen-Titel, was ich ein wenig .. gewagt find)

----------

## think4urs11

 *Necoro wrote:*   

> - Systray-Icon: Ist afaik nicht portabel zwischen verschiedensten DEs - also nein.

 

Sollte eigentlich schon, es gibt sowas wie die 'freedesktop.org System Tray Specification' an die sich mindestens die großen DE/WM halten

----------

## Ampheus

Das zuletzt installierte Paket herauszufinden dürfte doch eigentlich nicht schwer sein, oder?

Es gibt ja die logs von Portage und dazu kannst dir ja auch mal ansehn, wie genlop das macht. Das kann nämlich meines Wissens so etwas anzeigen. Oder du holst dir die Ausgabe von 

```
emerge --resume -pv
```

----------

## franzf

Da ist mir noch was aufgefallen:

Wenn ich per portato ein Paket in die Merge-Queue aufnehme stehen ruckzuck gleich alle Abhängigkeiten mit drinnen.

Wenn ich es dann merge, berechnet portage alle Abhängigkeiten nochmal neu, was leider deutlich länger dauert...

Gäbe es da eine andere (bessere) Lösung?

----------

## Necoro

@think4urs11: hmm ... ok ... ich werd mal schauen  :Smile:  (wenn ich Zeit hab -- und vor allem ein Icon ... Systrays ohne Icons sind doof  :Wink: ) ... und: warum um alles in der Welt steht da "Ninja" bei dir als Titel ...   :Cool: 

@Ampheus: guter Hinweis mit den logs. Ausgabe von "emerge -pv --resume" zu parsen macht in meinen Augen keinen Sinn  :Wink:  (und stdout parsen ist immer böse und gilt es zu vermeiden)

@franzf: Das ist mit Absicht so: Ich habe die Abhängigkeitsberechnung nur nachimplementiert - und kann auch sagen, dass sie nicht in 100% der Fälle zum gleichen Ergebnis wie Portage kommt (wobei ich ehrlich sagen muss, dass ich in all diesen Fällen eher ein Fehler in Portage vermute ...). Daher lass ich Portage selber bestimmen, was es installieren will ... will ja nicht Schuld sein, wenn auf einmal irgendwas kaputt ist  :Wink: 

Den QueueManager, werde ich wohl insofern implementieren, als dass beim Beenden des Programms einfach die aktuelle MergeQueue gespeichert wird. Und beim Neustart wieder hergestellt... Den "ManagementPart" mit hinzufügen und so gibts ja schon  :Wink:  - oder hab ich dich da falsch verstanden?

----------

## Necoro

Kurzer Statusreport in Sachen Qt:

- die Suche funktioniert

- man kann Pakete in die EmergeQueue (nicht per unmerge) hinzufügen und von dort auch wieder löschen

Auf jeden Fall wird das wohl eine Maintaining-Hölle  :Smile:  ... sehr viel copy'n'paste aus dem Gtk-Part ... ^^

Unverbindliches Release-Date einer Qt-Basis-Version: Nächstes Wochenende  :Smile: 

Außerdem: Qt4 hat sich mit seiner Implementation von Listen- und Treewidgets mal so tot abstrahiert - da bekommt man ja Ausschlag von  :Evil or Very Mad: 

----------

## Necoro

Soo ... beim Kopieren von Funktionen vom GTK zum Qt-Frontend stutzt man ab und zu und denkt "Was zur Hölle hab ich denn hier gemacht?"... In 75% der Fälle, findet man es aber raus und ist erfreut über seine Gedanken damals  :Wink: 

In den anderen 25% findet man aber in der Tat einen Fehler. So geschehen beim Anzeigen, ob ein Pasket masked ist (und auch beim Ändern dieses Zustandes) ... den Fehler zu beheben war umständlicher als ich dachte ... und auch wenn ich weiß, dass ich in einer Woche schon nicht mehr verstehe, wie das genau funktioniert (eigentlich versteh ich es jetzt schon nicht komplett  :Wink: ) - es funktioniert  :Smile: 

Außerdem kann das Qt-Frontend jetzt: Emergen, Unmerge, UpdateWorld, Flags setzen  :Smile:  ... Rest kommt in naher Zukunft  :Smile: 

----------

## Necoro

Preferences und noch so einige andere Gimmicks sind fertig für Qt...

Dabei noch eine Frage an alle KDE-Benutzer: Könnte mal bitte jmd ein Screenshot von dem Preferences-Fenster machen? - Bei mir werden die Titel von den GroupBoxes abgeschnitten, und ich würde gerne wissen, ob das an mir oder an Qt liegt ...

----------

## franzf

 *Necoro wrote:*   

> Dabei noch eine Frage an alle KDE-Benutzer: Könnte mal bitte jmd ein Screenshot von dem Preferences-Fenster machen? - Bei mir werden die Titel von den GroupBoxes abgeschnitten, und ich würde gerne wissen, ob das an mir oder an Qt liegt ...

 

Da, schau  :Smile: 

Bei mir scheint es ganz ordenrlich auszusehen.

----------

## Necoro

 *franzf wrote:*   

> Da, schau 
> 
> Bei mir scheint es ganz ordenrlich auszusehen.

 

Hmmm ... jo ... ok  :Smile:  danke - denn ignoriere ich das ab jetzt ^^ ... 

Noch was aus Entwickler-Sicht: es ist mir inzwischen klar, warum viele Programmiere GTK benutzen und nicht Qt: GTK ist einfacher  :Smile:  (ausgenommen sind die Entwickler für KDE, da die kdelibs ja viele Sachen vereinfachen/schon implementieren) --- (und es ist mir einfach nicht klar, warum Qt kein Markup bei CheckBoxen kennt  :Sad: )

----------

## Necoro

Nachtrag für heute: Ebuild-Fenster inkl Syntax-Highlighting gibt es jetzt auch für Qt (syntax-Flag wird hier _nicht_ benötigt)

----------

## franzf

Weil du meckerst, Qt sei sooo schwer, abstrahiert zu stark (QTreeWidget ist doch gar nimmer abstrakt  :Wink:  weil du das angeführt hattest), hier mal der aktuelle Status:

Anzahl Zeilen der GUIs:

GTK: 1793

Qt: 1297

Wenn du die Klausel am Anfang (12 Zeilen pro Datei) wegnimmst:

GTK: 1733

Gt: 1213

Ergo kommst du mit Qt schneller ans Ziel  :Wink:  (gute 30%) Und das obwohl du dank der Abstraktion der Qt-Klassen noch so viel konkretisieren musst  :Very Happy: 

Grüße

Franz

----------

## b3cks

 *franzf wrote:*   

> Ergo kommst du mit Qt schneller ans Ziel  (gute 30%) Und das obwohl du dank der Abstraktion der Qt-Klassen noch so viel konkretisieren musst 

 

Naja, die Aussage ist recht relativ. Wenn der Befehlssatz recht einfach gehalten ist, dürfe man ein paar hundert Zeilen schneller schreiben, als weniger Zeilen bei höherer Komplexität der Sprache.

Muss hier jetzt nicht stimmen, meine das nur allgemein.  :Wink: 

----------

## Necoro

 *franzf wrote:*   

> Ergo kommst du mit Qt schneller ans Ziel  (gute 30%) Und das obwohl du dank der Abstraktion der Qt-Klassen noch so viel konkretisieren musst 

 

Ähm puh ^^ ... das Qt-Frontend hat ja auch bei weitem noch nicht den Status, den das Gtk-Frontend hat ^^

Und auch wenn es kürzer ist (was ich auf das ganze gesehen nicht bestreiten will) - wie b3cks schon sagt: kürzer != einfacher  :Wink: 

----------

## Necoro

Soo ... Qt ist fertig als Alternative zu Gtk  :Smile: 

Ab sofort gibt es ein gtk-UseFlag. Nur wenn man dies gesetzt hat, wird auch die Gtk-Oberfläche installiert. Sollten beide gesetzt sein, wird aber weiterhin "gtk" als Standard angenommen - will man dann die Qt-Oberfläche benutzen, so ist anstatt "portato" "portato qt" als Aufruf zu wählen.

Da ich die Gtk-Oberfläche selber nutze - aber wohl nicht das Qt-Pendant, bitte ich hier verstärkt um Bug-Meldungen.

Das ganze gibt es wohl am Wochenende als Release, wenn ich noch so ein,zwei kleine Schönheitsfehler behoben hab, und auch das Plugin-System unter Qt läuft.

----------

## Necoro

Soo ... da ist es denn, das Baby:

Release 0.7.0 ist fertig. Qt-Frontend kann nun als gleichwertig mit dem Gtk-Ding betrachtet werden  :Smile:  --- mehr gibts dazu nicht zu sagen ... außer: Check it out!  :Cool: 

----------

## nikaya

Die User von Sabayon sind ziemlich interessiert an Portato:

http://www.sabayonlinux.org/forum/viewtopic.php?t=6564

----------

## Necoro

 *john.doe wrote:*   

> Die User von Sabayon sind ziemlich interessiert an Portato:
> 
> http://www.sabayonlinux.org/forum/viewtopic.php?t=6564

 

Ja --- bin auch schon überrascht ... in den letzten beiden Tagen zusammen fast 150 Checkouts ... (normal sind max 12 pro Tag ^^)

----------

## Necoro

So  :Smile:  Dank wolfden gibt es nun auch ein Icon für Portato. Daher hab ich dann auch .desktop-Dateien gebaut, so dass es in evtl system-menüs auftaucht. da portato als root laufen muss, wird je nach verwendetem frontend gksu oder kdesu mit installiert (und schon wieder ne abhängigkeit mehr drin  :Sad: )

Außerdem gibt es jetzt den Dialog, der einen darauf hinweist, wenn emerge noch am arbeiten ist bzw sich noch Einträge in der Emerge-Queue befinden.

Systray-Funktionalität gibt es demnächst  :Smile: 

----------

## misterjack

Hab es grad mal ausprobiert. Eins stört mich jedoch, man muss Root sein. Wenn man aber FEATURES="userpriv usersandbox" gesetzt hat und der Gruppe portage angehört, darf man ja auch als User emergen. Wäre es möglich, Portato dahingehend anzupassen?

----------

## Necoro

Hmm ... jopp ... kann man ja über ein Useflag lösen  :Smile:  *auf TODO Liste setz*

----------

## Necoro

 *misterjack wrote:*   

> Wäre es möglich, Portato dahingehend anzupassen?

 

So ... mit dem Useflag noroot sollte es jetzt möglich sein. Wäre nett, wenn du das mal ausprobierst und sagst ob es geht  :Smile: . Ich hoffe, alles funktioniert damit gut - Portato denkt jetzt nämlich einfach immer, es laufe als root.

Außerdem werden die System-Menu-Einträge bei dem UseFlag so angepasst, dass kein kdesu/gksu gestartet wird  :Smile:  (es ist damit natürlich auch aus den Dependencies raus).

----------

## misterjack

Wenn es sich emergen lassen würde: http://nopaste.info/2b6c2c7e47.html

PS: Hab sonst keine emerge-Probleme, hier ein emerge --info: http://rafb.net/p/4esLL887.html

----------

## Max Steel

Ähhh, Leute ich weiß das das nich so gut hier rein passt aber naja,

Könnt ihr mir sagen ob das stimmt?

und zwar das gtk etwas mit KDE zu tun hatt,

und gt etwas mit Gnome.

Wenn nicht berichtigt mich bitte.

----------

## Necoro

 *Max Steel wrote:*   

> Ähhh, Leute ich weiß das das nich so gut hier rein passt aber naja,
> 
> Könnt ihr mir sagen ob das stimmt?
> 
> und zwar das gtk etwas mit KDE zu tun hatt,
> ...

 

anders rum wird ein schuh draus  :Smile:  ... Gtk ist die Standardbibliothek (für Fenster und so) von Gnome, Xfce u.a. - und Qt die von KDE  :Smile: 

@misterjack: ich denke nicht, dass ich schuld bin  :Smile:  - subversion kann kein Verzeichnis anlegen... da würde ich den Fehler in deinem Rechtemanagement suchen

----------

## Max Steel

danke vielmals

Edith:

sieht garnicht schlecht aus.

Weiter so *11 THUMPS UP*

Übrigens bekomm ich jedesmal diese Meldung wenn ich ein Packet anschaue,

oder einzelne Versionen eines Packetes durchschaue:

```
egrep: /etc/portage/packages.mask: Datei und Verzeichnis nicht gefunden
```

Allerdings habe ich auch keine packages.mask

Außerdem dauerts ziemlich lange bis cih die erste Meldung (erscheinen des Fensters) bekomme.

geschätzte 45 Secs oder so.

Kann aber auch daran liegen das ich noch JuK und ein make vorgang (Kernelupdate) währendessen am laufen hab, beides auf der VMWare.

----------

## Necoro

 *Max Steel wrote:*   

> Übrigens bekomm ich jedesmal diese Meldung wenn ich ein Packet anschaue,
> 
> oder einzelne Versionen eines Packetes durchschaue:
> 
> ```
> ...

 

Öhm - ich habe scheinbar nicht daran gedacht, dass die Dateien in /etc/portage nicht vorhanden sein müssen ... das sollte ich noch ändern  :Smile:  - danke für den Hinweis

----------

## Max Steel

 *Necoro wrote:*   

> Öhm - ich habe scheinbar nicht daran gedacht, dass die Dateien in /etc/portage nicht vorhanden sein müssen ... das sollte ich noch ändern  - danke für den Hinweis

 

Aber immer doch.

----------

## Necoro

So - Fehler sollte gefixt sein ...

Außerdem wurde jetzt der lang ersehnte support für Systrays hinzugefügt  :Smile:  - Viel Spaß

----------

## misterjack

 *Necoro wrote:*   

> 
> 
> @misterjack: ich denke nicht, dass ich schuld bin  - subversion kann kein Verzeichnis anlegen... da würde ich den Fehler in deinem Rechtemanagement suchen

 

Jo, wenn ich FEATURES="userpriv usersandbox" rausnehme funktionierts. Und danke für die Mühe, jedoch hatte ich eine falsche Auffassung von userpriv. Hätte mich vorher informieren sollen, keine Ahnung wo ich das mal aufgeschnappt habe. Userpriv sorgt dafür, dass emerge die Berechtigungen auf portage:portage beim Installieren senkt. Usersandbox erlaubt, dass auch die Sandbox in Verbindung mit Userpriv funktioniert.

Sorry, dass ich dir Mehraufwand bereitet habe  :Wink: 

----------

## Max Steel

Moin Necoro,

Ich wollt jetz mal die portato-9999 installieren und bekam folgendes.

```
# emerge -av =app-portage/portato-9999

[ausgeschnittenesblabla]

>>> Emerging (1 of 1) app-portage/portato-9999 to /

 * checking ebuild checksums ;-) ...                                                                                    [ ok ]

 * checking auxfile checksums ;-) ...                                                                                   [ ok ]

 * checking miscfile checksums ;-) ...                                                                                  [ ok ]

>>> Unpacking source...

ACCESS DENIED  mkdir:     /vol1/portage/distfiles/svn-src

mkdir: kann Verzeichnis ▒/usr/portage/distfiles/svn-src▒ nicht anlegen: Keine Berechtigung

[ausgeschnittenesblabla]

!!! subversion.eclass: can't mkdir /usr/portage/distfiles/svn-src.

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/app-portage/portato-9999/temp/build.log'.

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------

LOG FILE = "/var/log/sandbox/sandbox-app-portage_-_portato-9999-28692.log"

mkdir:     /vol1/portage/distfiles/svn-src

--------------------------------------------------------------------------------

!!! This ebuild is from an overlay: '/usr/portage/local/layman/portato'

#
```

Ich mutmahse mal und sage Fehler im EBuild oder in der ./configure.

----------

## misterjack

FEATURES="userpriv usersandbox" rausnehmen, siehe bei mir  :Wink: 

----------

## Max Steel

Das Prob is bei mir ist, es ist schon FEATURES="" eingestellt und es klappt nicht.

Oder steht das woanders als in /etc/make.conf

Edith:

Also, ich hab jetz mal den Ordner ganz fies von Hand erstellt, jetz gehts.

Der brauchte den /usr/portage/distfiles/svn-scr

----------

## Necoro

Ja - Ordner von Hand erstellen hilft - k.A. was portage da manchmal hat

Ansonsten: Damit nicht alle mit dem instabilen SVN-ebuild (9999) leben müssen und trotzdem die letzten neuerungen bekommen:

Portato 0.7.2 ist da

Änderungen noch mal zusammengefasst:

- Icon und Menüeinträge hinzugefügt

- Systray eingebaut

- Warndialoge hinzugefügt, die aufpoppen, wenn noch etwas in der Queue sich befinden sollte

- "noroot"-Plugin, welches das emergen auch als normaler User erlaubt / erlauben sollte (ungetestet)

Wichtig: Wer von 0.7.0 upgradet oder eine SVN-Version hat, die älter ist als heute gegen 16 Uhr und das syntax-Plugin unter Gtk verwendet hat: Dieses ist ab sofort in einem extra Paket (portatosourceview), welches aber weiterhin über das UseFlag angezogen wird (also da keine Umstellung  :Smile: ). - Doch da dieses Paket Dateien überschreibt, von anderen Paketen, die das Flag vorher gebraucht hat, bitte "pygtksourceview" und "gtksourceview_gentoo" vor dem Update deinstallieren  :Smile: .

/edit: 0.7.1 wurde eliminiert - 0.7.2 ist jetzt der zweite Versuch  :Wink: 

----------

## Max Steel

portato rockt!!!

Ich bekomm halt noch sau viele ***DEBUG*** Meldungen ins KonsolenFenster.

---> Debugmeldungen <---

Aber davon mal abgesehen:

portato rockt!!!

----------

## Necoro

Hehe ... danke  :Wink: 

die Debug-Meldungen kannst du unter Preferences->Debug abschalten

----------

## Max Steel

ah ok, danke

----------

## Necoro

So ...

ein kleines (hauptsächlich) Bugfix-Release 0.7.3

Änderungen:

- Bugfixes

- man kann nun die Paketliste nun so sortieren, dass die installierten Pakete oben sind (in GTK: auf den Listen-Header drücken; in Qt: rechtsklick auf die Liste)

- schnelleres Terminal unter Qt (früher hat das Terminal teilweise 90% CPU verbraucht)

Known Issues:

Das Terminal unter Qt ist immer noch weit davon entfernt gut zu sein. Insbesondere, wenn man große Pakete emerget und sehr viel innerhalb kurzer Zeit auf die Konsole geschrieben wird, hängt sich Qt auf.

----------

## UTgamer

Nun da ich das heute mal entdeckt habe, und nach dem Lesen des ganzen Threads mich dazu entschlossen habe es mal auszuprobieren bin ich jetzt etwas irritiert.

Als Freund von Qt habe ich in meinen useflags kein gtk aktiviert, dafür aber qt gesetzt.

GTK-Anwendungen habe ich trotzdem, wie z.B. nedit oder Seamonkey/Firefox.

Ich habe Version 0.7.3 probiert.

```
emerge portato -p

These are the packages that would be merged, in order:

Calculating dependencies /

!!! All ebuilds that could satisfy ">=gnome-base/orbit-2.4" have been masked.

!!! One of the following masked packages is required to complete your request:

- gnome-base/orbit-2.14.2 (masked by: package.mask)

- gnome-base/orbit-2.14.0 (masked by: package.mask)

- gnome-base/orbit-2.14.7 (masked by: package.mask, ~amd64 keyword)

- gnome-base/orbit-2.14.4 (masked by: package.mask, ~amd64 keyword)

- gnome-base/orbit-2.12.5 (masked by: package.mask)

- gnome-base/orbit-2.12.2 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or

refer to the Gentoo Handbook.

(dependency required by "gnome-base/gconf-2.14.0"
```

Dank eines jahrelangen Blocks auf orbit, bleibe ich wunderbar von allen Gnomeanwendungen verschont, ist orbit erst einmal auf der Platte ist sämmtliches Desktopmanagement leider dahin. Die Abhängigkeit von Portato ist mir damit zur Zeit leider zu hoch, ich zieh kein ganzes Desktopenvironment nach, sorry.

Warum sind den die Abhängigkeiten auf Orbit = Gnome gesetzt, wobei ich ja auch nur QT möchte? GTK funktioniert doch auch ohne Orbit (bestes Beispiel alle Mozilla-Anwendungen). 

Sollte das kein Bug sein, schade, als Fluxbox/KDEler entferne ich das schöne Tool dann wieder.

----------

## Necoro

Öhm ... *irritiert*

wenn du kein gtk gesetzt hast (überprüfe das mal bitte  :Smile: ), kommen nur folgende Abhängigkeiten zum Tragen:

```
=sys-apps/portage-2.1.2*

   etcproposals? (>=app-portage/etcproposals-1.0)

   qt4? (

      >=dev-python/PyQt4-4.1.1

      !noroot? (>=kde-base/kdesu-3.5.5)

   )"
```

und da kann ich einfach nix erkennen, was auf orbit schließen lässt ... eventuell hast du auch etcproposals gesetzt und dort das gtk-Flag aktiviert ... das wäre das einzige was ich mir erklären kann.

Solltest du doch das gtk-Flag gesetzt haben, so kannst du leider nur auf orbit verzichten, wenn auch syntax deaktiviert ist. Ich muss mal gucken ob ich die Abhängigkeit da irgendwie rausbekomme, kann es aber nicht versprechen (die Python-Bindings vom GtkSourceview sind nun mal leider von Gnome =/).

----------

## UTgamer

Zu etcproposals bin ich noch nicht ganz vorgedrungen, hier meine Useflags:

USE="3dnow aac aalib alsa amd apache2 apm audiofile avi browserplugin bzip2 cdparanoia cdr cgi \

     cups dga directfb divx4linux doc dv dvb dvd dvdr dvdread emacs encode fbcon ffmpeg fftw flac \

     flash firebird foreign-package freetype fontconfig ftp gif glut gpm hal icq ieee1394 \

     imagemagick imlib jack javascript joystick jpeg kqemu ladcca lcms leim libg++ libwww lm_sensors mikmod \ 

     mime mmx mng modplug motif mozilla moznomail mp3 mpeg nas ncurses nls nosendmail nptlonly nsplugin \

     nvidia oav ogg oggvorbis ooo-kde openal opengl opie osc oss pdflib perl png portaudio \

     posix postgres profile python qt qtmt quicktime readline rp-pppoe ruby samba sasl scanner sdl \

     seamonkey shorten simplexml skins slang sndfile sockets socks5 sox speex spell sse sse2 sse3 ssl \

     svg svga tcltk tcpd tetex tiff truetype usb v4l vcd video_cards_nvidia videos vidix vorbis \

     win32codecs wxwindows X Xaw3d xface xine xinerama xml xml2 xmms xv xvid xvmc zlib \

     -arts -avahi -berkdb -bonobo -cjk -crypt -eds -gphoto2 -gnome -gstreamer -iconv -ipv6 -kerberos -java \

     -mailbase -mailwrapper -mbox -ruby -selinux -ssmtp -unicode -utf8 -zeroconf"

Nichts was auf gnome schließen läßt, weil darauf habe ich immer geachtet gehabt.

[Edit]

Das muste ich noch unmasken, aber kein Problem: dev-python/PyQt4-4.1.1 (masked by: ~amd64 keyword)

```
emerge portato -p

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] x11-libs/vte-0.14.1  USE="doc opengl python -debug"

[ebuild  N    ] gnome-base/orbit-2.14.2  USE="doc ssl -debug"

[ebuild  N    ] gnome-base/gnome-keyring-0.6.0  USE="-debug"

[ebuild  N    ] gnome-base/libgtop-2.14.6  USE="X -debug -gdbm"

[ebuild  N    ] app-admin/sudo-1.6.8_p12-r1  USE="pam -ldap -offensive (-selinux) -skey"

[ebuild  N    ] dev-python/sip-4.5.2-r1  USE="-debug"

[ebuild  N    ] gnome-base/gconf-2.14.0  USE="doc -debug"

[ebuild  N    ] dev-python/PyQt4-4.1.1  USE="doc -debug -examples"

[ebuild  N    ] x11-libs/libgksu-2.0.0  USE="doc nls -debug"

[ebuild  N    ] x11-libs/gksu-2.0.0  USE="doc -debug -gnome"

[ebuild  N    ] app-portage/portato-0.7.3  USE="gtk qt4 -noroot -syntax"
```

Das sind die Abhängigkeiten die auf nem Gnome freien Rechner noch fehlen.  :Wink: 

----------

## Necoro

Hmm ... komisch ...

ich hab auch auf meinem Rechner mal orbit deinstalliert (was macht das eigentlich?) - und portato mit -gtk installiert ... dabei will er kein orbit haben.

Demaskiere mal kurz dein orbit und mache ein "emerge -pvt =portato-0.7.3" - so sollte man den Übeltäter finden *g*

edit:/ Und du hast ja doch gtk gesetzt ^^

edit:/ gksu ist übrigens schuld -.- ... als Workaround: Setze noroot - das installiert dein kein (kde|gk)su

----------

## UTgamer

gtk nicht direkt.

Ich habe ja auch nichts gegen gtk, weil sonst müßte ich auf meine Browser, Lieblingseditoren und sonstiges verzichten  :Wink: 

```
emerge -pvt =portato-0.7.3

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild  N    ] app-portage/portato-0.7.3  USE="gtk qt4 -noroot -syntax" 0 kB [1]

[ebuild  N    ]  dev-python/PyQt4-4.1.1  USE="doc -debug -examples" 5,347 kB

[ebuild  N    ]   dev-python/sip-4.5.2-r1  USE="-debug" 408 kB

[ebuild  N    ]  x11-libs/gksu-2.0.0  USE="doc -debug -gnome" 431 kB

[ebuild  N    ]   x11-libs/libgksu-2.0.0  USE="doc nls -debug" 473 kB

[ebuild  N    ]    app-admin/sudo-1.6.8_p12-r1  USE="pam -ldap -offensive (-selinux) -skey" 572 kB

[ebuild  N    ]    gnome-base/libgtop-2.14.6  USE="X -debug -gdbm" 741 kB

[ebuild  N    ]    gnome-base/gnome-keyring-0.6.0  USE="-debug" 466 kB

[ebuild  N    ]    gnome-base/gconf-2.14.0  USE="doc -debug" 1,852 kB

[ebuild  N    ]     gnome-base/orbit-2.14.2  USE="doc ssl -debug" 691 kB

[ebuild  N    ]  x11-libs/vte-0.14.1  USE="doc opengl python -debug" 986 kB

Total: 11 packages (11 new), Size of downloads: 11,961 kB

Portage overlays:

 [1] /usr/local/portage
```

Orbit ist wohl die Kernbibliothek von Gnome (bin aber kein Gnome Experte), habe ich die einmal auf dem Rechner breitet sich eine Seuche an Abhängigkeiten aus. Früher bereits mal getestet.

----------

## Necoro

Siehe meinen zweiten edit:

 *Quote:*   

> edit:/ gksu ist übrigens schuld -.- ... als Workaround: Setze noroot - das installiert dein kein (kde|gk)su

 

Weiß sonst jemand einen ersatz für gksu, der kein Gnome benötigt?

----------

## UTgamer

Jep korrekt.  :Smile: 

```
USE="noroot" emerge portato -pvt

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild  N    ] app-portage/portato-0.7.3  USE="gtk noroot qt4 -syntax" 0 kB [1]

[ebuild  N    ]  dev-python/PyQt4-4.1.1  USE="doc -debug -examples" 5,347 kB

[ebuild  N    ]   dev-python/sip-4.5.2-r1  USE="-debug" 408 kB

[ebuild  N    ]  x11-libs/vte-0.14.1  USE="doc opengl python -debug" 986 kB

Total: 4 packages (4 new), Size of downloads: 6,740 kB

Portage overlays:

 [1] /usr/local/portage
```

[Edit]

kdesu benutze ich nur, alle Desktopmanager die über KDM gestartet werden benötigen kdesu, und die wohl über gdm gestartet werden gksu.  :Wink: 

#################################################################

Das Problem hierunter war ein nicht aufgelöstes Portage-Problem, ist gelöst.

#################################################################

[Edit 2]

Habe noch eine ACCESS VIOLATION

```
######################################

...

(cd . \

         && /usr/bin/pygtk-codegen-2.0 \

            --register /usr/share/pygtk/2.0/defs/pango-types.defs \

            --register /usr/share/pygtk/2.0/defs/gdk-types.defs \

            --register /usr/share/pygtk/2.0/defs/gtk-types.defs \

            --override vte.override \

            --prefix pyvte vte.defs) > gen-vte.c \

        && cp gen-vte.c vte.c \

        && rm -f gen-vte.c

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/argtypes.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/argtypes.pyc

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/definitions.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/definitions.pyc

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/defsparser.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/defsparser.pyc

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/scmexpr.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/scmexpr.pyc

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/override.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/override.pyc

ACCESS DENIED  unlink:    /usr/share/pygtk/2.0/codegen/reversewrapper.pyc

ACCESS DENIED  open_wr:   /usr/share/pygtk/2.0/codegen/reversewrapper.pyc

mkdir .libs

######################################################

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------

LOG FILE = "/var/log/sandbox/sandbox-x11-libs_-_vte-0.14.1-28252.log"

unlink:    /usr/share/pygtk/2.0/codegen/argtypes.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/argtypes.pyc

unlink:    /usr/share/pygtk/2.0/codegen/definitions.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/definitions.pyc

unlink:    /usr/share/pygtk/2.0/codegen/defsparser.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/defsparser.pyc

unlink:    /usr/share/pygtk/2.0/codegen/scmexpr.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/scmexpr.pyc

unlink:    /usr/share/pygtk/2.0/codegen/override.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/override.pyc

unlink:    /usr/share/pygtk/2.0/codegen/reversewrapper.pyc

open_wr:   /usr/share/pygtk/2.0/codegen/reversewrapper.pyc

--------------------------------------------------------------------------------
```

Schade, aber ich werde wieder auf Portato zurückkommen.   :Confused: 

[Edit 3]

Ich habe mal ein 

```
USE="noroot -qt4" emerge portato
```

 probiert, ändert aber nichts an der Access violation. Das Xft powered terminal widget (VTE) geht leider nicht zu kompilieren.

Muß es den genau dieses Terminal von XFCE sein? Nur als Vorschlag, Konsole von KDE kann wirklich enorm viel, oder auch ganz einfach welches überall vorhanden ist das von X selbst das xterm, aterm wird auch oft verwendet weil semitransparentz möglich ist, habe ich auch drauf.  :Wink: 

[Edit 4]

Nur mal so auf die Schnelle:

```
konsole --help

Verwendung: konsole [Qt-Optionen] [KDE-Optionen] [Optionen] [args]

X-Terminal für die Benutzung in KDE.

Allgemeine Optionen:

  --help                    Hilfe zu verfügbaren Optionen anzeigen

  --help-qt                 Spezielle Optionen zu Qt anzeigen

  --help-kde                Spezielle Optionen zu KDE anzeigen

  --help-all                Alle Optionen anzeigen

  --author                  Autoren-Information anzeigen

  -v, --version             Versionsinformation anzeigen

  --license                 Lizenz-Informationen anzeigen

  --                        Ende der Optionen

Optionen:

  --name <name>             Fensterklasse einstellen

  --ls                      Anmelde-Shell starten

  -T <title>                Fenstertitel einstellen

  --tn <terminal>           Terminaltyp aus der Umgebungsvariable [xterm]

                            $TERM übernehmen

  --noclose                 Konsole nach Programmende nicht schließen

  --nohist                  Keine Zeilen im Befehlspuffer speichern

  --nomenubar               Keine Menüleiste anzeigen

  --notabbar, --notoolbar   Keine Unterfensterleiste anzeigen

  --noframe                 Keinen Rahmen anzeigen

  --noscrollbar             Keine Bildlaufleiste anzeigen

  --noxft                   Xft (Kantenglättung) nicht verwenden

  --vt_sz CCxLL             Terminalgröße in Spalten x Zeilen

  --noresize                Terminalgröße ist eingefroren

  --type <type>             Mit vorgegebenem Sitzungsprofil starten

  --types                   Verfügbare Sitzungstypen auflisten

  --keytab <name>           Schema auf "Name" setzen

  --keytabs                 Verfügbare Schemata auflisten

  --profile <name>          Mit vorgegebenem Sitzungsprofil starten

  --profiles                Verfügbare Sitzungsprofile auflisten

  --schema <name> | <file>  Schema auf <name> setzen oder die Datei <file> benutzen

  --schemas, --schemata     Verfügbare Schemata auflisten

  --script                  Erweiterte DCOP-QT-Funktionen aktivieren

  --workdir <dir>           Arbeitsordner der Konsole zu Ordner <dir> ändern

  -e <command>              Den Befehl <command> anstelle der Shell ausführen

Argumente:

  args                      Argumente für <command>
```

Ich gebe mal kurz ein Beispiel wie ich die KDE-Konsole für solch eine einfache Aufgabe von Fluxbox aus ansteuere mit Feldgrößendefinition,Überschrift, Befehlsausführung und das sie sich nicht bei beenden der Aufgabe selbst schließt, ist ja nicht jeder fit im KDE:

```
konsole -T Monatskalender --noclose --nomenubar --notabbar --vt_sz 26x8 -e cal -m
```

Evtl. hilft es ja und nicht jeder muß das XFCE-Terminal installieren. Ansonsten müßte ich eigentl. einen Bugreport aufmachen das diese VTE-Version sich auf AMD64 nicht kompilieren läßt.

[Edit 5]

Das ACCESS VIOLATION Problem mit VTE ist altbekannt,

https://bugs.gentoo.org/show_bug.cgi?id=143330

https://bugs.gentoo.org/show_bug.cgi?id=126799

Es gibt soviele Dups davon das ist ja nicht mehr schön. Wenn die ganzen gegebeben Tips dort nicht funktionieren, werde ich mich mit einem Dup bei denen anschließen.  :Wink: 

Das Problem ist gelöst, es gab eine neue pygtk Version die nicht in emerge world auftauchte, nach einem erfolglosen python-updater installierte ich pygtk neu und es gab direkt eine neue Version.

Vielleicht läuft ja noch jemand in das gleiche Problem und kann sich direkt hier informieren.   :Very Happy: 

----------

## Necoro

Öhm öhm ...

das vte ist nicht das Terminal von Xfce. Es ist ein Gtk-Terminal-Widget (also vergleichbar mit einem Button, oder einem Menü ...). Leider gibt es nichts vergleichbares für Qt. konsole ist ein komplettes Programm - und kein Widget. Daher nützt es mir herzlich wenig =/.

Zu den Access Violations: Die Bugreports sagen was von python-updater laufen lassen und pygtk neu installieren  :Wink: 

Dann: Ich habe mir mal Gedanken gemacht, wie man es einbauen kann, dass nur ein fertig installiertes Paket aus der Queue entfernt wird. Dies erfordert (wie schon öfters genannt), dass ich weiß, wann emerge mit einem Paket fertig ist - und wie es heißt.

Dazu kam der Vorschlag, dass ich mir genlop anschauen sollte - immerhin kann das das auch. Das habe ich getan - und muss sagen: Bringt mir nix. genlop schaut nur zu einem Zeitpunkt (dann wenn ich "genlop -c" aufrufe) nach, ob emerge gerade was macht. Ich brauche es aber so, dass ein Event reinkommt, welches mir mitteilt, dass Paket xyz gerade fertig geworden ist. Man könnte dies lösen, indem man in einer Endlosschleife das macht, was genlop macht (ein bisschen mit ps und /proc rumspielen) - halte ich aber für sehr imperformant.

Daher habe ich mir folgendes überlegt: Ich benutze das elog System von Portage. Der Gedanke dahinter ist, dass diese elogs angelegt werden, sobald das Paket fertig ist.

Implementieren würde ich das folgendermaßen:

Statt emerge paket würde ich PORTAGE_ELOG_SYSTEM="custom" PORTAGE_ELOG_COMMAND="portato_elog_event '\${PACKAGE}'" emerge paket machen. Dies würde dazu führen, dass wenn immer ein elog angelegt werden würde, wird "portato_elog_event" mit dem Paketnamen aufgerufen. Das würde diesen Namen nun einfach in eine FIFO schreiben. Portato pollt nun solange, bis in der FIFO-Daten vorhanden sind und fasst den darin gespeicherten Namen denn als das oben gewünschte Event auf.

Anmerkungen dazu:

- Warum FIFO und keine Datei? => Ich brauche das nicht auf Festplatte schreiben. Und FIFO eignet sich aus Prinzip besser (und ich will mal was anwenden, was ich in der Betriebssystem-Vorlesung gelernt hab  :Smile: )

- Was ist, wenn ich mein eigenes PORTAGE_ELOG_COMMAND definiert hab? => Das wird natürlich beachtet und mit ausgeführt.

- Das elog-System legt doch zwei elogs an, wenn es vorher noch eine alte Version deinstalliert... => Das muss natürlich das portage_elog_event beachten und entsprechend filtern  :Smile: 

Hat jemand Verbesserungsvorschläge dazu? - Oder hab ich irgendwas übersehen?  :Smile:  --- Für Tipps und Ratschläge bin ich dankbar =)

----------

## UTgamer

Zurück zum Thema.  :Wink: 

@ Necoro, cool und danke für deine Mühen.

Ich mußte es ja ohne noroot erstellen, nun kommt wenn ich etwas emerge möchte diese Nachricht:

emerge: superuser access would be required.. 

Naja ist kein Beinbruch, bisher mußte ich ja immer erst (kde)su im Terminal eingeben, da ändert sich einfach nichts. Also wie früher: su und dann erst emerge.  :Wink: 

Nun noch eine Notiz am Rande, mein Screen unter Fluxbox ist 1280*1024 Pixel, die Schrift im QT-Modus ist viel zu klein, die im GTK-Modus geht so gerade, einfach weil die Zeilenabstände größer sind. Das gehört gesagt.

Ansonsten muß ich sagen, genau so etwas braucht Gentoo für die breite Masse!

------- Story aus dem Leben --------------------

Ich mußte in den letzten Monaten rund 10 Personen Debian/Ubuntu empfehlen, weil sie noch nie im Leben eine Konsole gesehen haben! Ich wollte mit jemandem remote über Teamspeak einen nVidia Treiber installieren. Nach einer halben Stunde wußte ich endlich wo sein Problem lag. Er hatte zwischen Befehl und Parametern kein Freizeichen gelassen, weil er noch nie im Leben so etwas gemacht hatte. Die anderen waren etwas geschickter, aber mehr als 1 Parameter hintendrann würde ich denen auch nicht zumuten. Auch wenn ich dem ein oder anderen Gentoo gewünscht hätte wegen deren Ehrgeiz, ich wette sie wären daran zugrundegegangen und sie hätten nur noch über Linux geflucht.

Deine Arbeit ist wertvoll!

----------

## Necoro

 *UTgamer wrote:*   

> ------- Story aus dem Leben --------------------
> 
> Ich mußte in den letzten Monaten rund 10 Personen Debian/Ubuntu empfehlen, weil sie noch nie im Leben eine Konsole gesehen haben! Ich wollte mit jemandem remote über Teamspeak einen nVidia Treiber installieren. Nach einer halben Stunde wußte ich endlich wo sein Problem lag. Er hatte zwischen Befehl und Parametern kein Freizeichen gelassen, weil er noch nie im Leben so etwas gemacht hatte. Die anderen waren etwas geschickter, aber mehr als 1 Parameter hintendrann würde ich denen auch nicht zumuten. Auch wenn ich dem ein oder anderen Gentoo gewünscht hätte wegen deren Ehrgeiz, ich wette sie wären daran zugrundegegangen und sie hätten nur noch über Linux geflucht.

 

 :Shocked:  ... *sprachlos*

Wegen den Schriften: Ich würde deinen Qt-Einstellungen die Schuld geben  :Smile: . (Hinweis: KDE ist viel Qt3 - Portato aber Qt4. Die muss man afaik beide konfigurieren - Qt4 übernimmt die nicht von 3 *glaub*). Und auch für GTK gilt: Die Schrifteinstellungen werden vom Nutzer gemacht  :Smile:  - ich habe da keinen Einfluss drauf.

Zu deinen Desktopeinträgen: Ich zitiere mal aus dem Sabayon-Forum:

 *wolfden wrote:*   

> to make a desktop icon you need to do the following
> 
> Right Click on desktop and go to
> 
> ---Create New
> ...

 

Damit hast du denn ein schönes Menü-Icon, welches kdesu mit startet  :Smile:  (das von Portato mitgelieferte hat es ja wegen noroot nicht)

Ansonsten danke für dein Lob  :Smile:  - und deine Hinweise

----------

## misterjack

 *UTgamer wrote:*   

> Auch wenn ich dem ein oder anderen Gentoo gewünscht hätte wegen deren Ehrgeiz, ich wette sie wären daran zugrundegegangen und sie hätten nur noch über Linux geflucht.

 

Lass sie ein Jahr mit Ubuntu warm werden und dann stichelste mal wegen Gentoo  :Smile:  Meine Cousine hat auch vor, sich Gentoo draufzumachen, nachdem sie von Windows auf Ubuntu umgestiegen ist. Liegt wohl am Einfluss von meinen Cousin und mir  :Smile: 

----------

## UTgamer

 *Necoro wrote:*   

>  *UTgamer wrote:*   ... Wegen den Schriften: Ich würde deinen Qt-Einstellungen die Schuld geben . (Hinweis: KDE ist viel Qt3 - Portato aber Qt4. Die muss man afaik beide konfigurieren - Qt4 übernimmt die nicht von 3 *glaub*). Und auch für GTK gilt: Die Schrifteinstellungen werden vom Nutzer gemacht  - ich habe da keinen Einfluss drauf. 

 Also für GTK, sollen angeblich 2 Einträge in der xorg.conf (Suchmachine sei dank) helfen, aber ich merke keinen Unterschied, die Werte für meinen 19 Zöller habe ich eben korrekt vermessen:

http://lists.debian.org/debian-user-german/2005/04/msg00368.html

und aus man: 

```
DisplaySize  width height

         This  optional  entry gives the width and height, in millimetres, of the picture area of the moni-

          tor. If given this is used to calculate the horizontal and vertical pitch (DPI) of the screen.
```

```
Section "Monitor"

# The identifier line must be present.

   Option "CalcAlgorithm" "CheckDesktopGeometry"

   DisplaySize  365 275

        ...
```

Aber bei QT4 steh ich noch komplett auf dem Schlauch, keine Idee bisher.

 *Necoro wrote:*   

> Zu deinen Desktopeinträgen: Ich zitiere mal aus dem Sabayon-Forum:
> 
>  *wolfden wrote:*   to make a desktop icon you need to do the following
> 
> Right Click on desktop and go to
> ...

 

Auch dir danke.

@ misterjack, daran denke ich auch immer, einen Ubuntuler der bereits jetzt mehr als 1 Jahr Erfahrung hat und auch richtig fit ist, will ich mir noch versuchen zu krallen, Fluxbox habe ich ihm auch schon bei gebracht da er eine Alternative suchte.  :Very Happy: 

----------

## Necoro

 *UTgamer wrote:*   

> Aber bei QT4 steh ich noch komplett auf dem Schlauch, keine Idee bisher.

 

```
qt-config
```

----------

## UTgamer

 *Necoro wrote:*   

>  *UTgamer wrote:*   Aber bei QT4 steh ich noch komplett auf dem Schlauch, keine Idee bisher. 
> 
> ```
> qt-config
> ```
> ...

 

qt-config = command not found

Mal auf die Suche gehen.

Aber das gtk-Schriftenproblem welches mich auch schon seit Ewigkeiten nervt konnte ich gerade lösen:

```
Section "Device"

   Option "UseEdidDpi"   "false"

   Option "Dpi"          "100 x 100"

        ...

```

Gefunden hier: http://my.opera.com/CrazyTerabyte/blog/index.dml/tag/fonts

nVidia hat mal wieder eigene Einstellungen und ignoriert Xorg, oder die konnten sich nicht miteinander absprechen, nVidia ist ja älter als Xorg.

----------

## Necoro

 *UTgamer wrote:*   

>  *Necoro wrote:*    *UTgamer wrote:*   Aber bei QT4 steh ich noch komplett auf dem Schlauch, keine Idee bisher. 
> 
> ```
> qt-config
> ```
> ...

 

Ups ... sollte "qtconfig" heißen ...

Zu meiner Idee für das Emerge-Event-Problem: Also elog eignet sich auch nicht  :Sad:  ... es gibt Pakete, wo keine elogs angelegt werden =/ ... *sich wieder auf die Suche nach einer Idee mach*

----------

## UTgamer

qtconfig hat keinerlei Einfluß auf Portato. Ich habe x11-libs/qt-4.2.3-r1 installiert, das Tool selbst benutzt den eingestellten Font, nur Portato nicht.

Ich habe nun rausgefunden das bei einer Einstellung von wahnsinnigen 150 dpi in der xorg.conf, die Schrift in portato sowohl mit gtk als auch mit qt eine annehmbare Größe haben, nur der Rest vom System ist bei max 120 dpi bereits ausgereizt. Also mit 150 dpi ist das System kaum noch bedienungsfähig, ich muß schon die Rahmen verschieben um an die Menüs zu kommen. Aber Portato fühlt sich hier recht wohl.   :Shocked: 

===========================================================

Einfach mal ausprobiert, ich wollte einfach arj zum testen emergen.

Bei "portago qt" bekomme ich einen freez mit dieser Debug Ausgabe den ich killen mußte und das normale Ausgabefenster ist zerstückelt:

```
portato qt

***DEBUG*** In wrapper (plugin.py:321): Overriding hook 'am_i_root' with plugin 'No Root' ***DEBUG***

Getötet
```

In der gtk version behauptet das Ausgabefenster:

```
Calculating dependencies... done!

>>> Emerging (1 of 1) app-arch/arj-3.10.22-r1 to /

waiting for lock on /var/tmp/portage/.app-arch.portage_lockfile
```

 und die Konsolenausgabe ist:

```
***DEBUG*** In wrapper (plugin.py:321): Overriding hook 'am_i_root' with plugin 'No Root' ***DEBUG***

***DEBUG*** In kill_emerge (gui_helper.py:623): Process should be killed ***DEBUG***

***DEBUG*** In update_packages (gui_helper.py:490): Category app-arch refreshed ***DEBUG***

***DEBUG*** In update_packages (gui_helper.py:490): Category app-arch refreshed ***DEBUG***
```

Und alle Prozesse ruhen auch, nur kann ich das Programm noch über den X-Button beenden.

Also es freezt einfach in beiden Versionen.

Über kdesu gestartet, ist der Fehler bei der gtk Version nicht vorhanden (man muß auch erstmal auf die Idee kommen kdesu zu verwenden). Es ist das einzige Programm bisher das sich nicht aus einer su-Konsole starten läßt. Die qt Version friert auch bei kdesu genauso wie mit su gestartet ein.

Also die Fehler sind: Mißachtung aller Font-/Desktopeinstellungen und einfrieren der VTE-Umgebung.

----------

## Necoro

Jetzt bin ich komplett überfragt ...

zu den Schriftgrößen: Ich weise jede Schuld von mir ... ich ändere an denen nichts und lasse Qt/Gtk machen

 *Quote:*   

> 
> 
> ```
> Calculating dependencies... done!
> 
> ...

 

Jo ... lösche einfach mal das lockfile ... - emerge macht manchmal Probleme wenn man es abbricht

 *Quote:*   

> 
> 
> ```
> ***DEBUG*** In wrapper (plugin.py:321): Overriding hook 'am_i_root' with plugin 'No Root' ***DEBUG***
> 
> ...

 

kill_emerge wird nur an zwei Stellen aufgerufen: Wenn man explizit den Button "Kill Emerge" betätigt - oder wenn man Portato beendet, während ein emerge-Prozess läuft.

Dass Qt freezed will ich nicht bestreiten ...  :Wink:  Qt macht sowas manchmal. Das was du unter Gtk als "Freeze" bezeichnest, ist aber nur eine emerge, was auf dieses Lockfile wartet. ^^ ...

----------

## Necoro

So ... ich habe Portato heute für den Sunrise-Overlay angemeldet. Dafür wurden einige Änderungen an den ebuilds vorgenommen. U.a. wurde "portatosourceview" von app-portage nach dev-util verschoben und das Flag noroot in userpriv umbenannt. Um die Versionsnummenr mit denen in Sunrise übereinstimmen zu lassen, habe ich keine Revisionsänderung vorgenommen. Ich bitte daher um ein update der ebuilds mittels "layman -s portato" um spätere Konflikte zu verhindern.  :Smile: 

----------

## Necoro

Okay ... Portato ist nun im sunrise-overlay. Sollte also jmd von euch diesen schon benutzen kann er getrost den portato-overlay entfernen. Es sei denn, er will die svn-version  benutzen - die gibt es nicht im sunrise.

----------

## Necoro

Neue Version: 0.7.4.1

Änderungen:

- Anzeige des Overlays, aus dem ein Paket stammt

- aus EMERGE_DEFAULT_OPTS werden "--ask"/"-a" und "--pretend"/"-p" entfernt

- Gründe fürs Maskieren werden als Tooltip bei der Masked-Checkbox angezeigt

- Man kann nun die Schriftart in der GTK-Konsole ändern

- Emerge Fortschritt wird auch im Fenstertitel angezeigt

- sollte nun auch mit PyQt4-4.2 funktionieren

/edit: http://www.sabayonlinux.org/forum/viewtopic.php?t=7642 *freu* ^^

----------

## nikaya

 *Necoro wrote:*   

> 
> 
> /edit: http://www.sabayonlinux.org/forum/viewtopic.php?t=7642 *freu* ^^

 

Ich freue mich für Dich mit.Du hast viel Arbeit und Grips in Portato investiert,das sollte mal anerkannt werden.  :Smile: 

Denen bei Sabayon scheint ein GUI-Paketmanager ja ziemlich wichtig zu sein,wenn man mal die Threads sieht,die sich allein auf Kuroo beziehen.

Mir ist CLI zwar lieber,würde mich aber freuen wenn die Sabayoner Portato mal als Default-GUI-Paketmanager nehmen würden.Das Konzept ist auf jeden Fall gut.

P.S.:Was war das im Mittelteil,mit Paludis Support?  :Wink: 

----------

## Necoro

 *john.doe wrote:*   

> P.S.:Was war das im Mittelteil,mit Paludis Support? 

 

Wie er schrieb: Wenn die Python-Bindings mal fertig werden, werde ich mich dransetzen  :Smile: 

----------

## nikaya

 *Necoro wrote:*   

>  *john.doe wrote:*   P.S.:Was war das im Mittelteil,mit Paludis Support?  
> 
> Wie er schrieb: Wenn die Python-Bindings mal fertig werden, werde ich mich dransetzen 

 

Aha,sind die denn schon in Arbeit?Ich meine irgendwo gelesen zu haben (Gentoo-Dev Mailing-list?) dass ciaranm nicht gerade erbaut ist von der Idee.

----------

## Necoro

 *john.doe wrote:*   

>  *Necoro wrote:*    *john.doe wrote:*   P.S.:Was war das im Mittelteil,mit Paludis Support?  
> 
> Wie er schrieb: Wenn die Python-Bindings mal fertig werden, werde ich mich dransetzen  
> 
> Aha,sind die denn schon in Arbeit?Ich meine irgendwo gelesen zu haben (Gentoo-Dev Mailing-list?) dass ciaranm nicht gerade erbaut ist von der Idee.

 

ciaranms Meinung ist mir ziemlich egal ;P ... aber sie sind schon in Arbeit (im SVN sind sogar schon einige Python-Sachen) - aber ich habe keine Ahnung, wann das offz wird... Außerdem sind die Python-Bindings für Paludis sogar ein "Google Summer of Code"-Projekt...

----------

## nikaya

 *Necoro wrote:*   

> 
> 
> Außerdem sind die Python-Bindings für Portato sogar ein "Google Summer of Code"-Projekt...

 

Ist bestimmt ein typo und sollte Paludis heißen.  :Twisted Evil: 

Aber wo Du es erwähnst fällt es mir auch wieder ein,da war doch was.  :Wink: 

http://ciaranm.org/show_post/111

----------

## Necoro

 *john.doe wrote:*   

>  *Necoro wrote:*   
> 
> Außerdem sind die Python-Bindings für Portato sogar ein "Google Summer of Code"-Projekt... 
> 
> Ist bestimmt ein typo und sollte Paludis heißen. 

 

Ups ... erst denken dann schreiben ^^ ... habs korrigiert  :Wink: 

----------

## think4urs11

 *Necoro wrote:*   

> Ich habe mir mal Gedanken gemacht, wie man es einbauen kann, dass nur ein fertig installiertes Paket aus der Queue entfernt wird. Dies erfordert (wie schon öfters genannt), dass ich weiß, wann emerge mit einem Paket fertig ist - und wie es heißt.

 

Überwachen von /var/log/emerge.log?

Etwa so: tail -f /var/log/emerge.log | sed -e '/completed emerge/!d;s/\([0-9]*\).*) \(.*\) to.*/\1 \2/'

Ergibt Datum (in epoch) und Kategorie/Paketname-Version (ohne Version: im sed ;s/-[0-9]\{1,\}.*$// anhängen)

Das epoch-Datum in 'lesbar' umwandeln geht dann z.B. so

a) date -d @1180797725 +"%F %T"

b) echo 1180797725 | awk '{ printf "%s\n", strftime("%F %T", $1) }'

----------

## Necoro

think4urs11: danke für die Mühe ^^ ... aber ich weiß nicht, ob ich das wirklich umsetzen werde ... eigentlich ist mir das zu dreckig  :Smile:  bin ja kein Perl-Programmierer ;P

/edit: Ich verstehe nicht, warum die Portage-Leute es nicht schaffen, einfach Hooks zur Verfügung zu stellen ... =/ (für Sync haben sie ja einen)

----------

## Necoro

Nur eine kurze info für die Benutzer des GTK-Frontends: Ich habe aus dem portatosourceview-Paket (welches die Python-Bindings für das gtksourceview bereitstellt) alle Gnome-Dependecies entfernt. Daher hab ich auch das syntax-use-flag entfernt, da ich nun keinen Grund mehr sehe, es nicht zu installieren  :Wink: 

----------

## Necoro

Neues Release: 0.7.5

Changes:

- new icon

- syncbefehl erlaubt nun auch "&&"

- mit "portato -e $package" wird das ebuild von $package angezeigt (der REst der Oberfläche wird nicht gestartet)

- Terminal unter Qt sieht jetzt besser aus und funktioniert besser  :Wink: 

- (auf Wunsch der Sabayon-Nutzer): es gibt nun auch einen Dialog, der die Pakete anzeigt, für die ein Update vorliegt

----------

## Necoro

Paludis hat jetzt Python-Bindings ... werde also wahrscheinlich in der nächsten Zeit mal versuchen ein Paludis-Backend zu schreiben ...

----------

## nikaya

 *Necoro wrote:*   

> Paludis hat jetzt Python-Bindings ... werde also wahrscheinlich in der nächsten Zeit mal versuchen ein Paludis-Backend zu schreiben ...

 

... bin gespannt darauf.  :Wink: 

----------

## Necoro

Hmm ... das mit Paludis braucht noch ... irgendwie sind die Python Bindings noch nicht in Portage ...

Aber:

Portato ist nun als Portage-Frontend beim Sabayonlinux 3.4 standardmäßig dabei  :Smile:  *freu*

----------

## misterjack

Mich würde noch der Homepage-Link zu jedem ebuild interessieren. Schau mir die gerne mal an, wenn ich auf der Suche nach nem Programm aus ner bestimmten Kategorie bin.

----------

## Necoro

 *misterjack wrote:*   

> Mich würde noch der Homepage-Link zu jedem ebuild interessieren. Schau mir die gerne mal an, wenn ich auf der Suche nach nem Programm aus ner bestimmten Kategorie bin.

 

http://portato.svn.sourceforge.net/viewvc/portato/overlay/app-portage/portato/ <-- da sind sie alle  :Smile: 

----------

## franzf

 *Necoro wrote:*   

>  *misterjack wrote:*   Mich würde noch der Homepage-Link zu jedem ebuild interessieren. Schau mir die gerne mal an, wenn ich auf der Suche nach nem Programm aus ner bestimmten Kategorie bin. 
> 
> http://portato.svn.sourceforge.net/viewvc/portato/overlay/app-portage/portato/ <-- da sind sie alle 

 

Hehe, du hast das falsch verstanden  :Wink: 

Es wird ein Link in Portato zu den Projektseiten eines jeden Pakets gesucht, nicht die Homepage zu Portato  :Wink: 

----------

## Necoro

 *franzf wrote:*   

>  *Necoro wrote:*    *misterjack wrote:*   Mich würde noch der Homepage-Link zu jedem ebuild interessieren. Schau mir die gerne mal an, wenn ich auf der Suche nach nem Programm aus ner bestimmten Kategorie bin. 
> 
> http://portato.svn.sourceforge.net/viewvc/portato/overlay/app-portage/portato/ <-- da sind sie alle  
> 
> Hehe, du hast das falsch verstanden 
> ...

 

Aah ... sorry ^^ ... das gibt es im nächsten Release ... bin gerade am einbauen ... unter Gtk funktioniert es schon --- nur Qt macht mal wieder Ärger (wie immer  :Sad: )

----------

## franzf

 *Necoro wrote:*   

> nur Qt macht mal wieder Ärger (wie immer )

 

Na gut, dann versuch ich mal in Python (kann das eigentlich nicht  :Wink: )

Irgendwie so sollte es funktionieren:

```
self.homepageLabel = QtGui.QLabel()

homepageLabel.setOpenExternalLinks( True )

homepageLabel.setTextFormat( Qt.RichText )

homepageLabel.setText( "<a href='www.portato.sf.net'>portato homepage</a>" )
```

Mehr brauchts  nicht  :Wink: 

Funktioniert genauso für den QTextBrowser.

Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

>  *Necoro wrote:*   nur Qt macht mal wieder Ärger (wie immer ) 
> 
> Na gut, dann versuch ich mal in Python (kann das eigentlich nicht )
> 
> Irgendwie so sollte es funktionieren:
> ...

 

Jopp -- danke - das wars  :Smile:  - muss man ja auch drauf kommen, dass nochmal in HTML Tags zu setzen ... bei GTK gibt es halt ein LinkButton Widget - da muss man nur den text setzen ...

Trotzdem macht Qt noch Stress ... schmiert jetzt ab und zu mit einem "X Window System Error" ab, wenn es einen Fehler-Dialog öffnen soll =/

----------

## franzf

 *Necoro wrote:*   

> bei GTK gibt es halt ein LinkButton Widget - da muss man nur den text setzen ...

 

Ist das ein "richtiger" Button?

Wenn du das mit Qt machen willst, erstell dir einfach einen QPushButton und connecte das "clicked()"-Signal mit einem Slot in dem du

```
bool QDesktopServices::openUrl ( const QUrl & url )   [static]
```

aufrufst. (Ich glaub in Python ersetzt du "::" durch ".", bei statischen Methoden, oder?)

 *Quote:*   

> Trotzdem macht Qt noch Stress ... schmiert jetzt ab und zu mit einem "X Window System Error" ab, wenn es einen Fehler-Dialog öffnen soll =/

 

 :Sad:  Kannst du mir mal sagen, welche Stellen für das Problem in Frage kommen? Vllt. hab ich ja nen kleinen Geistesblitz (soll ja hin&wieder mal vorkommen  :Wink: )

Grüße

Franz

----------

## Necoro

Also das Link-Problem hab ich gelöst  :Smile:  (und ja - in Gtk sind das wirklich Buttons weil Labels keine Events empfangen können). Danke nochmal  :Smile: 

Problem ist folgendes: Ich habe einen QDialog (egal ob modal oder nicht) - und wenn ich jetzt dort eine Fehlermeldung anzeigen lassen will (via QMessagebox.critical) schmiert er ab. In einem anderen Fall zeigt er sie noch an - und stürzt ab, wenn sie beendet wird...

----------

## franzf

 *Necoro wrote:*   

> Also das Link-Problem hab ich gelöst  (und ja - in Gtk sind das wirklich Buttons weil Labels keine Events empfangen können). Danke nochmal 

 

Kein Problem, immer gerne  :Smile: 

(Wenn du das gleiche Verhalten wie in GTK haben willst, kannst du dir ja eine eigene LinkButton-Klasse schreiben, die dann selbständig oben beschriebene Connection tätigt)

 *Quote:*   

> Problem ist folgendes: Ich habe einen QDialog (egal ob modal oder nicht) - und wenn ich jetzt dort eine Fehlermeldung anzeigen lassen will (via QMessagebox.critical) schmiert er ab. In einem anderen Fall zeigt er sie noch an - und stürzt ab, wenn sie beendet wird...

 

Ich hab das mal ausprobiert und hab mit Folgendem kein Problem:

```
QtGui.QMessageBox.critical( None, QtGui.qApp.tr("Critical Error"),

      QtGui.qApp.tr("Big error in win32.dll") )
```

Wie schaut der Aufruf denn bei dir aus?

----------

## Necoro

Also ich hab das jetzt mal versucht in Beispiel-Code zu fassen - aber in dem funktioniert es. Hab also keine Ahnung woran es liegt --- vielleicht ein Bug in PyQt - oder wirklich in meinem Code ...

/edit: Ach - und ich spiele mit dem Gedanken, das Qt Frontend zu kippen ...

----------

## franzf

Du connetest buttonBox::accepted() mit PreferenceWindow::finish(). Außerdem connectest du vorher (im *.ui) selbiges Signal mit QDialog::accept(). Dieser Slot schließt das Fenster. Ich denke hier liegt der Wurm. Evtl. wurde der QDialog schon zerstört und somit fehlt der Bezug zu QtGui.qApp (Bzw. QDialog als korrektes QWidget als parent, wenn QMessageBox.* nicht "None" als parent übergeben bekommt).

Sind aber nur Vermutungen, weiß ja nicht sooo viel von Python  :Smile: 

```
The program 'portato' received an X Window System error.

This probably reflects a bug in the program.

The error was 'BadMatch (invalid parameter attributes)'.
```

Das ist der Fehler den ich bekomme.

Das beste wird sein PreferenceWindow.accept() zu überschreiben. Wenn kein Error geraised wird -> QDialog.accept(), ansonsten -> io_ex_error().

Ich probier noch bissl rum.

Grüße

Franz

----------

## franzf

Hab direkt nach dem letzten Post in den Garten müssen ->Wurzeln ziehen  :Wink:  (gaaaanz böse viel zu tiefe...)

Den Crash im PreferenceWindow hab ich dir gesolved  :Wink: 

```
def accept (self):

    self._save()

    try:

        self.cfg.write()

        return QDialog.accept(self)

    except IOError, e:

        io_ex_dialog( self, e )
```

in windows.py in PreferenceWindow. Erst aber from PyQt4.QtGui import QDialog. Den Rest einfach so lassen.

finish() kannste dir schenken. Natürlich in __init__ die connection "accepted() -> finish()" löschen.

Das klappt bei mir hervorragend  :Smile: 

Werd mich in windows.py nochmal umschauen, ob ich was finde was genau so aufgebaut ist.

Aber erst mal Abend essen  :Razz: 

Grüße

Franz

----------

## Necoro

Hey danke  :Smile:  - werde das heute abend mal einbauen  :Smile: 

Was mich halt nur wundert - ich hab halt ein Beispiel gebaut wo es auch so eine finish-funktion gibt ... da klappt es aber hervorragend *wunder*

Du hast nicht zufällig Lust, das Qt-Frontend unter deine Fittiche zu nehmen?

 *Quote:*   

> Erst aber from PyQt4.QtGui import QDialog

 

Naa ^^ ... den import brauchst du nicht ... man könnte auch einfach Qt.QDialog machen  :Smile: 

----------

## franzf

GRRRRR

```
* checking 11 files for package collisions

existing file /usr/share/gtksourceview-1.0/language-specs/gentoo.lang is not owned by this package

* This package is blocked because it wants to overwrite

* files belonging to other packages (see messages above).

* If you have no clue what this is all about report it

* as a bug for this package on http://bugs.gentoo.org

package dev-util/portatosourceview-2.16.1 NOT merged

Searching all installed packages for file collisions...

Press Ctrl-C to Stop

 * x11-misc/gtksourceview_gentoo-1:

     '/usr/share/gtksourceview-1.0/language-specs/gentoo.lang'
```

Krieg ich mit angeschaltetem collision-protect.

Und das Qt-Frontend haste echt schon gekippt...

Willst mich unter Druck setzen, was?  :Smile: 

Wenn du geduldig bist kann ich es ja mal versuchen (aber bitte nicht schlagen, wenns daneben geht  :Wink: )

Grüße

Franz

----------

## Necoro

Zu deinem collision-protect system ... deinstallier mal gtksourceview_gentoo  :Smile: 

Eine Zeit hatte ich in dem portatosourceview immer ein Block auf das drin, hab ihn aber irgendwann rausgenommen, weil ich davon ausging, dass das niemand mehr installiert hat ^^

Wegen des Qt-Frontends:

Also aus dem nächsten Release wird es wohl definitv verschwinden. Der Grund ist aber eher, da sich einige Leute beschweren, weil es sich aufhängt. Das liegt an meiner Implementierung des Terminals - wenn man ein emerge-Vorgang mit viel Output hat, wird Qt leider überlastet und gibt auf. So lange niemand eine bessere Terminal-Implementierung hat (ich hoffe da auf den Port von Konsole nach Qt4) wird es auch draußen bleiben.

Insofern bin ich auch geduldig  :Wink: 

----------

## Necoro

So...

Version 0.8.0 ist da ...

Main Features:

Qt-Frontend gekippt

Zwei neue Plugins (beide Plugins müssen explizit im Plugin Menü aktiviert werden):

"Shutdown": schaltet den Rechner nach dem Emerge aus

"Resume Loop": lässt nach dem Emerge ein "while emerge --resume --skipfirst; do : ;done"

XSD für die Plugins  :Wink: 

man kann den emerge Prozess nun anhalten (wie halt ein Strg-Z in der Konsole) --- (und denn auch wieder weiterlaufen lassen)

Log Viewer für Portato logs

gtk design ein wenig überarbeitet

der Homepage Link eines Paketes wird nun angezeigt

Suche ein wenig verbessert

----------

## misterjack

 *Necoro wrote:*   

> der Homepage Link eines Paketes wird nun angezeigt

 

Fast perfekt, jedoch will Portato ein neues Firefox-Fenster öffnen, anstatt sich an die Systemvorgaben zu halten. Die Option Pakete mit missing keyword installieren zu können wäre auch noch ein Gewinn  :Smile: 

----------

## Necoro

 *misterjack wrote:*   

>  *Necoro wrote:*   der Homepage Link eines Paketes wird nun angezeigt 
> 
> Fast perfekt, jedoch will Portato ein neues Firefox-Fenster öffnen, anstatt sich an die Systemvorgaben zu halten. Die Option Pakete mit missing keyword installieren zu können wäre auch noch ein Gewinn 

 

Oh ... das Problem ist, dass er das Fenster als root öffnet. Wenn man portato als normaler User startet und auf einen Link klickt, öffnet sich nur ein neuer Tab. Ich sollte rausfinden, wie man firefox davon überzeugt, das als normaler User zu öffnen ... Ich denke ich werde das mal umstellen, so dass Portato als normaler User startet und nur für emerge vorgänge man das root password eingeben muss ...

Zu den missing keywords: Aye Sir - added to TODO  :Smile: 

----------

## misterjack

 *Necoro wrote:*   

> 
> 
> Oh ... das Problem ist, dass er das Fenster als root öffnet.

  Ah stimmt, hab ich gar nicht bedacht.  :Smile:  Du machst das schon, wird immer besser das Programm  :Smile: 

----------

## Necoro

 *misterjack wrote:*   

> Du machst das schon, wird immer besser das Programm 

 

Danke  :Very Happy:  - geb mir Mühe  :Smile: 

----------

## Necoro

 *Necoro wrote:*   

> Ich denke ich werde das mal umstellen, so dass Portato als normaler User startet und nur für emerge vorgänge man das root password eingeben muss ...

 Getan  :Smile:  ... bzw: Portato wird jetzt als normaler User gestartet. Denn forkt es sich und ein Prozess (als normaler User) fungiert als Listener welcher Befehle entgegennimmt (zB einen Browser zu öffnen). Der andere startet gksu (oder was auch immer) und läuft danach als root  :Smile:  -> Links werden nun im Browser des normalen Users angezeigt =)

----------

## Necoro

Um mal meine Release-Struktur ein wenig zu verbessern, gibt es jetzt ein Pre-Release von dem kommenden 0.8.5 Release. (Das Prerelease gibts nur im portato-Overlay - nicht auf sunrise).

Ich bitte alle Interessierten, sich das Teil mal anzugucken  :Smile:  - und zu schauen ob es noch Bugs gibt, die vor dem endgültigen Release gefixt werden sollten. Auch habt mal ein Auge drauf, ob das update-world in Portato und ein "emerge -upvND world" einen Unterschied zeigt.

Änderungen:

Exceptions werden nun nicht mehr einfach nach stderr geschrieben, sondern ein netter Dialog poppt auf  :Smile: 

i18n (ja - es gibt jetzt ne deutsche Übersetzung) 

neues Threading-Modell für Emerge  :Arrow:  hoffentlich keine aufgehangenen Prozesse mehr

Splash Screen

Notifies  :Arrow:  wenn libnotify gesetzt ist, poppt am Ende eines Emerge-Prozesses ein Notify-Popup auf und weist auf den (Mis)erfolg hin

Portato startet nun als normaler User und fragt danach nach dem root passwort (siehe Post drüber). Wenn es das nicht tun soll: "portato -L" läuft im Kontext des momentanen Users

Bei den Paket-Details wird nun zwischen "installierten" und "aktiven" Useflags unterschieden

bisschen am Terminal rumgeschraubt  :Arrow:  kein "klick nach starten eines neuen Prozesses in das Terminal" mehr ...

----------

## srm

Here some steps for PPC Powerbook G4

adding missing keyword:

```
echo "app-portage/portato **" >> /etc/portage/package.keywords/portato

echo "dev-util/portatosourceview **" >> /etc/portage/package.keywords/portato
```

adding additional packages:

```
echo "dev-python/lxml" >> /etc/portage/package.keywords/portato

echo "dev-python/setuptools" >> /etc/portage/package.keywords/portato
```

testwise unmerge working

Sync working

----------

## srm

Oh, ist ja deutsch hier...naja.

Beim Versuch von "update deep newuse world" kommt nach einiger Zeit folgende Fehlermeldung:

```
Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/portato/gui/gtk/windows.py", line 1185, in cb_idle_append

    self.queue.append(pkg.get_cpv(), unmask = unmask)

  File "/usr/lib/python2.4/site-packages/portato/gui/gui_helper.py", line 439, in append

    deps = pkg.get_dep_packages()

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/package.py", line 202, in get_dep_packages

    raise BlockedException, (self.get_cpv(), blocked[0].get_cpv())

BlockedException: ('sys-fs/udev-114', 'sys-fs/device-mapper-1.02.19')

```

Zusätzlich erschien keine Ausgabe in der Konsole von Portato.

Ich lasse das Update jetzt manuell laufen.

Kann es etwas mit der folgenden Ausgabe von emerge zu tun haben?

```
Calculating world dependencies /

!!! Ebuilds for the following packages are either all

!!! masked or don't exist:

games-rpg/planeshift media-gfx/nvidia-cg-toolkit mail-filter/spamassassin-ruledujour dev-games/crystalspace-ps dev-games/cel-ps

```

Diese erscheint, da ich die entsprechenden Pakete in einem Overlay habe beziehungsweise ausgeklammert habe um sie nur manuell zu updaten.

Gruß

----------

## Necoro

Nein - das hat damit nichts zu tun. Der Portato-Traceback sagt nur, dass "device-mapper" "udev" blockiert. Warum darauf kein entsprechender Dialog kam muss ich mal ergründen. (Und dass Portage nix anzeigt, liegt daran, dass die kein Block anzeigt, wenn er sich von selber auflöst ... mal schauen, ob ich das auch irgendwann implementiert bekomme ...)

edit:/ Fixed  :Smile:  - Danke nochmal für die Meldung

edit2:/ hab auch ppc64 als Keyword zu den ebuilds hinzugefügt  :Smile: 

----------

## srm

 *Necoro wrote:*   

> edit2:/ hab auch ppc64 als Keyword zu den ebuilds hinzugefügt 

 

Bei mir ist das aber ppc (32Bit)  :Wink: 

----------

## Necoro

 *srm wrote:*   

>  *Necoro wrote:*   edit2:/ hab auch ppc64 als Keyword zu den ebuilds hinzugefügt  
> 
> Bei mir ist das aber ppc (32Bit) 

 

Ups ... stimmt ... hab das "G4" als "64" gelesen  :Wink:  *korrigier*

----------

## Necoro

 *Necoro wrote:*   

> Um mal meine Release-Struktur ein wenig zu verbessern, gibt es jetzt ein Pre-Release von dem kommenden 0.8.5 Release. (Das Prerelease gibts nur im portato-Overlay - nicht auf sunrise).
> 
> Ich bitte alle Interessierten, sich das Teil mal anzugucken  - und zu schauen ob es noch Bugs gibt, die vor dem endgültigen Release gefixt werden sollten. Auch habt mal ein Auge drauf, ob das update-world in Portato und ein "emerge -upvND world" einen Unterschied zeigt.
> 
> Änderungen:
> ...

 

Ok --- released  :Smile:  ... Vielleicht findet es ja seinen Weg nach Portage  :Wink: 

----------

## dsiggi

Hi,

ich bin neu auf dem Gebiet Gentoo und möchte mir gern Portato installieren.

Aber irgendwie klappt das bei mir nicht.

Auf er Homepage von Necoro sind ja zwei Wege angegeben Portato zu installieren.

Weg a:

# emerge layman

# layman -a sunrise

# emerge -av portato

# emerge layman:

Funktionier und läuft ohne Fehler durch.

# layman -a sunrise

```
* Overlay "sunrise" does not exist!
```

Weg b:

# emerge layman

# füge http://portato.sf.net/layman.xml zur "overlays" Sektion in /etc/layman/layman.cfg hinzu

# layman -f

# layman -a portato

# emerge -av portato

# emerge layman

Hab ich ja schon gemacht.

# URL hinzufügen

Klappt ohne Probleme. 

# layman -f

Einen neue Befehlszeile erscheint. Es wird nichts ausgegeben.

# layman -a portato

```
* Running command "/usr/bin/svn co "https://portato.svn.sourceforge.net/svnroot/portato/overlay/" "/usr/portage/local/layman/portato""...

A    /usr/portage/local/layman/portato/app-portage

A    /usr/portage/local/layman/portato/app-portage/portato

A    /usr/portage/local/layman/portato/app-portage/portato/portato-0.8.5.ebuild

A    /usr/portage/local/layman/portato/app-portage/portato/files

A    /usr/portage/local/layman/portato/app-portage/portato/files/digest-portato-0.8.5

A    /usr/portage/local/layman/portato/app-portage/portato/Manifest

A    /usr/portage/local/layman/portato/app-portage/etcproposals

A    /usr/portage/local/layman/portato/app-portage/etcproposals/etcproposals-1.3.ebuild

A    /usr/portage/local/layman/portato/app-portage/etcproposals/files

A    /usr/portage/local/layman/portato/app-portage/etcproposals/files/digest-etcproposals-1.3

A    /usr/portage/local/layman/portato/app-portage/etcproposals/Manifest

A    /usr/portage/local/layman/portato/profiles

A    /usr/portage/local/layman/portato/profiles/use.local.desc

A    /usr/portage/local/layman/portato/profiles/repo_name

A    /usr/portage/local/layman/portato/dev-util

A    /usr/portage/local/layman/portato/dev-util/portatosourceview

A    /usr/portage/local/layman/portato/dev-util/portatosourceview/files

A    /usr/portage/local/layman/portato/dev-util/portatosourceview/files/digest-portatosourceview-2.16.1

A    /usr/portage/local/layman/portato/dev-util/portatosourceview/Manifest

A    /usr/portage/local/layman/portato/dev-util/portatosourceview/portatosourceview-2.16.1.ebuild

Checked out revision 447.

* Successfully added overlay "portato".
```

# emerge -av portato

```
These are the packages that would be merged, in order:

Calculating dependencies |

emerge: there are no ebuilds to satisfy "portato".

```

Keiner der beiden Wege funktioniert bei mir. Was mach ich den falsch?

dsiggi

----------

## nikaya

Weg a:

```
layman -S
```

(--sync-all) vergessen?

Die /etc/make.conf um folgenden Eintrag ergänzt?

```
source /usr/portage/local/layman/make.conf
```

----------

## dsiggi

Hi,

hab das Problem gefunden.

Ich bin beim Einrichten von layman nach folgendem HowTo vorgegangen:

http://de.gentoo-wiki.com/Portage_Overlay_konfigurieren

Dort steht nun man solle in die /etc/make.conf folgende zeilen einfügen:

```

PORTDIR_OVERLAY="/usr/portage/local/local-overlay"

source /usr/portage/local/layman/make.conf

```

Durch auskommentieren von "PORTDIR_OVERLAY="/usr/portage/local/local-overlay"" kann cih Portato nun installieren.

dsiggi

----------

## Necoro

 *dsiggi wrote:*   

> Durch auskommentieren von "PORTDIR_OVERLAY="/usr/portage/local/local-overlay"" kann cih Portato nun installieren.

 

Das eintragen von PORTDIR_OVERLAY="/usr/portage/local/local-overlay" war eher symbolisch gemeint. Man soll dort seinen lokalen Overlay (sofern man denn einen hat) eintragen  :Wink: 

----------

## Necoro

Es gibt einige Änderungen  :Smile: 

Portato ist im Portage-Tree  :Very Happy:   :Very Happy:  (danke @ jokey)

und das Projekt zieht auch langsam aber sicher von sourceforge um auf ein neues zu hause auf Origo --> http://portato.origo.ethz.ch/ (http://portato.necoro.net als Shortcut)

----------

## chesstux

Hallo,

Ich hab jetzt auch portato ausprobiert. Ich bekomm aber immer einen Fehler, wenn ich z.B. mir die Updates anzeigen lassen will:

Exception im Thread "Show Updates Thread":

Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/portato/gui/gtk/exception_handling.py", line 26, in run

    Thread.run(self)

  File "/usr/lib/python2.4/threading.py", line 422, in run

    self.__target(*self.__args, **self.__kwargs)

  File "/usr/lib/python2.4/site-packages/portato/gui/gtk/windows.py", line 1307, in __update

    packages.extend(system.get_updated_packages())

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/system.py", line 306, in get_updated_packages

    packages = self.get_new_packages(self.find_all_installed_packages(withVersion = False))

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/system.py", line 282, in get_new_packages

    inst = self.find_installed_packages(p)

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/system.py", line 176, in find_installed_packages

    return self.geneticize_list(t)

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/system.py", line 118, in geneticize_list

    return [package.PortagePackage(x) for x in list_of_packages]

  File "/usr/lib/python2.4/site-packages/portato/backend/portage/package.py", line 43, in __init__

    self._status = portage.getmaskingstatus(self.get_cpv(), settings = self._settings.settings)

  File "/usr/lib/portage/pym/portage.py", line 4945, in getmaskingstatus

    mygroups, eapi = portdb.aux_get(mycpv, ["KEYWORDS", "EAPI"])

  File "/usr/lib/portage/pym/portage.py", line 6218, in aux_get

    mydata = self.auxdb[mylocation][mycpv]

  File "/usr/lib/portage/pym/cache/sqlite.py", line 147, in __getitem__

    cursor.execute("select * from %s where %s=%s" % \

ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id -1211091280 and this is thread id -1242088560

----------

## Necoro

 *chesstux wrote:*   

> Hallo,
> 
> Ich hab jetzt auch portato ausprobiert. Ich bekomm aber immer einen Fehler, wenn ich z.B. mir die Updates anzeigen lassen will:
> 
> Exception im Thread "Show Updates Thread":
> ...

 

Das ist ein Portage-Bug mit dem SQLite backend. - Da kann ich mit Portato nix gegen tun (werde aber, so fern du nicht willst, das an die Portage Leute weiterleiten)

----------

## skibbi

Hab mal ne Feature Frage zu Portato

Und zwar gibt es ja mittelweile viele Meta-Packages im Potrage-Tree (z.B. xorg-x11, gnome, etc.), die viele Sachen installieren, die man dann im Falle der Deinstallation aber alle einzeln schön wieder entfernen darf. Gibt es vielleicht die Möglichkeit durch solche Pakte installierte Software beim löchen des Meta-Packages optional mit zu entfernen? Oder hab ich grundsätzlich was beim portage übersehen und das geht jetzt schon ohne große script-gebastel?

----------

## Knieper

Udept funktioniert ganz gut.

----------

## Necoro

```
emerge --ask --depclean
```

 =)

----------

## Necoro

Es gibt mal wieder ein neues Release. Dieses führt aber kaum neue Sachen ein (sorry wer schon länger auf ein bestimmtes Feature wartet ...):

Release 0.8.6:

"Portierung" auf Python-2.5  :Arrow:  es läuft nicht mehr mit python-2.4

"--with-bdeps=y" in EMERGE_DEFAULT_OPTS wird jetzt beachtet

Fixes in update world

der Exception-Dialog hat nun ein "Speichern unter"-Button =)

einige Buttons haben neue Labels und für einige hab ich auch Tooltips hinzugefügt

Sicherheitslücke geschlossen  :Arrow:  bei Portato-0.8.5 ist es möglich, Kommandos als User, der Portato ausführt, auszuführen (nur während Portato läuft)

Verbannung von portatosourceview und Verwendung von pygtksourceview stattdessen

----------

## franzf

 *Necoro wrote:*   

> [*]Verbannung von portatosourceview und Verwendung von pygtksourceview stattdessen[/list]

 

Und genau das will bei mir nicht :/

```
Making all in docs

make[2]: Entering directory `/var/tmp/portage/dev-python/pygtksourceview-2.0.0/work/pygtksourceview-2.0.0/docs'

/usr/bin/python -c 'import datetime; print datetime.date.today()' > reference/builddate.xml

xsltproc --nonet --xinclude -o ../docs/html/ \

                 --path ../docs/reference:./reference \

                 --stringparam gtkdoc.bookname "pygtksourceview2" \

                 --stringparam gtkdoc.version . \

                 /usr/share/pygobject/xsl/ref-html-style.xsl ./reference/gtksourceview2-ref.xml

I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl

warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"

compilation error: file /usr/share/pygobject/xsl/ref-html-style.xsl line 4 element import

xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl

make[2]: *** [build_stamp] Error 5

make[2]: Leaving directory `/var/tmp/portage/dev-python/pygtksourceview-2.0.0/work/pygtksourceview-2.0.0/docs'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/var/tmp/portage/dev-python/pygtksourceview-2.0.0/work/pygtksourceview-2.0.0'

make: *** [all] Error 2

 *

 * ERROR: dev-python/pygtksourceview-2.0.0 failed.
```

Bug ist reported...

Grüße

Franz

----------

## Necoro

Ein kurzes update auf 0.8.6.2 - beinhaltet nur einen Bugfix, so dass das "kde" useflag wieder funktioniert ...

----------

## franzf

 *franzf wrote:*   

> 
> 
> ```
> Making all in docs
> 
> ...

 

Hat denn keiner eine Idee?

Ich habs jetzt schon mit reemergen von python, diversen Python-Modulen, libxslt, glib, pygobject versucht, der Fehler bleibt :/

Die bemängelte Datei, welche aus dem Internet (was ich eigentlich ziemlich k**** finde), existiert und ich kann sie mit einem Browser o.Ä. auch betrachten...

Im Bugreport meldet sich auch keiner mehr.

Grüße

Franz

----------

## Necoro

Es fehlt eine Abhängigkeit (>=app-text/docbook-xsl-stylesheets-1.70.1). Wenn du das Paket installierst, findet er das File auf der Festplatte und muss es nicht mehr im Netz suchen (ich denke, dein IO-Error kommt daher, dass xsltproc mit --nonet aufgerufen wird und ihm das nachladen daher verbietet *rat*).

In deinem Bugreport hab ich mal einen Ebuild-Patch vorgeschlagen  :Smile: 

----------

## franzf

 *Necoro wrote:*   

> Es fehlt eine Abhängigkeit (>=app-text/docbook-xsl-stylesheets-1.70.1). Wenn du das Paket installierst, findet er das File auf der Festplatte und muss es nicht mehr im Netz suchen (ich denke, dein IO-Error kommt daher, dass xsltproc mit --nonet aufgerufen wird und ihm das nachladen daher verbietet *rat*).
> 
> In deinem Bugreport hab ich mal einen Ebuild-Patch vorgeschlagen 

 

Danke sehr für den ebuild-patch, ist schon auf meiner Platte  :Smile: 

Das erste was ich gemacht habe war das Makefile anzuschauen. Bin auch auf die Option "--nonet" gestoßen. Nur passiert überhaupt nix mehr, wenn ich die Option rausnehm, Ich warte eine Minutue und es geht nix vorwärts ^^

In jedem Fall hat es jetzt geklappt, mit und ohne "doc"  :Smile: 

Und Portato rennt auch wieder.

Ich hab auch schon geschaut, wie es im Moment mit den kdebindings für kde4 ausschaut. Das scheint für Python noch nix kompletto zu sein, also warten wir noch weiter auf den python-Konsole-part  :Smile: 

Grüße

Franz

----------

## Necoro

So meine lieben ...

der Onkel Necoro hat nach längerer Zeit mal wieder was neues zu vermelden ... ich habe ein wenig am design rumgebastelt. Daher wollte ich mal ein wenig nach Feedback fragen  :Smile: 

Die Screenshots gibt es hier: http://portato.origo.ethz.ch/wiki/New_Design

Wer es einmal ausprobieren möchte: http://download.origo.ethz.ch/portato/portato-new_design.tar.gz runterladen und entpacken  :Smile:  ... in dem entstandenen Verzeichnis denn ./portato.py -L ausführen. (Damit alle Abhängigkeiten vorhanden sind, empfielt es sich vorher portato normal zu emergen).

Also - wie findet ihr das neue Design?   :Cool: 

(Ach so: Die Version die ihr euch denn evtl runterladet kann recht buggy sein ... es geht hier vorrangig ums Design  :Wink: )

----------

## Necoro

Ok ... es gab einen kleinen Fehler im Paket ... (der dazu führte, dass es nicht startete)

Bitte noch einmal runterladen (Link ist der gleiche) ... aber zum Starten nun bitte ./run.sh ausführen ... es muss nämlich vor dem ersten start noch ein symlink gesetzt werden (ist zwar nur ein workaround -- aber normalerweise führt ja auch keiner das ganze als standalone aus  :Razz: )

----------

## genmich

Hi,

die Screenshots sehen gut aus! Ist der untere Bereich standardmäßig so hoch? Normalerweise ist ja die Portage Liste das interessanteste (und der meiste Text) also sollte dieser horizontale Bereich beim starten größer sein als die untere Hälfte.

Ich kann es leider nicht testen, da folgendes passiert:

```
./run.sh

  File "portato.py", line 15

    from __future__ import with_statement, absolute_import

SyntaxError: future feature with_statement is not defined
```

Wofür sind +/-/pfeil links in der Mitte? Können die auch in die gleiche Reihe wie emerge/unmerge/..., dann hättest du die Buttons alle in der gleichen Zeile

----------

## Necoro

 *miga wrote:*   

> Hi,
> 
> die Screenshots sehen gut aus! Ist der untere Bereich standardmäßig so hoch? Normalerweise ist ja die Portage Liste das interessanteste (und der meiste Text) also sollte dieser horizontale Bereich beim starten größer sein als die untere Hälfte.

 

Das ist ja variabel ... und in der neuen Version merkt sich die Anwendung auch, wie man das eingestellt hat  :Wink: 

 *Quote:*   

> Ich kann es leider nicht testen, da folgendes passiert:
> 
> ```
> ./run.sh
> 
> ...

 

Zu alte python version ;P (2.5 wird gebraucht)

 *Quote:*   

> Wofür sind +/-/pfeil links in der Mitte? Können die auch in die gleiche Reihe wie emerge/unmerge/..., dann hättest du die Buttons alle in der gleichen Zeile

 

Das +/-/Revert sind für das aktuell ausgewählte Paket ... die anderen Buttons beziehen sich auf die Queue (aka die Liste der zu installierenden Pakete)

----------

## franzf

Ich hatte Startprobleme. run.sh will einen symlink anlegen was er nicht kann da das Verzeichnis schon existiert (k.A. wieso selbst ln -snf will nicht). Also manuell gelöscht und gesymlinkt und alles geht prächtig  :Smile: 

Beziehen sich die von die angesprochenen Änderungen nur auf das Design des Frontends? Oder hast du auch am Backend "rumgepfuscht"?

Bei mir lässt sich die preview nicht horizontal verkleinern, erstreckt sich ohne Rücksicht auf meine Vorlieben über die ganze Breite  :Sad: 

Ansonsten: Die Teilung unten in 2 funktional getrennte Bereiche (Paketübersicht <-> emerge-queue/konsole) finde ich sehr gut! wenngleich die Tabs seitlich neben den Widgets zu viel Platz kosten. Geht es mit GTK diese auf Vertical zu drehen?

Ansonsten hier noch kleine Zusatzfunktionen, welche vllt ganz nett wären:

1) Wie wäre es mit einer einfachen Variante ebuilds automatisch ins Overlay zu packen und diese zu digesten? Würde vielen das Leben vereinfachen  :Smile: 

Man kann es ja so machen wie bei package.use usw: Optionen ob ebuilds in ein bereits existierendes Overlay gelegt werden sollen, ob ein Overlay speziell für Portato gewünscht wird oder ob bei jedem "ebuild"-Auftrag gefragt werden soll wo es denn jetzt in soll  :Smile: 

2) HTML-Info? Eine schön formatierte HTML-Ausgabe, welche einem Statisktiken bzgl. Portage/emerge/overlays/etc. anzeigt. Wäre in meinen Augen extrem nützlich und übersichtlich  :Smile: 

3) Wie wäre es mit einer (optionalen) Baumansicht? Das Dingens heißt ja auch Portage-Tree  :Wink:  Evtl. mögen das manche lieber (ich bin aber mit der jetzigen Darstellung recht zufrieden...)

4) Kann man bei einer Suche evtl. Einfach nur die Anzeige filtern? Also dass die Kategorien, welche keine entsprechenden Pakete enthalten ausgeblendet werden, und natürlich Pakete welche nicht auf die Suche passen.

5) Progress-Balken   :Very Happy: 

Mittels genlop (Portage bietet da wahrscheinlich selbst eine Funktion an) kann man ja die verstrichene mit der durchschnittlichen Bauzeit vergleichen und das irgendwo grafisch anzeigen  :Smile:  Würde einem zumindest einen Anhaltspunkt geben, wie lange man noch warten muss.

Zu guter letzt - das Qt-Frontend... Es war ja im Gespräch den Konsole-Part zu verwenden. Naja, die PyKDE4 ist nur ein Binding für die kdelibs - welche den konsole-part nicht enthalten :/ Wenn überhaupt wird das relativ spät kommen. Außerdem wird kde4 ja erst in späteren Versionen überhaupt mal testing  :Sad:  Man kann also noch recht lange warten auf diese Variante.

Eine Lösung in meinen Augen wäre vllt. an einem (minimalistischen) Port der Konsole auf Qt4 zu arbeiten, dafür dann Python-bindings zu schreiben (ich denke das ist effizienter als alles in Python selbst zu schreiben).

Oder hast du das Qt-Frontend schon komplett gestrichen?

Beste Grüße und weiter so!

Franz

----------

## Necoro

 *franzf wrote:*   

> Beziehen sich die von die angesprochenen Änderungen nur auf das Design des Frontends? Oder hast du auch am Backend "rumgepfuscht"?

 

Ich hab in zwei Branches gearbeitet ... also Frontendänderungen in einem anderen als Backendänderungen ... aber das Beispiel ist sowieso nur zum Anschauen gedacht  :Wink: 

 *Quote:*   

> Bei mir lässt sich die preview nicht horizontal verkleinern, erstreckt sich ohne Rücksicht auf meine Vorlieben über die ganze Breite 

 

Das ist ein komischer Bug bei manchen Paketen ... ich hab noch nicht rausgefunden woran es liegt

 *Quote:*   

> Ansonsten: Die Teilung unten in 2 funktional getrennte Bereiche (Paketübersicht <-> emerge-queue/konsole) finde ich sehr gut! wenngleich die Tabs seitlich neben den Widgets zu viel Platz kosten. Geht es mit GTK diese auf Vertical zu drehen?

 

Japp das geht ... aber wenn die vertikal sind, bringt man sie evtl leichter durcheinander ... Aber ich zieh es nochmal in Betracht  :Smile:  (bei mir fällt das nicht so auf ... mein Laptop kann nur 1400er Auflösung  :Wink: )

 *Quote:*   

> 1) Wie wäre es mit einer einfachen Variante ebuilds automatisch ins Overlay zu packen und diese zu digesten? Würde vielen das Leben vereinfachen 
> 
> Man kann es ja so machen wie bei package.use usw: Optionen ob ebuilds in ein bereits existierendes Overlay gelegt werden sollen, ob ein Overlay speziell für Portato gewünscht wird oder ob bei jedem "ebuild"-Auftrag gefragt werden soll wo es denn jetzt in soll 

 

Meinst du damit sowas wie ein "Öffnen"-Dialog in dem man das ebuild auswählen kann und es wird denn irgendwo hingelegt? - Oder dass man bestehende ebuilds in ein Overlay kopieren kann (was in meinen Augen relativ wenig Sinn macht, wenn man nicht auch einen Editor anbietet)

 *Quote:*   

> 2) HTML-Info? Eine schön formatierte HTML-Ausgabe, welche einem Statisktiken bzgl. Portage/emerge/overlays/etc. anzeigt. Wäre in meinen Augen extrem nützlich und übersichtlich 

 

In einem Bugtracker würde ich das mit "Wenn ein Patch eingereicht wird" markieren ... also wenn jmd das Statistik-Backend schreibt (Frontend wäre nicht unbedingt notwendig) gerne ^^... ansonsten: *auf das Plugin-System verweis* (auch wenn das noch ein wenig Feinschliff vertragen kann  :Smile: )

 *Quote:*   

> 3) Wie wäre es mit einer (optionalen) Baumansicht? Das Dingens heißt ja auch Portage-Tree  Evtl. mögen das manche lieber (ich bin aber mit der jetzigen Darstellung recht zufrieden...)

 

Hmm ... klingt nicht so als ob es übersichtlich wird  :Wink: 

 *Quote:*   

> 4) Kann man bei einer Suche evtl. Einfach nur die Anzeige filtern? Also dass die Kategorien, welche keine entsprechenden Pakete enthalten ausgeblendet werden, und natürlich Pakete welche nicht auf die Suche passen.

 

Ist geplant - ob ich es hinbekomme bis ins nächste Release weiß ich aber nicht

 *Quote:*   

> 5) Progress-Balken  
> 
> Mittels genlop (Portage bietet da wahrscheinlich selbst eine Funktion an) kann man ja die verstrichene mit der durchschnittlichen Bauzeit vergleichen und das irgendwo grafisch anzeigen  Würde einem zumindest einen Anhaltspunkt geben, wie lange man noch warten muss.

 

Eigentlich wollte ich warten bis moonitor fertig ist und das als Plugin anbieten ... ich muss mal nachhaken wie da der stand der dinge ist  :Smile: ...

 *Quote:*   

> Eine Lösung in meinen Augen wäre vllt. an einem (minimalistischen) Port der Konsole auf Qt4 zu arbeiten, dafür dann Python-bindings zu schreiben (ich denke das ist effizienter als alles in Python selbst zu schreiben).

 

Weißt du ob und wann ein Qt4-Konsole kommt? ... Weil dazu Bindings zu schreiben sollte nicht so schwierig sein. Aber die Konsole selber in C zu implementieren wird glaub ich sehr heftig ... (ich hatte mir mal den Konsole quellcode angeschaut ... und naja - die haben halt irgendwelche Black Magic gemacht ^^)

 *Quote:*   

> Oder hast du das Qt-Frontend schon komplett gestrichen?

 

Es gibt das qt-Frontend noch irgendwo - aber es ist schon länger nicht mehr gewartet - wird also ein wenig Arbeit es wieder auf den Stand der Dinge zu bringen...

Vielen Dank für deinen Input  :Smile:  ... das ist was womit man arbeiten kann  :Smile: 

----------

## franzf

 *Necoro wrote:*   

>  *Quote:*   1) Wie wäre es mit einer einfachen Variante ebuilds automatisch ins Overlay zu packen und diese zu digesten? Würde vielen das Leben vereinfachen 
> 
> Man kann es ja so machen wie bei package.use usw: Optionen ob ebuilds in ein bereits existierendes Overlay gelegt werden sollen, ob ein Overlay speziell für Portato gewünscht wird oder ob bei jedem "ebuild"-Auftrag gefragt werden soll wo es denn jetzt in soll  
> 
> Meinst du damit sowas wie ein "Öffnen"-Dialog in dem man das ebuild auswählen kann und es wird denn irgendwo hingelegt? - Oder dass man bestehende ebuilds in ein Overlay kopieren kann (was in meinen Augen relativ wenig Sinn macht, wenn man nicht auch einen Editor anbietet)

 

Ich dachte da tatsächlich an sowas wie nen "öffnen"-Dialog. So haben es die Leute leichter, die irgendwoher nen Link auf b.g.o haben und dann mit dem ebuild bzw. Overlay an sich wenig anfangen können. Oder für so faule S*** wie mich  :Wink: 

Optional wäre natürlich die Eingabe eines Links ins WWW, und portato zieht sich auch das ebuild noch automatisch.

Aber das ist eigentlich mehr eine Spielerei für später, wenn alles so funktioniert (und auch Funktionsumfang bietet) wie sich das der Herr Schäffartschitäkt so vorstellt  :Smile: 

 *Quote:*   

>  *Quote:*   2) HTML-Info? Eine schön formatierte HTML-Ausgabe, welche einem Statisktiken bzgl. Portage/emerge/overlays/etc. anzeigt. Wäre in meinen Augen extrem nützlich und übersichtlich  
> 
> In einem Bugtracker würde ich das mit "Wenn ein Patch eingereicht wird" markieren ... also wenn jmd das Statistik-Backend schreibt (Frontend wäre nicht unbedingt notwendig) gerne ^^... ansonsten: *auf das Plugin-System verweis* (auch wenn das noch ein wenig Feinschliff vertragen kann )

 

Hmmm, dann muss ich mir das ja mal anschaun  :Wink:  Hab ich aus dem Pluginsystem heraus auch Zugriff auf $BROWSER?

 *Quote:*   

>  *Quote:*   3) Wie wäre es mit einer (optionalen) Baumansicht? Das Dingens heißt ja auch Portage-Tree  Evtl. mögen das manche lieber (ich bin aber mit der jetzigen Darstellung recht zufrieden...) 
> 
> Hmm ... klingt nicht so als ob es übersichtlich wird 

 

War ja nur ein Gedanke...Es scheint ja auch Leute zu geben die einen Dateibrowser nur als solchen akzeptieren, wenn der eine "echte" Baumdarstellung kann  :Wink:  (Hat glaub ich bei dolphin gaaaanz böse Kommentare gegeben  :Wink: )

 *Quote:*   

>  *Quote:*   4) Kann man bei einer Suche evtl. Einfach nur die Anzeige filtern? Also dass die Kategorien, welche keine entsprechenden Pakete enthalten ausgeblendet werden, und natürlich Pakete welche nicht auf die Suche passen. 
> 
> Ist geplant - ob ich es hinbekomme bis ins nächste Release weiß ich aber nicht

 

Wunderbar  :Smile:  Macht das dann das Backend oder das Frontend? (Frage deshalb weil du vllt. auch an die ganzen neu aufkommenden Frontends denkst, welch dann das Filtern selbst implementieren müssten...  :Wink: )

 *Quote:*   

>  *Quote:*   5) Progress-Balken  
> 
> Mittels genlop (Portage bietet da wahrscheinlich selbst eine Funktion an) kann man ja die verstrichene mit der durchschnittlichen Bauzeit vergleichen und das irgendwo grafisch anzeigen  Würde einem zumindest einen Anhaltspunkt geben, wie lange man noch warten muss. 
> 
> Eigentlich wollte ich warten bis moonitor fertig ist und das als Plugin anbieten ... ich muss mal nachhaken wie da der stand der dinge ist ...

 

Feine Sache! Haben will  :Wink: 

 *Quote:*   

>  *Quote:*   Eine Lösung in meinen Augen wäre vllt. an einem (minimalistischen) Port der Konsole auf Qt4 zu arbeiten, dafür dann Python-bindings zu schreiben (ich denke das ist effizienter als alles in Python selbst zu schreiben). 
> 
> Weißt du ob und wann ein Qt4-Konsole kommt? ... Weil dazu Bindings zu schreiben sollte nicht so schwierig sein. Aber die Konsole selber in C zu implementieren wird glaub ich sehr heftig ... (ich hatte mir mal den Konsole quellcode angeschaut ... und naja - die haben halt irgendwelche Black Magic gemacht ^^)
> 
>  *Quote:*   Oder hast du das Qt-Frontend schon komplett gestrichen? 
> ...

 

Ich dachte da eigentlich auch eher an selber schreiben... So lange es nicht wirklich nen Konsole-Part gibt ist das wohl die einzige Lösung.

Halt, schnell Google anwerfen und finden:

http://lists.trolltech.com/qt-interest/2006-08/thread00505-0.html

QX11EmbedContainer  :Smile:  Damit kann man sich nen xterm in seine Qt-Application holen  :Smile:  Ist vllt. dann doch das schnellste...

Grüße

Franz

//edit:

Hab das dann doch noch heute schnell versucht - und es klappt  :Smile:   :Cool: 

Jetzt bräuchte man nur noch konkrete angaben deinerseits was das xterm alles können machen muss  :Smile:  (  :Arrow:  PM? Mail?)

----------

## Necoro

 *franzf wrote:*   

>  *Quote:*    *Quote:*   2) HTML-Info? Eine schön formatierte HTML-Ausgabe, welche einem Statisktiken bzgl. Portage/emerge/overlays/etc. anzeigt. Wäre in meinen Augen extrem nützlich und übersichtlich  
> 
> In einem Bugtracker würde ich das mit "Wenn ein Patch eingereicht wird" markieren ... also wenn jmd das Statistik-Backend schreibt (Frontend wäre nicht unbedingt notwendig) gerne ^^... ansonsten: *auf das Plugin-System verweis* (auch wenn das noch ein wenig Feinschliff vertragen kann ) 
> 
> Hmmm, dann muss ich mir das ja mal anschaun  Hab ich aus dem Pluginsystem heraus auch Zugriff auf $BROWSER?

 

Das Plugin kann so ziemlich alles machen was es will. Es ist quasi ne eigene Applikation, die zu bestimmten Zeitpunkten aufgerufen wird. Und je nach Zeitpunkt erhält sie noch bestimmte Infos.

 *Quote:*   

>  *Quote:*    *Quote:*   4) Kann man bei einer Suche evtl. Einfach nur die Anzeige filtern? Also dass die Kategorien, welche keine entsprechenden Pakete enthalten ausgeblendet werden, und natürlich Pakete welche nicht auf die Suche passen. 
> 
> Ist geplant - ob ich es hinbekomme bis ins nächste Release weiß ich aber nicht 
> 
> Wunderbar  Macht das dann das Backend oder das Frontend? (Frage deshalb weil du vllt. auch an die ganzen neu aufkommenden Frontends denkst, welch dann das Filtern selbst implementieren müssten... )

 

Das ist Sache des Frontends. Das Backend übernimmt zwar die Sache des Filterns insofern als dass es dir die entsprechenden Pakete liefert, auf die der String passt. Aber die Darstellung ist natürlich Frontend-Sache.

 *Quote:*   

> Halt, schnell Google anwerfen und finden:
> 
> http://lists.trolltech.com/qt-interest/2006-08/thread00505-0.html
> 
> QX11EmbedContainer  Damit kann man sich nen xterm in seine Qt-Application holen  Ist vllt. dann doch das schnellste...
> ...

 

Naja ... es bekommt ein Ende eines Pseudo-Terminals (sprich: pty) in dem viele Daten anliegen, die es darstellen muss ... Das ist die Grundbedingung - da es noch keine Unterstützung für interaktive Ebuilds gibt, muss die andere Richtung noch nicht implementiert werden - sollte aber net so schwer sein  :Wink: 

Ansonsten: Gerne Kontakt per Mail oder ICQ/Jabber/MSN  :Smile: 

----------

## genmich

 *Necoro wrote:*   

> Zu alte python version ;P (2.5 wird gebraucht)

 

Ist es ohne Probleme möglich auf 2.5 zu gehen? Bei mir ist immer noch 2.4.4-r6 als stable markiert. Nicht das nachher Portage nicht mehr geht! Würde Portato schon gerne mal testen, zumal kuroo bei mir nicht läuft  :Smile: 

----------

## Necoro

 *miga wrote:*   

>  *Necoro wrote:*   Zu alte python version ;P (2.5 wird gebraucht) 
> 
> Ist es ohne Probleme möglich auf 2.5 zu gehen? Bei mir ist immer noch 2.4.4-r6 als stable markiert. Nicht das nachher Portage nicht mehr geht! Würde Portato schon gerne mal testen, zumal kuroo bei mir nicht läuft 

 

Vorgehensweise:

- update world

- emerge -av python:2.5

- python-updater -i

- emerge -C python:2.4

- revdep-rebuild

- emerge -av portato

 :Smile:  ... Wenn du erst vor kurzem ein update world gemacht hast, kannst du es auch weglassen vorne. Ich will damit nur erreichen, dass die Aufgabe nicht vom python-updater übernommen wird ^^

----------

## genmich

Danke! Läuft jetzt.

Eine "All" Kategorie wäre nicht schlecht, wo man z.B. direkt alle installierten Pakete rechts sehen kann.

----------

## Necoro

in der aktuellen (also an der an der ich arbeite) gibt es die sicht "installed only" (Strg-I) ... wenn du dir die Design version mal anschaust - da sollte das auch gehen

----------

## genmich

Ja schon, aber du hast immer noch die Kategorien links, wo du rechts immer nur die Pakete zum gewählten Punkt siehst. Es gibt keine Möglichkeit alle Pakete direkt zu sehen (aus allen Kategorien)

----------

## Necoro

Naja ... aber wenn ich eine "ALL" kategorie einfüge, müssten die Pakete in der Paket-Ansicht die Kategorie vorne tragen -- und denn hättest du doch genauso viel gekonnt wie im Moment ... oder nicht *wunder*

----------

## genmich

Schöner wäre es dann so: 

All   |   programm (kategorie)

oder die Kategorie weglassen, da man die ja auch im unteren Bereich sieht

Ich kannte das nur früher von Kuroo (http://www.uni-koblenz.de/~soma/bldr/blog/kuroo.080b1.png), so konnte man schnell die Liste durchgehen und gucken was man deinstallieren konnte. So musste man nicht immer links eine neue Kategorie auswählen, sondern konnte schön rechts alles durchgehen.

----------

## Necoro

 *miga wrote:*   

> Schöner wäre es dann so: 
> 
> All   |   programm (kategorie)
> 
> oder die Kategorie weglassen, da man die ja auch im unteren Bereich sieht
> ...

 

Ok  :Smile:  ... ich werde es auf die TODO schreiben

/edit: implementiert (in svn)

----------

## Max Steel

Kannste nicht in diese installed ansicht so eine Art von dependencie Baum einbauen,

ich dachte mir das so das fettgedruckte in der world stehen, kursiv sind Systemsachen und alles so angeordnet wie ein Baum.

also

```
[i]portage

|-[i]python[/i]

||-[i]gcc[/i]

|-[i]glibc[/i]
```

oder so, wierum und so weiter muss ich nicht festlegen und will ich auch nicht.

----------

## Necoro

 *Max Steel wrote:*   

> Kannste nicht in diese installed ansicht so eine Art von dependencie Baum einbauen,
> 
> ich dachte mir das so das fettgedruckte in der world stehen, kursiv sind Systemsachen und alles so angeordnet wie ein Baum.
> 
> also
> ...

 

Das würde ich nicht in die installed ansicht reinbauen, sondern als extra fenster wenn dann. Ist aber ein wenig aufwendig, daher nicht in die aktuelle Version  :Wink: 

----------

## Necoro

Ok ... für alle, die das Risiko lieben  :Cool: : es gibt wieder was zu testen:

In Anbetracht des Näherrückens eines neuen Releases würde ich mich freuen, wenn sich einige Tester finden würden...

```
layman -f -o http://portato.sourceforge.net/layman.xml -a portato

emerge -av "=portato-0.8.9"
```

Diese Schritte sind notwendig um dieses nette Pre-Release zu installieren ... Die Changelog bis jetzt:

 *Quote:*   

> - added view for "installed only"
> 
> - removed "--ebuild" mode
> 
> - added log, ebuild, files, and changelog as tabs
> ...

 

Das neue Design ist das selbe wie schon vor einigen Posts gezeigt, aber mit franzfs Vorschlag die Tab-Reiter nach oben statt seitlich zu nehmen...

----------

## genmich

danke für das All  :Smile:  Genau so sollte es sein!

Ich hab allerdings ein kleines ergonomisches Problem:

die Buttons sind etwas verwirrend. Ich wollte ein Programm in die Unmerge-Queue aufnehmen und weiter gucken (also nicht direkt unmergen). Also hab ich das Programm markiert und auf "-Unmerge" geklickt. Was aber falsch war. Dann hab ich in der Queue "Unmerge" doppelgeklickt, selektiert und rechts, aber da war auch nix. Als ich die "+/-" Tasten gefunden habe wollte ich es mit + zur Unmerge Liste aufnehmen, ging aber zu Emerge. Dachte es war mein Fehler, also hab ich auf Emerge - Progammname - "-" geklickt um es zu entfernen und siehe da, es war in "Unmerge" aber immer noch in Emerge. Ich wusste zuerst nicht wie ich es aus der Emerge-Queue wieder rausnehmen konnte (Kontextmenü in der Queue wäre nicht schlecht), bis ich dann Remove unten rechts versucht hatte.

Zusammenfassend:

* ein Kontextmenü in der Queue wäre ganz gut: Add program to this queue, Remove program

* Drag&Drop in die Queue?

* Remove ist rechts unten, aber Add ist links oben (im unteren Teil der Fenster)

* der Button + ist irreführend. Ich dachte man könnte zur markierten Queue hinzufügen

* Tooltips auf den Buttons +/-/Rückgängig (ging bei mir übrigens nicht:

```
Traceback (most recent call last):

  File "/home/miga/portato/portato/gui/gtk/windows.py", line 755, in cb_package_revert_clicked

    self.versList.get_model().clear()

AttributeError: PackageTable instance has no attribute 'versList'
```

Kann auch an meinem Umgang mit dem Programm liegen, aber da ich es vorher noch nicht benutzt habe kamen die Probleme bei mir auf.

----------

## Necoro

 *miga wrote:*   

> danke für das All  Genau so sollte es sein!

  bitte  :Wink: 

 *Quote:*   

> Ich hab allerdings ein kleines ergonomisches Problem:
> 
> die Buttons sind etwas verwirrend. Ich wollte ein Programm in die Unmerge-Queue aufnehmen und weiter gucken (also nicht direkt unmergen). Also hab ich das Programm markiert und auf "-Unmerge" geklickt. Was aber falsch war. Dann hab ich in der Queue "Unmerge" doppelgeklickt, selektiert und rechts, aber da war auch nix. Als ich die "+/-" Tasten gefunden habe wollte ich es mit + zur Unmerge Liste aufnehmen, ging aber zu Emerge. Dachte es war mein Fehler, also hab ich auf Emerge - Progammname - "-" geklickt um es zu entfernen und siehe da, es war in "Unmerge" aber immer noch in Emerge. Ich wusste zuerst nicht wie ich es aus der Emerge-Queue wieder rausnehmen konnte (Kontextmenü in der Queue wäre nicht schlecht), bis ich dann Remove unten rechts versucht hatte.

 

Ich gebe zu: das ist alles wirklich etwas unergonomisch ... ich bin in das "will auf den Emerge-Button klicken anstatt auf das +" -Problem auch öfters gerannt ... da muss ich mir noch was einfallen

 *Quote:*   

> Rückgängig (ging bei mir übrigens nicht:
> 
> ```
> Traceback (most recent call last):
> 
> ...

 

Ok ... danke für den Hinweis =)

----------

## franzf

Noch eine Kleinigkeit zum Interface:

Ich denke es würde etwas "klarer" ausschauen, wenn die unteren Layouts symmetrisch wären. Soll heißen:

1) Tabs auf gleicher Höhe, also links und rechts oben. Zur Steigerung der Eindeutigkeit kannst du die Tabs auf der rechten Seite auch rechts anordnen.

2) Das "+, -, revert" unter das Tabwidget packen, in einer Zeile mit Name und Version des zu installierenden Pakets.

Und um dich nicht ganz zu verwirren hier ein kleiner Screenshot (Schnell mit dem Qt4-Designer gemurkst, aber was solls  :Wink: )

Grüße

Franz

----------

## Necoro

Das sieht in der Tat nett aus ... hat aber in meinen Augen zwei Nachteile:

1.) Der Paketname steht ganz unten ... das ist nicht so das wahre *find*

2.) Die "Emerge", "Unmerge", "Update World", "Remove" Knöpfe sind nur für das Queue-Tab. Sprich: Sie werden nicht im Konsolen-Tab benötigt...

Danke erstmal für die Idee ... ich hoffe, dass ich morgen dazu komme mal das Design zu überdenken  :Smile: 

----------

## franzf

Ich hab die Tabs unten angeordnet und und die Tabs rechts gefüllt  :Wink: 

Hier gleich das Designer Ui.

Wenn man das Spacing der Layouts ändert schauts auch nochmal besser aus  :Wink: 

----------

## Necoro

 *franzf wrote:*   

> Ich hab die Tabs unten angeordnet und und die Tabs rechts gefüllt 
> 
> Hier gleich das Designer Ui.

 

Sauber  :Smile:  ... danke  :Smile:  So sieht das wirklich besser aus

----------

## franzf

 *Necoro wrote:*   

>  *franzf wrote:*   Ich hab die Tabs unten angeordnet und und die Tabs rechts gefüllt 
> 
> Hier gleich das Designer Ui. 
> 
> Sauber  ... danke  So sieht das wirklich besser aus

 

Bitte, bitte, mach ich doch gern  :Smile: 

Ich hab mir auch extra noch glade installiert, aber leider komm ich so auf die Schnelle nicht damit klar... Sonst hätte ich dir gleich das gladefile geschickt...

----------

## Necoro

Soo... es gibt ein Update des Prereleases  :Smile:  (0.8.9.1)

Ich habe das Design noch einmal ein wenig überarbeitet:

1.) Da ich nicht wusste wie ich die Tabs am dümmsten anordne, hab ich das einfach mal dem User überlassen ... es ist unter Einstellungen einstellbar ^^

2.) Die andere Modifikationen hab ich von franzf übernommen  :Smile: 

3.) Ich habe an vielen Stellen "Emerge" und "Unmerge" durch "Install" und "Deinstall" ersetzt ^^ - "Emerge" meint jetzt nur noch den Vorgang des "tu mal was mit den paketen" an sich

4.) Queues werden jetzt dynamisch angelegt. Sprich: Die Emer^WInstall-Queue existiert erst, wenn man ein Paket zum installieren auswählt. Ferner wurde neben den zwei schon bestehenden noch eine dritte (Update) hinzugefügt. Diese wird fürs "Update World" genutzt.

Die Installation/Deinstallation erfolgt nun nicht mehr über einen Button "Emerge" / "Unmerge", da dies irgendwie Verdopplung war. Stattdessen gibt es nun den Button "Execute", welcher eine gewählte Queue "ausführt".

Dies erlaubt nun mehrere Queues in parallel zu betreiben und diese getrennt auszuführen. In Theorie wären damit auch mehrere "Install"-Queues denkbar.

Mit der Einführung der Update-Queue ist auch ein anderes Feature besser nutzbar (welches es schon länger gibt): Queues werden sequentiell abgearbeitet: Sprich wenn ich eine Queue ausführe kann ich eine weitere ausführen noch während die erste läuft. Die zweite bekommt denn den Status "In Progress" und wird gestartet nach dem die andere fertig ist.

Damit wäre es zum Beispiel möglich:

1.) Ein Stapel Pakete zu deinstallieren.

2.) Nebenbei ein update world fahren. Wenn auch dieses beendet ist, die Queue ausführen. (Da die in der Update-World-Queue angezeigten Pakete nur zur Info sind und nicht direkt übergeben werden stört es auch nicht wenn dort Pakete vorkommen die man im ersten schritt gerade dabei ist zu entfernen ^^)

3.) Einige Paktete installieren.

4.) Ins Bett gehen und wissen, dass die Deinstall/Update/Install Queues in dieser Reihenfolge ausgeführt werden  :Smile: 

Hinweis: Es ist möglich Pakete zu einer Queue hinzuzufügen, die als "In Progress" markiert ist. Bitte nicht machen ;P. Wenns doch mal passiert: Das hinzugefügte Paket schnell wieder löschen bevor die Queue zur Ausführung kommt  :Smile: 

So ... ich hoffe ich habe jetzt alle ein wenig verwirrt ... und freue mich auf Input  :Smile: 

P.S.:

Folgendes muss noch gemacht werden vor dem Release:

- warten auf die Catalan-Übersetzung

- hinzufügen von franzf zur Authors Datei ^^

- fixes im update world

- ... zu kommende bugs fixen

----------

## franzf

 *Necoro wrote:*   

> Folgendes muss noch gemacht werden vor dem Release:
> 
> - warten auf die Catalan-Übersetzung
> 
> - hinzufügen von franzf zur Authors Datei ^^
> ...

 

Guibeispiel != Code != Author => Danke trotzdem für die Blumen in 2)  :Smile: 

Zu Punkt 4... Will ich dich gleich beglücken...

Wollt ich mal schnell mit eric-4.0.4 ausprobieren. Da will der Installer am Schluss eine Datei (pyxml) patchen, frägt den User ob er das darf. Egal was ich mache - es geht nix weiter ^^

Liegt das evtl. am VTE? Mag der keinen User-Input?

Ansonsten gefällt mir dein Programm immer besser, freu mich wenn das mal als Stable in Portage ist (evtl. sogar als default im Handbook? ok... aber auf den Gui-Installer könntest du es schon schaffen  :Wink: )!

Grüße

Franz

----------

## LinuxTom

Ich würde es ja auch gerne mal ausprobieren und habe es installiert. Aber die Version 0.8.6.2. Beim Start kommt jedoch immer

```
'gtk' sollte installiert sein, aber das Einbinden schlug fehl. Das ist definitiv ein Bug. (No module named gtk)
```

Welche Einstellung ist da bei mir falsch?

----------

## Necoro

 *LinuxTom wrote:*   

> Ich würde es ja auch gerne mal ausprobieren und habe es installiert. Aber die Version 0.8.6.2. Beim Start kommt jedoch immer
> 
> ```
> 'gtk' sollte installiert sein, aber das Einbinden schlug fehl. Das ist definitiv ein Bug. (No module named gtk)
> ```
> ...

 

Du hast portato installiert ... dabei wurde python geupdated (auf 2.5) und du hast nicht dran gedacht python-updater -i laufen zu lassen  :Smile:  Hol das einfach nach  :Smile: 

@franzf: Das mit den interaktiven ebuilds werde ich heute einfach mal versuchen zu implementieren  :Smile:  ...

----------

## franzf

Noch ein kleiner Fehler:

app-cdr/k3b steht bei mir in der package.keywords, installiert ist 1.0.4. Diese ist bereits stabil. Trotzdem zeigt mir portato das Häkchen an bei "Testing" (wegen dem Eintrag in package.keywords?).

Wenn ich das Häkchen weg mach krieg ich einen IndexError und die Gui friert ein (komisch, Zweiteres war wohl nur beim ersten Mal so  :Wink: )

```
Traceback (most recent call last):

  File "/usr/lib64/python2.5/site-packages/portato/gui/gtk/windows.py", line 824, in cb_testing_toggled

    self.actual_package().set_testing(False)

  File "/usr/lib64/python2.5/site-packages/portato/backend/package.py", line 42, in set_testing

    flags.set_testing(self, enable)

  File "/usr/lib64/python2.5/site-packages/portato/backend/flags.py", line 665, in set_testing

    if pkg.matches(crit) and flags[0] == "~"+arch:

IndexError: list index out of range
```

Allerdings ist k3b das einzige Programm welches ich bisher finden konnte, das so reagiert...

Hab auch extra ein eix-sync eingeschoben (mit portato  :Wink: )

Außerdem hast du noch ein Problem mit "Expanded Use-Flags" (z.B. linguas):

```
/usr/lib64/python2.5/site-packages/portato/gui/gtk/windows.py:1644: GtkWarning: Failed to set text from markup due to error parsing markup: Fehler in Zeile 1, Zeichen 72: UngÃŒltiger UTF-8-kodierter Text - Â»<i>Dies ist ein "Expanded Use Flag" und kann daher nicht ausgewählt werden.</i>Â« ist nicht gÃŒltig

  gtk.main()
```

----------

## Necoro

 *franzf wrote:*   

> Noch ein kleiner Fehler:
> 
> app-cdr/k3b steht bei mir in der package.keywords, installiert ist 1.0.4. Diese ist bereits stabil. Trotzdem zeigt mir portato das Häkchen an bei "Testing" (wegen dem Eintrag in package.keywords?).
> 
> Wenn ich das Häkchen weg mach krieg ich einen IndexError und die Gui friert ein (komisch, Zweiteres war wohl nur beim ersten Mal so )
> ...

 

Ich schau mal  :Smile: 

 *Quote:*   

> Außerdem hast du noch ein Problem mit "Expanded Use-Flags" (z.B. linguas):
> 
> ```
> /usr/lib64/python2.5/site-packages/portato/gui/gtk/windows.py:1644: GtkWarning: Failed to set text from markup due to error parsing markup: Fehler in Zeile 1, Zeichen 72: UngÃŒltiger UTF-8-kodierter Text - Â»<i>Dies ist ein "Expanded Use Flag" und kann daher nicht ausgewählt werden.</i>Â« ist nicht gÃŒltig
> 
> ...

 

Hmm ... komisch. Kann ich nicht reproduzieren... Und auch sonst ... Zeichen 72 ist ein 'd'

/edit: Als workaround kannst du portato ja ersteinmal mit "-nls" emergen

----------

## Necoro

Und mal wieder ein Update (auf 0.8.9.2):

Ich hatte heute ein wenig (viel) Zeit und konnte einige Sachen implementieren:

1.) Interaktive Emerges  :Smile: 

2.) Das schon lange geforderte Feature nur die Sachen aus der Queue zu entfernen die wirklich schon emerget wurden ^^. Das ist nun umgesetzt. Kleine Einschränkung: Es wird etwas entfernt, kurz nachdem es anfängt zu emergen... (obwohl ... das andere wäre sinniger ... also morgen nochmal ein wenig abändern)

@franzf: Deinen Fehler mit k3b konnte ich nicht reproduzieren...

/edit:

@franzf: Kann es sein, dass du eine Zeile in der package.keywords hast, die nur aus dem Paketnamen besteht? Sprich das "~amd64" fehlt?...

Ansonsten: Könntest du den Fehler nochmal reproduzieren? - Als debug meldung sollte kurz vorher: "data (test): ..." auftauchen - das mal bitte posten  :Smile: 

----------

## franzf

So, hab das nochmal ausprobiert.

```
* data (test): [('/etc/portage/package.keywords/app-cdr', '1', 'app-cdr/k3b', ['~amd64'])] (flags.py:663)

* newTesting: {'app-cdr/k3b-1.0.4': [('/etc/portage/package.keywords/app-cdr', '1')]} (flags.py:675)
```

Kommt raus wenn ich in der package.keywords das ~amd64 ranhäng.

Kleiner Teilerfolg: Zwar ist es immer noch angekreuzt, aber ich kann es nicht mehr wegmachen  :Very Happy: 

Was in jedem Fall komisch ist, dass auch wenn ich es auskommentiere oder komplett den Eintrag lösche - hilft alles nix :/ Die 1.0.4 wird weiterhin als "Testing" angehakt.

Komisch ist dass nur k3b so reagiert...

Z.B. media-sound/lilypond funktioniert fabulös! Auch ohne "~amd64" angehangen.

Wenn das ein Problem ist welches nur ich hab soll dich das von einem Release nicht abhalten  :Smile: 

BTW. hat Eric4 jetzt perfekt emerged  :Smile:  Thx!

----------

## Necoro

Hast du es vielleicht noch in einem Overlay? In dem es testing ist? (Denn sollte bei Portato eigentlich zwar ein Overlay-Pfad mit angegeben sein - aber man weiß ja nie^^)...

Ansonsten: Das Weglassen des "~amd64" wird nich wirklich supported von Portato (vllt sollte ich das mal ändern -- dazu müsste ich aber den Code besser verstehen^^)

----------

## Necoro

 *Necoro wrote:*   

> 2.) Das schon lange geforderte Feature nur die Sachen aus der Queue zu entfernen die wirklich schon emerget wurden ^^. Das ist nun umgesetzt. Kleine Einschränkung: Es wird etwas entfernt, kurz nachdem es anfängt zu emergen... (obwohl ... das andere wäre sinniger ... also morgen nochmal ein wenig abändern)

 

So ... das ist getan  :Smile:  ... und damit auch wieder ein neues Prerelease: 0.8.9.3 ...

Es enthält noch einige Bugfixe für Sachen die mir ins Auge gesprungen sind (da waren schon einige böse dabei)...

Wenn ich morgen nicht noch viel Langeweile hab sollte das wenn möglich das letze Prerelease werden ^^ ...

ETA des endgültigen Releases: 25.01. ... Bugs bitte melden auf dass sie bis dato noch gefixt werden  :Smile: 

----------

## franzf

Mit einem Bug werd ich nimmer fertig :/

Wenn ich das erste mal (also ohne bestehender .portato/gtk_session.cfg) portato starte läuft das Fenster Amok... Das vergrößert sich unaufhörlich horizontal, ich kann nicht eingreifen und es auch nicht stopen, muss immer mit xkill ran  :Sad: 

Grüße

Franz

// edit:

hab das mal aufgenommen...

----------

## Necoro

Das ist ein GTK-Bug... in dem neuen Prerelease betraf einer der Bugfixes genau den.... aber scheinbar konnte ich ihn immer noch nicht umgehen...

Der Bug tritt auf, wenn ein Paned etwas verdeckt was nicht kleiner werden kann... hier ist der Paned zwischen den beiden Notebooks, der unten den Dateien-Tab verdeckt.

Workaround:

Variante 1) Wenn es startet und während es sich vergrößert einfach den Schieber unten nehmen und dem Dateien-Tab genug Lebensraum geben ^^ ... denn wird das Fenster automatisch wieder kleiner  :Smile: 

Variante 2) in der portato.cfg die Tabposition für das PackageNotebook auf "3" (left) setzen...

/edit: Hab mal einen "Fix" ins SVN geladen ... die Standardposition ist jetzt weiter rechts ... Kannst du mal schauen ob es denn bei dir passt?

----------

## franzf

 *Necoro wrote:*   

> /edit: Hab mal einen "Fix" ins SVN geladen ... die Standardposition ist jetzt weiter rechts ... Kannst du mal schauen ob es denn bei dir passt?

 

Dankeschön, damit passiert das nimmer, wenn ich portato das erste mal starte.

Ich habs auch mal ausprobiert für gtk-apps eine Fontsize von 24  :Very Happy:  auch hier passt sich die Größe des linken Fensters an, also sollte es jetzt passen (solange niemand auf die Idee kommt das mal manuell anzupassen...

Um mal einen Kommentar aus dem qt-branch etwas modifiziert zu zitieren:

 *Quote:*   

> gtk sucks =(

 

 :Very Happy: 

Thx und Grüße

Franz

----------

## Necoro

 *franzf wrote:*   

>  *Quote:*   gtk sucks =( 

 

Aber nicht ganz so häufig wie Qt ^^   :Cool: 

----------

## franzf

Ein weitere Alternative:

Im portato.glade für das packageNotebook die Option Scrollbar auf "ja".

Damit sollte doch der Effekt umgangen werden können, oder?

edit://

1) Option heißt "Rollbar"

2) Es funktioniert :=)

----------

## Necoro

 *franzf wrote:*   

> Ein weitere Alternative:
> 
> Im portato.glade für das packageNotebook die Option Scrollbar auf "ja".
> 
> Damit sollte doch der Effekt umgangen werden können, oder?
> ...

 

Hey  - danke  :Smile: 

----------

## LinuxTom

 *Necoro wrote:*   

>  *LinuxTom wrote:*   Ich würde es ja auch gerne mal ausprobieren und habe es installiert. Aber die Version 0.8.6.2. Beim Start kommt jedoch immer
> 
> ```
> 'gtk' sollte installiert sein, aber das Einbinden schlug fehl. Das ist definitiv ein Bug. (No module named gtk)
> ```
> ...

 

Danke, das war es.  :Smile: 

----------

## franzf

 *Necoro wrote:*   

>  *miga wrote:*    *Necoro wrote:*   Zu alte python version ;P (2.5 wird gebraucht) 
> 
> Ist es ohne Probleme möglich auf 2.5 zu gehen? Bei mir ist immer noch 2.4.4-r6 als stable markiert. Nicht das nachher Portage nicht mehr geht! Würde Portato schon gerne mal testen, zumal kuroo bei mir nicht läuft  
> 
> Vorgehensweise:
> ...

 

Nach dem Unmergen von python:2.4 wollte mir portage dieses bei jedem update neu draufhauen, hat aber nicht angezeigt warum, selbst mit --tree.

Dafür hab ich schnell 

```
echo "dev-lang/python:2.4" >> /etc/portage/package.mask/dev-lang
```

gemacht und schon wurde mir der Schuldige preisgegebenen:

dev-libs/boost

Ich musste mir die 1.34.1-r1 un-keyworden und schon klappte alles wieder bestens  :Smile: 

Wollte ich nur mal gesagt haben für evtl. Konfusionierte  :Wink: 

----------

## franzf

Noch eine Kleinigkeit die mich manchmal schon irritiert hat:

Ich rolle gerne die Fenster hoch um einen schnellen Blick auf das darunter liegende Fenster zu werfen. Wenn ich in den Optionen "minimiere zu Systray" aktiviere ist bei dieser Gelegenheit das Fenster futsch :/ Das resultiert in unnötig langen zusätzlichen Mauswegen  :Wink: 

Kann man dieses Verhalten irgendwie abschalten? Falls es aber gewünscht ist evtl. einen Punkt in die Einstellungen?

----------

## Necoro

Lässt sich bestimmt einrichten ...  :Smile: 

----------

## LinuxTom

Habe das erste Mal mit Portato gespielt. Allerdings mit der stabilen Version 0.8.6.2. Und habe gleich 'ne Frage:

Ich kenne es, dass "emerge -uND world" nicht alle Pakete updated werden und man diese mit "emerge -pve world" herausfinden kann. Das Portato diese gleich findet ist gut, aber es will bei mir noch einige andere Pakete erneut installieren (nur bei "Update World-Taste") und ich finde nicht heraus warum. Kann mir jemand einen Tipp geben?

So z.B. "will" Portato bei mir lua-5.1.1-r2 updaten ("zeige Pakete mit Updates"). Ok, lass ich es, es ist ja auch die stabilste höchste Version. Nach der Installation will Portato zusätzlich in einem nächsten Schritt wieder lua-5.0.2 installieren (für die mysql-gui-tools). Das reine "emerge" will aber die Version 5.1.1.-r2 löschen und die 5.0.2 drauf bringen.

Nach einem "revdep-rebuild" wurden mir automatisch die mysql-gui-tools neu installiert und dabei gleich die lua-Version wieder runter gesetzt.

Ok, Portato neu gestartet und die Ausgabe von "zeige Pakete mit Updates" ignoriert, denn da steht ja wieder lua drin. Aber trotzdem will er mir wieder die mysql-gui-tools installieren und ich erkenne nicht warum (diesmal aber ohne lua). Kann mir mal bitte jemand helfen?

EDIT:

Habe den Fehler gefunden, aber noch nicht die Ursage: "emerge" erkennt, dass ich die USE-Flags "administrator" und "query-browser" gesetzt habe und Portato nicht.  :Sad: 

----------

## Necoro

Ok ...

1.) die "Update World"-Funktion wurde jetzt für das neue Release ein wenig überholt - sie war nicht mehr ganz auf dem Stand der Zeit  :Wink: 

Insofern ist es gut möglich, dass sich das was Portato anzeigt und das was Portage macht unterscheidet.

2.) "Zeige Pakete mit Updates" wiederum ist was ganz anderes: Das listet einfach nur alle Pakete auf, für die es eine neue Version gibt (die auch installierbar wäre ohne was an den keywords/masking zu drehen). Es berücksichtigt aber nicht die eventuellen Abhängigkeiten anderer Pakete auf eine ältere Version.

/edit: Wegen den Useflags ... ähm ...   :Shocked: 

----------

## LinuxTom

Also sollte ich welche Version von Portato jetzt nehmen (und wie)?

 *Necoro wrote:*   

> /edit: Wegen den Useflags ... ähm ...  

 

Tja, großen Problem. Wenn ich mir das ebuild anschaue steht dort

```
IUSE="nls +administrator +query-browser workbench"
```

drin. Und das "+" vor den USE-Flags scheint das Problem zu sein. Ist bestimmt vom ebuild nicht korrekt, aber emerge macht es nun mal trotzdem richtig. Schau mal bei wine und beagle nach. Das Gleiche.

Edit:

Es wird wohl nach dem USE-Flag (incl. dem "+") gesucht und nicht gefunden.  :Wink: 

----------

## Necoro

Ah ... ok ... UseFlag-Defaults werden erst in der neuen Version unterstützt  :Smile: 

also:

```
layman -f -o http://portato.sf.net/layman.xml -a portato

emerge -av "=portato-0.8.9.3"
```

Alternativ einfach bis nächste Woche warten bis das nächste Release draußen ist (und denn auch in Portage)

----------

## LinuxTom

Grusliges Verhalten:

nach dem Start von portato-0.8.9.3 fließt das Fenster in die Breite. Ich kann es nur aufhalten, wenn ich es kurz verschiebe. Danach ist erst einmal wieder Ruhe. Versuche ich das Fenster in der Größe wieder zu ändern, dito. Das ist aber nur, wenn ich die Pakettabs unten/oben platzieren lasse. Lasse ich sie rechts/links platzieren, ist alles in Ordnung.

----------

## Necoro

Siehe ein paar Posts vor dir  :Smile:  Das ist gefixt, hab deswegen aber kein neues Prerelease gemacht...

----------

## Necoro

Da haben wir es denn:

Release 0.9.0

Changelog:

Neues Design und Handling

"Installed only" Ansicht

Neue Paketdaten-Tabs

Speicherung von Sessions

Korrekte Behandlung von use-defaults

Möglichkeit Plugins permanent an- oder abzustellen

Eine Kategorie "ALL" hinzugefügt

Interaktive Emerges

Nur bereits fertig installierte Pakete löschen

"Update World" besser gemacht  :Smile: 

Polnische Übersetzung hinzugefügt (by Tomasz Osiński)

Resume-Loop- und Shutdown-Plugin entfernt (buggy)

In einigen Tagen sollte es auch im Portage-Tree eintreffen  :Smile: 

----------

## return13

Verwende zur Zeit 0.9.0.2 - scheint jedoch noch ein wenig buggy zu sein - meine damit die veränderung der Größe des Fensters - welches bei machen Paketen unaufhörlich nach rechts wächst...

Ansonsten ist es recht gelungen.

Vielleicht noch als Feature request - ist es möglich die Zeit anzuzeigen die der emerge wahrscheinlich noch braucht?

Das wäre z.B. möglich, in dem man die werte von 'genlop -t' der einzelnen Pakete, die noch laufen, summiert und von der laufdauer abzieht, oder ähnliches...

Gruß

return13

----------

## Necoro

 *return13 wrote:*   

> Verwende zur Zeit 0.9.0.2 - scheint jedoch noch ein wenig buggy zu sein - meine damit die veränderung der Größe des Fensters - welches bei machen Paketen unaufhörlich nach rechts wächst...
> 
> Ansonsten ist es recht gelungen.

 

Versuche mal 0.9.0.3 aus dem Overlay. Das sollte das Problem nicht mehr haben  :Smile: 

----------

## Necoro

Es ist wieder geschafft ... ein neues Portato-Release hat das Licht der Welt erblickt  :Smile: : 0.10

Doch damit die ersten Laufbemühungen nicht in einem Desaster enden - vorher eine Woche Beta-Test:

Zum installieren der Version:

```
layman -o http://portato.sf.net/layman.xml -f -a portato

emerge -av "=portato-0.10_beta"
```

Kleiner Hinweis: Um mir dauerndes Packen zu sparen, ist dies ein Live-Ebuild. Sprich: Es lädt direkt aus dem Bzr-Branch den Code. Damit evtl Änderungen/Fixes im Code aber trotzdem bei jedem ankommen, wird ein Plugin mitgeliefert, was ein Popup aufmacht, so bald eine neue Revision eingecheckt ist  :Smile: . Dann muss man nur noch mit emerge -av "=portato-0.10_beta" das Paket neu fetchen und installieren  :Smile: 

So - nun aber die wichtigen Sachen: Das Changelog:

NEU: interaktive Suche - Ergebnisse erscheinen während des Tippens

NEU: Liste der Useflags wird im "Allgemein"-Tab mit angezeigt

NEU: Tab mit der Auflistung der Abhängigkeiten eines Pakets

NEU: in der Versionsliste werden auf Wunsch die Slots mit angezeigt

I18N: es gibt jetzt Portato auch auf Türkisch  :Smile: 

FIX: die ganzen Käfer, welche dazu geführt haben, das in 0.9.0.x eventuell das Fenster sich bis ins Unendliche vergrößert haben sollten erschlagen worden sein

REGRESSION: GTK ist jetzt das einzige unterstütze Frontend

/edit: Vergessen: Auch NEU: Beim Auftreten einer Exception werden automatisch alle wichtigen Versions-Informationen mit ausgegeben. Das sollte das Filen von Bugs erleichtern (vorausgesetzt, man kopiert sie mit)

----------

## return13

sieht ja mittlerweile richtig professionell aus...

----------

## Necoro

Das Release steht  :Smile: . Es gab noch einige Fixes und kleine Änderungen. Jetzt warten wir darauf, dass es irgendwann im Tree landet  :Smile:  - im Overlay ist das Ebuild bereits.

----------

## Necoro

Ok - ist im portage tree angekommen ... Danke an jokey  :Smile: 

----------

## f1fth_freed0m

Hi,

wollte mal Fragen wie es eigendlich mit der Unterstützung für paludis ausschaut und ne Anmerkung zur Optik machen.

Wenn man ein dunkles Theme hat gibt es einige Probleme mit der Lesbarkeit. Hab mal 2 Screenshots gemacht.

http://img169.imageshack.us/img169/7752/portato1fy6.png

http://img169.imageshack.us/img169/2269/portato2km0.png

Aber sonst nettes Programm

Bye

----------

## Necoro

 *f1fth_freed0m wrote:*   

> wollte mal Fragen wie es eigendlich mit der Unterstützung für paludis ausschaut

 

schlecht bis sehr schlecht. s. Thread: http://archives.gentoo.org/gentoo-guis/msg_05789f7c42f85c698453da9e5ac26f5a.xml

(Anm: Catapult war mal ne Idee von mir, um eine einheitliche API zu den Paketmanagern zu schaffen.) -- kurz: mir fehlt einfach die Zeit, um die galaktischen Paludis-Anforderungen umzusetzen

 *Quote:*   

> und ne Anmerkung zur Optik machen.

 

Jau ... ich war ja auch dumm und hab das weiß / das gelb direkt im Quellcode gesetzt ... sollte ich mal ändern  :Smile:  Danke für den Hinweis

 *Quote:*   

> Aber sonst nettes Programm

 

Merci  :Smile: 

----------

## Necoro

Ein neues Release wartet am Horizont  :Smile:  ...

wichtigste Änderungen:

Portage-2.2 Support

Komplett neu geschriebenes Plugin-System

Möglichkeit aus dem Programm heraus einen Bug direkt zu mailen

Die Sache mit den Farben (s.o.) ist auch gefixt  :Smile: 

----------

## Dirk_G

Hi Necoro

Könntest du mal die folgenden Zeilen der Konfig etwas genauer beschreiben! Wenn ich das doch richtig verstehe wird, sofern package.* ein Verzeichnis ist eine Datei angelegt die u.a. den Paketname hat. Aber was genau muss da stehen damit das auch passiert?

```
; control the name of the particular file if package.* is a directory - string $

; allowed placeholders:

;               - $(pkg) : package-name

;               - $(cat) : category-name

;               - $(cat-1)/$(cat-2) : first/second part of the category name

usefile = portato

maskfile = portato

keywordfile = portato
```

Egal was ich dort eintrage es wird immer eine Datei erzeugt die genau so heißt wie ich es dort eintrage. Eine Zeile mit  keywordfile = $(pkg) z.B. erzeugt eine Datei namens $(pkg) und nicht eine mit dem Paketnamen! Ich möchte aber eine Datei die so heißt wie das Paket. Am besten noch mit Versionsnummer.

cu

Dirk

PS: Ich nutze übrigens die Version 0.10 aber die 9999 macht es auch nicht.

----------

## Necoro

Danke für den Hinweis. In dem Bereich scheint richtig was kaputt zu sein. Beim durchschauen sind mir noch ein ganzer Stapel anderer Bugs dazu aufgefallen... Da ich das nie nutze, war mir das nie bewusst  :Smile: 

Also danke *mal überarbeiten muss*

/edit: Ab Revision 275 sollte es wieder funktionieren  :Smile: . In rev. 276 wurde auch $(version) eingeführt  :Smile: 

----------

## Dirk_G

Hi wieder

Das ging ja mal super schnell mit dem Bugfix, danke. Ich hätte da aber noch eine dumme Frage. Wenn sowas kommt wie

```
 Exception im Thread "Waiting Thread #1 (called by:<bound method EmergeQueue.sync of <portato.gui.queue.EmergeQueue instance at 0x8a6a2cc>>)":

Traceback (most recent call last):

  File "/usr/lib/python2.5/site-packages/portato/gui/utils.py", line 42, in run

    Thread.run(self)

  File "/usr/lib/python2.5/threading.py", line 446, in run

    self.__target(*self.__args, **self.__kwargs)

  File "/usr/lib/python2.5/site-packages/portato/gui/queue.py", line 415, in __emerge

    sub_emerge(command)

  File "/usr/lib/python2.5/site-packages/portato/plugin.py", line 415, in wrapper

    ret = func(*args, **kwargs)

  File "/usr/lib/python2.5/site-packages/portato/gui/queue.py", line 413, in sub_emerge

    update_packages()

  File "/usr/lib/python2.5/site-packages/portato/plugin.py", line 409, in wrapper

    call.call(*hargs, **hkwargs)

  File "/usr/share/portato/plugins/notify.py", line 47, in notify

    get_listener().send_notify(base = text, descr = descr, icon = icon, urgency = urgency)

  File "/usr/lib/python2.5/site-packages/portato/plistener.py", line 120, in send_notify

    self.__send(string)

  File "/usr/lib/python2.5/site-packages/portato/plistener.py", line 101, in __send

    self._rw.P()

  File "/usr/lib/python2.5/site-packages/shm_wrapper.py", line 230, in P

    self._SemaphoreHandle.P()

shm.error: can't access semaphore

Portato version: 9999 rev. 276

Python version: 2.5.2 (r252:60911, Jul 18 2008, 23:14:11) 

[GCC 4.1.2 (Gentoo 4.1.2 p1.1)]

Used backend: Portage 2.1.4.4

pygtk: 2.12.0 (using GTK+: 2.12.9)

pygobject: 2.14.1 (using GLib: 2.16.3)
```

wird man ja gefragt ob man es an den Entwickler schicken möchte. Klar, wieso nicht aber wie oft sollte man das machen;) Immer, auch wenn der Fehler bzw. die Ursache die gleiche ist oder nur einmal? Wo schickt man den Krempel  eigentlich hin? Kann man seinen Bug irgendwo sehen?

cu

Dirk

----------

## Necoro

Einmal ist genug  :Smile:  - Es sei denn die Umstände sind unterschiedlich. Für den Fall kann man das denn im Kommentarfeld vermerken... Viel besser wäre es natürlich, wenn du entweder einen Bugreport schreibst (http://portato.origo.ethz.ch/issues) oder zu mindestens eine Absende-Mail-Adresse angibst, so dass man evtl nachfragen kann  :Smile: 

Die Mail-Funktion ist vor allem für die Leute gedacht, die sowas nicht in ein Forum schreiben würden / keinen Bug reporten. Weil viele Fehler sind klein und lassen sich bereits aus dem Traceback heraus erkennen und fixen  :Smile: 

Und zu dem Bug: Hab den auch gerade ... mal schauen ob ich rausfinde wo das Problem ist  :Smile: 

/edit: Das Mail-Teil sendet mir einfach ne Mail mit dem Traceback und eventuellen Anmerkungen  :Smile: . Ansonsten passiert da nix...

/edit2: Fehler gefunden - nur noch keine Ahnung wie ich ihn behebe ...

----------

## Dirk_G

Hi

Mir ist da noch was aufgefallen.... Diese Fehlermeldung von oben kommt ja spätestens beim zweiten Klick auf den Link für die Homepage. Allerdings nur wenn man portato als Benutzer startet, also über gksu oder so. Startet man portato hingegen als root von der Konsole aus kommt dieser Fehler nicht. Vielleicht hilft dir das ja bei der Lösungsfindung.

----------

## Necoro

Ok - mit Revision 277 sollte der Fehler behoben sein  :Smile: 

----------

## Necoro

Portato-0.11_beta ist fertig  :Smile:  ... zu finden in meinem Overlay. Wenn bis Ende der Woche nicht zu viele Bugs reinkommen, werde ich es dann releasen. Dann gibts auch ein Changelog *gerade zu faul das aus dem mitgelieferten abzutippen und zu übersetzen*  :Cool: 

----------

## Necoro

Soo ... es ist erschienen - und dank Jokey auch bereits im Portage Tree  :Smile: 

Changelog:

 NEW: allowed collapsed categories -- similar to porthole

 NEW: make max. title length of the console changeable by the user

 NEW: added shortcut for "Reload Portage"

 NEW allow to send bug report directly per mail

 NEW: allowed to dismiss the warning dialogs for keywords/useflags

 NEW: complete new plugin system rewrite

 NEW: portage-2.2 support

 NEW: added new configuration possibilites: colors; max num of scrollback lines (note: only accessible in the config file - not in the GUI)

 NEW: support for multiple emerge-jobs (see: parallel builds for portage-2.2)

 CHANGE: move --oneshot from menu to button

 CHANGE: now only use external "shm" package

 FIX: lots of bugs  :Smile: 

Außerdem: Da eine Abhängigkeit (dev-python/shm) kein ppc Keyword hat, musste es leider auch aus portato selber fliegen  :Confused:  ich schau mal wie man das wieder gerade gebogen bekommt...

----------

## Necoro

Kurzes Announcement:

Portato 0.11.1 ist erschienen. Dies ist vor allem ein Bugfix-Release  :Smile: . Es sollte jetzt auch mit Portage-2.1.4.4 und mit komplexeren *DEPENDs funktionieren.

Außerdem wird nun auch ein Logfile angelegt (~/.portato/portato.log), welches beim Bug-Senden angehängt wird (sollte man das nicht explizit abwählen).

----------

## Necoro

Suche Helfer

Mal wieder ein Aufruf  :Smile: . Da ich seit knapp 2 Monaten mal endlich wieder was an Portato gemacht habe und sich bei mir die Bugs türmen: Es wäre großartig, wenn sich jemand finden würde, der gerne an dem Projekt mithelfen würde  :Smile: . Insb. KDE-4 scheint Unmengen an komischen Fehlern zu produzieren. Und da ich keine Möglichkeit habe diese zu reproduzieren und auch immer weiter den aktuellen Portage-Entwicklungen hinterher hänge, bräucht es jemanden, der sich in dem Bereich engagieren mag, damit das Projekt nicht langsam aber sicher versiegt.

Also: Meldet euch  :Wink: .

----------

## Necoro

Kurzer Hinweis: Portato-0.12 steht vor der Tür  :Smile: .

Wenn jemand Betatesten will - in meinem Overlay (layman -o http://portato.sf.net/layman.xml -a portato) befindet sich ein portato-0.12_beta ebuild  :Smile: . Als Releasetermin peile ich so erste Märzwoche an.

Wichtigste Änderungen: SQL-Datenbank, Einstellungsdialog überarbeitet, Bugfixes

----------

## Finswimmer

Linguas de will nicht:

```
>>> Compiling source in /var/tmp/portage/app-portage/portato-9999/work/portato-9999 ...                                                                        

Creating translation file for de.                                                                                                                              

Traceback (most recent call last):                                                                                                                             

  File "setup.py", line 16, in <module>                                                                                                                        

    from portato.constants import VERSION, DATA_DIR, ICON_DIR, PLUGIN_DIR, TEMPLATE_DIR                                                                        

  File "/var/tmp/portage/app-portage/portato-9999/work/portato-9999/portato/__init__.py", line 20, in <module>                                                 

    locale.setlocale(locale.LC_ALL, '')                                                                                                                        

  File "/usr/lib64/python2.5/locale.py", line 487, in setlocale                                                                                                

    return _setlocale(category, locale)                                                                                                                        

locale.Error: unsupported locale setting                                                                                                                       

 *                                                       
```

bzw. wenn ich keine Sprachen Flag habe:

```
>>> Compiling source in /var/tmp/portage/app-portage/portato-9999/work/portato-9999 ...                                                                        

Creating translation file for ca.                                                                                                                              

Creating translation file for de.                                                                                                                              

Creating translation file for pl.                                                                                                                              

Creating translation file for tr.                                                                                                                              

Traceback (most recent call last):                                                                                                                             

  File "setup.py", line 16, in <module>                                                                                                                        

    from portato.constants import VERSION, DATA_DIR, ICON_DIR, PLUGIN_DIR, TEMPLATE_DIR                                                                        

  File "/var/tmp/portage/app-portage/portato-9999/work/portato-9999/portato/__init__.py", line 20, in <module>                                                 

    locale.setlocale(locale.LC_ALL, '')                                                                                                                        

  File "/usr/lib64/python2.5/locale.py", line 487, in setlocale                                                                                                

    return _setlocale(category, locale)                                                                                                                        

locale.Error: unsupported locale setting                  

```

Tobi

----------

## Necoro

Hmm - komisch. Sowas hab ich noch nie gesehen ... was passiert, wenn du einfach nur 

```
python -c "import locale; print locale.setlocale(locale.LC_ALL, '');"
```

 machst? (sowohl als user als auch als root)

----------

## Finswimmer

User:

```
[21:28:24]|[tobi@tobi-desktop]|~

$python -c "import locale; print locale.setlocale(locale.LC_ALL, '');"

LC_CTYPE=en_GB;LC_NUMERIC=en_GB;LC_TIME=en_GB;LC_COLLATE=C;LC_MONETARY=en_GB;LC_MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=en_GB;LC_ADDRESS=en_GB;LC_TELEPHONE=en_GB;LC_MEASUREMENT=en_GB;LC_IDENTIFICATION=en_GB
```

Root:

```
$python -c "import locale; print locale.setlocale(locale.LC_ALL, '');"

LC_CTYPE=en_GB;LC_NUMERIC=en_GB;LC_TIME=en_GB;LC_COLLATE=C;LC_MONETARY=en_GB;LC_MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=en_GB;LC_ADDRESS=en_GB;LC_TELEPHONE=en_GB;LC_MEASUREMENT=en_GB;LC_IDENTIFICATION=en_GB
```

Sieht mir ziemlich gleich aus.

Tobi

----------

## Necoro

Hmm - soll das so (also en_GB als locale?). Und was sagt locale-gen -l - ist dort en_GB vertreten?

(bzw: in localedef --list-archive)

----------

## Finswimmer

 *Necoro wrote:*   

> Hmm - soll das so (also en_GB als locale?). Und was sagt locale-gen -l - ist dort en_GB vertreten?
> 
> (bzw: in localedef --list-archive)

 

$locale-gen -l

en_GB.ISO-8859-1

en_GB.ISO-8859-15

de_DE.ISO-8859-1

de_DE.ISO-8859-15@euro

$locale

LANG=en_GB.ISO-8859-15

LC_CTYPE="en_GB.ISO-8859-15"

LC_NUMERIC="en_GB.ISO-8859-15"

LC_TIME="en_GB.ISO-8859-15"

LC_COLLATE=C

LC_MONETARY="en_GB.ISO-8859-15"

LC_MESSAGES="en_GB.ISO-8859-15"

LC_PAPER="en_GB.ISO-8859-15"

LC_NAME="en_GB.ISO-8859-15"

LC_ADDRESS="en_GB.ISO-8859-15"

LC_TELEPHONE="en_GB.ISO-8859-15"

LC_MEASUREMENT="en_GB.ISO-8859-15"

LC_IDENTIFICATION="en_GB.ISO-8859-15"

LC_ALL=

$localedef --list-archive

de_DE

de_DE.iso88591

de_DE.iso885915@euro

de_DE@euro

deutsch

en_GB

en_GB.iso88591

en_GB.iso885915

german

Ich hoffe, du hast noch eine Idee.

Tobi

----------

## Necoro

Ja ist denn schon wieder Weihnachten? - Es ist Bescherung -> Portato 0.12 ist erschienen  :Smile: 

Änderungen :

NEU: kann eine SQLite-DB als interne DB benutzen

NEU: Dependency-Liste ist nach Useflags sortiert

NEU: Dependency- und Useflag-Liste ist jetzt 'lazy' - also wird nur auf Anforderung geladen

NEU: Höhe und Breite des Einstellungsfensters wird gemerkt

NEU: vor dem Starten werden Vorabbedingungen geprüft (insb. für Sabayon notwendig)

NEU: die Farben können jetzt auch endlich im Einstellungsdialog geändert werden und nicht nur in der Config direkt

I18N: spanische Übersetzung  :Smile: 

CHANGE: Einstellungsdialog ein wenig überarbeitet

CHANGE: Sessionhandling-Verbesserungen

CHANGE: verwende GtkBuilder anstatt libglade

FIX: die Suche sollte jetzt wieder funktionieren  :Smile: 

FIX: bugs fixed: #44, #41, #15, #47 und noch einige mehr

@Finswimmer: Ich habe keinen Plan was da bei dir passiert. Versuch mal es mit LC_ALL=C zu emergen. Und dann mal schauen ob es mit deiner Locale startet.

----------

## Finswimmer

 *Necoro wrote:*   

> @Finswimmer: Ich habe keinen Plan was da bei dir passiert. Versuch mal es mit LC_ALL=C zu emergen. Und dann mal schauen ob es mit deiner Locale startet.

 

Damit kann ich es installieren.

Und es scheint auch ohne Probleme zu laufen *strange*

Danke

Tobi

----------

## Necoro

Musste ein neues Release machen (0.12.1) wegen Bugfix =/

Das neue Ebuild behebt auch Finswimmers Fehler (tritt auf, wenn LC_ALL leer ist).

/edit: So - der locale-Fehler ist auf meinem Mist gewachsen augenscheinlich. Merke: Niemals eine Variable im Ebuild "LANG" nennen ...

----------

## Kunigunde

Hallo, ich habe Portato installiert und erhalte folgende Fehlermeldeung auf der Konsole:

Setting Portage System (__init__.py:56)

* Using portage-2.1 (__init__.py:25)

* Starte Portato v. 0.12.1 (portato:50)

* Listener wurde nicht gestartet. (plistener.py:94)

* All prereqs matched. Fine  :Smile:  (main.py:1921)

/usr/lib/python2.5/site-packages/portato/gui/windows/basic.py:73: GtkWarning: Invalid input string

  self._builder.add_from_file(os.path.join(TEMPLATE_DIR, self.__file__+".ui"))

Speicherzugriffsfehler

dmesg spukt folgendes aus:

portato[13136]: segfault at 99ea000 ip b7232bd0 sp bfaee6e0 error 4 in libglib-2.0.so.0.1800.4[b71f7000+ce000]

portato[22009]: segfault at 99ec000 ip b71eabd0 sp bfea72a0 error 4 in libglib-2.0.so.0.1800.4[b71af000+ce000]

portato[1867]: segfault at 9a29000 ip b7206bd0 sp bfa83da0 error 4 in libglib-2.0.so.0.1800.4[b71cb000+ce000]

Meine Frage: Wo muss ich ansetzen?

Danke

Kuni

----------

## Necoro

ich würde glib, gtk+, pygobject und pygtk neu bauen versuchen.

----------

## Kunigunde

Hallo,

Ich habe die Pakete glib, gtk+, pygobject und pygtk neu installiert (einfach emerge ohne unmerge)

aber ich erhalte immer noch die gleiche Fehlermeldung.

Hast du noch eine Idee?

Danke

Kuni

----------

## Klaus Meier

Entweder ist dein Speicher nicht in Ordnung oder dein gcc/binutils erzeugt Müll. Treten nur genau bei diesen Anwendung Fehler auf oder crasht dein System öfters mal. Wenn es nur in diesem Fall so ist, dann probier mal ein 

```
emerge -e system && emerge -e world
```

 Ansonsten, wenn du mehrere Speicherriegel in deinem Rechner hast, mal einen davon ziehen. Bringt aber nichts, wenn die Binaries auf deinem Rechner schon kaputt sind. Wenn du defekten Speicher entfernst, mußt leider alles noch mal übersetzen, da die kaputten Binaries sonst nicht verschwinden.

Kannst das ja auch erst mal mit memtest überprüfen.

----------

## Kunigunde

Hallo,

ich habe es:

locale-gen aufrufen und schon funktioniert portato

Fall gelöst

Danke 

Kuni

----------

## yaneyre

hallo!   :Very Happy: 

Ich habe keine idee über das thema, aber Ich möchte ein freunden, Ich lerne Deutsche Sprache und Ich brauche seine/ihre Hilfe bitte, nur für zu praktizieren per mail oder gentoo.org.

Entschuldigen Sie mir mein Fehler!

begrüsses

Deine Blondine

----------

## manuels

Hi,

ich habe gerade mal dein Portato ausprobiert, da ich schon länger kein portage-sync mehr gemacht habe und nicht alle Blocks von Hand lösen wollte.

Mein erster Eindruck:

- Die Möglichkeit ein Paket zu emergen ist ein bisschen versteckt (vielleicht werd ich auch alt).

Das das ganze im "Emerge"-Menü versteckt ist habe ich erst nach einiger Zeit gefunden.

Kannst du nicht dieses Menü auch als "Rechts-Klick-Kontextmenü" bei der Versionsauswahl ganz rechts ebenfalls anbieten?

- Mir wurde, als ich ein neues Paket installieren wollte, nur angezeigt, dass ich einen Blocker deinstallieren soll.

Wäre nett, wenn man bei der Meldung dazu gleich den Button angeboten bekommt, der den Blocker deinstalliert.

Ansonsten macht es einen ganz netten Eindruck. Ich werd es noch ein bisschen testen.

Ich werd wohl echt alt - dass ich ein Portage GUI verwenden muss...

----------

## Necoro

 *manuels wrote:*   

> - Die Möglichkeit ein Paket zu emergen ist ein bisschen versteckt (vielleicht werd ich auch alt).
> 
> Das das ganze im "Emerge"-Menü versteckt ist habe ich erst nach einiger Zeit gefunden.

 

Eigentlich ist es so gedacht, dass man das entsprechende Paket (inkl. Version) auswählt... Denn auf den "+"-Button drückt. Und wenn man alle Pakete zusammen hat, die man installieren will, benutzt man "Execute".

 *Quote:*   

> Kannst du nicht dieses Menü auch als "Rechts-Klick-Kontextmenü" bei der Versionsauswahl ganz rechts ebenfalls anbieten?

 

Klingt sinnvoll  :Smile: 

 *Quote:*   

> Mir wurde, als ich ein neues Paket installieren wollte, nur angezeigt, dass ich einen Blocker deinstallieren soll.
> 
> Wäre nett, wenn man bei der Meldung dazu gleich den Button angeboten bekommt, der den Blocker deinstalliert.

 

Die Blockererkennung ist leider alles andere als ausgereift. Insbesondere mit den moderneren Versionen von Portage gibts da einiges an Problemen. Ich bin so peu à peu dabei dies neu zu implementieren (was quasi daraus hinauf läuft, die Portage-Installations-Logik nachzubauen -.-) - vorher werde ich da sicherlich nix mehr dran ändern.

----------

## Dirk_G

Hallo

Ich habe ein kleines Problem mit der 0.12.1 Version. Die vergisst das '/' am Anfang wenn es die Verzeichnisse in /etc/portage/... sucht.  Hier mal die Ausgabe von Portato.

```
* newTesting: {u'x11-drivers/nvidia-drivers-185.18.31': [('etc/portage/package.keywords', '-1')]} (flags.py:698)

* new masked: {} (main.py:1534)

* new unmasked: {} (main.py:1535)

* new testing: {u'x11-drivers/nvidia-drivers-185.18.31': [('etc/portage/package.keywords', '-1')]} (main.py:1536)

* Datei oder Verzeichnis nicht gefunden: etc/portage/package.keywords (dialogs.py:36)
```

Wenn ich portato in / aufrufe geht es. Ist aber etwas umständlich. Gibt es dazu schon eine Lösung?

Dirk

----------

## Necoro

Gib mir mal bitte die Ausgaben der folgenden drei Kommandos:

```
python -c "from portato.gui.exception_handling import get_version_infos; print get_version_infos()"
```

```
python -c "from portato.backend import system; print system.get_config_path()"
```

```
python -c "import portage; print portage.USER_CONFIG_PATH"
```

----------

## Dirk_G

Hi Necoro

python -c "from portato.gui.exception_handling import get_version_infos; print get_version_infos()"

```
* Setting Portage System (__init__.py:56)

* Using portage-2.2 (__init__.py:21)

Portato version: 0.12.1

System: Gentoo 

Python version: 2.6.2 (r262:71600, Aug  1 2009, 12:07:42) 

[GCC 4.3.2]

Used backend: Portage 2.2_rc37

pygtk: 2.14.1 (using GTK+: 2.14.7)

pygobject: 2.18.0 (using GLib: 2.18.4)
```

python -c "from portato.backend import system; print system.get_config_path()"

```
* Setting Portage System (__init__.py:56)

* Using portage-2.2 (__init__.py:21)

etc/portage
```

python -c "import portage; print portage.USER_CONFIG_PATH"

```
etc/portage
```

----------

## Necoro

Kann den Fehler reproduzieren. Liegt augenscheinlich an der Portage-Version

workaround: auf <portage-2.2_rc35 umsteigen

/edit: Fixed in trunk.

----------

## Dirk_G

Hi nochmal Necoro

Habe mal meine LiveCD angeworfen und die Portage-Versionen durch getestet. Dort ging weder die rc35, die rc36 noch die rc37. Nur die rc33 geht von den 2.2 Versionen. Bei der 2.1.x tritt der Fehler ebenfalls nicht auf. Also, alle meine System zurücksetzen... schitte;) Trotzdem Danke für die schnelle Antwort.

Dirk

----------

## Necoro

 *Dirk_G wrote:*   

> Also, alle meine System zurücksetzen... schitte;) 

 

Oder dich an der 9999er Version von Portato probieren  :Wink: 

----------

## Dirk_G

Jo, die geht auch, aber die ist nicht im Portage-Tree. Und wenn ich schon mal am Fragen bin, gibt es die Möglichkeit einen 'shotdown wenn fertig' einzubauen? Da wo der 'oneshot' ist. Den hätte ich schon sehr oft gebrauchen können. Und weil es so schön ist ein 'layman -S'  Knopf währe auch cool;) besser noch ein Plugin wo man alles an oder abwählen kann...  :Rolling Eyes: 

Dirk

----------

## Necoro

Das "Shutdown wenn fertig"-Plugin gabs schon mal ... ist auf jeden Fall kein Problem, es (neu) zu schreiben

Auch das mit dem "layman -S" sollte kein Problem sein...

(Hmm ... vielleicht sollte ich mich mal an die "Wie schreibe ich ein Plugin"-Doku machen)  :Smile: 

----------

## Dirk_G

 *Necoro wrote:*   

> 
> 
> (Hmm ... vielleicht sollte ich mich mal an die "Wie schreibe ich ein Plugin"-Doku machen) 

 

Währe vielleicht nicht schlecht;)

----------

## Necoro

Das Problem ist, dass das mein Lieblingsspielfeld ist  :Razz:  - da kann man so viele Sachen ausprobieren ^^.

Naja mal schauen, dass das in den nächsten Tage was wird.

(Die neue Version wartet auch auf Veröffentlichung)

----------

## Necoro

Nur ne kurze Info: Ich habe jetzt Support für die eix-Datenbank in Portato eingebaut  :Smile: . Das Feature wird es aber noch nicht in 0.13 geben, sondern erst 0.14

----------

## Necoro

So  :Smile:  Mal wieder Zeit für ein kleines Release -> 0.13

NEU: arbeitet auch mit Zeilen in package.keywords, die kein Keyword enthalten

NEU: Support für ktsuss als grafisches SU-Tool ... (Achtung: Ktsuss ist sehr einfach ... und setzt u.a. die Env-Variablen net zurück. So wird zB das Home-Verzeichnis des Benutzers und nicht das von root benutzt)

NEU: Man-Page  :Smile: 

NEU: Kann mit "masked by EAPI" umgehen

NEU: mal wieder am Plugin-System geschraubt. Nun können Plugins auch die Oberfläche verändern.

CHANGE: "-L" Cmdline-Option wurde entfernt. Bitte "-F" benutzen.

CHANGE: einige Oberflächen-Elemente (Changelog, Ebuild, Dateien) wurden in Plugins ausgelagert

CHANGE: die Config-Dateien erlauben keinen Doppelpunkt mehr als Zuweisungsoperator. Nur noch "="

I18N: pt_BR translation - thanks to Alberto Federman Neto 

Die Version ist leider momentan noch net im Tree.

----------

## Necoro

Danke an Patrick Lauer für den Bump  :Smile:  - ist nun im Tree.

----------

## Finswimmer

Hi Necoro,

ich hätte einen Feature-Request:

Die World File als browsable Liste. Denn dann kann man schnell und einfach alle nicht benötigten Pakete aus der Liste entfernen.

Danke

Tobi

----------

## Finswimmer

```
Traceback (most recent call last):                                                                                     

  File "/usr/lib64/python2.6/site-packages/portato/gui/utils.py", line 40, in run                                      

    Thread.run(self)                                                                                                   

  File "/usr/lib64/python2.6/threading.py", line 477, in run                                                           

    self.__target(*self.__args, **self.__kwargs)                                                                       

  File "/usr/lib64/python2.6/site-packages/portato/gui/windows/main.py", line 1458, in __update                        

    updating = system.update_world(sets = self.updateSets, newuse = self.cfg.get_boolean("newuse"), deep = self.cfg.get_boolean("deep"))

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/system.py", line 366, in update_world                                

    check(p, True)                                                                                                                      

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/system.py", line 356, in check                                       

    bm = self.get_new_packages([i])                                                                                                     

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/system.py", line 271, in get_new_packages                            

    append(crit, self.find_best_match(crit), inst)                                                                                      

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/system.py", line 191, in find_best_match                             

    t = self.find_packages(search_key, pkgSet = pkgSet, masked = masked, with_version = True, only_cpv = True)

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/system.py", line 211, in find_packages

    return self.geneticize_list(self._get_set(pkgSet).find(key, masked, with_version, only_cpv), only_cpv or not with_version)

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/sets.py", line 34, in find

    t = self.get_pkgs(key, is_regexp, masked, with_version, only_cpv)

  File "/usr/lib64/python2.6/site-packages/portato/backend/portage/sets.py", line 126, in get_pkgs

    t = system.settings.porttree.dbapi.match(key)

  File "/usr/lib64/portage/pym/portage/dbapi/porttree.py", line 1013, in match

    return self.xmatch("match-visible", mydep)

  File "/usr/lib64/portage/pym/portage/dbapi/porttree.py", line 910, in xmatch

    mydep = dep_expand(origdep, mydb=self, settings=self.mysettings)

  File "/usr/lib64/portage/pym/portage/__init__.py", line 7200, in dep_expand

    return portage.dep.Atom(prefix + expanded + postfix)

  File "/usr/lib64/portage/pym/portage/dep.py", line 499, in __call__

    instance = super(_AtomCache, cls).__call__(s)

  File "/usr/lib64/portage/pym/portage/dep.py", line 530, in __init__

    raise InvalidAtom(s)

InvalidAtom: >=dev-lang/python-2.4.4[threads]:2.6

Portato version: 0.13

System: Gentoo

Python version: 2.6.2 (r262:71600, Aug  5 2009, 18:08:08)

[GCC 4.3.3]

Used backend: Portage 2.2_rc33

pygtk: 2.14.1 (using GTK+: 2.16.6)

pygobject: 2.18.0 (using GLib: 2.20.5) (exception_handling.py:125)

```

Das passiert beim Update World

----------

## Necoro

 *Finswimmer wrote:*   

> ich hätte einen Feature-Request:
> 
> Die World File als browsable Liste. Denn dann kann man schnell und einfach alle nicht benötigten Pakete aus der Liste entfernen.

 

Danke für die Idee  :Smile:  - revision 468 is your friend  :Very Happy: 

Zu dem Bug: Joa - den kenne ich schon. Ist leider nicht so einfach zu beheben (wenn man nicht irgendwelche recht dreckigen Workaround-Hacks haben will) und braucht daher noch ne Zeit die zu fixen  :Neutral: 

Im Moment hilft da: Nur eine Python-Version installiert haben

----------

## Finswimmer

```
[nomerge      ] app-portage/portato-0.13  USE="kde libnotify nls sqlite userpriv" LINGUAS="-ca -de -es_ES -pl -pt_BR -tr"

[ebuild  NS   ]  dev-lang/python-2.5.4-r3 [2.6.2-r1] USE="berkdb gdbm ncurses readline sqlite ssl threads xml -build -doc -examples -ipv6 -tk -ucs2 -wininst" 9,612 kB

```

Nun will er es doch wieder installieren? Ich habe im Ebuild nachgeschaut, kann es aber nicht nachvollziehen.

Tobi

----------

## Necoro

 *Finswimmer wrote:*   

> 
> 
> ```
> [nomerge      ] app-portage/portato-0.13  USE="kde libnotify nls sqlite userpriv" LINGUAS="-ca -de -es_ES -pl -pt_BR -tr"
> 
> ...

 

Strange -- weiß ich aber auch keine Antwort. Die momentanen Python-Abhängigkeiten sind teilweise ... mysteriös (kurzzeitig hing Python-2.6 ja auch von Python-3.1 ab). Ich sollte mich dran machen den Fehler zu fixen, sobald meine Klausuren vorbei sind.

----------

## Necoro

Nur eine kurze Meldung: Ich bin von Bzr nach Git gewechselt  :Smile: . Daher sind die Repositories (inkl. Overlay) ebenfalls von Launchpad nach GitHub gezogen.

Der trunk/master wird aber weiterhin auf Launchpad gespiegelt... denn die bieten neuerdings einen git-import an  :Smile: 

Den Code findet man also jetzt hier:

- http://github.com/Necoro/portato

- http://github.com/Necoro/portato-overlay

----------

## Necoro

0.13.1 gibts endlich  :Smile:  ... nur kleine Bugfixes (Segfault und speichern von useflags).

Danke an cla fürs ins-portage-bringen ...

----------

## Necoro

Hey  :Smile: 

Portato 0.14 steht vor der Tür. Wahrscheinlich an Anfang Mai wird es denn auch auf Mirrorn in Eurer Nähe zu finden sein  :Smile: . Aber damit möglichst wenig Bugs vorhanden sind, bitte ich alle, die momentane Alpha mal zu testen.

Im neuen Release wird es jetzt(tm) geben:

- Benutzung der Eix-Cache-DB ... damit ist nun auch die Suche in den Paketbeschreibungen möglich

- Liste der Pakete in World anzeigen (Finswimmer war glaube ich der Requester  :Smile: )

- Ein Icon zeigt nun an, wenn etwas die 'best' version ist ...

- fix bugmail sending

Das Alpha-Ebuild wird so installiert:

layman -a portato

emerge -av =app-portage/portato-0.14_alpha

Der Portato-Overlay ist nun in der offiziellen Gentoo-Repository-Liste ... braucht also layman nicht mehr mit was speziellem zu füttern  :Smile: 

----------

## Necoro

Portato 0.14 hat es nun in den Tree geschafft  :Smile: 

----------

## Necoro

Kurzes Update: Portato-0.14.1 ist draussen. Fixt Probleme mit neuem Portage (2.1.9 und 2.2_rc7x)

----------

