Calculator

[Matteo Agostinelli]

Hi,

I am currently working on improving the calculator runner, by adding an 
optional dependency on libqalculate. If the library is found, the calculator 
runner will be built against libqalculate and it will support "advanced" 
operations (such as currency conversion, unit conversion, equation solving, 
...). Otherwise it will fall back to the existing code that uses QtScript. I 
have tested the runner for some weeks now and it is stable.

I would like to hear some opinions about these points:
- currently there are two calculator plasmoids, with and without libqalculate 
support (btw I am the author of the qalculate one). I think that we could use 
a similar approach here as with the runner, i.e. have a unified calculator 
plasmoid that optionally depends on libqalculate.

- a Qalculate backend for Cantor is currently in playground (not developed by 
me). It is already quite stable and I think It would be nice to have it 
included in SC 4.5.

- one problem is that the runner, applet and Cantor backend have some 
duplicate code (e.g. evaluation options, support for QString, ...). As Aaron 
suggested some time ago, maybe it is worth it to add a wrapper library for 
libqalculate use in KDE (something like libkdeqalculate, feel free to suggest 
a nicer name ;). Where should this library be placed? Would 
kdebase/workspace/libs be an appropriate place?

Of course I volunteer to take care of these tasks before 4.5 freeze ;)

Thanks for your attention,
Matteo


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

GSoC : Multiscreen management

[Detlev Casanova]

Hello folks !

I'd like to work with you this summer (and even longer after that :-) ).
So, there's something in KDE that I find not really nice, It's the multiscreen 
management.
For instance, I have an extra monitor for my laptop which I use every day but 
I also unplug it every day. The problem is that the screen configuration is 
never kept and sometimes, the screen is deactivated and KRandr says the screen 
is configured in 1980x1200...

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.

In KRandr, there should be a possibility to keep configurations depending on 
the plugged device :
I'd like the university projector to be on the right of my laptop 
screen.
I'd like my 26" screen to be a clone of my laptop screen.

If a configuration exists for a monitor when it's plugged in, the configuration 
should directly be applied with the monitor entry still in the device notifier 
(so that it can be modified).

KRandr could also be more handy : the view could be used to move screens to 
place them at the wanted position (like a widget is moved on the desktop).

What do you think ?

I already posted the idea on #plasma but had to leave before you could answer 
so, it might feel familiar.

I know though that there are problems with xrandr and some drivers, like the 
NVidia driver. I'm not sure how big are the problems but interfacing with the 
NVidia tools is maybe possible.

Cheers,

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

[todd rme]

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.

I might also suggest a quick-config system that allows you to select
common configurations (display 1 only, display 2 only, clone displays,
side-by-side).  This could also be triggered with the laptop's "change
screen configuration" keyboard combo (often Fn+F#, where F# is an
F1-F12 key that depends on the laptop).

> In KRandr, there should be a possibility to keep configurations depending on
> the plugged device :
>        I'd like the university projector to be on the right of my laptop 
> screen.
>        I'd like my 26" screen to be a clone of my laptop screen.

This would be extremely useful.

> I know though that there are problems with xrandr and some drivers, like the
> NVidia driver. I'm not sure how big are the problems but interfacing with the
> NVidia tools is maybe possible.

The size of the problem is basically "NVidia does not support randr at
all and may never support it."  They have been promising for years
that it is a has-priority task and that it is coming very soon, but
late last year they admitted that it wasn't actually ever a priority
and there are no real firm plans to implement it ever and there never
were.  So if you want support for nvidia cards you will need to
integrate with NVidia's own tools.  There is a third-party
command-line tool called disper that is supposed to replicate some of
the features that randr has: http://willem.engen.nl/projects/disper/

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Will Stephenson]

On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote:
> I'd like to work with you this summer (and even longer after that :-) ).
> So, there's something in KDE that I find not really nice, It's the
> multiscreen management.
> For instance, I have an extra monitor for my laptop which I use every day
> but I also unplug it every day. The problem is that the screen
> configuration is never kept and sometimes, the screen is deactivated and
> KRandr says the screen is configured in 1980x1200...
> 
> 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.
> 
> In KRandr, there should be a possibility to keep configurations depending
> on the plugged device :
>   I'd like the university projector to be on the right of my laptop 
> screen.
>   I'd like my 26" screen to be a clone of my laptop screen.
> 
> If a configuration exists for a monitor when it's plugged in, the
> configuration should directly be applied with the monitor entry still in
> the device notifier (so that it can be modified).
> 
> KRandr could also be more handy : the view could be used to move screens to
> place them at the wanted position (like a widget is moved on the desktop).
> 
> What do you think ?

All great features, but you should look at  
http://techbase.kde.org/Projects/Plasma/ScreenManagement
http://aike.me/site/blog/20090407/multihead_in_kde_422
http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/
http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/

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.

I feel the same itch as you do and have spent the last couple of days getting 
into the Kephal code - it's been hardly touched since 2008 and could do with a 
clean up, so I'll see how far I get with it over the weekend.  

Aaron, do you think there's another GSoC project in completing Kephal?

> I already posted the idea on #plasma but had to leave before you could
> answer so, it might feel familiar.
> 
> I know though that there are problems with xrandr and some drivers, like
> the NVidia driver. I'm not sure how big are the problems but interfacing
> with the NVidia tools is maybe possible.

I know the disper tool tries to abstract both systems, but haven't used it.

Will
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Asraniel]

Hei, i would just like to add my support for that idea, because as of kde 4.4, 
my second screen has no more wallpaper (plasma) and if i set dragonplayer to 
fullscreen on it, it goes to the first screen (kwin?). this is sadly with the 
nvidia driver.

It would be great to have a more robust multiscreen support. Even if this is 
probably not the scope of the project, there are quite alot of plasma 
bugreports about multiscreen bugs, perhaps a few might get fixed during that 
project?

greetings

beat wolf

