June 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Styling a Pharo UI application

by Yuriy Tymchuk

> On 24 Jun 2016, at 16:38, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I dont see what Bloc and Bric have to do with sexiness. It has. You see, I can take twitter bootstrap and my webpage will not be ugly. It will not be special, but if I want I can make my own changes. Still, it will not be ugly. But when you take Spec and build a UI it is ugly. And it is very painful to change it. You cannot say `model title size: model title size * 1.5`, you have to do some magic. And then you can use morphic, and athens, and as we have ffi you can use OpenGL. But I donât have time for that, I just want a simple UI which is not ugly and I want to create it fast. Uko > The only thing I see is Athens which Morphic already has access to. To be truly custom GUI friendly the API needs to at least offer some GPU acceleration and access to a myriad of graphical effects. I have not seen anything in Bloc and Bric that would make me abandon Morphic. > > Actually the one thing that I am waiting for with some excitement is SDL support which would make things easier for someone like that loves to create custom GUIs. > > > > On Fri, Jun 24, 2016 at 11:51 AM Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Itâs kind of a pity that to make something sexy we still have to use Morphicâ¦ Hopefully this will change with Bloc & Bric > >> On 24 Jun 2016, at 10:25, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> In my case is just personal preference none the less Spec has ways to wrap morphs to Spec widgets so you should be able to build Spec widgets using Morphic for more flexibility. You dont have to decide to use Spec or Morphic, you can use both. Last time I checked Spec came with examples on how to do this and I think Spec docs also mention this. >> >> Also I think Athens is very good at rendering text (because its wraps around the Cairo library) , so maybe you can take advantage of that though I suspect Bloc may be even better choice in this case because it is based on Athens and it is fully compatible with Morphic. >> >> There is also a text widget that is being build that is much more flexible with handling text >> >> https://vimeo.com/67752734 <https://vimeo.com/67752734> >> >> Be advised though that both Bloc and TxText are far from finished >> >> On Fri, Jun 24, 2016 at 1:28 AM Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>> wrote: >> Personally I don't dislike the Spec approach, but the API still looks not expressive enough for doing things beyond the standard. >> >> I am deepening my knowledge of Morphic now, thanks for your answer! >> Tommaso >> >> >> >> On 22/06/16 17:11, Dimitris Chloupis wrote: >>> Documentation is always a problem. >>> >>> I dont use Spec because I dont like it , but I use Morphic for my project ChronosManager. I do some "styling" for example use different fonts for different labels , different sizes , I format strings to time stamps and even offer easy ways for user to change them without modifying the whole string. >>> >>> You can do a lot with Morphic, though I have not played with layout stuff since this GUI is static and image (PNGs) based but yeah Morphic can do that as well. My project is on Catalog browser and it has class comments , dont know if this exactly what you want but it may be a good start. >>> >>> Obviously there are a ton of things you can do with a web page that Morphic will not offer you out of the box. >>> >>> You can use Html as the front end / GUI and keep Pharo as the backend, thats how most web apps made with Pharo work. This you get the full power of Html/JS and Pharo. Seaside has classes that map html to pharo methods so you dont have to write html and js, and also I remember a pharo library dealing with CSS. >>> >>> Another option is to use a GUI API like QT , I have tried this with my python bridge and it works at least on a very basic level, again similar recipe to the above solution. >>> >>> But yeah if you are not too demanding I think Morphic will serve you well. Personally I only like Morphic , its the only GUI API that does not kill my inner child. >>> >>> On Wed, Jun 22, 2016 at 5:44 PM Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>> wrote: >>> Hello everybody, >>> >>> I have a question about the UI toolkits available for Pharo. I already >>> asked something about this on Slack, but since I saw that there was a >>> recent discussion about UI in the mailing list, I think this is a better >>> place to discuss the matter. >>> >>> I am writing an application for Pharo where I am displaying some >>> structured text. The structure is similar to the one of a web page: A >>> main title with a list of paragraphs, where each paragraph has a title >>> and a description. >>> >>> What I would like to do is to format the text to present the contents in >>> a meaningful way: For example, I would like a bigger font for the title, >>> and change the background of the text, to give a better separation >>> between the paragraphs. Basically I would like to manipulate and display >>> my contents as I would do in a web page. >>> >>> To write UI widgets I usually use Spec, but I found that going beyond >>> easy formatting (e.g. bold text and emphasis) is harder than I thought. >>> I saw there were discussion about the styling text and the role of the >>> theme class, using TextStyle but that part is not really documented. >>> >>> So far, the easiest way to solve my problem seems to be to use Morphic >>> to display the contents as I want it, and then include my widget in my >>> spec application. >>> >>> Do you have any suggestions about how to do that? I think that styling >>> the UI widgets is an important part of the application development, but >>> it is really hard to find documentation about this. >>> >>> Thanks, have a nice day! >>> Tommaso >>> >>> >> >

