Toolbar Problem Linux - Windows

Hier werden, insbesondere in den Beta-Phasen, Bugmeldungen gepostet. Das offizielle BugForum ist allerdings hier.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Toolbar Problem Linux - Windows

Beitrag von ts-soft »

Unter Windows zählt die Toolbar zur Arbeitsfläche, während es unter Linux
nicht so ist.

Dies sollte unter allen OS gleich gehandhabt werden, weil das Layouten doch
ziemlich erschwert wird.

Beispiel: Einen Button direkt unter die Toolbar setzen

Code: Alles auswählen

; windows
If OpenWindow(0, 0, 0, 150, 70, "ToolBar", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If CreateToolBar(0, WindowID(0))
    ToolBarStandardButton(0, #PB_ToolBarIcon_New)
    ToolBarStandardButton(1, #PB_ToolBarIcon_Open)
    ToolBarStandardButton(2, #PB_ToolBarIcon_Save)
  EndIf
  ButtonGadget(0, 5, ToolBarHeight(0), 140, 25, "void") ; < --
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow 
EndIf
; linux
If OpenWindow(0, 0, 0, 150, 70, "ToolBar", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If CreateToolBar(0, WindowID(0))
    ToolBarStandardButton(0, #PB_ToolBarIcon_New)
    ToolBarStandardButton(1, #PB_ToolBarIcon_Open)
    ToolBarStandardButton(2, #PB_ToolBarIcon_Save)
  EndIf
  ButtonGadget(0, 5, 0, 140, 25, "void") ; < --
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow 
EndIf
Mir ist zwar klar, das das Layout zwischen verschiedenen OS nie
übereinstimmt, ich bin aber der Meinung, zumindest in diesem Fall
unnötig, somit ein Bug ist.

Gruß
Thomas
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

hm.... ist das jetzt ein koordinatenproblem oder wie muss ich das verstehen?

ich bezweifle, dass sich da wirklich was machen läßt, das ist nämlich auch wieder Sache des OS.
es wird nicht unter, sondern von den OS gehandhabt, kann also kein PB-Bug sein.

was meinst du, wie doof ich geguckt hab, als ich gesehen hab,
dass die Menus unter Windows nicht zur Arbeitsfläche gehören.
man erzeugt ein Fenster mit Y höhe, es hat aber nur Y-MenuHeight...
das würde ich auch klar als Bug bezeichnen, aber als einen von Windows.

würde es denn Abhilfe schaffen, wenn du auf beiden Systemen mit GDI+ deine Fenster layoutest?
ich hatte vor längerem mal nen tip in der Richtung gelesen...

ob es sich aber lohnt, ALLE betroffenen PB-Libs so umzuschreiben,
dass die übergebenen Werte nicht mehr den API-Werten entsprechen,
dafür aber konsistent und sinnvoll sind, ist die Frage.

das würde z.b. bedeuten, dass wenn ich ein Fenster öffne mit 100 Y im Aufruf,
dass es nicht nur wie bisher, 100 + Kopfleiste + Rahmen hoch ist,
sondern 100+ Kopfleiste + Rahmen + Menu + Toolbars.
das würde gleichzeitig bedeuten, dass mein Fenster seine größe ändern müsste,
wenn ich toolbars dazuschalte oder verberge...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
DarkDragon
Beiträge: 6267
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Beitrag von DarkDragon »

Kaeru Gaman hat geschrieben:würde es denn Abhilfe schaffen, wenn du auf beiden Systemen mit GDI+ deine Fenster layoutest?
Microsoft GDI+ unter Linux? Oder meintest du GTK? Btw.: Das ist kein Bug von Windows, das ist eher einer von PB. Das war nämlich mal unter Windows so mit PB, dass man nicht die Clientarea hatte sondern das komplette Fenster. Unter Linux scheint das demnach noch so zu sein. Das wollten einige mal geändert haben in PB 3.81 oder so.
Zuletzt geändert von DarkDragon am 17.03.2009 11:29, insgesamt 1-mal geändert.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag von ts-soft »

Aber es kann ja nicht sein, das in einer Sprache die Toolbar mal zur
Arbeitsfläche gehören und mal nicht.

Kann doch nicht so schwer sein, das abzustellen?

Es wäre auf jedenfall einfacher, wenn die Toolbar nicht zur Arbeitsfläche
gehört, weil das macht auch resizen usw. einfacher. Wer dann unter Windows
unbedingt was über die Toolbar packen will (ob das Sinn macht), der kann ja
mit Minuskoordinaten arbeiten, ist ja dann sowieso der Ausnahmefall.

Tausende von CompilerIfs im Source bringens ja auch nicht, da kann ich
gleich einen Source je OS schreiben :wink:

nur meine 2 eurocents dazu
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

DarkDragon hat geschrieben:
Kaeru Gaman hat geschrieben:würde es denn Abhilfe schaffen, wenn du auf beiden Systemen mit GDI+ deine Fenster layoutest?
Microsoft GDI+ unter Linux? Oder meintest du GTK?
achja... genau.
wahrscheinlich meine ich dann GTK.

na, auf jeden fall das, womit man normal auf LINUX seine fensterle layoutet und das man auf Windows auch benutzen kann...

... immer diese unkommentierten dreibuchstabigen Abkürzungen.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

Das ist kein Bug von Windows, das ist eher einer von PB. Das war nämlich mal unter Windows so mit PB, dass man nicht die Clientarea hatte sondern das komplette Fenster. Unter Linux scheint das demnach noch so zu sein. Das wollten einige mal geändert haben in PB 3.81 oder so.
wie jetzt... also "früher" zählten Menu und Toolbar zur Clientarea?

also
1.) ich stimme ts zu, dass es grundsätzlich konsistent sein sollte, also auf alles Plattformen gleich.

und
2.) sollte es auch in sich konsistent sein, damit meine ich,
wenn Toolbar und Menu nicht zur Clientarea gehören,
dann soll ihre Höhe weder bei den Größenangaben des Fensters noch bei den Koordinaten der Gadgets mitgezählt werden.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag von ts-soft »

> wenn Toolbar und Menu nicht zur Clientarea gehören,
so ist das unter Linux, unter Windows gehört nur das Menu nicht zur
Clientarea.

Einheitlich wäre alles einfacher :wink:
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
DarkDragon
Beiträge: 6267
Registriert: 29.08.2004 08:37
Computerausstattung: Hoffentlich bald keine mehr
Kontaktdaten:

Beitrag von DarkDragon »

ts-soft hat geschrieben:> wenn Toolbar und Menu nicht zur Clientarea gehören,
so ist das unter Linux, unter Windows gehört nur das Menu nicht zur
Clientarea.

Einheitlich wäre alles einfacher :wink:
Vielleicht sollte man die Befehle etwas erweitern:

CreateMenu(..., InsideClientArea)
CreateToolbar(..., InsideClientArea)

Und wenn man sich für Inside entscheidet, gibt es ja noch die Befehle:

MenuHeight()
ToolBarHeight(#ToolBar)

P.S.: Ich würde einfach alle Gadgets erstellen und da man ja sowieso so eine Resize-Prozedur erstellt zum aktualisieren der Größen könnte man ja die danach aufrufen zum korrekten Platzieren in Abhängigkeit der Fensterdimension/Toolbarposition/Statusbarposition/Menüposition.
Angenommen es gäbe einen Algorithmus mit imaginärer Laufzeit O(i * n), dann gilt O((i * n)^2) = O(-1 * n^2) d.h. wenn man diesen Algorithmus verschachtelt ist er fertig, bevor er angefangen hat.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag von ts-soft »

DarkDragon hat geschrieben: Vielleicht sollte man die Befehle etwas erweitern:

CreateMenu(..., InsideClientArea)
CreateToolbar(..., InsideClientArea)

Und wenn man sich für Inside entscheidet, gibt es ja noch die Befehle:

MenuHeight()
ToolBarHeight(#ToolBar)
Das hört sich ganz gut an!
DarkDragon hat geschrieben: P.S.: Ich würde einfach alle Gadgets erstellen und da man ja sowieso so eine Resize-Prozedur erstellt zum aktualisieren der Größen könnte man ja die danach aufrufen zum korrekten Platzieren in Abhängigkeit der Fensterdimension/Toolbarposition/Statusbarposition/Menüposition.
Ich erstelle in Resizeable Fenster eigentlich alles mit der größe 0, 0, 0, 0
aber das mag Linux wohl auch nicht. Aber damit kann man ja leben, wenn
man es weiß
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Simon74
Beiträge: 60
Registriert: 04.05.2014 10:05

Re: Toolbar Problem Linux - Windows

Beitrag von Simon74 »

Ich habe dasselbe Problem unter Linux.
Der Eintrag ist 5 Jahre alt, aber es gibt noch keine Lösung dafür ?
Ausserdem noch das Problem das GadgetToolTip unter Windows immer funktioniert, unter Linux leider nicht immer.
Antworten