FLTK Meinungen

Artchi

freizeit_programmierer schrieb:

Habe ich das richtig verstanden, ich darf deine lib nutzen und statisch linken ohne meinen quelltext offen zu legen

Richtig!

freizeit_programmierer schrieb:

wenn ich deine Erklärung und dein Copyright irgendwo in meiner Software mit angebe z.B. im Info Bereich oder bei der Installation?

Richtig! Der Lizenztext muß für den User jeder Zeit einsehbar sein, z.B. im Handbuch. Nur bei der Installation wäre glaube ich etwas wenig, weil ihn der User nur einmalig lesen kann. Den Lizenztext muß jeder immer lesen können, damit er weiß, woran er ist: z.B. wenn die Lizenzdatei einfach in dem Verzeichnis deiner Anwendung liegt, im Infobereich, Hilfe oder Handbuch.

Hier mal sinngemäß die Übersetzung der zweiten Bedingung:

2. Weiterverbreitete kompilierte Exemplare müssen das obige Copyright, diese Liste der Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder anderen Materialien, die mit dem Exemplar verbreitet werden, enthalten.

@artchi: deine lib schaut schon ganz nett aus es fehlen aber auch einige GUI Elemente wie TreeViews, Grids, Toolsbars, Split- und TabbedWindows oder?

@scrontch: hmm, bin jetzt etwas in grübeln geraten wegen fltk und denke ich werde auch mal wxwidgets ausprobieren. Bei qt darf ich nicht statisch linken und kann auch nicht ohne weiteres den Code einfach kompilieren. Ne IDE kommt mir nicht ins Haus sooo große Projekte will ich nicht machen als das ich ne IDE brauche. Is echt schwer was komplettes leichtgewichtiges nur für GUI zu finden.

Scorcher24

freizeit_programmierer schrieb:

@artchi: deine lib schaut schon ganz nett aus es fehlen aber auch einige GUI Elemente wie TreeViews, Grids, Toolsbars, Split- und TabbedWindows oder?

@scrontch: hmm, bin jetzt etwas in grübeln geraten wegen fltk und denke ich werde auch mal wxwidgets ausprobieren. Bei qt darf ich nicht statisch linken und kann auch nicht ohne weiteres den Code einfach kompilieren. Ne IDE kommt mir nicht ins Haus sooo große Projekte will ich nicht machen als das ich ne IDE brauche. Is echt schwer was komplettes leichtgewichtiges nur für GUI zu finden.

Einer der großen Vorteile an wxWidgets ist die Lizenz. Du darfst damit quasi fast alles machen was Du willst. Ein einfaches Beispiel mal, wie verdammt einfach wxWidgets ist und doch so mächtig:

//////////////////////////////////////////////////////////////////////////
// Event Table
BEGIN_EVENT_TABLE(Mainframe, wxFrame)
	EVT_MENU(idMENU_RELOAD_HTML, Mainframe::OnReloadHtml)
	EVT_MENU(idMENU_SHOW_STARTUP, Mainframe::OnShowStartup)
	EVT_MENU(idMENU_ABOUT, Mainframe::OnAbout)
	EVT_MENU(idMENU_EXIT, Mainframe::OnExit)
END_EVENT_TABLE()
//////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////
// Constructor and Deconstructor
//////////////////////////////////////////////////////////////////////////
Mainframe::Mainframe(long style)
: wxFrame(NULL, -1, "AweSomeScript", wxDefaultPosition, wxSize(800,600), style),
  m_currentPage(ASS_STARTUP_FILE)
{
	// Create Menu

	wxMenu* mnuPreview = new wxMenu;
	mnuPreview->Append(idMENU_RELOAD_HTML, _("Reload\tF5"));

	wxMenuBar* bar = new wxMenuBar();
	bar->Append(mnuPreview, _("Preview"));
	this->SetMenuBar(bar);

	// Create Notebook
	m_notebook = new wxNotebook(this, idNOTEBOOK);
	CreateTextPage(m_notebook);
	CreateHtmlPage(m_notebook);
	m_notebook->ChangeSelection(1);
}

