[Ann] Calypso update: method browser and better UI
Hi. I glad release new version of Calypso: - white toolbar (according to theme background color) - separators between radio button groups - clickable labels instead of buttons - method browser - view modes - scopes - window tabs for following navigation requests Read details with pictures here http://dionisiydk.blogspot.fr/2017/01/calypso-update-methodbrowser-and-bette... Best regards, Denis
It looks great! The tabs on the MessageBrowser really reduces the window noise. I see these error when asking for implementors: "Instance of AColorSelectorMorph class did not understand #localMethodNamed:ifAbsent:" Something really cool, will be the implementors and sender button to work too for selected method in the source code area. I know we can get it from the contextual menu 'Code search...', but it is so common to search for implementor and senders of methods used in the source code itself. And of course it should open in new tab too. Hilaire Le 12/01/2017 à 12:07, Denis Kudriashov a écrit :
Hi.
I glad release new version of Calypso:
-- Dr. Geo http://drgeo.eu
2017-01-12 15:08 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
The tabs on the MessageBrowser really reduces the window noise. I see these error when asking for implementors: "Instance of AColorSelectorMorph class did not understand #localMethodNamed:ifAbsent:"
You need latest version of Pharo 6. New method is there.
Something really cool, will be the implementors and sender button to work too for selected method in the source code area. I know we can get it from the contextual menu 'Code search...', but it is so common to search for implementor and senders of methods used in the source code itself.
But how you suggest to distinguish user intention? what to use as query source: method from method view or current message in code editor?
And of course it should open in new tab too.
Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place.
Le 12/01/2017 à 15:29, Denis Kudriashov a écrit :
You need latest version of Pharo 6. New method is there.
Ok
But how you suggest to distinguish user intention? what to use as query source: method from method view or current message in code editor?
Easy: if no text selected in code editor -> query from method view, otherwise -> query from selected method in code editor. Tools tips of the implementors and senders buttons should document it to make the feature discoverable by user.
And of course it should open in new tab too.
Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place.
I guess so, but you will be real winner. -- Dr. Geo http://drgeo.eu
2017-01-12 15:44 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
And of course it should open in new tab too.
Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place.
I guess so, but you will be real winner.
And this is done. I just upload new stable version: - source code shortcuts are managed by Calypso. I found simple hook how to achieve this - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window. - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors
Am 20.01.2017 um 14:12 schrieb Denis Kudriashov <dionisiydk@gmail.com>:
And this is done. I just upload new stable version: - source code shortcuts are managed by Calypso. I found simple hook how to achieve this - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window. - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors
This is really great. I love the Method Browser. Thank you! Bernhard
Pharo's implementation of Float>>sign is very odd, and rather disturbing. It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct. Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do. The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN). The current implementation of #sign is self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0 I'd propose factoring this into two simpler methods: sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0 isSignMinus ^((self at: 1) bitShift: -31) = 1 Which would restore symmetry, as well as conforming to all the relevant specs. -Martin
2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com>:
Pharo's implementation of Float>>sign is very odd, and rather disturbing.
It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct.
Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do.
OK, I think you are right
The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN).
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
isSignMinus ^((self at: 1) bitShift: -31) = 1
Which would restore symmetry, as well as conforming to all the relevant specs.
-Martin
Or just
signBit ^(self at: 1) bitShift: -31) That means that we'd have to refactor most (all?) senders of sign...
Hi, i wonder what is the reasoning that "Float nan sign" returns anything else than Float nan? werner On 01/26/2017 09:47 PM, Nicolas Cellier wrote:
2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com <mailto:martin@hand2mouse.com>>:
Pharo's implementation of Float>>sign is very odd, and rather disturbing.
It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct.
Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do.
OK, I think you are right
The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN).
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
isSignMinus ^((self at: 1) bitShift: -31) = 1
Which would restore symmetry, as well as conforming to all the relevant specs.
-Martin
Or just
signBit ^(self at: 1) bitShift: -31)
That means that we'd have to refactor most (all?) senders of sign...
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com <mailto:martin@hand2mouse.com>>:
[...]
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
This addition makes sense to me. The standards help a *little* and suggest on alternative. ANSI Smalltalk acts like NaNs don't exist (basically, it lets implementers do what they want for those values). ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when it *cannot* rely on 10967, it does, sigh). That spec only defines a "sign" operation for floats with a definite numeric value, and says that operations are *permitted* to accept infinities and NaNs, but does not require this, nor say what the answer should be. The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation. If we extend this to Smalltalk, I *think* this would have us answer qNaN for qNaN, and for a sNaN signal a resumable exception (a Notification, perhaps?) that if resumed would answer qNaN. This also seems to make some sense -- NaNs are supposed to propagate, and asking the just plain "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.
That means that we'd have to refactor most (all?) senders of sign...
Certainly should audit senders of sign, but I'd expect that most senders don't really care about what the sign of -0.0 or NaNs are. The answer would remain the same for all other receivers. Regards, -Martin
2017-01-27 0:15 GMT+01:00 Martin McClure <martin@hand2mouse.com>:
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com <mailto:martin@hand2mouse.com>>:
[...]
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
This addition makes sense to me.
The standards help a *little* and suggest on alternative.
ANSI Smalltalk acts like NaNs don't exist (basically, it lets implementers do what they want for those values).
ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when it *cannot* rely on 10967, it does, sigh). That spec only defines a "sign" operation for floats with a definite numeric value, and says that operations are *permitted* to accept infinities and NaNs, but does not require this, nor say what the answer should be.
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
If we extend this to Smalltalk, I *think* this would have us answer qNaN for qNaN, and for a sNaN signal a resumable exception (a Notification, perhaps?) that if resumed would answer qNaN. This also seems to make some sense -- NaNs are supposed to propagate, and asking the just plain "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.
I'm OK with answering NaN, it was just a question. An incomplete specification is an open door to useless differences
That means that we'd have to refactor most (all?) senders of sign...
Certainly should audit senders of sign, but I'd expect that most senders don't really care about what the sign of -0.0 or NaNs are. The answer would remain the same for all other receivers.
Regards,
-Martin
-0.0 sign is answering -1 at least since 1998, so we might have get used to it ;) I've done the job on Squeak trunk, the answer is we need to revise some senders....
On 01/26/2017 05:12 PM, Nicolas Cellier wrote:
-0.0 sign is answering -1 at least since 1998, so we might have get used to it ;) I've done the job on Squeak trunk, the answer is we need to revise some senders....
Thanks for looking into it. I'm afraid I don't have time to dig into this one further. A GemStone user noticed the difference between Pharo and GemStone behavior, and in this case it looked like it was the Pharo behavior that made less sense. Regards, -Martin
On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2017-01-27 0:15 GMT+01:00 Martin McClure <martin@hand2mouse.com>:
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com <mailto:martin@hand2mouse.com>>:
[...]
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
This addition makes sense to me.
The standards help a *little* and suggest on alternative.
ANSI Smalltalk acts like NaNs don't exist (basically, it lets implementers do what they want for those values).
ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when it *cannot* rely on 10967, it does, sigh). That spec only defines a "sign" operation for floats with a definite numeric value, and says that operations are *permitted* to accept infinities and NaNs, but does not require this, nor say what the answer should be.
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
If we extend this to Smalltalk, I *think* this would have us answer qNaN for qNaN, and for a sNaN signal a resumable exception (a Notification, perhaps?) that if resumed would answer qNaN. This also seems to make some sense -- NaNs are supposed to propagate, and asking the just plain "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.
I'm OK with answering NaN, it was just a question. An incomplete specification is an open door to useless differences
That means that we'd have to refactor most (all?) senders of sign...
Certainly should audit senders of sign, but I'd expect that most senders don't really care about what the sign of -0.0 or NaNs are. The answer would remain the same for all other receivers.
Regards,
-Martin
-0.0 sign is answering -1 at least since 1998, so we might have get used to it ;) I've done the job on Squeak trunk, the answer is we need to revise some senders....
For reference here are the Squeak changes. http://forum.world.st/The-Trunk-Kernel-nice-1054-mcz-td4931787.html http://forum.world.st/The-Trunk-KernelTests-nice-317-mcz-td4931795.html What is the next step for Pharo? cheers -ben
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
That's ISO 10967. However, IEEE-758-2008 specifies implementations shall provide isSignMinus(x). This operation is true if and only if x has negative sign, and applies to zeros and NaNs. IMO, values that operate according to IEEE-758-2008 should behave as specified by IEEE-758-2008 by default. The ISO 10967 standard seems more of a layer on top of things like IEEE-758-2008, because it's a standard for language agnostic arithmetic. So, shouldn't #sign behave as in IEEE-758-2008? ^self isSignMinus ifTrue: [-1] ifFalse: [1] It looks like the real question is whether Float's methods are merely renaming IEEE-758-2008 functionality (if yes, why rename at all and add to the confusion?), ISO 10967 functionality, or are something else entirely (e.g. Smalltalk provided behavior in the context of the Smalltalk experience). For example, does it make sense -0.0 < 0.0 to answer false (because zeros must be numerically equivalent) while -0.0 ~= 0.0 sign answers true? That depends on where #sign belongs to. This is very important because if #sign isn't IEEE-758 or ISO 10967, then why use it or care about how it behaves? And if there's no good explanation, then why is #sign there in the first place? Andres.
At Stef's request, I've opened case 19629 on this issue. On 01/27/2017 11:14 PM, Andres Valloud wrote:
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
That's ISO 10967. However, IEEE-758-2008 specifies implementations shall provide isSignMinus(x). This operation is true if and only if x has negative sign, and applies to zeros and NaNs.
IMO, values that operate according to IEEE-758-2008 should behave as specified by IEEE-758-2008 by default. The ISO 10967 standard seems more of a layer on top of things like IEEE-758-2008, because it's a standard for language agnostic arithmetic.
So, shouldn't #sign behave as in IEEE-758-2008?
^self isSignMinus ifTrue: [-1] ifFalse: [1]
I think that defining #sign this way would add to the confusion. IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1. IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards.
It looks like the real question is whether Float's methods are merely renaming IEEE-758-2008 functionality (if yes, why rename at all and add to the confusion?), ISO 10967 functionality, or are something else entirely (e.g. Smalltalk provided behavior in the context of the Smalltalk experience).
First and foremost, Smalltalk. The ANSI Smalltalk numeric spec is based on 10967, but that standard lacks some operations found in IEEE-754. But those have different names anyway, so it's easy in this case to comply with *both* standards. Regards, -Martin
**TX** Without bug entry it will get lost in the noise and stress. Stef
At Stef's request, I've opened case 19629 on this issue.
On 01/27/2017 11:14 PM, Andres Valloud wrote:
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
That's ISO 10967. However, IEEE-758-2008 specifies implementations shall provide isSignMinus(x). This operation is true if and only if x has negative sign, and applies to zeros and NaNs.
IMO, values that operate according to IEEE-758-2008 should behave as specified by IEEE-758-2008 by default. The ISO 10967 standard seems more of a layer on top of things like IEEE-758-2008, because it's a standard for language agnostic arithmetic.
So, shouldn't #sign behave as in IEEE-758-2008?
^self isSignMinus ifTrue: [-1] ifFalse: [1]
I think that defining #sign this way would add to the confusion.
IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1.
IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards.
It looks like the real question is whether Float's methods are merely renaming IEEE-758-2008 functionality (if yes, why rename at all and add to the confusion?), ISO 10967 functionality, or are something else entirely (e.g. Smalltalk provided behavior in the context of the Smalltalk experience).
First and foremost, Smalltalk. The ANSI Smalltalk numeric spec is based on 10967, but that standard lacks some operations found in IEEE-754. But those have different names anyway, so it's easy in this case to comply with *both* standards.
Regards,
-Martin
-- Using Opera's mail client: http://www.opera.com/mail/
Martin, On 1/30/17 16:41 , Martin McClure wrote:
IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1.
IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards.
Yes on isSignMinus. It may also be useful to define #signBit, and implement #isSignMinus as ^self signBit = 1. These types of messages are very useful for testing the implementation is doing the right thing IEEE-wise (hence VM-primitive-wise), so that it's possible to implement e.g. ISO 10967 with confidence. Andres.
Hi martin open a ticket so that we do not lose this point. Stef
[...]
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
This addition makes sense to me.
The standards help a *little* and suggest on alternative.
ANSI Smalltalk acts like NaNs don't exist (basically, it lets implementers do what they want for those values).
ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when it *cannot* rely on 10967, it does, sigh). That spec only defines a "sign" operation for floats with a definite numeric value, and says that operations are *permitted* to accept infinities and NaNs, but does not require this, nor say what the answer should be.
The 2007 update of 10967 is somewhat more helpful. It replaces the "sign" operation with one called "signum" which returns 1, -1, or NaN. It returns 1 for positive zero and positive infinity, and -1 for negative zero and negative infinity. If given a qNaN, it returns a qNaN. If given a signaling NaN, it returns a qNaN but notifies the application of an "invalid" situation.
what is a qNan?
If we extend this to Smalltalk, I *think* this would have us answer qNaN for qNaN, and for a sNaN signal a resumable exception (a Notification, perhaps?) that if resumed would answer qNaN. This also seems to make some sense -- NaNs are supposed to propagate, and asking the just plain "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.
That means that we'd have to refactor most (all?) senders of sign...
Certainly should audit senders of sign, but I'd expect that most senders don't really care about what the sign of -0.0 or NaNs are. The answer would remain the same for all other receivers.
Regards,
-Martin
-- Using Opera's mail client: http://www.opera.com/mail/
2017-01-26 21:09 GMT+01:00 Bernhard Pieber <bernhard@pieber.com>:
- no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors This is really great. I love the Method Browser.
I also forgot to show in demo that it is possible to drag window tab to get normal separate window (just drag it to free space in World). I hope it will be enough because to my mind tabs are most suitable approach but when you really need separate window you will just drag tab out.
On Fri, Jan 27, 2017 at 5:33 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-01-26 21:09 GMT+01:00 Bernhard Pieber <bernhard@pieber.com>:
- no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors This is really great. I love the Method Browser.
I also forgot to show in demo that it is possible to drag window tab to get normal separate window (just drag it to free space in World). I hope it will be enough because to my mind tabs are most suitable approach but when you really need separate window you will just drag tab out.
Cool! This should be intuitive enough from peoples experience with web browsers. cheers -ben
This specific point is terribly super cool! Thanks Le 20/01/2017 à 14:12, Denis Kudriashov a écrit :
- senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window.
-- Dr. Geo http://drgeo.eu
2017-01-31 1:20 GMT+01:00 Stephan Eggermont <stephan@stack.nl>:
Nice!
* white toolbar (according to theme background color)
That doesn't work well. Don't mix styles like this, that is confusing.
Why? It was by intention. Idea to make toolbar with same color as main table panels. And they have default background color
On 31/01/17 14:45, Denis Kudriashov wrote:
2017-01-31 1:20 GMT+01:00 Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>>:
Nice!
* white toolbar (according to theme background color)
That doesn't work well. Don't mix styles like this, that is confusing.
Why? It was by intention. Idea to make toolbar with same color as main table panels. And they have default background color
- The whole window uses visible separation, except for the toolbar. - It is unclear where the toolbar applies to - The color and style of the radio buttons differs from other UI elements - The color of the tabs and tab panel are incorrect, the inactive tabs take away attention. Stephan
2017-01-31 18:53 GMT+01:00 Stephan Eggermont <stephan@stack.nl>:
* white toolbar (according to theme background color)
That doesn't work well. Don't mix styles like this, that is confusing.
Why? It was by intention. Idea to make toolbar with same color as main table panels. And they have default background color
- The whole window uses visible separation, except for the toolbar.
Ok. - It is unclear where the toolbar applies to
- The color and style of the radio buttons differs from other UI elements - The color of the tabs and tab panel are incorrect, the inactive tabs take away attention.
I always said that UI needs much more work. But my question was to your "don't mix styles". Do you think it looks worse than before? I am not designer and would be very appreciate if somebody paint how it should be.
On 31/01/17 21:10, Denis Kudriashov wrote:
I always said that UI needs much more work. But my question was to your "don't mix styles". Do you think it looks worse than before?
I like the toolbar in the middle, and the separators.
I am not designer and would be very appreciate if somebody paint how it should be.
I'll take a look at it, but am a bit slow at the moment. Attached is current painting state of a morph that might be useful. Stephan
participants (10)
-
Andres Valloud -
Ben Coman -
Bernhard Pieber -
Denis Kudriashov -
Hilaire -
Martin McClure -
Nicolas Cellier -
Stephan Eggermont -
stepharong -
werner kassens