Am Donnerstag 01 April 2010 16.35:59 schrieb Detlev Casanova:
> Hello folks !
> 
> I'd like to work with you this summer (and even longer after that :-) ).
> So, there's something in KDE that I find not really nice, It's the
> multiscreen management.
> For instance, I have an extra monitor for my laptop which I use every day
> but I also unplug it every day. The problem is that the screen
> configuration is never kept and sometimes, the screen is deactivated and
> KRandr says the screen is configured in 1980x1200...
> 
> 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.
> 
> In KRandr, there should be a possibility to keep configurations depending
> on the plugged device :
>   I'd like the university projector to be on the right of my laptop 
> screen.
>   I'd like my 26" screen to be a clone of my laptop screen.
> 
> If a configuration exists for a monitor when it's plugged in, the
> configuration should directly be applied with the monitor entry still in
> the device notifier (so that it can be modified).
> 
> KRandr could also be more handy : the view could be used to move screens to
> place them at the wanted position (like a widget is moved on the desktop).
> 
> What do you think ?
> 
> I already posted the idea on #plasma but had to leave before you could
> answer so, it might feel familiar.
> 
> I know though that there are problems with xrandr and some drivers, like
> the NVidia driver. I'm not sure how big are the problems but interfacing
> with the NVidia tools is maybe possible.
> 
> Cheers,
> 
> Detlev.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Björn Ruberg]

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 - and the other students using 
MacOS or Windows laugh at me. KDE and Linux makes no good impression 
concerning multi screens - and that is no "special" feature but one that is 
much needed everywhere and everyday.

The problem for me is not the intel-driver. I can get everything as I want 
with xrandr. It is a interface problem!

I wrote some mails about this on kde-devel half a year ago and wanted to do a 
plasmoid myself. Sadly I have not the free time to do such a project on my own 
as long the underlying libarys are not in better shape. My own screen 
management plasmoid is here:
http://websvn.kde.org/trunk/playground/base/plasma/applets/screen_control/
Add this to Wills list of related work :)

It uses Kephal just for reading in data - for actually changing anything it 
makes command line calls to xrandr. That may sound ugly but it works - at 
least it works much better than kephal does in changing screen configuration.

If Kephal would not only be useable for finding out your screen configuration 
but could actually change it, I'm quite confident I would bring this applet in 
a good and working shape. So, it would be great if Kephal could become a GSOC 
project. Even if proprietary nvidia drivers would not work (what may be worked 
around by an abstraction layer) it would be a great improvement. In the 
current state you have no good time with multiple screens in KDE with any 
driver you can use.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Media Center and state machines

[Christophe Olinger]

Hallo everybody,

Since I am still realy new to Qt, plasma and KDE, I made a small draft
of how I would imagine handling implemeting state machines in the PMC
code.
Please feel very free on adding and commenting ideas, and pointing out
stupid things. Marco and Aaron were already so nice to give me a small
nudge in the hopefully right direction.

Thanks all,

Chris (aka binarylooks)
___

1) the top level libs (mediacenter.h) class knows about which types of
applets (=UIComponents) exist and which states exist

Example:
enum State {
BrowseVideos;
PlayVideos;
PlayMusic;
MusicVisualizations;
BrowsePictures;
SinglePictures;
PicturesSlideshow;
}

enum UIComponent {
ControlBar;
InfoBar;
Browser;
Player;
Playlist;
HomeScreen;
}
_

2) there is a MediaCenterState class which keeps track of all possible
smallwidgets (=subComponents) for the whole PMC and can hand out
pointers to them.
(Maybe the state objects can do that for the widgets that are needed
in their state)

Example:
enum subComponent {
iconVideoMode;
iconMusciMode;
iconPictureMode;
iconHomeScreen;
iconTogglePlaylistAutohide;
iconToggleControlBarAutohide;
iconToggleInfoBarAutohide;
iconVideoModePlayPause;
iconVideoModeSkipForward;
iconVideoModeSkipBackward;
iconVideoModeStop;
iconMusicModePlayPause;
iconMusicModeSkipForward;
iconMusicModeSkipBackward;
iconMusicModeStop;
sliderMusicModeVolume;
sliderMusicModeSeek;
iconSlideshow;
iconRotateCW;
iconRotateCCW;
...
}

class MEDIACENTER_EXPORT MediaCenterState(QObject *parent)
: QAbstractState(parent)
m_iconVideosMode(new Plasma::IconWidget(this))
//initialize all of them
{
}

//here we handle the pointers of the created objects (the enum,
initialilzation and pointer handling could be in the actual subclass
of the state objects
QGraphicsWidget
*BrowseVideoState::giveComponent(MediaCenter::subComponent component)
{
   if (component == iconVideoMode) {
   m_videoModeWidget->setIcon("bla");
   return m_videoModeWidget;
   }
}
_

3) there will be subclasses (like BrowseVideoState) of the above class
that can handle each mode
_



4) The MediaContainment starts the state machine

Example:
//Prepare StateMachine
QStateMachine machine; //this is not a pointer

//Set up all possible states
MediaCenterState mediaCenterState = new MediaCenterState(); //these are pointers
VideoBrowserState videoBrowserState = new VideoBrowserState(mediaCenterState);

//Define state change buttons
mediaCenterState->addTransition(m_control,
SIGNAL(switchToVideoBrowseState()), videoBrowseState);
mediaCenterState->addTransition(m_control,
SIGNAL(switchToPicturesBrowseState()), pictureBrowseState);

//Define other signals for state change
mediaCenterState->addTransition(player, SIGNAL(slideshowStopped()),
pictureBrowseState);

//Setup and start statemachine
machine.addState(mediaCenterState); //this is our toplevel state
mediaCenterState->setInitialState(videoBrowserState); //set this to
the homescreen state eventually
machine.start();

_


5) these sublasses will be used by the MediaContainment to create state objects
The mediacontainment initiates state switches while handing pointers
of the UIComponents to the state objects

Example:
QList uiComponentsList; //pointer will be
added in the setApplet functions

_

6) the state objects (i.e. BrowseVideoState) use the pointers of the
UIComponents to tell them to add subComponents to them
They also configure the UIComponents. This all happens on state change
(enter and exit methods)
The pointers of the subComponents are either created in each state
class, or they are created and handed out by another class (maybe
MediaCenterState).

Example of functions to be reimplemented:
assignPoperty(Object, "property", "value")
invokeMethodOnEntry(this, "method")

Example of code:
void BrowseVideoState::invokeOnEntry(QList list)
{
For each UIComponent in list {
if (UIComponent == "ControlBar") {
subComponentsList.clear();
subComponentsList <<
addSubComponent(MediaCenterState::giveComponent(MediaCenter::iconVideoMode));
subComponentsList <<
addSubComponent(MediaCenterState::giveComponent(MediaCenter::iconPictureMode));
...//add all widgets
configure UIComponent (show, hide, autohide,...)
}
if UIComponent = "InfolBar" {
...//add widgets
}
...//treat all UIComponents
}
}

