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

Reply via email to