2011/7/30 Carsten Haitzler <ras...@rasterman.com>: > On Sat, 30 Jul 2011 19:26:51 +0200 Leif Middelschulte > <leif.middelschu...@gmail.com> said: > >> 2011/7/30 Carsten Haitzler <ras...@rasterman.com>: >> > On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte >> > <leif.middelschu...@gmail.com> said: >> > >> >> 2011/7/30 Carsten Haitzler <ras...@rasterman.com>: >> >> > On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte >> >> > <leif.middelschu...@gmail.com> said: >> >> > >> >> > why did you make it conf_randr. >> >> Because I thought maybe people don't need it all the time. Just to >> >> configure their setup once and afterwards they don't have to load it >> >> anymore. >> >> > already months ago i merged config modules - >> >> > it's part of conf_display - and e_int_config_display.[ch] in there. as >> >> > already mentioned missing icon.png, which we dont have to worry about >> >> > if >> >> > you merge it in with conf_display. can you do that? :) >> >> The reason I didn't merge in conf_display in the first place was, that >> >> people might not even have multiple displays, so the entire >> >> adjustment/policy stuff is useless to them (e.g. if their drivers just >> >> supports RandR <=1.1). >> > >> > this isn't just for multiple displays its for resolution too and just fyi.. >> > people with laptops need this quite often. :) if its never used the code is >> > never paged in from disk so it costs nothing (if its already part of a >> > module loaded anyway). >> > >> I know what conf_display did :-) I'll integrate its options into >> 'conf_randr'. >> >> >> But yes, I can merge in conf_display as another page in the toolbook. >> >> Though it'll have to wait a bit, until I'm finished with my next exam >> >> (end of next week). >> > >> > well it really should be one and the same dialog. to set up resolution and >> > rotation for each screen AND set up how many screens are enabled or not and >> > what the policy is when a new screen is found (auto-enable, never enable, >> > should it extend or clone etc.). >> Per display stuff will be integrated along the integration of conf_display. >> Policy stuff is already there and "works for me"(TM). >> > >> >> I planned to adjust e_int_config_display so it works with CRTCs (RandR >> >> 1.2) instead of just the primary screen (RandR 1.1) as it does right >> >> now. I won't support RandR 1.1 in that dialog anymore. People whose >> >> drivers just support RandR 1.1 shall stay with the current dialog. So >> >> actually we need a new name like 'conf_display2' or rename current >> >> dialog to e_int_config_single_display and the new one >> >> e_int_config_multiple_displays >> > >> > it really should support the whole range - 1.1, 1.2 etc. - a user shouldnt >> > have to switch dialogs to choose what version of a spec is supported. they >> > have no clue which one is supported. they just want it to "work". :) >> But randr <= and >1.1 work completly different. There is not code >> sharing. That's why I pliedge for leaving the dialog (conf_display) as >> is and just pop it up instead of integrating it into an else useless >> dialog (conf_randr), making the code more complicated than it needs to >> be. I went that way before and it's double effort without any >> advantage. >> As I proposed above: >> if (randr < 1.2) >> return conf_display; >> else >> return conf_randr; //with conf_display2 integrated >> >> If you can point out a good reason why to rewrite most of the old >> craft, I'll do it. But else I see more benefit in getting other things >> done. > > you are thinking like the programmer and not the USER. the USER doesnt know > ifd > their driver does 1.1 or 1.2 and they shouldnt NEED to know. it is the job of > the app (e) to figure that out and present the appropriate UI for their > situation AND to use the appropriate protocol. it is not the users job to try > and figure out which protocol they have and then go choose the right config > dialog for that protocol. it is the job of code in e to fgure that out and > switch internally as appropriate and presetn at the ui level the features you > can configure given that protocol version that our driver happens to do that > we > DISCOVEr at runtime. Okay, I think we're arguing on different things. 1.) You're right about the dialog's behaviour. It should provide the user with a dialog resembling his driver's capabilities, no matter what they are. 2.) I tried to communicate: conf_display -> conf_display1 conf_randr -> conf_display //with integrated conf_display2 (for randr >=1.2) and conf_display1
conf_display will then be displaying either the current dialog (if ran on randr <1.2) or the new all-in-wonder dialog if supported. Is that okay? Man, sometimes seeing people for really simplifies discussions a big deal :-/ Thanks for your interest :-) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- Leif ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel