The latest changes on ThemeIcons completely broke functionality and icons of external and included packages. 1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well? 2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now 3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right? 4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly. I know we want to make progress ... but were such changes discussed on the list before? Thx T.
On 02 Oct 2015, at 20:34, Nicolai Hess <nicolaihess@web.de> wrote:
2015-10-02 19:40 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection.
That is really bad, I am working behind a proxy too.
I've said this before: this can only be developed by someone behind a proxy. Any help would be appreciated. I know it works more or less for plain HTTP, but there are edge cases. There does indeed seem to be a problem with HTTPS, maybe just something small/simple. That being said, I must say that I do not understand very well how HTTPS proxying might work. I mean, the traffic is by definition encrypted so how can a proxy even do something ? And if there is some way around this, the connection is no longer end-to-end secure. From my point of view, proxies are from last century ;-) Sven
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly. Wait, if I download a fresh image it starts downloading yet more stuff? (I can't try it now as I am on FUP-constrained mobile connection.) I thought that images are supposed to be self contained and stuff like this should be delegated to CI that builds the image or let the user do it manually on top of Pharo-Minimal/Pharo-Bootstrap.
I mean, the traffic is by definition encrypted so how can a proxy even do something ?
I think it can still establish connection and forward packets (I think), it can simply let the connection through directly or it can fail to connect (which is the case above).
From my point of view, proxies are from last century ;-)
They are indeed, but then again so is Smalltalk. ;) Also your traffic is most likely going through proxies of your ISP (who then injects packets with ad trackers ;)). Peter On Fri, Oct 2, 2015 at 9:21 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 02 Oct 2015, at 20:34, Nicolai Hess <nicolaihess@web.de> wrote:
2015-10-02 19:40 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection.
That is really bad, I am working behind a proxy too.
I've said this before: this can only be developed by someone behind a proxy. Any help would be appreciated. I know it works more or less for plain HTTP, but there are edge cases. There does indeed seem to be a problem with HTTPS, maybe just something small/simple.
That being said, I must say that I do not understand very well how HTTPS proxying might work. I mean, the traffic is by definition encrypted so how can a proxy even do something ? And if there is some way around this, the connection is no longer end-to-end secure. From my point of view, proxies are from last century ;-)
Sven
On 02 Oct 2015, at 20:34, Nicolai Hess <nicolaihess@web.de> wrote:
2015-10-02 19:40 GMT+02:00 Torsten Bergmann <astares@gmx.de <mailto:astares@gmx.de>>:
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection.
That is really bad, I am working behind a proxy too.
but you will not be forced to go through it. this is just if you want to change the icon set. Esteban
Have not tires #50359 but my WFT rate per minute just had a dirac spike. In TWM that I am trying to port to 5.0 there are tons of icons... Geez. Phil On Fri, Oct 2, 2015 at 7:40 PM, Torsten Bergmann <astares@gmx.de> wrote:
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
I know we want to make progress ... but were such changes discussed on the list before?
Thx T.
Hi guys I think that esteban will have some work to detress from FFI and Spur hacking :). Some random thoughts: - We should have by default icon objects (and not their description and the objects in the image) in the image - We should not need to access github to get pharo running :) -- icon description should be cached on the disc (I was teaching in a place where there is no internet). - Icons should probably also delivered modularly (a tool may want to have specific button). - Do not push changes like that the friday afternoon :) Stef Le 2/10/15 19:40, Torsten Bergmann a écrit :
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
I know we want to make progress ... but were such changes discussed on the list before?
Thx T.
On 03 Oct 2015, at 09:35, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that esteban will have some work to detress from FFI and Spur hacking :).
Some random thoughts:
- We should have by default icon objects (and not their description and the objects in the image) in the image
how so?
- We should not need to access github to get pharo running :)
you DO NOT need it!
-- icon description should be cached on the disc (I was teaching in a place where there is no internet).
they are cached :)
- Icons should probably also delivered modularly (a tool may want to have specific button). - Do not push changes like that the friday afternoon :)
well⦠it was yesterday or never. Now I need to finish it, of course :) Anyone wanting to use the old icons still can do: ThemeIcons current: EclipseUIThemeIcons new. (but this will go away, so beware of it) Esteban
Stef
Le 2/10/15 19:40, Torsten Bergmann a écrit :
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
I know we want to make progress ... but were such changes discussed on the list before?
Thx T.
- We should have by default icon objects (and not their description and the objects in the image) in the image
how so? you have them else how can you display them? I mean the objects = form that represent the bitmap of the icons (vs the png file)
- We should not need to access github to get pharo running :) you DO NOT need it!
I know :) now the icons sets (alternate) should be also packaged with the distribution because people may not have nice internet connexion. I should bring you to Togo/Senegal/Algeria/ ... to see what I mean.
-- icon description should be cached on the disc (I was teaching in a place where there is no internet). they are cached :)
- Icons should probably also delivered modularly (a tool may want to have specific button). - Do not push changes like that the friday afternoon :) well⦠it was yesterday or never. Now I need to finish it, of course :)
:)
Anyone wanting to use the old icons still can do:
ThemeIcons current: EclipseUIThemeIcons new.
(but this will go away, so beware of it)
Esteban
Stef
Le 2/10/15 19:40, Torsten Bergmann a écrit :
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
I know we want to make progress ... but were such changes discussed on the list before?
Thx T.
On 03 Oct 2015, at 16:33, stepharo <stepharo@free.fr> wrote:
- We should have by default icon objects (and not their description and the objects in the image) in the image
how so? you have them else how can you display them? I mean the objects = form that represent the bitmap of the icons (vs the png file)
- We should not need to access github to get pharo running :) you DO NOT need it!
I know :) now the icons sets (alternate) should be also packaged with the distribution because people may not have nice internet connexion. I should bring you to Togo/Senegal/Algeria/ ... to see what I mean.
mmm Pharo will come with the default icon set. The other sets are adds that people can use but is not necessary⦠thatâs why we are moving them out image⦠otherwise, we could have them pre-loaded anyway (inside the image, it would be possible, after all). if needed and wanted (but I do not think we really need it), we could add those files to the âportableâ edition⦠but as I said, extra icon sets should not be considered part of the pharo distribution. Esteban
-- icon description should be cached on the disc (I was teaching in a place where there is no internet). they are cached :)
- Icons should probably also delivered modularly (a tool may want to have specific button). - Do not push changes like that the friday afternoon :) well⦠it was yesterday or never. Now I need to finish it, of course :)
:)
Anyone wanting to use the old icons still can do:
ThemeIcons current: EclipseUIThemeIcons new.
(but this will go away, so beware of it)
Esteban
Stef
Le 2/10/15 19:40, Torsten Bergmann a écrit :
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
I know we want to make progress ... but were such changes discussed on the list before?
Thx T.
Hi Esteban, It's broken: "Smalltalk ui icons" now returns an instance of ThemeIconPack instead of the usual ThemeIcons/subclass. But most external packages extended ThemeIcons or subclasses with own icons as this is/was up to the change the default way to do it. It's not possible to access these extensions anymore using Smalltalk ui icons myIcon now. I understand that you needed a "break" - but it is not fun if you "break" ;) Bye T.
Ho Torsten, No, it is not broken. As I said, is an ongoing change: https://pharo.fogbugz.com/f/cases/16651 ThemeIconPack is finally renamed as ThemeIcons and all external packages extending it will be able to use. Now, some thing will not be backward compatibility: - if you used directly ThemeIcons children - it you used outside the class some of the private methods (like *IconContents, etc.) - if you extended ThemeIcons children instead ThemeIcons they will need to be adapted. I hope there are not so many because those issues were never recommended anyway :) (but even if not recommended, I needed to change a lot of miss-uses in some packages⦠I would like to have a monkey rule to forbid this kinds of integrations into the image :S) I started this change last friday, in commit 50357⦠it is tuesday and we are in commit 50366. Itâs been just 4 days and 9 builds⦠(and btw SLICE is not integrated because some weird monkey issues, not because is not ready). so, please⦠be patient! ;) Esteban
On 06 Oct 2015, at 09:54, Torsten Bergmann <astares@gmx.de> wrote:
Hi Esteban,
It's broken: "Smalltalk ui icons" now returns an instance of ThemeIconPack instead of the usual ThemeIcons/subclass.
But most external packages extended ThemeIcons or subclasses with own icons as this is/was up to the change the default way to do it. It's not possible to access these extensions anymore using
Smalltalk ui icons myIcon
now. I understand that you needed a "break" - but it is not fun if you "break" ;)
Bye T.
nope they where âprivateâ, so why to assume it? of course, they can be reintroduced, Iâm not against it⦠:) (but in that case I would not put a misleading âprivateâ as a category :P) Esteban
On 06 Oct 2015, at 15:51, Stephan Eggermont <stephan@stack.nl> wrote:
On 06-10-15 14:04, Esteban Lorenzano wrote:
- it you used outside the class some of the private methods (like *IconContents, etc.)
I assume the private - utilities methods will remain?
Stephan
Hi, this is an ongoing change. I still need to push two slices :) Final change will be backward compatible. What we are doing is eliminating the multiple icon sets from the image⦠we will have just one, and people will be able to load others if desired, but they *will not* live inside the image (I would like to make the same for themes, but thatâs a lot more complicated). The idea is that people can contribute icons / iconpacks same way linux distros work (ok, we are not as big, but you get the idea).
On 02 Oct 2015, at 19:40, Torsten Bergmann <astares@gmx.de> wrote:
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
not really. we decided the change because eclipse icons do not work at all with dark-theme (and there is no easy way to adopt the svg eclipse icons) So after trying a couple of things, we decided that this iconset works fine in all themes (eclipse maybe do not break existing tools, but you cannot use eclipse with dark theme so many people are outside). You will still be able to change to eclipse pack if desired.
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now.
As I say, extension to theme icons will be compatible, just let me finish :) now⦠all subclasses will go away so projects will need to adapt (they will need to extend ThemeIcons instead his children).
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
more or less⦠we do not have still a good way to do that. so, we are adopting something like a âlinux desktopâ style: we allow icon packs to include icons specific to tools. for example, nothing is agains having idea11/eclipse/other icons overlays versionner catalog etc. is not perfect, but since is how linux distros work, I think finding a good solution is not so easy (Iâm playing with some pragma-based ideas but not sure how to implement them yetâ¦)
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
not that I did not think about :) in fact you do not need to go out, is just the way I implemented it in settings. If you have icons package in ./icon-packs, they will be load from there, I will change some stuff then: - I will not auto-fetch available packs. Instead, I will add a âfetchâ button in settings. - I will make possible to specify urls/directories to fetch. - I will add a way to do something like that: ThemeIcons new loadFromArchive: aReference; beCurrent. so anyone can have the iconset they want in their machine and load in startup without going through internet.
I know we want to make progress ... but were such changes discussed on the list before?
I think we discussed it but like one-two years ago⦠just now I got burned by spur and I did this âto relax a bit" :) Iâm sorry if we failed again with communication, sometimes we do not do the movements in right order :( I will try to enhance that. Esteban
Thx T.
On 03 Oct 2015, at 10:13, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
this is an ongoing change. I still need to push two slices :) Final change will be backward compatible.
What we are doing is eliminating the multiple icon sets from the image⦠we will have just one, and people will be able to load others if desired, but they *will not* live inside the image (I would like to make the same for themes, but thatâs a lot more complicated). The idea is that people can contribute icons / iconpacks same way linux distros work (ok, we are not as big, but you get the idea).
On 02 Oct 2015, at 19:40, Torsten Bergmann <astares@gmx.de> wrote:
The latest changes on ThemeIcons completely broke functionality and icons of external and included packages.
1. Intelli J Icons are now used as default, but most icons of external packages (Pomodoro, MongoTools, EventRecorder, ScriptManager, ....) align with the eclipse icon set. Can we please stay with Eclipse as default so that we do not have to introduce intelliJ icons on each external project as well?
not really. we decided the change because eclipse icons do not work at all with dark-theme (and there is no easy way to adopt the svg eclipse icons) So after trying a couple of things, we decided that this iconset works fine in all themes (eclipse maybe do not break existing tools, but you cannot use eclipse with dark theme so many people are outside). You will still be able to change to eclipse pack if desired.
2. The mechanisms of ThemeIcons class do not work anymore. The icons in Versionner are lost. Also other external package who extended ThemeIcons (like DesktopManager) are now broken. Just try to load it into a Pharo5.0 Latest update: #50359 now.
As I say, extension to theme icons will be compatible, just let me finish :) now⦠all subclasses will go away so projects will need to adapt (they will need to extend ThemeIcons instead his children).
3. Some of the icons are removed - for instance in catalog and moved to be retrieved from Github. But we wanted to componentize the image into configs. So the icons of catalog should belong to this project. Right?
more or less⦠we do not have still a good way to do that. so, we are adopting something like a âlinux desktopâ style: we allow icon packs to include icons specific to tools.
for example, nothing is agains having
idea11/eclipse/other icons overlays versionner catalog etc.
is not perfect, but since is how linux distros work, I think finding a good solution is not so easy (Iâm playing with some pragma-based ideas but not sure how to implement them yetâ¦)
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly.
not that I did not think about :)
ouch⦠I meant: ânow, that I did not think about :)" which is exactly the contrary of what it looks with the typo :)
in fact you do not need to go out, is just the way I implemented it in settings. If you have icons package in ./icon-packs, they will be load from there, I will change some stuff then:
- I will not auto-fetch available packs. Instead, I will add a âfetchâ button in settings. - I will make possible to specify urls/directories to fetch. - I will add a way to do something like that:
ThemeIcons new loadFromArchive: aReference; beCurrent.
so anyone can have the iconset they want in their machine and load in startup without going through internet.
I know we want to make progress ... but were such changes discussed on the list before?
I think we discussed it but like one-two years ago⦠just now I got burned by spur and I did this âto relax a bit" :)
Iâm sorry if we failed again with communication, sometimes we do not do the movements in right order :( I will try to enhance that.
Esteban
Thx T.
4. I can not open the settings in the latest image anymore because the icons are tried to retrieve from Github using a HTTPS connection. Doesnt work either because I'm on Windows, because of HTTPs, because ZnClient does not deal with a firewall correctly. It is not good to rely on additional external downloads directly. not that I did not think about :) in fact you do not need to go out, is just the way I implemented it in settings. If you have icons package in ./icon-packs, they will be load from there, I will change some stuff then:
- I will not auto-fetch available packs. Instead, I will add a âfetchâ button in settings. - I will make possible to specify urls/directories to fetch. - I will add a way to do something like that:
ThemeIcons new loadFromArchive: aReference; beCurrent.
so anyone can have the iconset they want in their machine and load in startup without going through internet.
excellent!
I know we want to make progress ... but were such changes discussed on the list before? I think we discussed it but like one-two years ago⦠just now I got burned by spur and I did this âto relax a bit" :)
Iâm sorry if we failed again with communication, sometimes we do not do the movements in right order :( I will try to enhance that.
It should be easy :)
participants (8)
-
Esteban Lorenzano -
Nicolai Hess -
Peter Uhnák -
phil＠highoctane.be -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Torsten Bergmann