Re: [E-devel] E/ELM fdo icon config issues

[Massimo Maiurana]

As a simple user I think this makes perfect sense.
I would only add a tiny message to tell it to the user, just to be sure
it is clear. Something like "This will try to set an icon theme for
other Fdo compliant environments, rely on the specific tool if you want
to set them different". I'm sure you'll render it in a better english :)

Bye
Massimo

Andrew Williams ha scritto il 28/08/2016 alle 01:28:
> After chatting on IRC I think there is another approach.
> The underlying principle is that we have 2 different viewpoints - that
> which elm is FDo compliant - and that which it should be seperate.
> 
> If the elm icon theme were able to hint at which FDo theme it is
> complatible with (if any) as mentioned earlier then we could do this:
> *) remove E's "icon theme for enlightenment" checkbox - we should always
> assume you are configuring E
> *) update the "icon theme for applications" checkbox to also apply to efl
> apps
> *) when the user selects an FDo icon theme we iterate through all the elm
> themes to see if any declare a match - and if so and the "icon theme for
> applications" is set then we tell elm to use it's theme instead of the FDo
> one.
> 
> In this manner anyone wanting GTK or ELM specific icons could still run
> their own configuration tool (elm_config will not know how to do the lookup
> to affect other (i.e. GTK) apps when chosing a theme that happens to be
> marked as matching an FDO theme.
> 
> Of course that relies on the appropriate theme being installed as well,
> which can be checked for.
> 
> I think this accomplishes all the requirements with the addition of not
> being any more complex for the user. I'm not really so sure we should have
> seperate checkboxes for ELM and "GTK" as the non-elm applies to all other
> apps, being an FDo spec that we are trying to comply with. Going with the
> existing "icon theme for applications" to apply to all toolkits seems to
> make sense.
> 
> Would this work?
> Andrew
> 
> On Sat, 27 Aug 2016 at 18:11 Davide Andreoli  wrote:
> 
>> 2016-08-27 17:52 GMT+02:00 Davide Andreoli :
>>
>>> 2016-08-27 17:23 GMT+02:00 Andrew Williams :
>>>
 I think the complexity is that Enlightenment looks at this all the other
 way around.
 I.e. Choose your theme - and do you want it to apply to apps as well?
 I'm tempted to go in and remove all the complexity and have it be just
 that
 (I.e. Ignore elm vs gtk as seperate values) then it would make more
>> sense
 for elm to try and say what gtk theme matches. But at the moment (in E)
 the
 user could have specified that this is not the chosen behaviour but elm
 won't know that.

 My aim in all of this is to provide a consistent experience but maybe
 others prefer the config options approach?

>>>
>>> I don't want/need a consistent experience (between ELM and GTK). I just
>>> want
>>> gtk to looks beautiful with it's Mint-X icons and elm to look beautiful
>>> (and be fast)
>>> with the icons embedded in theme. I don't neither use a gtk theme that
>>> match the
>>> elm one, on my system gtk apps are light and elm are dark, I like this
>>> separation.
>>>
>>> Please make a system that permit this type of configuration. Don't forget
>>> the
>>> fundamental E principle: let the user choose !
>>>
>>
>> After some more thinking about the E config dialog I ended up that
>> list+checks
>> are the wrong choice, if we want to give the user the "power to choose" we
>> need
>> 3 independent lists, so that user can choose the icons for ELM, the icons
>> for GTK
>> and the icons for E itself. This could be made with 2 new tabs, so that we
>> end up
>> with 3 tabs for icons: "ELM icons", "GTK icons", "E icons".
>> ...or maybe on a single page with just 3 combobox.
>>
>>
>>>
>>>

 Andrew
 On Sat, 27 Aug 2016 at 15:00, Stephen Houston 
 wrote:

> Would it not be simpler for Edje theme to provide a data in the elm
 config
> stating the matching fdo icon theme and then just have a check box in
 the
> Enlightenment dialog that says match elm theme? data.item: "matching"
> "Enlightenment-X"; if use matching is checked, then elm uses its
 internal
> icons and enlightenment uses specified date string.
>
> On Sat, Aug 27, 2016, 2:56 AM Davide Andreoli >>
> wrote:
>
>> 2016-08-27 6:00 GMT+02:00 Simon Lees :
>>
>>>
>>>
>>> On 08/27/2016 11:46 AM, Carsten Haitzler (The Rasterman) wrote:
 On Fri, 26 Aug 2016 10:04:51 +0200 Davide Andreoli <
>>> d...@gurumeditation.it>
 said:

> Hi all (Andrew in particular)
>
> I really think we have 2 issue in the way we let the user
 configure
>> the
>>> fdo
> icon theme for their system.
>
> 1. In the E config we have a list of fdo themes and 2 checkbox:
>   * Enable for applications
>   * Enable for Enlightenment
>
> The first one will set the theme 

[EGIT] [core/enlightenment] annotated tag v0.21.2 created (now 6936f5a)

[Enlightenment Git]

This is an automated email from the git hooks/post-receive script.

simotek pushed a change to annotated tag v0.21.2
in repository core/enlightenment.

at  6936f5a   (tag)
   tagging  4000ac4e40b04cec9941040ea18a3f1077cd3193 (commit)
  replaces  v0.21.1
 tagged by  Simon Lees
on  Mon Aug 22 11:11:14 2016 +0930

- Log -
21.2 Release

Carsten Haitzler (7):
  e - fix dnd problems coming from getting top object in comp canvas
  e ibar/ibox port to elm box - fix assumption on resize
  e - fix major memory bloat when in gl mode - dont create shm segments
  e temp module - kill tempget process not terminate to ensure death
  e ibar - fix devilhorns fix to use the right widght and hight for 
separator
  e comp - set alpha after setting native surface to avoid random crash
  e ipc - fix cleanup of ipc socket on shutdown

Chidambar Zinnoury (3):
  e: Don’t show two consecutive menu separators if there is no need in 
client menu.
  e fm: Add a separator only if there is something before.
  e fm: Don’t check every other line whether the location is writable when 
creating menu.

Christopher Michael (7):
  Revert "e - fix major memory bloat when in gl mode - dont create shm 
segments"
  remove unused variables from _ibar_resize_handle
  use proper variables to set size_hint_max on ibar
  e ibar - fix "old man" fat finger typo ;)
  remove need to create different dialog windows under wayland
  wl_fb: Check that e_comp_wl_init does not fail.
  add key_up and key_down methods to sreen interface

Derek Foreman (2):
  Fix wayland clients not deleting when they're hidden
  Fix wayland extension global creation

Jean-Philippe ANDRÉ (1):
  bg: Fix bg with single jpeg images (no edj)

JengHyun Kang (1):
  e_comp_wl: break from meaningless loop

Marcel Hollerbach (4):
  e_comp_wl: destroy e_drag when source disappears
  e_alert: define EFL_BETA_API_SUPPORT before any include
  e_dnd: move the ungrab to the object free
  xwayland: show the dialog after ecore_wl2 is in sync

Massimo Maiurana (2):
  Updating italian and spanish translations
  Updating italian translation

Mike Blumenkrantz (10):
  only check x11 configurerequest geometry changes when applicable
  improve quickaccess relaunch help dialog text
  move new version of e_comp_top_window_at_xy_get() to dnd, restore old 
version
  clear wl subsurface data during delete only if subsurface is not also 
deleted
  add xwayland compat for efl 1.19+
  bump efl wayland req to 1.18 now that it's out
  Revert "track/manage size hints for zoomap child objects"
  track current bryce geom, force recalc on gadget site upon change
  clean up some string leaks in wireless gadget popups
  delete previous wireless popup when activating editor from connection list

Romain Naour (1):
  E: include uuid.h only when Wayland support is enabled.

Simon Lees (3):
  README.wayland --enable-elput is required for building wayland efl
  21.2 Release
  21.2 NEWS Updates

Stefan Schmidt (1):
  mailmap: sync updated file from efl repo

---

This annotated tag includes the following new commits:

   new  06f7fd2   21.2 Release
   new  4000ac4   21.2 NEWS Updates

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


-- 

[EGIT] [core/enlightenment] enlightenment-0.21 01/02: 21.2 Release

[Simon Lees]

simotek pushed a commit to branch enlightenment-0.21.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=06f7fd2b89bdc0a19aed5314951db09b2d07534a

commit 06f7fd2b89bdc0a19aed5314951db09b2d07534a
Author: Simon Lees 
Date:   Sun Aug 21 16:39:44 2016 +0930

21.2 Release
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7608181..14897e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,11 +2,11 @@
 ##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
 m4_define([v_maj], [0])
 m4_define([v_min], [21])
-m4_define([v_mic], [1])
+m4_define([v_mic], [2])
 m4_define([v_rev], m4_esyscmd([(git rev-list --count HEAD 2>/dev/null || echo 
0) | tr -d '\n']))dnl
 ##--   When released, remove the dnl on the below line
 m4_undefine([v_rev])
-m4_define([relname], [0.21.0])
+m4_define([relname], [0.21.2])
 ##--   When doing snapshots - change soname. remove dnl on below line
 m4_define([relname], [ver-0.21])
 dnl m4_define([v_rel], [-release relname])

-- 

[EGIT] [core/enlightenment] enlightenment-0.21 02/02: 21.2 NEWS Updates

[Simon Lees]

simotek pushed a commit to branch enlightenment-0.21.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=4000ac4e40b04cec9941040ea18a3f1077cd3193

commit 4000ac4e40b04cec9941040ea18a3f1077cd3193
Author: Simon Lees 
Date:   Sun Aug 21 16:40:05 2016 +0930

21.2 NEWS Updates
---
 NEWS | 63 +++
 1 file changed, 63 insertions(+)