void BrowseVideoState::exit() {
For each UIComponent in list {
if (UIComponent == "ControlBar") {
UIComponent->removeSubComponents(subComponentsList);
}
}
}
_

7) The type definitions of the UIComponents in the libs
(playb

Re: GSoC : Multiscreen management

[Chani]

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? 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.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


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: Calculator

[Aaron J. Seigo]

On April 1, 2010, you wrote:
> Hi,
> 
> I am currently working on improving the calculator runner, by adding an
> optional dependency on libqalculate. If the library is found, the
> calculator runner will be built against libqalculate and it will support
> "advanced" operations (such as currency conversion, unit conversion,
> equation solving, ...). Otherwise it will fall back to the existing code
> that uses QtScript. I have tested the runner for some weeks now and it is
> stable.

great; can you post a patch to review-board for this so we can triage it in 
asap?

> I would like to hear some opinions about these points:
> - currently there are two calculator plasmoids, with and without
> libqalculate support (btw I am the author of the qalculate one). I think
> that we could use a similar approach here as with the runner, i.e. have a
> unified calculator plasmoid that optionally depends on libqalculate.

agreed

> - a Qalculate backend for Cantor is currently in playground (not developed
> by me). It is already quite stable and I think It would be nice to have it
> included in SC 4.5.
> 
> - one problem is that the runner, applet and Cantor backend have some
> duplicate code (e.g. evaluation options, support for QString, ...). As
> Aaron suggested some time ago, maybe it is worth it to add a wrapper
> library for libqalculate use in KDE (something like libkdeqalculate, feel
> free to suggest a nicer name ;). Where should this library be placed?
> Would
> kdebase/workspace/libs be an appropriate place?

only if it is used by things in kdebase-workspace alone. otherwise, i'd 
recommend kdesupport and ship it as a separate library.

> Of course I volunteer to take care of these tasks before 4.5 freeze ;)

terrific :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Aaron J. Seigo]

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)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Media Center and state machines

[Christophe Olinger]

>From Aaron:

> //This class knows about things that are important for every toplevel
> thing needed in the MediaCenter like
>  MediaType for example
>
> enum State {
> BrowseVideos;
> PlayVideos;
> PlayMusic;
> MusicVisualizations;
> BrowsePictures;
> SinglePictures;
> PicturesSlideshow;
> }

is this enum really needed? it's really only something the state machine needs
to know about.

the only thing that needs to get at this would be the Home Page (or whatever
it's being called :), but if that was also part of the state machine system
then the states could quite easily just add themselves to the home page.

> //Not sure if we need this enum
> enum playbackState {
> Playing;
> Paused;
> Stopped;
> }

maybe just playing/paused as a global setting. this is probably separate from
the state machine work, however.

> Important: The main MediaCenter lib knwos which types of UIComponents
> exist. If we add a new type, it needs to be included here

correct..

> 
>
> ***MediaCenterState (subclass of QAbstractState)***
>
> //This class allows for the MediaCenter to have states. In here we
> have only things that are needed for the containment to do its work.
> It also hands out pointers to widgets
> //It also keeps a collection of all subComponents needed within all
> states (maybe each state should keep its own subcomponents instead)
> // the problem would be that if we change between states that have the
> same subComponents, we would delete and recreate them?)
>
>
> #include "mediacenter.h"
> #include "mediacenter_export.h"
>
> namespace MediaCenter
> {
>
> enum subComponent {
> iconVideoMode;

small detail: the first letter should be capitalized as well. also, instead of
pepending "icon", "slider", etc. i'd recommend just stating what it does.
"JumpToVideoMode", "MusicModeVolume". that way if we switch the actual UI
elements that accomplish these tasks, we don't end up with odd / outdated
enums :)

> iconMusciMode;
> iconPictureMode;
> iconHomeScreen;
> iconTogglePlaylistAutohide;
> iconToggleControlBarAutohide;
> iconToggleInfoBarAutohide;
> iconVideoModePlayPause;
> iconVideoModeSkipForward;
> iconVideoModeSkipBackward;
> iconVideoModeStop;
> iconMusicModePlayPause;
> iconMusicModeSkipForward;
> iconMusicModeSkipBackward;
> iconMusicModeStop;
> sliderMusicModeVolume;
> 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?

> //here we handle the pointers of the created objects (the enum,
> initialilzation and pointer handling could be in the actual subclass
> of the state objects? makes it easier to add modes/plugins?)
>
> QGraphicsWidget
> *BrowseVideoState::giveComponent(MediaCenter::subComponent component)

should probably be createComponent(..) or just component(..)

> {
>if (component == iconVideoMode) {
>
>m_videoModeWidget->setIcon("bla");
>
>return m_videoModeWidget;
>}
> }

this is probably a bad example; the standard items such as JumpToVideoMode
should be provided by the base class. it will be shared by all modes, after
all. only custom items specific to the state should be here. for instance, the
VideoState might offer (as a made up example) a channel listing display and a
button for that should appear in the top bar. in this case, that buton would
be provided by VideoState as a custom item.

