Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1624.mcz ==================== Summary ==================== Name: Morphic-mt.1624 Author: mt Time: 17 February 2020, 4:18:38.814347 pm UUID: 9aec0d72-c81c-6041-9bd4-8c1826a49d65 Ancestors: Morphic-mt.1623 Fixes three (hi-dpi / demo mode) scaling issues: (1) selected icon in docking bars (2) box replacement in windows (thanks to Christoph (ct)!) (3) full-screen icon in world main docking bar. =============== Diff against Morphic-mt.1623 =============== Item was changed: ----- Method: DockingBarItemMorph>>selectedIcon: (in category 'accessing') ----- + selectedIcon: aFormOrNil - selectedIcon: aForm + selectedIcon := aFormOrNil + ifNotNil: [:form | form scaleIconToDisplay].! - selectedIcon := aForm! Item was changed: ----- Method: SystemWindow>>applyUserInterfaceTheme (in category 'user interface') ----- applyUserInterfaceTheme super applyUserInterfaceTheme. self setDefaultParameters; + replaceBoxes; refreshWindowColor. self isLookingFocused ifTrue: [self lookUnfocused; lookFocused] ifFalse: [self lookFocused; lookUnfocused]. self isCollapsed ifTrue: [self setProperty: #applyTheme toValue: true].! Item was changed: ----- Method: TheWorldMainDockingBar>>toggleFullScreenOn: (in category 'right side') ----- toggleFullScreenOn: aDockingBar | toggleMorph onIcon offIcon box bgColor | + offIcon := (MenuIcons fullscreenWireframeIcon dyed: + (self userInterfaceTheme logoColor ifNil: [Color black])) scaleIconToDisplay. + onIcon := (MenuIcons fullscreenWireframeIcon dyed: + (self userInterfaceTheme selectionLogoColor ifNil: [Color white])) scaleIconToDisplay. - offIcon := MenuIcons fullscreenWireframeIcon dyed: - (self userInterfaceTheme logoColor ifNil: [Color black]). - onIcon := MenuIcons fullscreenWireframeIcon dyed: - (self userInterfaceTheme selectionLogoColor ifNil: [Color white]). bgColor := (UserInterfaceTheme current get: #selectionColor for: #DockingBarItemMorph) ifNil: [Color blue]. toggleMorph := offIcon asMorph. box := Morph new color: Color transparent; hResizing: #shrinkWrap; vResizing: #spaceFill; listCentering: #center; width: toggleMorph width; changeTableLayout; borderWidth: 1; borderColor: Color transparent; balloonText: 'toggle full screen mode' translated; addMorph: toggleMorph. toggleMorph setToAdhereToEdge: #rightCenter. box on: #mouseUp send: #value to: [ DisplayScreen toggleFullScreen. "toggleMorph image: MenuIcons smallFullscreenOffIcon" ] ; on: #mouseEnter send: #value to: [ toggleMorph image: onIcon. box color: bgColor; borderColor: bgColor]; on: #mouseLeave send: #value to: [ toggleMorph image: offIcon. box color: Color transparent; borderColor: Color transparent]. aDockingBar addMorphBack: box! |
Hm, it would be also nice if the menu items could implement #applyUserInterfaceTheme properly ...
By the way: The indent of labels next to symbols is hard-coded and not the same for icons and markers (see MenuItemMorph >> drawLabelOn:). We currently don't have any mechanism for centering all icons
horizontally and all labels to the left, do we?
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Montag, 17. Februar 2020 16:18 Uhr An: [hidden email]; [hidden email] Betreff: [squeak-dev] The Trunk: Morphic-mt.1624.mcz Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1624.mcz ==================== Summary ==================== Name: Morphic-mt.1624 Author: mt Time: 17 February 2020, 4:18:38.814347 pm UUID: 9aec0d72-c81c-6041-9bd4-8c1826a49d65 Ancestors: Morphic-mt.1623 Fixes three (hi-dpi / demo mode) scaling issues: (1) selected icon in docking bars (2) box replacement in windows (thanks to Christoph (ct)!) (3) full-screen icon in world main docking bar. =============== Diff against Morphic-mt.1623 =============== Item was changed: ----- Method: DockingBarItemMorph>>selectedIcon: (in category 'accessing') ----- + selectedIcon: aFormOrNil - selectedIcon: aForm + selectedIcon := aFormOrNil + ifNotNil: [:form | form scaleIconToDisplay].! - selectedIcon := aForm! Item was changed: ----- Method: SystemWindow>>applyUserInterfaceTheme (in category 'user interface') ----- applyUserInterfaceTheme super applyUserInterfaceTheme. self setDefaultParameters; + replaceBoxes; refreshWindowColor. self isLookingFocused ifTrue: [self lookUnfocused; lookFocused] ifFalse: [self lookFocused; lookUnfocused]. self isCollapsed ifTrue: [self setProperty: #applyTheme toValue: true].! Item was changed: ----- Method: TheWorldMainDockingBar>>toggleFullScreenOn: (in category 'right side') ----- toggleFullScreenOn: aDockingBar | toggleMorph onIcon offIcon box bgColor | + offIcon := (MenuIcons fullscreenWireframeIcon dyed: + (self userInterfaceTheme logoColor ifNil: [Color black])) scaleIconToDisplay. + onIcon := (MenuIcons fullscreenWireframeIcon dyed: + (self userInterfaceTheme selectionLogoColor ifNil: [Color white])) scaleIconToDisplay. - offIcon := MenuIcons fullscreenWireframeIcon dyed: - (self userInterfaceTheme logoColor ifNil: [Color black]). - onIcon := MenuIcons fullscreenWireframeIcon dyed: - (self userInterfaceTheme selectionLogoColor ifNil: [Color white]). bgColor := (UserInterfaceTheme current get: #selectionColor for: #DockingBarItemMorph) ifNil: [Color blue]. toggleMorph := offIcon asMorph. box := Morph new color: Color transparent; hResizing: #shrinkWrap; vResizing: #spaceFill; listCentering: #center; width: toggleMorph width; changeTableLayout; borderWidth: 1; borderColor: Color transparent; balloonText: 'toggle full screen mode' translated; addMorph: toggleMorph. toggleMorph setToAdhereToEdge: #rightCenter. box on: #mouseUp send: #value to: [ DisplayScreen toggleFullScreen. "toggleMorph image: MenuIcons smallFullscreenOffIcon" ] ; on: #mouseEnter send: #value to: [ toggleMorph image: onIcon. box color: bgColor; borderColor: bgColor]; on: #mouseLeave send: #value to: [ toggleMorph image: offIcon. box color: Color transparent; borderColor: Color transparent]. aDockingBar addMorphBack: box!
Carpe Squeak!
|
> On 2020-02-17, at 10:59 AM, Thiede, Christoph <[hidden email]> wrote: > > Hm, it would be also nice if the menu items could implement #applyUserInterfaceTheme properly ... > > <pastedImage.png> > > By the way: The indent of labels next to symbols is hard-coded and not the same for icons and markers (see MenuItemMorph >> drawLabelOn:). We currently don't have any mechanism for centering all icons horizontally and all labels to the left, do we? Do people actually like having icons stuck in their menus? It never seemed like much of a good idea to me; so many menu entries have no reasonable iconic representation, the size of the icons really needs to be carefully constrained in order to not make a messy visual (look at what the inspect/explore lines do in your image), very few icons are well designed, it can drastically slow down menu rendering... really not something I like. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: EROS: Erase Read-Only Storage |
To clarify this: This screenshot was made after 1) opening the menu and 2) saying Preferences changeFontSize: 12. Thanks to Marcel's recent commits, menus don't look that bad when opened after rescaling:
> It never seemed like much of a good idea to me; so many menu entries have no reasonable iconic representation
In some of their Win32 guidelines, Microsoft says that context menus should not need icons. But Microsoft also says that context menus should be very short, so they are far away from us by worlds ...
> the size of the icons really needs to be carefully constrained in order to not make a messy visual (look at what the inspect/explore lines do in your image), very few icons are well designed
+1 for redesigning the icons consistently (but, sorry, I'm not a graphic artist). -1 for dropping support for a simple feature because we could not get it working in the past :)
> it can drastically slow down menu rendering
I never faced that issue. I made some performance analysis recently when each world cycle in my image took a few hundred milliseconds, and the main loads still are the following:
- displaying of long lists (3 out of 45 seconds in FormCanvas, mainly font rendering & primitives) - displaying of windows and shadows (together, 11 out of 45 seconds)
The main problem is that all of these drawing operations are executed whenever a Browser or something else is hovered for a moment (and no, I do not wish to turn off "windows contents always active" :) )
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Montag, 17. Februar 2020 20:05:05 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1624.mcz > On 2020-02-17, at 10:59 AM, Thiede, Christoph <[hidden email]> wrote: > > Hm, it would be also nice if the menu items could implement #applyUserInterfaceTheme properly ... > > <pastedImage.png> > > By the way: The indent of labels next to symbols is hard-coded and not the same for icons and markers (see MenuItemMorph >> drawLabelOn:). We currently don't have any mechanism for centering all icons horizontally and all labels to the left, do we? Do people actually like having icons stuck in their menus? It never seemed like much of a good idea to me; so many menu entries have no reasonable iconic representation, the size of the icons really needs to be carefully constrained in order to not make a messy visual (look at what the inspect/explore lines do in your image), very few icons are well designed, it can drastically slow down menu rendering... really not something I like. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: EROS: Erase Read-Only Storage
Carpe Squeak!
|
> On 2020-02-17, at 11:35 AM, Thiede, Christoph <[hidden email]> wrote: > > To clarify this: This screenshot was made after 1) opening the menu and 2) saying Preferences changeFontSize: 12. Thanks to Marcel's recent commits, menus don't look that bad when opened after rescaling: > > <pastedImage.png> But still the icons really don't add anything. Remember, icons were originally thought of as a useful aide memoire in the early days of GUIs when a) we needed to have pretty graphics to justify all the extra expense (and it was non-trivial) of machines with the ability to even do basic bitmap graphics. b) almost everyone thought that trying to do realistic (forget photo-realistic - hardly anyone was even fantasising about that) looking messy desktop simulations was a Really Neat Idea, in the same way that Douglas Adams referred to digital watches. c) text rendering on these ancient systems was... not so good. An 800*600 pixel screen was utter luxury. > > > It never seemed like much of a good idea to me; so many menu entries have no reasonable iconic representation > > In some of their Win32 guidelines, Microsoft says that context menus should not need icons. But Microsoft also says that context menus should be very short, so they are far away from us by worlds ... It's nice (albeit rare) to see the MS have some sensible idea about a UI element. It's definitely sometihng we should be striving for. Consider the menu you posted. It is pretty much a classic example of what we have wrong with menus in my not at all humble opinion. - far too long - pointless icons - mix of submenus done via a tree menu mechanism (ie the 'embed into' submenu) and the ... mechanism (ie the 'adhere to edge...') menu and even one case of a mix! - far wider than it really needs to be, seemingly driven by the menu title (another thing I dislike as a concept, largely there to make a menu behave like a persistent panel rather than actually implementing the right thing) - a rather random splodge of stuff with little rhyme or reason to it And that lot doesn't even begin to delve into the horrors of the implementation code as of the last time I dug int it. I hope it may have improved a little since. > > > the size of the icons really needs to be carefully constrained in order to not make a messy visual (look at what the inspect/explore lines do in your image), very few icons are well designed > > +1 for redesigning the icons consistently (but, sorry, I'm not a graphic artist). > -1 for dropping support for a simple feature because we could not get it working in the past :) Dropping support for sometihng one can't make work well is a very sensible thing to do in a lot of cases. > > > > it can drastically slow down menu rendering > > I never faced that issue. I made some performance analysis recently when each world cycle in my image took a few hundred milliseconds, and the main loads still are the following: Try a Pi Zero with a non-Cog VM. I really think that using a slow machine needs to be a part of testing whenever possible. Not especially because lots of people have them (which used to be the case, when developer machines were often 5X faster than general machines and 10-30X more expensive - and then remember that a Pi Zero with said non-cog VM is many times faster than even the fantasy developer machines we had circa 1990) but because it helps illustrate poor choices that damage the experience tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it |
In reply to this post by timrowledge
> Do people actually like having icons stuck in their menus?
I certainly do not. Stef |
In reply to this post by timrowledge
> On 17.02.2020, at 20:05, tim Rowledge <[hidden email]> wrote: > > > Do people actually like having icons stuck in their menus? Always. A few icons help me navigating. Change the Icons and I'm startled for days. That's also one reason for me to use colorful windows: I can navigate the "Tools" menu better. For "Apps" without icons/colorpatches, I actually have to read the menus, for "Tools" I can just jump to the memoized color. TL;DR: a few memorable icons help navigating. Best regards -Tobias PS: Turns out I don't really care what the icons are or whether they fit what they're standing in for as long as they're memorable. |
In reply to this post by timrowledge
I never really look at the icons. Except the check box that is functional I see the icons as a visual noise that make the menus and UI look more interesting visually :-P Best, Karl On Mon, Feb 17, 2020 at 8:05 PM tim Rowledge <[hidden email]> wrote:
|
Mostly greebleless UI that Tim might be refering to: Maybe the gray level obtained by dithering is a little bit too fancy ;) Le lun. 17 févr. 2020 à 22:00, karl ramberg <[hidden email]> a écrit :
|
And if you take a look at the left pad of a Sun keyboard, you can see how easy it was to live in this era: Almost a perfect fit! Le lun. 17 févr. 2020 à 22:17, Nicolas Cellier <[hidden email]> a écrit :
|
In reply to this post by Nicolas Cellier
> Maybe the gray level obtained by dithering is a little bit too fancy ;)
That's how decadence begins... Stef |
> On 2020-02-17, at 1:47 PM, Stéphane Rollandin <[hidden email]> wrote: > >> Maybe the gray level obtained by dithering is a little bit too fancy ;) > > That's how decadence begins... I'm all for a bit of decadence in general. Good chocolate. Beautiful furniture. Exquisite tools. A looong time ago when the very first Apple colour UIs came out they were softly grey with just the Apple logo at the top-right having any bright colouring. That's actually be pretty decent colour scheme for typical applications. Yes, there are definitely places where all the colour is needed - art and image processing and design work amongst them - but it's hard to really justify psychedelia for a word processor. And yes, Nicholas is quite right to point out the old ST-80 black and white UI; it is after what I cut my Smalltalk teeth on in the very early 1980's. You get attached to these things in much the same way as we all tend to think of any music dating from after our late teens a 'modern trash jangle'. Excluding, of course, SteamPunk magnificence like Abney Park. Now, Tobias claims that icons in menus help navigating but I rather suspect that in fact it is the positional memory that really assists. Simply turning off menu icons may cause momentary confusion but I think that would rapidly be replaced by direct positional recollection. This, by the way, is one of the reason MS's attempt at menus that update and change layout based on recent usage is not so pleasant. Generally we would not want hugely long menus but my experience in RISC OS suggests that one can effectively deal with a quite large number of menu choices IF the menu is broken into a sensible tree; it seems that the positional memory thing works even hierarchically. We've got past some hilariously tacky skeuomorphism in UI design (in the wider world, not Squeak) and are currently into a bit of a swing too far into the "don't give the user a damn clue what is a button or other thing" paradigm. Maybe we'll settle down some day. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Compatible: Gracefully accepts erroneous data from any source. |
In reply to this post by Stéphane Rollandin
Me neither, especially badly done icons.
/————————————————————/ For encrypted mail use [hidden email] Get a free account at ProtonMail.com Web: https://objectnets.net and https://objectnets.org https://datascilv.com https://datascilv.org On Feb 17, 2020, at 12:39, Stéphane Rollandin <[hidden email]> wrote:
|
In reply to this post by Tobias Pape
Tobias Pape <[hidden email]> schrieb am Mo., 17. Feb. 2020, 21:55:
+1 But it might also work well without icons if the menus were not as long and dense. Preference? |
> Consider the menu you posted. It is pretty much a classic example of what we have wrong with menus in my not at all humble opinion.
>
> - far too long
> - pointless icons
> - mix of submenus done via a tree menu mechanism (ie the 'embed into' submenu) and the ... mechanism (ie the 'adhere to edge...') menu and even one case of a mix!
> - far wider than it really needs to be, seemingly driven by the menu title (another thing I dislike as a concept, largely there to make a menu behave like a persistent panel rather than actually implementing the right thing)
> - a rather random splodge of stuff with little rhyme or reason to it
>
> And that lot doesn't even begin to delve into the horrors of the implementation code as of the last time I dug int it. I hope it may have improved a little since.
FYI: We @ HPI are currently investigating this issue and I hope we will be able to clean up this a bit after the release.
Concerning icons in general: At least at the moment, I find them quite useful to find the right item quickly (in a list of 15 items, "this one with the magnifier" is easier to find that "number 5"). Anyway, most time I use type-to-search. Few icons, such as "tally it", also help me to get an initial understanding of what an item might do. Clock is more intuitive to me than the word "tally" (though I'm not a native speaker). Hey, how about a preference for showing/hiding icons? :-)
If Squeak needs new icons (maybe not for small context menus, but for larger menus, consider also the tool icons), IMO they should be definitively minimalistic (which also includes two-tone colors). And maybe we could also make a hook for exchanging the icon set like UI themes.
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Dienstag, 18. Februar 2020 07:44:14 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1624.mcz Tobias Pape <[hidden email]> schrieb am Mo., 17. Feb. 2020, 21:55:
+1
But it might also work well without icons if the menus were not as long and dense.
Preference?
Carpe Squeak!
|
> Hey, how about a preference for showing/hiding icons? :-)
Of course. And that is just what we have at the moment, which is fine with me: Preferences menuWithIcons Stef |
Free forum by Nabble | Edit this page |