diff --git a/NEWS b/NEWS
index 2c303da..83a6078 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,66 @@
+Release 0.21.2:
+-
+Carsten Haitzler (6):
+  e - fix dnd problems coming from getting top object in comp canvas
+  e ibar/ibox port to elm box - fix assumption on resize
+  e temp module - kill tempget process not terminate to ensure death
+  e ibar - fix devilhorns fix to use the right widght and hight for 
separator
+  e comp - set alpha after setting native surface to avoid random crash
+  e ipc - fix cleanup of ipc socket on shutdown
+
+Chidambar Zinnoury (3):
+  e: Don’t show two consecutive menu separators if there is no need in 
client menu.
+  e fm: Add a separator only if there is something before.
+  e fm: Don’t check every other line whether the location is writable when 
creating menu.
+
+Christopher Michael (6):
+  remove unused variables from _ibar_resize_handle
+  use proper variables to set size_hint_max on ibar
+  e ibar - fix "old man" fat finger typo ;)
+  remove need to create different dialog windows under wayland
+  wl_fb: Check that e_comp_wl_init does not fail.
+  add key_up and key_down methods to sreen interface
+
+Derek Foreman (2):
+  Fix wayland clients not deleting when they're hidden
+  Fix wayland extension global creation
+
+Jean-Philippe ANDRÉ (1):
+  bg: Fix bg with single jpeg images (no edj)
+
+JengHyun Kang (1):
+  e_comp_wl: break from meaningless loop
+
+Marcel Hollerbach (4):
+  e_comp_wl: destroy e_drag when source disappears
+  e_alert: define EFL_BETA_API_SUPPORT before any include
+  e_dnd: move the ungrab to the object free
+  xwayland: show the dialog after ecore_wl2 is in sync
+
+Massimo Maiurana (2):
+  Updating italian and spanish translations
+  Updating italian translation
+
+Mike Blumenkrantz (9):
+  only check x11 configurerequest geometry changes when applicable
+  improve quickaccess relaunch help dialog text
+  move new version of e_comp_top_window_at_xy_get() to dnd, restore old 
version
+  clear wl subsurface data during delete only if subsurface is not also 
deleted
+  add xwayland compat for efl 1.19+
+  bump efl wayland req to 1.18 now that it's out
+  Revert "track/manage size hints for zoomap child objects"
+  track current bryce geom, force recalc on gadget site upon change
+  clean up some string leaks in wireless gadget popups
+
+Romain Naour (1):
+  E: include uuid.h only when Wayland support is enabled.
+
+Simon Lees (1):
+  README.wayland --enable-elput is required for building wayland efl
+
+Stefan Schmidt (1):
+  mailmap: sync updated file from efl repo
+
 Release 0.21.1:
 -
 Al Poole (1):

-- 

Re: [E-devel] Mac for EFL build bot.

[Jean Guyomarc'h]

Hi,

I can't tell you how to integrate your machine into the E
infrastructure (because I don't know :p) but here is what I think
would be nice to have:
1) one VM dedicated to EFL builds would be very cool.
2) Ideally, it should always run the latest OSX version (OSX can be
downloaded and installed for free) with the latest SDK (automatically
brought by Xcode)
I don't think it is necessary to build for several versions of OSX, so
we shouldn't have need for several VMs (e.g. one per OSX version) or
several SDKs (would take a lt of time to build).

And thank you for proposing a mac build bot :-)

Best regards,
Jean


On Sun, Aug 28, 2016 at 4:09 AM, David Seikel  wrote:
> On Fri, 26 Aug 2016 09:55:59 +1000 David Seikel 
> wrote:
>
>> On Thu, 25 Aug 2016 10:56:35 -0700 Cedric BAIL 
>> wrote:
>>
>> > On Thu, Aug 25, 2016 at 10:34 AM, Jean Guyomarc'h
>> >  wrote:
>> > > I guess the Jenkins could use it as a slave (or an OSX VM running
>> > > atop of it). There was a discussion with Cedric and Stefan about
>> > > adding a mac in the build infra, but I don't know what happened...
>> >
>> > We need to get a working VPN infrastructure to connect it to our
>> > server. I actually also have an Odroid XU3 supposed to do the same
>> > for ARM. Beber was investigating it a few weeks back and I kind of
>> > forgot to ping him on the subject during last month coding rush.
>>
>> I had doubled the RAM in it earlier this year, for no other reason
>> than I had some suitable RAM left over after upgrading something
>> else, so it has plenty of RAM for a VM.  I already run ssh and
>> Splashtop servers on it so another developer can use it for virtual
>> world development.  I can easily add a VPN as well.  For those that
>> don't know, Splashtop is remote desktop software that can handle 3D
>> graphics, audio, and video, making it suitable for virtual world
>> work, none of the other remote desktop software can handle that.
>>
>> I have plenty of time, but no money (currently unemployed), so just
>> let me know what needs to be done, and I can do it.  Also let me know
>> what sort of bandwidth would be needed, I tend to be very careful
>> with that, bandwidth is very expensive in this country.
>
> Can I get some answers here soon please?  That other virtual world
> developer wants me to upgrade the OS and XCode, or run a VM with a
> different OS, and I need to figure out both sets of requirements, plus
> my own, before I can start to plan it all.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
> --
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac for EFL build bot.

[David Seikel]

On Sun, 28 Aug 2016 11:22:49 +0200 "Jean Guyomarc'h"
 wrote:

> I can't tell you how to integrate your machine into the E
> infrastructure (because I don't know :p) but here is what I think
> would be nice to have:
> 1) one VM dedicated to EFL builds would be very cool.
> 2) Ideally, it should always run the latest OSX version (OSX can be
> downloaded and installed for free) with the latest SDK (automatically
> brought by Xcode)
> I don't think it is necessary to build for several versions of OSX, so
> we shouldn't have need for several VMs (e.g. one per OSX version) or
> several SDKs (would take a lt of time to build).

Well, I don't have enough resources for running several VMs at the same
time, likely only one at a time.  So that would be two OS versions
running at once, the host OS and the guest VM.  I doubt if we need a VM
just for building, it's more to be able to cater for a couple of OS
versions.  Certainly I could have several VMs for several OS versions,
so long as only one VM runs at a time, there's plenty of storage space.
My Mac Mini came with a 1 TB drive, it's over 90% empty.  I build my
virtual world viewer releases by scripted firing up of Linux and Windows
VMs to do the work, I can handle this sort of thing for a build bot.

Building for multiple SDKs is easier, multiple SDKs can live on one
OS.  There are restrictions on which version of SDK / XCode runs under
which version of the OS though, as I found when I built this system in
the first place.

Building virtual world viewers that are based on the bloated Second
Life viewer builds quicker with lots of RAM, where EFL builds are more
CPU bound I have found.  On my Linux dev box, building a viewer and
building the entirety of E's git takes about the same amount of time.
Jenkins probably isn't in a hurry though, and likely doesn't need to
build everything in E's git.  Doubling my Macs RAM happened purely by
accident, I had suitable RAM left over after upgrading another box, so
the original amount of RAM was already perfectly suitable for viewer
building and testing, that's what the box was built for.  Which means I
have twice as much RAM than needed now.  B-)

The hard part for me is to keep everyone happy, including myself.  Once
I know what every one requires, then I can start to juggle the
resources I have.  The other virtual world developer (Nicky) has told me
what he requires, I know what I require, now I'm just waiting for the
EFL developers to come to the party so I can get started figuring it all
out.

Right now I'm thinking about keeping the host OS fully up to date with
the latest versions of everything, then setting up what ever VMs are
needed for what ever older OS versions are needed by us all.  Seems
reasonable, and perhaps slightly more secure, based on the theory that
latest stuff has security holes plugged quicker.

Oh, and running VMs gets around Apples lack of legal support for
multiple users at the same time.  A VM per user, and don't count
services like build bots as a user, that should work legally.  Nicky
lives on the opposite side of the planet from me, so it's not been that
hard making sure only one of us uses it at a time.

> And thank you for proposing a mac build bot :-)

Well, other than building and testing virtual world viewers for myself
and Nicky, it's sitting there gathering dust.  Might as well put it to
good use.  Cost me enough.  lol

> Best regards,
> Jean
> 
> 
> On Sun, Aug 28, 2016 at 4:09 AM, David Seikel 
> wrote:
> > On Fri, 26 Aug 2016 09:55:59 +1000 David Seikel 
> > wrote:
> >
> >> On Thu, 25 Aug 2016 10:56:35 -0700 Cedric BAIL
> >>  wrote:
> >>
> >> > On Thu, Aug 25, 2016 at 10:34 AM, Jean Guyomarc'h
> >> >  wrote:
> >> > > I guess the Jenkins could use it as a slave (or an OSX VM
> >> > > running atop of it). There was a discussion with Cedric and
> >> > > Stefan about adding a mac in the build infra, but I don't know
> >> > > what happened...
> >> >
> >> > We need to get a working VPN infrastructure to connect it to our
> >> > server. I actually also have an Odroid XU3 supposed to do the
> >> > same for ARM. Beber was investigating it a few weeks back and I
> >> > kind of forgot to ping him on the subject during last month
> >> > coding rush.
> >>
> >> I had doubled the RAM in it earlier this year, for no other reason
> >> than I had some suitable RAM left over after upgrading something
> >> else, so it has plenty of RAM for a VM.  I already run ssh and
> >> Splashtop servers on it so another developer can use it for virtual
> >> world development.  I can easily add a VPN as well.  For those that
> >> don't know, Splashtop is remote desktop software that can handle 3D
> >> graphics, audio, and video, making it suitable for virtual world
> >> work, none of the other remote desktop software can handle that.
> >>
> >> I have plenty of time, but no money (currently unemployed), so just
> >> let me know what needs to be done, and I can do it.  Also let me
> >> know what sort of bandwidth wou

Re: [E-devel] E/ELM fdo icon config issues

[Simon Lees]

Hi All,

I'm going to start again, we just had another discussion on IRC and this
is what we seem to have come to, i'm sorry if I repeat something I only
skim read some of the discussion.

Firstly all non FDO standard icons used in elm/e will be installed into
the hicolor icon theme this means that if users choose to use any FDO
icon theme which doesn't have all the icons enlightenment / elm will
just use the existing fallback mechanisms.

The configuration dialog will be simplified too two settings (If I got
this right), firstly you will be able to choose a FDO icon theme,
Secondly you will be able to choose if Enlightenment and Elm apps use
the icon set from the enlightenment/elm theme (.edj) or from the current
FDO theme.

This implementation is simple and straight forward but has a couple of
caveats, Firstly if you would like e to use a different theme to the FDO
theme and the one provided by your current enlightenment theme bad luck
for now you will need to modify your enlightenment theme (This won't be
as bad once we make a way to provide composite themes). Similarly if you
are using a theme that is recolored and you choose to use a FDO icon
theme rather then the one from the .edj you will fall back to blue icons
rather then icons of the color of your theme, there are 2 work arounds
here, import the FDO theme you are using into the .edj file and get e to
use the theme from that or also recolor the Enlightenment-X theme and
get the FDO theme of your choosing to fallback through the recolored
Enlightenment-X.

