Re: Plasma::ToolTipManager API review
Le Tuesday 21 October 2008, Aaron J. Seigo a écrit : > > > > * void setToolTipContent (QGraphicsWidget *widget, const > > > > ToolTipContent &data) > > > > > > > > This one is very much used. Should stay. I'm not sure what to do > > > > about ToolTipContent though. Makes sense internally, but maybe in the > > > > public API you want to pass the parameters in the method. Not having > > > > to construct an object, set the members, then make the call. > > > > > > have you seen how many items we pass in? =) > > > > Between one and three? Doesn't looks like a big deal to me, but maybe > > that's just me. :-) > > one and four, actually. Ah? Aren't the WId and the QPixmap kind of mutually exclusive? Oh right, fallback system if no compositing... so yeah: four. > > Now in your changes last night you added something about state of the > > manager: activated, deactivated, inhibited. I'm wondering about this > > three/state thing, wouldn't inhibited or not be enough? In your doc about > > deactivated, it means ignoring calls to setContent(), I'm not really > > confident with having a method silently discarding the content passed > > depending on a state which might be set somewhere else. Looks like a neat > > way to shoot yourself in the foot. > > the idea is for devices where we *never* want tooltips we also tend to be > more memory constrained ... so ... Ah, I see. Makes sense, might be abused from C++ though, so definitely something we don't want applet to be able to fiddle with: aka don't expose in scripting APIs. > > // no default, on purpose ;-) > > all that does it make people write more lines of code. which is silly. Improves readability on maintainance too... which isn't silly IMO. "setContent(w);" vs "setContent(w, Content());", on the first form if I read the line we could assume it's using anything as default value. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance." 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 on thinclients / poor performance
On Tuesday 21 October 2008, Martin Vogt wrote: > The thinclients are not that old, > but usually do not support GLX/OpenGL. that's fine; what sort of graphics cards and drivers are in them? > Basically, what I see, is: > > -A _poor_ performance of KDE 4.1.2 on thinclients. > > Example1: > > -Dragging the "transparent desktop Folder" (the one with > the Icons in it) ==> not very responsive/interactive. sounds like a painting efficiency issue, which could either be "too many server roundtrips" or "poor xrender acceleration in the driver" or perhaps something else even. > Example2: > > -System Settings->Desktop->Click on multiple desktops->21..22..23 > Dialog opens.(2-3 seconds) > -System Settings->Click window behavior 21,22,23 dialog opens > -Click tab "tilebar actions" 21,22,23 dialog opens. > etc... this has absolutely nothing to do with plasma, of course, and there are so many parts of the framework involved here that it's hard to know what is causing the issues without some profiling. > Does plasma/KDE 4.X gets some testing on thinclients? if you're asking whether or not anybody develops kde on a thin client, i don't think so. and we don't have test labs either; we rely on downstream for data on these kinds of things. > The remote hosts was a 2GB 2core system, with load around 0.3%. > The thinclients do handle KDE 3.5.x very well. 3.5 is a very different animal than 4.x. something to try: in the kdeglobals config, try putting this: [KDE-Global GUI Settings] GraphicEffectsLevel=0 that should kill all the animations (though unfortunately not all the gradients still need to work on that) and make things work a bit faster. -- 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 Software 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
plasma on thinclients / poor performance
Hello list, I'm currently testing plasma/KDE 4.1.2 (SUSE 11.1 beta2) on some thinclients. The thinclients are not that old, but usually do not support GLX/OpenGL. Basically, what I see, is: -A _poor_ performance of KDE 4.1.2 on thinclients. Example1: -Dragging the "transparent desktop Folder" (the one with the Icons in it) ==> not very responsive/interactive. Example2: -System Settings->Desktop->Click on multiple desktops->21..22..23 Dialog opens.(2-3 seconds) -System Settings->Click window behavior 21,22,23 dialog opens -Click tab "tilebar actions" 21,22,23 dialog opens. etc... Does plasma/KDE 4.X gets some testing on thinclients? (The overall performance on a normal desktop is fine, btw) The remote hosts was a 2GB 2core system, with load around 0.3%. The thinclients do handle KDE 3.5.x very well. regards, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma::ToolTipManager API review
On Tuesday 21 October 2008, Kevin Ottens wrote: > Le Tuesday 21 October 2008, Aaron J. Seigo a écrit : > > > * void showToolTip (QGraphicsWidget *widget) > > > * void delayedHideToolTip () > > > * void hideToolTip (QGraphicsWidget *widget) > > > > the first one was used in a recent patch until i changed the patch ;) but > > i think there are reasonable use cases for these things (action occurs -> > > show tip without wating for mouse hover) so we'll end up adding them at > > some point anyways. > > Agreed, except for delayedHideToolTip(), AFAIK it's only used internally, > this one is an implementation detail IMO (interestingly it's the only one > not taking a QGraphicsWidget arg BTW). hm.. ok, that one can go internal... > > > * void registerWidget (QGraphicsWidget *widget) > > > > > > Used several times, but always followed by a setToolTipContent() > > > call... first line of setToolTipContent() being registerWidget(). Very > > > good candidate for removal IMO. > > > > registerWidget allows you to register a widget, in other words say "watch > > this widget" without allocating memory right then for a (usually useless) > > tooltip. > > OK, I see, it's the "problem" of having this tooltip system concurrently > with the regular tooltip system of Qt. right.. > > what ought to happen is either all those calls to setToolTipContent be > > modified to use the delayed creation approach (nicer on memory usage) or > > just not call registerWidget in the first place. > > Couldn't setContent() take care of the delayed creation itself then? It > keeps the content around (obviously) but allocate the ToolTip object only > when needed. thing is that the tooltip data itself isn't tiny (it's not HUGE either, though) and it often isn't set once but highly context sensitive. see the taskbar or clock items for examples of this. so we'd be store good amounts of bogus data. > > > * void setToolTipContent (QGraphicsWidget *widget, const > > > ToolTipContent &data) > > > > > > This one is very much used. Should stay. I'm not sure what to do about > > > ToolTipContent though. Makes sense internally, but maybe in the public > > > API you want to pass the parameters in the method. Not having to > > > construct an object, set the members, then make the call. > > > > have you seen how many items we pass in? =) > > Between one and three? Doesn't looks like a big deal to me, but maybe > that's just me. :-) one and four, actually. > > > bool isToolTipActivated (QGraphicsWidget *widget) > > > > > > Never used, remove until really needed? > > > > it's probably a functional duplication of widgetHasTooltip, no? > > Seems to be a slightly different semantic, since you can have a tooltip, > but this one not being activated... oh well. I still think it could be > removed anyway. :-) it already has been =) > > > I'm not fully happy with it yet, > > > > but are you ever? ;-P > > Well, when it's my own production: never. You already know that, whatever I > do turns sour I think. always the optimist ;) > Now in your changes last night you added something about state of the > manager: activated, deactivated, inhibited. I'm wondering about this > three/state thing, wouldn't inhibited or not be enough? In your doc about > deactivated, it means ignoring calls to setContent(), I'm not really > confident with having a method silently discarding the content passed > depending on a state which might be set somewhere else. Looks like a neat > way to shoot yourself in the foot. the idea is for devices where we *never* want tooltips we also tend to be more memory constrained ... so ... > I kept static because AFAIK you weren't against it, so I assumed it was > planned but "not done yet". yeah... > // no default, on purpose ;-) all that does it make people write more lines of code. which is silly. -- 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 Software 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
keyboardLeds moved to kdereview
Hi, I moved keyboardLeds plasmoid to kdereview. Bye, Davide Bettio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma::ToolTipManager API review
Le Tuesday 21 October 2008, Aaron J. Seigo a écrit :
> > * void showToolTip (QGraphicsWidget *widget)
> > * void delayedHideToolTip ()
> > * void hideToolTip (QGraphicsWidget *widget)
>
> the first one was used in a recent patch until i changed the patch ;) but i
> think there are reasonable use cases for these things (action occurs ->
> show tip without wating for mouse hover) so we'll end up adding them at
> some point anyways.
Agreed, except for delayedHideToolTip(), AFAIK it's only used internally, this
one is an implementation detail IMO (interestingly it's the only one not
taking a QGraphicsWidget arg BTW).
> > * void registerWidget (QGraphicsWidget *widget)
> >
> > Used several times, but always followed by a setToolTipContent() call...
> > first line of setToolTipContent() being registerWidget(). Very good
> > candidate for removal IMO.
>
> registerWidget allows you to register a widget, in other words say "watch
> this widget" without allocating memory right then for a (usually useless)
> tooltip.
OK, I see, it's the "problem" of having this tooltip system concurrently with
the regular tooltip system of Qt.
> what ought to happen is either all those calls to setToolTipContent be
> modified to use the delayed creation approach (nicer on memory usage) or
> just not call registerWidget in the first place.
Couldn't setContent() take care of the delayed creation itself then? It keeps
the content around (obviously) but allocate the ToolTip object only when
needed.
Actually that's what happens in Qt itself when you use setToolTip() on a
widget. The widget only stores the content necessary to create the tooltip,
but the tooltip is created by the QToolTip::showText() call which happens on a
ToolTip event.
I guess the main problem with Plasma::ToolTipManager right now, is that it is
both QWidget::setToolTip() and QToolTip::* feature wise.
> > * void unregisterWidget (QGraphicsWidget *widget)
> >
> > Used only once by a good citizen. Otherwise widgets are never
> > unregistered, even if the tooltip content gets empty. Just like
> > registerWidget() is called by setToolTipContent(), this method should
> > probably call
> > unregisterWidget() for empty content.
>
> that implies we'd have to keep all tooltips in memory then.
Not necessarily, see above.
> registering a widget gets it watched, but it doesn't have to have any
> tooltip data registered yet.
It's the case when applications QToolTip from the Qt API, but it's done
because of application needs not how the tooltip system is implemented
underneath.
> > * void setToolTipContent (QGraphicsWidget *widget, const ToolTipContent
> > &data)
> >
> > This one is very much used. Should stay. I'm not sure what to do about
> > ToolTipContent though. Makes sense internally, but maybe in the public
> > API you want to pass the parameters in the method. Not having to
> > construct an object, set the members, then make the call.
>
> have you seen how many items we pass in? =)
Between one and three? Doesn't looks like a big deal to me, but maybe that's
just me. :-)
> > bool isToolTipActivated (QGraphicsWidget *widget)
> >
> > Never used, remove until really needed?
>
> it's probably a functional duplication of widgetHasTooltip, no?
Seems to be a slightly different semantic, since you can have a tooltip, but
this one not being activated... oh well. I still think it could be removed
anyway. :-)
> > I'm not fully happy with it yet,
>
> but are you ever? ;-P
Well, when it's my own production: never. You already know that, whatever I do
turns sour I think.
Now in your changes last night you added something about state of the manager:
activated, deactivated, inhibited. I'm wondering about this three/state thing,
wouldn't inhibited or not be enough? In your doc about deactivated, it means
ignoring calls to setContent(), I'm not really confident with having a method
silently discarding the content passed depending on a state which might be set
somewhere else. Looks like a neat way to shoot yourself in the foot.
So, second try for the API taking into account your commits and the above:
--
class ToolTip
{
static void show(QGraphicsWidget *widget,
const ToolTip::Content &content = ToolTip::Content());
static void hide(QGraphicsWidget *widget);
static void isVisible(QGraphicsWidget *widget);
static void setInhibited(bool inhibited);
static bool isInhibited();
// no default, on purpose ;-)
static void setContent(QGraphicsWidget *widget,
const ToolTip::Content &content);
};
--
I kept static because AFAIK you weren't against it, so I assumed it was
planned but "not done yet".
Now, I also tried to make clear we had three groups of methods there:
1) show/hide/isVisible
I grouped them together to make it clearer: it looks a whole lot like QToolTip
now. You could almost replace one API with the other
Re: 4.2: the binary compatible release
Aaron J. Seigo wrote: > yes, functions or methods. not data members (which i usually shortcut to > just "members", versus "methods" ... probably what caused confusion; > sorry.) > You're right. I read methods instead of members. Sorry for the noise. Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fix for plasma crash
On Tuesday 21 October 2008, Guillaume Pothier wrote: > patches. But it was probably something related to adding/removing > monitors. You can see setContainment(0) statements in > DesktopView::screenOwnerChanged and PlasmaApp::adjustSize. ok, so it's most likely the screenOwnerChanged paths then; good to know, thanks =) -- 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 Software 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: 4.2: the binary compatible release
On Tuesday 21 October 2008, Stephen Kelly wrote: > Aaron J. Seigo wrote: > > for those wondering what binary compat means for us, in a nutshell: > > > > * we can't add new members to the public classes (the dptr makes that > > unecessary in the first place, of course =) > > Are you sure about this one? positive. > Techbase says you can: > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_D >o.27s_and_Don.27ts "You cannot... [...] add new data members to a class or change order of data members in a class (doesn't apply to static ones)." > > You can add new non-virtual functions including signals and slots and > > constructors. yes, functions or methods. not data members (which i usually shortcut to just "members", versus "methods" ... probably what caused confusion; sorry.) -- 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 Software 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: 4.2: the binary compatible release
Aaron J. Seigo wrote: > for those wondering what binary compat means for us, in a nutshell: > > * we can't add new members to the public classes (the dptr makes that > unecessary in the first place, of course =) Are you sure about this one? Techbase says you can: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts > You can add new non-virtual functions including signals and slots and constructors. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fix for plasma crash
2008/10/21 Aaron J. Seigo <[EMAIL PROTECTED]>: > On Tuesday 21 October 2008, Guillaume Pothier wrote: >> Hi, >> DesktopView::setContainment is sometimes explicitly called with a null >> containment, > > hm. when does that happen? when changing the Activity via the conig dialog? or > switching between existing Activities? I don't remember exactly the sequences of actions that trigger the crash, I just stumbled upon that fix while tidying up my plasma/kephal patches. But it was probably something related to adding/removing monitors. You can see setContainment(0) statements in DesktopView::screenOwnerChanged and PlasmaApp::adjustSize. >> however this is not checked in the code. The attached >> patch solves that. Ok to commit? > > yep... Oka > > -- > 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 Software > > > > ___ > 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: panel sizing of applets
On Tuesday 21 October 2008 13:46:58 Marco Martin wrote: > On Tuesday 21 October 2008, Sebastian Kügler wrote: > > On Tuesday 21 October 2008 01:49:34 Sebastian Kügler wrote: > > > On Tuesday 21 October 2008 01:12:09 Guillaume Pothier wrote: > > > > 2008/10/20 Sebastian Kügler <[EMAIL PROTECTED]>: > > > > > Removing the sizeHint (which I did last night) makes it work. So it > > > > > turns out that our automatic machinery already works quite well. :) > > > > > > > > Not sure it is related, but now my panel is huge (and somehow the > > > > rendering gets wrapped to the top of the screen instead of blow it). > > > > Removing the battery applet solves this. > > > > However, after removing it, the taskbar applet appears very thin; > > > > growing the panel higher does make it bigger, but only to a fraction > > > > of the available height. Then making the panel smaller makes the > > > > taskbar very thin again, it seems it uses about 30% of the available > > > > height. > > > > > > I'm getting weird sizing information in the battery applet after > > > today's update. I'm also getting a huge panel that overflows to the top > > > of the screen with the battery. The battery gets a contentsRect > > > QRectF(0,0 264x269) assigned, which has obviously a bogus size. > > > > This is how it looks like with battery in panel (default for all laptops) > > right now: http://oct21.imghost.us/DPku.png > > Removing the battery applet helps, the panel gets back to normal then. > > I've looked at the battery again, but I don't see where it's going wrong. > > The initial size the battery gets seems correct (i.e. makes it fit into > > the panel), then it receives a constraintsEvent which gives it a far too > > large size. The panel then overflows and shows the effect from the > > picture. > > > > This has only happened after yesterday's update in trunk/. I've removed > > all sizing magic in the battery (i.e. no set*Size (height, width) from > > the battery, but it still buggers up the layout. I'm a bit in the dark > > here what's going on, maybe someone else can have a quick look at it (it > > must be pretty annoying, broken panel in trunk ... :/). > > this patch -seems- to fix it, it just makes sure that the minimum height > for horizontal panels is 0 and so the width for vertical panels > (i wonder if it shouldn't be forced in > applet::flushpendingconstraintevents, but maybe would just be hiding > problems) "Hiding problems" would IMO be fine in applets (we applet devs should be allowed to be stupid, no? ;-)) Those sizing problems are quite weird from an innocent POV though. (See this case, totally non-obvious what the fix would be ...). I'm all for preventing this kind of unwanted stuff somewhere lower in the stack. > oh, and a minor thing since in the panel size=contentsize, but > setminimumSize(contentsrect().size()) would make a resizing endless loop if > they were different Aye, was wondering about that. Makes sense. Thanks a lot for having a look at it! -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Fix for plasma crash
On Tuesday 21 October 2008, Guillaume Pothier wrote: > Hi, > DesktopView::setContainment is sometimes explicitly called with a null > containment, hm. when does that happen? when changing the Activity via the conig dialog? or switching between existing Activities? > however this is not checked in the code. The attached > patch solves that. Ok to commit? yep... -- 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 Software 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
Fix for plasma crash
Hi,
DesktopView::setContainment is sometimes explicitly called with a null
containment, however this is not checked in the code. The attached
patch solves that. Ok to commit?
g
Index: kdebase/workspace/plasma/shells/desktop/desktopview.cpp
===
--- kdebase/workspace/plasma/shells/desktop/desktopview.cpp (revision 874161)
+++ kdebase/workspace/plasma/shells/desktop/desktopview.cpp (working copy)
@@ -173,7 +173,7 @@
}
Plasma::ZoomLevel zoomLevel = PlasmaApp::self()->desktopZoomLevel();
-if (zoomLevel == Plasma::DesktopZoom) {
+if (zoomLevel == Plasma::DesktopZoom && containment) {
//make sure actions are up-to-date
//this is icky but necessary to have the toolbox show the right actions for the zoom level
containment->enableAction("zoom in", false);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: gui hacking sessions?
On Tuesday 21 October 2008 08:17:05 Michael Rudolph wrote: > On Thu, Oct 16, 2008 at 18:50, Celeste Lyn Paul <[EMAIL PROTECTED]> wrote: > > On Thursday 16 October 2008 11:19:52 Aaron J. Seigo wrote: > >> On Thursday 16 October 2008, Celeste Lyn Paul wrote: > >> > Would it make sense (and is there interest) for weekly (or scheduled > >> > somehow) GUI hacking sessions in #plasma? > >> > >> if you could post your "office hours" when you'll be in #plasma, i'm > >> sure people will show up (i'll help make peopel aware of the > >> opportunity) > > > > Haha.. "office hours".. although it would be a good idea for me to put it > > on my calendar. When is the best time of the day for most people? Morning > > (EST)/Afternoon (CET) or Afternoon (EST)/Evening (CET)? > > > > -- > > Celeste Lyn Paul > > Hello Celeste, > > I just wanted to enquire whether any hacking sessions have been > scheduled yet? And whether these sessions have been made more official > through a public calendar or a wiki page? Hi Michael, Not yet, I was waiting a few days to see if anyone had a preference for the time of day. It seems like around 17-19 CET/11-13 EST is when the most people are around, but there should probably be an evening EST time for people who work. I'll probably post something to the plasma list today. ~ Celeste -- Celeste Lyn Paul KDE Usability Project usability.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Toolbox positioning issue (yes, with multiple monitors...)
On Tue, Oct 21, 2008 at 9:18 AM, Thomas Fjellstrom <[EMAIL PROTECTED]> wrote: > On Thursday 16 October 2008, Guillaume Pothier wrote: >> 2008/10/16 Aaron J. Seigo <[EMAIL PROTECTED]>: >> > just curious (since i haven't actually tested it myeslf yet and need to >> > step out here for a bit): did you also test placement of the toolbox when >> > zoomed out with your patch? >> >> It works as expected: the code for scaled mode was already correct! >> g > > Woot. I've been wondering if anyone else saw that bug :o Do you mean there is a bug when zoomed out? g > >> > -- >> > 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 Software >> > >> > >> > ___ >> > 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 > > > -- > Thomas Fjellstrom > [EMAIL PROTECTED] > ___ > 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: Toolbox positioning issue (yes, with multiple monitors...)
On Thursday 16 October 2008, Guillaume Pothier wrote: > 2008/10/16 Aaron J. Seigo <[EMAIL PROTECTED]>: > > just curious (since i haven't actually tested it myeslf yet and need to > > step out here for a bit): did you also test placement of the toolbox when > > zoomed out with your patch? > > It works as expected: the code for scaled mode was already correct! > g Woot. I've been wondering if anyone else saw that bug :o > > -- > > 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 Software > > > > > > ___ > > 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 -- Thomas Fjellstrom [EMAIL PROTECTED] ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: gui hacking sessions?
On Thu, Oct 16, 2008 at 18:50, Celeste Lyn Paul <[EMAIL PROTECTED]> wrote: > On Thursday 16 October 2008 11:19:52 Aaron J. Seigo wrote: >> On Thursday 16 October 2008, Celeste Lyn Paul wrote: >> > Would it make sense (and is there interest) for weekly (or scheduled >> > somehow) GUI hacking sessions in #plasma? >> >> if you could post your "office hours" when you'll be in #plasma, i'm sure >> people will show up (i'll help make peopel aware of the opportunity) > > Haha.. "office hours".. although it would be a good idea for me to put it on > my calendar. When is the best time of the day for most people? Morning > (EST)/Afternoon (CET) or Afternoon (EST)/Evening (CET)? > > -- > Celeste Lyn Paul Hello Celeste, I just wanted to enquire whether any hacking sessions have been scheduled yet? And whether these sessions have been made more official through a public calendar or a wiki page? Thanks in advance, michael ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panel sizing of applets
On Tuesday 21 October 2008, Sebastian Kügler wrote:
> On Tuesday 21 October 2008 01:49:34 Sebastian Kügler wrote:
> > On Tuesday 21 October 2008 01:12:09 Guillaume Pothier wrote:
> > > 2008/10/20 Sebastian Kügler <[EMAIL PROTECTED]>:
> > > > Removing the sizeHint (which I did last night) makes it work. So it
> > > > turns out that our automatic machinery already works quite well. :)
> > >
> > > Not sure it is related, but now my panel is huge (and somehow the
> > > rendering gets wrapped to the top of the screen instead of blow it).
> > > Removing the battery applet solves this.
> > > However, after removing it, the taskbar applet appears very thin;
> > > growing the panel higher does make it bigger, but only to a fraction
> > > of the available height. Then making the panel smaller makes the
> > > taskbar very thin again, it seems it uses about 30% of the available
> > > height.
> >
> > I'm getting weird sizing information in the battery applet after today's
> > update. I'm also getting a huge panel that overflows to the top of the
> > screen with the battery. The battery gets a contentsRect QRectF(0,0
> > 264x269) assigned, which has obviously a bogus size.
>
> This is how it looks like with battery in panel (default for all laptops)
> right now: http://oct21.imghost.us/DPku.png
> Removing the battery applet helps, the panel gets back to normal then.
> I've looked at the battery again, but I don't see where it's going wrong.
> The initial size the battery gets seems correct (i.e. makes it fit into the
> panel), then it receives a constraintsEvent which gives it a far too large
> size. The panel then overflows and shows the effect from the picture.
>
> This has only happened after yesterday's update in trunk/. I've removed all
> sizing magic in the battery (i.e. no set*Size (height, width) from the
> battery, but it still buggers up the layout. I'm a bit in the dark here
> what's going on, maybe someone else can have a quick look at it (it must be
> pretty annoying, broken panel in trunk ... :/).
this patch -seems- to fix it, it just makes sure that the minimum height for
horizontal panels is 0 and so the width for vertical panels
(i wonder if it shouldn't be forced in applet::flushpendingconstraintevents,
but maybe would just be hiding problems)
oh, and a minor thing since in the panel size=contentsize, but
setminimumSize(contentsrect().size()) would make a resizing endless loop if
they were different
Cheers,
Marco Martin
> Thanks,
Index: battery.cpp
===
--- battery.cpp (revision 874297)
+++ battery.cpp (working copy)
@@ -168,20 +168,23 @@
if (constraints & (Plasma::FormFactorConstraint | Plasma::SizeConstraint)) {
if (formFactor() == Plasma::Vertical) {
if (!m_showMultipleBatteries) {
-setMinimumHeight(qMax(m_textRect.height(), contentsRect().width()));
+setMinimumHeight(qMax(m_textRect.height(), size().width()));
} else {
-setMinimumHeight(qMax(m_textRect.height(), contentsRect().width()*m_numOfBattery));
+setMinimumHeight(qMax(m_textRect.height(), size().width()*m_numOfBattery));
}
+setMinimumWidth(0);
//kDebug() << "Vertical FormFactor";
} else if (formFactor() == Plasma::Horizontal) {
if (!m_showMultipleBatteries) {
-setMinimumWidth(qMax(m_textRect.width(), contentsRect().height()));
+setMinimumWidth(qMax(m_textRect.width(), size().height()));
} else {
-setMinimumWidth(qMax(m_textRect.width(), contentsRect().height()*m_numOfBattery));
+setMinimumWidth(qMax(m_textRect.width(), size().height()*m_numOfBattery));
}
+setMinimumHeight(0);
//kDebug() << "Horizontal FormFactor" << m_textRect.width() << contentsRect().height();
} else {
setMaximumSize(QWIDGETSIZE_MAX, QWIDGETSIZE_MAX);
+setMinimumSize(KIconLoader::SizeSmall, KIconLoader::SizeSmall);
}
}
if (!m_showMultipleBatteries || m_numOfBattery < 2) {
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: panel sizing of applets
On Tuesday 21 October 2008 01:49:34 Sebastian Kügler wrote: > On Tuesday 21 October 2008 01:12:09 Guillaume Pothier wrote: > > 2008/10/20 Sebastian Kügler <[EMAIL PROTECTED]>: > > > Removing the sizeHint (which I did last night) makes it work. So it > > > turns out that our automatic machinery already works quite well. :) > > > > Not sure it is related, but now my panel is huge (and somehow the > > rendering gets wrapped to the top of the screen instead of blow it). > > Removing the battery applet solves this. > > However, after removing it, the taskbar applet appears very thin; > > growing the panel higher does make it bigger, but only to a fraction > > of the available height. Then making the panel smaller makes the > > taskbar very thin again, it seems it uses about 30% of the available > > height. > > I'm getting weird sizing information in the battery applet after today's > update. I'm also getting a huge panel that overflows to the top of the > screen with the battery. The battery gets a contentsRect QRectF(0,0 > 264x269) assigned, which has obviously a bogus size. This is how it looks like with battery in panel (default for all laptops) right now: http://oct21.imghost.us/DPku.png Removing the battery applet helps, the panel gets back to normal then. I've looked at the battery again, but I don't see where it's going wrong. The initial size the battery gets seems correct (i.e. makes it fit into the panel), then it receives a constraintsEvent which gives it a far too large size. The panel then overflows and shows the effect from the picture. This has only happened after yesterday's update in trunk/. I've removed all sizing magic in the battery (i.e. no set*Size (height, width) from the battery, but it still buggers up the layout. I'm a bit in the dark here what's going on, maybe someone else can have a quick look at it (it must be pretty annoying, broken panel in trunk ... :/). Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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
