Sorry for not replying earlier, I completely missed this one, as I'm not very active on phab.
May 9 2017
Dec 8 2016
Nov 16 2016
Just a couple of thoughts:
We already did Edinburgh and Paris recently.
Edinburgh and London are fairly expensive (even with the recent currency devaluation).
Oct 19 2016
Sep 30 2016
Sep 29 2016
Sep 28 2016
Sep 19 2016
Sep 12 2016
There have been a few fixes, we are now at:
00007f661ecea000 116K r---- libelementary.so.1.18.99
00007f661ed07000 32K rw--- libelementary.so.1.18.99
Sep 9 2016
This should be OK now. Is it?
Sep 2 2016
Yes, I think we should go with the second option. Option 1 feels wrong. It's not the poor app's fault that the system is broken. We need to help it.
Thanks, your second (redacted) log and analysis is very helpful. I'll only be able to take a look next week (hopefully), but this would really help, and more so, it's probably very simple to fix.
Aug 23 2016
On the phone/desktop you don't see terminal output when you run an application, you will never see this error as a user of an application. Furthermore, in some cases it can't be done at all (font embedded in the theme, or a specific file). There is no nice graceful way of printing an error from our side. Applications could potentially check and report the lack of fonts, but that's out of scope for us as the GUI toolkit. If you want absolute correct results as an app, deal with it an error, otherwise, we owe it to applications to do the right thing. There is no spec anywhere saying that fonts should come with bold variants, so "runtime embolden" should be considered as a reasonable alternative. More so, it actually is. I doubt fonts will be too screwed.
Yes, using a good font that was designed this way is best. However, such a font is not always available so we try to do our best in accommodating the programmer's request, so we make fonts bold on runtime. It's a fallback to a missing font.
Aug 22 2016
Unless I'm misunderstanding something (or just don't remember the code correctly), I don't see how this has anything to do with fontconfig.
@herdsman, I think you misunderstood the ticket. He's talking about runtime embolden in freetype when the system can't find a bold variant of the chosen font.
Aug 17 2016
So... More info.
You misunderstood me, the "not the end of the world" was referring to putting RO data in executable pages. The memory issue is real, and I'm still looking into it. I solved a minor case. Working on the rest.
OK, after giving it a second look, it seems that it just maps the global consts into the "rx" section, so if it's a global and constant page it would be there. I thought it would separate to non-executable pages, but I guess it's fine to put it in an executable page. So not the end of the world.
I looked into it a bit. I managed to make some progress, but not a lot.
I managed to reduce a page for each library by removing some static variables in class creation. Just because it's only a page (and to be honest, the amount of memory these variables should take) I don't think that's the culprit. However, after looking a bit more into it, I saw something very suspicious. According to pmap on libefl:
Oh, I didn't see you said it was private pages (though now I remember we actually talked about it a while back). Hm... OK, I will have to check. Annoying that there's no compiler option/tool to easily see what is mapped to private pages. Maybe I will have to write one. :|
Aug 16 2016
I just fixed heap usage a bit, but I wonder what this is and where it's coming from.
I still haven't dug deep, been dealing with other more urgent matters. Will hopefully manage to find the issue soon.
Jul 15 2016
Jun 20 2016
No reply for a while, let's consider this close.
May 20 2016
May 17 2016
May 12 2016
May 6 2016
@q66, it's already fixed.
May 3 2016
Apr 28 2016
"class" is actually a good enough key I guess, because you want the returned type to be of a certain class and for this purpose it shouldn't pose a problem to only have one of each class.
I like it much better than loop get, that's for sure so it can already go in, but I have a few concerns still.
Apr 26 2016
Apr 18 2016
Apr 14 2016
You don't want to convert on your own. Nevermind then. This sucks though.
Apr 13 2016
I'd much rather you made it a wiki page and made it more descriptive. This is very hard to work with. I have many comments and this feels incomplete. I commented a bit on IRC.
Apr 8 2016
Looks good. I just needed to slightly change the documentation of evas_language_reinit(), please take a look at what I did.
I also slightly changed the commit message.
I'm a bit surprised and sad to see that non-utf8 is actually legal. :( I'd say we should probably just restrict ourselves to utf-8 and open a ticket with upstream. This is quite ridiculous.
Apr 7 2016
vpath: please open a new patch and assign to @raster. This has nothing to do with this issue.
Apr 6 2016
I suspect it's another issue with the weak API change. That is, @jpeg's fault. :)
It was not moved on purpose in order to not break people relying on the git repository for creating packages from commits and tags.
Mar 31 2016
This is weird. Could you please provide a test case?
Mar 24 2016
Mar 11 2016
Mar 8 2016
Happy my patches helped. :) It was a stupid regression that shouldn't have been there in the first place...
I guess you also probably wanted to reopen this.
@raster, I didn't even look at the screenie, just assumed that was the case. :)
Mar 7 2016
@raster, I think we need to optimise for the default case. I know you like having nexus there by default, but maybe we should use a bigger font? Or a bigger version of nexus? You use inhumanly small font sizes on your desktop, you are definitely not the yardstick...
Mar 4 2016
@raster already covered most of it. Label is going to be a thin wrapper around entry with a few different defaults. Performance won't be a problem anymore thanks to eo_add, and everything will be covered with rainbows.
Mar 3 2016
@q66, this needs fixing.
Mar 2 2016
You can't really have a "changed" interface, because the changed should/would have different event info depending on what has changed. This is an example of a took generic naming that won't work any more. We would need to rename it to "state,changed" or whatever.
Feb 29 2016
I came up with a solution for the multiple parents while I was in HQ. I discussed it a bit and people seem happy. I'm going to work on Eo4 (more about that soon) in the next few days, but once that's done, I'll tackle the multiple parents thing to be clear and consistent.
Feb 22 2016
Terminology issue is now fixed.
Feb 19 2016
I'm not sure what I'm seeing, but per my message to the ML, I found rELM79b6edd1a6ad763258337b7aac5bd7799411bb44 to be buggy and screw up my terminology. Maybe it's related?
Feb 18 2016
Anddddd one last comment. Sorry for the storm.
Looks fine, I only have one query. Is parent_obj set by any other means (I think it is)? If so, we should update the eo parent there too.
This is correct.
Looks fine with me. @herdsman, is this ready to go in?
Btw, just to clarify something that is kinda related to my original objection to data_ref: using and storing the data directly is a bad idea. We use it internally for optimisations, but it's generally not recommended otherwise, so if your code is using it. Stop.
I'm way more comfortable with blaming @cedric than blaming me.
I'm talking about font_callbacks in font_desc, which is what this patch is about, it's following the previous patch, no?
Feb 17 2016
I know we deal with bearing, and I know some have negative bearing. I was just saying your example was unfair.
I'm starting to think me letting the patch introducing fallbacks in was a mistake. :|
I'm letting it in for consistency (and Edje fonts), though you probably want to set the fontconfig font fallbacks in your (tizen) case, and not use this api.
Feb 16 2016
Sweet. I know @herdsman had a few minor comments, I wonder why he hasn't posted them yet. Will chase him now.
This is too big to review here, so we are reviewing externally. Keeping this open for tracking.
Looks good to me. If everything compiles without warnings and tests fail before this and pass now, I'm happy.
I agree, and since the new phab update, I can see the change is already split to commits like I asked!
Many comments to _ami_ on irc.
Feb 15 2016
@raster, your example from above is not 100% correct, you made it sound as if it was:
(underscore indicates the spacing)
Feb 12 2016
Feb 11 2016
Feb 10 2016
I'll keep it open for now, and maybe i'll get to fixing it up myself. As it is, it can't go in. Commit message is not conforming to our guidelines, and it'll be too hard to review for others reviewing, or for me.
There is a much easier solution to this problem (that also has the benefit of a better ux), which is what is done on Android. Don't let them swap places, just block it, so back to my example, if you try dragging @ all the way to the right (or bottom for that matter), it becomes:
The big question and reason why we didn't do it still remains. This isn't done on textblock, should it be done only here?