Dave has volunteered to do at least the icon related changes and will
aim to do that for efl 1.19, after that point we can look at rewriting
the theme dialog probably as part of e22.

Cheers

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E/ELM fdo icon config issues

[Stephen Houston]

I think Andrew's proposal solves the problems for everyone without the
caveats. That's what I would vote for.

On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:

> Hi All,
>
> I'm going to start again, we just had another discussion on IRC and this
> is what we seem to have come to, i'm sorry if I repeat something I only
> skim read some of the discussion.
>
> Firstly all non FDO standard icons used in elm/e will be installed into
> the hicolor icon theme this means that if users choose to use any FDO
> icon theme which doesn't have all the icons enlightenment / elm will
> just use the existing fallback mechanisms.
>
> The configuration dialog will be simplified too two settings (If I got
> this right), firstly you will be able to choose a FDO icon theme,
> Secondly you will be able to choose if Enlightenment and Elm apps use
> the icon set from the enlightenment/elm theme (.edj) or from the current
> FDO theme.
>
> This implementation is simple and straight forward but has a couple of
> caveats, Firstly if you would like e to use a different theme to the FDO
> theme and the one provided by your current enlightenment theme bad luck
> for now you will need to modify your enlightenment theme (This won't be
> as bad once we make a way to provide composite themes). Similarly if you
> are using a theme that is recolored and you choose to use a FDO icon
> theme rather then the one from the .edj you will fall back to blue icons
> rather then icons of the color of your theme, there are 2 work arounds
> here, import the FDO theme you are using into the .edj file and get e to
> use the theme from that or also recolor the Enlightenment-X theme and
> get the FDO theme of your choosing to fallback through the recolored
> Enlightenment-X.
>
> Dave has volunteered to do at least the icon related changes and will
> aim to do that for efl 1.19, after that point we can look at rewriting
> the theme dialog probably as part of e22.
>
> Cheers
>
> --
>
> Simon Lees (Simotek)http://simotek.net
>
> Emergency Update Team   keybase.io/simotek
> SUSE LinuxAdeliade Australia, UTC+9:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E/ELM fdo icon config issues

[Simon Lees]

On 08/28/2016 10:02 PM, Stephen Houston wrote:
> I think Andrew's proposal solves the problems for everyone without the
> caveats. That's what I would vote for.
> 
It still has the same issues of setting e to use a theme different from
the FDO theme and .edj file (This is probably only very few people).
Rather then having the second issue the user would simply get no icons
if they chose an FDO theme and it is missing some of the required icons
they would get no icons, we could still implement the match thing but in
the case of matching FDO and Elm theme the user could just not select
"Use FDO Icons for E" which saves some code and needing to modify every
theme to contain a matching icon theme, we could implement the opposite
though so that each E theme can recommend a FDO icon set and if you have
a box checked E automatically updates the FDO icon set for Qt/GTK when
you change e themes similar to the wallpaper dialog. Again that doesn't
give you much more and would annoy some users enough that it probably
couldn't be default behavior.

> On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:
> 
>> Hi All,
>>
>> I'm going to start again, we just had another discussion on IRC and this
>> is what we seem to have come to, i'm sorry if I repeat something I only
>> skim read some of the discussion.
>>
>> Firstly all non FDO standard icons used in elm/e will be installed into
>> the hicolor icon theme this means that if users choose to use any FDO
>> icon theme which doesn't have all the icons enlightenment / elm will
>> just use the existing fallback mechanisms.
>>
>> The configuration dialog will be simplified too two settings (If I got
>> this right), firstly you will be able to choose a FDO icon theme,
>> Secondly you will be able to choose if Enlightenment and Elm apps use
>> the icon set from the enlightenment/elm theme (.edj) or from the current
>> FDO theme.
>>
>> This implementation is simple and straight forward but has a couple of
>> caveats, Firstly if you would like e to use a different theme to the FDO
>> theme and the one provided by your current enlightenment theme bad luck
>> for now you will need to modify your enlightenment theme (This won't be
>> as bad once we make a way to provide composite themes). Similarly if you
>> are using a theme that is recolored and you choose to use a FDO icon
>> theme rather then the one from the .edj you will fall back to blue icons
>> rather then icons of the color of your theme, there are 2 work arounds
>> here, import the FDO theme you are using into the .edj file and get e to
>> use the theme from that or also recolor the Enlightenment-X theme and
>> get the FDO theme of your choosing to fallback through the recolored
>> Enlightenment-X.
>>
>> Dave has volunteered to do at least the icon related changes and will
>> aim to do that for efl 1.19, after that point we can look at rewriting
>> the theme dialog probably as part of e22.
>>
>> Cheers
>>
>> --
>>
>> Simon Lees (Simotek)http://simotek.net
>>
>> Emergency Update Team   keybase.io/simotek
>> SUSE LinuxAdeliade Australia, UTC+9:30
>> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>>
>>
>> --
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [website/planet] master 01/01: MINOR: config: Remove raster dead blog

[Bertrand Jacquin]

beber pushed a commit to branch master.

http://git.enlightenment.org/website/planet.git/commit/?id=6f0e0476ac73b19c57dcca2d4e589730585dddcb

commit 6f0e0476ac73b19c57dcca2d4e589730585dddcb
Author: Bertrand Jacquin 
Date:   Sun Aug 28 17:11:48 2016 +0100

MINOR: config: Remove raster dead blog
---
 conf/config.ini | 5 -
 1 file changed, 5 deletions(-)

diff --git a/conf/config.ini b/conf/config.ini
index d1bfefa..f2090f9 100644
--- a/conf/config.ini
+++ b/conf/config.ini
@@ -97,11 +97,6 @@ name = ~Deon Thomas
 user = thanatermesis
 name = ~Thanatermesis
 
-[http://www.rasterman.com/rss.xml]
-user = raster
-name = ~Carsten Haitzler
-face = yes
-
 [http://www.ravenlock.us/blog/?feed=rss2]
 user = ravenlock
 name = ~Eric Schuele

-- 

Re: [E-devel] Hosting for new theme site

[Bertrand Jacquin]

Hi Andrew,

I think you missed an email I sent you:

- Can you use distutil or something like this to automate installation ?
- Can you try to use mod_python to avoid having to run a daemon ? That
  would help automation

Cheers

On Fri, Aug 26, 2016 at 02:20:15PM +, Andrew Williams wrote:
> How are we going with this configuration? Is there anything more you need
> from me?
> 
> Thanks,
> Andy
> 
> On Fri, 12 Aug 2016 at 22:59, Andrew Williams  wrote:
> 
> > I've added the license and a "release" branch - I hope branch is OK, I
> > prefer that to shifting a tag for latest release.
> > If you need distutil in there too I shall try to look at it tomorrow -
> > that's new to me.
> >
> > Thanks again,
> > Andrew
> >
> > On Fri, 12 Aug 2016 at 22:44 Andrew Williams  wrote:
> >
> >> Aha, I see you applied them already - thanks :)
> >>
> >> Andrew
> >>
> >> On Fri, 12 Aug 2016 at 22:26 Andrew Williams 
> >> wrote:
> >>
> >>> Thanks so much for all of this, looking at it just now.
> >>> Andrew
> >>> On Fri, 12 Aug 2016 at 21:03, Bertrand Jacquin 
> >>> wrote:
> >>>
>  Can you please apply to two attached patches ?
> 
>  Thanks
> 
>  On Fri, Aug 12, 2016 at 08:59:27PM +0100, Bertrand Jacquin wrote:
>  > Also, sheebang is missing on run.py
>  >
>  > On Fri, Aug 12, 2016 at 08:47:16PM +0100, Bertrand Jacquin wrote:
>  > > Hi Andrew,
>  > >
>  > > Mutliple comments about the app:
>  > >
>  > > - Can you please create tag release so I can stick on it ?
>  > > - Can you define the licence in the code itself ?
>  > > - Can you disable the debug mode by default ?
>  > > - Can you use distutil or something like this to automate
>  installation ?
>  > > - Can you try to use mod_python to avoid having to run a daemon ?
>  That
>  > >   would help automation
>  > >
>  > > Cheers,
>  > > Beber
>  > >
>  > > On Thu, Aug 11, 2016 at 02:40:46PM +, Andrew Williams wrote:
>  > > > Hi,
>  > > >
>  > > > Thanks so much for looking at this :)
>  > > > Git is
>  https://git.enlightenment.org/devs/ajwillia-ms/extra-server.git/
>  > > > Probably needs to move if it proves to be successful.
>  > > >
>  > > > Thanks again - ping me if you have something and I'll test it out.
>  > > > Andrew
>  > > > On Thu, 11 Aug 2016 at 13:32, Bertrand Jacquin
>   wrote:
>  > > >
>  > > > > How in the name of Jaysus are ya,
>  > > > >
>  > > > > Thanks for the forward raster, I'll do the needed bits on DNS,
>  getting
>  > > > > extra-server
>  > > > > deployed to e5-web1 and enable the git deployment hooks during
>  the week
>  > > > > end.
>  > > > >
>  > > > > Andy, can you share with me the git repo for extra.e.org so I
>  can do the
>  > > > > preliminary tests ?
>  > > > >
>  > > > > Slán
>  > > > > Bertrand
>  > > > >
>  > > > > On 11/08/2016 03:58, Carsten Haitzler wrote:
>  > > > > > On Sat, 06 Aug 2016 22:28:13 + Andrew Williams
>  > > > > >  said:
>  > > > > >
>  > > > > > hey beber. did you see this? does andy have to do anything to
>  help you
>  > > > > > out? let
>  > > > > > him know! :)
>  > > > > >
>  > > > > >> Hi all,
>  > > > > >>
>  > > > > >> So I finally have a little more time to work on some theme
>  > > > > >> distribution /
>  > > > > >> discovery and have a pretty skeletal server code stack set
>  up.
>  > > > > >> To start getting folk interested I hoped this could be moved
>  to host
>  > > > > >> on E
>  > > > > >> infrastructure...
>  > > > > >>
>  > > > > >> Can anyone please get the python app in
>  devs/ajwillia-ms/extra-server
>  > > > > >> running on one of our hosts and point the dns
>  extra.enlightenment.org
>  > > > > >> at it
>  > > > > >> with whatever virtualhost config is needed? As a bonus can
>  the server
>  > > > > >> update on a git hook? :)
>  > > > > >>
>  > > > > >> Thanks so much!
>  > > > > >> I'm working on "extra" (the client) as well - hoping to get
>  theme and
>  > > > > >> wallpaper listing and download working in a week or so...
>  > > > > >>
>  > > > > >> Thanks for listening :)
>  > > > > >> Andrew
>  > > > > >>
>  > > > >
>  --
>  > > > > >> ___
>  > > > > >> enlightenment-devel mailing list
>  > > > > >> enlightenment-devel@lists.sourceforge.net
>  > > > > >>
>  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>  > > > > >>
>  > > > >
>  > > > > --
>  > > > > Bertrand
>  > > > >
>  > >
>  > > --
>  > > Bertrand
>  >
>  >
>  >
>  > --
>  > Bertrand
> 
> 
> 
>  --
>  Bertrand
> 
> >>>

