Ich möcht gerne für mich ein GUI Programm schreiben. Zahlreiche Softwarehersteller haben bei ihren eigenen Programmen dieses typische, neue Windows Design, wie Windows in Word, Excel und Co., also mit dieser großen Menüleiste, großen Buttons usw. Es gibt dafür also sicher ein Framework. Kann mir jemand ein Stichwort dazu geben, wie ich eine GUI in diesem Style programmieren kann?
Moin, die Dinger nennt man Ribbons. Auch wenn die Frage ein wenig seltsam anmutet würde ich dir C# empfehlen. Für QT gibts aber auch entsprechende Sachen, also such dir was raus ^^
Martin schrieb: > neue Windows Design, wie Windows in Word, Excel und Co., also > mit dieser großen Menüleiste, großen Buttons usw. Martin schrieb: > wie ich eine GUI in diesem > Style programmieren kann? Und warum um Himmels Willen will man das? Gruss Chregu
>Für QT gibts aber auch entsprechende Sachen
Als Linux Benutzer stimme ich natürlich für ein portables Framework. Für
Windows findet man sowieso schon genug gute Programme.
Wenn du wenig Ahnung hast und es trotzdem in kurzer Zeit zu einem ansehnlichen Ergebnis bringen möchtest, führt wohl kein Weg an MS Visual Studio.NET vorbei. Die kostenlose Community Version reicht sicher. Wenn c# noch zu schwierig ist, gibts immer noch das guta alte VB.net ;) https://visualstudio.microsoft.com/de/
Mit der MFC lässt sich das auch erledigen, allerdings sind dann noch Zusatzwerkzeuge wie z.B. BCGControlBar zu kaufen. Ohne diese bleibt die GUI im ältlichen Windows-7-Stil, auch wenn die Programme unter neueren Windows-Versionen eingesetzt werden. Eine Unterstützung für die Kachel-GUI bietet die MFC ebenfalls nicht an, o.g. BCGControlBar-Paket aber unterstützt das. Wenn man zwar C++, aber nicht die MFC verwenden möchte, lohnt ein Blick zu wxWidgets oder dem bereits erwähnten Qt. Beides hat den Vorteil der Portabilität, d.h. damit lassen sich auch Programme für macOS und Linux erzeugen. Wenn man eher Basic mag, wäre Xojo einen Blick wert, das hieß früher "RealBasic" und ist ebenfalls ein plattformübergreifendes Werkzeug.
Volker Volkersson schrieb: > Wenn du wenig Ahnung hast und es trotzdem in kurzer Zeit zu einem > ansehnlichen Ergebnis bringen möchtest, führt wohl kein Weg an MS Visual > Studio.NET vorbei. Oder anders gesagt: Wenn du keine Ahnung hast, aber in kurzer Zeit einen schlechten unsicheren Codehaufen produzieren willst, führt wohl kein Weg an MS Visual Studio.NET vorbei. Ansonsten benutz was gutes wie C++ und QT.
>>Wenn du keine Ahnung hast, aber in kurzer Zeit einen schlechten >>unsicheren Codehaufen produzieren willst, führt wohl kein Weg an MS >>Visual Studio.NET vorbei. >>Ansonsten benutz was gutes wie C++ und QT. C++ ist deutlich komplexer und schwieriger als C#. Mit MS Visual Studio.NET und C# wird man als Einsteiger sicherlich schneller zum Ergebnis kommen. Als Ergebnis meine ich ein funktionierendes und stabil laufendes GUI Programm.
Christian M. schrieb: > Und warum um Himmels Willen will man das? Die Frage habe ich mir auch gestellt. Seit der Abschaffung von Menüs und der Umstellung auf diese unsäglichen Ribbons ist Microsoft Office für mich quasi unbenutzbar geworden. Ich frage mich, wie man auf so eine schräge Idee erst mal kommt, und wie sie sich dann auch noch durchsetzen kann. Rufus Τ. F. schrieb: > Ohne diese bleibt die > GUI im ältlichen Windows-7-Stil, auch wenn die Programme unter neueren > Windows-Versionen eingesetzt werden. Mal ganz ehrlich, mir persönlich sagt der freundliche frische Win7-Look wesentlich mehr zu, als dieses Design von Windows 10, das aussieht, als hätte man versucht, die Grafik so weit zu vereinfachen, daß selbst die alte S3 Virge mit nem halben MB Speicher sie wieder flüssig darstellen kann. Alles unkoordiniert duster, Bedienelemente werden teilweise erst hervorgehoben, wenn man mit der Maus drüber geht (Ich will eine Benutzeroberfläche, kein Wimmelbildspiel!).. näh. Ich merke den Produktivitätsunterschied bei der Arbeit. Da, wo Windows 7 drauf ist, brauche ich für vieles halb so viel Zeit wie da, wo Windows 10 drauf ist, weil ich immer nach dem passenden Button suche.
Mein Fall sind die Ribbons auch nicht, aber unsere Roadmap sieht eine Implementierung in dieser Richtung vor. Da wir im .NET unterwegs sind, haben wir unter anderem Fluent.Ribbon evaluiert. Mir persönlich gefällt es gut. Was hier und da nicht passt, kann man selbst im Code anpassen. Das ist für mich der grösste Vorteil. So sieht es aus: https://github.com/fluentribbon/Fluent.Ribbon/blob/develop/Images/Showcase.gif
Beitrag #5854094 wurde von einem Moderator gelöscht.
Tutorial für Windows, ios und Android Apps mit Oberfläche https://docs.microsoft.com/de-de/visualstudio/get-started/csharp/?view=vs-2019
Unter allen obigen Voraussetzungen würde ich ebenfalls C++/Qt nehmen. Ich würde auf jeden Fall auch an die Zeit nach Windows denken und mich bei stetig steigendem Wasserstand nicht für alle Zeit auf einer kleinen Insel festketten lassen wollen.
Wenn sich das GUI-Programm als Web-App schreiben lässt, z.B. mit asp.net core, dann würde ich das in Erwägung ziehen. Selbst als reine lokale Anwendung ist asp.net möglich und sinnvoll mit verwendung des localhost-servers (IIS). Vorteil: man kann die SW leicht online stellen und Dienste als SAAS anbieten, wenn man möchte.
Ich musste mir die Frage Ende letzten Jahres stellen, als es um die Modernisierung einer legacy-Anwendung in MFC/C++ ging. Ich hatte nach der Einführung von Office 2007 auch grosse Probleme mit den ribbons und habe eine ganze Weile gebraucht, mich damit anzufreunden, und war deswegen zuerst skeptisch. Inzwischen mag ich sie. Die Dokumentation des ribbon-Frameworks der MFC ist sehr gut, und mit dem Ribbon-Designer, der den XML-Code erstellt, kann man sogar die Anwender in das Design mit einbinden. Wichtig ist, sich mit der Philosophie der Ribbons auseinanderzusetzen: Oft benötigte Funktionen sind direkt zugänglich und nicht erst über ein Dialogbox (die es zusätzlich geben kann), und der Einfluss mancher Optionen auf das Ergebnis ist als Vorschau direkt und interaktiv sichtbar. Ich empfehle, sich vorher ein paar Gedanken über Struktur und ggf. Workflow zu machen, damit die Optionen in den Panels landen, wo sie intuitiv erwartet werden. Der neue Ribbon, wie er im aktuellen Office zu sehen ist, wurde von Microsoft extern entwickeln lassen und dazugekauft. Mit Visual Studio wird lediglich das Framework von 2007 geliefert, ich bin jedoch der Meinung, dass dies in den meisten Fällen völlig ausreichend ist. Eine nachträgliche Migration zum weiter oben erwähnten BCGControlBar scheint mir einfach und jederzeit machbar (hab's noch nicht gemacht, nur etwas Doku gelesen).
Zumindest ich komme bei diesem Stil (Ribbons) durcheinander: man sucht dort nach einem Befehl, findet ihn nicht, und realisiert irgendwann, dass man im falschen Ribbon ist. Eine statische Leiste mit oft benötigten Funktionen finde ich besser. Selten gebrauchte Funktionen kann man in Untermenüs verpacken.
Das Ribbon-Konzept sehe ich als echten Fortschritt in der Benutzerfreundlichkeit. Allerdings passt es nicht zu jedem Programm. Die Vorteile sind klar: Symbol und Text sind kombiniert, das ermöglicht ein intuitives Erlernen. Anfänglich ist man auf den Text angewiesen, mit Routine führen die Symbole zu mehr Übersicht und schnellerem Arbeiten. Der Ribbon ist entweder kontextbezogen oder kategorisiert. Dadurch ist erst genug Platz im Menü für die Text-/Symbolkombination. Natürlich muss das Ribbon-Menü gut durchdacht sein. Das mag etwas schwieriger sein wie beim klassischen Menü, welches man aber auch vermurksen kann.
Wer sich ganz ans Windows-System binden will, kann ab W10 1903 auch XAML-Islands in klassischen W32-Anwendungen verwenden... https://docs.microsoft.com/de-de/windows/apps/desktop/modernize/xaml-islands und dann bspw. so etwas https://blogs.msdn.microsoft.com/juanmejia/2017/10/office-ribbon-styling-the-pivot-control/ machen. FreePascal/Lazarus + BGRAControls wäre auch noch eine Möglichkeit. Ebenso geht's mit Avalonia UI (XAML-basiert wie WPF/UWP, aber auch auf Linux, MacOS, iOS und Android zu Hause) oder man nimmt/hostet ein WebBrowser-Control und entsprechende JavaScript-Libraries (gibt's/gab's von MS https://github.com/OfficeDev/office-ui-fabric-react) oder nutzt gleich "Frameworks" wie Electron... Wie sinnvoll diese Optionen hier wären, ist eine andere Frage...
:
Bearbeitet durch User
Bernd K. schrieb: > Ich würde auf jeden Fall auch an die Zeit nach Windows denken Ob wir die noch erleben? :-)
C# mit WPF, wenn es eine reine Windows Applikation wird, ansonsten Qt mit Qml, daran stört mich nur das der Java Interpreter kein uint64 versteht und es etwas umständlich ist solche Datentypen über C++ Backend reinzuholen
Rufus Τ. F. schrieb: > lohnt ein Blick > zu wxWidgets oder dem bereits erwähnten Qt. Wie weit wird wxWidgets noch weiter entwickelt? Ich habe den Eindruck, dass das kaum noch voran kommt.
Das letzte Release ist vom Dezember 2018, es wird also offensichtlich weiterentwickelt. Oder erwartest Du "agile" Releasezyklen?
Nachdenklicher schrieb: > Christian M. schrieb: >> Und warum um Himmels Willen will man das? > > Die Frage habe ich mir auch gestellt. Seit der Abschaffung von Menüs und > der Umstellung auf diese unsäglichen Ribbons ist Microsoft Office für > mich quasi unbenutzbar geworden. Ich frage mich, wie man auf so eine > schräge Idee erst mal kommt, und wie sie sich dann auch noch durchsetzen > kann. Wie man auf die Idee kommt, nach dem Umstieg von 4:3 Monitoren auf 16:9, auch noch den in der Höhe kleiner gewordenen Platz mit mehr Fläche für Buttons zu verschwenden, geht mir auch nicht auf.
Max M. schrieb: > Bernd K. schrieb: >> Ich würde auf jeden Fall auch an die Zeit nach Windows denken > > Ob wir die noch erleben? :-) Das kann ja jeder für sich entscheiden. Man muss ja nicht der letzte sein, der dann die Tür - äh - das Fenster zumacht. ;-)
Der Trend ist aber: https://saasmag.com/the-evolution-of-saas-4-trends-to-watch-in-2019/ Die Zeit ist einfach (fast) vorbei, wo Programme auf einen lokalem Rechner installiert werden.
Freiberufler schrieb: > https://saasmag.com/the-evolution-of-saas-4-trends-to-watch-in-2019/ > > Die Zeit ist einfach (fast) vorbei, wo Programme auf einen lokalem > Rechner installiert werden. Gut dass die Überschrift "Incorporation of Artificial Intelligence (AI)" so groß und fett und schon von Weitem lesbar ist. Da konnte ich direkt wieder das Lesen aufhören.
:
Bearbeitet durch User
Freiberufler schrieb: > Die Zeit ist einfach (fast) vorbei, wo Programme auf einen lokalem > Rechner installiert werden. Der Trend ist mal so und mal so, alle Extreme sind schon dagewesen und kommen immer wieder. Erst hatten wir Mainframes und dumme Terminals, dann kamen irgendwann die "personal computer" in Mode und alle Apps liefen lokal und der Mainframe war tot, dann kam das www und es hieß es lokale Anwendungen sind unpraktisch, nur noch Web-Anwendungen sind der heilige Gral (180-Grad-Wende). Dann kamen die Smartphones auf und da ist es wieder absolut schick daß als Ersatz für jede popelige bereits existierende Webanwendung plötzlich wieder auf jedem Gerät eine eigene lokale App installiert werden muß.
> Erst hatten wir Mainframes und dumme Terminals,
Da hatten wir aber noch kein breit verfügbares Internet.
Jetzt ist aber so, dass quasi schon jedes Smartphone und PC sowieso am
Inet permanent angeschlossen ist.
Dass sich dieser Trend (Vernetzung) jemals umkehrt, ist
unwahrscheinlich.
Zensuren werden schon zunehmen, aber zurück zu den Offline-PCs ist
unmöglich.
Damit steht SaaS jederzeit zur Verfügung, und die Vorteile ggü
fest-installierter SW überwiegen.
Freiberufler schrieb: > Damit steht SaaS jederzeit zur Verfügung, und die Vorteile ggü > fest-installierter SW überwiegen. Klar, vor allem für den Anbieter, der dann monatlich abkassieren kann. Wo kämen wir denn hin, wenn jeder seine vor 10 Jahren gekaufte Software einfach weiternutzt, anstatt jedes Update zu kaufen... Freiberufler schrieb: > Da hatten wir aber noch kein breit verfügbares Internet. > > Jetzt ist aber so, dass quasi schon jedes Smartphone und PC sowieso am > Inet permanent angeschlossen ist. Genau, und was passiert wenn die Internetverbindung mal gestört ist? Dann sitzen die Mitarbeiter sinnlos in der Firma rum, bis die tolle SaaS wieder verfügbar ist. Für Privatpersonen mag Warten vielleicht noch zumutbar sein, aber einer Firma kostet das eine Stange Geld.
> wenn jeder seine vor 10 Jahren gekaufte Software einfach weiternutzt,
Genau das ist der Haupt-Punkt.
Wenn jemand 10 Jahre lang ein Software-Produkt intensiv benutzt, und ein
anderer das gleiche Produkt nur sporadisch,
dann bezahlen beide bei der Festinstallation den gleichen Preis(!!!)
- SaaS ermöglicht eine gerechte Bezahlung,
- jeder Installations-Aufwand entfällt,
- bei Wechsel des Rechners entfällt die Neuinstallation,
- ...
Das gestörte Netz ist ein Problem.
Aber seien wir ehrlich, wie oft passiert das?
Das mit den "gerechteren" Kosten mag theoretisch stimmen, aber praktisch gesehen zahlt man meistens drauf, vor allem wenn man nicht jedes Update kauft. Aber für den einen oder anderen Fall mag das ganz praktisch sein, wenn man eine bestimmte Software nur ein mal bzw. über einen kurzen Zeitraum benötigt, zugegeben. Und gekaufte lokale Software hat noch einen weiteren unschlagbaren Vorteil: Wenn der Anbieter einer SaaS Lösung pleite geht oder den Service einstellt, hat man schlicht und einfach die A-Karte gezogen, das Ding ist dann einfach endgültig weg. Gekaufte lokal installierte Software kann ich einfach weiternutzen, egal was mit dem Anbieter passiert.
Kennt jemand SaaS - Software-Produkte für Firmen und Privatanwender ? Office 365 wird meistens genannt, z.B. https://www.cmswire.com/cms/information-management/cloud-service-models-iaas-saas-paas-how-microsoft-office-365-azure-fit-in-021672.php Compiler wäre praktisch und sinnvoll als SaaS, habe ich aber noch nicht gehabt, meistens hat man einen Lizenz-Dongle, den man im Schreibtischen von Kollegen erst suchen muss.
steckersammler schrieb: > Gekaufte lokal installierte Software kann ich einfach weiternutzen, egal > was mit dem Anbieter passiert. Die werden doch mittlerweile alle online Aktiviert, damit hat man das gleiche Problem. Im schlimmsten Fall gibt es sogar Always Online DRM, wo eine Anwendung einige Funktionen grundlos auf den Server packt und konstant prüft, ob man verbunden ist, um zu garantieren, das man das ohne Internet oder wenn Server offline genommen werden die Anwendung garantiert nicht mehr nutzen kann. Eigentlich schon komisch, wie Firmen ihre Kunden mittlerweile enteignen dürfen, oder es denen eventuell mittlerweile egal ist. Bei freier Software hat man das zum glück eigentlich nie. Sowas käme bei respektablen Distributionen wie z.B. Debian nie in main rein, höchstens nach contrib oder non-free. In Zweifelsfall sollte man aber selbst dort selbst nochmal nachkontrollieren.
Nachdenklicher schrieb: > Seit der Abschaffung von Menüs und > der Umstellung auf diese unsäglichen Ribbons ist Microsoft Office für > mich quasi unbenutzbar geworden. geht mir auch so. dagegen hilft https://www.officeclassicmenu.com/de/download.php oder http://www.ubit.ch/software/ubitmenuoffice2007/
:
Bearbeitet durch User
DPA schrieb: > Eigentlich schon komisch, wie Firmen ihre Kunden mittlerweile enteignen > dürfen, oder es denen eventuell mittlerweile egal ist. Der überwiegenden Zahl der Anwender ist es egal weil sie das Problem einfach nicht erkennen (können) oder es erfolgreich verdrängt haben, deshalb bekommst Du niemals eine Mehrheit mobilisiert gegen diese unerfreuliche Praxis. > Bei freier Software hat man das zum glück eigentlich nie. Anwender freier Software haben im Schnitt ein erheblich höheres Bildungsniveau und einen höheren IQ, deshalb kannst Du denen sowas nicht ohne weiteres verkaufen.
:
Bearbeitet durch User
Beitrag #5871642 wurde von einem Moderator gelöscht.
Ich stimme einigen vorherigen Antworten voll und ganz zu! Sollte sich das GUI-Programm als Web-App schreiben lassen, kann man das in Betracht ziehen. Auch eine reine lokale Anwendung ist asp.net möglich und macht unter Verwendung des localhost-servers (IIS) Sinn. Der Vorteil ist, dass man die SW einfach online stellen kann und dabei die Dienste als SAAS anbieten kann. Gruß, MelNell https://mobilunity.ch/blog/nearshoring-rumanien-wie-gunstig-und-sinnvoll-ist-es-entwickler-in-rumanien-einzustellen/
Rufus Τ. F. schrieb: > Mit der MFC lässt sich das auch erledigen Ist das jetzt ein Ratschlag der Kategorie "Wie reitet man ein totes Pferd"? Wenn er etwas neues lernt, weil er Neuland betritt, dann doch bitte nicht diesen uralten, total verhunzten MFC Schrott, sondern etwas, das aktuell entwickelt und eingesetzt wird, wie .NET oder andere aktuelle Sprachen mit aktuellen Frameworks. Also kein MFC, kein WPF, Flash, irgendwelches altgedientes Java Zeugs.
Martin S. schrieb: > wie .NET oder andere aktuelle > Sprachen mit aktuellen Frameworks. > > Also kein MFC, kein WPF Ist WPF nicht Teil von .NET?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.