On Sun, 31 Jul 2011 02:59:21 +0200 Leif Middelschulte <leif.middelschu...@gmail.com> said:
review (yes i know the cover things you say don't work or aren't done yet etc.): 1. X-Enlightenment-ModuleType should be settings, not config (if u want this to be a separate module) in the module.desktop.in - this makes it show up. 2. as discussed - should be part of conf_display module 3. e_randr_screen_info in e_randr.c needs an EAPI if u want its symbol exported to modules! same in e_randr.h 4. still missing an icon.png so people can build this. 5. segv on closing dialog. yay! crash here: (gdb) bt #0 0x00abc832 in ?? () from /lib/ld-linux.so.2 #1 0x0015ef01 in pause () at ../sysdeps/unix/syscall-template.S:82 #2 0x08071373 in e_alert_show (sig=11) at e_alert.c:43 #3 0x081120fb in e_sigseg_act (x=11, info=0xbfc10e1c, data=0xbfc10e9c) at #e_signals.c:125 4 <signal handler called> #5 _e_config_randr_dialog_subdialog_arrangement_smart_class_resize #(obj=0x876ca38, w=331, h=270) at e_int_config_randr_arrangement.c:182 6. general design i think can be a lot better. this shouldn't be a separate config dialog to resolutions/rotation so, i'll put in some diagrams here. see attached. notice how i have it all integrated. you can select the available screens and outputs in the main view - click on one and it shows its selected (eg the red box around the inner screen). when you select a screen the surrounding option panes become "enabled" depending on options set and let you disable (never), enable, or set a screen to "ask" (ie when screen is detected e will pop up this dialog and select the new output found and thus ask u what to do with it every time). if set to "ask" all other panes (content, mirror/rot, resolution) are disabled. same if set to "never". if set to "always" this means the display is always enabled (if there is something plugged in - no point enabling it if there isn't). if always on choose the rotation and mirror flags (mirror flags are toggles, rotation is select one of the 4). choose if it clones the primary display (only thing i havent addressed here is choosing what the primary display is). and then select resolution. if selecting native - you basically mean "auto" - ie select the native res for the display (eg the lcd panel res) or whatever randr says is the "default" or "native" res. to choose which screen is to the left/right/above/below just drag them around the screens area. it should zoom in and our and move screens around as needed to fit what u are arranging. drag up and down to get screen to align to top-.middle/bottom of a larger screen (eg the vga one next to the hdmi one). the screens in the screens area show the rotation icon (and hint with a base of the screen rotating too to indicate how the screen might be placed in real life) with some info in the screen giving rotation arrow, add a flip arrow for the flip modes and the output name, its configured state and resolution. that's what it should be imho. :) > Attached, > > a new set of patches. > > Basically their only intend is to cover the missing image issue. > There is no further difference. > So whether is conf_display integrated nor does it show up in e's > loadable modules list. > > Just the icon added, so testing is easier. > > For those who didn't follow: > 1.) Apply attached patches to root. Patches were created based on > revision 61924. > 2.) Compile and install e17. > 3.0) Open a terminal and > 3.1) Enter "enlightenment_remote -module-load conf_rand" and afterwards > 3.2) Enter "enlightenment_remote -module-enable conf_randr" > > You should now find a configuration dialog called "screen setup". > > Note that this is just testing. The module will be integrated into e > and replace by integrating the dialog e_int_config_display. > > If you face issues like a SEGV, please attach gdb and provide a > backtrace. I'll try to help asap. > > BR, > > Leif > > 2011/7/30 Leif Middelschulte <leif.middelschu...@gmail.com>: > > 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 > > > > -- > Leif -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com
<<attachment: randr.png>>
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
