On Mon, 8 Aug 2011 22:53:50 +0200 Leif Middelschulte <leif.middelschu...@gmail.com> said:
> 2011/8/8 Carsten Haitzler <ras...@rasterman.com>: > > 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.): > Thanks :-) > > > > 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. > No, will be demodulized. > > 2. as discussed - should be part of conf_display module > Will be done. > > 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 > Will add in future patch. > > 4. still missing an icon.png so people can build this. > No, it's there. I just have had a look at the moste recent patch I > sent. Maybe you applied the old version, which indeed misses it. hmm - seems i did look at the older patch. i didn't have the newer one marked. ) > > 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 > what the heck? Those lines are secured by checks for NULL. i don't think it was null - it was invalid somehow. > > 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. > Thanks for your effort here. > Well, I intended to seperate that resolution stuff away. Not > necessarily into another dialog, but into another page. Today's > monitors actually have and provide a prefered resolution. That > resolution is also used when screens are autoenabled on attachement > (policy). > My intention was that you usually don't deal with resolutions > nowadays. Why would you? Except you're trying to clone some other > output, which is another story. there lies the problem. there will be a lot of people who DONT have "todays monitors" still. nice old CRT's. a lot of people like to run e on "older" systems because it uses less resources. like it or not CRT's still are around and in use in enough numbers to need a resolution selector. > > notice how i have it all integrated. > Yeah, I split it intentionally to not overwhelm the user with options, > he/she/ doesn't even care about, just for the sakeness of all possible > options to be visible at once for advanced users with large monitors > and in need of those ;-) well in the case of a single screen it'll be the same as the current screen res dialog except you see a preview icon of the screen with its output name and 1 extra set of options: "never, always, ask". that's it. as its the only screen content is automatically "new screen" and u cant change it. the res is rotation, flip and resolution. it's better to be on the same area as then you can see how your options affect the preview (screens area) and the rest is done by dragging preview screens around and selecting them. configuring your screen imho is already an advanced option. imho the DEFAULT mode we should have in e for "all outputs without a specific config" is "always + new screen + no rotation/mirror + native res". then by DEFAULT it does what most people will want a they never have to poke in the screen config dialog. > But I think it would be nice to have the entire look customizable. But > I guess that'll be only feasable with elm. > > 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). > Already is there and themeable via edc. > > 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). > As of now, the dialog provides more than just 'extend'. It let's you > chose a direction in which it extends the screen as well. the mock i drew does that too - drag the screens around. you can even then select how the extended screen ALIGNS to other screens. have you used the gnome or nvidia settings apps that let u configure screen layout? used the windows one? you just drag the screens around to lay them out. much simpler and nicer than a limited "list" of how to lay them out and select one. > > 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. > I am not sure whether I get this right. How could we posibly select a > resolution of a monitor never connected? What if the new monitor does > not provide that resolution/mode? the dialog only shows connected monitors. if there is nothng connected/detected, then it doesnt show up there, so it cant be selected and configured. if the output is configured for native res and it doesnt provide one - probably just choose the highest one it provides, or if none, choose some default (640x480) etc. hmm - i forgot refresh rate selection there too i think. :) > > 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). > This is already there. But only those somehow connected to the most > upperleft screen are actually placed. This is due to rounding errors > when scaling down the representations and then up again for monitor > placement. i couldnt test with > 1 screen attached, so i only saw 1 dragable screen thing.. :) > > 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. > Screen rotation and reflection options are not there yet. > > > > 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 > > > > > > > > -- > Leif > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
