Hello Em 02/09/2008, às 10:02, Aike J Sommer escreveu:
> Hi, > > i have the feeling that my gsoc-project finally is in a state, in > which it > could be made ready for trunk... So i wanna get a discussion started > on what > still needs to be done or what should be changed! :-) Good to hear that :) > The current state is: > - there is a daemon (kephald) which will monitor xrandr events and > change > configurations accordingly > - each set of connected monitors will be saved along with the last > used > configuration for them > - if a known set of monitors is plugged in, that saved > configuration will be > loaded and applied to the monitors (that includes position, size, > rate, > rotation, reflection) > - if unknown monitors are plugged in a default configuration will > be loaded > - theres a library (libkephal) which wraps kephald's d-bus api, > which is split > in 3 parts: > 1) screens: the individual areas available for apps, eg what plasma > needs > for deciding where to put a desktop-containment > 2) outputs: the actual outputs and its connected monitor, needed for > configuration of those > 3) configurations: the configurations, these have a unique name and > can be > used for context > - theres a dataengine, holding most of the available information from > libkephal, including jobs for actions like move, resize... > - theres a (very basic) applet for managment of screens, it allows > for: > - moving of an output > - resizing of an output > - reverting or confirming the change > - its not really well tested yet and still lacks lots of possible > settings > > There is currently only support for xrandr 1.2, but xinerama support > is > already started locally... If xrandr is not available it will just > fall back > to using QDesktopWidget for screen-information, so it should still > behave > kind of sane!! ;-) > > My currently planned next steps would be: > - compile time checks for xrandr 1.2 In krandr I have done this, so it might be a good idea checking it there. > - xinerama support The only thing that should be taken care of is not to mix real xinerama with fake xinerama (which provides randr1.2 info). I don't really know what happens if you use a xinerama setup for two cards that have more than one output each. > - maybe nv-control support > - work on the applet > - use as much of the applet as possible to create a kcm > > What would be needed in plasma: > - make plasma listen to libkephal's signaling about screen-changes > instead of > qdesktopwidget > - use the configuration-name for context > > > There's also a techbase page, where i put some more infos: > http://techbase.kde.org/Projects/Plasma/ScreenManagement > > > Now... Would be nice to get as much input as possible... :-) > One of my open questions would be: Should kephald be converted into a > kded-module? I would say it is a good idea, as kded is already in place for that purpose. > And of course: What do or dont you like? > What did i forget? I might have missed this, but where is the source hosted? I want to take it a look. > What ideas do you have? Your work seems very complete from my point of view. The only thing I could think about was to do some integration with kwin's effects, to add a fade-to-black and fade-from-black effects when switching outputs' parameters to make the transition look more smooth. Besides that, I guess the work on this stuff is following a good way. Congratulations for the job! []'s Boiko _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