-- 

Re: [E-devel] E/ELM fdo icon config issues

[Andrew Williams]

I don't understand why we want to expose the choice of efl widget set icons
in E - users can override a default using elm_config if they want to but
promoting this choice in E seems strange - basically a "do you want your
other apps to look different to E ones?"

I like the description of elm icons as an optimisation because fdo is
really slow. With this in mind we could implement it purely as an
optimisation so when the fdo choice can be mapped to edj then we do so
automatically.
You would still need to fall back to hicolor but it's less likely to happen
if I understand correctly?

For me I think we should be fdo compliant and make it transparent for
users. Otherwise we should probably just ignore the standards and hope folk
make icon sets specifically for us...

Andrew
On Sun, 28 Aug 2016 at 14:52, Simon Lees  wrote:

>
>
> On 08/28/2016 10:02 PM, Stephen Houston wrote:
> > I think Andrew's proposal solves the problems for everyone without the
> > caveats. That's what I would vote for.
> >
> It still has the same issues of setting e to use a theme different from
> the FDO theme and .edj file (This is probably only very few people).
> Rather then having the second issue the user would simply get no icons
> if they chose an FDO theme and it is missing some of the required icons
> they would get no icons, we could still implement the match thing but in
> the case of matching FDO and Elm theme the user could just not select
> "Use FDO Icons for E" which saves some code and needing to modify every
> theme to contain a matching icon theme, we could implement the opposite
> though so that each E theme can recommend a FDO icon set and if you have
> a box checked E automatically updates the FDO icon set for Qt/GTK when
> you change e themes similar to the wallpaper dialog. Again that doesn't
> give you much more and would annoy some users enough that it probably
> couldn't be default behavior.
>
> > On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:
> >
> >> Hi All,
> >>
> >> I'm going to start again, we just had another discussion on IRC and this
> >> is what we seem to have come to, i'm sorry if I repeat something I only
> >> skim read some of the discussion.
> >>
> >> Firstly all non FDO standard icons used in elm/e will be installed into
> >> the hicolor icon theme this means that if users choose to use any FDO
> >> icon theme which doesn't have all the icons enlightenment / elm will
> >> just use the existing fallback mechanisms.
> >>
> >> The configuration dialog will be simplified too two settings (If I got
> >> this right), firstly you will be able to choose a FDO icon theme,
> >> Secondly you will be able to choose if Enlightenment and Elm apps use
> >> the icon set from the enlightenment/elm theme (.edj) or from the current
> >> FDO theme.
> >>
> >> This implementation is simple and straight forward but has a couple of
> >> caveats, Firstly if you would like e to use a different theme to the FDO
> >> theme and the one provided by your current enlightenment theme bad luck
> >> for now you will need to modify your enlightenment theme (This won't be
> >> as bad once we make a way to provide composite themes). Similarly if you
> >> are using a theme that is recolored and you choose to use a FDO icon
> >> theme rather then the one from the .edj you will fall back to blue icons
> >> rather then icons of the color of your theme, there are 2 work arounds
> >> here, import the FDO theme you are using into the .edj file and get e to
> >> use the theme from that or also recolor the Enlightenment-X theme and
> >> get the FDO theme of your choosing to fallback through the recolored
> >> Enlightenment-X.
> >>
> >> Dave has volunteered to do at least the icon related changes and will
> >> aim to do that for efl 1.19, after that point we can look at rewriting
> >> the theme dialog probably as part of e22.
> >>
> >> Cheers
> >>
> >> --
> >>
> >> Simon Lees (Simotek)http://simotek.net
> >>
> >> Emergency Update Team   keybase.io/simotek
> >> SUSE LinuxAdeliade Australia, UTC+9:30
> >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> >>
> >>
> >>
> --
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> --
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> --
>
> Simon Lees (Simotek)http://simotek.net
>
> Emergency Update Team   keybase.io/simotek
> SUSE LinuxAdeliade Australia

Re: [E-devel] E/ELM fdo icon config issues

[Stephen Houston]

Uh... Why would you want E to use a different theme than everything else?
You are talking about the possibility of using one icon set for E, one for
other toolkits, and one for Elm. That is crazy. And, there would be no
missing icons as we would fall back of course. What code does use FDO icons
for E save? You set the FDO theme. If a match exists, it chooses the
matching edje. In the case that you didn't want E and elm to match, you
would just run elm config and set a different theme. As elm has no business
updating E, but E can and should safely update Elm. In this case your E
would have an FDO theme and elm would have a different theme, basically
whatever you set. So it appeases the 99% by automatically keeping E and Elm
in tandem, but still allows the 1% to have different icons for E and Elm.
The 99% will want uniformity in icons and that it is what we are trying to
make the easiest but with the most optimization. The 1% case you are
talking about is still possible just with a little extra work (hardly
though). That is the way it should be. Also., you mention needing to modify
every theme to contain matching icon theme..  First there is only one full
theme that exists right now really, and it is adding one simple line to the
default.edc of that theme. Secondly, if you don't update the theme and
there is no data for matching icon theme, it will just fallback to using
the selected FDO from E and not an edje icon theme.  This is not a problem
at all for themes.

On Sun, Aug 28, 2016, 8:53 AM Simon Lees  wrote:

>
>
> On 08/28/2016 10:02 PM, Stephen Houston wrote:
> > I think Andrew's proposal solves the problems for everyone without the
> > caveats. That's what I would vote for.
> >
> It still has the same issues of setting e to use a theme different from
> the FDO theme and .edj file (This is probably only very few people).
> Rather then having the second issue the user would simply get no icons
> if they chose an FDO theme and it is missing some of the required icons
> they would get no icons, we could still implement the match thing but in
> the case of matching FDO and Elm theme the user could just not select
> "Use FDO Icons for E" which saves some code and needing to modify every
> theme to contain a matching icon theme, we could implement the opposite
> though so that each E theme can recommend a FDO icon set and if you have
> a box checked E automatically updates the FDO icon set for Qt/GTK when
> you change e themes similar to the wallpaper dialog. Again that doesn't
> give you much more and would annoy some users enough that it probably
> couldn't be default behavior.
>
> > On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:
> >
> >> Hi All,
> >>
> >> I'm going to start again, we just had another discussion on IRC and this
> >> is what we seem to have come to, i'm sorry if I repeat something I only
> >> skim read some of the discussion.
> >>
> >> Firstly all non FDO standard icons used in elm/e will be installed into
> >> the hicolor icon theme this means that if users choose to use any FDO
> >> icon theme which doesn't have all the icons enlightenment / elm will
> >> just use the existing fallback mechanisms.
> >>
> >> The configuration dialog will be simplified too two settings (If I got
> >> this right), firstly you will be able to choose a FDO icon theme,
> >> Secondly you will be able to choose if Enlightenment and Elm apps use
> >> the icon set from the enlightenment/elm theme (.edj) or from the current
> >> FDO theme.
> >>
> >> This implementation is simple and straight forward but has a couple of
> >> caveats, Firstly if you would like e to use a different theme to the FDO
> >> theme and the one provided by your current enlightenment theme bad luck
> >> for now you will need to modify your enlightenment theme (This won't be
> >> as bad once we make a way to provide composite themes). Similarly if you
> >> are using a theme that is recolored and you choose to use a FDO icon
> >> theme rather then the one from the .edj you will fall back to blue icons
> >> rather then icons of the color of your theme, there are 2 work arounds
> >> here, import the FDO theme you are using into the .edj file and get e to
> >> use the theme from that or also recolor the Enlightenment-X theme and
> >> get the FDO theme of your choosing to fallback through the recolored
> >> Enlightenment-X.
> >>
> >> Dave has volunteered to do at least the icon related changes and will
> >> aim to do that for efl 1.19, after that point we can look at rewriting
> >> the theme dialog probably as part of e22.
> >>
> >> Cheers
> >>
> >> --
> >>
> >> Simon Lees (Simotek)http://simotek.net
> >>
> >> Emergency Update Team   keybase.io/simotek
> >> SUSE LinuxAdeliade Australia, UTC+9:30
> >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> >>
> >>
> >>
> --
> >> ___

Re: [E-devel] E/ELM fdo icon config issues

[Davide Andreoli]

2016-08-28 19:18 GMT+02:00 Andrew Williams :

> I don't understand why we want to expose the choice of efl widget set icons
> in E - users can override a default using elm_config if they want to but
> promoting this choice in E seems strange - basically a "do you want your
> other apps to look different to E ones?"
>

Yes, this is what I want right now! because it's the only way I know to have
both (GTK and ELM) to looks beautiful. I didn't find any GTK theme that
looks right in ELM apps nor the bluish icons looks well in light GTK themes.
I do not mind if GTK and ELM looks different, I'm just interested in them to
looks good with their icons.

I can live with the "change the E config dialog and then go to change the
ELM one" to make my choice... but frankly I think you are forcing your view
of  "how do you prefer your icons to look" to me (and probably others).


> I like the description of elm icons as an optimisation because fdo is
> really slow. With this in mind we could implement it purely as an
> optimisation so when the fdo choice can be mapped to edj then we do so
> automatically.
>

I agree with this one.


> You would still need to fall back to hicolor but it's less likely to happen
> if I understand correctly?
>