> }//ending namesapce MediaCenter
>
> __
>
> ***PlaybackControl (=ControlBar)***
> //This class defines what an actual implementation of a controlbar
> needs to be able to do
>
> //When adding a subComponent we need to return it. This is necessary
> to keep a track of them in a list in the state object
> MediaCenter::subComponent addSubComponent(MediaCenter::SubComponent)
> {
> }
>
> //This class gets the exact pointers of who do remove in a list
> void
> removeSubComponents(MediaCenter::SubComponent(QList ents>) {
> }



> //these are all empty classes
>
> Important: The correct public slots and signals need to exist and
> reimplememted in the actual applet.
>
> signals
> browserGoPrevious
> playerPlayPauseVideo
> playerPlayPauseMusic
> playerPlayPausePictures

what would thse signals be used for, exactly? and why are there separate ones
for Video, Music, Pictures, etc?
- Show quoted text -
why is a subComponentList needed? should the definition of which components to
show be done in the constructor instead, and only action taken to reflect that
in the actual UI done in the enter event? if there are multiple possible
states for a mode, then those could be child states, which would make it such
that each state object would represent one configuration of widgets which
wouldn't change within that state object.

> subCompone

Re: GSoC : Multiscreen management

[Aaron J. Seigo]

On April 1, 2010, Asraniel wrote:
> Hei, i would just like to add my support for that idea, because as of kde
> 4.4, my second screen has no more wallpaper (plasma) and if i set

dual head? or is the second screen just not being seen at all? can you provide 
some debug output from plasma-desktop regarding the scren setup process?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Containment view

[todd rme]

As discussed earlier, I am working on the containment viewer
application, which will allow people to test-run containments in a
similar manner to the plasmoid viewer.  It already supports changing
the size of the containment, both with a hard-coded list of common
screen resolutions and the ability to change the resolution to
arbitrary values (which should be useful for things like smartphones,
which can have unusual resolutions).  The code is still fairly ugly,
but it loads, successfully displays a containment, and successfully
changes the containment's size.

The one thing that is not working is the add widgets dialog.  I get a
crash whenever I hit the add widgets buttons in the window, and the
add widgets button in the containment does nothing.  I cannot figure
out why, and was hoping I could get some help.  However, I don't know
the best way to go about getting help on this matter.  Should I attach
the crash report to an email?  Just attach the whole source code to an
email?  Put some particular snipets in the body of an email?  Meet at
some time on IRC?  Something else entirely?

Thanks for your help.

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Containment view

[Aaron J. Seigo]

On April 1, 2010, todd rme wrote:
> the best way to go about getting help on this matter.  Should I attach
> the crash report to an email? 

yes

> Just attach the whole source code to an email? 

no; that's what svn is for :)

> Put some particular snipets in the body of an email?  Meet at
> some time on IRC?

both are fine. you can find us in #plasma :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Containment view

[Guillaume DE BURE]

Le jeudi 01 avril 2010 20:19:30, todd rme a écrit :
> As discussed earlier, I am working on the containment viewer
> application, which will allow people to test-run containments in a
> similar manner to the plasmoid viewer.

I am very interested by this, it might prove very useful for Skrooge (See our 
GSOC idea : 
http://community.kde.org/GSoC/2010/Ideas#Plasma_Dashboard_in_Skrooge).

Where can I find the code ?

Thanks,

Guillaume

-- 
Skrooge, a personal finances manager powered by KDE 4.x 
http://skrooge.org 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Detlev Casanova]

On Thursday 01 April 2010 18:13:09 Will Stephenson wrote:
> On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote:
> > I'd like to work with you this summer (and even longer after that :-) ).
> > So, there's something in KDE that I find not really nice, It's the
> > multiscreen management.
> > For instance, I have an extra monitor for my laptop which I use every day
> > but I also unplug it every day. The problem is that the screen
> > configuration is never kept and sometimes, the screen is deactivated and
> > KRandr says the screen is configured in 1980x1200...
> > 
> > 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.
> > 
> > In KRandr, there should be a possibility to keep configurations depending
> > 
> > on the plugged device :
> > I'd like the university projector to be on the right of my laptop
> > screen. I'd like my 26" screen to be a clone of my laptop screen.
> > 
> > If a configuration exists for a monitor when it's plugged in, the
> > configuration should directly be applied with the monitor entry still in
> > the device notifier (so that it can be modified).
> > 
> > KRandr could also be more handy : the view could be used to move screens
> > to place them at the wanted position (like a widget is moved on the
> > desktop).
> > 
> > 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.

> 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.

> 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 ?
 
> 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 ?

> I feel the same itch as you do and have spent the last couple of days
> getting into the Kephal code - it's been hardly touched since 2008 and
> could do with a clean up, so I'll see how far I get with it over the
> weekend.
> 
> Aaron, do you think there's another GSoC project in completing Kephal?
> 
> > I already posted the idea on #plasma but had to leave before you could
> > answer so, it might feel familiar.
> > 
> > I know though that there are problems with xrandr and some drivers, like
> > the NVidia driver. I'm not sure how big are the problems but interfacing
> > with the NVidia tools is maybe possible.
> 
> I know the disper tool tries to abstract both systems, but haven't used it.

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: Containment view

[todd rme]

On Thu, Apr 1, 2010 at 3:04 PM, Guillaume DE BURE
 wrote:
> Le jeudi 01 avril 2010 20:19:30, todd rme a écrit :
>> As discussed earlier, I am working on the containment viewer
>> application, which will allow people to test-run containments in a
>> similar manner to the plasmoid viewer.
>
> I am very interested by this, it might prove very useful for Skrooge (See our 
> GSOC idea : 
> http://community.kde.org/GSoC/2010/Ideas#Plasma_Dashboard_in_Skrooge).
>
> Where can I find the code ?
>
> Thanks,
>
> Guillaume

Currently, on my hard drive.  I don't have svn access.

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Detlev Casanova]

On Thursday 01 April 2010 18: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 - and the other
> students using MacOS or Windows laugh at me. KDE and Linux makes no good
> impression concerning multi screens - and that is no "special" feature but
> one that is much needed everywhere and everyday.

Yes, I've had that problem.

> The problem for me is not the intel-driver. I can get everything as I want
> with xrandr. It is a interface problem!
> 
> I wrote some mails about this on kde-devel half a year ago and wanted to do
> a plasmoid myself. Sadly I have not the free time to do such a project on
> my own as long the underlying libarys are not in better shape. My own
> screen management plasmoid is here:
> http://websvn.kde.org/trunk/playground/base/plasma/applets/screen_control/
> Add this to Wills list of related work :)

I'm not sure having multiple places where you can configure the same thing is a 
good idea. Also, I think that Plasma Widgets shouldn't be configuration 
interfaces. But it's only what I think, and people usually love widgets on 
theyr desktop :)

> It uses Kephal just for reading in data - for actually changing anything it
> makes command line calls to xrandr. That may sound ugly but it works - at
> least it works much better than kephal does in changing screen
> configuration.
> 
> If Kephal would not only be useable for finding out your screen
> configuration but could actually change it, I'm quite confident I would
> bring this applet in a good and working shape.

Centralizing everything in on library (Kephal for instance), is IMHO a good 
idea. 

> So, it would be great if
> Kephal could become a GSOC project.

I think so too :-)

> Even if proprietary nvidia drivers
> would not work (what may be worked around by an abstraction layer) it
> would be a great improvement. In the current state you have no good time
> with multiple screens in KDE with any driver you can use.

It would be great to have something that works with friendly drivers first. 


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: Containment view

[todd rme]

On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
> On April 1, 2010, todd rme wrote:
>> the best way to go about getting help on this matter.  Should I attach
>> the crash report to an email?
>
> yes


Here it is.

-Todd


containmentviewer-20100401-153632.kcrash
Description: Binary data
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Detlev Casanova]

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)

I also recently found some bugs with that icon (apparently not always showing 
all plugged in monitors to configure them)

I have to check the difference between "Monitor", "Screen", "Display" and 
"Head" or are those actually the same thing ?

I'm obviously really interested in that project, that's how I thought things 
should work except that I did not know about Kephal (even though I remember 
hearing about it but not really care at that time)

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: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag & drop marker.

[Ingomar Wesp]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3358/
---

(Updated 2010-04-01 20:01:41.294461)


Review request for Plasma.


Changes
---

Changes as discussed on plasma-devel:

* Improved the appearance of the drop marker.
* Added a placeholder that is displayed when an icon area is empty.
* Replaced the configuration setting "visible icons" with something like 
  "enable popup" (suggestions for better wording welcome ;)

Is there anything important I should take into consideration when introducing
new user visible strings?


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 serialized into a single lis

Re: Plasma Media Center and state machines

[Christophe Olinger]

Replies inline,

Adapted workflow at the end of this message.

(I think its almost time to start coding this)


On Thu, Apr 1, 2010 at 8:16 PM, Christophe Olinger 
wrote:
> From Aaron:
>
>> //This class knows about things that are important for every toplevel
>> thing needed in the MediaCenter like
>>  MediaType for example
>>
>> enum State {
>> BrowseVideos;
>> PlayVideos;
>> PlayMusic;
>> MusicVisualizations;
>> BrowsePictures;
>> SinglePictures;
>> PicturesSlideshow;
>> }
>
> is this enum really needed? it's really only something the state machine
needs
> to know about.

moved to the MediaCenterState class

>
> the only thing that needs to get at this would be the Home Page (or
whatever
> it's being called :), but if that was also part of the state machine
system
> then the states could quite easily just add themselves to the home page.
>
>> //Not sure if we need this enum
>> enum playbackState {
>> Playing;
>> Paused;
>> Stopped;
>> }
>
> maybe just playing/paused as a global setting. this is probably separate
from
> the state machine work, however.

will remove the stopped state eventually

>
>> Important: The main MediaCenter lib knwos which types of UIComponents
>> exist. If we add a new type, it needs to be included here
>
> correct..
>
>> 
>>
>> ***MediaCenterState (subclass of QAbstractState)***
>>
>> //This class allows for the MediaCenter to have states. In here we
>> have only things that are needed for the containment to do its work.
>> It also hands out pointers to widgets
>> //It also keeps a collection of all subComponents needed within all
>> states (maybe each state should keep its own subcomponents instead)
>> // the problem would be that if we change between states that have the
>> same subComponents, we would delete and recreate them?)
>>
>>
>> #include "mediacenter.h"
>> #include "mediacenter_export.h"
>>
>> namespace MediaCenter
>> {
>>
>> enum subComponent {
>> iconVideoMode;
>
> small detail: the first letter should be capitalized as well. also,
instead of
> pepending "icon", "slider", etc. i'd recommend just stating what it does.
> "JumpToVideoMode", "MusicModeVolume". that way if we switch the actual UI
> elements that accomplish these tasks, we don't end up with odd / outdated
> enums :)

will do.

>
>> iconMusciMode;
>> iconPictureMode;
>> iconHomeScreen;
>> iconTogglePlaylistAutohide;
>> iconToggleControlBarAutohide;
>> iconToggleInfoBarAutohide;
>> iconVideoModePlayPause;
>> iconVideoModeSkipForward;
>> iconVideoModeSkipBackward;
>> iconVideoModeStop;
>> iconMusicModePlayPause;
>> iconMusicModeSkipForward;
>> iconMusicModeSkipBackward;
>> iconMusicModeStop;
>> sliderMusicModeVolume;
>> 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?

>
>> //here we handle the pointers of the created objects (the enum,
>> initialilzation and pointer handling could be in the actual subclass
>> of the state objects? makes it easier to add modes/plugins?)
>>
>> QGraphicsWidget
>> *BrowseVideoState::giveComponent(MediaCenter::subComponent component)
>
> should probably be createComponent(..) or just component(..)
>
>> {
>>if (component == iconVideoMode) {
>>
>>m_videoModeWidget->setIcon("bla");
>>
>>return m_videoModeWidget;
>>}
>> }
>
> this is probably a bad example; the standard items such as JumpToVideoMode
> should be provided by the base class. it will be shared by all modes,
after
> all. only custom items specific to the state should be here. for instance,
the
> VideoState might offer (as a made up example) a channel listing display
and a
> button for that should appear in the top bar. in this case, that buton
would
> be provided by VideoState as a custom item.

I agree. Separation of general widgets and specific widgets will be in the
indiviual state object classes or the main MediaCenterState class.

>
>> }//ending namesapce MediaCenter
>>
>> __
>>
>> ***PlaybackControl (=ControlBar)***
>> //This class defines what an actual implementation of a controlbar
>> needs to be able to do
>>
>> //When adding a subComponent we need to return it. This is necessary
>> to keep a track of them in a list in the state object
>> MediaCenter::subComponent addSubComponent(MediaCenter::SubComponent)
>> {
>> }
>>
>> //This class gets the exact pointers of who do remove in a list

Re: Containment view

[Aaron J. Seigo]

On April 1, 2010, todd rme wrote:
> On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
> > On April 1, 2010, todd rme wrote:
> >> the best way to go about getting help on this matter.  Should I attach
> >> the crash report to an email?
> > 
> > yes
> 
> Here it is.

it's a bug and crash in Qt. what version of Qt are you using?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Containment view

[todd rme]

On Thu, Apr 1, 2010 at 4:30 PM, Aaron J. Seigo  wrote:
> On April 1, 2010, todd rme wrote:
>> On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
>> > On April 1, 2010, todd rme wrote:
>> >> the best way to go about getting help on this matter.  Should I attach
>> >> the crash report to an email?
>> >
>> > yes
>>
>> Here it is.
>
> it's a bug and crash in Qt. what version of Qt are you using?

4.6.2-107.1 (openSUSE version).  Are you sure the bug is the fault of
Qt?  The code is based on the screensaver corona's add widget dialog,
and it doesn't crash.  Neither does the desktop corona version.  I
would think that if everything else works fine, but my program
crashes, then the problem is probably in my program, right?

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Media Center and state machines

[Aaron J. Seigo]

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.

> >> 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.

> > 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.

> When each state object adds widgets to applets, how can the
> MediaCenterState object know about this?

what widgets to which applets?

> 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)

> > 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.

> 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.

> "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.
 