June 24, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Alistair Grant

Hi Nicolai, On Fri, Jun 24, 2016 at 11:22:07PM +0200, Nicolai Hess wrote: > Can you try if this is working with this change (attach .st) > I'll open an issue and do some more tests. Yep, that works, I can inspect the variable correctly in both the demo code I posted and the original code that triggered the problem. Thanks! Alistair

June 24, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Nicolai Hess

Can you try if this is working with this change (attach .st) I'll open an issue and do some more tests. 2016-06-24 21:56 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Nicolai, > > On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote: > > > > > > 2016-06-24 20:57 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > > > Hi All, > > > > I'm currently regularly hitting an issue with the debugger where > > inspecting a temporary variable shows the string "error obtaining > field > > value" rather than the actual value. > > > > > > I am not sure if this is the same error. We had a couple of issues with > reading > > different kinds of variables in the debugger, > > and some fix work for one access and introduces new issues for other > kinds of > > variables :( > > > > Most things are working now, but we have still an issue in Pharo 6.0 > with block > > local vars in optimized blocks (case 17343) > > But I think this one is a different issue. > > Before we open a new issue, it would be good if I can reproduce this one. > > Give me some time ( or some hints) what I need to reproduce this) > > Thanks for your reply. > > I've created a class that reproduces the problem: > > > 'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 at > 9:51:07.97744 pm'! > Object subclass: #AKGDebuggerBug > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'AKG-Bugs'! > > !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'! > method1 > "AKGDebuggerBug new method1" > self method2: [ 'hello world' ].! ! > > !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! > method3: aBlock > > | result | > > [ result := aBlock value ] value. > ^result.! ! > > !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! > method2: aBlock > | result | > [ result := aBlock numArgs = 1 > ifTrue: [ aBlock value: self ] > ifFalse: [ aBlock value ] ] value. > ^ result! ! > > > Debugging "AKGDebuggerBug new method1" and stepping through to where > result is assigned in method2: will trigger the problem. > > Note that modifying method1 to call method3: will not reproduce the > problem. > > > Thanks, > Alistair > > >

June 24, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Alistair Grant

Hi Nicolai, On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote: > > > 2016-06-24 20:57 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi All, > > I'm currently regularly hitting an issue with the debugger where > inspecting a temporary variable shows the string "error obtaining field > value" rather than the actual value. > > > I am not sure if this is the same error. We had a couple of issues with reading > different kinds of variables in the debugger, > and some fix work for one access and introduces new issues for other kinds of > variables :( > > Most things are working now, but we have still an issue in Pharo 6.0 with block > local vars in optimized blocks (case 17343) > But I think this one is a different issue. > Before we open a new issue, it would be good if I can reproduce this one. > Give me some time ( or some hints) what I need to reproduce this) Thanks for your reply. I've created a class that reproduces the problem: 'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 at 9:51:07.97744 pm'! Object subclass: #AKGDebuggerBug instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'AKG-Bugs'! !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'! method1 "AKGDebuggerBug new method1" self method2: [ 'hello world' ].! ! !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! method3: aBlock | result | [ result := aBlock value ] value. ^result.! ! !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! method2: aBlock | result | [ result := aBlock numArgs = 1 ifTrue: [ aBlock value: self ] ifFalse: [ aBlock value ] ] value. ^ result! ! Debugging "AKGDebuggerBug new method1" and stepping through to where result is assigned in method2: will trigger the problem. Note that modifying method1 to call method3: will not reproduce the problem. Thanks, Alistair

June 24, 2016

Re: [Pharo-users] The myth of a small deployment image using metacello

by Dale Henrichs