For what I have understand this will happen when you select an external
FDO theme that do not provide the icons that I'm going to add in the next
weeks/months in elm. Basically all the icons needed by E that do not have
an exact match in the FDO naming spec.


>
> For me I think we should be fdo compliant and make it transparent for
> users. Otherwise we should probably just ignore the standards and hope folk
> make icon sets specifically for us...
>

We are already full FDO compliant, in the mean that our elm theme provide
ALL the icons required by the spec (maybe 5 are missing). The problem
is that the FDO spec do not list lots of icons needed by general
applications,
nor all the one needed by E.

So we decided that I will extend the elm theme (and the Enlightenment-X) to
provide more icons, starting from all the icons needed by E. But keep
in mind that this new icons will not be FDO compliant and hardly you will
find them in other (non efl) themes.
As a consequence if you will choose to use a non-efl icon theme, then your
window manager will have half icons from your theme and half from the
bluish one. I cannot see any solution for this problem.


>
> Andrew
> On Sun, 28 Aug 2016 at 14:52, Simon Lees  wrote:
>
> >
> >
> > On 08/28/2016 10:02 PM, Stephen Houston wrote:
> > > I think Andrew's proposal solves the problems for everyone without the
> > > caveats. That's what I would vote for.
> > >
> > It still has the same issues of setting e to use a theme different from
> > the FDO theme and .edj file (This is probably only very few people).
> > Rather then having the second issue the user would simply get no icons
> > if they chose an FDO theme and it is missing some of the required icons
> > they would get no icons, we could still implement the match thing but in
> > the case of matching FDO and Elm theme the user could just not select
> > "Use FDO Icons for E" which saves some code and needing to modify every
> > theme to contain a matching icon theme, we could implement the opposite
> > though so that each E theme can recommend a FDO icon set and if you have
> > a box checked E automatically updates the FDO icon set for Qt/GTK when
> > you change e themes similar to the wallpaper dialog. Again that doesn't
> > give you much more and would annoy some users enough that it probably
> > couldn't be default behavior.
> >
> > > On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:
> > >
> > >> Hi All,
> > >>
> > >> I'm going to start again, we just had another discussion on IRC and
> this
> > >> is what we seem to have come to, i'm sorry if I repeat something I
> only
> > >> skim read some of the discussion.
> > >>
> > >> Firstly all non FDO standard icons used in elm/e will be installed
> into
> > >> the hicolor icon theme this means that if users choose to use any FDO
> > >> icon theme which doesn't have all the icons enlightenment / elm will
> > >> just use the existing fallback mechanisms.
> > >>
> > >> The configuration dialog will be simplified too two settings (If I got
> > >> this right), firstly you will be able to choose a FDO icon theme,
> > >> Secondly you will be able to choose if Enlightenment and Elm apps use
> > >> the icon set from the enlightenment/elm theme (.edj) or from the
> current
> > >> FDO theme.
> > >>
> > >> This implementation is simple and straight forward but has a couple of
> > >> caveats, Firstly if you would like e to use a different theme to the
> FDO
> > >> theme and the one provided by your current enlightenment theme bad
> luck
> > >> for now you will need to modify your enlightenment theme (This won't
> be
> > >> as bad once we make a way to provide composite themes). Similarly if
> you
> > >> are using a theme that is recolored and you choose to use a 

[E-devel] Emotion Media Center 1.2.0 beta2

[Davide Andreoli]

Hi all,

the second beta is out!

As always you can found the downloads at:
https://github.com/DaveMDS/ep 
https://github.com/DaveMDS/epymc/releasesymc/releases


Changes since beta1:

  * Greatly improved initial music scan speed (~10 times faster)
  * Thumbnailer now check mod time on files, so you always have updated
thimbs
  * Improved all the sliders, and add a new volume slider in the music
player
  * Proper style for genlist/gengrid group items
  * New Finnish translation
  * Updated Italian translation

...and some other small fixes



CALL FOR TRANSLATORS:
Guys this is the right time to submit your updated translations !!!

Happy testing from your couch :)

davemds
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac for EFL build bot.

[Jean Guyomarc'h]

> Oh, and running VMs gets around Apples lack of legal support for
> multiple users at the same time.  A VM per user, and don't count
> services like build bots as a user, that should work legally.

Urg. That's right, there is the 2B section of the SLA...
Blurry legal language... Since the non-virtualized system
is exclusive to the owner of the license, I guess we are
obliged to have a VM.

I also hope your mac mini has a decent hard drive also (in terms
of speed of access). Because a full build of EFL takes about 20
minutes on my macbook pro :'( so painful to develop with...

Jean

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E/ELM fdo icon config issues

[Simon Lees]

On 08/29/2016 02:48 AM, Andrew Williams wrote:
> I don't understand why we want to expose the choice of efl widget set icons
> in E - users can override a default using elm_config if they want to but
> promoting this choice in E seems strange - basically a "do you want your
> other apps to look different to E ones?"

Ok here to simplify things I am treating enlightenment as just another
elm app, which is what it is working to becoming, it is quite common for
many users myself included to pick a FDO icon set and want that to apply
to everything including gtk/Qt/elm and e, having the case where this is
just set in the elm config will essentially hide it from users wanting
to do this so in the same way e's theme dialog really changes an elm
setting, this dialog would also change a elm setting so users can find
it. (Maybe as part of the config rewrite we can find a better way to
manage elm settings like this).

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E/ELM fdo icon config issues

[Simon Lees]

On 08/29/2016 03:06 AM, Stephen Houston wrote:
> Uh... Why would you want E to use a different theme than everything else?
> You are talking about the possibility of using one icon set for E, one for
> other toolkits, and one for Elm. That is crazy. 

Yes that is why I mentioned it as a caveat that we are not supporting :-)


> missing icons as we would fall back of course. What code does use FDO icons
> for E save? You set the FDO theme. If a match exists, it chooses the
> matching edje. In the case that you didn't want E and elm to match, you
> would just run elm config and set a different theme. As elm has no business
> updating E, but E can and should safely update Elm. In this case your E
> would have an FDO theme and elm would have a different theme, basically
> whatever you set. So it appeases the 99% by automatically keeping E and Elm
> in tandem, but still allows the 1% to have different icons for E and Elm.

See the other reply but life is much simpler here if we treat e as just
another elm app, into the future with some things we are looking at for
theme fallback and theme mixing and matching this will apply to icon
sets as well and will make it easier for users to further customise
there icon theme for e should they want it different to the FDO one they
have selected.

> The 99% will want uniformity in icons and that it is what we are trying to
> make the easiest but with the most optimization. The 1% case you are
> talking about is still possible just with a little extra work (hardly
> though). That is the way it should be. Also., you mention needing to modify
> every theme to contain matching icon theme..  First there is only one full
> theme that exists right now really, and it is adding one simple line to the
> default.edc of that theme. Secondly, if you don't update the theme and
> there is no data for matching icon theme, it will just fallback to using
> the selected FDO from E and not an edje icon theme.  This is not a problem
> at all for themes.
> 
There are at least 3-4 decent themes going around and many others that a
few people use :-). The point I was making here was that with the
options we are providing users in the case that they can do caching "FDO
Theme == Elm Theme" the user could just select use the "ELM Theme" then
the icons will be continue to be loaded from the .edj and we don't need
the mapping in the theme, all the mapping in the theme does is make it
faster when a User selects that elm/e should use icons from the FDO
theme and "FDO Theme == Elm Theme" if it doesn't match we can't really
use the caching so this seems to be adding a feature thats hardly needed
(If we want to add it anyway we could but its extra complexity with
basically no gain).

> On Sun, Aug 28, 2016, 8:53 AM Simon Lees  wrote:
> 
>>
>>
>> On 08/28/2016 10:02 PM, Stephen Houston wrote:
>>> I think Andrew's proposal solves the problems for everyone without the
>>> caveats. That's what I would vote for.
>>>
>> It still has the same issues of setting e to use a theme different from
>> the FDO theme and .edj file (This is probably only very few people).
>> Rather then having the second issue the user would simply get no icons
>> if they chose an FDO theme and it is missing some of the required icons
>> they would get no icons, we could still implement the match thing but in
>> the case of matching FDO and Elm theme the user could just not select
>> "Use FDO Icons for E" which saves some code and needing to modify every
>> theme to contain a matching icon theme, we could implement the opposite
>> though so that each E theme can recommend a FDO icon set and if you have
>> a box checked E automatically updates the FDO icon set for Qt/GTK when
>> you change e themes similar to the wallpaper dialog. Again that doesn't
>> give you much more and would annoy some users enough that it probably
>> couldn't be default behavior.
>>
>>> On Sun, Aug 28, 2016, 6:36 AM Simon Lees  wrote:
>>>
 Hi All,

 I'm going to start again, we just had another discussion on IRC and this
 is what we seem to have come to, i'm sorry if I repeat something I only
 skim read some of the discussion.

 Firstly all non FDO standard icons used in elm/e will be installed into
 the hicolor icon theme this means that if users choose to use any FDO
 icon theme which doesn't have all the icons enlightenment / elm will
 just use the existing fallback mechanisms.

 The configuration dialog will be simplified too two settings (If I got
 this right), firstly you will be able to choose a FDO icon theme,
 Secondly you will be able to choose if Enlightenment and Elm apps use
 the icon set from the enlightenment/elm theme (.edj) or from the current
 FDO theme.

 This implementation is simple and straight forward but has a couple of
 caveats, Firstly if you would like e to use a different theme to the FDO
 theme and the one provided by your current enlightenment theme bad luck

Re: [E-devel] E/ELM fdo icon config issues

[The Rasterman]

On Sat, 27 Aug 2016 23:28:53 + Andrew Williams  said:

> After chatting on IRC I think there is another approach.
> The underlying principle is that we have 2 different viewpoints - that
> which elm is FDo compliant - and that which it should be seperate.

yup. i'm on the "elm has its own theme mechanics and thus this also applies to
icons. it applies to wallpapers in e, and everything else" but there are peolpe
who want elm to mimic their gtk/qt etc. apps and use those icons. so thus the
option to turn fdo theme use on or off at the elm level.

> If the elm icon theme were able to hint at which FDo theme it is
> complatible with (if any) as mentioned earlier then we could do this:

i dislike these things. it breaks the principle of themes being self-contained
data bundles that just work without any data outside of them.

> *) remove E's "icon theme for enlightenment" checkbox - we should always
> assume you are configuring E

yes. i agree.

> *) update the "icon theme for applications" checkbox to also apply to efl
> apps

actually i would go for something simpler... just a single checkbox "apply to
e/efl apps too". icon theme is selected and apply, ie to everything and all
apps. including e. e/efl can go off on their own and use icons from their
themes (as long as they exist- fall back to configured fdo theme if not found).
if you dont like the theme + icons that match together, then that checkbox will
turn on the "look in fdo first".

isnt this simplest? is there really a need to configure e separately from
elm/rest of efl here with icons?

> *) when the user selects an FDo icon theme we iterate through all the elm
> themes to see if any declare a match - and if so and the "icon theme for
> applications" is set then we tell elm to use it's theme instead of the FDo
> one.

why do this? so complex? select icon theme... have a checkbox "apply to e/efl
too". perhaps clicking/selecting any icon theme will set that checkbox to true
assuming the user wants to see the effects immediately everywhere, e/fl
included. they can then uncheck that if they don't like it. :)

isn't this simplest? less code, fewer controls in the ui.

> In this manner anyone wanting GTK or ELM specific icons could still run
> their own configuration tool (elm_config will not know how to do the lookup
> to affect other (i.e. GTK) apps when chosing a theme that happens to be
> marked as matching an FDO theme.
> 
> Of course that relies on the appropriate theme being installed as well,
> which can be checked for.
> 
> I think this accomplishes all the requirements with the addition of not
> being any more complex for the user. I'm not really so sure we should have
> seperate checkboxes for ELM and "GTK" as the non-elm applies to all other
> apps, being an FDo spec that we are trying to comply with. Going with the
> existing "icon theme for applications" to apply to all toolkits seems to
> make sense.
> 
> Would this work?
> Andrew
> 
> On Sat, 27 Aug 2016 at 18:11 Davide Andreoli  wrote:
> 
> > 2016-08-27 17:52 GMT+02:00 Davide Andreoli :
> >
> > > 2016-08-27 17:23 GMT+02:00 Andrew Williams :
> > >
> > >> I think the complexity is that Enlightenment looks at this all the other
> > >> way around.
> > >> I.e. Choose your theme - and do you want it to apply to apps as well?
> > >> I'm tempted to go in and remove all the complexity and have it be just
> > >> that
> > >> (I.e. Ignore elm vs gtk as seperate values) then it would make more
> > sense
> > >> for elm to try and say what gtk theme matches. But at the moment (in E)
> > >> the
> > >> user could have specified that this is not the chosen behaviour but elm
> > >> won't know that.
> > >>
> > >> My aim in all of this is to provide a consistent experience but maybe
> > >> others prefer the config options approach?
> > >>
> > >
> > > I don't want/need a consistent experience (between ELM and GTK). I just
> > > want
> > > gtk to looks beautiful with it's Mint-X icons and elm to look beautiful
> > > (and be fast)
> > > with the icons embedded in theme. I don't neither use a gtk theme that
> > > match the
> > > elm one, on my system gtk apps are light and elm are dark, I like this
> > > separation.
> > >
> > > Please make a system that permit this type of configuration. Don't forget
> > > the
> > > fundamental E principle: let the user choose !
> > >
> >
> > After some more thinking about the E config dialog I ended up that
> > list+checks
> > are the wrong choice, if we want to give the user the "power to choose" we
> > need
> > 3 independent lists, so that user can choose the icons for ELM, the icons
> > for GTK
> > and the icons for E itself. This could be made with 2 new tabs, so that we
> > end up
> > with 3 tabs for icons: "ELM icons", "GTK icons", "E icons".
> > ...or maybe on a single page with just 3 combobox.
> >
> >
> > >
> > >
> > >>
> > >> Andrew
> > >> On Sat, 27 Aug 2016 at 15:00, Stephen Houston 
> > >> wrote:
> > >>
> > >> > Would it not be simpler for Edje theme to provide 

Re: [E-devel] [EGIT] [core/efl] master 02/02: efreet - save about 240-300k or so of memory used by efreet mime

[The Rasterman]

On Sat, 27 Aug 2016 14:15:31 +0200 marcel-hollerb...@t-online.de said:

> On Sat, Aug 27, 2016 at 09:59:51AM +0900, Carsten Haitzler wrote:
> > On Fri, 26 Aug 2016 17:34:25 +0200 marcel-hollerb...@t-online.de said:
> > 
> > > Hello,
> > > 
> > > On Mon, Aug 22, 2016 at 08:04:09PM -0700, Carsten Haitzler wrote:
> > > > raster pushed a commit to branch master.
> > > > 
> > > > http://git.enlightenment.org/core/efl.git/commit/?id=561f8eaa8faebe32b9a03cf9674c147cf0d6d9ab
> > > > 
> > > > commit 561f8eaa8faebe32b9a03cf9674c147cf0d6d9ab
> > > > Author: Carsten Haitzler (Rasterman) 
> > > > Date:   Tue Aug 23 11:59:37 2016 +0900
> > > > 
> > > > efreet - save about 240-300k or so of memory used by efreet mime
> > > > 
> > > > so efreet mime was loading a bunch of mime type info files, parsing
> > > > them on startup and allocating memory to store all this mime info -
> > > > globs, mimetype strings and more. all a big waste of memory as its
> > > > allocated on the heap per process where its the SAME data files
> > > > loaded every time.
> > > > 
> > > > so make an efreet mime cache file and a tool to create it from mime
> > > > files. mmap this file with all the hashes/strings in it so all that
> > > > data is mmaped once in memory and shared between all processes and
> > > > it is only paged in on demand - as actually read/needed so if your
> > > > process doesnt need to know about mime stuff.. it wont touch it
> > > > anyway. 
> > > > this saves about 240-300k or so of memory in my tests. this has not
> > > > covered the mime MAGIC files which still consume memory and are on
> > > > the heap. this is more complex so it will take more time to come up
> > > > with a nice file format for the data that is nicely mmaped etc.
> > > > 
> > > > @optimize
> > > > ---
> > > 
> > > [snip]
> > > 
> > > > +
> > > >  EAPI int
> > > >  efreet_mime_init(void)
> > > >  {
> > > > @@ -194,14 +386,15 @@ efreet_mime_init(void)
> > > >   }
> > > >  
> > > > efreet_mime_endianess = efreet_mime_endian_check();
> > > > -
> > > > -   monitors = eina_hash_string_superfast_new(EINA_FREE_CB
> > > > (ecore_file_monitor_del)); -
> > > > efreet_mime_type_cache_clear();
> > > >  
> > > > +   _efreet_mimedb_update();
> > > > +
> > > > if (!efreet_mime_init_files())
> > > >   goto unregister_log_domain;
> > > >  
> > > > +   _efreet_mime_update_func = _efreet_mimedb_update;
> > > > +
> > > > return _efreet_mime_init_count;
> > > >  
> > > >  unregister_log_domain:
> > > > @@ -228,6 +421,9 @@ efreet_mime_shutdown(void)
> > > > if (--_efreet_mime_init_count != 0)
> > > >   return _efreet_mime_init_count;
> > > >  
> > > > +   _efreet_mimedb_shutdown();
> > > > +   _efreet_mime_update_func = NULL;
> > > > +
> > > > efreet_mime_icons_debug();
> > > >  
> > > > IF_RELEASE(_mime_inode_symlink);
> > > > @@ -241,10 +437,7 @@ efreet_mime_shutdown(void)
> > > > IF_RELEASE(_mime_application_octet_stream);
> > > > IF_RELEASE(_mime_text_plain);
> > > >  
> > > > -   IF_FREE_LIST(globs, efreet_mime_glob_free);
> > > > IF_FREE_LIST(magics, efreet_mime_magic_free);
> > > > -   IF_FREE_HASH(monitors);
> > > > -   IF_FREE_HASH(wild);
> > > > IF_FREE_HASH(mime_icons);
> > > > eina_log_domain_unregister(_efreet_mime_log_dom);
> > > > _efreet_mime_log_dom = -1;
> > > > @@ -387,11 +580,10 @@ efreet_mime_magic_type_get(const char *file)
> > > >  EAPI const char *
> > > >  efreet_mime_globs_type_get(const char *file)
> > > >  {
> > > > -   Eina_List *l;
> > > > -   Efreet_Mime_Glob *g;
> > > > char *sl, *p;
> > > > -   const char *s;
> > > > -   char *ext, *mime;
> > > > +   const char *s, *mime;
> > > > +   char *ext;
> > > > +   unsigned int i, n;
> > > >  
> > > > EINA_SAFETY_ON_NULL_RETURN_VAL(file, NULL);
> > > >  
> > > > @@ -406,25 +598,27 @@ efreet_mime_globs_type_get(const char *file)
> > > >  while (p)
> > > >{
> > > >   p++;
> > > > - if (p && (mime = eina_hash_find(wild, p))) return mime;
> > > > + if (p && (mime = _efreet_mimedb_extn_find(p))) return
> > > > mime; p = strchr(p, '.');
> > > >}
> > > >   }
> > > >  
> > > > -   /* Fallback to the other globs if not found */
> > > > -   EINA_LIST_FOREACH(globs, l, g)
> > > > +   // Fallback to the other globs if not found
> > > > +   n = _efreet_mimedb_glob_count();
> > > > +   for (i = 0; i < n; i++)
> > > >   {
> > > > -if (efreet_mime_glob_match(file, g->glob))
> > > > -  return g->mime;
> > > > +s = _efreet_mimedb_glob_get(i);
> > > > +if (efreet_mime_glob_match(file, s))
> > > > +  return _efreet_mimedb_glob_mime_get(i);
> > > 
> > > The upper line is introducing a problem.
> > > 
> > > Before the return was a stringshare, now it is not anymore.
> > > I am not so sure if it is a good idea to fix it with 
> > 
> > the api docs do not say it is a stringshare str

Re: [E-devel] Callback arrays and callback invocation optimisations

[The Rasterman]

On Fri, 26 Aug 2016 22:14:11 -0700 Cedric BAIL  said:

> On Fri, Aug 26, 2016 at 5:44 PM, Carsten Haitzler 
> wrote:
> > On Fri, 26 Aug 2016 12:15:57 -0700 Cedric BAIL  said:
> >> On Fri, Aug 26, 2016 at 2:46 AM, Tom Hacohen  wrote:
> >> > On 24/08/16 20:03, Cedric BAIL wrote:
> >> >> On Wed, Aug 24, 2016 at 2:24 AM, Tom Hacohen 
> >> >> wrote:
> >> >>> On 23/08/16 18:51, Cedric BAIL wrote:
> >>  On Tue, Aug 23, 2016 at 3:31 AM, Tom Hacohen 
> >>  wrote:
> 
> 
> 
> >> > We can also store a pointer to the array in a hash table with the key
> >> > being some sort of a hash of the array in order to do some
> >> > deduplication afterwards (point to the same arrays, but obviously
> >> > different private data, so that would still be duplicated) if we
> >> > feel it's needed. It probably won't save as much though and will
> >> > have some running costs.
> >> 
> >>  For anything < 16 entries, I bet that a hash table will be slower than
> >>  walking an array. Don't forget you need to compute the hash key, jump
> >>  in an array, walk down a rbtree and finally iterate over a list. Hash
> >>  are good for very large number of object, not for small number.
> >> >>>
> >> >>> That was an optimisation that I just threw out there to the world, but
> >> >>> I believe you misunderstood me. I didn't mean we create a hash table
> >> >>> for calling events, it was for saving memory and deduplicating event
> >> >>> callbacks (essentially callback arrays automatically). This is only
> >> >>> done on callback add/del.
> >> >>
> >> >> Indeed I missunderstood your intent. Still this will increase the cost
> >> >> of insertion for no benefit in my opinion. See below.
> >> >
> >> > Again, this is a side comment, not that important.
> >>
> >> I have discovered that this is an important use case actually. We do
> >> insert and remove callback quite a lot now that animator is an event
> >> on an object. We do already spend nearly as much time doing
> >> efl_event_callback_priority_add (0.90% for 110 000 calls),
> >> efl_event_callback_array_priority_add (0.49% for 110 000 calls),
> >> efl_event_callback_array_del (0.27% for 40 000 calls) and
> >> efl_event_callback_del (0.93% for 110 000 calls). The cost of adding
> >> and destroying events is not negligeable. It is, cumulatively,
> >> actually higher than our current cost for calling events.
> >
> > something to optimize. :) having priority doesn't help us a lot here as we
> > have to walk a lot of list nodes and pull in a lot of l1 cache pages to do
> > the insert given priority. if we sort also by event ptr it wont really
> > matter.
> >
> > if we move to an array of event ptrs for events then we likely will pull in
> > all existing event id's in 1 l1 cache line fetch and this will very likely
> > make insert and remove a lot faster.
> 
> Uh ? Removing from an array is costly as you have to deal with hole !
> That's why we rely on list so much. How do you think we can deal

instead of just babbling on... i did some actual tests. arrays come out ahead of
lists for my tests of 8 event callbacks if you dirty all of l1/l2/l3 cache
then arrays win for 8 events which is about the balllpark of our average
callback count. it's an isolated test where i duplicated the event cb add/del
code from eo and write some array equivalent code and timed it. my test uses
10k objects as the testbed and with 5 different event id's being used. when i
pollute all cache arrays are about 5% faster than the linked list next ptr
setup just for adding and deleting callbacks. i didn't check "finding events
to call them".

so the theory holds for totally uncached data. the more is in l1 cache the
faster the linked list method gets vs arrays.

> faster with array ? Doing an sorted insert on priority add, should
> actually help to make destruction faster... at likely the cost of

actually i just looked at the eo code... its a lot less efficient that it
should be. it will make a cb for deletion then later walk all event cb's and
then free the ones with delete_me. it should only do this while walking events
on that object, otherwise it should do it immediately.

if events were ordered by event id it would raise insertsion cost as right now
we only insert base on priority not event id and in most cases that means a
priority of 0 and most if not all events are 0 so it means just a prepend on
the head of the list.

> increasing insertion... Not so sure there is much to be done there. I
> may be wrong, but maybe an easy way to speedup allocation/destruction
> of single callback is to have an allocation cache using Eina_Trash,
> will try that next week. I don't have the benchmark result at hand
> anymore.

right now we calloc/free callback structs. maybe use mempool?

> > to do this we have to redesign our internal structures. i think with
> > callback arrays we should also have the callback array content duplicated
> > internally in more optimal memory layout thus it no

Re: [E-devel] E/ELM fdo icon config issues

[Simon Lees]

On 08/29/2016 02:37 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 27 Aug 2016 23:28:53 + Andrew Williams  
> said:
> 
>> After chatting on IRC I think there is another approach.
>> The underlying principle is that we have 2 different viewpoints - that
>> which elm is FDo compliant - and that which it should be seperate.
> 
> yup. i'm on the "elm has its own theme mechanics and thus this also applies to
> icons. it applies to wallpapers in e, and everything else" but there are 
> peolpe
> who want elm to mimic their gtk/qt etc. apps and use those icons. so thus the
> option to turn fdo theme use on or off at the elm level.
> 
>> If the elm icon theme were able to hint at which FDo theme it is
>> complatible with (if any) as mentioned earlier then we could do this:
> 
> i dislike these things. it breaks the principle of themes being self-contained
> data bundles that just work without any data outside of them.
> 
>> *) remove E's "icon theme for enlightenment" checkbox - we should always
>> assume you are configuring E
> 
> yes. i agree.

