This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all convinced.
What do people think about my proposal with adding a picture/drawing per
kid that is part of the Palette then? We can see if we want to transfer
this compressed to
On Thursday, 20 June 2013, Simon Schampijer wrote:
This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all convinced.
The technical solution proposed here has pretty strong implications on the
feature though. It becomes completely
I agree that the technical solution we have come up with to a large
extent obviates the need for consensus around whether or not to
implement this feature as it pushes it to the user space in the from
of an activity. (Gonzalo and I have been discussing the fact that
other cpsection widgets could
On 06/20/2013 12:16 PM, Daniel Narvaez wrote:
On Thursday, 20 June 2013, Simon Schampijer wrote:
This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all convinced.
The technical solution proposed here has pretty strong
I still think adding a photo/drawing would be a valuable addition.
This involves a lot of code rewrite..
I'm making a new activity for set XoIcon
My idea is: A simple plaint for make svg icons.!
2013/6/20 Simon Schampijer si...@schampijer.de
On 06/20/2013 12:16 PM, Daniel Narvaez wrote:
On Thu, Jun 20, 2013 at 7:32 AM, Simon Schampijer si...@schampijer.de wrote:
On 06/20/2013 12:16 PM, Daniel Narvaez wrote:
On Thursday, 20 June 2013, Simon Schampijer wrote:
This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all
On 06/20/2013 01:28 PM, Walter Bender wrote:
I agree that the technical solution we have come up with to a large
extent obviates the need for consensus around whether or not to
implement this feature as it pushes it to the user space in the from
of an activity. (Gonzalo and I have been
On 20 June 2013 13:28, Walter Bender walter.ben...@gmail.com wrote:
Regarding our broken decision-making process, the problem I have is
less that we don't reach consensus than that the discussions are
happening very late in the process. We had, for example, had an email
from our release
Yes it was accepted. You can see the list of accepted features here
https://github.com/sugarlabs/roadmap/issues?milestone=1state=open
On 20 June 2013 13:40, Simon Schampijer si...@schampijer.de wrote:
On 06/20/2013 01:28 PM, Walter Bender wrote:
I agree that the technical solution we have
:)
https://github.com/sugarlabs/roadmap/issues/7
Don't likes this feature. But I will do everything possible to work and be
approved by the community!
2013/6/20 Daniel Narvaez dwnarv...@gmail.com
Yes it was accepted. You can see the list of accepted features here
On 20 June 2013 13:32, Simon Schampijer si...@schampijer.de wrote:
For such a change I would like to see a design discussion first
independent from the implementation. It is relatively easy to quickly
implement something that sort of works, to hack something but creating a
good user
On 20 June 2013 13:40, Simon Schampijer si...@schampijer.de wrote:
Has there been a mail to ask for feedback for the design?
Not that I can find. Though I'd say the features discussion should be a
chance for the design team to take a look to the proposals and give input
if they are aspects
There seem to be agreement that the ability to override theme icons makes
sense as a backend, not user visible feature. Since that's the only
dependency for Walter proposal I think we could probably just punt the icon
change feature from 0.100. In the proposed implementation it's not a
feature of
If we can at least land the patch to extend the icon search path in
the theme to include env.get_profile_path()/icons then we have the
opportunity to user-space mods. Without that, it would be difficult
for our users, w/o root access, to make changes.
-walter
On Thu, Jun 20, 2013 at 9:08 AM,
Yeah that's what I mean with the backend ability to override theme icons.
On Thursday, 20 June 2013, Walter Bender wrote:
If we can at least land the patch to extend the icon search path in
the theme to include env.get_profile_path()/icons then we have the
opportunity to user-space mods.
Here are some thoughts about the custom icon patch:
(1) if we prepend ~/.sugar/icons to the theme icon path, then anything
in that path will be used (as long as we flush the cache) as per
dnarvaez's comment on the patch
(2) if we have a sugar activity for selecting svg files (from the
journal and
On Wed, Jun 19, 2013 at 10:53 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
About the cache, did you try
https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-rescan-if-needed
Tried that. Sugar seems to cache its icons separately from GTK. There
used to be a cache file, but
On Wed, Jun 19, 2013 at 11:53 AM, Daniel Narvaez dwnarv...@gmail.comwrote:
About the cache, did you try
https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-rescan-if-needed
I think the cache involved is in icon.py _SVGLoader.
Right now, does not check if the file was
About the cache, did you try
https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-theme-rescan-if-needed
On Wednesday, 19 June 2013, Walter Bender wrote:
Here are some thoughts about the custom icon patch:
(1) if we prepend ~/.sugar/icons to the theme icon path, then anything
Oh yes, you will need to invalidate both caches. I guess the shell can keep
a file monitor on the icons dir and invalidate when it changes.
On Wednesday, 19 June 2013, Walter Bender wrote:
On Wed, Jun 19, 2013 at 10:53 AM, Daniel Narvaez
dwnarv...@gmail.comjavascript:;
wrote:
About the
If inotify is available it will use that I think. Checking time is an
option for the sugar cache (file content) but not for the gtk one (file
path).
Perhaps it's fine if the change is picked up on activity restart? It will
probably not auto apply anyway, only newly created icons will change even
Hmm, that will be a file monitor for every activity running too,
if I am not wrong, that is implemented polling,
may be is better check datetime modification when one icon is needed.
Gonzalo
On Wed, Jun 19, 2013 at 12:05 PM, Daniel Narvaez dwnarv...@gmail.comwrote:
Oh yes, you will need to
Actually gtk supports on the fly changes, so in theory that's possible
(will likely require sugar fixes). I'm not too sure if that works well when
an icon inside a theme changes rather than the whole theme though.
I suspect finding the best solution will involve reading gtk icon themes
code here
23 matches
Mail list logo
