On Thu, 7 Jul 2011 13:09:53 +0200 Nicolas Aguirre <[email protected]> said:
> 2011/6/24 Carsten Haitzler <[email protected]>: > > > > that would be the right thing to do. :) n.b. nicolas: i'm thinking elfe with > > some improvmeents would be good for e18 as default illume home. things > > needed tho: > > That sounds good :) > > > > > 1. elm needs to work properly in e as a child window or just in a "foreign > > canvas". this needs to be partly done in elm at least. like e_win but part > > of the infra in elm as hooks and part in e. > > I don't understand what you mean by "foreign canvas". elm's widget tree RELIES on the fact that the eventual top-level will end up being an elm window EVAS OBJECT for things like proper focus handling and more. elm can kind of limp along without this but a bunch of things won't work. more importantly is that e NEED to create its won ACTUAL windows to manage. e itself has special infra for this - e_win. as when a wm creates its own windows.. they do not get redirected like everyone elses - so all the normal rules of "wm intercepts action X and gets to do it for the client" don't happen. elm_win ASSUMEs that a wm will be doing all of these things. if you used elm_win in e it'd fail miserably without glueing into something like e_win. you wouldnt get a border. you couldnt then move/resize and otherwise use it properly. even worse the ecore-evas compositor sync mechanism will probably end up in a deadlock. hooray! :) first step is allowing elm to wrap up an existing ecore-evas with an elm_win and then "work" as expected. next is so elm_win itself can "just work" as it would when used outside of the wm. > I plan for the composited window list selector, to render all Elfe's > Evas_Object in the evas of the compositor. > It seems that we can't create a proxy object in canvas wich is not the > canvas of the parent. So i have no other option than creating all my > objects in the compistor canvas. > But maybe that you plan to change that for e18 ? it's an e17 > limitation ? or evas ? its an evas limit - it won't be going away. as such the plan for e18 is to move more and more INTO the compositor canvas. it solves so many problems. i am planing on e18 or e19 becoming "compositing only" to make this "sane to support". > > 2. elfe doesnt like "strange sizes" of icons - it clips them and some > > things. it's ok. its new. but its good! :) > > Default value for icons is 72x72px. You can change that in the eet > configuration file. I do that because SHR people have a per device > configuration. I did not find a way always have icons to looks good, > so i take the choice to have a fixed size. Indeed when the icon size > is not choosen with the rows and columns numbers, you get a clipping > problem. What could be good ? Compute the colums/row size depending on > the DPI of the screen and resize icons accordingly ? What would you > prefer ? it'd be good if it adapted to the screen res/size better eg with more rows or columns of icons if there is more space etc. etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