> > while (it.hasNext()) {
> > 
> >   MediaCenter::SubComponent c = it.next();
> >   if (!components.contains(c)) {

small bug: this sould be:

if (c >= MediaCenter::CustomSubComponent || !components.contains(c))

all custom components should be removed.

> >   
> >   MediaCenterComponent *w = m_subComponents.value(c);
> >   
> >if (w) {
> >
> > w->hide(); // TODO animate

anothe bug: w also needs to be removed from the layout.

probably time to start drafting some class headers and putt them into svn so 
we can work together from there :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: global menu bar for gsoc

[Ivan Ruchkin]

2010/3/31 Aaron J. Seigo 

> On March 30, 2010, Ivan Ruchkin wrote:
> > 2010/3/29 Aaron J. Seigo 
> >
> > > On March 28, 2010, you wrote:
> > > > My name is Ivan, I'd like to improve global Mac-OS style menu bar as
> my
> > > > GSoC project.
> > > > Can you please point me to the development code of it?
> > > > How does it corellate with XBar plasmoid?
> > >
> > > there is a fairly old start to such a plasmoid in:
> > >/trunk/playground/base/plasma/applets/menubar/
> > >
> > > it has no relation to the xbar plasmoid, which only works with bespin.
> > >
> > > done "right", i think what really ought to happen is this:
> > >
> > > * add a "global menubar" option to the Desktop -> Workspace control
> panel
> > > in
> > > system settings
> >
> > That seems more or less clear. That's systemsettings application
> > (kdebase/workspace/systemsettings). But where can I find code that
> > configures the exact panel "Desktop->Workspace"?
> >
> > > * create a Plasma::Containment of type Panel for the menubar; it would
> be
> > > much
> > > like the current Panel containment, but it would have the
> implementation
> > > of the menubar directly inside it, and it would arrange other plasmoids
> > > around it. this means that the menubar itself wouldn't be so much a
> > > separate plasmoid
> > > as it would a Plasma::Contaiment. this would go into
> > > kdebase/workspace/plasma/desktop/containments/.
> >
> > So, that's a subclass of Plasma::Containment, but most of code is copied
> > from Panel and some special features added?
>
> yes. (not that there is all that much code in the Panel containment; and
> some
> of what is there could probably be done cleaner at this point)
>


And then KDE applications should add their applet-menus into the menubar
containment?

Or maybe a special interface should be created for adding something like
QMenu there and encapsulate applet creation inside menubar?


Anyway, this project will probably need some demostration of really working
MacOS menubar. Thus some applications should be hacked to provide their
menus (or applets with menus) for menubar?


>
> > > top of the screen, it would not be resizeable (always the height of the
> > > menubar) and it would not be directly removable (system settings would
> > > control
> > > it)
> >
> > I didn't really get the idea of that passage. I'm a newbie in Plasma, so
> > can you please tell me what's the responsibility of PanelView (didn't
>
> PanelView is the actual window. it is a QGraphicsView which views an area
> of
> the QGraphicsScene (the Corona class), in particular it shows the area of
> the
> scene on which the panel Containment is. PanelView is responsible for the
> position on screen, autohiding, those sorts of things.
>
> > understand it from docs and code) -- to create Containments like Desktop
> > and Panel?
>
> that's handled by the Corona. the View just displays them.
>
> > And what's "that configuration option"?
>
> the "global menubar" option in the Desktop -> Workspace control panel. so
> when
> the user turns that on, plasma-desktop will then create the menubar view
> automatically.
>
> this is how it was done, eventually, in kicker in kde3 as well. prior to
> that
> the user had to set it all up themself: add a new panel, add the menubar
> applet, turn the configuration option on in kcontrol, etc, etc. it was a
> hassle and not clear at all how to do it. so i ended up rewriting it so
> that
> just turning the option on in kcontrol made kicker set up the panel for the
> user automatically.
>
> this would be the same goal with plasma-desktop.
>

Okay, I see. Thanks for explaining.

>
> > About keeping it always on the top of screen: maybe the position (top or
> > botton) of menubar should be configured in control panel as well?
>
> does it make any sense to have the menubar at the bottom of the screen?
> (certainly doesn't on the left/right, we know that much for sure ;)
>


As for me, I keep a panel with taskbar and icons in the top of screen, so I
may want to have menubar in the bottom. Sounds wild, but why not..?



>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
> ___
> 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: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag & drop marker.

[Lukas Appelhans]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3358/#review4843
---


All in all it looks good to me... I haven't tested it, but I found a pair of 
issues...

Thanks,

Lukas


/trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp


Why two layouts and why not as member-vars?



/trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp


Why this? We have this in the else-statement as well... :)



/trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp


If itemsChanged is false, then we don't even need to care about the stuff 
above... we just need to set the preferred size...


- Lukas


On 2010-04-01 20:01:41, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3358/
> ---
> 
> (Updated 2010-04-01 20:01:41)
> 
> 
> Review request for Plasma.
> 
> 
> 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 posi

Re: Review Request: Prefetching in Comic Strip plasmoid

[Matthias Fuchs]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2636/#review4848
---

Ship it!


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.

- Matthias


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: global menu bar for gsoc

[Aaron J. Seigo]

On April 1, 2010, Ivan Ruchkin wrote:
> 2010/3/31 Aaron J. Seigo 
> 
> > On March 30, 2010, Ivan Ruchkin wrote:
> > > 2010/3/29 Aaron J. Seigo 
> > > 
> > > > On March 28, 2010, you wrote:
> > > > > My name is Ivan, I'd like to improve global Mac-OS style menu bar
> > > > > as
> > 
> > my
> > 
> > > > > GSoC project.
> > > > > Can you please point me to the development code of it?
> > > > > How does it corellate with XBar plasmoid?
> > > > 
> > > > there is a fairly old start to such a plasmoid in:
> > > >/trunk/playground/base/plasma/applets/menubar/
> > > > 
> > > > it has no relation to the xbar plasmoid, which only works with
> > > > bespin.
> > > > 
> > > > done "right", i think what really ought to happen is this:
> > > > 
> > > > * add a "global menubar" option to the Desktop -> Workspace control
> > 
> > panel
> > 
> > > > in
> > > > system settings
> > > 
> > > That seems more or less clear. That's systemsettings application
> > > (kdebase/workspace/systemsettings). But where can I find code that
> > > configures the exact panel "Desktop->Workspace"?
> > > 
> > > > * create a Plasma::Containment of type Panel for the menubar; it
> > > > would
> > 
> > be
> > 
> > > > much
> > > > like the current Panel containment, but it would have the
> > 
> > implementation
> > 
> > > > of the menubar directly inside it, and it would arrange other
> > > > plasmoids around it. this means that the menubar itself wouldn't be
> > > > so much a separate plasmoid
> > > > as it would a Plasma::Contaiment. this would go into
> > > > kdebase/workspace/plasma/desktop/containments/.
> > > 
> > > So, that's a subclass of Plasma::Containment, but most of code is
> > > copied from Panel and some special features added?
> > 
> > yes. (not that there is all that much code in the Panel containment; and
> > some
> > of what is there could probably be done cleaner at this point)
> 
> And then KDE applications should add their applet-menus into the menubar
> containment?
> 
> Or maybe a special interface should be created for adding something like
> QMenu there and encapsulate applet creation inside menubar?

there are a few approaches to this, including using xembed or a dbus based 
system (e.g. where the active window can be queried for its top level menubar 
entries, and a signal sent to the application to show the corresponding menu 
in the correct location when it is activated). perhaps look at how bespin is 
doing this currently, how the menubar kick applet in kde3 did it and perhaps 
look at how other systems on x11 do this (if any do?)

> > > About keeping it always on the top of screen: maybe the position (top
> > > or botton) of menubar should be configured in control panel as well?
> > 
> > does it make any sense to have the menubar at the bottom of the screen?
> > (certainly doesn't on the left/right, we know that much for sure ;)
> 
> As for me, I keep a panel with taskbar and icons in the top of screen, so I
> may want to have menubar in the bottom. Sounds wild, but why not..?

because offering configuration options that make no sense is inelegant and 
comes at a cost to testability, quality and usability.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Containment view

[Aaron J. Seigo]

On April 1, 2010, todd rme wrote:
> On Thu, Apr 1, 2010 at 4:30 PM, Aaron J. Seigo  wrote:
> > On April 1, 2010, todd rme wrote:
> >> On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
> >> > On April 1, 2010, todd rme wrote:
> >> >> the best way to go about getting help on this matter.  Should I
> >> >> attach the crash report to an email?
> >> > 
> >> > yes
> >> 
> >> Here it is.
> > 
> > it's a bug and crash in Qt. what version of Qt are you using?
> 
> 4.6.2-107.1 (openSUSE version).  Are you sure the bug is the fault of
> Qt?  The code is based on the screensaver corona's add widget dialog,
> and it doesn't crash.  Neither does the desktop corona version.  I
> would think that if everything else works fine, but my program
> crashes, then the problem is probably in my program, right?

not necessarily; you could just be doing things in an order that triggers a 
crash in Qt. in particular, it looks like during the creation of the widget 
exporer, the tooltip is being created and set up and Qt is barfing on that. it 
shouldn't, but that's what it is doing.

perhaps you could commit your code and we could work this out together. please 
commit it to /trunk/playground/base/plasma/shells/

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: global menu bar for gsoc

[Marco Martin]

On Thursday 01 April 2010, Aaron J. Seigo wrote:
> On April 1, 2010, Ivan Ruchkin wrote:
> > > 
> > > > > of the menubar directly inside it, and it would arrange other
> > > > > plasmoids around it. this means that the menubar itself wouldn't be
> > > > > so much a separate plasmoid
> > > > > as it would a Plasma::Contaiment. this would go into
> > > > > kdebase/workspace/plasma/desktop/containments/.
> > > > 
> > > > So, that's a subclass of Plasma::Containment, but most of code is
> > > > copied from Panel and some special features added?
> > > 
> > > yes. (not that there is all that much code in the Panel containment;
> > > and some
> > > of what is there could probably be done cleaner at this point)
> > 
> > And then KDE applications should add their applet-menus into the menubar
> > containment?
> > 
> > Or maybe a special interface should be created for adding something like
> > QMenu there and encapsulate applet creation inside menubar?
> 
> there are a few approaches to this, including using xembed or a dbus based
> system (e.g. where the active window can be queried for its top level
> menubar entries, and a signal sent to the application to show the
> corresponding menu in the correct location when it is activated). perhaps
> look at how bespin is doing this currently, how the menubar kick applet in

i just had a quick look years ago but afaik bespin does something based on 
dbus
the theme eradicates the menubar in polish() then publishes the list of the 
toplevel actions on the bus, when one clicks on a menu entry of the xbar 
applet, a dbus method gets called with the click position, so the theme will 
move the corresponding qmenu at the proper position.
it's absolutely cruent, but i quite don't see other ways to interact so low in 
a standard qt component?

> kde3 did it and perhaps look at how other systems on x11 do this (if any
> do?)

kde3 eradicated the sub window with the menubar and xembedded it there(not 
possible anymore with alien widgets is suppose), gnome has a dbus spec for 
that iirc


Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag & drop marker.

[Ingomar Wesp]

> On 2010-04-01 21:18:42, Lukas Appelhans wrote:
> > All in all it looks good to me... I haven't tested it, but I found a pair 
> > of issues...
> > 
> > Thanks,
> > 
> > Lukas

Thanks for having a look :)


> On 2010-04-01 21:18:42, Lukas Appelhans wrote:
> > /trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp,
> >  line 205
> > 
> >
> > Why this? We have this in the else-statement as well... :)

You're right, this is unnecessary. I'll remove it shortly.


> On 2010-04-01 21:18:42, Lukas Appelhans wrote:
> > /trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp,
> >  line 135
> > 
> >
> > Why two layouts and why not as member-vars?

> Why two layouts

I'm currently using the outer linear layout because I need a spacer (stretch) 
that pushes the icons to the top (for horizontal panel/desktop) or to the left 
(in vertical panels) if there is more space available than needed.

This also prevents the inner grid layout from resizing the individual icons 
beyond their preferred size because of excess space.

> why not as member-vars

I didn't see the need in saving the pointers in member vars as they are 
accessible through layout() and layout->itemAt(0). I do agree, however, that 
the latter is pretty ugly (as is the casting required to use them).

In the long run, I think it would be preferrable to put all the layouting code 
in a custom QGraphicsLayout subclass that is not a subclass of 
QGraphicsGridLayout (as this would imply that we constantly have to add/remove 
items in order to get the wrapping right). Something like a flow layout with a 
fixed cell size, maybe.


> On 2010-04-01 21:18:42, Lukas Appelhans wrote:
> > /trunk/KDE/kdebase/workspace/plasma/generic/applets/quicklaunch/quicklaunchicongrid.cpp,
> >  line 486
> > 
> >
> > If itemsChanged is false, then we don't even need to care about the 
> > stuff above... we just need to set the preferred size...

Well, actually we do have to care, as we need to check whether the current 
row/column wrapping is still valid after a resize, change of orientation or a 
change to the icon size hint.


- Ingomar


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3358/#review4843
---


On 2010-04-01 20:01:41, Ingomar Wesp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3358/
> ---
> 
> (Updated 2010-04-01 20:01:41)
> 
> 
> Review request for Plasma.
> 
> 
> 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 a

Re: Containment view

[todd rme]

On Thu, Apr 1, 2010 at 5:47 PM, Aaron J. Seigo  wrote:
> On April 1, 2010, todd rme wrote:
>> On Thu, Apr 1, 2010 at 4:30 PM, Aaron J. Seigo  wrote:
>> > On April 1, 2010, todd rme wrote:
>> >> On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
>> >> > On April 1, 2010, todd rme wrote:
>> >> >> the best way to go about getting help on this matter.  Should I
>> >> >> attach the crash report to an email?
>> >> >
>> >> > yes
>> >>
>> >> Here it is.
>> >
>> > it's a bug and crash in Qt. what version of Qt are you using?
>>
>> 4.6.2-107.1 (openSUSE version).  Are you sure the bug is the fault of
>> Qt?  The code is based on the screensaver corona's add widget dialog,
>> and it doesn't crash.  Neither does the desktop corona version.  I
>> would think that if everything else works fine, but my program
>> crashes, then the problem is probably in my program, right?
>
> not necessarily; you could just be doing things in an order that triggers a
> crash in Qt. in particular, it looks like during the creation of the widget
> exporer, the tooltip is being created and set up and Qt is barfing on that. it
> shouldn't, but that's what it is doing.
>
> perhaps you could commit your code and we could work this out together. please
> commit it to /trunk/playground/base/plasma/shells/


I don't have svn access.

-Todd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: GSoC : Multiscreen management

[Björn Ruberg]

> 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. 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Plasma::DialogManager

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3474/
---

Review request for Plasma.


Summary
---

this is the DialogManager class, as discussed before on irc with aaron. will 
let plasma-netbook and plasma mobile show the config uis in a bit fancier way
the base class happily does exactly nothing, actual implementations will be 
only in shells.
there are still some doubts, expressed by the various todo/fixme :)


