|
|
|
GNOME entfernt AppMenu wieder
|
AppMenu wird endlich abgeschafft. Hat lange gebraucht bis Sie es eingesehen haben - endlich.
Das hat nie funktioniert. Es gibt keinen guten Grund das Anwendungsmenü aus dem Anwendungsfenster zu nehmen. Endlich wieder vernünftig mit zwei Bildschirmen arbeiten
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 26.06.2018 11:45]
|
|
|
|
|
|
Es gibt auch keinen guten Grund dafür Gnome3 zu verwenden.
|
|
|
|
|
|
|
Jetzt müssten sie nur noch ihre hirntoten Dateidialoge fixen und dann könnte man Gnome schon fast für grundlegende Aufgaben verwenden.
Bei AppMenu muss ich irgendwie an die Unity-Suche denken. Die haben die ja so schön von Windows 7 abgekupfert, dass sie sogar die ewigen Ladezeiten für Suchergebnisse kopiert haben! Ein paar hundert kleine Textdateien durchsuchen, da finde ich fünf Sekunden absolut angemessen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.06.2018 12:04]
|
|
|
|
|
|
Wobei ich AppMenu für die verschlimmerte Version der MacOS-Menüleiste halte. Mit dem Dateidialog komme ich gut klar
|
|
|
|
|
|
|
| Zitat von MartiniMoe
Und dazu dann den dotmgr
| |
Davon gibt es nichtmal ein AUR-Paket, das macht mir irgendwie Sorgen . Laut Archwiki gibt es noch etwa 200 andere solcer Tools. Bisher benutze ich eine selbst gebaute Lösung, aber die hat keine Intelligenz für verschiedene Hosts und das ist durchaus öfter mal nervig. Allerdings hat das bisher auf wirklich allen Hosts funktioniert. Gibt es bei dotmgr ein "notfall-deployment" wenn auf einem Host kein Python ist?
(Danke für deinen Hinweis, rats)
|
|
|
|
|
|
|
| Zitat von hoschi
Mit dem Dateidialog komme ich gut klar
| |
Eh, du bist ja auch komisch.
e: Sicherlich masochistisch veranlagt. (Wörterbuch schlägt vor: stochastisch m(
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.06.2018 21:10]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Zitat von csde_rats
Jetzt müssten sie nur noch ihre hirntoten Dateidialoge fixen und dann könnte man Gnome schon fast für grundlegende Aufgaben verwenden.
| |
uhh ja, die schaffens echt immer wieder was neues da reinzupacken wo ich mir vorher dachte dass es schlimmer echt nimmer kommen kann.
dass sie dateien und verzeichnisse wild durcheinander gemixt haben konnte man ja noch ändern indem man ne option wieder gesetzt hat um zuerst verzeichnisse und dann die dateien zu haben.
aber dass mittlerweile wenn man lostippt das nichtmehr nur im aktuellen ordner sucht sondern "irgendwie überall"(tm) und sich das afaik auch nichtmehr so leicht ändern lässt (derjenige der mich hier widerlegt kriegt nen bier!) hat schon ne ganz neue qualität von "wollt ihr mich verarschen?"
|
|
|
|
|
|
|
|
|
|
|
| Zitat von [KdM]MrDeath
| Zitat von csde_rats
Jetzt müssten sie nur noch ihre hirntoten Dateidialoge fixen und dann könnte man Gnome schon fast für grundlegende Aufgaben verwenden.
| |
uhh ja, die schaffens echt immer wieder was neues da reinzupacken wo ich mir vorher dachte dass es schlimmer echt nimmer kommen kann.
dass sie dateien und verzeichnisse wild durcheinander gemixt haben konnte man ja noch ändern indem man ne option wieder gesetzt hat um zuerst verzeichnisse und dann die dateien zu haben.
aber dass mittlerweile wenn man lostippt das nichtmehr nur im aktuellen ordner sucht sondern "irgendwie überall"(tm) und sich das afaik auch nichtmehr so leicht ändern lässt (derjenige der mich hier widerlegt kriegt nen bier!) hat schon ne ganz neue qualität von "wollt ihr mich verarschen?"
| |
Ich packe in manchen Ordnern "_" vor die Namen von Unterordnern, damit diese immer ganz am Anfang stehen.
... seit einiger Zeit sortieren manche Programme "schlauer", sodass "_oss" jetzt irgendwo bei "New_Folder" rumhängt
|
|
|
|
|
|
|
| Zitat von hoschi
AppMenu wird endlich abgeschafft. Hat lange gebraucht bis Sie es eingesehen haben - endlich.
Das hat nie funktioniert. Es gibt keinen guten Grund das Anwendungsmenü aus dem Anwendungsfenster zu nehmen. Endlich wieder vernünftig mit zwei Bildschirmen arbeiten
| |
Können sie jetzt bitte auch mal bei Evince sinnvolle Dialogfenster einbauen? Schlimm genug dass das der beste verfügbare PDF-Viewer ist (seit llpp bei mir zuverlässig abstürzt), aber ich schaffe es immer noch nicht, zu raten welche Funktion sich jetzt hinter dem linken und welche hinter dem rechten Button versteckt
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 26.06.2018 23:18]
|
|
|
|
|
|
| Zitat von B0rG*
| Zitat von MartiniMoe
Und dazu dann den dotmgr
| |
Davon gibt es nichtmal ein AUR-Paket, das macht mir irgendwie Sorgen . Laut Archwiki gibt es noch etwa 200 andere solcer Tools. Bisher benutze ich eine selbst gebaute Lösung, aber die hat keine Intelligenz für verschiedene Hosts und das ist durchaus öfter mal nervig. Allerdings hat das bisher auf wirklich allen Hosts funktioniert. Gibt es bei dotmgr ein "notfall-deployment" wenn auf einem Host kein Python ist?
(Danke für deinen Hinweis, rats)
| |
Hat ein Freund von mir entwickelt Ist aber in PyPI
Notfall-Deployment hats bisher nicht. Aber wie sollte dotmgr auf einem Host laufen, der kein Python hat?
| Zitat von Danzelot
| Zitat von hoschi
AppMenu wird endlich abgeschafft. Hat lange gebraucht bis Sie es eingesehen haben - endlich.
Das hat nie funktioniert. Es gibt keinen guten Grund das Anwendungsmenü aus dem Anwendungsfenster zu nehmen. Endlich wieder vernünftig mit zwei Bildschirmen arbeiten
| |
Können sie jetzt bitte auch mal bei Evince sinnvolle Dialogfenster einbauen? Schlimm genug dass das der beste verfügbare PDF-Viewer ist (seit llpp bei mir zuverlässig abstürzt), aber ich schaffe es immer noch nicht, zu raten welche Funktion sich jetzt hinter dem linken und welche hinter dem rechten Button versteckt
https://i.imgur.com/QRRkXuk.png
| |
Das ist echt so dumm Geht mir genau so!
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von MartiniMoe am 26.06.2018 23:41]
|
|
|
|
|
|
Es ist wirklich dumm. Ihr dürfte gerne in deren Gitlab einen Bug aufmachen, ich stimme dafür
Meine Theorie:
- Werkzeug: Alles was die Betrachtungweise verändert
- Hamburger: Klassische Menüoperationen, wie Öffnen, Speichern, Drucken, Eigenschaften und so weiter.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 27.06.2018 11:18]
|
|
|
|
|
|
| Zitat von Danzelot
| Zitat von hoschi
AppMenu wird endlich abgeschafft. Hat lange gebraucht bis Sie es eingesehen haben - endlich.
Das hat nie funktioniert. Es gibt keinen guten Grund das Anwendungsmenü aus dem Anwendungsfenster zu nehmen. Endlich wieder vernünftig mit zwei Bildschirmen arbeiten
| |
Können sie jetzt bitte auch mal bei Evince sinnvolle Dialogfenster einbauen? Schlimm genug dass das der beste verfügbare PDF-Viewer ist (seit llpp bei mir zuverlässig abstürzt), aber ich schaffe es immer noch nicht, zu raten welche Funktion sich jetzt hinter dem linken und welche hinter dem rechten Button versteckt
https://i.imgur.com/QRRkXuk.png
| |
urgs, evince hat den quatsch auch?
finde gedit ist absolut krass unbenutzbar geworden seitdem es das selbe layout hat... ich mein wer kommt auf so ne idee, wirklich?
es war auch irgendwas(tm) nicht möglich, hab aber erfolgreich verdrängt was...
|
|
|
|
|
|
|
Ich denke das klassische Anwendungsmenü und Symbolleiste waren immer eine gute Sache, nur eben häufig überladen und im Konflikt mit dem Kontextmenü und der möglichen Symbolleiste. Das ist für viele Anwender verwirrend, zumal man es als Experte sowieso über Tastenkombinationen arbeiten kann. Auftritt CSD, mit dessen Hilfe man die Oberfläche kompakter halten kann und eventuell bei einfachen Anwendung zusätzlich aufräumen könnte.
Was in der Beschreibung zur Ablösung des AppMenu steht irritiert mich "No other pla(t)form has this pattern". Die Grundidee das Menü vom Fenster zu lösen kommt von Apple und ich halt das bei Apple schon grundsätzlich für falsch, das Menü gehört zur Anwendung und man sollte den Weg zwischen Anwendungsoberfläche und Menüleiste kurz halten.
Das trifft jetzt auf CSD und beides bietet wenig Platz um komplexe Menüs ordentlich abzubilden. Sie täten gut daran in Ihren Styleguides den Einsatz von CSD zu minimieren und Anwendungsmenüs wieder ganz regulär zu verwenden, Evolution dabei geblieben. Ich will da gar nicht Apple kritisieren, die Tauschen mir Ideen nur immer undurchdacht aus.
Ich nehme mal an Apple hat das Problem mit dem Mehrschirmbetrieb irgendwie gelöst. Das Anwendungsmenü wird auf allen Bildschirmen angezeigt, oder?
|
|
|
|
|
|
|
https://news.ycombinator.com/item?id=17415871
not-sure-if-hackernews-or-troll
|
I need a very good reason before using any external library in an attempt to keep the total code base as clean as possible.
It is just too easy to be rushed and bring in a heap of code, so I prefer to use SQL instead of ORM's.
All access to the database is done in a single module and they are wrapped in functions like below
|
Code: |
def get_table_as_list(user_id, cols, tbl, where_clause, params_as_list, conn_str, order_by="1", maxrows='2000'):
"""
This should be the ONLY place that selects from the database
"""
db = get_db_conn(conn_str)
cur = db.cursor()
where_clause += ' AND user_id = %s'
sql = "SELECT " + cols + " FROM " + tbl + " WHERE " + where_clause + " ORDER BY " + order_by + " LIMIT " + maxrows
params_as_list.append(str(user_id))
cur.execute(sql, params_as_list)
res = list(cur.fetchall())
cur.close()
db.close()
return res |
|
The database is designed and built first, then in the application the definitions are done like below
|
Code: |
all_tables = [
{'tbl':'as_note',
'cols':['id','title','pinned', 'important','content','folder'],
'col_types':['id','Text','Checkbox','Checkbox', 'Note','Text'],
},
{'tbl':'as_task',
'cols':['id','Title','Pinned', 'Important','Notes','folder','Done'],
'col_types':['id','Text','Checkbox','Checkbox','Note','Text','Checkbox'],
}]
|
|
So far it is working well, and it is very simple to add new tables to the schema and have them working in the application.
| |
|
|
|
|
|
|
|
PHP dev.
|
|
|
|
|
|
|
Das habe ich auch gedacht. (Wobei es sicher Skripts gibt, wo so eine Funktion Sinn ergibt)
https://code.djangoproject.com/wiki/NewbieMistakes
Hi there, Hacker News. This page isn't part of Django's documentation; it's part of the community wiki. This page is also 13 years old, and many of the things listed here applied only in incredibly ancient versions of Django. Django's actual documentation can be found at docs.djangoproject.com.
hihi
|
|
|
|
|
|
|
|
|
|
|
Python 3.7 ist seit ein paar Tagen raus. Sieht hauptsächlich nach Detailänderungen aus:
- Es gibt jetzt breakpoint() (statt import pdb; pdb.set_trace())
- @dataclass ("mutable namedtuples with defaults"... hmnaja)
- Module __getattr__ and __dir__... ursprünglich etwas, was Python 2->3 gebrochen hat (in Python 2 haben die meisten Deskriptoren auch mit Modulen funktioniert, in 3 gingen keine mehr).
- contextvars (=TLS für Asyncio-Coroutinen)
e: Die ersten beiden sind denke ich am signifikantesten. breakpoint() ist halt einfach schöner zu tippen und auf dem zweiten Blick ist @dataclass eher das, was man eigentlich immer haben wollte, wenn man namedtuple benutzt hat.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 02.07.2018 20:16]
|
|
|
|
|
|
Dataclass ist sehr cool, war ein großes Loch in der Standardbibliothek. Ist eine Python-Entsprechung für (beispielsweise) case classes in Scala. Jetzt fehlt quasi nur noch anständiges pattern matching!
|
|
|
|
|
|
|
| Zitat von B0rG*
Dataclass ist sehr cool, war ein großes Loch in der Standardbibliothek. Ist eine Python-Entsprechung für (beispielsweise) case classes in Scala. Jetzt fehlt quasi nur noch anständiges pattern matching!
| |
Kannst du erläutern, wofür man das benutzen könnte?
|
|
|
|
|
|
|
Ist das nicht einfach ein aufgepepptes struct aus C? Ist natürlich cool das zu haben, aber verpasse ich etwas?
|
|
|
|
|
|
|
Das ist reiner Syntaxzucker.
e: Nichtmal __slots__ wird gesetzt, weil
class foo:
...
bar = dataclass(foo)
assert bar is foo
gilt.
(Die Typ-Annotationen sind da rein kosmetisch; Python selbst tut damit nix.)
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 02.07.2018 23:31]
|
|
|
|
|
|
| Zitat von mYstral
Kannst du erläutern, wofür man das benutzen könnte?
| |
Ich würde sagen die (vorerst?) wichtigste Anwendung aus Python-Sicht ist, dass Dataclasses der korrekte (tm) State-Behälter für APIs ist, um möglichst selbstdokumentierenden Code zu erzeugen. Man sieht in Python-Code vielerlei Behelfslösungen dafür, zum Beispiel Tupel (bei denen man raten muss was die Einträge bedeuten), Dictionaries (die mutable sind und damit eigentlich zu mächtig) und, naja, schlechter selbst implementierte Dataclasses oder die sehr verwandten Namedtuple. Es sei natürlich auch noch attrs (und noch ein paar andere) erwähnt, eine Bibliothek die sehr wichtige Inspiration für die Dataclasses ist und im Vergleich noch einen Tick mächtiger ist. Warum sind Dataclasses im API-Kontext cool? Einige Beispiele: Sinnvolle Interfaces zu Datenbanken, die automatisch serialisiert werden können, Rückgabewerte von Funktionen (Forenpost mit Titel, Icon und Text) oder (weil ich das erst selbst benutzt habe) eine kompakte Darstellung für den Parametersatz, der eine numerische Simulation beschreibt.
Man könnte jetzt einwerfen, dass das ja "nur" schickere structs aus C sind (so wie so ziemlich jedes Konstrukt aus Programmiersprachen) oder dass das "nur" Syntaxzucker ist (so wie so ziemiich jedes Konstrukt aus Programmiersprachen). Man kann ja mit Dataclasses erstmal nichts erreichen, was man nicht mit einer ganz normalen Klasse (oder einem Dict) auch erreichen könnte. Außer, dass man die ganzen nervigen Dunder-Methoden (Vergleiche und son kram) nicht mehr implementieren muss. Und ich würde zustimmen.
Aber der wichtige Punkt für mich ist der: Dataclasses implementieren (mehr oder weniger) das Konzept von algebraischen Datentypen und stellen so eine sehr saubere Möglichkeit dar, Zustand (i.e. state) in Programmen zu verpacken: Im Vergleich zu "normalen" Klassen geben algebraische Datentypen normalerweise (und so auch in Python, wenn man sich an die Spielregeln hält) mehr Garantien bezüglich der Analysierbarkeit zur Compilezeit. Von außen ist in einer allgemeinen Klasse erstmal überhauptnicht klar, wo eigentlich Zustand versteckt ist und wann zwei Instanzen einer Klasse äquivalent sind. Deshalb muss man methoden wie __eq__ und __hash__ meistens selbst implementieren. Dataclasses sind das Versprechen, dass der gesamte Zustand in den zur Definition der Dataclass angegebenen Membern ist und dass zwei Instanzen genau dann gleich (und wenn immutable sogar identifizierbar) sind, wenn diese Member gleich sind. Die Member sollten entsprechend auch tunlichst "algebraisch" sein, sonst wird diese Interpretation ein bisschen schwierig. Deshalb kann man überhaupt die dunder-Methoden automatisch erzeugen. Und es ergibt sich dann auch fast direkt der Sprung zum Pattern-Matching: In vielen Fällen hat ein algebraischer Datentyp nur endlich viele überhaupt mögliche Instanziierungen (man denke an Binärbäume) und deshalb wird es dann möglich zur Compilezeit (äh, mit mypy) zum Beispiel zu überprüfen, dass ein Stück Code wirklich alle möglichen Fälle abdeckt, auch wenn nicht-Basistypen im Spiel sind. Und um diese Fallunterscheidungen hübsch in Syntax abzubilden haben quasi alle Sprachen mit algebraischen Datentypen dann auch Syntax für Pattern-Matching. Man könnte sagen das gibt es auch in Python schon eingeschränkt mit dem unpacking von iterables (a, *bs, c = [1, 2, 3, 4] ). Nebenbei wird der Code auch für menschen lesbarer und einfacher zu verstehen, weil es schwieriger wird Schweinereien zu verstecken und das ist im Zweifel ja immer gut.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 03.07.2018 0:39]
|
|
|
|
|
|
Danke für die ausführliche Erklärung.
|
|
|
|
|
|
|
|
|
|
Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |