Re: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag & drop marker.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3358/ --- (Updated 2010-04-02 19:05:06.237279) Review request for Plasma. Changes --- As discussed with Lukas: * Make the two layouts in QuicklaunchIconGrid available as member vars. * Remove unnecessary call to QuicklaunchIcon::setPreferredSize(...). Horizontal alignment of icons when there is excess horizontal space (in horizontal panels) or vertical alignment when there is excess vertical space (in vertical panels or the desktop) remains unchanged for now, but is easy to change if requested. Summary --- Ok, this is a biggie (and still a work in progress), so there are certainly a bunch of issues. I just wanted to let you know that I've started to refactor the quicklaunch applet hoping to make it a bit easier to address existing issues and to add new features. As this turned out to be more of an undertaking than I originally thought and since it is now now in a state where it's not completely broken ;), I thought I'd collect some feedback on the patch thus far. Especially since I accumulated a number of questions regarding decisions I can't Without further ado, these are the main points of the patch: - Moved icon layout, memory management and drag & drop handling into a new widget (QuicklaunchIconGrid), so not everything has to be handled by the QuicklaunchApplet class. However, since the existing logic requires that icons are pushed to / pulled from the dialog depending on the total number of icons, I couldn't get rid of some icon management code in the applet quite yet (more about that later). - Changed the way the icon size is used in order to make it work better in size constrained conditions. The user configurable icon size is now used as a hint that restricts the creation of new columns (in vertical form factors) or rows (in horzional form factors) when this would mean that the configured size would be undershot. Icons are now allowed to scale down below the set icon size if there is not enough space available. - Added preliminary display of drop markers (as of now: in the form of ugly gray squares) when dragging icons around. - Added drag & drop support to the dialog. Known regressions / still missing: - Sorting of icons is not yet re-implemented. - The code is still quite hacky at some points (but I'll wait with cleanup until I know about the outcome of the discussion about the questions below). - The primary icon area is not repopulated once all icons are removed. Although I tried to preserve the current functionality during the rewrite, I ran into a few design decisions that I thought might deserve some discussion: 1.) The dialog (and it's configuration by the number visible icons) Especially since drag & drop to the dialog works now (or at least it should ;), I think it feels odd (from a user perspective) that the separation between icons in the primary area and icons in the dialog needs to be manually configured by setting the number of icons that should be displayed by the main area. Consider the following use case: Joe uses the quicklaunch applet for starting some apps he uses regularly (which he wants to be reachable from the primary area) as well as for apps he uses sometimes, but not too often (which he wants to be in the dialog). Lets say, his favourite apps are called FooApp and BarApp. In order to configure what he wants, he needs to - add his favourite 2 apps to the quicklaunch applet - order the icons so that they are at indices 0 and 1 respectively. - open the config dialog and set the number of visible icons to 2 After a few days where he also added a number of other programs to the dialog, he discovers a new program he really likes: BazApp (obviously). In order to add it to the main area, he would have to: - open the config dialog and set the number of visible icons to 3. - notice that the first program that previously was on the dialog (OtherApp) popped into the main area. - drop BarApp in the main area at a position where it pushes OtherApp back into the dialog. Had Joe forgot about how the applet works, he might have tried to drag BarApp to the main area before reconfiguring the applet, which would have caused it to be pushed into the (possibly hidden) dialog immediately. As a first step to a solution, I would suggest changing the behaviour so that the user simply chooses whether to show a dialog or not. If the dialog is enabled, items can be freely dragged to / from the dialog or the main area (or added / removed using the context menu). This would require to display some default content when the icon areas are empty (but that would probably be a good idea anyway - see 2). This change would not even require a change to the applet's config as the icons could still be s
Re: Plasma Media Center and state machines
On Fri, Apr 2, 2010 at 5:54 PM, Shantanu Tushar Jha wrote: >> >> Shan proposed to have states for each applet. I my mind this means that a >> plugin would need to write states for all applets, so actually similar to >> the above, except that the instructions are closer to the applets and >> seperated in individual state objects. Sounds more complicated to extend in >> my head. > > Hehe, just because I like simplicity doesn't mean I'm always right. I > noted Marco's comment that even this doesn't solve the problem. /me > thinks, If I get an idea, I'll post. uhm, let's see: what about qstates built and selected not from an enum but from strings. the plugin says my state is called foo. for the player control applet i want those features (an or of stuff like play, net,progress etc) for the browser applet i want this.. and maybe i want also my own applet positioned here the loader builds the proper states from that, knowing what each plugin wants to enable/disable ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
On Fri, Apr 2, 2010 at 7:31 PM, Christophe Olinger wrote: > > > On Thu, Apr 1, 2010 at 10:43 PM, Aaron J. Seigo wrote: >> >> On April 1, 2010, Christophe Olinger wrote: >> > >> sliderMusicModeSeek; >> > >> iconSlideshow; >> > >> iconRotateCW; >> > >> iconRotateCCW; >> > > >> > > would these rotation ones belong to the image browser, and be provided >> > > as >> > > "custom" elements rather than named elements in the main enum? >> > >> > I thought we could to this: >> > Have a main enum with things common to the states (enum >> > MainSubComponents) >> > Have an enum with things specific to a state. (enum >> > BrowseVideoModeSubComponents) >> > In that case, the rotate buttons would be part of the BrowsePictureMode >> > and >> > BrowseSinglePictureMode enums? >> > Custom widgets always belong to some state, don't they? >> >> yes; what i was/am unclear on in your email was how the enums were all >> mixed >> together with both the common sub-components and the state-specific ones >> listed there. > > > They will be seperated in the real implementation. > Shared widgets will be owned by the MediaCenterState class, while state > specific widgets will be owned by the state subclasses. > >> >> > >> browserGoPrevious >> > >> playerPlayPauseVideo >> > >> playerPlayPauseMusic >> > >> playerPlayPausePictures >> > > >> > > what would thse signals be used for, exactly? and why are there >> > > separate >> > >> > ones >> > >> > > for Video, Music, Pictures, etc? >> > >> > I thought that if the controlBar needs to tell the browser to go up one >> > levelm it needs a signal to do that and the browser needs a slot to >> > accept >> > that. When we handle connecting applets between them in the >> > mediacontainment or whereever, we only have the type implemenations of >> > the >> > applets available. By adding public slots and signals to the type >> > classes, >> > we make sure that we do not forget reimplementing these in the actual >> > applets. >> >> ah, you mean as interface descriptions for the media center applets? sure, >> that makes sense. > > Uff > >> >> > > i think the MediaCenterState object should simply remove/hide all >> > >> > components >> > >> > > that were visible in the last state but which are not visible in the >> > > now- >> > > current state. >> > >> > Thats why I thought keeping a list when entering a state would be a good >> > idea. >> >> yes; but not in the state subclasses. do it in the class that owns the >> shared >> widgets so that those objects are never directly exposed. > > Ok, as above: MediaCenterState object created by containment will own shared > widgets. There will actually not be many of these I think. > >> >> > When each state object adds widgets to applets, how can the >> > MediaCenterState object know about this? >> >> what widgets to which applets? > > That was a stupid question by me. On state change, First the shared widgets > in the MediaCenterStage will be looked at and added to the applets and than > the state specific widgets will follow. At the moment, this only concerns > the ControlBar and the InfoBar applets. The player, playlist, browser all > have the same widgets in all states. Except maybe the tab bar that we want > to add to the browser. > Shared widgets are JumpToHomeScreen and the widgets showing the active > background modes. Probably toggle autohide buttons. > The HomeScreen widgets will belong to the homeState object. > >> >> > Would this be done by having the list defined in the MediaCenterState >> > Object and the individual states would use that list. >> >> yes, i think so. >> >> > A simple public (or protected) member variable? >> >> avoid shared members, use accessors and setters. (encapsulation) > > sorry, setters and getters FTW > >> >> > > QList components = >> > > newState->subComponents(); >> > >> > Okay, so in each State class I need a subComponents() function that >> > returns >> > pointers of all subComponents needed in that state. >> >> of all the *custom* sub-components. > > indeed > >> >> > What about the general ones from the MediaCenterState class? >> >> my guess is that those are owned by the containment, and so it is the >> containment that should be managing them. the state object (subclass of >> MediaCenterState) should simply describe a layout, nothing more. > > let's see in an actual implementation > >> >> > "newState" will be replaced by the actual object that is the next stage? >> >> newState is the next state, in that example. and yes, on the next >> transition >> it would be done all over again with the new state. >> >> > > QListIterator it (m_visibleSubComponents); >> > >> > The m_VisibleSubComponents was filled on state change by the last state >> > and >> > is stored in the MediaCeterState object? >> >> no, probably in the containment. there will be multiple MediaCenterState >> objects (one for each state in the machine), but only one set of >> components, >> owned by the containment. > > true. ver
Re: Plasma Media Center and state machines
On Fri, Apr 2, 2010 at 2:04 PM, Alessandro Diaferia wrote: > > > 2010/4/2 Marco Martin >> >> On Friday 02 April 2010, Shantanu Tushar Jha wrote: >> > (My ideas, be free to kick ;) >> > >> > Hi Christophe, now I'm able to understand most of what you've >> > proposed. Somehow, I don't like having just one state machine for the >> > whole MC, the main reason being that we're going to support >> > extensibility through custom plugins, so the MC can no longer assume >> > that it knows exactly how many states are present. >> > What I propose is not altering the libraries, but to have a state >> > machine for each component (component as in the containment, >> > controller applet etc). Though I don't have code to show that right >> > now (i'm writing a small Qt app to demo it), I'll try to explain a >> > sample working- >> >> While i share the concern over extesibility (and wouldn't know how to do >> it >> with a single global state machine) how a state machine for each component >> would fix that? >> a part every plugin being a omplete set of new applets... >> >> Cheers, >> Marco Martin >> ___ >> Plasma-devel mailing list >> Plasma-devel@kde.org >> https://mail.kde.org/mailman/listinfo/plasma-devel > > I like the extensibility idea too but i think that we are bound to the > definition of a set of possible states. We can try to look forward as much > as we can and define such states. Plugins will just specify which of those > states they'll refer to. In the future, probably, we'll update our libraries > with the states that we could have never imagined in the past :-). Seems something like pseudo extensible :P > > So we can now have: > Pictures, > Videos, > Audio tracks, > Games, > Olographic films :-) > ... > > That's probably enough for now :-P > > Cheers > > -- > Alessandro Diaferia > KDE Developer > KDE e.V. member > > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
On Fri, Apr 2, 2010 at 6:40 PM, Christopher Blauvelt wrote: > Perhaps I haven't been paying close enough attention but what is the need of > the state machine? > >>> >>> So we can now have: >>> Pictures, >>> Videos, >>> Audio tracks, >>> Games, >>> Olographic films :-) >>> ... >>> >>> That's probably enough for now :-P > > Your joke I think proves that it would be better not to have one. If we're > going to use a plugin architecture then the whole point is that we don't > know how many states we're going to have. I really think the model-view > framework is our friend here and, while I don't like the visual interface, > MythTV has done a good job with defining a menu system. When it all comes > down to it, that's what this really is. Instead of a state machine I think > it would make more sense to have layouts defined which you move to once a > selection is entered. You can zoom and twirl your way there however you > like. The layouts could be defined via some kind of XML schema, like > MythTV, or through some other means. Well, seems similar to GUIXML, hmm. will think over this. > > To illustrate my point a little better: > You're at the home screen and the user selects "Pictures." You move to the > picture/album browser layout where you can scroll to the album or picture > that you like. Your menubar changes based on parameters defined in the > plugin instead of parameters defined in the part of the program that > launches the plugins. This gives the flexibility to the plugin writer to > define what he/she wants without requiring changes to the main program. > > Thoughts? > > Chris > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 20:15:40 Aaron J. Seigo wrote: > On April 1, 2010, Will Stephenson wrote: > > Aaron, do you think there's another GSoC project in completing Kephal? > > yes, particularly on the storing / restoring of configurations and > integrating it with the existing UI elements (device notifier and > providing a more user- friendly alternative to the current kandr icon, > which is highly functional but also tricky to use) Ok, Can I write a proposal for this then ? I'll keep asking about implementation issues while I'm looking how to do that and what's necessary to do that project. At first glance, it looks a bit light to make it as a GSoC but I can be wrong about that. By the way, I'm Cazou on IRC. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Friday 02 April 2010 16:26:36 todd rme wrote: > On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova > > wrote: > > So, my point is : there are problems. > > So far, what's the link with plasma you might ask. Well, I'd like the > > device notifier to react when a monitor is plugged in, showing the > > screen. 2 actions should be possible : Auto configure and manual > > configuration. > > -> Auto configure would try to find the best configuration depending on > > the screen capabilities (read resolutions). > > -> Manual configuration would open KRandr. > > There is also an issue with plasma were activities that end up on a > monitor of the wrong size do not properly re-scale the widgets they > contain, which can result in widgets overlapping, having unpredictable > locations, extending off the screen, or having large blank areas. > Fixing this would probably be a worthwhile task. Mmmh, I'm not using plasma activities but it's also to be checked, of course. Detlev. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thu, Apr 1, 2010 at 10:35 AM, Detlev Casanova wrote: > So, my point is : there are problems. > So far, what's the link with plasma you might ask. Well, I'd like the device > notifier to react when a monitor is plugged in, showing the screen. 2 actions > should be possible : Auto configure and manual configuration. > -> Auto configure would try to find the best configuration depending on the > screen capabilities (read resolutions). > -> Manual configuration would open KRandr. There is also an issue with plasma were activities that end up on a monitor of the wrong size do not properly re-scale the widgets they contain, which can result in widgets overlapping, having unpredictable locations, extending off the screen, or having large blank areas. Fixing this would probably be a worthwhile task. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Dew
___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
On Thu, Apr 1, 2010 at 10:43 PM, Aaron J. Seigo wrote:
> On April 1, 2010, Christophe Olinger wrote:
> > >> sliderMusicModeSeek;
> > >> iconSlideshow;
> > >> iconRotateCW;
> > >> iconRotateCCW;
> > >
> > > would these rotation ones belong to the image browser, and be provided
> as
> > > "custom" elements rather than named elements in the main enum?
> >
> > I thought we could to this:
> > Have a main enum with things common to the states (enum
> MainSubComponents)
> > Have an enum with things specific to a state. (enum
> > BrowseVideoModeSubComponents)
> > In that case, the rotate buttons would be part of the BrowsePictureMode
> and
> > BrowseSinglePictureMode enums?
> > Custom widgets always belong to some state, don't they?
>
> yes; what i was/am unclear on in your email was how the enums were all
> mixed
> together with both the common sub-components and the state-specific ones
> listed there.
>
They will be seperated in the real implementation.
Shared widgets will be owned by the MediaCenterState class, while state
specific widgets will be owned by the state subclasses.
>
> > >> browserGoPrevious
> > >> playerPlayPauseVideo
> > >> playerPlayPauseMusic
> > >> playerPlayPausePictures
> > >
> > > what would thse signals be used for, exactly? and why are there
> separate
> >
> > ones
> >
> > > for Video, Music, Pictures, etc?
> >
> > I thought that if the controlBar needs to tell the browser to go up one
> > levelm it needs a signal to do that and the browser needs a slot to
> accept
> > that. When we handle connecting applets between them in the
> > mediacontainment or whereever, we only have the type implemenations of
> the
> > applets available. By adding public slots and signals to the type
> classes,
> > we make sure that we do not forget reimplementing these in the actual
> > applets.
>
> ah, you mean as interface descriptions for the media center applets? sure,
> that makes sense.
>
Uff
>
> > > i think the MediaCenterState object should simply remove/hide all
> >
> > components
> >
> > > that were visible in the last state but which are not visible in the
> now-
> > > current state.
> >
> > Thats why I thought keeping a list when entering a state would be a good
> > idea.
>
> yes; but not in the state subclasses. do it in the class that owns the
> shared
> widgets so that those objects are never directly exposed.
>
Ok, as above: MediaCenterState object created by containment will own shared
widgets. There will actually not be many of these I think.
>
> > When each state object adds widgets to applets, how can the
> > MediaCenterState object know about this?
>
> what widgets to which applets?
>
That was a stupid question by me. On state change, First the shared widgets
in the MediaCenterStage will be looked at and added to the applets and than
the state specific widgets will follow. At the moment, this only concerns
the ControlBar and the InfoBar applets. The player, playlist, browser all
have the same widgets in all states. Except maybe the tab bar that we want
to add to the browser.
Shared widgets are JumpToHomeScreen and the widgets showing the active
background modes. Probably toggle autohide buttons.
The HomeScreen widgets will belong to the homeState object.
>
> > Would this be done by having the list defined in the MediaCenterState
> > Object and the individual states would use that list.
>
> yes, i think so.
>
> > A simple public (or protected) member variable?
>
> avoid shared members, use accessors and setters. (encapsulation)
>
sorry, setters and getters FTW
>
> > > QList components =
> newState->subComponents();
> >
> > Okay, so in each State class I need a subComponents() function that
> returns
> > pointers of all subComponents needed in that state.
>
> of all the *custom* sub-components.
>
indeed
>
> > What about the general ones from the MediaCenterState class?
>
> my guess is that those are owned by the containment, and so it is the
> containment that should be managing them. the state object (subclass of
> MediaCenterState) should simply describe a layout, nothing more.
>
let's see in an actual implementation
>
> > "newState" will be replaced by the actual object that is the next stage?
>
> newState is the next state, in that example. and yes, on the next
> transition
> it would be done all over again with the new state.
>
> > > QListIterator it (m_visibleSubComponents);
> >
> > The m_VisibleSubComponents was filled on state change by the last state
> and
> > is stored in the MediaCeterState object?
>
> no, probably in the containment. there will be multiple MediaCenterState
> objects (one for each state in the machine), but only one set of
> components,
> owned by the containment.
>
true. very true.
>
> > > while (it.hasNext()) {
> > >
> > > MediaCenter::SubComponent c = it.next();
> > > if (!components.contains(c)) {
>
> small bug: this sould be:
>
> if (c >= MediaCenter::CustomSubComponent || !components.contains(c))
>
Re: Plasma Media Center and state machines
Perhaps I haven't been paying close enough attention but what is the need of the state machine? > So we can now have: >> Pictures, >> Videos, >> Audio tracks, >> Games, >> Olographic films :-) >> ... >> >> That's probably enough for now :-P >> > Your joke I think proves that it would be better not to have one. If we're going to use a plugin architecture then the whole point is that we don't know how many states we're going to have. I really think the model-view framework is our friend here and, while I don't like the visual interface, MythTV has done a good job with defining a menu system. When it all comes down to it, that's what this really is. Instead of a state machine I think it would make more sense to have layouts defined which you move to once a selection is entered. You can zoom and twirl your way there however you like.The layouts could be defined via some kind of XML schema, like MythTV, or through some other means. To illustrate my point a little better: You're at the home screen and the user selects "Pictures." You move to the picture/album browser layout where you can scroll to the album or picture that you like. Your menubar changes based on parameters defined in the plugin instead of parameters defined in the part of the program that launches the plugins. This gives the flexibility to the plugin writer to define what he/she wants without requiring changes to the main program. Thoughts? Chris ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
I'll just have to try and see how far I get with a single state machine. I think that Shan's idea could work but also think that extending things would mean writing new states for all applets. For me it seems easier to write a top level state which can direct infromation to all applets. The applets wouldn't need to know any states, they would just do what they are told. Could any new future states simply be added to the State enum in the library? Would extending it be some form of binary incompatibilty or something? Chris On Fri, Apr 2, 2010 at 10:34 AM, Alessandro Diaferia wrote: > > > 2010/4/2 Marco Martin > > On Friday 02 April 2010, Shantanu Tushar Jha wrote: >> > (My ideas, be free to kick ;) >> > >> > Hi Christophe, now I'm able to understand most of what you've >> > proposed. Somehow, I don't like having just one state machine for the >> > whole MC, the main reason being that we're going to support >> > extensibility through custom plugins, so the MC can no longer assume >> > that it knows exactly how many states are present. >> > What I propose is not altering the libraries, but to have a state >> > machine for each component (component as in the containment, >> > controller applet etc). Though I don't have code to show that right >> > now (i'm writing a small Qt app to demo it), I'll try to explain a >> > sample working- >> >> While i share the concern over extesibility (and wouldn't know how to do >> it >> with a single global state machine) how a state machine for each component >> would fix that? >> a part every plugin being a omplete set of new applets... >> >> Cheers, >> Marco Martin >> ___ >> Plasma-devel mailing list >> Plasma-devel@kde.org >> https://mail.kde.org/mailman/listinfo/plasma-devel >> > > I like the extensibility idea too but i think that we are bound to the > definition of a set of possible states. We can try to look forward as much > as we can and define such states. Plugins will just specify which of those > states they'll refer to. In the future, probably, we'll update our libraries > with the states that we could have never imagined in the past :-). > > So we can now have: > Pictures, > Videos, > Audio tracks, > Games, > Olographic films :-) > ... > > That's probably enough for now :-P > > Cheers > > -- > Alessandro Diaferia > KDE Developer > KDE e.V. member > > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 21:28:38 Detlev Casanova wrote: > On Thursday 01 April 2010 18:13:09 Will Stephenson wrote: > > On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote: > > > What do you think ? > > > > All great features, but you should look at > > http://techbase.kde.org/Projects/Plasma/ScreenManagement > > Well, that's almost exactly what I had in mind :-) > > > http://aike.me/site/blog/20090407/multihead_in_kde_422 > > This is more like a bug fixes list. But I see the idea of improving > multihead management is at least 1 year old. That was Aike (the previous GSoC student)'s introduction. > > http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/ > > I'll have a look at it, but it seems to be exactly what I wanted to do. It doesn't _do_ everything it claims to do though. > > http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/ > > So you think another plasma widget than the device notifier should be used > for monitors ? Is the Device Notifier widget only for mass storage devices > ? I didn't say anything, just pointing out Aike's prototype UI plasmoid. I think these events should be displayed using Device Notifier. > > This was already the subject of a GSoC project in 2008, which was > > successful but stopped short of applying policies to restore previous > > configuration, doing KNotifications or events or providing UI to edit > > configurations. > > > > KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some > > SUSE patches to launch an improved version of the KRandR KCM, and does > > not use Kephal. > > But couldn't KRandR use Kephal eventually ? Yes. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Friday 02 April 2010 00:09:01 Björn Ruberg wrote: > > I have to check the difference between "Monitor", "Screen", "Display" and > > "Head" or are those actually the same thing ? > > "Monitor", "Display" and "Head" are probably the same - in Kephal they are > named as "Output". "Screen" ist actually something different. A screen can > have several outputs ordered left to right. If you have two monitors with > 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels > and two outputs in it. One at position 0x0 and one at 1600x0. Aike, could you shed some light on this question? Or Aaron, if you have the overview of how Kephal works from mentoring Aike? Björn's description matches the xrandr model, but not the Kephal one. Xrandr 1.3 has a single Screen numbered 0 but does not support additional Screens; xrandr Screens are distinct from the screennumber in X's $DISPLAY, and multiple Screen support is being discussed again for xrandr 1.4 according to one of our local Xorg guys. Kephal has both multiple Outputs and multiple Screens in its model. A screen owns zero or more Outputs, But it also seems that one Screen per output is created, looking at the usage of Kephal in KRunner, Plasma and KWin, which iterate, because they iterate the screens, react to screen added/removed signals, and use screen ids for panel and popup placement. If this is the case I'm not sure why there are both Screens and Outputs. Perhaps it's future-proofing for when xrandr supports multiple Screens. But if that is true, I don't know why Plasma and KWin react to Screen changes but not Output changes. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Prefetching in Comic Strip plasmoid
> On 2010-04-01 21:33:03, Matthias Fuchs wrote: > > Ok, I tried it now and it works great! Fantastic addition, really makes > > reading some comics more comfortable. > > Go on and commit it :) -- unless if you have no svn account then please > > write that here. > > Miha Cancula wrote: > Thank you :) > And no, I don't have an account, so I have to ask that you or someone > else do it. Ok, comitted it, it is in r1110194, so that feature will be included with 4.5. - Matthias --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2636/#review4848 --- On 2010-01-25 10:19:38, Miha Cancula wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2636/ > --- > > (Updated 2010-01-25 10:19:38) > > > Review request for Plasma and Matthias Fuchs. > > > Summary > --- > > When a new strip is loaded, it caches both the previous and the next one, > without interfering with the currently displayed comic. This is very useful > if you're reading throug a particular comic, especially on slower > connections. It's a two-line patch, but it greatly improves the experience > for this use-case. Caching is done by the DataEngine, so no further > modifications were needed. > > After a discussion in the mailing list, the decision was to have no > configuration for this, as the cost of downloading a single picture is qiute > low. > > > Diffs > - > > /trunk/KDE/kdeplasma-addons/applets/comic/comic.cpp 1075738 > > Diff: http://reviewboard.kde.org/r/2636/diff > > > Testing > --- > > I tested it on my Ubuntu machine with todays trunk. It works as expected, and > I haven't noticed any regressions. > > > Thanks, > > Miha > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Thursday 01 April 2010 20:07:14 Chani wrote: > On April 1, 2010 09:40:12 Björn Ruberg wrote: > > Hello, > > > > I fully agree with Detlev's points. The multiscreen management is very > > bad in KDE currently, although in KDE 4.4 it is a little better than in > > KDE 4.3. Every time I want to plug a beamer to my laptop in university I > > have to fight up to one minute getting every thing correct > > I have *very* little experience with multiscreen, but... how much of this > is a distro or driver thing? Distro/driver is not important; the multiscreen features discussed above are simply missing even with a perfect driver/distro combination. > when I plugged my tv into my laptop running > arch, the video seemed to Just Work - I opened up krandr, set the new > screen to the first resolution and there it was. later I thought maybe I > wanted the other screen on top, so I tried that, and it worked too. > > when I tried the netbook reference thing, though, it didn't really want to > obey the settings I chose. it just wanted to clone the laptop screen onto > the tv screen. weird stuff happened as I fought with it... :/ > > I'm not saying multiscreen is in a *good* state, just that I had two very > different experiences on different distros. The intel driver can cause this behaviour, since contemporary releases of different distros ship different X servers *and* different intel drivers, and intel's feature set varies from release to release. The intel driver in the openSUSE 11.2 build of Plasma Netbook Reference Platform is especially bad at detecting the correct native monitor resolution from the EDID. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
2010/4/2 Marco Martin > On Friday 02 April 2010, Shantanu Tushar Jha wrote: > > (My ideas, be free to kick ;) > > > > Hi Christophe, now I'm able to understand most of what you've > > proposed. Somehow, I don't like having just one state machine for the > > whole MC, the main reason being that we're going to support > > extensibility through custom plugins, so the MC can no longer assume > > that it knows exactly how many states are present. > > What I propose is not altering the libraries, but to have a state > > machine for each component (component as in the containment, > > controller applet etc). Though I don't have code to show that right > > now (i'm writing a small Qt app to demo it), I'll try to explain a > > sample working- > > While i share the concern over extesibility (and wouldn't know how to do it > with a single global state machine) how a state machine for each component > would fix that? > a part every plugin being a omplete set of new applets... > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > I like the extensibility idea too but i think that we are bound to the definition of a set of possible states. We can try to look forward as much as we can and define such states. Plugins will just specify which of those states they'll refer to. In the future, probably, we'll update our libraries with the states that we could have never imagined in the past :-). So we can now have: Pictures, Videos, Audio tracks, Games, Olographic films :-) ... That's probably enough for now :-P Cheers -- Alessandro Diaferia KDE Developer KDE e.V. member ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Media Center and state machines
On Friday 02 April 2010, Shantanu Tushar Jha wrote: > (My ideas, be free to kick ;) > > Hi Christophe, now I'm able to understand most of what you've > proposed. Somehow, I don't like having just one state machine for the > whole MC, the main reason being that we're going to support > extensibility through custom plugins, so the MC can no longer assume > that it knows exactly how many states are present. > What I propose is not altering the libraries, but to have a state > machine for each component (component as in the containment, > controller applet etc). Though I don't have code to show that right > now (i'm writing a small Qt app to demo it), I'll try to explain a > sample working- While i share the concern over extesibility (and wouldn't know how to do it with a single global state machine) how a state machine for each component would fix that? a part every plugin being a omplete set of new applets... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Prefetching in Comic Strip plasmoid
> On 2010-04-01 21:33:03, Matthias Fuchs wrote: > > Ok, I tried it now and it works great! Fantastic addition, really makes > > reading some comics more comfortable. > > Go on and commit it :) -- unless if you have no svn account then please > > write that here. Thank you :) And no, I don't have an account, so I have to ask that you or someone else do it. - Miha --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2636/#review4848 --- On 2010-01-25 10:19:38, Miha Cancula wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2636/ > --- > > (Updated 2010-01-25 10:19:38) > > > Review request for Plasma and Matthias Fuchs. > > > Summary > --- > > When a new strip is loaded, it caches both the previous and the next one, > without interfering with the currently displayed comic. This is very useful > if you're reading throug a particular comic, especially on slower > connections. It's a two-line patch, but it greatly improves the experience > for this use-case. Caching is done by the DataEngine, so no further > modifications were needed. > > After a discussion in the mailing list, the decision was to have no > configuration for this, as the cost of downloading a single picture is qiute > low. > > > Diffs > - > > /trunk/KDE/kdeplasma-addons/applets/comic/comic.cpp 1075738 > > Diff: http://reviewboard.kde.org/r/2636/diff > > > Testing > --- > > I tested it on my Ubuntu machine with todays trunk. It works as expected, and > I haven't noticed any regressions. > > > Thanks, > > Miha > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