Diffs
-

  /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1110066 
  /trunk/KDE/kdelibs/plasma/applet.h 1110066 
  /trunk/KDE/kdelibs/plasma/applet.cpp 1110066 
  /trunk/KDE/kdelibs/plasma/corona.h 1110066 
  /trunk/KDE/kdelibs/plasma/corona.cpp 1110066 
  /trunk/KDE/kdelibs/plasma/dialogmanager.h PRE-CREATION 
  /trunk/KDE/kdelibs/plasma/dialogmanager.cpp PRE-CREATION 

Diff: http://reviewboard.kde.org/r/3474/diff


Testing
---


Thanks,

Marco

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Containment view

[Aaron J. Seigo]

On April 1, 2010, todd rme wrote:
> On Thu, Apr 1, 2010 at 5:47 PM, Aaron J. Seigo  wrote:
> > On April 1, 2010, todd rme wrote:
> >> On Thu, Apr 1, 2010 at 4:30 PM, Aaron J. Seigo  wrote:
> >> > On April 1, 2010, todd rme wrote:
> >> >> On Thu, Apr 1, 2010 at 2:44 PM, Aaron J. Seigo  wrote:
> >> >> > On April 1, 2010, todd rme wrote:
> >> >> >> the best way to go about getting help on this matter.  Should I
> >> >> >> attach the crash report to an email?
> >> >> > 
> >> >> > yes
> >> >> 
> >> >> Here it is.
> >> > 
> >> > it's a bug and crash in Qt. what version of Qt are you using?
> >> 
> >> 4.6.2-107.1 (openSUSE version).  Are you sure the bug is the fault of
> >> Qt?  The code is based on the screensaver corona's add widget dialog,
> >> and it doesn't crash.  Neither does the desktop corona version.  I
> >> would think that if everything else works fine, but my program
> >> crashes, then the problem is probably in my program, right?
> > 
> > not necessarily; you could just be doing things in an order that triggers
> > a crash in Qt. in particular, it looks like during the creation of the
> > widget exporer, the tooltip is being created and set up and Qt is
> > barfing on that. it shouldn't, but that's what it is doing.
> > 
> > perhaps you could commit your code and we could work this out together.
> > please commit it to /trunk/playground/base/plasma/shells/
> 
> I don't have svn access.

