KTabCtl, alternativen?

[dipesh]

Hi,

ich bin auf der Suche nach einem KTabCtl-Ersatz welcher mehr Möglichkeiten bietet um beispielsweise einen Button zum Schliessen des Tabs unterzubringen.
Soweit ich lass, ist etwas in der Richtung event. für Konqi's Tab-Modus geplant. Gibt es da schon etwas existierendes?

Danke im voraus für jegliche Antwort (zum Thema) :-)

[anda_skoa]

Gute Frage, ich hab mich mal schlau gemacht :D

Es war nicht möglich, gewissen Sachen in einer QTabWidget Subklasse zu implementieren, weil wichtige Bereiche private sind.

Zack Rusin hat entsprechende Erweiterungen dafür gemacht und ich glaube auch an TT gesandt.

http://lists.kde.org/?l=kde-core-devel&m=104657112728340&w=2

Für Details einfacc den ganzen Thread auf kde-core-devel nachlesen.
Es gibt dort auch Links für zwischenzeitliche Lösungen.

Ciao,
_

[dipesh]

Danke für die rasche Antwort anda_skoa :-)

Scheint leider wirklich so zu sein, dass gem. dem dev-Thread und dem kde-3.2-featureplan (http://developer.kde.org/development-versions/kde-3.2-features.html) das neue KTabWidget erst mit KDE 3.2 Einzug in die kdelibs halten wird. Bis dahin heisst es wohl alternativen Code nutzen. Leider sind die Links zu den zwischenzeitlichen Lösungen tot und der Author hat leider auch keinen weiteren Link zu einem cvs oder dergleichen gepostet. Da google.de auch nichts ausspuckt, heisst es wohl doch selbst implementieren (soviel zum Thema; das Rad stetig neu erfinden zu muessen) :-(

[anda_skoa]

Soweit ich das vestanden habe, gibt es solche Übergangslösungen in Kopete und Knight.

Eventuell aus deren Sourcetree kopieren.

Ciao,
_

[dipesh]

Danke nochmals und werd ich wohl machen. Opensource ist einfach genial! :-)

[anda_skoa]

Hab gerade in einem Thread auf kde-core-devel gelesen, dass eine neue Tab Widget Implementierung in kdenonbeta/testwidgets/tab zu finden ist.
http://lists.kde.org/?l=kde-core-devel&m=105310008306572&w=2

Qt3.2 wurde gerade released und hat jetzt Unterstützung für einige der Erweiterungen wie per-Tab Close buttons.

Ciao,
_

[dipesh]

Danke für den Hinweis. Wir haben uns jetzt die entspr. Quellen aus QTella "ausgeborgt". Die Nutzung der hauseigenen QT 3.2 Erweiterung halte ich persönlich für derzeit nicht sinnvoll. Schiesslich würde man potentielle Nutzer sonst dazu zwingen mind. QT 3.2 einzusetzen - gerade aufgrund des noch ausstehenden KDE 3.2 wenig sinnvoll.

Danke übrigens auch für die hervorragenden Texte in "Tutorial: Qt Grundlagen". Hat sehr geholfen bei der manuellen Erstellung einer make-Datei für ein anderes reines QT-Prog.

[anda_skoa]

Original geschrieben von dipesh
Danke für den Hinweis. Wir haben uns jetzt die entspr. Quellen aus QTella "ausgeborgt". Die Nutzung der hauseigenen QT 3.2 Erweiterung halte ich persönlich für derzeit nicht sinnvoll. Schiesslich würde man potentielle Nutzer sonst dazu zwingen mind. QT 3.2 einzusetzen - gerade aufgrund des noch ausstehenden KDE 3.2 wenig sinnvoll.


AFAIK ist Qt3.2 noch gar nicht draußen, sondern für nächste Zeit angekündigt.
Man sollte aber vielleicht im eigenen TODO einen entsprechenden Eintrag machen, damit man dann nicht vergisst :)



Danke übrigens auch für die hervorragenden Texte in "Tutorial: Qt Grundlagen". Hat sehr geholfen bei der manuellen Erstellung einer make-Datei für ein anderes reines QT-Prog.

Bei Pure-Qt Anwendungen verwende ich immer qmake.
Geht auch für kleinere KDE Apps ganz gut.