Mainframe::~Mainframe()
{
}

//////////////////////////////////////////////////////////////////////////
// Creating Notebook Pages
//////////////////////////////////////////////////////////////////////////

void Mainframe::CreateHtmlPage( wxBookCtrlBase* parent )
{	
	m_winHtml  = new wxHtmlWindow(parent, idPAGE_HTML);
	m_winHtml->LoadFile(wxFileName(m_currentPage));
	parent->AddPage(m_winHtml, _("Preview"));
}

void Mainframe::CreateTextPage( wxBookCtrlBase* parent )
{
	m_txtSource = new wxTextCtrl(parent, idPAGE_SOURCE);
	parent->AddPage(m_txtSource, _("Source") );
}

//////////////////////////////////////////////////////////////////////////
// Events
//////////////////////////////////////////////////////////////////////////

void Mainframe::OnExit( wxCommandEvent& )
{
	this->Close(true);
}

void Mainframe::OnAbout( wxCommandEvent& )
{
}

void Mainframe::OnReloadHtml( wxCommandEvent& )
{
	m_winHtml->LoadFile(wxFileName(m_currentPage));
}

void Mainframe::OnShowStartup( wxCommandEvent& )
{
	m_currentPage = ASS_STARTUP_FILE;
	m_winHtml->LoadFile(wxFileName(m_currentPage));
}

http://img687.imageshack.us/img687/7918/97340824.jpg
Daran arbyte ich grade :P. Was da angezeigt wird, ist HTML. wx kann derzeit zwar nur HTML 1, also nur basics, aber wxWebKit ist in der mache und wird hoffentlich bald erscheinen.
Am Ende musst Du es wissen, was Du willst...
rya.

Is sehr nett, ich habe auch schon mal mit rumgespielt. Mir gefallen die dynamsichen Eventhanlding besser als die Eventmakros, aber das kann ja jeder machen wie er will.

Das mit HTML 1 is völlig egal, da ich nur GUI brauche und den Rest selbst mache zu Lernzwecken oder halt noch andere libs bei bedarf dazuhole.

Kann ich eigentlich bei wxWidgets wenn ich das für statisch kompiliere auch nur die libs reinhauen die ich brauche also z.B html draussen lassen?

Scorcher24

freizeit_programmierer schrieb:

Is sehr nett, ich habe auch schon mal mit rumgespielt. Mir gefallen die dynamsichen Eventhanlding besser als die Eventmakros, aber das kann ja jeder machen wie er will.

Das mit HTML 1 is völlig egal, da ich nur GUI brauche und den Rest selbst mache zu Lernzwecken oder halt noch andere libs bei bedarf dazuhole.

Kann ich eigentlich bei wxWidgets wenn ich das für statisch kompiliere auch nur die libs reinhauen die ich brauche also z.B html draussen lassen?

Das macht der Compiler automatisch. Der linkt nur, was wirklich gebraucht wird.
Das Framework ist allerdings in mehrere kleine libs unterteilt. So musst Du nur gegen das linken, was du brauchst. Auch bei den .dll ist das so. Es gibt viele kleine dll, die für einen bestimmten Bereich zuständig sind. Man kann aber auch alles in eine große packen. Wie man das möchte.
rya.

Artchi

freizeit_programmierer schrieb:

@artchi: deine lib schaut schon ganz nett aus es fehlen aber auch einige GUI Elemente wie TreeViews, Grids, Toolsbars, Split- und TabbedWindows oder?

Verständlich das da noch so viel fehlt, da es ja nicht mal eine Version 1.0 gibt. Es ist ganz klar noch in Entwicklung und es lebt auch sehr stark. Deshalb gibt es auch keine "Werbung" dafür.
Die anderen GUI-Libs wie FLTK oder wx sind dagegen schon viel länger auf dem Markt. Wenn Du JETZT was produktives brauchst, sind die anderen Libs besser für dich geeignet.

