Sorry for not replying earlier, I completely missed this one, as I'm not very active on phab.

Just a couple of thoughts:
We already did Edinburgh and Paris recently.
Edinburgh and London are fairly expensive (even with the recent currency devaluation).

Nice catch. :)

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

This should be OK now. Is it?

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.

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.

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.

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. :|

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.

Closed.

No reply for a while, let's consider this close.

@q66, it's already fixed.

"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.

You don't want to convert on your own. Nevermind then. This sucks though.

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.

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.

vpath: please open a new patch and assign to @raster. This has nothing to do with this issue.

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.

This is weird. Could you please provide a test case?

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. :)

@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...

@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.

@q66, this needs fixing.

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.

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.

Terminology issue is now fixed.

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?

Anddddd one last comment. Sorry for the storm.

@JackDanielZ did it in rELMf7086fac95cb557f65a68c34639666397fd6d7d6
I think by accident, but you can never be sure with that menace of a guy. ;P

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.

Just to update this. As @jpeg checked and found out, data ref doesn't actually ref the object. @cedric wrote it, and didn't do it. I guess it's just there for debug (that's awfully confusing)?

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?

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.

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.

@raster, your example from above is not 100% correct, you made it sound as if it was:
(underscore indicates the spacing)
"Hello"
vs.
"Hello_"

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?