Here I slightly disagree, if E/Elm are using the option to take icons
from the elm theme rather then the FDO them should we disable the list?
or should it just set the FDO theme for gtk/Qt (Doing this saves having
to install a different application to set it) See my other mail.

> 
>> *) update the "icon theme for applications" checkbox to also apply to efl
>> apps
> 
> actually i would go for something simpler... just a single checkbox "apply to
> e/efl apps too". icon theme is selected and apply, ie to everything and all
> apps. including e. e/efl can go off on their own and use icons from their
> themes (as long as they exist- fall back to configured fdo theme if not 
> found).
> if you dont like the theme + icons that match together, then that checkbox 
> will
> turn on the "look in fdo first".
> 
> isnt this simplest? is there really a need to configure e separately from
> elm/rest of efl here with icons?

I don't think we do either, e is a elm app and should just follow its
settings you can't pick a different icon theme for gnome and gtk or kde
and Qt (you can't even pick a different icon theme for gtk and Qt I
don't believe).

> 
>> *) when the user selects an FDo icon theme we iterate through all the elm
>> themes to see if any declare a match - and if so and the "icon theme for
>> applications" is set then we tell elm to use it's theme instead of the FDo
>> one.
> 
> why do this? so complex? select icon theme... have a checkbox "apply to e/efl
> too". perhaps clicking/selecting any icon theme will set that checkbox to true
> assuming the user wants to see the effects immediately everywhere, e/fl
> included. they can then uncheck that if they don't like it. :)
> 
> isn't this simplest? less code, fewer controls in the ui.

Again see my proposal.

> 
>> In this manner anyone wanting GTK or ELM specific icons could still run
>> their own configuration tool (elm_config will not know how to do the lookup
>> to affect other (i.e. GTK) apps when chosing a theme that happens to be
>> marked as matching an FDO theme.
>>
>> Of course that relies on the appropriate theme being installed as well,
>> which can be checked for.
>>
>> I think this accomplishes all the requirements with the addition of not
>> being any more complex for the user. I'm not really so sure we should have
>> seperate checkboxes for ELM and "GTK" as the non-elm applies to all other
>> apps, being an FDo spec that we are trying to comply with. Going with the
>> existing "icon theme for applications" to apply to all toolkits seems to
>> make sense.
>>
>> Would this work?
>> Andrew
>>
>> On Sat, 27 Aug 2016 at 18:11 Davide Andreoli  wrote:
>>
>>> 2016-08-27 17:52 GMT+02:00 Davide Andreoli :
>>>
 2016-08-27 17:23 GMT+02:00 Andrew Williams :

> I think the complexity is that Enlightenment looks at this all the other
> way around.
> I.e. Choose your theme - and do you want it to apply to apps as well?
> I'm tempted to go in and remove all the complexity and have it be just
> that
> (I.e. Ignore elm vs gtk as seperate values) then it would make more
>>> sense
> for elm to try and say what gtk theme matches. But at the moment (in E)
> the
> user could have specified that this is not the chosen behaviour but elm
> won't know that.
>
> My aim in all of this is to provide a consistent experience but maybe
> others prefer the config options approach?
>

 I don't want/need a consistent experience (between ELM and GTK). I just
 want
 gtk to looks beautiful with it's Mint-X icons and elm to look beautiful
 (and be fast)
 with the icons embedded in theme. I don't neither use a gtk theme that
 match the
 elm one, on my system gtk apps are light and elm are dark, I like this
 separation.

 Please make a system that permit this type of configuration. Don't forget
 the
 fundamental E principle: le

Re: [E-devel] E/ELM fdo icon config issues

[The Rasterman]

On Mon, 29 Aug 2016 15:01:53 +0930 Simon Lees  said:

> 
> 
> On 08/29/2016 02:37 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sat, 27 Aug 2016 23:28:53 + Andrew Williams 
> > said:
> > 
> >> After chatting on IRC I think there is another approach.
> >> The underlying principle is that we have 2 different viewpoints - that
> >> which elm is FDo compliant - and that which it should be seperate.
> > 
> > yup. i'm on the "elm has its own theme mechanics and thus this also applies
> > to icons. it applies to wallpapers in e, and everything else" but there are
> > peolpe who want elm to mimic their gtk/qt etc. apps and use those icons. so
> > thus the option to turn fdo theme use on or off at the elm level.
> > 
> >> If the elm icon theme were able to hint at which FDo theme it is
> >> complatible with (if any) as mentioned earlier then we could do this:
> > 
> > i dislike these things. it breaks the principle of themes being
> > self-contained data bundles that just work without any data outside of them.
> > 
> >> *) remove E's "icon theme for enlightenment" checkbox - we should always
> >> assume you are configuring E
> > 
> > yes. i agree.
> 
> Here I slightly disagree, if E/Elm are using the option to take icons
> from the elm theme rather then the FDO them should we disable the list?
> or should it just set the FDO theme for gtk/Qt (Doing this saves having
> to install a different application to set it) See my other mail.

