On 05/09/12 09:58, Christopher Michael wrote: > On 05/09/12 07:49, Tom Hacohen wrote: >> On 05/09/12 09:43, Christopher Michael wrote: >>> On 05/09/12 07:32, Tom Hacohen wrote: >>>> Another idea: >>>> Make evas_object_move move stuff within the framespace (i.e default >>>> framespace already taken into account) >>> >>> Maybe I am not understanding you here because I have not had my coffee >>> yet, or maybe you are not understanding framespace, but that is exactly >>> what is going on now. evas_object_move accounts for the framespace. >> >> I understand that how framespace is supposed to work, I understood you >> were doing something different. I can't say I dove deep into your code, >> but the sheer fact that you had to use evas_output_framespace_get was a >> red flag. Why do you have to use it in elm? I'd expect no adjustments to >> be needed. >> >> -- >> Tom. >> > > It needs to be used in elm in certain cases because of how some of the > elm widgets are made. Just as an example, the hover widget. It creates > this "grey" area when it shows up that is used to respond to clicks so > it can dismiss the hover, however that grey area is not part of the > actual widget itself but rather drawn over the background.
To sum our discussion from IRC. We were both talking about the same thing and the adjustments you did in elm were specific "hacks" around broken code in elm. Framespace does not need anyone to take it into account. -- Tom. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