On 6/24/16 6:28 AM, Norbert Hartl wrote: > I have a seaside project that will be installed in a typical fashion headless on a server somewhere on the net. The project is in its final stage so I started to care about the size of the image. Or better: The size of the image is not my main concern but the number of packages installed. The less packages you load the better it is, it is that simple. > This time I encountered a problem that I often see but this particular one explains in a very good way that how we use metacello can be improved. > > In my project I load only Seaside-Core. This has the advantage of loading far less packages and I don't have the need to remove a bunch of registered web applications that registered themselves when being loaded. > I make use of a bootstrap template bought somewhere on the net. I use magritte a lot so I was happy to see that there is a package called BootstrapMagritte. The package extends some magritte ui classes and overwrites some methods to add specific classes to HTML tags. Basically not very much code. > What happended after I added the package as a dependency to my own project you can see here in the load directive of metacello > > linear load : > explicit load : 0.2.3 [ConfigurationOfBootstrapMagritte] > linear load : 0.2.3 [ConfigurationOfBootstrapMagritte] > linear load : 3.5.0 [ConfigurationOfMagritte3] > linear load : 1.1.0 [ConfigurationOfMagritteGlamourForPharo40] > load : Glamour-Presentations.issue_1126-SeanDeNigris.178 > load : Glamour-Morphic-Renderer.issue_1126-SeanDeNigris.325 > explicit load : 3.1.5 [ConfigurationOfSeaside3] > linear load : 3.1.5 [ConfigurationOfSeaside3] > explicit load : 0.26 [ConfigurationOfParasol] > linear load : 0.26 [ConfigurationOfParasol] > linear load : 3.2.0 [ConfigurationOfSeaside3] > load : Seaside-Tests-REST-Core-EstebanMaringolo.34 > > This is wrong in so many ways. I load a little extensions to my web application and end up loading _all_ of seaside which loads beach parasol (a ui testing framework), _all_ of magritte which in turn loads glamour packages (a ui toolkit). So at this point I think WTF? > > Why does this happen? Because the "default" group in many projects contains all of the packages and dependencies of the project. I thought at first this is wrong but in the meantime I think it is right. Whenever a configuration is loaded without additional parameters the "default" group gets loaded. This is the best scenario for newcomers (e.g. using the catalog to load). They don't know better but want to see what the package has to offer. Fine, we should support that. > > For managing projects this gets annoying really quick like you can see above. It would always load all dependencies and all packages of every project that your own project depends. This is a no-go. To circumvent this a lot of people add a "core" group to their configurations (loading the essential parts). This is great because in my own project I can add a dependency to a project and load only the "core" group. This works if the dependency chain is not very long (at best it works in depth 1 ;) ). As soon as a project has two interesting groups the problem gets worse. A good example is magritte. It is useful for describing your model as well as it contains useful seaside components. The moment I add a dependency from my model package to magritte seaside I know it is wrong. I find myself sometimes duplicating dependencies just to mitigate the effect. I do something like > > project: 'Magritte3Seaside' with: [ > spec > className: #ConfigurationOfMagritte3; > versionString: #'stable'; > loads: #('Seaside' ); > repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; > project: 'Magritte3Core' with: [ > spec > className: #ConfigurationOfMagritte3; > versionString: #'stable'; > loads: #('Core' ); > repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; > > andâ¦ > package: #'MyProject-Model-Core' with: [ > spec requires: #( 'Magritte3Core' ). ]; > package: #'MyProject-UI-Core' with: [ > spec requires: #( 'Seaside3' 'Magritte3Seaside' 'BootstrapMagritte' ). ]; > > > just to be able to put the right dependencies. But this way is cumbersome to do and not support by tools like Versionner. > > The main problem to me is that the maintainer of the configuration defines the granularity of pieces to load forcing me to do stupid workarounds to achieve what I want. To me the problem is that the separation is not done properly. I think the logic of having loads() in the baseline and a pure string like "Magritte3Core" in the dependency spec is reversed. It should be > > project: 'Magritte3' with: [ > spec > className: #ConfigurationOfMagritte3; > versionString: #'stable'; > repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; > > andâ¦ > > package: #'MyProject-Model-Core' with: [ > spec requires: #( 'Magritte3:Core' ). ]; > package: #'MyProject-UI-Core' with: [ > spec requires: #( 'Seaside3' 'Magritte3:Seaside' 'BootstrapMagritte' ). ]; > > Note the "Magritte3:Core" in the dependency spec. The meaning is that there is a dependency to Magritte3 and group Core. This way dependencies can be properly aligned. Or are there other way to deal with it? > > What do you think? > > Norbert Norbert, Does the following meet your needs? project: 'Magritte3' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; project: 'Magritte3Seaside' copyFrom: 'Magritte' with: [ spec loads: #('Seaside' ) ]; project: 'Magritte3Core' copyFrom: 'Magritte' with: [ spec loads: ##('Core' ) ]; I assume the "stupid workaround" is the fact that in your example you had to specify Magritte twice? #project:copyFrom:with: has been around for a long time in Metacello and was invented to solve this particular problem ... FWIW, this feature is documented in Lesson12 of "Metacello Configuration Tutorial Part 2" in the Help Browser ... Dale

June 24, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Nicolai Hess

2016-06-24 20:57 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi All, > > I'm currently regularly hitting an issue with the debugger where > inspecting a temporary variable shows the string "error obtaining field > value" rather than the actual value. > I am not sure if this is the same error. We had a couple of issues with reading different kinds of variables in the debugger, and some fix work for one access and introduces new issues for other kinds of variables :( Most things are working now, but we have still an issue in Pharo 6.0 with block local vars in optimized blocks (case 17343) But I think this one is a different issue. Before we open a new issue, it would be good if I can reproduce this one. Give me some time ( or some hints) what I need to reproduce this) > Selecting the temporary variable and attempting to inspect it in the > code pane results in: > > True(Object)>>doesNotUnderstand: #indexInTempVectorFromIR: > OCVectorTempVariable>>searchFromContext:scope: > DebuggerMethodMapOpal>>tempNamed:in: > DebuggerMethodMapOpal>>namedTempAt:in: > Context>>namedTempAt: > GlorpSession>>DoItIn: > OpalCompiler>>evaluate > RubSmalltalkEditor>>evaluate:andDo: > RubSmalltalkEditor>>highlightEvaluateAndDo: > [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] in [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: > ann action. > textMorph shoutStyler style: textMorph text ] ] in > GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: > in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... > RubEditingArea(RubAbstractTextArea)>>handleEdit: > [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: > ann action. > textMorph shoutStyler style: textMorph text ] ] in > GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: > in Block: [ textMorph textArea... > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldState>>doOneSubCycleFor: > WorldMorph>>doOneSubCycle > MenuMorph>>invokeModalAt:in:allowKeyboard: > MenuMorph>>invokeModal: > MenuMorph>>invokeModal > [ :menu | > menu setInvokingView: self editor. > menu invokeModal. > self changed. > ^ true ] in RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: in > Block: [ :menu | ... > MenuMorph(Object)>>ifNotNilDo: > RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: > RubEditingArea(RubAbstractTextArea)>>mouseDown: > RubEditingArea(Morph)>>handleMouseDown: > MouseButtonEvent>>sentTo: > RubEditingArea(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchMouseDown:with: > MorphicEventDispatcher>>handleMouseDown: > > This is in: > > Pharo5.0 > Latest update: #50757 > > OS: 4.6.2-1-ARCH > > It appears to be a resurrection of > https://pharo.fogbugz.com/f/cases/13260/ > > I'm hitting the problem by executing (using the example from the Glorp > chapter in Pharo in Progress): > > session > inUnitOfWorkDo: [ | person | > person := session readOneOf: Person where: [ :each > | each lastName = 'Locke' ]. > person birthDate: Date today ] > > > Stepping in to GlorpSession>>inUnitOfWorkDo: and attempting to inspect > 'result' after it has been assigned. > > Is this a known problem, should I open a new issue, or...? > > Thanks! > Alistair > >

June 24, 2016

Fogbugz 13260 reappears?

by Alistair Grant

Hi All, I'm currently regularly hitting an issue with the debugger where inspecting a temporary variable shows the string "error obtaining field value" rather than the actual value. Selecting the temporary variable and attempting to inspect it in the code pane results in: True(Object)>>doesNotUnderstand: #indexInTempVectorFromIR: OCVectorTempVariable>>searchFromContext:scope: DebuggerMethodMapOpal>>tempNamed:in: DebuggerMethodMapOpal>>namedTempAt:in: Context>>namedTempAt: GlorpSession>>DoItIn: OpalCompiler>>evaluate RubSmalltalkEditor>>evaluate:andDo: RubSmalltalkEditor>>highlightEvaluateAndDo: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] in [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... RubEditingArea(RubAbstractTextArea)>>handleEdit: [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoMethodRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea... WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldState>>doOneSubCycleFor: WorldMorph>>doOneSubCycle MenuMorph>>invokeModalAt:in:allowKeyboard: MenuMorph>>invokeModal: MenuMorph>>invokeModal [ :menu | menu setInvokingView: self editor. menu invokeModal. self changed. ^ true ] in RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: in Block: [ :menu | ... MenuMorph(Object)>>ifNotNilDo: RubEditingArea(RubAbstractTextArea)>>yellowButtonActivity: RubEditingArea(RubAbstractTextArea)>>mouseDown: RubEditingArea(Morph)>>handleMouseDown: MouseButtonEvent>>sentTo: RubEditingArea(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>handleMouseDown: This is in: Pharo5.0 Latest update: #50757 OS: 4.6.2-1-ARCH It appears to be a resurrection of https://pharo.fogbugz.com/f/cases/13260/ I'm hitting the problem by executing (using the example from the Glorp chapter in Pharo in Progress): session inUnitOfWorkDo: [ | person | person := session readOneOf: Person where: [ :each | each lastName = 'Locke' ]. person birthDate: Date today ] Stepping in to GlorpSession>>inUnitOfWorkDo: and attempting to inspect 'result' after it has been assigned. Is this a known problem, should I open a new issue, or...? Thanks! Alistair

June 24, 2016

Re: [Pharo-users] Better color contrast for class extensions in dark theme

by Cyril Ferlicot

On Friday, 24 June 2016, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > Pharo3DarkTheme >>#selectionColor > > > > The problem is that for the extension color it is hard coded into Nautilus. We should add a method in UITheme and use it. >From my phone -- Cyril > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org > <javascript:_e(%7B%7D,'cvml','pharo-users-bounces(a)lists.pharo.org');>] *On > Behalf Of *Offray Vladimir Luna CÃ¡rdenas > *Sent:* Friday, June 24, 2016 7:20 PM > *To:* pharo-users(a)lists.pharo.org > <javascript:_e(%7B%7D,'cvml','pharo-users(a)lists.pharo.org');> > *Subject:* Re: [Pharo-users] Better color contrast for class extensions > in dark theme > > > > Hi :), > > Well, in the spirit of today's bug fixing hackathon, I should ask better > some pointers about how to fix the color issue myself. So any advice is > appreciated. > > Cheers, > > Offray > > > > On 24/06/16 11:52, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi :), > > I'm enjoying the Pharo Dark Theme a lot (in fact my tweet on a 10 minutes > hack about it[1] have more impact that the tweets with month and a half > work behind for Panama Papers[2]... that's life :-P), but I still have > some suggestions on color contrast, particularly when you're doing class > extensions and the light gray over blue makes the reading really difficult > (see screenshot at bottom). > > [1] https://twitter.com/offrayLC/status/738828257680850944 > > [2] https://twitter.com/offrayLC/status/729069808684285953 > > > > > > Hope this helps to improve this theme. > > Cheers, > > Offray > > > -- Cheers Cyril Ferlicot

June 24, 2016

Re: [Pharo-users] Better color contrast for class extensions in dark theme

by Henrik Nergaard

Pharo3DarkTheme >>#selectionColor From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Offray Vladimir Luna CÃ¡rdenas Sent: Friday, June 24, 2016 7:20 PM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Better color contrast for class extensions in dark theme Hi :), Well, in the spirit of today's bug fixing hackathon, I should ask better some pointers about how to fix the color issue myself. So any advice is appreciated. Cheers, Offray On 24/06/16 11:52, Offray Vladimir Luna CÃ¡rdenas wrote: Hi :), I'm enjoying the Pharo Dark Theme a lot (in fact my tweet on a 10 minutes hack about it[1] have more impact that the tweets with month and a half work behind for Panama Papers[2]... that's life :-P), but I still have some suggestions on color contrast, particularly when you're doing class extensions and the light gray over blue makes the reading really difficult (see screenshot at bottom). [1] https://twitter.com/offrayLC/status/738828257680850944 [2] https://twitter.com/offrayLC/status/729069808684285953 [cid:image001.png@01D1CE52.7B5408C0] Hope this helps to improve this theme. Cheers, Offray

June 24, 2016

Re: [Pharo-users] Better color contrast for class extensions in dark theme

by Offray Vladimir Luna CÃ¡rdenas

Hi :), Well, in the spirit of today's bug fixing hackathon, I should ask better some pointers about how to fix the color issue myself. So any advice is appreciated. Cheers, Offray On 24/06/16 11:52, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi :), > > I'm enjoying the Pharo Dark Theme a lot (in fact my tweet on a 10 > minutes hack about it[1] have more impact that the tweets with month > and a half work behind for Panama Papers[2]... that's life :-P), but > I still have some suggestions on color contrast, particularly when > you're doing class extensions and the light gray over blue makes the > reading really difficult (see screenshot at bottom). > > [1]https://twitter.com/offrayLC/status/738828257680850944 > [2]https://twitter.com/offrayLC/status/729069808684285953 > > > > Hope this helps to improve this theme. > > Cheers, > > Offray

June 24, 2016