the icon selection applies to everything, UNLESS the checkbox says "dont applye
to e/efl". then it applies to everything else except e/efl. simple enough.
solves the core issue at hand.

> > 
> >> *) update the "icon theme for applications" checkbox to also apply to efl
> >> apps
> > 
> > actually i would go for something simpler... just a single checkbox "apply
> > to e/efl apps too". icon theme is selected and apply, ie to everything and
> > all apps. including e. e/efl can go off on their own and use icons from
> > their themes (as long as they exist- fall back to configured fdo theme if
> > not found). if you dont like the theme + icons that match together, then
> > that checkbox will turn on the "look in fdo first".
> > 
> > isnt this simplest? is there really a need to configure e separately from
> > elm/rest of efl here with icons?
> 
> I don't think we do either, e is a elm app and should just follow its
> settings you can't pick a different icon theme for gnome and gtk or kde
> and Qt (you can't even pick a different icon theme for gtk and Qt I
> don't believe).
> 
> > 
> >> *) when the user selects an FDo icon theme we iterate through all the elm
> >> themes to see if any declare a match - and if so and the "icon theme for
> >> applications" is set then we tell elm to use it's theme instead of the FDo
> >> one.
> > 
> > why do this? so complex? select icon theme... have a checkbox "apply to
> > e/efl too". perhaps clicking/selecting any icon theme will set that
> > checkbox to true assuming the user wants to see the effects immediately
> > everywhere, e/fl included. they can then uncheck that if they don't like
> > it. :)
> > 
> > isn't this simplest? less code, fewer controls in the ui.
> 
> Again see my proposal.
> 
> > 
> >> In this manner anyone wanting GTK or ELM specific icons could still run
> >> their own configuration tool (elm_config will not know how to do the lookup
> >> to affect other (i.e. GTK) apps when chosing a theme that happens to be
> >> marked as matching an FDO theme.
> >>
> >> Of course that relies on the appropriate theme being installed as well,
> >> which can be checked for.
> >>
> >> I think this accomplishes all the requirements with the addition of not
> >> being any more complex for the user. I'm not really so sure we should have
> >> seperate checkboxes for ELM and "GTK" as the non-elm applies to all other
> >> apps, being an FDo spec that we are trying to comply with. Going with the
> >> existing "icon theme for applications" to apply to all toolkits seems to
> >> make sense.
> >>
> >> Would this work?
> >> Andrew
> >>
> >> On Sat, 27 Aug 2016 at 18:11 Davide Andreoli 
> >> wrote:
> >>
> >>> 2016-08-27 17:52 GMT+02:00 Davide Andreoli :
> >>>
>  2016-08-27 17:23 GMT+02:00 Andrew Williams :
> 
> > I think the complexity is that Enlightenment looks at this all the other
> > way around.
> > I.e. Choose your theme - and do you want it to apply to apps as well?
> > I'm tempted to go in and remove all the complexity and have it be just
> > that
> > (I.e. Ignore elm vs gtk as seperate values) then it would make more
> >>> sense
> > for elm to try and say what gtk theme matches. But at the moment (in E)
> > the
> > user could have specified that this is not the chosen behaviour but elm
> > won't know that.
> >
> > My aim in all of this is to provide a consistent experience but maybe
> > others prefer the config options approach?
> >
> 
>  I don't want/need a consistent expe

Re: [E-devel] Apache OpenOffice 4.1.2 locks in Enlightenment 0.21.99.21605

[The Rasterman]

On Sat, 27 Aug 2016 03:42:52 -0700 Jose R R  said:

> Niltze [Hello], all!
> 
> I've noticed that Enlightenment 0.17.x.y and 0.21.x.y GUI environment
> sometimes becomes locked upon mousing over icons in Apache OpenOffice 4.1.2.
> 
> Notwithstanding, when I built Enlightenment 0.19.x.y and 0.20.xy, the
> locking issue disappeared and I thought it was resolved; but then issue
> reappeared once more in Enlightenment 0.21.x.y. I have to CTRL + ALT and
> press F1, F2, etc. to get another shell, login and restart XDM.
> 
> Any feedback would be greatly appreciated.

is e stuck - has it crashed? do you get a crashdump?

https://www.enlightenment.org/docs-efl-debug

you can also find if it isnt crashing by forcing a segv and seeing where the bt
says it was stuck:

killall -SEGV enlightenment

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: efreet - save about 240-300k or so of memory used by efreet mime

[marcel-hollerbach]

On Sun, Aug 28, 2016 at 02:25:25AM +0900, Carsten Haitzler wrote:
> On Sat, 27 Aug 2016 14:15:31 +0200 marcel-hollerb...@t-online.de said:
> 
> > On Sat, Aug 27, 2016 at 09:59:51AM +0900, Carsten Haitzler wrote:
> > > On Fri, 26 Aug 2016 17:34:25 +0200 marcel-hollerb...@t-online.de said:
> > > 
> > > > Hello,
> > > > 
> > > > On Mon, Aug 22, 2016 at 08:04:09PM -0700, Carsten Haitzler wrote:
> > > > > raster pushed a commit to branch master.
> > > > > 
> > > > > http://git.enlightenment.org/core/efl.git/commit/?id=561f8eaa8faebe32b9a03cf9674c147cf0d6d9ab
> > > > > 
> > > > > commit 561f8eaa8faebe32b9a03cf9674c147cf0d6d9ab
> > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > Date:   Tue Aug 23 11:59:37 2016 +0900
> > > > > 
> > > > > efreet - save about 240-300k or so of memory used by efreet mime
> > > > > 
> > > > > so efreet mime was loading a bunch of mime type info files, 
> > > > > parsing
> > > > > them on startup and allocating memory to store all this mime info 
> > > > > -
> > > > > globs, mimetype strings and more. all a big waste of memory as its
> > > > > allocated on the heap per process where its the SAME data files
> > > > > loaded every time.
> > > > > 
> > > > > so make an efreet mime cache file and a tool to create it from 
> > > > > mime
> > > > > files. mmap this file with all the hashes/strings in it so all 
> > > > > that
> > > > > data is mmaped once in memory and shared between all processes and
> > > > > it is only paged in on demand - as actually read/needed so if your
> > > > > process doesnt need to know about mime stuff.. it wont touch it
> > > > > anyway. 
> > > > > this saves about 240-300k or so of memory in my tests. this has 
> > > > > not
> > > > > covered the mime MAGIC files which still consume memory and are on
> > > > > the heap. this is more complex so it will take more time to come up
> > > > > with a nice file format for the data that is nicely mmaped etc.
> > > > > 
> > > > > @optimize
> > > > > ---
> > > > 
> > > > [snip]
> > > > 
> > > > > +
> > > > >  EAPI int
> > > > >  efreet_mime_init(void)
> > > > >  {
> > > > > @@ -194,14 +386,15 @@ efreet_mime_init(void)
> > > > >   }
> > > > >  
> > > > > efreet_mime_endianess = efreet_mime_endian_check();
> > > > > -
> > > > > -   monitors = eina_hash_string_superfast_new(EINA_FREE_CB
> > > > > (ecore_file_monitor_del)); -
> > > > > efreet_mime_type_cache_clear();
> > > > >  
> > > > > +   _efreet_mimedb_update();
> > > > > +
> > > > > if (!efreet_mime_init_files())
> > > > >   goto unregister_log_domain;
> > > > >  
> > > > > +   _efreet_mime_update_func = _efreet_mimedb_update;
> > > > > +
> > > > > return _efreet_mime_init_count;
> > > > >  
> > > > >  unregister_log_domain:
> > > > > @@ -228,6 +421,9 @@ efreet_mime_shutdown(void)
> > > > > if (--_efreet_mime_init_count != 0)
> > > > >   return _efreet_mime_init_count;
> > > > >  
> > > > > +   _efreet_mimedb_shutdown();
> > > > > +   _efreet_mime_update_func = NULL;
> > > > > +
> > > > > efreet_mime_icons_debug();
> > > > >  
> > > > > IF_RELEASE(_mime_inode_symlink);
> > > > > @@ -241,10 +437,7 @@ efreet_mime_shutdown(void)
> > > > > IF_RELEASE(_mime_application_octet_stream);
> > > > > IF_RELEASE(_mime_text_plain);
> > > > >  
> > > > > -   IF_FREE_LIST(globs, efreet_mime_glob_free);
> > > > > IF_FREE_LIST(magics, efreet_mime_magic_free);
> > > > > -   IF_FREE_HASH(monitors);
> > > > > -   IF_FREE_HASH(wild);
> > > > > IF_FREE_HASH(mime_icons);
> > > > > eina_log_domain_unregister(_efreet_mime_log_dom);
> > > > > _efreet_mime_log_dom = -1;
> > > > > @@ -387,11 +580,10 @@ efreet_mime_magic_type_get(const char *file)
> > > > >  EAPI const char *
> > > > >  efreet_mime_globs_type_get(const char *file)
> > > > >  {
> > > > > -   Eina_List *l;
> > > > > -   Efreet_Mime_Glob *g;
> > > > > char *sl, *p;
> > > > > -   const char *s;
> > > > > -   char *ext, *mime;
> > > > > +   const char *s, *mime;
> > > > > +   char *ext;
> > > > > +   unsigned int i, n;
> > > > >  
> > > > > EINA_SAFETY_ON_NULL_RETURN_VAL(file, NULL);
> > > > >  
> > > > > @@ -406,25 +598,27 @@ efreet_mime_globs_type_get(const char *file)
> > > > >  while (p)
> > > > >{
> > > > >   p++;
> > > > > - if (p && (mime = eina_hash_find(wild, p))) return mime;
> > > > > + if (p && (mime = _efreet_mimedb_extn_find(p))) return
> > > > > mime; p = strchr(p, '.');
> > > > >}
> > > > >   }
> > > > >  
> > > > > -   /* Fallback to the other globs if not found */
> > > > > -   EINA_LIST_FOREACH(globs, l, g)
> > > > > +   // Fallback to the other globs if not found
> > > > > +   n = _efreet_mimedb_glob_count();
> > > > > +   for (i = 0; i < n; i++)
> > > > >   {
> > > > > -if (efreet_mime_glob_match(file, g->glob))
> > > > > -  return g->mime;
> > > > > +s = _efreet_mimedb_glob_get(i);