you should fix that ;)

seriously, if you are going to continue to work on this, let's get you hooked 
up:

http://techbase.kde.org/Contribute/Get_a_SVN_Account

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: global menu bar for gsoc

[Ryan Rix]

On Thu 1 April 2010 3:04:18 pm Marco Martin wrote:
> gnome has a dbus spec for 
> that iirc

http://code.google.com/p/gnome2-globalmenu/wiki/GlobalMenuSpecification ? 
afaict, that's the "official" globalmenu applet for GNOME.

See also, a fairly old blog post explaining all of the global menu whatnots 
since kde3... http://frinring.wordpress.com/2009/01/29/mac-style-menubar-
for-kde-4-and-others/

Ryan

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==


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: Plasma Media Center and state machines

[Shantanu Tushar Jha]

(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-

User chooses "Pictures", containment goes to Pictures state and emits
a signal which other components receive and decide what to do (which
will be generally changing their states too), and so they can layout
themselves (add/remove UI elements like buttons).

This way, we can just have the new plugin have its own state machine
to do its stuff. So, we get something like an independence between the
components, they just interact, there is no central manager who needs
to know everything.
Another advantage will be that we don't have to change all applets at
once for this, we can first build the containment state machine, test
it, and then commit the code (at this point some functionality will be
broken, but thats why its called playground) which helps keeping the
things in small increments and easy for the others to follow. Then we
can proceed to making the applets like controller,browser to be aware
of these changes.

Please point out if at any point I've gone wrong (or, so many
statemachines will mean lots of overhead).

Thanks,

On Fri, Apr 2, 2010 at 2:13 AM, 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.
>
>> >>     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.
>
>> > 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.
>
>> When each state object adds widgets to applets, how can the
>> MediaCenterState object know about this?
>
> what widgets to which applets?
>
>> 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)
>
>> > 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.
>
>> 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.
>
>> "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