Hi, Thanks for reading my looong mail. The main problem (IMO) is that wmaker depends on X11. If X11 dies (is deprecated), wmaker will have problems.
Cheers. On Sun, 20 Oct 2013, Christophe escribió: > > ----- Rodolfo García Peñas (kix) <[email protected]> a écrit : > > Hi, > > > > I was working on these patches, but I think is too much work for only one > > person. I need your help. > > > > What I am doing? I am working on abstraction. My aim is that the wmaker > > elements doesn't use the screen or other physical devices. The aim is > > create the object in memomy and map it on the screen only when is needed. > > Therefore, if we change the screen, we can "re-map" the object, but we > > don't need re-create the object (and then, restart windowmaker). This idea > > is needed for XRandR. > > > Hi, > A little remark here: I think XRandR probably doesn't need this. > Under X there may be more than 1 screen, but if it is the case they may not > have the same color depth, which is why it was historically not possible to > move windows across screen, and why wmaker currently have distinct icons per > screens. > > Now the added value brought by Xinerama and RandR was, with the constraint > that all screens have the same depth, to make the screens look like a single > one to the applications, so you could move windows across screens. In this > mode, wmaker will also create only 1 WScreen struct. > > When calling 'XineramaQueryScreens' or the more modern 'XRRGetScreenInfo' you > get the physical screens, but it should not turn into wmaker screens as it is > not what wmaker calls a screen too, for the historical reason above. > > > > [...] > > > > The second problem is the icon images. The icon should be screen > > independent, but sometimes is not possible. > > My personal feeling is that they *have* to be screen dependant. Icons are > meant to be displayed on a screen, so they need to be. Keeping a screen > independent version looks like a memory overuse for me (and images are > already the biggest memory consuming things) > > > > [...] > > > > Without these ideas, is very difficult (IMO impossible) implement XRandR, > > Multiheader, ... configurations. > > I think the problem is not taken for the right angle. > It is not the image loading and icon creation that should be split, it is the > WScreen information: > The legacy X screen info (basically: depth, the infos to convert the image > into X specific format) should be separated from physical screen info (as > returned by Xinerama and Xrandr, info like size of the screen and the likes). > > But that's just my feeling... > > Christophe. > > > -- > To unsubscribe, send mail to [email protected]. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to [email protected].