Ja stimmt du bist ja noch nicht bei der Version 1 angelangt und leider brauche ich schon jetzt was komplettes. Das soll aber nicht heißen das ich deine Lib nicht mal ausprobieren werden, auf jedenfall bleibt der Link zu deiner Seite erhalten. Es macht alles einen sehr seriösen Eindruck, ist irgendwie schade das nur du dran arbeitest, was passiert wenn du keine Lust mehr drauf hast oder dir was passiert?

freizeit_programmierer schrieb:

Is echt schwer was komplettes leichtgewichtiges nur für GUI zu finden.

wieso?
so wie ich das sehe kommt eigentlich nur fltk fuer dich in Frage - da warst du eigentlich schon auf dem richtigen Weg. fltk-programme duerfen statisch gelinkt werden und erreichen eine unschlagbare Exe-Groesse - wenns dir darum geht wirst du was besseres (im Moment) nicht finden. Mit Hilfe von Schemes kannst du auch den "altmodischen" Look aufpeppen.
wxWidgets ist keine reine GUIlib sondern ein Framework mit allem moeglichem SchnickSchnack und meiner Meinung nach zu ueberladen fuer einen, der "nur" eine "leichtgewichtige GUIlib" sucht.

Hast ja recht, aber nachdem ich gelesen habe das fltk doch ziemlich instabil werden kann werde ich jetzt mal wxwidgets probieren, da sind die exe dann ca 3MB was zwar 10x mehr als bei fltk ist aber noch hart an der grenze liegt was ich mir so vorstellen kann. Vorteil sind natürlich die nativen Widgets. Das mit den Schemes kling aber auch interessant.

Artchi

freizeit_programmierer schrieb:

ist irgendwie schade das nur du dran arbeitest, was passiert wenn du keine Lust mehr drauf hast oder dir was passiert?

Das ein Proejkt eingestellt wird, kann jedem Projekt passieren. Bei MySQL hat man auch das Zittern bekommen, als Oracle Sun aufkaufte.

Das Argument für OpenSource ist aber meistens, das falls es sterben sollte, man es wenigstens selber weiter entwickeln oder zumindest pflegen kann (z.B. an neue Betriebssystem-Versionen anpassen). Von Algierlib ist jedenfalls der gesamte Sourcecode und Dokumentation bei Tigris verfügbar! Falls ich morgen weg sein sollte, kann jeder weiter machen... ob für sich privat oder öffentlich ist egal.

Ich selber bastel jetzt über drei Jahre daran. Habe damals nach dem ersten Jahr alles über den Haufen geworfen und neu angefangen. Dann später wieder das Design geändert (speziell die Smartpointer-Geschichte). Dann ist noch das MVC dazu gekommen. Die Doku/Manual wird von mir meiner Meinung nach recht gut gepflegt, was mir auch wichtig ist.
Zur Zeit werden fünf Compiler von mir unterstützt, d.h. ich teste jedes Release mit diesen Compilern.
Auch sind jetzt Unittests für TDD dazu gekommen, auch wenn noch nicht alles abgedeckt wird.

Also, das macht schon alles Arbeit, und bisher habe ich noch nicht aufgegeben. Vieles geht auf Design und wie du sagst "seriösität" drauf, so das die Widget-Anzahl leider leiden muß. Aber ich finde, es bringt nichts, wenn ich alles mit Widgets voll stopfe, aber die "seriösität" leiden muß.

Vor sechs Monaten hatte ich die Lib hier vorgestellt, und es gab überwiegend gute Kritik. Ein paar Änderungswünsche sind auch schon eingeflossen. Es geht also immer weiter. Ich weiß aber auch in etwa, was noch alles an Features fehlt, um eine breitere Anwendermasse zu erreichen. Deshalb habe ich auch eine Roadmap, in der ich das geplant habe. Wenn diese Anwendermasse erreicht wird, wird auch das Risiko kleiner, das das Projekt stirbt.

Vielleicht haste auch die Chance, nach Fertigstellung der V1.0, dass du noch mehr Unterstürzung von guten Entwicklern erhälst. Ich gebe dir recht das die Qualität nicht zugrunde der Quantität aufgegeben werden sollte. Ich drücke dir das auf jeden Fall feste die Daumen

Qtianer schrieb:

