Re: Plasmate previewer
Hi Shantanu, I got that one more or less sorted out already, and am now thinking about what's the best way to arrange the code before committing :P On that topic, now that I've actually tried out using a KMenu, I actually like it better than the overlay - it's keyboard accessible and the overlay has visibility problems with certain backgrounds. I'd actually be quite happy if we just used a KMenu all the way :P What do you think? For now I'm implementing what we discussed - use KMenu only when it's small. I'll try getting my stuff committed by the end of today. In the meantime maybe you could help me take a look at my refresh applet code? At least for me, the applet always ends up being a little smaller post-refresh, and I'm not sure how to fix that :P Will get on #plasma in case you'd like to talk. On 7/11/09, Shantanu Tushar Jha jhahon...@gmail.com wrote: Hi, so my exams are finished now. Yuen has sorted out most of the things we discussed. Now, I think next we should fix the previewer_being_small problem. As far as I remember, we can provide a menu whenever the previewer is too small for the overlay to be displayed correctly (not removing the overlay completely). I'm taking a look how to implement using a KMenu, just wanted to know if you're doing something already, Yuen? -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate previewer
On Sat, Jul 11, 2009 at 11:56 AM, Yuen Hoe Lim yuenho...@gmail.com wrote: Hi Shantanu, I got that one more or less sorted out already, and am now thinking about what's the best way to arrange the code before committing :P On that topic, now that I've actually tried out using a KMenu, I actually like it better than the overlay - it's keyboard accessible and the overlay has visibility problems with certain backgrounds. I'd actually be quite happy if we just used a KMenu all the way :P What do you think? Well, I kind of like the Overlay, but it is a personal opinion, so I think we gather others' opinion on this. Maybe on #plasma. Even I was trying how to use a KMenu right now, but as you've already done it, I'm eager to see it in action :) For now I'm implementing what we discussed - use KMenu only when it's small. I'll try getting my stuff committed by the end of today. In the meantime maybe you could help me take a look at my refresh applet code? At least for me, the applet always ends up being a little smaller post-refresh, and I'm not sure how to fix that :P Let me check it out. Will get on #plasma in case you'd like to talk. Yep, I'm there right now, come if you can :) On 7/11/09, Shantanu Tushar Jha jhahon...@gmail.com wrote: Hi, so my exams are finished now. Yuen has sorted out most of the things we discussed. Now, I think next we should fix the previewer_being_small problem. As far as I remember, we can provide a menu whenever the previewer is too small for the overlay to be displayed correctly (not removing the overlay completely). I'm taking a look how to implement using a KMenu, just wanted to know if you're doing something already, Yuen? -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ -- 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: Review Request: Fix scrolling with mouse (without wheel) in krunner
On Friday 10 July 2009 15:23:24 Aaron J. Seigo wrote: On Friday 10 July 2009, Jacopo De Simoi wrote: foreground is the same used to draw the background of the widget, therefore putting 0 alpha would make the dialog as well transparent. that completely depends on the composition mode. For sure, but DestinationIn seems the correct choice to me... Again, It seems that I have to redirect the painter to a pixmap and then blend over it, that's what you do in the resultitem::paint iirc... Any better idea than render(), again? there should be no need to render to a pixmap. something is not right in your code. i'll try and take a look on the airplane later today. That would be great! right now I'm going to a (sicilian) wedding and I'll probably be ko for a couple of days ;) Thanks a lot. J ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
plasmate changelog
Hi Diego, I was editing the PlasMate changelog just now and noticed the ordering of the entries is somewhat off, and while I was correcting that I noticed that your changelog entries were dated June 5 and June 7 but your svn commits were dated July 6 and July 7 :P I assumed those were typos and went ahead and changed your changelog entry dates to July 5 and July 7, and just now committed. Just letting you know :) and I apologize beforehand if those weren't in fact typos. -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bof?
Forwarding to kwin mailinglist - please remeber to keep both lists in cc Am Samstag 11 Juli 2009 00:40:33 schrieb Marco Martin: On 7/10/09, Chani chan...@gmail.com wrote: here's my notes from the bof... sorry, they're not the greatest. does anyone else have notes? summary: pretty much everything is doable, but plasma guys will need to do most of the work. kwin guys need to write us some specs and give guidance. -- the kwin guys want things to happen, but like most projects they're really short on manpower. lubos is going on vacation and then will have something else he needs to work on. the slide effect should be in kwin there were worries it would conflict with fade - no, turns out it was actually scale-in. and that can be fixed (also, it's off by default) the view-per-desktop option is being (has been?) moved to a kcm. we need some sort of notification when it changes. the # of rows in the pager needs the same thing to happen. ATM if you have two pagers and change the rows in one, the other doesn't notice. and hte option real ly doesn't belong in the plasmoid. plasma wants a nice shiny API to call instead of using xatoms n'stuff directly. this would simplify plasma code, protect kwin's internals from the world, stop exposing implementation details. if kwin needs to change those details later it' ll be much easier with an API. it'll go into libkworkspace we need a proper way to mark panels, popups, etc. as don't-show (in taskbar, alt-tab, etc) it'll be a special window type right now plasma is doing icky things to do this itself, it's not good. konq has some java windows in alt-tab but that's probably a konq bug types of windows that shouldn't be shown: -pager -popups -dashboard?? -... plasma needs to give kwin a list of what types are wanted. someone remarked that the popup-shows-over-screensaver bug was solved in the wrong place. the dashboard is handled by plasma, it'd be better if kwin did that the first priority is making it work with kwin. getting it to work in other window managers comes second. if necessary we can check if kwin is running, and if it is do things the good way, if not then do ugly hacks. would kwin be able to publish some capabilities for us to check this? yes. this is another window type we'll need aaron's willing to do (or find someone to do) the work, but needs kwin to state what's acceptable there are windownamager classes in kdeui that can be copypasted to add new [window types?] effects are easy, hte dashboard will be slightly harder. hte UI continuity/theming stuff is already done :) someone thought it would be nice to have a close-button on popupapplets so that you don't have to find the icon htey came from to close them, but there may not always be a good place to put the button the glow when you get near a hidden panel should be done by kwin right now it's slow and is intercepting clicks, which is evil to do it in kwin: -plasma should publish locations kinda same format as extended structs, edge, start and stop, we won't heed the height tough -kwin should tell plasma when the mouse touches that area -could this tie into hte slide effect? or might we want to use it for more stuff later? -the panel should announce what things there are, not tell kwin exactly what to do. everyone really agrees on this :) nuno wants to be able to have two colours for the active-window glow effect. plasma is doing its own shadows. this sucks. yes and no. their look is really dependent on the theme style (compare shadows of air and oxygen for instance) what really sucks is that shadows are counted in the window geometry right now kwin can't do them for shaped windows. nobody's got a solution for this. if a clear specification can be written for effects, zack may be willing to write some awesome ones. but they really have to be clear specs right now there's not much structure to the effects what we need is technical details, not stuff about how it looks -how to publish information -naming of things like xatoms -a list of xatoms - don't much care what they are, but kwin should make them up. this should be generic, not tied to plasma. we should ask on the kwin mailing list before doing weird stuff with windows the panel has an ugly hack for slide in/out if kwin were to do this the shadows would be a lot less broken still the problem that the shadow would also be drawn behind the panel but perhaps semi acceptable in the short term? what kwin needs from plasma: set some atoms on a visible window [like the desktop view?] uuh, visible window? ...I didn't understand the next few minutes of the conversation; lubos was explaining compilcated stuff -- This message brought to you by eevil bananas and the
Re: windowgroups / pager / ZUI
Am Samstag 11 Juli 2009 02:25:04 schrieb Sebastian Kügler: Forgot to cross-post. Of course this needs to go to k...@kde.org as well... On Saturday 11 July 2009 01:20:35 Sebastian Kügler wrote: So today during lunch, Chani, Marco, Rich and I were talking about the ZUI and the confusion between the ZUI and virtual desktops. We came up with a design that would make it less confusing. The idea is to make virtual desktop less zui-like. Virtual desktops are basically groups of windows that can live on top of an activity (or rather, a context), they can also be tied to this context. The idea is to remove the zoom-out grid metaphore from virtual desktops, and make it clearer that those are window groups. Instead of adding a window to a virtual desktop, they're tagged with a group. (This can also allow for session saving, saving and starting groups of windows. An activity would have a plasma context and possibly a set of applications. Switching to an activity would switch to this plasma activity and start the set of windows related to this. The desktop grid effect (which zooms out and therefore looks a lot like the ZUI) would be replaced by a column-based layout, much like present windows. You can drag windows from one column to another (effectively moving them from one group to another). The concept of virtual desktops is completely replaced by window groups. Switching between virtual desktops is done like shown in the mockup. A modified present windows effect that groups the windows in columns is used to visualize this. = Example: Work Activity = The email client is started, an office application is started, the desktop contains a folderview with my current project's work document, and some RSS feeds that are relevant to my work. = How does the ZUI look like = The ZUI could have the background of a faded to black current activity, or black. Adding and removing an activity rearranges the activities for optimal space usage (if you search for gnome shell on youtube, the first hit gives a nice example how this could look like. (We agreed that the visualization is quite nice, but the concepts are a bit weak since it's not much more than a polished virtual desktop grid). vdesktop (in fact windowgroup switcher): http://imagebin.ca/view/YXgSWis.html gnome-shell screencast: http://www.youtube.com/watch?v=kcpndKUx4pc So much for the braindump from today's lunch session :-) This is quite a departure from the concepts as we're using it now, and I think quite a bit of work to implement. It didn't stop us from talking about this idea of course :-) We can also offer a traditional/simple mode, much like it's now, : but without ZUI at all. That would just mean keeping what we have now and removing the zoom-out. The idea sounds completely awesome and I think we should implement it. But this will require lots of work and I do not dare to touch any code of it before KDE has switched to git. So I prupose that we start to design the whole thing first and discuss it in length during Tokamak III and get some things into techbase. And then I'd say we start working on the code after 4.4 and the switch to git. So we could with good luck have some things already in 4.5 and with the help from GSoC get that really started in 4.6 (yeah that's ambitious). So let's start by thinking who should be involved in the discussion: * plasma * kwin * usability team * GNOME shell (how do they want to implement their activities. Can we get it both in a way that switching from GNOME to KDE and vice versa is not a too big step in the concept from user point of view) * Compiz (with that change and GNOME Shell Compiz would be dead :-( let's at least try to not knock them out) * anyone missing? 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: KDE/kdeplasma-addons/applets/pastebin
On Friday 10 July 2009, 23:52 Travis wrote: They prefer you to use the api which returns a small amount of plaintext where you just need to take the final line and that's your URL. I've done this for the Konversation tinyurl shell script found here: http://lxr.kde.org/source/extragear/network/konversation/data/scripts/tinyu rl Thanks for your feedback. I was not able to find their api before. I'll fix this asap ;). That was the idea of CCing the mailing list ;) Cheers, -- Artur Duque de Souza openBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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: Plasmate previewer
Hey, I'll be off for 3 days. Going back home. Will join from there. On 7/11/09, Shantanu Tushar Jha jhahon...@gmail.com wrote: On Sat, Jul 11, 2009 at 2:06 PM, Yuen Hoe Lim yuenho...@gmail.com wrote: Hi Shantanu, I've commited modifications so that we use KMenu instead of the overlay when the previewer is small. 'Small' is decided by a static height limit - not very intelligent but should do for now :) Right now, I think it should apply to width also. Rest seems all fine to me. Try it out and see what you think :) On 7/11/09, Shantanu Tushar Jha jhahon...@gmail.com wrote: On Sat, Jul 11, 2009 at 11:56 AM, Yuen Hoe Lim yuenho...@gmail.com wrote: Hi Shantanu, I got that one more or less sorted out already, and am now thinking about what's the best way to arrange the code before committing :P On that topic, now that I've actually tried out using a KMenu, I actually like it better than the overlay - it's keyboard accessible and the overlay has visibility problems with certain backgrounds. I'd actually be quite happy if we just used a KMenu all the way :P What do you think? Well, I kind of like the Overlay, but it is a personal opinion, so I think we gather others' opinion on this. Maybe on #plasma. Even I was trying how to use a KMenu right now, but as you've already done it, I'm eager to see it in action :) For now I'm implementing what we discussed - use KMenu only when it's small. I'll try getting my stuff committed by the end of today. In the meantime maybe you could help me take a look at my refresh applet code? At least for me, the applet always ends up being a little smaller post-refresh, and I'm not sure how to fix that :P Let me check it out. Will get on #plasma in case you'd like to talk. Yep, I'm there right now, come if you can :) On 7/11/09, Shantanu Tushar Jha jhahon...@gmail.com wrote: Hi, so my exams are finished now. Yuen has sorted out most of the things we discussed. Now, I think next we should fix the previewer_being_small problem. As far as I remember, we can provide a menu whenever the previewer is too small for the overlay to be displayed correctly (not removing the overlay completely). I'm taking a look how to implement using a KMenu, just wanted to know if you're doing something already, Yuen? -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com -- Sent from Gmail for mobile | mobile.google.com 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: KDE/kdebase/workspace/plasma/applets/kickoff/core
The comment got screwed up because of the # in the bt from gdb
#0 qWarning (msg=0x7305e8d8 QObject::connect: Connecting from COMPAT
signal (%s::%s)) at
/home/mjansen/kde/trunk/src/qtmaster/src/corelib/global/qglobal.cpp:2130
#1 0x72fc230d in QObject::connect (sender=0x8a4bb0,
signal=0x7fffda8fc1e1 databaseChanged(), receiver=0xdeb5b0,
method=0x7fffda8fc169 reloadApplications(),
type=Qt::AutoConnection) at
/home/mjansen/kde/trunk/src/qtmaster/src/corelib/kernel/qobject.cpp:2534
#2 0x7fffda8f3a6e in Private (this=value optimized out, parent=value
optimized out)
at
/home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/systemmodel.cpp:97
The AppModel One is nearly identical.
On Saturday 11 July 2009 18:59:12 Michael Jansen wrote:
SVN commit 994993 by mjansen:
Fix runtime warning:
type=Qt::AutoConnection) at
/home/mjansen/kde/trunk/src/qtmaster/src/corelib/kernel/qobject.cpp:2534 at
/home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/s
ystemmodel.cpp:97 at
/home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/s
ystemmodel.cpp:134
CCMAIL:plasma-devel@kde.org
M +1 -1 systemmodel.cpp
--- trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/systemmodel.cpp
#994992:994993 @@ -94,7 +94,7 @@
q, SLOT(startRefreshingUsageInfo()));
refreshTimer.start(1);
QTimer::singleShot(0, q, SLOT(startRefreshingUsageInfo()));
-connect(KSycoca::self(), SIGNAL(databaseChanged()), q,
SLOT(reloadApplications())); +connect(KSycoca::self(),
SIGNAL(databaseChanged(const QStringList)), q,
SLOT(reloadApplications())); }
void queryFreeSpace(const QString mountPoint) {
___
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
KDE/kdebase/workspace/plasma/applets/devicenotifier
SVN commit 994992 by mjansen: Fix runtime warning: QLayout: Attempting to add QLayout to QWidget , which already has a layout CCMAIL:plasma-devel@kde.org M +1 -1 notifierdialog.cpp --- trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.cpp #994991:994992 @@ -256,7 +256,7 @@ QLabel *icon = new QLabel(m_widget); icon-setPixmap(KIcon(emblem-mounted).pixmap(KIconLoader::SizeMedium, KIconLoader::SizeMedium)); -QHBoxLayout *l_layout2 = new QHBoxLayout(m_widget); +QHBoxLayout *l_layout2 = new QHBoxLayout; l_layout2-setSpacing(0); l_layout2-setMargin(0); ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/applets/kickoff/core
SVN commit 994993 by mjansen:
Fix runtime warning:
type=Qt::AutoConnection) at
/home/mjansen/kde/trunk/src/qtmaster/src/corelib/kernel/qobject.cpp:2534
at
/home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/systemmodel.cpp:97
at
/home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/systemmodel.cpp:134
CCMAIL:plasma-devel@kde.org
M +1 -1 systemmodel.cpp
--- trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/systemmodel.cpp
#994992:994993
@@ -94,7 +94,7 @@
q, SLOT(startRefreshingUsageInfo()));
refreshTimer.start(1);
QTimer::singleShot(0, q, SLOT(startRefreshingUsageInfo()));
-connect(KSycoca::self(), SIGNAL(databaseChanged()), q,
SLOT(reloadApplications()));
+connect(KSycoca::self(), SIGNAL(databaseChanged(const QStringList)),
q, SLOT(reloadApplications()));
}
void queryFreeSpace(const QString mountPoint) {
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/applets/kickoff/core
SVN commit 994994 by mjansen: Fix runtime warning: type=Qt::AutoConnection) at /home/mjansen/kde/trunk/src/qtmaster/src/corelib/kernel/qobject.cpp:2534 at /home/mjansen/kde/trunk/src/kdebase/workspace/plasma/applets/kickoff/core/applicationmodel.cpp:280 CCMAIL: plasma-devel@kde.org M +1 -1 applicationmodel.cpp --- trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/applicationmodel.cpp #994993:994994 @@ -277,7 +277,7 @@ (void)new KickoffAdaptor(this); QDBusConnection::sessionBus().registerObject(/kickoff, this); dbus.connect(QString(), /kickoff, org.kde.plasma, reloadMenu, this, SLOT(reloadMenu())); -connect(KSycoca::self(), SIGNAL(databaseChanged()), this, SLOT(checkSycocaChange())); +connect(KSycoca::self(), SIGNAL(databaseChanged(const QStringList)), this, SLOT(checkSycocaChange())); d-fillNode(QString(), d-root); } ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
