- bisher können wir das GUI nur aktiv intern schließen, -
-- indem wir ein GTK-Signal erzeugen, das das Hauptfenster schließt -
- -- ...das war genau der Kern der "Plugin-Debatte". -
-- Eine solche globale, flache, dynamisch gebundene Ebene -
-- klingt nach wahnsinnigen Möglichkeiten, aber nur solange, bis man sich -
-- eine einzige Funktion konkret durchdenkt: es läuft auf Spaghetti-Code hinaus -
- - -- jede Facade-Funktion brauch einen Dispatcher -
-- Das wird eine ganze Me -
- - -- bevor die Facade geöffnet wir -
- - -- und arbeitet asynchron -
- - -- Argument-Storage -
-- organisieren -
- - -- brauche dedizierten Dispatcher -
- - -- ...könnte das am Ende nicht sinnvoll sein, -
-- speziell den UI-Shutdown-Trigger über den neuen Mechanismus laufen zu lassen, -
-- obwohl jener doch genau der Anlaß war, diesen neuen Mechanismus zu bauen. -
- - -- wenn die Queue voll ist -
-- wird erst alles Andere abgearbeitet -
- - -- wenn UI-Thread blockt/verhungert, -
-- kommt der rettende Shutdown gar nicht durch -
- - -- ...indem der NotificatonService nun vom UI-Manager gemanaged wird :) -
- - -- zieht komplett-Umbau -
-- des Gui-top-Level nach sich -
- -- ...nur eine heuristische Vermutung von mir -
-- stützt sich auf folgenden Quellcode -
-- -
-- Application::Application(const Glib::ustring& application_id, Gio::ApplicationFlags flags) -
-- : -
-- // Mark this class as non-derived to allow C++ vfuncs to be skipped. -
-- //Note that GApplication complains about "" but allows NULL (0), so we avoid passing "". -
-- Glib::ObjectBase(0), -
-- Gio::Application(Glib::ConstructParams(custom_class_init(), "application_id", (application_id.empty() ? 0 : application_id.c_str()), "flags", GApplicationFlags(flags), static_cast<char*>(0))), -
-- m_argc(0), -
-- m_argv(0) -
-- { -
-- gtk_init(0, 0); -
-- } -
- -+ ...das ist nützlich zur Diagnose, +
++ jede Facade-Funktion brauch einen Dispatcher +
++ Das wird eine ganze Me +
+ ++ bevor die Facade geöffnet wir +
+ ++ und arbeitet asynchron +
+ ++ Argument-Storage +
++ organisieren +
+ ++ brauche dedizierten Dispatcher +
+ ++ ...könnte das am Ende nicht sinnvoll sein, +
++ speziell den UI-Shutdown-Trigger über den neuen Mechanismus laufen zu lassen, +
++ obwohl jener doch genau der Anlaß war, diesen neuen Mechanismus zu bauen. +
+ ++ wenn die Queue voll ist +
++ wird erst alles Andere abgearbeitet +
+ ++ wenn UI-Thread blockt/verhungert, +
++ kommt der rettende Shutdown gar nicht durch +
+ ++ bisher können wir das GUI nur aktiv intern schließen, +
++ indem wir ein GTK-Signal erzeugen, das das Hauptfenster schließt +
+ + ++ ...das war genau der Kern der "Plugin-Debatte". +
++ Eine solche globale, flache, dynamisch gebundene Ebene +
++ klingt nach wahnsinnigen Möglichkeiten, aber nur solange, bis man sich +
++ eine einzige Funktion konkret durchdenkt: es läuft auf Spaghetti-Code hinaus +
+ + ++ ...indem der NotificatonService nun vom UI-Manager gemanaged wird :) +
+ + ++ zieht komplett-Umbau +
++ des Gui-top-Level nach sich +
+ ++ ...nur eine heuristische Vermutung von mir +
++ stützt sich auf folgenden Quellcode +
++ +
++ Application::Application(const Glib::ustring& application_id, Gio::ApplicationFlags flags) +
++ : +
++ // Mark this class as non-derived to allow C++ vfuncs to be skipped. +
++ //Note that GApplication complains about "" but allows NULL (0), so we avoid passing "". +
++ Glib::ObjectBase(0), +
++ Gio::Application(Glib::ConstructParams(custom_class_init(), "application_id", (application_id.empty() ? 0 : application_id.c_str()), "flags", GApplicationFlags(flags), static_cast<char*>(0))), +
++ m_argc(0), +
++ m_argv(0) +
++ { +
++ gtk_init(0, 0); +
++ } +
+ +