Was will man denn noch mehr?

Modernes C++.

bietet ein ganzes Framework, dass auf fast jedem C++-Compiler, der je entwickelt wurde kompilierbar ist

Leider behindern sich die Entwickler mit diesem Anspruch eher selbst. Wozu soll das gut sein? Wer verwendet heute noch 10 Jahre alte Compiler?

Gruß,
Qtianer

Gebe dir Recht. Das ist aber auch der Grund weshalb Qt keine Exceptions verwendet; um die Kompatibilität zu älteren Compilern zu wahren.

l'abra d'or

Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.
Warum das Gedöhns mit eigener EVENT_TABLE? Dafür gibt es in C++ "virtual". Man kann sich dann halt keine eigenen Bezeichner ausdenken sondern muss bestimmte Virtuelle Funktionen implementieren. Aber wen scherts? Oder hat das EVENT_TABLE noch nen Vorteil, den ich nicht sehe?
Hier gab es mal ein böses Problem (SEGFAULT) durch diese EventTable, find ich leider nimmer...

Das andere was ich immer finde ist das "IMPLEMENT_APP", was scheinbar eine globale Variable anlegt. Will man das nutzen braucht es ein DECLARE_APP (oder?). Kann man da nicht gleich nen Singleton verwenden? Das erleichtert die Arbeit ungemein.

Wegen Qt und Moc:
Das macht schon noch mehr als nur SIGNAL/SLOT ermöglichen. Properties, z.B. Das wird dank Kinetic (Animations-Framework) richtig bequem, dank QPropertyAnimation. In 5 Zeilen hat man eine fertige Animation
Designer-Integration wird dadurch auch verdammt einfach.
QMetaObject ist auch ne feine Sache.

Und wer will kann auf den moc komplett verzichten. Der erstellt nur ein Sourcefile, das man natürlich auch selber schreiben kann, dann sollte man auf die nicht-C++-konformen Sachen und einen zusätzlichen Preprozessor verzichten können. Ist halt zusätzlicher, fehleranfälliger Zeitaufwand, aber dafür kann man alles "direkt kompilieren". moc machts halt automatisch und einfacher
Und die nötigen Tools kommen bei der Qt-Standardinstallation mit, also was solls

Wenn man über die Probleme hinwegsehen kann, bietet Qt halt einiges an Bequemlichkeiten.

Scorcher24

Du übersiehst etwas..
Wegen den Events:
Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen. Hat den selben Effekt. Diese Makros sind im Endeffekt ein überbleibsel als das so gängig war. Stichwort: Ähnlichkeit zu MFC schaffen. Kam von M$ das Gedöns :P. Ich finds nicht so übel, weil ich es halbwegs übersichtlich finde und solange es funktioniert... im Endeffekt sinds nur Makros, die eine Funktion implementieren mit eben diesen Bind() Commands bzw sowas ähnliches.

Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.

edit:
Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.

l'abra d'or

Scorcher24 schrieb:

Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen.

Ja, das hab ich auch gelesen. Trotzdem: Warum nicht gleich mit virtellen Methoden? Hast du ne Ahnung ob sich das mit wxWidgets-3.0 ändern wird? Ist halt ne zusätzliche Krücke. Wenn ich in Qt wissen will, was der Kerl jetzt mit der Maus anstellt, mach ich "Strg+F"->"mousePressEvent"->Enter->Ziel. So hab ich nen zusätzlichen Suchaufwand. Aber wahrscheinlich gibts eh Namenskonventionen, an die man sich hält.

Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.

Dann scheint es Qt in die lib auszulagern, denn da funktionieren Programme mit normalem Standard-C++-konformem "int main()", man legt ein QApplication-Objekt in der main() an, und auf allen Plattformen läuft es.

Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.

Das meinte ich mit "wenn man das nutzern will". Laut Doku macht das ne forward-declaration auf das app-Objekt.

l'abra d'or schrieb:

Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.
Warum das Gedöhns mit eigener EVENT_TABLE? Dafür gibt es in C++ "virtual". Man kann sich dann halt keine eigenen Bezeichner ausdenken sondern muss bestimmte Virtuelle Funktionen implementieren. Aber wen scherts? Oder hat das EVENT_TABLE noch nen Vorteil, den ich nicht sehe?