Ciao,
_

[dipesh]

AFAIK ist Qt3.2 noch gar nicht draußen, sondern für nächste Zeit angekündigt.
Man sollte aber vielleicht im eigenen TODO einen entsprechenden Eintrag machen, damit man dann nicht vergisst :)


Naja. Ich versuche eigentlich - insofern möglich - abwärtskompatibel zu sein. Kann ja nicht von jedem verlangen auf QT 3.2 upzudaten nur um den "neusten hype" mitzumachen.
Ist meiner Meinung nach sowieso ein grosser Nachteil von Linux sicherlich bedingt durch die mannigfaltigen Möglichkeiten die man hat. Schon nach wenigen Monaten trieft man auf die ersten neuen Anwendungen die die neuste release einer bestimmten Lib vorraussetzt. Diese Lib wiederum zwingt einem andere Libs ebenfalls zu aktualisieren und bevor man sich versieht ist man wieder dabei sein System upzudaten. Da lob ich mir das Konzept von Debian stets das aktuell eingesetzte weiterzupflegen und dem Eigentümer auf diesem Wege die notwendigen Updates so leicht als möglich von der Hand gehen zu lassen :-)



Bei Pure-Qt Anwendungen verwende ich immer qmake.
Geht auch für kleinere KDE Apps ganz gut.


Zwingt jedoch denjenigen der den Code später kompileiren will qmake zu installieren + die Umgebungsvariablen zu setzen. Oder ist es so auch möglich Makefiles erzeugen zu lassen die man dann einfach weitergibt?

[anda_skoa]

Original geschrieben von dipesh
Naja. Ich versuche eigentlich - insofern möglich - abwärtskompatibel zu sein. Kann ja nicht von jedem verlangen auf QT 3.2 upzudaten nur um den "neusten hype" mitzumachen.


Ich meinte ein #ifdef Conditional.
Muss man nicht machen, aber lässt die Applikation dann besser integriert aussehen, wenn sie die selben Tabfeatures unterstützt wie alles andere auch.



Ist meiner Meinung nach sowieso ein grosser Nachteil von Linux sicherlich bedingt durch die mannigfaltigen Möglichkeiten die man hat. Schon nach wenigen Monaten trieft man auf die ersten neuen Anwendungen die die neuste release einer bestimmten Lib vorraussetzt. Diese Lib wiederum zwingt einem andere Libs ebenfalls zu aktualisieren und bevor man sich versieht ist man wieder dabei sein System upzudaten. Da lob ich mir das Konzept von Debian stets das aktuell eingesetzte weiterzupflegen und dem Eigentümer auf diesem Wege die notwendigen Updates so leicht als möglich von der Hand gehen zu lassen :-)


Die Libs sind ja alle innerhalb des selben Major releases abwärtskompatibel.
D.h. man kann eh alle gehen Qt3.0 kompilierten Anwendungen mit Qt3.1 oder Qt3.2 laufen lassen.
Wenn jemand für eine Applikation 3.2 Features braucht, oder ort ein essentieller Bugfix ist, wird halt die neue Version installiert.
Die anderen Applikationen merken davon ja nix.



Zwingt jedoch denjenigen der den Code später kompileiren will qmake zu installieren + die Umgebungsvariablen zu setzen.

Installiert hat er es ja schon.
qmake ist Teil der qt-devel Pakete, bzw. des Qt Source Paketes (wenn es jemadn selber komipliert hat)
Hat jemand die Header, hat er auch qmake.

Und zwei Umgebungsariablen setzen, von denen eine praktisch trivial ist (QMAKESPEC), halte ich nicht für sehr schwierig.



Oder ist es so auch möglich Makefiles erzeugen zu lassen die man dann einfach weitergibt?
Das qmake generierte Makefile braucht AFAIK nur ein gesetzte QTDIR.

Ich halte qmake für eine ganz feine Sache.
Die einzige Alternative ist automake/autoconf und das ist für den Entwickler wesentlich komplizierter und während der Entwicklungsphase zeitraubender.

Ich kann ohne weiteres aus dem Gedächtnis ein qmake .pro File schreiben, aber ein automake/autoconf System muss ich mir generieren lassen.
Da schaff ich selbst nur das editieren der Makefile.am Dateien.

Ciao,
_