c++ verwendet vtable für virtuelle Funktionen, 4 Byte werden für jede virtuelle Funktion verwendet, egal ob überschrieben oder nicht.
Bei der Komplexität von MFC würde jedes Fenster eine ca 400 Byte große Tabelle mit sich rumschleppen.

l'abra d'or schrieb:

Scorcher24 schrieb:

Man muss diese Makros nicht benutzen. Man kann auch über Bind() dynamisch in die Events einsteigen.

Ja, das hab ich auch gelesen. Trotzdem: Warum nicht gleich mit virtellen Methoden? Hast du ne Ahnung ob sich das mit wxWidgets-3.0 ändern wird? Ist halt ne zusätzliche Krücke. Wenn ich in Qt wissen will, was der Kerl jetzt mit der Maus anstellt, mach ich "Strg+F"->"mousePressEvent"->Enter->Ziel. So hab ich nen zusätzlichen Suchaufwand. Aber wahrscheinlich gibts eh Namenskonventionen, an die man sich hält.

Das IMPLEMENT_APP-Makro hingegen ist wichtig. Es ist ein Makro, welches im Endeffekt die Main einsetzt, damit der Linker sich nicht wegen fehlender WinMain oder _main beschwert. Das sorgt für Platformunabhängigkeit und ist schöner als tausend #ifdefs wenn Du ein Programm für als bsp Handheld und M$ Windows kompilierst.

Dann scheint es Qt in die lib auszulagern, denn da funktionieren Programme mit normalem Standard-C++-konformem "int main()", man legt ein QApplication-Objekt in der main() an, und auf allen Plattformen läuft es.

Nein, DECLARE_APP brauchts nicht unbedingt. Nur wenn man in anderen Klassen auf das einzigste wxApp Element zugreifen will...
rya.

Das meinte ich mit "wenn man das nutzern will". Laut Doku macht das ne forward-declaration auf das app-Objekt.

Is doch egal wie es Qt macht, bedenke das wxWdigets wirklich freie Software ist, im Gegensatz zu Qt wo du dich denen fügen musst, auch wenn es viel besser geworden ist so kannst du denn noch nicht machen was du willst damit, da es doch kommerziell ist.

Ich persönlich kenne keine Alternative zu wxWidgets wo man mit machen kann was man will. Für viele reicht es einfach, und es muss auch nicht immer alles perfekt sein um Spass zu machen. Ich kenne Leute die programmieren 8bit Assembler und haben jede Menge Freude dran.

Wenn dir Qt soviel besser gefällt nimm es doch und gut ist, anderen gefällt es halt nicht, basta. Es gibt nun mal nicht das perfekte Framework für alle.

Artchi

Zabou schrieb:

c++ verwendet vtable für virtuelle Funktionen, 4 Byte werden für jede virtuelle Funktion verwendet, egal ob überschrieben oder nicht.
Bei der Komplexität von MFC würde jedes Fenster eine ca 400 Byte große Tabelle mit sich rumschleppen.

Und?

Artchi

l'abra d'or schrieb:

Was mir an wxWidgets nicht gefällt ist diese Makro-Lastigkeit.

...

Das macht schon noch mehr als nur SIGNAL/SLOT ermöglichen. Properties, z.B. Das wird dank Kinetic (Animations-Framework) richtig bequem, dank QPropertyAnimation. In 5 Zeilen hat man eine fertige Animation
Designer-Integration wird dadurch auch verdammt einfach.
QMetaObject ist auch ne feine Sache.

Komische Logik. Du beschwerst dich über die Makros in wx, aber die Makros in Qt stellst du als Vorteil.

Entweder man findet Makros schlimm, oder nicht. Warum sind die Qt/Moc-Makros nicht schlimm, oder sogar gut?.

Nimm den nicht zu ernst, der trollt gerne mal etwas rum. Die Kommentare kann man zu 90% ignorieren wenn es um qt zu wxwidgets geht.